MongoDB's MongoUK conference
20 June 2010
MongoUK—a small MongoDB conference in London—happened last Friday, and it was wonderful. I haven’t been to that many conferences, but it probably the best tech conference I’ve been to, at least in terms of my enjoyment of the talks themselves. (DPC is over three days, in Amsterdam…)
The conference was run by 10gen (the company behind MongoDB) themselves, though it felt about as much like an independent conference as it was possible to be under the circumstances. (I’m pretty the conference was subsidised—10gen are just getting started, and so at this point they want to get as many people as possible happily using MongoDB as possible, and they have the VC money to do it.)
A few points that struck me about MongoDB:
- Unlike most NoSQL databases, MongoDB supports SQL-like indexes, though it will only use one index per query. Curiously, if multiple indices could potentially be used to resolve a particular query, the server picks the index to be used via a heuristic that includes some information about how useful the index on previous queries.
- Sharding is complicated. Maybe even very complicated. Since production deployments are recommended to have two slaves per master, a deployment with sharding involves at least 6 servers for the data itself, plus several configuration servers, plus several servers to act as front-ends to the shards (to conceal the existence of the shards from clients). These servers more or less need to be manually configured—the cluster doesn’t organise itself. Perhaps some of these can be virtual machines (?), but a production setup with sharding involves many physical machines.
- With map/reduce over shards, the maps are done separately within each shard, but the reduce is done on one server. This also means that the resulting collection is itself not sharded.
- Most contributions to the MongoDB server itself come from 10gen itself—they haven’t had many outside contributions.
- No-one asked about the AGPL license!
Overall, my feelings toward MongoDB didn’t change that much. It’s a new product, to be used with a modicum of caution, and it shouldn’t be the automatic first choice. (Though perhaps there is no automatic first choice when it comes to NoSQL document-oriented databases.) It is used in production (many of the attendees I spoke to were using it in production), though I think many of the very large and complicated deployments are done with a small amount of hand-holding from 10gen. I was reassured by the quality of the MongoDB people, and their commitment to their product and its users. 10gen and MongoDB are extremely developer-friendly in all respects—the product itself, the documentation, their people, their “marketing” (there was no hard sell), etc.