Я часто слышу о возможной согласованности в разных выступлениях о NoSQL, сетках данных и т. Д. Кажется, что определение конечной согласованности варьируется во многих источниках (и, возможно, даже зависит от конкретного хранилища данных).
Может ли кто-нибудь дать простое объяснение, что такое конечная согласованность в общих чертах, не связанная с каким-либо конкретным хранилищем данных?
Ответы:
Возможная согласованность:
В конце концов, все серверы (вы, я, ваш сосед) знают правду (что завтра будет дождь), но тем временем клиент (его жена) ушел, думая, что будет солнечно, хотя она и просила после того, как один или несколько серверов (вы и я) имели более актуальное значение.
В отличие от строгой согласованности / соответствия ACID:
Ваш баланс ни в коем случае не может отражать что-либо, кроме фактической суммы всех транзакций, совершенных на вашем счете к этому моменту.
Причиной , почему так много систем NoSQL иметь в конечном итоге последовательности является то , что практически все они предназначены для распределения, и с полностью распределенными системами есть супер-линейные накладные для поддержания строгой последовательности (то есть вы можете только масштабировать до сих пор , прежде чем вещи начинают замедляться вниз, и когда они появляются, вам нужно использовать в геометрической прогрессии больше оборудования, чтобы продолжить масштабирование).
источник
Возможная согласованность:
В основном, поскольку для репликации данных на нескольких серверах требуется время, запросы на чтение данных могут поступать на сервер с новой копией, а затем отправляться на сервер со старой копией. Термин «возможный» означает, что в конечном итоге данные будут реплицированы на все серверы, и, таким образом, все они будут иметь актуальную копию.
Конечная согласованность является обязательной, если вы хотите читать с малой задержкой, поскольку отвечающий сервер должен возвращать свою собственную копию данных и у него нет времени для консультации с другими серверами и достижения взаимного согласия по содержанию данных. Я написал сообщение в блоге, объясняющее это более подробно.
источник
Думаю, у вас есть приложение и его копия. Затем вам нужно добавить новый элемент данных в приложение.
Затем приложение синхронизирует данные с другой репликой, показанной ниже.
Тем временем новый клиент будет получать данные с одной реплики, которая еще не обновлена. В этом случае он не может получить правильные актуальные данные. Потому что синхронизация получить какое-то время. В этом случае это не в конечном итоге согласованности
Проблема в том, как мы можем в конечном итоге добиться последовательности ?
Для этого мы используем приложение-посредник для обновления / создания / удаления данных и используем прямые запросы для чтения данных. которые помогают в конечном итоге добиться согласованности
источник
Когда приложение вносит изменение в элемент данных на одном компьютере, это изменение необходимо распространить на другие реплики. Поскольку распространение изменений не происходит мгновенно, существует интервал времени, в течение которого некоторые копии будут иметь самое последнее изменение, а другие - нет. Другими словами, копии будут несовместимы. Однако в конечном итоге изменение будет распространено на все копии, отсюда и термин «возможная согласованность». Термин «конечная согласованность» - это просто признание того, что существует неограниченная задержка в распространении изменения, сделанного на одной машине, на все другие копии. Конечная согласованность не имеет смысла и не актуальна в централизованных (единичных) системах, поскольку нет необходимости в распространении.
источник: http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf
источник
На простом английском языке мы можем сказать: хотя ваша система может находиться в несовместимых состояниях, цель всегда состоит в достижении согласованности в какой-то момент для каждой части данных.
источник
В конечном итоге согласованность означает, что изменениям требуется время для распространения, и данные могут не находиться в одном и том же состоянии после каждого действия, даже для идентичных действий или преобразований данных. Это может привести к очень плохим вещам, когда люди не знают, что они делают при взаимодействии с такой системой.
Не создавайте хранилища данных критически важных для бизнеса документов, пока вы хорошо не поймете эту концепцию. Ошибку в реализации хранилища данных документа исправить гораздо сложнее, чем в реляционной модели, потому что фундаментальные вещи, которые будут испорчены, просто не могут быть исправлены, поскольку вещи, которые требуются для их исправления, просто отсутствуют в экосистеме. Рефакторинг данных бортового хранилища также намного сложнее, чем простые преобразования ETL в СУБД.
Не все хранилища документов одинаковы. Некоторые в наши дни (MongoDB) действительно поддерживают своего рода транзакции, но миграция хранилищ данных, вероятно, сопоставима со стоимостью повторной реализации.
ПРЕДУПРЕЖДЕНИЕ: разработчики и даже архитекторы, которые не знают или не понимают технологию хранилища данных документа и боятся признать это из-за страха потерять работу, но прошли классическое обучение работе с СУБД и знают только системы ACID (насколько это может отличаться ?) и кто не знает технологии или не торопится изучать ее, пропустит разработку хранилища данных документа. Они также могут попробовать использовать его в качестве СУБД или для таких вещей, как кеширование. Они разбивают то, что должно быть атомарными транзакциями, которые должны работать со всем документом, на «реляционные» части, забывая, что репликация и задержка - это вещи, или, что еще хуже, втягивают сторонние системы в «транзакцию». Они сделают это, чтобы их РСУБД могла отражать их озеро данных, независимо от того, будет оно работать или нет, и без тестирования, потому что они знают, что делают. Тогда они будут удивлены, когда в сложных объектах, хранящихся в отдельных документах, таких как «заказы», «элементов заказа» будет меньше, чем ожидалось, или, возможно, их вообще нет. Но это случится не часто или достаточно часто, поэтому они просто идут вперед. Они могут даже не столкнуться с проблемой в разработке. Затем, вместо того, чтобы переделывать вещи, они будут использовать «задержки», «повторные попытки» и «проверки», чтобы подделать реляционную модель данных, которая не будет работать, но добавит дополнительной сложности без всякой пользы. Но уже слишком поздно - вещь развернута, и теперь на ней работает бизнес. В конце концов, вся система будет выброшена, а отдел будет отдан на аутсорсинг, и кто-то другой будет его обслуживать. Он по-прежнему не будет работать правильно, но они могут выйти из строя дешевле, чем текущий сбой.
источник
Конечная последовательность больше похожа на спектр. С одной стороны, у вас есть сильная последовательность, а с другой - конечная последовательность. Между ними есть такие уровни, как «Снимок», «Чтение моих записей», ограниченное устаревание. Дуг Терри в своей статье дает прекрасное объяснение возможной последовательности в бейсболе .
По моему мнению, конечная согласованность - это в основном терпимость к случайным данным в случайном порядке каждый раз, когда вы читаете их из хранилища данных. Все, что лучше, является более сильной моделью согласованности. Например, моментальный снимок содержит устаревшие данные, но при повторном чтении он будет возвращать те же данные, что делает его предсказуемым. Иногда приложение может допускать данные, которые устарели в течение определенного времени, по истечении которого ему требуются согласованные данные.
Если вы посмотрите на значение согласованности, оно больше относится к единообразию или отсутствию отклонений. Таким образом, в терминах, не относящихся к компьютерным системам, это могло означать терпимость к неожиданным изменениям. Это можно очень хорошо объяснить через банкомат. Банкомат может быть в автономном режиме, что может отличаться от баланса счета основных систем. Однако есть допуск для отображения различных балансов для временного окна. После того, как банкомат подключится к сети, он сможет синхронизироваться с основными системами и отобразить тот же баланс. Таким образом, можно сказать, что банкомат в конечном итоге станет устойчивым.
источник