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

PostgreSQL Outperforms MongoDB in New Round of Tests

blogs.enterprisedb.com

Post reply on HN
Print view View original

121–130 of 171 posts

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#121

Post by jacques_chester »

danohuiginn wrote: post #51
hnhipster wrote: post #42

This is very interesting. Around when MongoDB was quickly becoming the cool thing to do I'd ask people about why it is better than just storing things in Postgres. People would have answers that would be grammatically correct but would not make any sense. That being said, I find it weird that now it is cool to make fun of MongoDB. Some people on this thread have even said they want to know if a service is using Mongo…

yeah, mongodb has flipped from hype to hatred without much in between. The reason, I think, is that few people using it had a good sense of where the pain points would be. Many of us somehow imagined that because we didn't know where mongodb's limitations were, we wouldn't run into them. Cue frustration when you're bitten by some issue you didn't think about. I do believe there are good uses for it. But they are pret…

> yeah, mongodb has flipped from hype to hatred without much in between.

The hatred was always present, it's just that the hype has died down as the early adopters have (re)discovered the sharp corners in both architecture and implementation.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#122

Post by yangyang »

gregwebs wrote: post #110

This benchmark misses the entire point of MongoDB: that you can atomically update individual fields in the document. Thas has not been possible with Postgres json storage type. Instead, the entire JSON blob must be read out, modified, and inserted back in. This reality is well known to those that understand Postgres, which is why they have HStore. HStore is limited though (particularly to the size of the store), so t…

The improvements to hstore (primarily to make it hierarchical and add array support) ended up becoming jsonb.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#123

Post by nemothekid »

craigching wrote: post #94
Nitramp wrote: post #79

Earlier quoted context omitted.

Is MongoDB's distribution and scaling story really nicer? A cluster story that's easy to set up but then doesn't actually work (loses data, fails in potentially catastrophic ways) sounds not all that useful. http://aphyr.com/posts/284-call-me-maybe-mongodb

It depends on your workload, but MongoDB has worked extremely well for us, we've never lost data. I love aphyr's posts on databases, but you can't use them as a blanket for everything.

Just because you haven't had a failure yet, it doesn't make the test any less true.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#124

Post by vertex-four »

mikegioia wrote: post #89
vertex-four wrote: post #80

Earlier quoted context omitted.

At the end of 2013, Stack Overflow worked on one SQL server (plus a redis server for caching). The rest of Stack Exchange runs on another SQL server.[0] For the most part, for most projects, worrying about multi-master replication is going to be pointless. You can always put some data in a distributed K/V (or document) store and point to that from your SQL if you need to. [0] http://nickcraver.com/blog/2013/11/22/wha…

What I meant was a data-size that was too large for a machine. Adding arbitrarily large JSON to your table could expand the data-size to be too big for one machine, or even too big for block storage. Plus you might not want it all in block storage. My point is that an RDBMS can be better served storing the relational data alone with a separate DB Engine for the potentially massive JSON data.

You're storing exactly the same data whatever you're storing it in. The point is that there's rather few use cases where your primary database is going to be more than a few terabytes, which is usually easy to handle with a single machine + some caching. I pointed to Stack Overflow as an example of a large site which still manages to keep its entire database on one machine.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#125

Post by craigching »

nemothekid wrote: post #123
craigching wrote: post #94

Earlier quoted context omitted.

It depends on your workload, but MongoDB has worked extremely well for us, we've never lost data. I love aphyr's posts on databases, but you can't use them as a blanket for everything.

Just because you haven't had a failure yet , it doesn't make the test any less true.

Three years? Numerous customers? That's good enough for me so far.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#126

Post by craigching »

Twirrim wrote: post #118
kennu wrote: post #104

Earlier quoted context omitted.

I think your comment summarizes why this stuff so hard on traditional SQL; one doesn't even know where exactly to start. In MongoDB, you just turn on replication according to http://docs.mongodb.org/manual/replication/ , which means basically adding one directive to mongod.conf and typing in the IP addresses of the nodes. MongoDB handles everything else for you. I'm not claiming that it's better or reliabler, just th…

