Здравствуйте, chaotic-kotik, Вы писали:
G>>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
CK>Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже.
CK>Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
Так всетаки про какой availability идет речь в контексте NoSQL? Который CAP или который общечеловечский?
G>>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
CK>На практике, это важно тогда, когда возможность сохранить данные важнее целостности.
В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки.
Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null.
CK>Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения.
Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться?
Если бы клиент мог управлять свойствами системы при записи или можно было бы поделить систему на CA\CP\AP куски заранее, то проблема бы решалась. Но на практике мы этого не видим.
CK>Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
и?
G>>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
CK>Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
Прости, но CAP рассматривает свойства бинарно, либо есть, либо нет. Нельзя быть немного беременным.
На практике это означает, что большинство систем только притворяются partition tolerant или имеют это свойство в readonly режиме. А при записи теряют сразу все свойства
CK>>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>>Но тогда появляется гораздо интереснее сценарий.
G>>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
G>>Ты же сам привел аналогичный пример ниже.
CK>Биллинг можно сделать на чем-нибудь другом.
Тогда и все остальное можно сделать на другом.
На этом предлагаю закончить.
CK>Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
Потому что записи, пришедшие в разные ноды вызовут конфликт и не факт что его вообще можно решить. Eventual consistency реально работает, когда нет записей на протяжении интервала достижения согласованности. Это у Гилберт и Линч написано черным по английскому.
Я на хабре приводил пример с продажей билетов.
G>>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
CK>Вывод из этого следует такой — нельзя делать системы без partition tolerance.
Все указанные в примерах системы были AP
Получается нельзя строить системы без consistency. Ровно о том, что я говорю.
G>>Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
CK>Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится.
За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают.
G>>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
CK>Tradeoff же.
Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД.
