Why I Migrated Away From MongoDB
1–10 of 213 posts
Re: Why I Migrated Away From MongoDB
#2Looks like he jumped ship just a bit too early.
Re: Why I Migrated Away From MongoDB
#3"To be honest, the decision to use MongoDb was an ill-thought out one. Lesson learned - thoroughly research any new technology you introduce into your stack, know well the strengths and weaknesses thereof and evaluate honestly whether it fits your needs or not - no matter how much hype there is surrounding said technology."
I think you are not alone in learning this lesson with this particular technology. Fortunately it's one I learned by proxy from working adjacent to a team that decided to introduce Mongo into their stack...but I still wake up and hear the sceams at night of "You have to put the whole dataset on RAM?"...you weren't there, man...we lost a lot of good guys...
You have to draw a clean line between "stuff it is really fun and enlightening to play with" and "stuff you introduce into your stack".
Re: Why I Migrated Away From MongoDB
#4Looks like he jumped ship just a bit too early. http://docs.mongodb.org/manual/applications/aggregation/
[deleted]
Re: Why I Migrated Away From MongoDB
#5"I can only come to the conclusion that mongodb is a well-funded and elaborate troll."
It's possible the reasoning he used to use mongodb is the same as the one he used to abandon it.
Re: Why I Migrated Away From MongoDB
#6Fourthly, 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 with an SQLite data store, only the other way around. Strings were getting converted to numbers, with leading zeros that were significant and needed to be maintained being lost along the way.
It sucked all the fun out of dynamic typing for me. At least in combination with automatic type conversions. Having to think about type and when to make transitions across type boundaries when you need to is just a little light busywork. Having to worry about type and transitions across type boundaries being made contrary to your intentions is a downright PITA and, it turns out, a serious quality control issue.
Re: Why I Migrated Away From MongoDB
#7You used a tool without researching it first, you jumped a bandwagon without finding out its destination, you most likely used it wrong because you didn't RTFM. Now you ditch and diss it. Grow up.
Re: Why I Migrated Away From MongoDB
#8You used a tool without researching it first, you jumped a bandwagon without finding out its destination, you most likely used it wrong because you didn't RTFM. Now you ditch and diss it. Grow up.
Very harsh given that he points out he made these mistakes right at the beginning of his post.
Re: Why I Migrated Away From MongoDB
#9I've ran into similar issue as you described. Something that can be done so simple and quickly in SQL, was bewilderingly difficult to do in mongo.
The schema-less database approach also seems attractive at first but updating your data whenever your "app schema" changes starts to become a pain real quick.
Now I can't really live w/o having a schema first, it actually saves you a lot more time in the long run (even short run), being schema-less means you can't really do anything too fancy w/ your data (generate reports, advanced search, etc...)
Re: Why I Migrated Away From MongoDB
#10The 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 need it, an RDBMS makes sense given the flexibility.
Maybe, instead of looking at NoSQL as a full-on replacement for RDBMS, we can look at it as a better solution to sharding.