3 ms·
I can't see using MongoDB for any production project. It combines a limited replication/sharding model with a poor single-server durability, lack of tunable CAP
by aphyr 16y ago
I can't see using MongoDB for any production project. It combines a limited replication/sharding model with a poor single-server durability, lack of tunable CAP constraints, and some surprising performance bottlenecks.
If you want integrity and SQL, use PostGres. If you want volatile speed, use Redis or Membase. If you want a rich data model and excellent durability with limited but highly configurable replication, experiment with Couch. If you want federation, predictable horizontal scaling, and HA, perhaps look at Voldemort, Cassandra, HBase, or Riak. There are a lot of good datastores out there, and chances are one of them fits your needs better.
Edit: I think http://www.paperplanes.de/2011/1/10/mongodb_and_data_durability.html http://www.paperplanes.de/2011/1/10/mongodb_and_data_durabil... basically sums it up. When the Mongo folks started telling me that kill -9 should never happen to any database, I stopped taking them seriously.
- wesleyzhao 16y agoI have just been reading that MongoDB is much more scalable and faster and I looked into it and saw that its queries were very similar to SQL. There are a lot of DB choices out there, and just trying to find one that I should either stick to or learn based of trends, benefits, and level of user-support out on the web.
- aphyr 16y agoits queries were very similar to SQL You may want to learn more SQL. If you're interested in picking up a more complex document database, I would recommend Couch. For a simple k/v store that will get you thinking about concurrency, perhaps Riak.