bored, bored, bored....good luck trying to shard postgres! idiots
PostgreSQL Outperforms MongoDB in New Round of Tests
131–140 of 171 posts
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#132Only 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.
You can use PLV8 to do that in javascript on heroku.
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#133Earlier quoted context omitted.
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...
Table groups look rather like hierarchical databases [1], which were the norm before relational databases came along.
Do bear in mind that you'll never get MongoDB-style in-place updates in PostgreSQL, due to MVCC. You may save a round-trip with the entire JSON object once they implement update operators, though.
[1] http://en.wikipedia.org/wiki/Hierarchical_database_model
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#134Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#135I'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...).
Exactly! I can't imagine anyone using MongoDB at all in a couple of years either. Everything will be in Node! But then again, I am going to say the opposite of what I just said to hedge my bet and point out plenty of shops still use MySQL. No serious company like YouTube, Facebook, or until recently Google Ads would use it. I love sitting in my armchair and passing technical judgements without providing any technical…
The approach to comments link doesn't indicate I should avoid sarcasm. But if that's how it is going to be then maybe one of the moderators can add that there?
Link in question: https://news.ycombinator.com/newswelcome.html.
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#136Did 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…
The entire narrative behind MongoDB in the first chapters of its evangelism was performance, partly due to its document-oriented approach (things are quicker in some scenarios when you get rid of relations, and it was contrast against the many tables approach), which is something that you can only very recently do in pgsql, and partly due to implementation choices like the dangerous default lack of fsync. Early evang…
I wonder if Node.js will follow the same fate...get a nice dose of reality check.
It is mistakenly evangelized as also being faster, leaner, scalable, more concurrent than anything out there. Some clients would pay extra to redo CRUD using Node.js because it's "Asynchronous and We wanna Pay For Speed and Scalability".
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#137I 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 think people mix up three things: (1) Transactional model. Many NoSQL databases are non-ACID, but others are (Google's stores all have some transactional guarantees). Some databases try to gain efficiency by relaxing their transactional guarantees, some probably just didn't get around to implementing a proper transactional system yet. (2) Data model. The relational models can be overly restrictive as you cannot eas…
> ... contained, repeated elements in an object
Pardon me if I'm just sniping on the word "object" here, but if you think of your data as objects then you will find the relational model restrictive.
In my experience, objects are an application concept, closely coupled to an implementation. If you can conceive of your data in implementation-independent terms, i.e. as entities and relationships, then you can put a RDBMS to effective use.
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#138Did 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 depends on what your measuring. I work on a project that gained significant speed improvements moving to MongoDB simply due to packing and unpacking the data. MongoDB BSON serialization was way faster than the ORM when building up the data objects after fetching from the database. In our workload that operation actually dominated the workload not IO.
This article is interesting because Postgres document store options may make it competitive to us when compared to MongoDB.
Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#139Re: PostgreSQL Outperforms MongoDB in New Round of Tests
#140This 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.
Could you confirm that you can atomically update a single item inside a jsonb field without reading/writing all of the jsonb data? I know this is possible with hstore (but not 9.3's json type), but can not find a clear answer for jsonb in the documentation. Any pertinent links would be much appreciated!