What is the link between MongoDB and them getting hacked?
http://www.reddit.com/r/Bitcoin/comments/1wtbiu/how_i_stole_...
Why is MongoDB bad? It's not ACID compliant. It's hard to determine the state of the database with concurrent processes attempting to modify its data. Given the explanation it's fairly clear that it's Coinbase being talked about.
(Also, MongoDB is like the worst NoSQL data store out there for a task like this.)
It makes sense to use mongodb for commenting system where nobody cares if you lose a comment or certain comments are written before others.
But no competent architect would use mongodb for financial/currency transactions.
If coinbase did use mongodb, it will be inevitable they will have transactional issues. The more popular coinbase gets, the more transactions they process, the more issues they'll have. I don't envy the poor souls that have to track down these kinds of issues...
If you do want to experiment with NoSQL databases, MongoDB is probably the easiest to get going with (which is why it is so widely used). However, you seem statistically unlikely to be in the group that is happy with MongoDB in production :-)
HBase has a much brighter future for the NoSQL use cases (and is even getting SQL support!)
Having said all of that on my personal site I actually use RethinkDB because it is delightfully easy to setup and code against (I just persist my Go structs to the db and don't worry about a relational schema to maintain) and I don't really care about data integrity there, so I don't mind that RethinkDB is relatively new and untested. So one size doesn't fit all, but PostgreSQL is still, IMO, generally the "safest bet" if you do care about data integrity and don't want to spend hundreds of thousands of dollars on licensing to scale it up.
It's not particularly likely to eat your data or kill you as you get started, and the ecosystem is relatively unified which means consistent and generally good best practices documentation. Becoming a Postgres expert could take a lifetime as the database offers an astonishing depth of features, but it won't bite you if you just use the basics. Plus the source is quite good if you ever find the urge to dig deep.
A couple of gotchas might bother you. You'll need to implement your own strategy for upserts if you need those. But you do get robust native support for popular data types commonly seen in today's apps: geographic data as well as document data (via HStore or JSON).
The MySQL/MariaDB family is well-proven as well, but with tens of available storage engines, two core forks, and a bit of non-standard SQL magic sprinkled throughout it's harder for a beginner to learn the best practices IMO.
The challenge comes once you exceed what one machine can do and want to move beyond the simple client(s) <-> (possibly replicated) server model. Keep in mind that depending on your project, this might not ever happen to you. Certain types of mid-sized sites like Basecamp and Stack Exchange have gotten away with throwing bigger hardware at their database systems.
If or when you reach the point where you need a distributed database, you have to choose between consistency and availability. I'll let the experts explain some of those concepts by linking to this excellent article by Coda Hale: http://codahale.com/you-cant-sacrifice-partition-tolerance/ . That's when you'll find yourself in the NoSQL world - many NoSQL databases are useful in that they try to trade consistent for available in some way or another. While they generally fail completely to actually do so, as illustrated in Kyle Kingsbury's excellent "Call Me Maybe" series, the largest -scale systems are all based on a "NoSQL" data store in some way or another.
Else you're better off with NoSQL (I found CouchDB amazingly easy).
From the point of view of NoSQL data stores, it'll really depend on your application needs, and I can't give you a full overview, buuuut.... Amazon did a solid job with its DynamoDB database, and Apache Cassandra did a solid job cloning it. I believe I've also heard decent things about the sanity level of Redis and Hypderdex.
It is loosely based on the Dynamo paper like most modern distributed databases, but Dynamo and DynamoDB are very different things.
Riak could be another interesting option in that space. Redis is more adapted for small datasets with high workloads and low durability expectations (i.e. do not host a Bitcoin exchange purely on it unless you really know what you are doing :p).
If you are even thinking about following any of the advice on that page, you are no longer in the MongoDB use case: you plainly need transactions.
Tokutek engineers are top notch.
The problem here is that developers not taking the time to understand their application and how their tools work. Yes, MongoDB gives you enough rope to hang yourself and I certainly wouldn't suggest using it for a financial ledger, but you could have a durable application based on it if you really wanted to.
However if developers of a financial system cant grasp the need for atomicity in the transaction path then they're going to be buggering things up all over the place.
In particular, dijit asserted that "Not ACID => Not secure" (which is debatable, but that doesn't matter here) from which you can also validly deduce the contrapositive "Secure => ACID". However, you then (sarcastically) asserted that dijit is saying "ACID => Secure", whereas in fact he said nothing like that.
That being said, I don't think a schemaless database is really appropriate for carefully considered (or what should be carefully considered) financial data.
I dislike MongoDB, but if I had to try to summarize objectively:
1) It is marketed very heavily, including to use cases to which it is poorly suited
2) It can be very complicated to run in production, I think because it actually wasn't originally designed to be distributed.
3) It has a history of data loss. I think this is because it generally favors performance over reliability, combined with #1 and #2
What about other NoSQL solutions?
MOST other NoSQL solutions actually do things like treat their index differently than their bulk data so that it isn't accidentally swapped out, ruining performance. Many also do important things like supplying durable writes. (Your data may not be consistent at any one given moment, but it'll get there.)
I have run it in production, thrown over the fence by some dumb devs who believed the lies that "you don't need a DBA". Well you need a full time team and a lot of hardware, and that's comparing it to Oracle.