Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки.
G>>Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null.
CK>Костыль же жуткий.
Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь.
CK>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь.
Тогда и распределенной базы будет та же проблема.
CK>Помимо этого нужно будет как-то прозрачно дать доступ к тому что ты хранишь в памяти. Намного проще писать в эластик, например, и не думать об этом вообще. А если запись отвалилась — то выбрать следующую ноду по round robin и продолжать писать в нее.
Да, всего-то пару серверов нужно еще, со всеми вытекающими проблемами
CK>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.
Ты точно делал веб-сервисы? По процессу на запрос это сильно.
G>>Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться?
CK>Так никто ведь не заставляет в такой БД хранить такие данные, для которых ты не можешь разрулить конфликт.
Я бы больше сказал, я даже не хочу разруливать конфликты, хочу чтобы конкурентный доступ база на себя взяла, она для этого создана. Внезапно NoSQL при такой постановке вопроса начинают сосать. И сразу вспоминают про CAP.
CK> На запись запускается консенсус, а на чтение нет, поэтому даже если запись невозможна(отсутствует связь с большинством машин), можно все равно читать старые данные. Но можно читать данные через sync и в этом случае консенсус будет гоняться на чтение и оно будет уже не АР а СР.
Когда кто-нить запилит продажу билетов на такой системе я поверю, что она жизнеспособна, пока только голословные заверения.
CK>И латентность будет ниже, а пропускная способность выше.
Про быстродействие еще ни слова не было.
CK>Смотри, можно как zookeeper или etcd гонять консенсус для всех транзакций и обеспечивать с его помощью полную линеаризуемость, можно не гонять его для операций чтения, только для записи и получить сериализуемость. Можно разделить данные на части и гонять консенсус только для тех данных, которые должны быть согласованными, а для тех что не должны, можно гонять консенсус параллельно (например можно иметь транзакции, работающие в рамках одной таблицы или одной записи/документа, получится что если мы пишем в два документа, то две параллельные транзакции запустят два независимых инстанса алгоритма консенсуса, это работает быстрее и лучше масштабируется, но нельзя согласовать данные в двух документах).
Обязательно посмотрю на zookeeper.
CK>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.
Давай подробный сценаий кто к кому и вкакой момент обращается.
CK>>>Вывод из этого следует такой — нельзя делать системы без partition tolerance.
G>>Все указанные в примерах системы были AP
CK>В статье есть примеры и с VoltDB и с монгой.
Про VoltDB не в курсе, а монго — AP при чтении (возвращает мусор), а при записи вообще гарантий не дает.
G>>Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится.
CK>Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками.
Автоскейлинг мешает знать состав кластера?
CK>Ну это работает, я согласен, так можно жить. Но это не CA система. В зависимости от того как ты выбираешь мастера — система может быть СР, так как если поляжет больше половины машин, ты просто не выберешь нового мастера. Я конечно не знаю как там все работает, но подозреваю, что если нет автоскейлинга и failure детектора, то кластер не поймет что для консенсуса нужно меньше машин, а если он есть и алгоритм выбора лидера не partition tolerant, то две независимые части могут выбрать себе по мастеру.
В реальности вероятность полегания двух машин из трех в кластере мала, менее 0,01%, то есть 4 девятки на них спокойно живут.
G>>За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают.
CK>А как данные реплицируются и откуда клиенты читают данные? Просто если стойки друг друга не видят, то где гарантия что ты не прочитаешь устаревшие данные? Данные на slave-е могут быть непротиворечивыми с точки зрения ACID гарантий, но при этом отличаться от мастера.
Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две.
G>>Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД.
CK>Я бы сказал что не существует дефолтного решения. РСУБД это клево и очень широко применимо (а многим адептам NoSQL нужно просто выучить SQL наконец и выкинуть монгу на помойку), но не универсально, как и NoSQL решения. Я не могу представить РСУБД кластер, который будет в состоянии заменить наш сетап
Я бы сказал что существует, пока нет серьезных оснований использовать что-то другое.
По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы.
