Amazon - DynamoDB Сильные последовательные чтения: они новы и как?

В попытке использовать Dynamodb для одного из проектов, я сомневаюсь в сильной модели согласованности dynamodb. Из часто задаваемых вопросов

Сильно согласованные чтения - в дополнение к возможной последовательности, Amazon DynamoDB также дает вам гибкость и контроль, чтобы запросить строго последовательное чтение, если этого требует приложение или элемент вашего приложения. Сильно согласованное чтение возвращает результат, который отражает все записи, которые получили успешный ответ до чтения.

Из приведенного выше определения я получаю, что сильное последовательное чтение вернет последнее значение записи.

Взяв пример: Давайте скажем, что Client1 выдает команду записи в Key K1 для обновления значения от V0 до V1. Через несколько миллисекунд Client2 выдает команду чтения для ключа K1, тогда в случае сильной согласованности V1 будет возвращаться всегда, однако в случае возможной согласованности V1 или V0 могут быть возвращены. Правильно ли я понимаю?

Если это так: Что делать, если операция записи вернула успех, но данные не обновлены во всех репликах, и мы выдаем строго согласованное чтение, как оно будет гарантировать, чтобы вернуть в этом случае последнее значение записи?

Следующая ссылка AWS DynamoDB читает после согласования записи - как это работает теоретически? пытается объяснить архитектуру, стоящую за этим, но не знаю, так ли это на самом деле? Следующий вопрос, который приходит мне на ум после прохождения этой ссылки, заключается в следующем: это DynamoDb на основе Single Master, многократной подчиненной архитектуры, где записи и сильные согласованные чтения проходят через главную реплику, а обычные чтения - через других.

Ответ 1

Короткий ответ: запись в строго согласованном режиме требует, чтобы ваша запись была успешной на большинстве серверов, которые могут содержать запись, поэтому любые будущие последовательные чтения всегда будут видеть одни и те же данные, потому что последовательное чтение должно читать большинство серверы, которые могут содержать нужную запись. Если вы не выполняете строго согласованное чтение, система запросит случайный сервер для записи, и возможно, что данные не будут обновлены.

Представьте себе три сервера. Сервер 1, сервер 2 и сервер 3. Чтобы написать строго согласованную запись, вы выбираете минимум два сервера и записываете данные. Пусть выбрать 1 и 2.

Теперь вы хотите последовательно читать данные. Выберите большинство серверов. Скажем, мы выбрали 2 и 3.

Сервер 2 имеет новые данные, и это то, что возвращает система.

В конечном итоге согласованные чтения могут поступать с сервера 1, 2 или 3. Это означает, что если сервер 3 выбран случайным образом, ваша новая запись пока не появится, пока не произойдет репликация.

Если один сервер выходит из строя, ваши данные по-прежнему безопасны, но если два из трех серверов выйдут из строя, ваша новая запись может быть потеряна до восстановления автономных серверов.

Больше объяснений: DynamoDB (предполагая, что он похож на базу данных, описанную в документе Dynamo, выпущенном Amazon) использует кольцевую топологию, где данные распространяются на многие серверы. Сильная согласованность гарантируется, потому что вы напрямую запрашиваете все соответствующие серверы и получаете от них текущие данные. В кольце нет хозяина, в кольце нет подчиненных. Данная запись будет отображаться на несколько одинаковых хостов в кольце, и все эти серверы будут содержать эту запись. Нет раба, который мог бы отстать, и нет мастера, который может потерпеть неудачу.

Не стесняйтесь читать любую из многих статей по этой теме. Доступна аналогичная база данных под названием Apache Cassandra, которая также использует кольцевую репликацию.

http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf

Ответ 2

Вы можете найти ответ на свой вопрос здесь: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/APISummary.html

Когда вы выдаете строго согласованный запрос на чтение, Amazon DynamoDB возвращает ответ с самыми последними данными, которые отражают обновления по всем предшествующим связанным операциям записи, к которым Amazon DynamoDB вернул успешный ответ.

В вашем примере, если запрос updateItem для обновления значения от v0 до v1 был успешным, последующий строго согласованный запрос на чтение вернет v1.

Надеюсь, что это поможет.

Ответ 3

Отказ от ответственности: следующее не может быть проверено на основе публичной документации DynamoDB, но они, вероятно, очень близки к истине

Начиная с теории, DynamoDB использует quorums, где V - общее количество узлов реплики, Vr - это число узлов реплики запрашивает операцию чтения, а Vw - количество узлов реплики, где выполняется каждая запись. Чтение кворума (Vr) можно использовать, чтобы удостовериться, что клиент получает последнее значение, а кворум записи (Vw) можно использовать, чтобы убедиться, что записи не создают конфликтов.

Исходя из того, что в DynamoDB нет конфликтов записи (так как их нужно было бы согласовать с клиентом, таким образом, отображаться в API), мы заключаем, что DynamoDB использует Vw, который соблюдает второй закон (Vw > V/2), возможно, просто V/2+1, чтобы уменьшить латентность записи.

Теперь, когда вы читаете кворумы, DynamoDB предоставляет два разных типа чтения. Сильно согласованное чтение использует прочитанный кворум, который учитывает первый закон (Vr + Vw > V), возможно, только V/2, если мы предположим, что V/2+1 для записи, как и прежде. Однако в конечном итоге последовательное чтение может использовать только одну случайную реплику Vr = 1, поэтому она намного быстрее, но дает нулевую гарантию на согласованность.

Примечание. Существует вероятность того, что используемый кворум записи не соблюдает второй закон (Vw > V/2), но это означало бы, что DynamoDB автоматически разрешает такие конфликты (например, путем выбора последнего по местному времени) без согласования с клиент. Но я считаю, что это вряд ли будет правдой, поскольку в документации DynamoDB такой ссылки нет. Однако в этом случае остальные рассуждения остаются прежними.