Здравствуйте, gandjustas, Вы писали:

G>Так всетаки про какой availability идет речь в контексте NoSQL? Который CAP или который общечеловечский?
Я уже запутался. Я топил за NoSQL и availability в этом контексте, Sinclair за все хорошее и против всего плохого.

G>В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки.
G>Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null.
Костыль же жуткий. Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь. Помимо этого нужно будет как-то прозрачно дать доступ к тому что ты хранишь в памяти. Намного проще писать в эластик, например, и не думать об этом вообще. А если запись отвалилась — то выбрать следующую ноду по round robin и продолжать писать в нее. К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.

G>Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться?
Так никто ведь не заставляет в такой БД хранить такие данные, для которых ты не можешь разрулить конфликт.

G>Если бы клиент мог управлять свойствами системы при записи или можно было бы поделить систему на CA\CP\AP куски заранее, то проблема бы решалась. Но на практике мы этого не видим.
Обычно так и есть. В той же монге, у клиента есть возможноть тупо записать данные в хранилище, как в АР систему, безусловно. А можно сделать CAS update и получить CP систему на уровне одного документа. Или вот zookeeper — по дефолту запись туда — СР, а чтение — АР. На запись запускается консенсус, а на чтение нет, поэтому даже если запись невозможна(отсутствует связь с большинством машин), можно все равно читать старые данные. Но можно читать данные через sync и в этом случае консенсус будет гоняться на чтение и оно будет уже не АР а СР.


CK>>Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
G>и?
И латентность будет ниже, а пропускная способность выше.

G>Прости, но CAP рассматривает свойства бинарно, либо есть, либо нет. Нельзя быть немного беременным.
G>На практике это означает, что большинство систем только притворяются partition tolerant или имеют это свойство в readonly режиме. А при записи теряют сразу все свойства
Не понял ход мысли. Смотри, можно как zookeeper или etcd гонять консенсус для всех транзакций и обеспечивать с его помощью полную линеаризуемость, можно не гонять его для операций чтения, только для записи и получить сериализуемость. Можно разделить данные на части и гонять консенсус только для тех данных, которые должны быть согласованными, а для тех что не должны, можно гонять консенсус параллельно (например можно иметь транзакции, работающие в рамках одной таблицы или одной записи/документа, получится что если мы пишем в два документа, то две параллельные транзакции запустят два независимых инстанса алгоритма консенсуса, это работает быстрее и лучше масштабируется, но нельзя согласовать данные в двух документах).


CK>>Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
G>Потому что записи, пришедшие в разные ноды вызовут конфликт и не факт что его вообще можно решить. Eventual consistency реально работает, когда нет записей на протяжении интервала достижения согласованности. Это у Гилберт и Линч написано черным по английскому.
G>Я на хабре приводил пример с продажей билетов.

И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.

CK>>Вывод из этого следует такой — нельзя делать системы без partition tolerance.
G>Все указанные в примерах системы были AP
В статье есть примеры и с VoltDB и с монгой.

G>Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится.
Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками. Ну это работает, я согласен, так можно жить. Но это не CA система. В зависимости от того как ты выбираешь мастера — система может быть СР, так как если поляжет больше половины машин, ты просто не выберешь нового мастера. Я конечно не знаю как там все работает, но подозреваю, что если нет автоскейлинга и failure детектора, то кластер не поймет что для консенсуса нужно меньше машин, а если он есть и алгоритм выбора лидера не partition tolerant, то две независимые части могут выбрать себе по мастеру.

G>За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают.
А как данные реплицируются и откуда клиенты читают данные? Просто если стойки друг друга не видят, то где гарантия что ты не прочитаешь устаревшие данные? Данные на slave-е могут быть непротиворечивыми с точки зрения ACID гарантий, но при этом отличаться от мастера.

G>Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД.
Я бы сказал что не существует дефолтного решения. РСУБД это клево и очень широко применимо (а многим адептам NoSQL нужно просто выучить SQL наконец и выкинуть монгу на помойку), но не универсально, как и NoSQL решения. Я не могу представить РСУБД кластер, который будет в состоянии заменить наш сетап