Live data from Hacker News

Mongodb – not evil, just misunderstood

siddharth-ravichandran.com

31–40 of 53 posts

Re: Mongodb – not evil, just misunderstood

#31

I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…

"A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it." Not if your application is still on development. 100k+ rows? Not complicated. Try with 23M rows. Nobody would risk migrating that table.

Usually a migration is adding a column. That takes the same time with 1M rows as it does with 1 row (in Postgres).

Re: Mongodb – not evil, just misunderstood

#32

Earlier quoted context omitted.

"A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it." Not if your application is still on development. 100k+ rows? Not complicated. Try with 23M rows. Nobody would risk migrating that table.

At my last job we did that on a regular basis, for the most part without even having downtime.

And at my last job no one would risk it because any issues with this would mean loss of revenue, angry customers and people having to revert code at a whim.

(Of course, not only migration issues, but any code issues as well)

Re: Mongodb – not evil, just misunderstood

#34

I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…

> What you are saying is that I need to change MongoDB in order to make it safe. Relational database are safe out of the box, no change necessary Relational databases are safe out of the box, but it is not their unique capability. Most other NoSQL stores are safe out of the box, too, being at the same time faster and easier to scale than RDBMSes. It is only Mongo which did it differently, so please don't extrapolate…

He didn't. Also, the Most part of "Most other NoSQL stores are safe out of the box" doesn't really give you the right to be snarky about the supposed implication.

Re: Mongodb – not evil, just misunderstood

#35

Earlier quoted context omitted.

> What you are saying is that I need to change MongoDB in order to make it safe. Relational database are safe out of the box, no change necessary Relational databases are safe out of the box, but it is not their unique capability. Most other NoSQL stores are safe out of the box, too, being at the same time faster and easier to scale than RDBMSes. It is only Mongo which did it differently, so please don't extrapolate…

For the use case described here scalability is irrelevant. The OP is processing hundreds of real world shipment updates per day. I'm pretty sure that Postgres can handle that on a $10-20 digital ocean droplet. A back of the envelope calculation. Assume each shipment brings in $0.10 in profit to his company. Suppose at some point he needs to scale up to 100,000 shipments/day. His revenue is now $10,000/day. A "Perform…

Scalability is irrelevant, but availability/reliability is. I simply don't get why you insist on comparing MongoDB to RDBMS while there are better NoSQL alternatives, which would be the right tool for the job.

Re: Mongodb – not evil, just misunderstood

#36

I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…

"A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it." Not if your application is still on development. 100k+ rows? Not complicated. Try with 23M rows. Nobody would risk migrating that table.

What DB were you using?

Re: Mongodb – not evil, just misunderstood

#38
post #18

Disappointing. I want to like MongoDB, but if this is the best a MongoDB apologist can come up with, I'll stick to SQL with a decent O-R mapping.

Fortunately MongoDB is not the end of NoSQL. Some other NoSQL database stores have huge advantages over relational database systems, especially in terms of reliability, scalability and performance-to-price ratio.

what do you think of http://www.arangodb.org/ ?

Re: Mongodb – not evil, just misunderstood

#39
>The advantages of schemaless documents are priceless. Not having to migrate is just one of the perks.

Was the first sign that this person doesn't know what he is talking about...

Of course you still have to migrate. Either your DB or your code, because you can't handle a change in how you store stuff without one or the other.

"No migrations" is true only for the most trivial of changes, and only if you're willing to handle special cases in your code.

Re: Mongodb – not evil, just misunderstood

#40

I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…

"A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it." Not if your application is still on development. 100k+ rows? Not complicated. Try with 23M rows. Nobody would risk migrating that table.

How does this change with MongoDB? The question of development support applies equally to both but it's usually MUCH safer to add a SQL column (default null, etc.) than to dive into a thicket of app-specific JS.

This has been happening for decades in the RDBMS world – even the ultra-conservative Oracle admins I've worked with were willing to come of out in-place retirement long enough to do something like that.

Post reply on HN