Earlier quoted context omitted.
The nice thing about using an RDBMS with JSON support, rather than a NoSQL solution, is that you can store all the fixed-schema stuff in column as usual, and benefit from the performance, consistency, ease of joins and so on with that, but you can also store your JSON documents alongside that data in the same table, efficiently indexed.
Yes, but what happens if your JSON data size grows so large that it can't fit on a single machine? Multi-master replication or sharding is a terrible pain in any RDBMS (at least according to my research and trials).
PostgreSQL Outperforms MongoDB in New Round of Tests
81–90 of 171 posts
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#82Earlier quoted context omitted.
The nice thing about using an RDBMS with JSON support, rather than a NoSQL solution, is that you can store all the fixed-schema stuff in column as usual, and benefit from the performance, consistency, ease of joins and so on with that, but you can also store your JSON documents alongside that data in the same table, efficiently indexed.
Yes, but what happens if your JSON data size grows so large that it can't fit on a single machine? Multi-master replication or sharding is a terrible pain in any RDBMS (at least according to my research and trials).
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#83MongoDB 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
#84Earlier quoted context omitted.
I didn't mean "view" in the sense of "database view" but rather in the sense of "page view". All data displayed on a page with multiple types of documents was returned in a single query. That's certainly doable in pg, but requires a lot of hacks and it's not efficient. Or you can use hstore and basically use pg as a nosql db.
Ah, that makes sense, though couldn't you solve this by something like creating a table called 'pages' and storing the materialized JSON (the same that mongo would generate) in the table?
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#85I'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
#86Since when MongoDB is considered as a database comparable with PostgreSQL?)
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#87Only 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?
http://www.postgresql.org/message-id/534C4225.6020600@agliod...
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#88Earlier quoted context omitted.
Yes, but what happens if your JSON data size grows so large that it can't fit on a single machine? Multi-master replication or sharding is a terrible pain in any RDBMS (at least according to my research and trials).
Sure, but how many people genuinely have data that big?
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#89Earlier quoted context omitted.
Yes, but what happens if your JSON data size grows so large that it can't fit on a single machine? Multi-master replication or sharding is a terrible pain in any RDBMS (at least according to my research and trials).
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…
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#90Earlier quoted context omitted.
once you start page faulting and hitting spinning disk it's game over for any database's performance, postgres included.
... but that usually doesn't mean you have to have your full data set in memory, only the hot parts. And even if so, one or two ~10 ms seeks during a query aren't that terrible.
a few seeks aren't terrible for small/medium applications, but when you're asking for thousands of queries a second any disk access is bad news.