MongoDB's New Query Matcher

I wish the 10gen folks would do some work on various issues that have been in MongoDB for a long time. For me the most serious one is data size. Storage is pretty terrible, especially compared to CPU these days. I would far prefer the use of more CPU in order to reduce storage.<p>Records in a collection mostly use the same set of keys. Every record includes the full key which makes the storage that much larger. Strings can interned and replaced with a far smaller numerical token to reduce storage. (I'd be happy for it to be attempted for string values as well.)<p>The other is compression which is a straight forward cpu versus storage tradeoff.<p><a href="https://jira.mongodb.org/browse/SERVER-863" rel="nofollow">https://jira.mongodb.org/browse/SERVER-863</a><p><a href="https://jira.mongodb.org/browse/SERVER-164" rel="nofollow">https://jira.mongodb.org/browse/SERVER-164</a>

As a large commercial user of MongoDB (almost 300 instances of it running in production), I've seen some big shifts in 10gen's focus lately. They've really ramped up the customer service, and they are making more regular releases that seem like improvements.<p>Unfortunately, the better customer service doesn't provide better answers or solutions to problems, and the improvements aren't targeting long standing, basic issues with the platform.<p>This feature announcement fits the pattern: an improvement, but not in a critical area like indexing, or document-level locking, sharding stability, etc. There are basic fundamentals that need addressing like overcoming the 20K maximum connections per server, or mongos CPU usage. These are the things I deal with in production and that are business critical, but those feature requests sit untouched in JIRA for months or years.<p>This feature seems interesting, but it solves a problem I don't have. I'd prefer them to solve real world problems.

My name might be "Mud" a a previous client because I recommended MongoDB and implemented a first-rev persistence interface based on my presumption that this issue would be fixed in the near-term:<p><a href="https://jira.mongodb.org/browse/SERVER-3253" rel="nofollow">https://jira.mongodb.org/browse/SERVER-3253</a><p>To be fair, I educated the client on the alternatives should 10Gen not improve the aggregation framework so that it could do arbitrary transforms without failure should the output size exceed 16MB. [Use other MongoDB mechanisms, custom compilation with higher per-document size cap, etc.] What annoys me is that 10Gen did not mention this incredibly important limitation when they were touting the planned features of 2.2. My client would not have minded had it simply been the case that queries with large result set sizes were somewhat slow. What this client could not tolerate were failures to deliver any results at all. In retrospect, I wish that I had pushed harder for a solution based on the Hadoop stack. While it seems to have its own demons, at least there is an ecosystem dedicated to fixing the most blatant of limitations.

Do I regret choosing MongoDB a couple years ago to augment Postgres for several data analysis applications? Not really. But I do wish Mongo has been more mature. I'm happy to see each step forward taken, but it does bother me that often serious issues get overlooked for press-friendly feature additions. Until Mongo adopts some form of compression I won't be using for new projects aside from personal ones where development ease trumps everything else.

I use MonogoDB. I hope they will be able to manage the technical debt and stay competitive with newer alternatives. Seems like this is a step forward.