Есть много (большинство?) Сценариев, в которых ACID не нужен.Например, если у вас есть база данных продуктов, в которой одна таблица - id -> description, а другая - id -> todays_price, а еще одна - id -> sales_this_week, то нет необходимости блокировать все таблицы при обновлении чего-либо.Даже если (по какой-то причине) в трех таблицах есть общие биты данных, в зависимости от использования, их несинхронизация в течение нескольких секунд не может быть проблемой.Возможно, ежемесячные продажи нужны только в конце месяца при агрегировании отчета.Не быть ACID-совместимым означает необязательно удовлетворять всем четырем свойствам ACID ... в большинстве бизнес-случаев, если все в конечном итоге согласуется друг с другом, это может быть достаточно хорошим.
Стоит отметить, что коммиты, затрагивающие тот же раздел Кассандры, являются атомарными.Если что-то должно быть атомарно непротиворечивым, то ваша модель данных должна стремиться поместить этот бит информации в один и тот же раздел (и, как таковой, в одну и ту же таблицу).Когда мы говорим о возможной согласованности в контексте cassandra, мы имеем в виду вещи, влияющие на разные разделы (которые могут быть разными строками в одной таблице), а не на один и тот же раздел.
Каноническим примером "транзакции" является дебет с одного счета и кредит с другого .... это "важно", потому что "банки".На самом деле, это не так, как работают банки.Такая система нуждается в определенном списке транзакций (читай переводов).Если бы вы смоделировали это для Кассандры, вы могли бы иметь таблицу переводов, состоящую из (from_account, to_account, сумма, время и т. Д.).Эти записи будут атомарно согласованы.Ваши таблицы "счетов" будут обновлены из этого списка переводов.Как скоро это отразится, зависит от бизнеса.Например, в Великобритании переводы из банка Lloyds в банк Lloyds происходят практически мгновенно.В то время как некоторые межбанковские переводы могут занять пару дней.В последнем случае на балансе вашего счета обычно отображается не вычтенная сумма ожидающих переводов, тогда как отдельный «доступный остаток» учитывает ожидающие переводы.
Различные вещи работают с разными задержками, а в некоторых случаях ACID, и результирующая немедленная согласованность всех обновленных записей может быть важной.Для многих других, тем не менее, особенно при работе с распределенными системами с большим количеством данных, ACID на уровне базы данных может не потребоваться.
Даже там, где требуется «видимая согласованность», ее часто можно обрабатывать согласованно.механизмы на уровне приложений, CRDT и т. д. Для конечного пользователя система является атомарной - либо что-то происходит успешно, либо нет, и пользователь получает подтверждение.Внутренне, система может обновлять несколько баз данных, иметь дело с внешними сервисами и т. Д., И подтверждать только тогда, когда все хорошо.Таким образом, ACID для разных строк в таблице, или для таблиц в одной базе данных, или даже для нескольких баз данных может быть недостаточным для внешне видимой согласованности.Cassandra обладает настраиваемой согласованностью, при которой вы можете использовать моделирование данных и иметь дело с компромиссами, чтобы создать «достаточно хорошую» систему, отвечающую требованиям бизнеса.Однако, если вам нужна транзакция ACID для разных таблиц - Cassandra не подойдет для этого варианта использования.Однако вы можете смоделировать свои бизнес-требования в рамках ограничений cassandra и использовать его для получения других преимуществ масштабируемости, которые он предоставляет.