Simultaneous money withdrawls from a distributed/replicated database

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:

• that ACID is essential for a database system (see the .pdf), and

• that there's nothing wrong with SQL - high level langauages are good and that NoSQL is basically really a great leap 30 years backwards.

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.

StackExchange Database Administrators Q#69822, answer score: 4