It only takes an hour or so to google and read up on what the different ways of replicating data are in PostgreSQL, their advantages and disadvantages. Are we really that scared of 'research'?

> Are we really that scared of 'research'?

You've missed the main point of why we use MongoDB. We use it embedded in our product and it's up to our customers to configure HA if they need it. Sure, we document the process for configuring it, but the simpler it is, the less likely a customer is going to have a problem with it.

I would agree with you if it were a database that we maintained in-house, yeah, it's certainly doable. But my main point is that this has to be done in the field at customers who are just trying to use our product.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#127

Post by craigching »

kennu wrote: post #104
yangyang wrote: post #102

Earlier quoted context omitted.

Streaming replication is really not hard to set up in PostgreSQL. It is cluster-level; if you want to replicate a single database you'll need to use a 3rd party solution like Slony or Burcado (logical replication built on features in 9.4 will improve this). 2ndQuadrant have developed Bi-Directional Replication for 9.4 ( http://2ndquadrant.com/en/resources/bdr/ , https://wiki.postgresql.org/wiki/BDR_User_Guide ) based…

I think your comment summarizes why this stuff so hard on traditional SQL; one doesn't even know where exactly to start. In MongoDB, you just turn on replication according to http://docs.mongodb.org/manual/replication/ , which means basically adding one directive to mongod.conf and typing in the IP addresses of the nodes. MongoDB handles everything else for you. I'm not claiming that it's better or reliabler, just th…

You are absolutely right, it is as simple as adding the replSet name to your configuration, rs.init(), rs.add() for each other host that will participate in the replica set. Exactly the point.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#128

Post by gregwebs »

yummyfajitas wrote: post #112
gregwebs wrote: post #110

This benchmark misses the entire point of MongoDB: that you can atomically update individual fields in the document. Thas has not been possible with Postgres json storage type. Instead, the entire JSON blob must be read out, modified, and inserted back in. This reality is well known to those that understand Postgres, which is why they have HStore. HStore is limited though (particularly to the size of the store), so t…

This is an excellent post. You've answered a question I've had for a while - are there any circumstances where MongoDB is the right tool for the job? You seem to be on point that Mongo is currently the best for frequent updates of JSON blobs. Thank you. I'll take issue with a couple of points, though. Postgres has arrays: http://www.postgresql.org/docs/9.3/static/arrays.html Rapid counting of increments can be done f…

It does have arrays, but they aren't first class to the same extent as MongoDB.

* A Postgres Array can end up being stored elsewhere, whereas in MongoDB an array will be contained within the document

* I am also not clear on what exactly can be stuck inside an array (In MongoDB it can be an object that contains more arrays) while maintaining first-class access and updates.

I would love to find more detailed information on these points, but with jsonb they may be moot now.

I will look into the increment issue in PostgreSQL more carefully. I just know that it wasn't feasible in MySQL when I was using it.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#129

Post by gregwebs »

yangyang wrote: post #122
gregwebs wrote: post #110

This benchmark misses the entire point of MongoDB: that you can atomically update individual fields in the document. Thas has not been possible with Postgres json storage type. Instead, the entire JSON blob must be read out, modified, and inserted back in. This reality is well known to those that understand Postgres, which is why they have HStore. HStore is limited though (particularly to the size of the store), so t…

The improvements to hstore (primarily to make it hierarchical and add array support) ended up becoming jsonb.

That is really exciting! I am going to take a serious look at jsonb and using Postgres now, although FoundationDB has caught my eye with its table group functionality: https://foundationdb.com/layers/sql/documentation/Concepts/t...

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#130

Post by larry_the_lover »

Argorak wrote: post #16
threeseed wrote: post #11

Earlier quoted context omitted.

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.

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

good luck sharding postgres - idiots
Post reply on HN