Способы реализации «транзакций» с SimpleDB

Question

Я использую SimpleDB AWS, как и предполагалось, по большей части, но также хочу хранить некоторые важные платежные / финансовые данные по нескольким доменам (таблицы). RDS - это, конечно, вариант, но, поскольку у меня уже есть достойный уровень над SimpleDB, если бы его было просто реализовать на этом уровне, я понимаю, почему бы и нет.

Итак, я думаю, требования:

• Блокировка доступа к объектам домена, участвующим в транзакции
• Хранение предыдущих версий объектов для облегчения отката
• Обнаружение доступа к объекту (объектам) с «прерванной» или «сбойной» транзакцией и откат всего задействованного

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

С макушки головы:

• Добавить атрибут current_transaction_guid во все домены
• В каждом домене должен быть домен аудита / истории, в котором хранятся предыдущие версии (с идентификаторами)
• Когда транзакция начинается, пишите в домен «транзакции» с уникальным идентификатором (скажем, GUID), датой / временем начала, is_complete = false
• При записи изменений в объект сохраняйте существующие версии в таблице истории
• Записывать изменения во все домены, обновляя атрибут current_transaction_guid в каждом случае
• (после записи / обновления) обновить объект транзакции is_complete до true
• Обновить все объекты домена current_transaction_guid до нуля
• Перед чтением / записью / внесением чего-либо в транзакцию проверьте current_transaction_guid. Если ноль, продолжайте, но если не ноль, прочитайте статус транзакции. Если is_complete = false, дождитесь истины или истечения времени ожидания транзакции; если is_complete = true, подождите немного, а затем обновите current_transaction_guid до нуля

Тьфу, если подумать, может быть, это не стоит хлопот, и было бы лучше объединить все данные для всех доменов, участвующих в одном домене, даже если это избыточно? Для этого должно быть достаточно последовательного чтения и оптимистичного параллелизма (по номеру версии)?

Answer 1

Я разработал систему транзакций для использования с SimpleDB. Я не уверен, что ваша схема выше будет работать из-за возможной последовательности. Хотя можно использовать согласованное чтение, это повлияет на вашу производительность и сведет на нет преимущества масштабируемости при использовании SimpleDB (возможно, вместо этого лучше использовать кластер серверов RDBMS).

Мой механизм не использует согласованные операции чтения и использует функцию многозначных элементов в SimpleDB для хранения истории транзакций, пар значений. Идентификаторы транзакций и статус хранятся в домене транзакций, который также записывает, какой домен / столбцы влияют на транзакцию.

После прочтения можно определить непротиворечивое значение col, создав дерево, в котором узлами являются значения (текущие и исторические), а соединения - это зависимости версия-> предыдущая_версия, и топологически отсортировав его. Если имеется один хвост (уникальный последний элемент в топологической сортировке), то это непротиворечивое значение для столбца. Значения, принадлежащие незафиксированным значениям, игнорируются в этом процессе. Если нет уникального хвоста, это означает конфликт. Конфликты невозможно избежать в распределенной системе - из-за физики - просто невозможно иметь центральные часы, против которых можно ставить метки времени (или числа версий). Это потребовало бы соединения с задержкой 0 мс между всеми серверами, которые составляют систему (что невозможно - спросите Эйнштейна). При обнаружении конфликтов мы передаем их приложению для разрешения (поскольку это иногда не имеет большого значения и часто может быть разрешено с помощью дополнительной информации из моделей).

Мы также отмечаем время начала транзакции, и любая транзакция в таблице, не помеченная как зафиксированная или прерванная, считается прерванной, если истекло время ожидания. Транзакции и исторические значения могут быть удалены из строк в любой точке, в которой они были уникальным узлом во всех топологических порядках.

Надеюсь, это даст вам (или кому-то) некоторые идеи, если вы решите пойти в этом направлении.