Hacker News Reader

Hacker News

Comment by dschiptsov | Hacker News Reader

Full thread

dschiptsov

Since when MongoDB is considered as a database comparable with PostgreSQL?)

View on HN

It's a comparison on MongoDB's home turf, showing how well PostgreSQL works when used as a NoSQL document store.

That's not really relevant, since the point is that Postgres can do what MongoDB does but faster.

Except it doesn't. It just has a JSON data type. As does many other databases e.g. Oracle, Teradata.

People are switching to MongoDB because the developer and deployment experience is so good.

Capability is not the same thing as usability. Postgres is demonstratively more capable than Mongo, it's just not perceived as usable.

There's a deep lesson here to be learned. One that can make you rich.

Hate to say so, but many are switching to MongoDB because it's the current new kid on the block.

I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. Not that MongoDB is a bad database, but it has it's fair share of issues. Granted, this is the case for every database, but if you pick any database without being aware of those, you end up in a world of pain.

(Context: I consult for backend systems in general)

That was my only experience with MongoDB - "let's try this, for this experimental project, to see what it's like", without taking into account its characteristics.

After that the project grew, I was brought in and needed to do some reports, which were a huge pain in the ass without proper SQL and joins.

I don't intend to have anything to do with people using MongoDB unless they have a really, really good reason for doing so, and it's used alongside other databases.

A friend of mine came up with the perfect use-case for MongoDB.

His company installs and monitors sensors in civic infrastructure: roads, train tracks, bridges, ... These sensors provide constant data streams which need to be stored somewhere before processing. Any raw data older than 2 weeks is worthless, and if 2-3% of data is lost before written it's not much of a problem. More data is coming in all the time any way.

For them MongoDB is the perfect transient cache. Sensor data is processed and the results stored elsewhere. Easy to expand. Flipping between installations is just a matter of toggling load balancer, an once an offline cache has been processed, it can be nuked and put back as a fresh system.

So, for a setup where easy size expansion, fast mostly-reliable writes and ease of use are the primary design constraints, mongo fits in suprisingly well. It's a fascinating use-case.

From what that sounds like, I agree. This is a complex problem description with a pointer where the database provides solutions.

> I found that many companies have incredibly bad, not use-case driven reasons to pick their DB.

As in "Our lead dev always wanted to try X, because he likes the name".

Given that, I really need to build an app using project-he-who-may-not-be-named.

good luck sharding postgres - idiots

>because the developer and deployment experience is so good. That was ironic, right?

http://php.net/manual/en/mongo.sqltomongo.php

Strangely,there is no JOIN example ...

Well, you won't find one. That's a property of the way the system works. It can be either good or bad, but you won't find an example on how to store and query whole documents with a map/reduce implementation on an SQL database. Both can be either a good fit or a bad fit to your needs - I've seen project that leveraged CouchDB to basically return all data for any given view with a single query from a pre-calculated view, something which would have impossible with an SQL database. That's a good fit. Using a document store as drop-in-replacement for an SQL dabase is most of the time a very very bad fit.

The general issue that I often see is that people don't choose their databases by "is this a good fit or a bad fit for our use case" but rather by "that looks cool" or "we need that to attract talent" or "we did that project with X, so X is also fine for that new, totally different thing". And then they also try and stick with it at all costs, instead of acknowledging that the choice was a bad fit. And then they call you and say "we have an X database in flames, can you come in and rescue our data? Best would be yesterday?"

This is not restricted to document databases. I've seen apps run on mysql on a cluster with 10 Sun XFires where after a man-month of index-optimization 3 would have been sufficient. That was like shooting dead fish in a dry barrel. A lot of developers don't want to bother with stuff like "how does that complicated piece of machinery actually behave if I push it."

> I've seen project that leveraged CouchDB to basically return all data for any given view with a single query from a pre-calculated view, something which would have impossible with an SQL database.

This sounds interesting. I've been looking for a good example where NoSQL db is better than relation db. Could you provide more details.

Postgresql has materialized views now:

http://www.postgresql.org/docs/9.3/static/sql-creatematerial...

Unless I'm misunderstanding what Xylakant means, that's certainly doable in Postgresql and has been in other relational databases for a long time.

I didn't mean "view" in the sense of "database view" but rather in the sense of "page view". All data displayed on a page with multiple types of documents was returned in a single query. That's certainly doable in pg, but requires a lot of hacks and it's not efficient. Or you can use hstore and basically use pg as a nosql db.

Ah, that makes sense, though couldn't you solve this by something like creating a table called 'pages' and storing the materialized JSON (the same that mongo would generate) in the table?

Sure, you could. But CouchDB just makes that very easy to do while it is very hard and hacky in PG. On the flip side, the use case did not require the guarantees that PG has to offer, so why go through the pain for no gain :)

I maintain an environment that has both pg and mongodb. While pg was simple to install and to debug, mongo has given me just pains. I agree that MongoDBs developer experience is nice - download, run, develop, but from the OPS side, that looks totally different. PG is a bit the other way round.

The sad state of affairs however is that often developers choose which DB they'd like to work with and (Dev)OPS doesn't get a say in that.

I refuse to believe you speak from experience.

> People are switching to MongoDB because the developer and deployment experience is so good.

WAT? can you tell us more about your experience? according to mine ,developers are moving away "en masse" from Mongodb,because the experience was so bad.

... and far more safely. No one should be using MongoDB in production (or if you do, please never let me store data in your service).

Since NoSQL movement started comparing their database options with SQL based ones.

Come on. To call itself a database the product should have state-of-the-art storage technology implemented, not just a simple API which always returns OK before actual data has been committed to disk.

In old times you could suddenly switch off power of a running Informix server and it will correctly restore the state on that very moment after reboot, dropping all partially (unfinished) transactions, keeping all the committed ones, so it was possible to have a clean state of the system.

How does it work? Append-only so-called "physical logs" on an direct-access, unbuffered by an OS and hard drives storage, proper partitioning on separate physical drives (for real parallelism), etc.

Again, real databases are all about data-storage (architecture, data-structures, algorithms, design decisions, proper implementation) not some "user-friendly" APIs and "well-written" docs to quickly gain popularity among ignorant.

Database back-ends are among the hardest problems in programming and the amount of research which has been done in 80s and 90s in this field is quite remarkable. I doubt that a bunch of punks with professional marketing and sales techniques could adequately replace implementation of a high-performance and fail-safe storage back-end, which is called a database.

So CouchdDB qualifies? Given a proper hardware underneath it will at most loose the last, unfinished write.

You are right on all counts.

As someone who evaluated and eventually recommended against implementing MongoDB for a new product, I entirely agree with you. The Mongo implementation was shot after about three months of wasted time after failure in pre-production testing. It was rolled back at great cost to SQL Server with a light document-style abstraction as Mongo failed miserably on precisely what you said: reliability, consistency, scalability and storage management.

Proper relational databases (PostgreSQL, Oracle, SQL Server in my scope of experience) can take an absolute incredible amount of punishment without breaking any guarantees. The relational bit above is optional but it is at least something you can choose to use or not.

I never got the point of the NoSQL movement.

For me it always sounded like a bunch of people not willing to learn how to write proper queries and optimize data storage.

Since the phrase "big data" appeared.

Reply on news.ycombinator.com