Why MongoDB Never Worked Out at Etsy
mcfunley.com
mcfunley.com
"Before you get too excited, the reason for the failure is probably not any of the ones you're imagining. Mainly it's this: adding another kind of production database was a huge waste of time."
The blog title is misleading IMO. It could as well be titled "Why [any other DBMS] Never Worked Out at Etsy" and the conclusion would be the same.
His point was "in our specific scenario the benefits of using MongoDB were outweighed by the difficulties in having to manage two DBMS in parallel [at a time when MongoDB hadn't been around for long and we had to set up everything ourselves]."
If you've got data sitting in one place and then data sitting in another, it's generally a massive fucking pain in the ass.
Speaking from my experience anyway. Bonus points if one of them was written by a company in the early 2000s who didn't trust those newfangled RDBMSes to get it right. Extra bonus points if they thought UTF-8 was for sissies.
We primarily use MySQL and CouchDB (BigCouch). Our user records (accounts and payment) are stored the RDBMS, while the data the users created is in BigCouch. We enjoy the schemaless nature, durability and scalability of BigCouch a lot.
Depending on your definition of "database system", we also have a hefty Solr index (for search), some Redis (no persistence only to connect systems/services via pubsub) and Memcache (cache).
I'm not even saying if the article was interesting or not. It surely has it's merits, it touches a point worth discussing (the downsides of trying to cover one DBMS's weakness throwing in another DBMS in the mix), but I was uninterested. I was expecting to hear why MongoDB wasn't fit for his use case, to better understand when to use NoSQL and when not to, so yes, I was indeed biased waiting for something different—but, in my defense, I say I was biased because the title made me think this way.
I've heard of or directly witnessed enough situations where somebody with influence, but maybe not much actual technical experience, pushes for the use of a NoSQL database of some sort. Yes, the project is implemented and often does end up in production for at least some amount of time. But it doesn't survive long. Problems arise, and the system is either discarded, or moved to a more traditional relational database system. That's why I'm curious about that list, and how many of the entires are still valid, as we approach the beginning of 2013.
And there's s growing list of stories at 10gen.com/presentations
Some good ones to point out: Analytica: http://www.10gen.com/presentations/mongosv-2012/exploring-pu...
Apollo Group (The University of Phoenix) http://www.10gen.com/presentations/mongosv-2012/how-we-evalu...
AOL : http://www.10gen.com/presentations/managing-large-scale-data...
Github: http://www.10gen.com/presentations/mongosv-2012/mongodb-anal...
Banjo: http://www.10gen.com/presentations/real-time-location-based-...
Telefonica: http://www.10gen.com/presentations/mongodb-uk-2012/MongoDB-o...
MapMyFitness: http://www.10gen.com/presentations/mongodb-seattle-2012-mong...
Sailthru: http://www.10gen.com/presentations/mongodb-seattle-2012-sail...
Stripe: http://www.10gen.com/presentations/high-availability-mongodb...
eBay: http://www.10gen.com/presentations/mongodb-ebay
These are all large deployments. It's a mix of small startups, startups that grew up and large engineering companies (like eBay and Apollo group).
Its weird at first, coming from a background of Access then SQLite then MySQL/PHPMyAdmin but you get used to it. I essentially treat it like a gigantic python dictionary object.
The sharding is too much of a ball-ache to set up so I've created an optimal way of distributing/mapping files across our cluster to make use of all machines.
Data integration is nice. Making sure there's no temptation to output each integrated line to the terminal, pymongo and its C extensions can integrate a ~500 byte record in ~0.0001 seconds.
Basically the main advantage is not having a schema whatsoever - you can just add random attributes to documents whenever the hell you want. But later you have to be careful with exception handling since documents might not have the attributes you expect.
So right off the bat, you've lost the querying power that SQL offers. When dealing with data that's intended to be analyzed, that sounds like a pretty big loss.
Clearly its built-in sharding support, which is often touted as one of its biggest benefits, wasn't suitable for you. So you had to invest some time and effort coming up with an alternate system. That sounds like a loss to me.
When it comes to the schema issue, it sounds like you haven't actually reduced the effort or work in any way, but merely pushed it somewhere else. Like you admit, you still do have to deal with the schema, it's just handled within the application logic, rather than the database. That sounds worse to me, especially if there is more than one application using the database.
I'm just not seeing the benefit.
Can you point me to any reasonably-priced database systems that allow me to execute SQL queries against a cluster of shared-nothing machines running commodity hardware? I'm not interested in paying $20-100K/TB/year for Vertica and friends.
SQL can be great if you have vast amounts of money or if your data can fit onto a single machine. When neither of those things are true though, nosql DBs become important.
If it has to have built-in sharding then I can't think of anything off-hand.
Auto sharding, shared nothing, SQL support, it does a pretty good job of things.
MongoDB Counters: http://railstips.org/blog/archives/2011/06/28/counters-every... http://railstips.org/blog/archives/2011/07/31/counters-every...
Kestrel: http://railstips.org/blog/archives/2012/03/05/misleading-tit...
Gets some decent traffic and works well.
My other site, http://www.BudgetSimple.com on the other hand is using SQL Server (in the process of porting to MySQL). It would not be a great use-case for Mongo, because there are usually as many update, delete, inserts as there are reads, and instant database integrity and a schema are important.
Anyone that claims a tool is perfect for every problem is probably wrong. You need to figure out the best one for your use case, and load test, security test, performance test, etc... until you have a good guess for the right answer.
Did you ever consider a datasource like elasticsearch? If yes what made you choose mongo?
That probably would have worked as well (don't think I considered that specific solution). Mongo came up on top because of it's wide use (among other things), ie it's pretty easy to find support and lots of stories about how to scale it under different scenarios.
We were very well aware of its characteristics when choosing our DB, and didn't go in expecting any magic Web Scale or somehow getting a HA setup with plenty of durability with just one server.
For a multitenant CMS where you want to store documents with custom schemas, need more than just a key/value store and want some capability to do ad-hoc queries against custom fields, MongoDB is a pretty good fit.
We don't index custom fields and for queries where that would be required we do the actual querying with ElasticSearch, but for simple filters on a custom field or the like, Mongo does fine.
That said, 99% of our production issues involve bugs in MongoDB and it's inability to effectively use all available resources before it becomes unresponsive. I would say it needs a few more generations to become truly solid.
These things should be good learning examples for all.
I've found using Mongo as a stop-gap for consuming JSON APIs extremely useful. You could probably s/Mongo/{nosqldb} there since it's nothing earth shattering.
However, as the only tech guy in our startup I'm always looking harder at Redis than Mongo for most of the problems for which a NoSQL solution might be tempting. I've recently had a lot of success with JSON in Postgres and knowing HStore is always there if I need it has firmly cemented my opinion that I don't need a separate NoSQL solution (yet). (Of course I am merely persisting data in JSON format- not querying on it).
"Why MongoDB Never Worked Out Two Years Ago When We Tried to Run It For Our First Time For One Feature, And Beside Another Database Which We Really Considered Production."
I've seen and used MongoDB on multiple projects, big and small, and it's fine. It's a database that stores data. Use it for that purpose and you will be ok.
Also foursquare runs a very large MongoDB deployment. http://www.10gen.com/presentations/mongodb-foursquare-cloud-...
Craigslist: http://www.10gen.com/customers/craigslist
Shutterfly also has a very large deployment: http://www.10gen.com/customers/shutterfly
But it's always MySQL. Starting with MySQL, going back to MySQL, staying with MySQL.
All these things should be simple. You already have (or should have) a unified system for dealing with logging/monitoring/graphing/init scripts/backup across multiple services that are far more different from each other than they are from mongodb (Sharding strategy and slow queries are probably an application-level concern). It shouldn't be hard - in fact it should be trivial - to add one more service. At last.fm (disclaimer: my experience was brief and getting on for two years ago) it felt like we were running every database under the sun, but we had a unified system for doing deployment/monitoring/everything, so it was no bother to add one more if an application wanted it.
I've learned, especially on HN, that article titles can be extremely misleading.
I read the article. That statement makes it sound very much like they thought Mongo would be silver bullet for that feature.
The best use case for MongoDB is as a document store. I can essentially cache numerous MySQL requests into a compiled set of useful information. Especially if the information changes somewhat infrequently, then instead of running MySQL requests for every page load I can pull the information from MongoDB. In most cases when I use MongoDB, its not as a persistent data store, but as a "compiled" data store.
MongoDB also has some useful set operations.
I for one don't believe that MongoDB is /directly/ competing with MySQL, Postgres, etc. but rather enhances these databases.
Also, we DO implement a two DB setup... Couchbase and MySQL. They both have their place.
> I wrote about what I was thinking at the time here [1]
Range sharding (for saas,shard by client_id).
No sorting by value on couchbase indexes? And many other small features.
On the other hand i love about couchbase: no mongos,all servers equal.
I'm curious on the index sorting though, do you mean in terms of specifying what to sort on, or that you can't sort at all? As far as I understood the new indexing capabilities allow at the very least to sort on numeric values and similar.
http://www.couchbase.com/forums/thread/how-do-you-sort-resul...
There are a large number of well-established and quality installations of MongoDB. It works really well at both small and large scale and with a bit of tweaking (like any technology), can perform nicely.
There are certainly reasons for using Riak, HBase, Cassandra, etc. and there are reasons for using MongoDB. It is when people seem to act confused when their hammer isn't acting like a screwdriver that we get these blog posts.
I do not see Riak or Cassandra as competing at all. In fact I would expect most applications that use Riak or Cassandra are also using a general-purpose database as well (such as MySQL or Mongo). You could use some of those databases as a general purpose database but it would be more work for little benefit. It makes more sense to me to use Riak or Cassandra for use-cases that really need high-throughput and unlimited write-scalability and use an app database for things like user accounts and preference management and all the little things that can take up a lot of development time but will never have really demanding runtime requirements (for 99.99% of internet apps).
Finally, some closure!