CODEWITHSUNDEEP
transactionsrdbmsnosql
Sahil
Sahil

Reputation: 9486

How do transactions differ in RDBMS and Nosql?

I am trying to understand the difference between NO-SQL and RDBMS model, and everywhere on the web I have read that, RDBMS has better support for transactions then NOSQL. According to one blog I read,

When it comes to data reliability and safe guarantee of performed transactions, SQL databases are still the better bet.

According to this answer on SO

Dropping Atomicity lets you shorten the time tables (sets of data) are locked. Example: MongoDB, CouchDB.

I understand what atomicity means,

Say I have a bank related transaction with one credit operation and one debit operation, either both will succeed or no one will succeed.

How does this particular transaction behave in no-sql world if there are no transactions?

Upvotes: 1

Views: 2544

Answers (4)

Amit Dusane
Amit Dusane

Reputation: 1454

Nowadays NoSQL databases supporting transactions in multiple senses like Single Shared ACID, Multi-Shared ACID, Single-region, Multi-region. There are some open sources and some propriety databases.

For Example -

Azure Cosmos DB - Single Key ACID (Strong Consistency)

Mongo DB - Single Shared ACID

Foundation DB - Multi Shared ACID - Single Region

TiKV - Multi Shared ACID - Single Region

Amazon Dynamo DB - Multi Shared ACID - Single Region

YugaByte DB - Multi Shared ACID - Multi-Region

FAUNA DB - Multi Shared ACID - Multi-Region

As per your requirement, you can choose one of them.

Upvotes: 1

rystsov
rystsov

Reputation: 1928

Usually NoSQL data stores lack the atomic multi key updates and support transaction only on the document level. It means that if you use straightforward approach to transfer money from one account to another you may end up with very unexpected results. Here a couple of scenarios what can happen:

  • Withdraw money, got a error in the process of transfer and lost the information about the transaction and hence the money
  • Withdraw the same money twice from an account in case of concurrent withdraw operation (double-spending)
  • Withdraw and successfully deposit money to the target account but lost them because of the concurrent account update (lost update)

But you can implement ACID transaction on the application level to prevent such scenarios. If a data store supports per key linearizability and compare-and-set (document level atomicity) then it's enough to implement client-side transactions, more over you have several options to choose from:

  1. If you need Serializable isolation level then you can follow the same algorithm which Google use for the Percolator system or Cockroach Labs for CockroachDB. I've blogged about it and create a step-by-step visualization, I hope it will help you to understand the main idea behind the algorithm.

  2. If you expect high contention but it's fine for you to have Read Committed isolation level then please take a look on the RAMP transactions by Peter Bailis.

  3. The third approach is to use compensating transactions also known as the saga pattern. It was described in the late 80s in the Sagas paper but became more actual with the raise of distributed systems. Please see the Applying the Saga Pattern talk for inspiration.

Upvotes: 1

Dennis Anikin
Dennis Anikin

Reputation: 1011

My guess is that when you're saying NoSQL you mean specifically a pure key-value NoSQL database. Which doesn't allow you to atomically change two values for two different keys.

Those databases are still useful in many cases when each of your transactions is changing exactly one value by a specific key.

But in the case of debit one account and credit another one you should use another SQL or NoSQL database that supports "all or nothing" for at least two operations.

So NoSQL means No SQL but not No Transactions.

Upvotes: 1

saljuama
saljuama

Reputation: 2966

First of all, NoSQL is not just one model as many people (wrongly) believe, at this point there are 4 different models: key-value, document, column and graph, and each of them are different from eachother. And there are many vendors for each different model, and each vendor includes a different set of features for the database. There are NoSQL databases that support transactions and ACID properties, and some other NoSQL databases that doesn't.

To answer your question, if you choose a NoSQL database that does support transactions and ACID properties, it is the same as SQL, the database handle it.

But in the other hand, if you choose a database that doesn't support transactions directly, then responsability lies in the application itself. There are some strategies that are commonly accepted to deal with this issue, like a 2-phase commit.

Hope it helps.

Upvotes: 3

Related Questions