Actually in C++11 you can just say:

    auto id = mongo::OID("1234...");

This gives you much (not all) of the brevity and flexibility of dynamic typing, while maintaining the power and safety of static typing.

Actually, as of 2.4 there is an experimental text search feature built-in: http://docs.mongodb.org/manual/core/text-search/. While it is no Lucene (and is still considered experimental) it does provide simple tokenizing, stop-words and stemming.

One case that could break by this change is if you relied on insert's old default of being a no-op if an object with the same _id already exists. This can be used to efficiently insert a default document without race conditions. Example at https://github.com/RedBeard0531/Mongurl/blob/master/mongurl....

That said, it makes sense for this to be opt-in behavior rather than the default.

Out of curiosity, did you have an index on the ts field that you are matching with?

By the way, if you (or anyone else for that matter) come up with useful benchmarks I'd love to get a copy of them at mathias@10gen.com. I have a few of my own, but I'd like to get some real-world workloads from the community to test potential optimizations against.

Yes, I had a single index:

  db.events.ensureIndex({ ts: 1 });

I'll try to clean up my benchmark code a little, throw it in a gist, and then I'll send it your way.

Update: already forwarded this to Mathias, but posting here in case anyone else wanted to see the full benchmark test: https://gist.github.com/3518344

There is an official tutorial on http://mongodb.org, just click "Try It Out" in the top banner. Karl Seguin also wrote two great tutorials (one on basics, one on geo queries) at http://tutorial.mongly.com/.

Locking in particular has improved substantially since 1.6. For example, 2.0 introduced yielding in some cases where MongoDB would go to disk rather than page-faulting with the lock held[1]. This has been extended and improved for 2.2, along with increasing the granularity of the lock from process-wide to per-db. There are plans to increase the granularity further in future releases.

[1] To see an example of the difference this makes see http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html

Thanks for bringing this to our attention. It has just been fixed in master.

Take a look at the $push and $addToSet[1] update operators in mongodb. They are both for atomically adding one or more elements to an array in an object. On the other hand, MongoDB doesn't support server-side set union or intersection so if you are using those features redis would still probably be a good use there.

[1] http://www.mongodb.org/display/DOCS/Updating#Updating-%24add...

I don't know exactly what your GIS needs are, but it might be worth seeing if MongoDB's geospatial indexing meets them if you are interested in querying free-form data.

http://www.mongodb.org/display/DOCS/Geospatial+Indexing http://www.mongodb.org/display/DOCS/Geospatial+Haystack+Inde...

We try to keep documentation on EC2 best practices here: http://www.mongodb.org/display/DOCS/Amazon+EC2

I am aware of that page and it is a great starting point but is not enough. Please take a look a this document from IBM http://public.dhe.ibm.com/software/dw/data/bestpractices/DB2...

I was hoping for something along these lines .