Hacker Newsnew | comments | show | ask | jobs | submitlogin
bonobo 564 days ago | link | parent

I 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 Out at Etsy" and the conclusion would be the same.



gfodor 564 days ago | link

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.

-----

bonobo 563 days ago | link

What I meant was that the article was not about MongoDB at all. I think thefreeman summarized it better than me on his reply: the author is talking about his experiences on running more than one DBMS in production, not about MongoDB in particular.

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.

-----

thefreeman 564 days ago | link

I think his point was more "Why you shouldn't try to run two different DBMS in production"

-----

julian37 564 days ago | link

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]."

-----

Groxx 563 days ago | link

And it depends on how you define "DB". We've recently started using Redis for a number of things, and it has been incomprehensibly faster than our SQL database when it comes to rapidly finding and inserting records in (the equivalent of) a billion-row table. It's also far cheaper to run than significantly beefing up the database server just because of that one bottleneck. Easily worth the time and trouble of setting it up (neither of which was very much).

-----

mattmanser 563 days ago | link

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.

-----

tillk 563 days ago | link

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 (no persistence only to connect systems/services via pubsub) and Memcache (cache).

-----

jasonmccay 563 days ago | link

Yep ... in interacting with many developers, setups like this are almost commonplace.

-----




Guidelines | FAQ | Lists | Bookmarklet | DMCA | News News | Bugs and Feature Requests | Y Combinator | Apply | Library | Contact

Search: