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