I think it is time for the major forums software providers to really give a hard look at MongoDB and other NoSQL soluations. I'm looking at you Vbulletin and phpBB.
We use MySQL extensively on our platform and much of our data is relatively key=>value type stuff. So it makes since for us.
I don't mind migrating our primary business operations to MongoDB (we already have moved some data as a POC), but it would be nice to have our forums supported so when we ultimately create our future MongoDB cluster, I'm not having to manage a MySQL instance for VBforums.
I'm not sure what you mean. Would "stable candidate" work better? The 1.8x distribution is still clearly marked as "latest stable", and the 2.0 stuff is marked "development". RCs in open source - at least as long as I can remember - have been publicly released with a "this isn't officially considered stable" disclaimer.
Especially for smaller projects with a lot of data, it's a little bit annoying that you can't really limit the amount of RAM MongoDB will take.
Using e.g. Mongo and Elasticsearch on the same machine would be a little bit problematic as sooner or later, MongoDB would just take over most of the RAM.
You can't limit the amount of RAM, but the RAM metrics are somewhat deceptive; it uses memory-mapped files, so your virt usage is going to basically be the size of your whole dataset. Your resident usage is going to consume up to as much RAM as isn't being used by other processes on the machine; the kernel's VMM should manage how much resident memory is actually used.
In practice, you generally want your DB server(s) on their own machines if RAM is ever possibly going to be a concern. Any database that constantly has to hit the disk isn't going to perform worth a hill of beans.
New command for collection-level compaction,
Better concurrency,
Index Enhancements,
Authentication with sharded clusters,
Replica set priorities (set preference for which server should be primary),
Data-center awareness,
Polygon searches,
..a few other things...it's all in the release notes.
I can tell you I'm excited about the new indexes...this weekend I'm going to restore our production database into a local 2.0 instance and see what type of memory savings, if any, we get (since I'm cheap and ram is my biggest issue) (it won't be as easy for me to measure the possible improvement in performance mentioned).
"Indexes are often 25% smaller and 25% faster (depends on the use case)"
Huge performance increases, actually. The write lock yielding whenever the DB is hitting the disk is huge and is going to resolve a large number of my production complaints with it. The improved indexes are also quite tantalizing.
Change Log: https://jira.mongodb.org/browse/SERVER/fixforversion/10596
I'm excited personally because they accepted my super rough patch for polygon geo-spatial search queries. They fixed up the code a lot, but it's still my baby. http://www.mongodb.org/display/DOCS/2.0+Release+Notes#2.0Rel...