Soundcloud wrote a blog post http://backstage.soundcloud.com/2011/04/failing-with-mongodb... about the specifics of how they failed in implementing an analytics platform in MongoDB, then went with Cassandra (and why). I have been at a company where it was on developers to deploy mongo clusters, setting up logging can suck, but still there are no numbers or even application integration specifics here. As someone pointed out - manual denormilization can suck. There are options like MongoHQ and Heroku though so this shouldn't resolve to "don't try a new data store its hard and possibly buggy".
Why MongoDB Never Worked Out at Etsy
41–50 of 73 posts
Re: Why MongoDB Never Worked Out at Etsy
#42The bottom line is that MongoDB and MySQL are two different persistent data structures. MySQL is a more powerful data structure that can do more things. MongoDB is less powerful, but is more efficient at certain things. Due to pre-mature optimization or shortsightedness, some folks are romanticized with the efficiency of a less powerful data structure (MongoDB) and fail to realize that their application really need the more powerful relational data structure.
These things should be good learning examples for all.
Re: Why MongoDB Never Worked Out at Etsy
#43Earlier quoted context omitted.
So, if someone asked you why they should use "Riak and countless others" and not MongoDB, what would you really say? Also, you seemed to imply that Riak was a go-to solution (my wording) while implying that MongoDB was more of a fringe "buzzword" technology ... when, counting features, I think most would acknowledge MongoDB as being more mainstream. There are a large number of well-established and quality installatio…
I would say that (and I suppose this is a bit of a weasel words style answer) each is going to have their benefits and drawbacks and they would have to investigate each for their particular use-case to determine which would best work for them. I think it's pretty true though. I didn't mean to imply that Riak is a go-to solution at all. It was more to give a couple 'options' to explore if you were to start a list alon…
I agree and I do think that often times people will select a technology and think it should work like some other technology, become frustrated when it doesn't and then, in turn, blast the technology on only the merits they understand.
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.
Re: Why MongoDB Never Worked Out at Etsy
#44Misleading article tile's summary: We tried to use a technology that was less mature than another technology. We had to figure some stuff out that had already been figured out on the more mature technology. Using two technologies was more complicated than using one.
Re: Why MongoDB Never Worked Out at Etsy
#45I was expecting a post describing why MongoDB specifically weren't fit to their use case, but the TL;DR version is basically: " 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 Ou…
Your proposed title is very confusing and meta. The current title is only misleading if you are going into it with biased expectations about what it's going to teach you. The article is interesting precisely because it is not just another "NoSQL sucks" screed.
Re: Why MongoDB Never Worked Out at Etsy
#46Maybe it should be titled... "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.
You didn't read the article because the point was that the lesson learned was that if you are going to have two data stores the human tendency is for one to be a second class citizen with regards to support by ops, etc.
Re: Why MongoDB Never Worked Out at Etsy
#47I was expecting a post describing why MongoDB specifically weren't fit to their use case, but the TL;DR version is basically: " 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 Ou…
I think his point was more "Why you shouldn't try to run two different DBMS in production"
That would be a silly point to make. Many people are running multiple DBMS in production without regrets. Each DBMS has strengths and weaknesses in different areas, and for many businesses it doesn't make sense to shove everything into a single DBMS just because things are easier to manage that way.
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]."
Re: Why MongoDB Never Worked Out at Etsy
#48Earlier quoted context omitted.
Where exactly is the net gain in your situation? 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 li…
right off the bat, you've lost the querying power that SQL offers. 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…
MySQL Cluster?
Auto sharding, shared nothing, SQL support, it does a pretty good job of things.
Re: Why MongoDB Never Worked Out at Etsy
#49Earlier quoted context omitted.
right off the bat, you've lost the querying power that SQL offers. 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…
MySQL Cluster? Auto sharding, shared nothing, SQL support, it does a pretty good job of things. http://www.mysql.com/products/cluster/scalability.html
MySQL cluster is another option beyond MySQL Galera (and Cluster actually has a NoSQL layer on top of it.. FYI)... but I have to say if we want to talk about scaling issues for MongoDB, you might not be happy with some of the limitations of NDB.
Re: Why MongoDB Never Worked Out at Etsy
#50The bottom line is that MongoDB and MySQL are two different persistent data structures. MySQL is a more powerful data structure that can do more things. MongoDB is less powerful, but is more efficient at certain things. Due to pre-mature optimization or shortsightedness, some folks are romanticized with the efficiency of a less powerful data structure (MongoDB) and fail to realize that their application really need t…
This also makes it sound like whoever intervened to rewrite said feature in sharded mysql had an easy time. Usually this would not be an obvious port. However we don't know the technical nature of the feature or specifically why it failed.