MongoDB 2.0.0-rc0 Released(mongodb.org)
mongodb.org
MongoDB 2.0.0-rc0 Released
http://www.mongodb.org/display/DOCS/2.0+Release+Notes
24 comments
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.
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.
If you're mostly K=>V and you want distributed, why not look into Riak? It's really easy to administer and has very nice operational characteristics.
I got tired of waiting, and am working on a replacement to vBulletin that has a rich API and uses sensible modern data stores.
Beyond just 'mongo please', are there features you're looking for?
Beyond just 'mongo please', are there features you're looking for?
Unfortunate to see it still has the global lock pair and lack of online compaction.
I had the chance to chat to a 10gen guy who said that they would gradually whittle away the global write lock over 2.2, 2.4 and I think 2.6.
It's still web scale tho'.
Does anyone else find it amusing that it seems to have become the norm nowadays that "Release Candidates" are "Released"?
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.
I'm not 100% sure, can somebody confirm this:
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.
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.
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.
The same strategy is used by Varnish.
Excellent updates. However disappointed that the improvements to aggregation previously mentioned for 2.0 did not seem to make the cut.
What's new and cool in 2.0 in general?
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.
Yeah, but are there any performance improvements? I'll be waiting to see the blog posts about it that are undoubtedly forthcoming.
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)"
"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.
All the more reason to consider using MongoDB in your next project if you haven't already.
No improvement on the map-reduce. Cool to have a Replica set priorities though.
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...