Alexander RyndinReciprocatedПод кластером я подразумеваю KV-хранилку пошарденную на 10 узлов, например.
Допустим, каждый узел у нас:
- является "мастером" для 1/10 части пространства ключей (имеет право их менять)
- является "репликой" для какой-то части ключей (тупо читая журнал каких-то других нод и вылавливая там то, что реплицируем). Ну, какой-то там коэффициент репликации есть.

Интересует возможная физическая реализация транзакции, затрагивающей изменения ключей, мастером для которых являются разные ноды.
Читать исходники не предлагать, предлагать презенташки-видосики или лучше краткое изложение ключевого механизма на 1 абзац своими словами.

Я понимаю, решений зоопарк (где-то даже свалили всё на клиента). Зоопарк и интересует. Онтология распределённого коммита.
Хотя, вроде как в серьёзных местах он сам по себе считается ересью. Но это мои слухи.Насколько я знаю, в шардингах обычно кросс-узловые транзакции не поддерживаются. А частенько не поддерживаются и в рамках одного узла: Cassandra , MongoDB .
Ну там знаете CRUD и бла-бла.
Как вариант всякие распределенные транзакции и двухфазные Commit.

P.S. в этом плане интересны слухи про шардинг в Oracle 12.2 - будет ли там полный ACID?

хмм.. вряд ли они сделают полнофункциональное чудо

АстронавтReciprocated,

В кассандре нет мастер ноды. Все ноды одинаковые.
Dml с клиента приходит на одну из нод. Она будет координатором для этого запроса (отвечает за выполнение дмл). В кластере установлен RF (replication factor) - сколько успешных реплик должно быть, чтобы операция считалась успешно завершенной. Скажем -3. Координатор вычисляет по значению главного ключа номер ноды куда пойдет первая реплика, а по заданной стратегии - номера нод для остальных реплик. Координатор отправляет туда данные и время начала операции и ждет 2 успешных ответа ( > 50%). Если пришло меньше 2 ответов - на клиента отправляется ошибка. Данные не откатываются, потому что ...

Правильно - читатель потом разберется. При чтении задается уровень согласованности реплик.

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

Там еще в бэкграунде бегает процесс который сравнивает времена обновлений колонок и значения от неуспешных операций перезаписывает на успешные.

Могут быть неточности - только разбираюсь с этим чудом.
Курсы с деталями - https://academy.datastax.com/courses/ds201-cassandra-core-concepts

Одно из решений у кассандры, но свсем не двухфазная транзакция