DynamoDB: условная запись против теоремы CAP
Используя DynamoDB, два независимых клиента пытаются записать в один и тот же элемент одновременно, используя условные записи и пытаются изменить значение, на которое ссылается условие. Очевидно, что одна из этих записей обречена на неудачу с проверкой состояния; это нормально.
Предположим, что во время операции записи происходит что-то плохое, и некоторые из различных узлов DynamoDB выходят из строя или теряют связь друг с другом. Что происходит с моими операциями записи?
Будут ли они оба блокировать или потерпеть неудачу (жертва "А" в теореме CAP)? Удастся ли им обоим добиться успеха, и только позже окажется, что один из них фактически был проигнорирован (жертва "С")? Или они так или иначе будут работать правильно из-за некоторого волшебства (последовательного хеширования?), Происходящего в системе DynamoDB?
Это кажется действительно сложной проблемой, но я не могу найти ничего, что обсуждало бы возможность проблем доступности с условными записями (в отличие, например, от согласованных операций чтения, где возможность снижения доступности является явной).
1 ответ
В этой области не хватает четкой информации, но мы можем сделать довольно убедительные выводы. Многие люди предполагают, что DynamoDB реализует все идеи своего предшественника "Динамо", но, похоже, это не так, и важно держать их в уме. Оригинальная система Dynamo была тщательно описана Amazon в документе Dynamo. Размышляя об этом, также полезно, если вы знакомы с распределенными базами данных, основанными на идеях Динамо, таких как Риак и Кассандра. В частности, Apache Cassandra, которая предоставляет полный спектр компромиссов в отношении CAP.
Сравнивая DynamoDB, который четко распределен по параметрам, доступным в Cassandra, я думаю, что мы можем видеть, где он находится в пространстве CAP. Согласно Amazon, "DynamoDB поддерживает несколько копий каждого элемента для обеспечения долговечности. Когда вы получаете" успешную операцию "на ваш запрос на запись, DynamoDB гарантирует, что запись будет устойчивой на нескольких серверах. Однако для распространения обновления требуется время. ко всем копиям." ( Чтение данных и согласованность соображений). Кроме того, DynamoDB не требует, чтобы приложение выполняло разрешение конфликтов, как это делает Dynamo. Предполагая, что они хотят обеспечить как можно большую доступность, так как говорят, что пишут на несколько серверов, записи в DyanmoDB эквивалентны Cassandra. QUORUM уровень. Кроме того, казалось бы, DynamoDB не поддерживает хинтованную передачу обслуживания, поскольку это может привести к ситуациям, требующим разрешения конфликта. Для максимальной доступности несовместимое чтение должно быть только в эквиваленте Кассандры ONE уровень. Однако, чтобы получить согласованное чтение с учетом записи кворума, потребуется QUORUM прочитанный уровень (после R + W > N для согласованности). Для получения дополнительной информации об уровнях в Cassandra см. О согласованности данных в Cassandra.
Таким образом, я заключаю, что:
- Записи - это "Кворум", поэтому большинство узлов, на которые реплицируется строка, должны быть доступны для успешной записи.
- Несогласованные чтения - это "один", поэтому должен быть доступен только один узел со строкой, но возвращаемые данные могут быть устаревшими
- Согласованные операции чтения являются "кворумом", поэтому большинство узлов, на которые реплицируется строка, должны быть доступны для успешного чтения.
Таким образом, записи имеют такую же доступность, что и согласованное чтение.
Чтобы конкретно ответить на ваш вопрос о двух одновременных условных записях, один или оба не удастся, в зависимости от того, сколько узлов не работает. Тем не менее, никогда не будет противоречий. Доступность записей на самом деле не имеет ничего общего с тем, являются ли они условными или нет, я думаю.