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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

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

  • Создайте базу данных для учетных записей участников.
  • Создайте очередь сообщений. Прозвище это "книга".
  • Добавить в фоновых работников для выполнения каждого запроса в очереди.

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

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

  • Отправьте запрос на получение денег.
  • Запрос отправляется на сервер.
  • Сервер помещает его в очередь. Это сообщение: "Вывести 5000 долларов".
  • Клиент отображается: "Подождите, пока запрос будет выполнен..."
  • Клиентские машины опросают сервер каждые 2 секунды, спрашивая: "Выполнен ли запрос?"
  • На сервере фоновые работники выполняют предыдущие запросы от других участников в режиме "первый-в-первом". В конце концов, они получают запрос клиента на получение денег.
  • Как только запрос выполнен, клиенту присваивается сообщение с новым балансом.

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

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

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

Ответ 3

Просто хотел прокомментировать советы по сделкам с деньгами в этой теме. Сделки - это то, что вы действительно хотите использовать с денежными переводами.

В примере, приведенном, как делать переводы очень красивыми и аккуратными.

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

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

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

Ответ 4

NoSQL охватывает разнообразный набор инструментов и сервисов, в том числе хранилища ключей, документов, графиков и широкоформатных столбцов. Обычно они пытаются улучшить масштабируемость хранилища данных, как правило, путем распространения обработки данных. Ожидаемые ACID свойства реляционных БД (также определяющие правильные транзакции) ограничивают возможности масштабирования: мы должны выбирать между отказом от масштабируемости, согласованность или отказоустойчивость - и большинство из этих инструментов отказываются от последовательности и, следовательно, ACID.

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

Новый, более слабый набор требований, заменяющий ACID, BASE ( "в основном avalilable, soft state, конечная согласованность" ). Однако в конечном итоге последовательные инструменты ( "в конечном итоге все обращения к элементу будут возвращать последнее обновленное значение" ) вряд ли приемлемы для транзакционных приложений, таких как банковское дело. Здесь неплохо было бы использовать базы данных, основанные на столбцах и распределенные базы данных SQL/ACID, например VoltDB; Я предлагаю взглянуть на эти решения "NewSQL".

Ответ 5

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

  • Записать + 5000 долларов на счет получателя
  • Если успех - напишите - $5000 на счет отправителя
  • Если сбой - попробуйте еще раз или отмените или покажите сообщение

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

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

  • Создание уникального идентификатора транзакции и создание объекта транзакции
  • Записать + $5000 на счет получателя (со ссылкой на идентификатор транзакции)
  • Если успех - установить состояние транзакции для отправки
  • Write - $5000 для учетной записи с автономной учетной записью (со ссылкой на идентификатор транзакции)
  • Если успех - установить состояние транзакции для получения

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

Посмотрите на скалярные данные: нет sql db с сильной согласованностью и реализованными транзакциями.

Ответ 9

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

Ответ 10

  • Новое хранилище ключей FoundationDB
  • Старый хранилище ключей Berkley DB

Конечно, есть другие

Ответ 11

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