Earlier quoted context omitted.
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…
Why MongoDB Never Worked Out at Etsy
61–70 of 73 posts
Re: Why MongoDB Never Worked Out at Etsy
#62Earlier quoted context omitted.
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…
Are there? Who are these magical people? 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).
Re: Why MongoDB Never Worked Out at Etsy
#63Wondering why everybody is using MySQL if Postgresql is supposed to be better. Are there any (startup) success stories involving Postgresql?
Re: Why MongoDB Never Worked Out at Etsy
#64Earlier quoted context omitted.
Are there? Who are these magical people? 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.
I don't consider myself to be magical, but anyway — since you were asking. 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 (…
Re: Why MongoDB Never Worked Out at Etsy
#65Earlier quoted context omitted.
Did you read the article? His main reason had nothing to do with Mongo itself.
Yes, yes I did. My question is why it was selected in the first place, rather than a period of exploration of the benefits and drawbacks of the different NoSQL solutions (which perhaps might have stopped this particular test-case from being a failure). The article doesn't mention those details though. Also, we DO implement a two DB setup... Couchbase and MySQL. They both have their place.
Re: Why MongoDB Never Worked Out at Etsy
#66Genuine question- who is using MongoDB successfully in production, and at scale? I'm not aware of anyone myself- I hear of it being used in hackathons etc because its so quick to set up, but I'd be curious to know what people are using it with.
They have a list of who's using MongoDB in production. http://www.mongodb.org/display/DOCS/Production+Deployments
Re: Why MongoDB Never Worked Out at Etsy
#67Genuine question- who is using MongoDB successfully in production, and at scale? I'm not aware of anyone myself- I hear of it being used in hackathons etc because its so quick to set up, but I'd be curious to know what people are using it with.
Re: Why MongoDB Never Worked Out at Etsy
#68All 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.
Re: Why MongoDB Never Worked Out at Etsy
#69Earlier quoted context omitted.
I run two sites, one is the perfect use-case for MongoDB - http://www.AUsedCar.com , it's a used car search engine. We've seen nothing but benefits by switching to it from MS SQL Server. Queries are way faster etc... It's a great use case because 99.9% of DB interactions are read-only searches. My other site, http://www.BudgetSimple.com on the other hand is using SQL Server (in the process of porting to MySQL). It wo…
Can you give me an example of a query that was made much faster?
Re: Why MongoDB Never Worked Out at Etsy
#70Earlier quoted context omitted.
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.
I'm the developer that helped migrate the data from mongo to mysql (under mcfunley's supervision). Even a straightforward data migration becomes complicated when you have to do it without affecting the production feature or consumers of your public api (parallel writes to both dbs, snapshot and move the historical data, switch reads to the new db, etc). In addition, we took the opportunity to move the feature to a sh…