Транзакции в NoSQL?

StackOverflow https://stackoverflow.com/questions/2212230

  •  18-09-2019
  •  | 
  •  

Вопрос

Я изучаю NoSQL для масштабирования альтернатив базе данных.Что мне делать, если мне нужны вещи на основе транзакций, чувствительные к такого рода вещам?

Это было полезно?

Решение

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

Как правило, те, которые выполняют репликацию master-master, обеспечивают меньшую согласованность и большую доступность.Поэтому нужно выбрать правильный инструмент для решения правильной проблемы.

Многие предлагают транзакции на уровне одного документа (или строки и т. д.).Например, в MongoDB существует атомарность отдельного документа, но документы могут быть довольно обширными, поэтому обычно это работает довольно хорошо – подробнее здесь.

Другие советы

Это самый близкий ответ, который я нашел, который применим к любой базе данных NoSQL.Это запись в блоге Адама Виггинса с Heroku.com в 2007 году:

Старый пример использования транзакции базы данных для перевода денег с одного банковского счета на другой — Total Bull.Правильное решение — хранить список событий реестра (переводов между счетами) и показывать текущий баланс как сумму реестра.Если вы программируете на функциональном языке (или думаете таким образом), это очевидно.

От: http://adam.heroku.com/past/2007/12/17/a_world_without_sql/ (Его веб-сайт отлично подходит для идей по масштабируемости.)

Я интерпретировал приведенный выше абзац как:

  1. Создайте базу данных для учетных записей участников.
  2. Создайте очередь сообщений.Назовите его «леджер».
  3. Добавьте фоновых работников для выполнения каждого запроса в очереди.

Больше информации.по очередям/фоновым работникам: http://adam.heroku.com/past/2009/4/14/building_a_queuebacked_feed_reader_part_1/

Клиент (он же участник или клиент) выполняет следующие шаги, чтобы вывести деньги:

  1. Отправьте заявку на вывод денег.
  2. Запрос отправляется на сервер.
  3. Сервер помещает его в очередь.Сообщение следующее:«Возьмите 5000 долларов».
  4. Клиент показан:«Пожалуйста, подождите, запрос выполняется...»
  5. Клиентские машины опрашивают сервер каждые 2 секунды, спрашивая: «Выполнен ли запрос?»
  6. На сервере фоновые работники выполняют предыдущие запросы от других участников в порядке очереди.В конце концов, они доходят до запроса вашего клиента о снятии денег.
  7. Как только запрос будет выполнен, клиенту будет отправлено сообщение с новым балансом.

Вы можете использовать Heroku.com для быстрого создания небольшого макета, если вам комфортно работать с Node.js или Ruby/Rack.

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

Отказ от ответственности: Я еще не реализовал это каким-либо образом.Я читаю об этих вещах ради любопытства, хотя практической необходимости в них нет.Да, @gbn прав в том, что СУБД с транзакциями, вероятно, будет достаточной для нужд Тимми и меня.Тем не менее, было бы интересно посмотреть, как далеко вы сможете продвинуть базы данных NoSQL с помощью инструментов с открытым исходным кодом и веб-сайта с практическими рекомендациями под названием «Торнадо бритвенных клинков".

NoSQL охватывает разнообразный набор инструментов и услуг, включая хранилища ключей, документов, графиков и широких столбцов.Обычно они пытаются улучшить масштабируемость хранилища данных, обычно путем распределения обработки данных.Транзакции требуют КИСЛОТА свойства того, как БД выполняют пользовательские операции.ACID ограничивает способы улучшения масштабируемости:Большинство инструментов NoSQL ослабляют критерии согласованности операций, чтобы обеспечить отказоустойчивость и доступность для масштабирования, что очень затрудняет реализацию транзакций ACID.

Часто цитируемое теоретическое обоснование распределенных хранилищ данных — это Теорема CAP:согласованность, доступность и устойчивость к разделению не могут быть достигнуты одновременно.Инструменты SQL, NoSQL и NewSQL можно классифицировать в зависимости от того, что они дают;можно найти хорошую фигуру здесь.

