NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



CTO of 10gen, MongoDB creators: We are sort of similar to MySQL or PostgreSQL in terms of how you could use us

Some quotes and comments from ☞ (a quite long) interview with Eliot Horowitz, CTO of 10gen, creators of MongoDB:

I think the first question you have to ask about any database these days is, “What’s the data model?”

The only thing I’d add is: “… and how does that fit my problem?”.

That whole class of problems exists because there’s a very clunky mapping from objects to relational databases. With document databases, that mapping becomes much simpler.

I only partially agree with this. There are some scenarios when mappings seem to be easier with document databases, but for very complex models (read hierarchical, multi-relational) things will remain quite the same — I am saying “quite” because you can still use some short routes, but at the end of the day it will depend also on how you’ll use that data.

I also think […] that the object databases before were actually more closely related to current graph databases than to document databases. The document database is really just taking MySQL, and instead of having a row, you have a document. So I think it’s a much simpler transition and it’s actually much closer to MySQL than a lot of people might think.

I assume that the connection with graph databases is based on the following arguments: the connectivity between objects can be very rich and while all that can be persisted it is not accomplished in a transparent way.

The second part is also worth emphasizing, as it is basically a validation of the schema-less relational database, that FriendFeed and others (see [1] and [2]) are using.

If you look at our road map for this year, there’s no one big feature. I think the only big thing we’re doing right now is getting the auto-sharding to be fully production bulletproof.

I totally agree. That auto-sharding feature has been in alpha for too long.

We are sort of similar to MySQL or PostgreSQL in terms of how you could use us, and people want all the features that they’re used to in MySQL and PostgreSQL. These include things like full-text search, SNMP, and all the assorted add-ons providing special indexing.

Is this the market MongoDB is trying to reach? Is MongoDB trying to become the new MySQL? Definitely interesting.

If there was a feature that would hurt our performance, we would think long and hard about implementing it, and we are definitely more interested in making the basics work than we are in adding more features.

I really appreciate this sort of opinionated approach, even if sometimes you’ll have to tell users a bit more about the tradeoffs.