Transactions in NoSQL?

Question

I\'m looking into NoSQL for scaling alternatives to a database. What do I do if I want transaction-based things that are sensitive to these kind of things?

Answer 1

That's why I'm creating a NoSQL Document store solution to be able to use "real" transactions on Enterprise applications with the power of unstructured data approach. Take a look at http://djondb.com and feel free to add any feature you think could be useful.

Answer 2

Just wanted to comment to money transaction advice on this thread. Transactions are something you really want to use with money transfers.

The example given how do que the transfers is very nice and tidy.

But in real life transferring money may include fees or payments to other accounts. People get bonuses for using certain cards that come from another account or they may get fees taken from their account to another account in same system. The fees or payments can vary by financial transaction and you may need to keep up bookkeeping system that shows credit and debit of each transaction as it comes.

This means you want to update more than one row same time since credit on one account can be debit on one or more accounts. First you lock the rows so nothing can change before update then you make sure data written is consistent with the transaction.

That's why you really want to use transactions. If anything goes wrong writing to one row you can rollback whole bunch of updates without the financial transaction data ending inconsistent.

Answer 3

You can always use a NoSQL approach in a SQL DB. NoSQL seems to generally use "key/value data stores": you can always implement this in your preferred RDBMS and hence keep the good stuff like transactions, ACID properties, support from your friendly DBA, etc, while realising the NoSQL performance and flexibility benefits, e.g. via a table such as

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

Bonus is you can add extra fields here to link your content into other, properly relational tables, while still keeping your bulky content in the main BLOB (or TEXT if apt) field.

Personally I favour a TEXT representation so you're not tied into a language for working with the data, e.g. using serialized Java means you can access the content from Perl for reporting, say. TEXT is also easier to debug and generally work with as a developer.

Answer 4

You can implement optimistic transactions on top of NoSQL solution if it supports compare-and-set. I wrote an example and some explanation on a GitHub page how to do it in MongoDB, but you can repeat it in any suitable NoSQL solution.

Answer 5

The problem with one transaction and two operations (for example one pay $5,000, second receive $5,000) - is that you have two accounts with same priority. You cannot use one account to confirm second (or in reverse order). In this case you can guaranty only one account will be correct (that is confirmed), second (that confirm) may have fails. Lets look why it can fails (using message aproatch, sender is confirmed by receiver):

1. Write +$5,000 to receiver account
2. If success - write -$5,000 to sender account
3. If fails - try againt or cancel or show message

It will guaranty save for #1. But who guaranty if #2 fails? Same for reverse order.

But this is possible to implements to be safe without transactions and with NoSQL. You are always allowed use third entity that will be confirmed from sender and receiver side and guaranty your operation was performed:

1. Generating unique transaction id and creating transaction entity
2. Write +$5,000 to receiver account (with reference to transaction id)
3. If success - set state of transaction to send
4. Write -$5,000 to sedned account account (with reference to transaction id)
5. If success - set state of transaction to receive

This transaction record will guaranty that is was ok for send/receive massages. Now you can check every message by transaction id and if it has state received or completed - you take it in account for user balance.