Lets say I have $10 in my bank account. The database is replicated in North America and Asia. At the exact same time I do a withdrawl of $10 in N. America and in Asia, meaning that my withdraw would do work on two different copies of the data. How can I be prevented from ending up with a balance of -$10 and $20 in my pocket?
Is it possible to produce the proper result with NoSQL?
(I'm not a database expert, just curious)
Thanks!
Take a look at the views of Micheal Stonebraker here - pages 21 and 22. Stonebraker is both an academic and a serious commercial player in the database world (Postgres, Vertica, Informix, VoltDB inter alia). For your particular question, note his views on banking.
Stonebraker is an advocate of "NewSQL".
NewSQL is a two-pronged approach which addresses both fundamental facets of database processing: OLTP and OLAP.
For OLTP (banking, shopping) he proposes in memory, sharded, shared nothing architectures with none of the transactional/buffering overhead of "OldSQL" (that's Oracle, SQL Server, MySQL... &c. to you and me). His offering in this area is VoltDB. Oracle and Microsoft are playing catch-up (with In-Memory and Hekaton)
For OLAP (DW) applications he is a fan of column oriented stores - i.e. Vertica (a commerical success he sold to HP).
He says two main things:
He makes the excellent point that back in the 1970's, there was a debate in the CS/IT world about C versus assembler. Some thought that hand-crafted assembler (think Map-Reduce programmes) would be more efficient than a C compiler's output (think database query optimiser).
As you may have guessed, I'm a big Stonebraker fan.
In a distributed system, you can't be prevented from simultaneous withdrawals. If you want to prevent simultaneous transactions then don't use a distributed system.
By "distributed system", I mean a system where two or more different components can act without waiting for confirmation from the rest of the system. Two-phase commit is not distributed, because while it might involve physically different systems communicating by passing messages, a transaction still has to wait for confirmation from all members.
I think the correct term for what I mean is "loosely coupled", but DbQuestioner88 used the term "distributed system" in the question, so I used it in the answer.
There used to be a bank in New Zealand whose ATMs would operate when disconnected. If the ATM could not contact the central computer system, it would still allow a withdrawal of up to $40. When it did connect later on, the central system would gather together all of these changes. If the withdrawals meant you were now in overdraft then you were in overdraft, and probably paying some interest.
The bank did this so that you could still get some cash out for things like groceries, taxis home, and small emergencies, even if the computer network was down (which it wasn't often, even in the 80s).
Each ATM would only do this once per account, so if you wanted to abuse it then you had to quickly travel between lots of ATMs, which wasn't cost effective. A few people still abused it but the bank treated this as a cost of providing this extra service. In any case, you still had to pay the overdraft back.
