Транзакции в NoSQL? - PullRequest
       81

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

67 голосов
/ 06 февраля 2010

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

Ответы [ 11 ]

36 голосов
/ 06 февраля 2010

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

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

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

17 голосов
/ 15 августа 2010

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

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

От: 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 с помощью инструментов с открытым исходным кодом и веб-сайта с практическими рекомендациями под названием « Торнадо бритвенных лезвий ».

16 голосов
/ 23 августа 2012

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

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

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

13 голосов
/ 08 ноября 2011

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

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

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

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

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

6 голосов
/ 23 апреля 2012

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

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

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

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

  1. Генерация уникального идентификатора транзакции и создание объекта транзакции
  2. Запись + $ 5000 на счет получателя (со ссылкой на идентификатор транзакции)
  3. В случае успеха - установить состояние транзакции для отправки
  4. Запись - $ 5000 на счет заблокированного аккаунта (со ссылкой на идентификатор транзакции)
  5. В случае успеха - установить состояние транзакции для получения

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

2 голосов
/ 06 февраля 2010

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

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

1 голос
/ 16 января 2013
  • Новое хранилище значений ключей FoundationDB
  • Старое хранилище ключей Berkley DB

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

1 голос
/ 07 июля 2012

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

1 голос
/ 05 июня 2012

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

1 голос
/ 23 февраля 2010

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

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

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

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

...