Hacker News new | ask | show | jobs
by tilsammans 4572 days ago
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. Not having to migrate is just one of the perks. Our schemas were largely in the form of Orders (having many) Shipments (going_from) ShipPoint (to) ShipPoint

You say priceless. I don't think it means what you think it means. 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. The schema you are using (orders have many shipments going from point to point) are easily expressed in a relational schema and once defined would hardly ever need to change, if at all during the lifetime of the application. So what if I need to add a column here or there. It won't matter at all. Do you have more than 100 million documents in MongoDB? I guess you don't. Even if you do, relational has that covered too.

> This doesn’t always have to be the case, though it significantly contributes to Mongodb’s fast writes.

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.

> We add a lot of Notes to each shipment [...] it doesn’t critically affect the business workflows of the application.

Say what?

You're fine with data, even notes, being lost? That is completely acceptable to you? I guess this is what shocks me most. You kids think it's normal to lose data, and consider storing a note to be optional or something. It baffles me. If a note is optional, why have it in the first place?

> They do but since most of the stuff is memory mapped

Translates to: you need to have your data in RAM. This does not scale at all. It doesn't even begin to scale to the level where MySQL was. TEN years ago.

> Here is a simplified snapshot

What follows is a class that is 236 lines long. Two hundred and thirty-six lines long. Dear sir, if this is your simplified code I fear what your actual production code looks like. If you committed that to one of my repos we would have a very serious talk. Also you would do this exactly once during your career at my company.

> I haven’t even touched upon the replication and sharding features that Mongodb offers which I will reserve for another post.

Which every relational store also offers.

> To summarise I feel Mongodb is awesome

Why is it awesome? You have only shown me why it is horrible. I have seen nothing that is awesome. Optional data persistence, needs huge amounts of RAM, complex application level code to deal with reports, this is all stuff that you can do better, faster and more reliable with a relational solution.

2 comments

> 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 that bad experience to all NoSQL.

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 "Performance One" Rackspace server costs $1250/month and Rackspace isn't known for being cheap. A Hetzner box with all the things added (12TB HD, 2.4TB SSD HD, 384GB RAM) costs 831 Euro/Month.

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

Changing code is one thing, changing the DB is another. A deployment that changes only the code is simpler than one that changes the DB.

How many DBs do you have? Testing (usually local), staging, production? For how many sites?

It works the same, if row['new_field'] do_something() else do_something_else()

You have unit tests to make sure it works.

And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.

> A deployment that changes only the code is simpler than one that changes the DB.

In your experience, perhaps, but that's reversed in many other places.

As for everything else your point is only accurate if you assume that migrations are done by hand. If use a migration library it's impossible to forget to apply a migration to a database so there's no problem working with copies or even forks of databases.

> And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.

You're implying causation incorrectly: hstore and JSON are useful for cases where you explicitly do not want schema enforcement or can't afford the performance impact of normalization. This is not saying that migrations are hard, merely that not all problems have the same best solution.

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)

MongoDb is not going to solve development/operations issues, which is what you are describing. If anything, it makes those things worse as it is much more cavalier with your data.
> Nobody would risk migrating that table

People migrate tables a lot bigger than 23M rows all the time. On MySQL, even, though it's an offline task there.

pt-online-schema-change, problem solved!
What DB were you using?