Live data from Hacker News

“MongoDB is dead. Long live Postgresql”

github.com

101–110 of 160 posts

Re: “MongoDB is dead. Long live Postgresql”

#101

Seriously, another case of using Mongo incorrectly? I want to believe all the Mongo hate, but I can't because I always find out that the actual problem was one or more of: * didn't read the manual * poor schema * didn't maintain the database (compactions, etc.) In this case, they hit several: " Its volume on disk is growing 3-4 times faster than the real volume of data it store;" They should be doing compactions and…

> "Finally we sleep quietly, and don’t fear that mongodb will drive out redis to swap once again."

MongoDB and Redis on the same box? Two data stores that need working set / all of the data to reside in RAM for performance? That is a recipe bound for failure.

Everyone seems to learn about physical separation the hard way.

Re: “MongoDB is dead. Long live Postgresql”

#102
post #39

Earlier quoted context omitted.

And let's not forget the fact that it has a per database lock, which is a really strange choice for a document database.

The guys at MongoDB are working on moving this to a more fine-grained lock in the future. In practice, it's not usually a problem but it'll be less so going forward.

It is a problem in practice if you have any amount of load. You'll see latency quickly go up with lock times, which go up with concurrency.

Why bother, when you can use another db without this problem, right now?

Re: “MongoDB is dead. Long live Postgresql”

#103
post #54

Earlier quoted context omitted.

Or, to be even more specific--if there's a Right Way to use a program, that Right Way should be encoded as defaults you have to override (if you know what you're doing), and automated actions you have to disable (if you know what you're doing.)

It has nothing to do with the defaults. It is all about people forgetting that MongoDB is a document database and not a relational one. I can write apps that will be 10x faster with MongoDB and 10x faster with PostgreSQL. It's all about matching your domain model to your database.

>t is all about people forgetting that MongoDB is a document database and not a relational one.

It's been a while since I looked into Mongo, but that was a Mongo marketing problem. They used to (still?) advertised themselves as a RDBMS replacement, literally.

Re: “MongoDB is dead. Long live Postgresql”

#104
post #40

Lets just say that PostgreSQL answers the criticisms of relational databases that led to NoSQL. The complaints all boiled down to saying that the RDBMS forced you to do things one way and that it was cumbersome. PostgreSQL evolved and fixed the most annoying issues like JSON support and schemaless key-value store support. That's the way open source is supposed to work. Now folks are learning that throwing out the bab…

> PostgreSQL evolved and fixed the most annoying issues like JSON support and schemaless key-value store support. As I recall, automatic sharding was on that list, and pg doesn't attempt to tackle that afaik.

Mongo doesn't really do that in a way you can reliably use in practice either, though. Its sharding offers a subset of operations over an inconsistent view of your dbs.

You can do that with Postgres trivially, and even automatically with postgres_fdw and writeable views.

Re: “MongoDB is dead. Long live Postgresql”

#105
post #65

I'm no MongoDB expert, but recently started to look into this db. Can anyone tell me (from experience, not from promo materials) - for which use cases MongoDB is good fit and for which ones it's not? It's clear that it can't fit for everyone. That's why it would be good to know in advance, for what it most likely to find and for what it's most likely not to fit.

Don't.

Having used it on what is supposed to be its perfect use case, I think it's a terrible product. Use anything else you like the look of.

Re: “MongoDB is dead. Long live Postgresql”

#106
post #46

The title is a bit misleading. This is basically an announcement of a fork of Errbit that has Postgres support. Additionally, the fork was announced as an issue on errbit with no discussion or as an official pull request. I would not consider this good etiquette. If you fork your project (especially without discussing the intention first), adding a bug to the original project isn't a very nice thing to do. An officia…

There is nothing wrong with announcing a fork within the original's community. Where else would you announce it?

Re: “MongoDB is dead. Long live Postgresql”

#107
post #63

Earlier quoted context omitted.

Although it is true that MongoDB uses a lot of disk compared to your average RDMS there are reasons for that. 1) MongoDB (and various other NoSQL solution) are schemaless and thus have to store document fields along with the values for each document. This alone usually results in roughly twice as much actual disk space being used compared to an RDBMS. 2) MongoDB preallocates fairly large chunks of disk for their mmap…

1. That's not necessarily the only possible implementation. It would be trivial to assign a number to each key and keep this map in the header of the db file. 2. That's not really the issue, I don't care about the size of small dbs. Large dbs have gigantic sizes. 3. That is absolutely abysmal, yes. It doesn't just use 2x as much space as other dbs, in practice that can be up to 20-30x as much in bad cases. It's commo…

1) Not trivial at all. As documented in a rather broad range of papers and whatnot. You're almost certainly oversimplifying the problem.

2) For gigantic DBs the preallocation overhead is almost non-existent.

3) Fair enough.

Your last point is, again, is not fact. It's not slower but on average measurably faster than most commonly used RDBMs with equal "tuning" efforts if utilized for the same task. I can't help but feel you're not entirely objective here ;)

Re: “MongoDB is dead. Long live Postgresql”

#108
post #34

Earlier quoted context omitted.

> * didn't read the manual > * poor schema > * didn't maintain the database (compactions, etc.) The real world dictates that this happens more often than not. You know why I like Postgres? When I don't read the manual, create a crappy schema, and forgot to maintain the database it STILL seems to work okay.

To be fair, Postgres has automatic vacuuming now, but it is a relatively new feature. Both projects seem to agree that it is not a high-priority item, though there is certainly something to be said about using a mature product, which Mongo is most certainly not. Your comment has made me quite curious to know what people using mature databases of the time were saying about Postgres 19 years ago, when it was roughly th…

Back when Postgres didn't have automatic vacuuming, the need for manual vacuuming was one of the commonly-suggested reasons why MySQL was a better option - after all, MySQL just worked out of the box.

Re: “MongoDB is dead. Long live Postgresql”

#109
post #2

I'm nearly sure one day someone will write a MongoDB compatibility layer on top of PostgreSQL

Funny you mention this, we've written one as we transition from MongoDB to PostgreSQL. It was actually much easier than I expected, because MongoDB doesn't really do anything - all the JOIN logic is in code and it mostly consists of "find" and "findOne" calls with minor filtering that is easily translatable to SQL.

The hardest part is re-training all the devs to stop thinking like Mongo devs (ie. "I must make five queries and join the info in code") and let the DB do the heavy lifting it was designed to do.

Re: “MongoDB is dead. Long live Postgresql”

#110

Maybe I am just incredibly lucky, but mongodb has worked fine for ridewithgps.com - we are sitting at 670gb of data in mongo (actual DB size, indexes included) and haven't had a problem. Replica sets have been fantastic, I wish there was another DB out there that did auto-failover as cleanly/easily as mongo does. We've had a few server crashes of our primary, and aside from 1-2 seconds or so of errors as requests com…

670 gigabytes is a puny database size. You should be able to press so much power through a system with a disk system like the one you have. I would seriously consider a Postgres setup on a data set of that size. Additionally, I would probably just store the JSON data directly inside postgresql.
Post reply on HN