Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Migrated Away From MongoDB

svs.io

Post reply on HN
Print view View original

21–30 of 213 posts

Re: Why I Migrated Away From MongoDB

#21

Post by zemo »

bunderbunder wrote: post #6

Fourthly, and this one completely blew my mind - somewhere along the stack of mongodb, mongoid and mongoid-map-reduce, somewhere there, type information was being lost. I thought we were scaling hard when one of our customers suddenly had 1111 documents overnight. Imagine my disappointment when I realised it was actually four 1s, added together. They’d become strings along the way. I've been having a similar problem…

Mongo accepts the data you give it. If you have a type-conversion error, it's in your application layer. I use Mongo daily and have never seen this problem, because I'm using a statically typed language. This seems like more of a complaint about Ruby than Mongo.

I use Mongo daily on a Go project, and I actually think it's pretty annoying; I'm not trying to be a Mongo apologist, but ... this type conversion argument doesn't seem to be very fair to Mongo.

Re: Why I Migrated Away From MongoDB

#22

Post by daveman »

As an analytics professional who was pressured into a MongoDB environment, I feel the OP's pain. If you want to do gymnastics with your data, (aggregations of aggregations, joining result sets back onto data), SQL expressions are a 1000 times easier than Mongo constructs (e.g. map reduces). We usually ended up scraping out data from Mongo and dumping records into a SQL database before doing our transformations.

All that said, our developers loved the ease of simple retrieval and insertion, and of course the scalability. So I guess you ultimately need to base your decisions on your priorities.

I don't fault the OP though, since it's hard to know just how limiting NoSQL will be until you try to do all the things you used to assume were database tablestakes (no pun intended).

Re: Why I Migrated Away From MongoDB

#23

Post by aneth4 »

stevencorona wrote: post #10

The downside, or challenge, with NoSQL (generally speaking) is that you need to handle your aggregations ahead of time - you need to know what queries you'll want to run in the future when you store your data. If you have some new aggregation you want to keep, you'll need to re-process the data (with Hadoop or something else). It's the trade-off of being able to scale reads and writes horizontally. And unless you nee…

This is the opposite of "agile." It is difficult to know where your product will be in 2 months let alone 12, so it seems the advice to use SQL first is sound - unless you enjoy long distractions to solve simple JOINs.

Re: Why I Migrated Away From MongoDB

#24

Post by itaborai83 »

To be fair, some NoSQL solutions were being sold marketing wise as the be-all and end-all of data solutions. Just google "mongodb mysql migration" and look how everyone is/was so eager to jump on the non-relational bandwagon. Some backlash was to be expected, after all, we might have reached the Trough of Disillusionment

Re: Why I Migrated Away From MongoDB

#25

Post by bunderbunder »

rbranson wrote: post #14

I'm no fan of MongoDB, but this same advice goes for any NoSQL data store. I am an Apache Cassandra contributor and community MVP, but my advice stays the same: it's best just to start with a SQL database and go from there. Read some books and learn it well: the "SQL Cookbook" from O'Reilly is great, and so is "The Art of SQL." Premature optimization continues to be the root of all evil.

Don't forget to read a book that's specific to your particular RDBMS. Because SQL databases are only trivially interchangeable for trivial cases.

There have been more than a couple times when I was ready to blame the relational model, but further investigation revealed that the real root of the problem was that the existing schema or query used an approach that was optimized for one DBMS but performed terribly on the one we were actually using.

Re: Why I Migrated Away From MongoDB

#26

Post by zemo »

armored_mammal wrote: post #15

Can someone confirm that there is no such thing as a case insensitive index/search in Mongo? If true it seems likely that the author's comments have some degree of truth, at least when it comes to its usefulness for web and mobile applications. Storing data only lowercase isn't a good a idea for obvious reasons, and storing two copies of the same data for searching only, while not the end of the world, seems a little…

case-insensitive regex searches are supported.

Re: Why I Migrated Away From MongoDB

#27

Post by enjo »

dkarl wrote: post #20

You have to load every document in the database and extract the audit trail from it, then filter it in your app for the user you’re looking for. Just the thought of what that would do to my hardware was enough to turn me off the whole idea. Naive question from somebody who has done a little reading on and dabbling with key/document-with-MapReduce style datastores, but who hasn't tackled a real production problem: I t…

Yep, or you need to build some other construct to support it (IE: keeping running tallies and the like).

It's a tradeoff between the benefits of the document store vs the loss of relational data. The blog author here clearly didn't understand the trade-offs he was making.

As always with these discussions: it's important to use the right tool for the job. I'm a big fan of what Mongo is doing. I've used it two higher scale projects and have no complaints. Of course, I'm using it in the context for which Mongo excels.

Re: Why I Migrated Away From MongoDB

#28

Post by adambard »

As a relative idiot when it comes to this sort of thing, I'd like to insert the following supplementary question: what is the sort of application/dataset for which Mongo is particularly suited?

I've used it on small projects, and have enjoyed it. Perhaps my data has just been simple/loosely-coupled enough to never run into these problems?

I read a lot of posts like this on HN before every trying Mongo, so I've at least been convinced to always implement schema at the application layer. Others seem to keep learning that lesson in harder ways.

Re: Why I Migrated Away From MongoDB

#29

Post by lucasjans »

zemo wrote: post #26
armored_mammal wrote: post #15

Can someone confirm that there is no such thing as a case insensitive index/search in Mongo? If true it seems likely that the author's comments have some degree of truth, at least when it comes to its usefulness for web and mobile applications. Storing data only lowercase isn't a good a idea for obvious reasons, and storing two copies of the same data for searching only, while not the end of the world, seems a little…

case-insensitive regex searches are supported.

Do you know why are case-insensitive searches not recommended? What's the realistic work-around?

Re: Why I Migrated Away From MongoDB

#30

Post by rbranson »

bunderbunder wrote: post #25
rbranson wrote: post #14

I'm no fan of MongoDB, but this same advice goes for any NoSQL data store. I am an Apache Cassandra contributor and community MVP, but my advice stays the same: it's best just to start with a SQL database and go from there. Read some books and learn it well: the "SQL Cookbook" from O'Reilly is great, and so is "The Art of SQL." Premature optimization continues to be the root of all evil.

Don't forget to read a book that's specific to your particular RDBMS. Because SQL databases are only trivially interchangeable for trivial cases. There have been more than a couple times when I was ready to blame the relational model, but further investigation revealed that the real root of the problem was that the existing schema or query used an approach that was optimized for one DBMS but performed terribly on the…

This is why the "SQL Cookbook" is good, it has dozens and dozens of examples with permutations in Oracle, MS SQL, MySQL, and PostgreSQL.
Post reply on HN