Coming soon: day-long MongoDB training sessions in SF and NYC
blog.mongodb.org
blog.mongodb.org
Keys in the document values are stored in the document. Big keys = more space required.
No async client drivers (still true? The last time I surveyed was in November)
"It doesn't support rollback or anything like that, so you'd have to do that yourself."
Smaller problems or non-problems:
It is not durable (writes every N seconds). Granted, most "NOSQL" experiments are not strictly durable (e.g. Redis, Tokyo Cabinet, etc.)
4MB limit / document (I don't have values this large anyway)
32-bit host limits MongoDB DBs to 2GB total size (so use 64-bit)
Auto-sharding is in alpha, and I'm glad to see it coming. But, things like this scare me: "If a shard is down, the query will return an error." Compare that feature to something like Riak wherein multiple copies of values are stored (Riak's W, DW parameters). MongoDB with auto-sharding does not seem fault tolerant. Am I missing something on this?
Please let me know your thoughts as I do like MongoDB for its speed and query operators but the above concerns me.
Key storage in the document objects make it more 'schemaless' which is actually incredibly useful; the document format (BSON) is efficient. In practice that works just fine. Try it out sometime on a test project?
Do you think that MongoDB would perform well on a shared environment like a Linode VPS? Does MongoDB have any sort of resource gotchas like "oh, you need at least 512MB RAM for the thing to even start up" or the like?