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

101–110 of 171 posts

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#101

Post by pjmlp »

dschiptsov wrote: post #37
pjmlp wrote: post #12

Earlier quoted context omitted.

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

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.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#102

Post by yangyang »

craigching wrote: post #93
tete wrote: post #65

Did I miss something? MongoDB was never ever faster than Postgres. That's nothing new. Most of these things are clear when one reads the MongoDB docs: MongoDB stores Metadata, (nearly) uncompressed on a per document basis, so of course it uses way more diskspace. It doesn't store the data in any efficient way either. Also it's pretty much unoptimized, compared to Postgres which has been around for a really long time…

> it's a charm to scale (in many different kinds), compared to PostgreSQL. If PostgreSQL had something built in(!) ... This! A million times! I agree 100% that Postgresql is better than MongoDB in every way except in ease of replication (that's really my only need) for HA. We needed an embedded database in our product and I wanted so bad to use Postgres, but we needed HA and we needed our customers to be able to set…

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 on the aforementioned logical changeset support in 9.4.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#103

Post by Shorel »

krylon wrote: post #49

I never really "got" the new wave of NoSQL databases. Mongo seemed to be the one I could most easily wrap my head around, but still. I was never sure, though, if that meant I had never faced a problem suitable for one of these DBMSs or if my mind is just so warped by years of using relational engines (mostly Postgres, or SQLite for simple projects) that I could not think of modeling my data any other way. Recently th…

> I never really "got" the new wave of NoSQL databases.

It's easy: Overzealous DBAs who insist in normalization at all costs.

A new technology allows developers to try new approaches to the challenges, by sidestepping those DBAs.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#104

Post by kennu »

yangyang wrote: post #102
craigching wrote: post #93

Earlier quoted context omitted.

> it's a charm to scale (in many different kinds), compared to PostgreSQL. If PostgreSQL had something built in(!) ... This! A million times! I agree 100% that Postgresql is better than MongoDB in every way except in ease of replication (that's really my only need) for HA. We needed an embedded database in our product and I wanted so bad to use Postgres, but we needed HA and we needed our customers to be able to set…

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 that it's really easy to set it up in 5 minutes.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#105

Post by krylon »

romanovcode wrote: post #63
krylon wrote: post #49

I never really "got" the new wave of NoSQL databases. Mongo seemed to be the one I could most easily wrap my head around, but still. I was never sure, though, if that meant I had never faced a problem suitable for one of these DBMSs or if my mind is just so warped by years of using relational engines (mostly Postgres, or SQLite for simple projects) that I could not think of modeling my data any other way. Recently th…

It is for storing huge number of data with dynamic keys. For example when site admin says "I want new archive that I can fill with items, items will have Id (automatically), Name (string), IsMale (bool)". He also want to do complex queries on this data as well. That's where NoSQL comes to help. And to answer why exactly MongoDb is so popular - it's because it has awesome driver support for every popular language. I d…

Thanks for the explanation.

Quite frankly, no application I have ever worked on has had to deal with "huge" amounts of data by any common definition (a couple of gigabytes at the most).

And like I did say, looking at our ERP system's database I am beginning to understand the appeal of a database without a fixed schema. Some of the tables have dozens of columns, with most of the rows being full of NULL values. So I do get that part, but no application I have ever worked on was like that.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#106

Post by marcosdumay »

Shorel wrote: post #103
krylon wrote: post #49

I never really "got" the new wave of NoSQL databases. Mongo seemed to be the one I could most easily wrap my head around, but still. I was never sure, though, if that meant I had never faced a problem suitable for one of these DBMSs or if my mind is just so warped by years of using relational engines (mostly Postgres, or SQLite for simple projects) that I could not think of modeling my data any other way. Recently th…

> I never really "got" the new wave of NoSQL databases. It's easy: Overzealous DBAs who insist in normalization at all costs. A new technology allows developers to try new approaches to the challenges, by sidestepping those DBAs.

So, a technological solution to a political problem.

Now I can understand where that people are coming from.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#107

Post by yangyang »

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 do have a point. PostgreSQL undoubtedly has many more knobs and do you do end up having to learn a fair bit to do stuff like replication.

I'd rather spend more time understanding things up-front and have a reliable solution rather than flick a switch and have something which initially works but I'm not too confident in. That's fine for initial development I suppose, but not in production.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#108

Post by rpedela »

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.

How many use cases really exceed a single, multi-terabyte machine? Your argument is true for any data type and format not just JSON. If you have more than a few terabytes then you have "big data" and most solutions, including Mongo, probably won't work.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#109

Post by yummyfajitas »

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…

I would suggest that if you've reached the point where you need streaming replication (rather than, say, a cron job uploading database dumps to s3), you've reached the point where you need to do your research.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#110

Post by gregwebs »

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 there is work underway to make it more competitive with MongoDB.

So now they are also releasing a jsonb (b for binary) storage format, which looks promising, but I can't find any information on exactly what its features are. I would love to actually see a benchmark comparing field updates, but this benchmark is not it.

MongoDB is a database with trade-offs, downsides, and more crappy edge cases then MySQL, but it does exist because at its core it allows data modeling that traditional SQL databases are lacking.

MongoDB has first class arrays rather than forcing you to do joins. It supports schema-less data, which is rarely useful, but when you need it can be very useful. It can do inserts and count increments very quickly (yes the write lock means you eventually have to put collections in separate databases), which is also useful for certain use cases.

Post reply on HN