Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“MongoDB is dead. Long live Postgresql”

github.com

Post reply on HN
Print view View original

131–140 of 160 posts

Re: “MongoDB is dead. Long live Postgresql”

#131

Post by jeltz »

remon wrote: post #107
lucian1900 wrote: post #100

Earlier quoted context omitted.

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 f…

PostgreSQL and MySQL both support compression of data, so even if you do not solve the duplicated key problem you still can reduce disk usage.

The only benchmarks where I have seen MongoDB winning have been those where MongoDB was configured with different consistency requirements than MySQL and PostgreSQL. My suspicion is the MongoDB is slowest but I have never seen any high quality benchmarks.

Re: “MongoDB is dead. Long live Postgresql”

#132

Post by functional_test »

derefr wrote: post #54
rlpb wrote: post #30

Earlier quoted context omitted.

> Seriously, another case of using Mongo incorrectly? If a large proportion of MongoDB users are using it incorrectly, then I'd argue that it is a MongoDB problem, if only a documentation and messaging one. Clarity on what is and is not an appropriate use should be prominent. So, what is this proportion?

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

The primary "unreasonable" default seems to be that in the beginning, writes were not safe by default. Although they were explicit about it (if you read the docs), it probably was a bad decision. This has been changed, thankfully.

As far as maintenance, it's unreasonable to expect that you could have a zero maintenance configuration. What other software does that? Your operating system doesn't. Your browser doesn't either. Nothing is immune to entropy.

Re: “MongoDB is dead. Long live Postgresql”

#133

Post by jeltz »

mikegioia wrote: post #85
endijs wrote: 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.

It has the benefits and ease of use of a json document store, it allows you to do SQL style where clauses, it takes about a minute to install and start using, there are a wide range of drivers available for many languages, and it has a simple javascript map/reduce. on the flip side, it implements database level locking, uses more disk/RAM than it probably should, and can start to give you headaches if you try to do a…

> to give you a real world example, we use mariadb for storing everything persistently. however, a lot of data like "number of teachers in school A" is aggregated and too difficult to run in real time when we render paged results. to get around that, we use mongo as a document store and use its SQL like querying to generate the paged search results. this lets us sort/filter on the data without having to do everything in SQL.

This use case should be possible to solve with the JSON type in PostgreSQL. The indexing in PostgreSQL is just as advanced in 9.3 and will be better than MongoDB in 9.4 if a couple of patches land.

Re: “MongoDB is dead. Long live Postgresql”

#135

Post by weixiyen »

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

Well duh, Mongo was designed to live on its own server as it tries to claim all of the free memory available. Putting it on the same server with Redis makes no sense.

The case that caused you sleepless nights does not apply to 99% of projects out there.

Re: “MongoDB is dead. Long live Postgresql”

#136

Post by antonmaju »

jwarkentin wrote: post #96
endijs wrote: 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.

Some things to consider: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...

This is a reply to Sarah Mei's post from Ayende Rahien http://ayende.com/blog/164483/re-why-you-should-never-use-mo...

Re: “MongoDB is dead. Long live Postgresql”

#137

Post by jeltz »

viraptor wrote: post #23
jcampbell1 wrote: post #18

Earlier quoted context omitted.

It is probably not as simple as "supports json now". Imagine if HN comments were stored as a JSON document: Client A: Read JSON. Client B: Read JSON. Client A: Append new comment to json document. Client B: Append new comment to json document. Client A: Save JSON Client B: Save JSON A's comment will get deleted. My understanding is that Mongo DB does have a way to append a record within a document, but Postgres does…

In that case you can (should) just "SELECT ... FOR UPDATE" in your transaction. This should prevent the issue. Client B will wait with the read until client A commits.

I am pretty sure that just running UPDATE is enough. If an UPDATE happens to get stuck waiting for a lock it is re-evaluated.

EDIT: Found where it is explained in the documentation. I do not see why this should not also apply to JSON.

http://www.postgresql.org/docs/9.3/static/transaction-iso.ht...

Re: “MongoDB is dead. Long live Postgresql”

#138

Post by jeltz »

lucisferre wrote: post #38
jcampbell1 wrote: post #18

Earlier quoted context omitted.

It is probably not as simple as "supports json now". Imagine if HN comments were stored as a JSON document: Client A: Read JSON. Client B: Read JSON. Client A: Append new comment to json document. Client B: Append new comment to json document. Client A: Save JSON Client B: Save JSON A's comment will get deleted. My understanding is that Mongo DB does have a way to append a record within a document, but Postgres does…

Mongo also doesn't have a concept of a transaction so it needs these types of atomic update mechanisms in order to be able to do much of anything sanely. This isn't a problem with SQL which has ACID. I'm not saying that's always the right thing or a good thing, just that your example and conclusion isn't technically correct. Mongo's update capabilities are not more sophisticated but are necessarily different. That be…

> That being stated, I'll agree that similar mechanisms for the JSON fields would make sense for Postgres to consider in the future.

I think they are working on adding modification functions for hstore right now, and the plan is to also add them to JSON once that is done.

You could easily implement your own such functions right now, since PostgreSQL already support atomic modifications in of columns with UPDATE with no overwriting. This statement is safe to use to increment a counter.

  UPDATE c SET counter = counter + 1 WHERE id = 42;
And since that is the case this should also be safe.

  UPDATE c SET data = my_json_array_append(data, 7) WHERE id = 42;
There is nothing magical about "+".

Re: “MongoDB is dead. Long live Postgresql”

#139

Post by jeltz »

AlisdairO wrote: post #32
viraptor wrote: post #23

Earlier quoted context omitted.

In that case you can (should) just "SELECT ... FOR UPDATE" in your transaction. This should prevent the issue. Client B will wait with the read until client A commits.

Or you can use serialisable transaction isolation and retry on conflict.

For the simple cases you do not even need that.

Re: “MongoDB is dead. Long live Postgresql”

#140

Post by jeffdavis »

functional_test wrote: post #118
jeffdavis wrote: post #43

Earlier quoted context omitted.

> They should be doing compactions and are not. https://jira.mongodb.org/browse/SERVER-11763 It looks like compaction is an offline process. That really puts the user between a rock and a hard place.

In a proper production environment, you just compact each slave one at a time because you have a replica set rather than a single instance. Of course, if you aren't replicating your business's production database, you have a whole world of problems.

Good point, but that would make me a little nervous. What happens if the compaction takes a while and the replica gets far behind? And wouldn't the compaction time just keep getting longer and longer as data grows?

Can you repartition the data online to keep the cleanup work bounded?

Post reply on HN