Новый, более слабый набор требований, заменяющий ACID, БАЗА («в основном доступно, мягкое состояние, конечная согласованность»).Однако в конечном итоге согласованные инструменты («в конечном итоге все обращения к элементу будут возвращать последнее обновленное значение») вряд ли приемлемы в транзакционных приложениях, таких как банковское дело.Здесь хорошей идеей было бы использовать, например, размещаемые в памяти, столбцово-ориентированные и распределенные базы данных SQL/ACID. ВольтДБ;Я предлагаю посмотреть на эти решения «NewSQL».

Просто хотел прокомментировать советы по денежным операциям в этой теме.Транзакции — это то, что вы действительно хотите использовать при денежных переводах.

Приведенный пример того, как осуществлять переводы, очень красивый и аккуратный.

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

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

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

Проблема с одной транзакцией и двумя операциями (например, одна платит 5000 долларов, вторая получает 5000 долларов) - у вас есть два аккаунта с одинаковым приоритетом.Вы не можете использовать одну учетную запись для подтверждения второй (или в обратном порядке).В этом случае вы можете гарантировать, что только одна учетная запись будет правильной (подтвержденной), вторая (подтверждающая) может оказаться неудачной.Давайте посмотрим, почему это может дать сбой (при использовании сообщения отправитель подтверждается получателем):

  1. Запишите +$5000 на счет получателя
  2. В случае успеха напишите -$5000 на счет отправителя.
  3. Если не получилось - повторите попытку, отмените или покажите сообщение.

Это гарантирует сохранение для #1.Но кто гарантирует, если №2 потерпит неудачу?То же самое и в обратном порядке.

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

  1. Генерация уникального идентификатора транзакции и создание сущности транзакции
  2. Напишите +5000 долларов США на счет получателя (с указанием идентификатора транзакции).
  3. В случае успеха — установите состояние транзакции для отправки.
  4. Запишите -$5000 на счет отправленного аккаунта (со ссылкой на идентификатор транзакции)
  5. В случае успеха - установите состояние транзакции для получения

Эта запись транзакции гарантирует, что для отправки/получения сообщений все в порядке.Теперь вы можете проверять каждое сообщение по идентификатору транзакции, и если оно имеет статус «получено» или «завершено», вы учитываете его для баланса пользователя.

Зависит от вашей БД, но...Я бы сказал, что в целом вы можете использовать «Оптимистичные сделки» чтобы добиться этого, но я полагаю, что нужно обязательно понимать реализацию базы данных атомарность гарантии (напр.какие операции записи и чтения являются атомарными).

Кажется, есть некоторые обсуждения в сети о HBase транзакции, если это поможет.

Вы всегда можете использовать подход NoSQL в базе данных SQL.NoSQL, похоже, обычно использует «хранилища данных ключ/значение»:вы всегда можете реализовать это в предпочитаемой вами СУБД и, следовательно, сохранить такие полезные вещи, как транзакции, свойства ACID, поддержку со стороны вашего дружественного администратора базы данных и т. д., одновременно реализуя преимущества производительности и гибкости NoSQL, например.через таблицу, например

CREATE TABLE MY_KEY_VALUE_DATA
(
    id_content INTEGER PRIMARY KEY,
    b_content  BLOB
);

Бонусом является то, что вы можете добавить сюда дополнительные поля, чтобы связать свой контент с другими, правильно реляционными таблицами, сохраняя при этом объемный контент в основном поле BLOB (или TEXT, если это возможно).

Лично я предпочитаю ТЕКСТОВОЕ представление, чтобы вы не были привязаны к языку работы с данными, например.использование сериализованной Java означает, что вы можете получить доступ к контенту из Perl, скажем, для создания отчетов.TEXT также легче отлаживать, и с ним обычно легче работать разработчику.

взгляните на scalaris, это база данных без SQL с строгой согласованностью и реализованными транзакциями.

Вот почему я создаю решение для хранения документов NoSQL, чтобы иметь возможность использовать «реальные» транзакции в корпоративных приложениях с помощью подхода неструктурированных данных.Взгляни на http://djondb.com и не стесняйтесь добавлять любую функцию, которая, по вашему мнению, может быть полезна.

  • Новое хранилище ключей-значений FoundationDB
  • Старое хранилище ключей-значений Беркли ДБ

наверняка есть и другие

Вы можете реализовать оптимистичные транзакции поверх решения NoSQL, если оно поддерживает сравнение и установку.Я написал пример и некоторые пояснения на GitHub страницу, как это сделать в MongoDB, но вы можете повторить это в любом подходящем решении NoSQL.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top