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

51–60 of 171 posts

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#51

Post by danohuiginn »

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 pretty specialised, and I'd rather use a relational db for most things.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#53

Post by gozzoo »

Xylakant wrote: post #38
aikah wrote: post #32

Earlier quoted context omitted.

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

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

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#54

Post by yangyang »

bshimmin wrote: post #39

I'm sort of struggling to imagine anyone really using MongoDB at all in a couple of years. But then again, plenty of shops still use MySQL (and one of my clients uses DB2...).

What's wrong with DB2? I know it's commercial and a bit arcane in areas, but it's a far more powerful database than MySQL.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#55

Post by yangyang »

RyanZAG wrote: post #24
jedisct1 wrote: post #9

How does it compare to TokuMX? I am a huge fan of PostgreSQL, but in order to avoid having to rewrite an application designed for Mongo, I tried TokuMX and was pleasantly surprised by its performance.

Going off [1] it looks like TokuMX is a similar multiple faster than Mongo than Postgre is from Mongo, so I'd guess Postgre and Toku would be fairly similar speed wise. Obviously depending on your data and search patterns one may still be significantly faster than the other as the usual caveat. [1] http://www.databasejournal.com/sqletc/tokumx-compared-to-mon...

Nitpick: PostgreSQL, or Postgres for short. Never "Postgre".

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#56

Post by nl »

mm_throwaway wrote: post #33
xtrumanx wrote: post #4

Only problem I have with JSON on Postgres is you can't update a property of a JSON object like so: update table set jsonCol->propertyA = 42; You need to write an extension for that. Easiest to do so using Python but sadly Heroku doesn't support python on postgres since its unsafe.

Please correct me if I'm wrong, but isn't updating JSON properties one the big improvements of the soon-to-be-released 9.4 version?

Yes this is true, and much needed.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#57

Post by lgas »

gozzoo wrote: post #53
Xylakant wrote: post #38

Earlier quoted context omitted.

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

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

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#58

Post by sergiosgc »

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 see where you are coming from, and my opinion is mostly the same. However, I can see a use case for relaxing constraints in a distributed scenario, as described by the CAP theorem.

In a distributed scenario, when a partition event occurs, relational databases opt for consistency, whereas nosql opts for availability. This is formally correct behaviour by relational dbs, but comes with a cost. The cost is a serial performance component, that can't be parallelized. Nosql DBs (most of them), in this scenario, go for availability, and may thus eschew some consistency guarantee tasks, with a cost in data consistency and an advantage in parallel performance.

The trick, as ever, is to use each tool in its function. Nosql and relational dbs are wholly different tools, for wholly different problem classes. Using nosql where consistency is paramount irks me to no end, and that is the case 80% of the time I see people using nosql. On the other hand, in specific cases, nosql DBs are a new useful tool in my arsenal.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#59

Post by brey »

tszming wrote: post #44

MongoDB work well ONLY if indexes (and working set) fit in the memory. What are the indexes size in the benchmark? (I doubt as I see you are running a 145GB database on a 32GB instance) http://docs.mongodb.org/manual/tutorial/ensure-indexes-fit-r...

once you start page faulting and hitting spinning disk it's game over for any database's performance, postgres included.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#60

Post by JonnieCache »

bencollier49 wrote: post #34
xtrumanx wrote: post #4

Only problem I have with JSON on Postgres is you can't update a property of a JSON object like so: update table set jsonCol->propertyA = 42; You need to write an extension for that. Easiest to do so using Python but sadly Heroku doesn't support python on postgres since its unsafe.

Just tried to google this, but couldn't find anything. Why is Python on Postgres considered unsafe?

Just because its a programming language. It can write to disk, open sockets, etc.

"As of PostgreSQL 7.4, PL/Python is only available as an "untrusted" language, meaning it does not offer any way of restricting what users can do in it. It has therefore been renamed to plpythonu. The trusted variant plpython might become available again in future, if a new secure execution mechanism is developed in Python. The writer of a function in untrusted PL/Python must take care that the function cannot be used to do anything unwanted, since it will be able to do anything that could be done by a user logged in as the database administrator. Only superusers can create functions in untrusted languages such as plpythonu."

http://www.postgresql.org/docs/current/static/plpython.html

Incidentally I've been merging my json in perl. It's automatically built into postgres, and the Hash::Merge library with it's configurable behaviour is very handy. Still, looking forward to not doing that. 9.4 is coming before xmas, right?

Post reply on HN