Is a great decision to make use of NoSQL database for any banking system instead of RDBMS?

If so, Do you know the suggested NoSQL databases for any banking system?

Getting labored within the banking industry, I'd be careful applying not well-examined, "legacy" RDBMS systems or mainframes for core banking reasons (Accounts, SOR, GL, etc). For peripheral systems, like marketing, analytical databases etc, NoSQL is okay, but you need to be more specific regarding your use situation to obtain any kind of a great response to this.

Every tool has the simple truth is use situation. Banking is very risk averse and conservative.

Nathan Hurst has an excellent blog posting around the idea behind NoSQL databases. I'll do my better to paraphrase:

A database is usually selected based-on qualities of Consistency, Availability and Partition Tolerance (CAP Theorem). Obviously, the CAP Theorem states that the database can reasonably only concentrate on a couple of these. NoSQL databases need partition ability to tolerate scale correctly, so that they finish-up compromising either availability or consistency. RDBMSs negotiate this issue by selecting consistency and availability, and utilize other means to have their data partition tolerant (ex: replication).

You are able to typically begin to see the results of this in the transaction-level. In RDBMS-land all transactions ought to be Acidity (Atomic, Consistent, Isolated and sturdy). NoSQL databases typically don't have strict Acidity needs. In by doing this, data that's up-to-date using a transaction might be atomic (transaction is either implemented to all update locations or folded-back), might not be durable when the energy fails, and could run underneath the assumption of "eventual consistency."

Therefore "no", a NoSQL database is certainly not advisable for any banking solution.

It's also wise to observe that "NoSQL" database architectures differ considerably by brand. What I have stated this is a generalization about NoSQL databases. That is certainly not every-encomapssing.

Before responding to this I must give a good example: GT.M is really a NoSQL Database that offer extreme transaction. which is often used within the world's biggest core banking system, FIS Core Banking system (rated #1 by inntron)

So theoretically it's achievable to make use of NoSQL for core banking systems so long as your NoSQL engine supports transactions.

Source: http://www.slideshare.net/fachrybafadal/nosql-technology