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

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

Кажется, ведутся дискуссии в сети о транзакциях 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 также легче отлаживать, и с ним обычно можно работать как разработчик.

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

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

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