What I get from these slides is that MongoDB has better average performance (when both using indexes or doing full scans) compared to all schemaless PostgreSQL options.
PostgreSQL as Schemaless Database [pdf]
41–50 of 90 posts
Re: PostgreSQL as Schemaless Database [pdf]
#42would it be possible to build an extension to expose a mongo compatible interface in postgres - essentially being able to use all the ORM/code built around mongo for postgres, seamlessly.
Yes, but why bother? There are already so many good SQL clients out there, like SQLAlchemy.
there are many apps built around mongodb that it would be interesting to do a drop-in swap with postgres (assuming protocol compatibility).
hell, ill personally pay a lot to have a mysql compliant interface just for WordPress!
Re: PostgreSQL as Schemaless Database [pdf]
#43Where is taligent when we need him? MongoDB is pretty impressive considering its age to the market, but I'd still go with the relational version of PostgreSQL anyday. Not because of the benchmarks, but in general, most use-cases are covered well enough by our relational db's like MySQL and PostgreSQL. The most expensive mistake one could make is using a NoSQL db where an SQL db fits perfectly. I admittedly made this…
Why do you need me ? I am just that crazy troll who believes that no database is perfect for all use cases and that making blind generalisations like "all NoSQL is bad" is stupid. Especially since MongoDB is as different from Cassandra or Riak as it is from Spanner as that is from the other 120+ odd NoSQL databases.
And if benchmarks impress you I suggest you take a look at Cassandra sometime.
http://techblog.netflix.com/2011/11/benchmarking-cassandra-s...
Re: PostgreSQL as Schemaless Database [pdf]
#44I want to admit that conclusion in presentation can be interpreted vise versa: MongoDB almost is fast as PostgreSQL. Also, notice that comparsion was done with Mongo 2.2, in 2.4 JS engine was changed to V8, so there is a lot of speed improvements. And compare PG have 18 years of development vs 5 of MongoDB. So what I want to say? Difference is not so big after all.
PostgreSQL hasn't spent 18 years pitching itself as a pure performance play, though. It started as a research project into the object-relational model and was adapted to be a safe and featuresome database first and performant second. Mongo's performance will converge downwards as people demand more features and safety guarantees. If however you want the original premise -- memory-only, schemaless, auto-sharded docume…
"1. overestimate the size of your data, (especially since relational models by design squeeze out all duplicated statements of data)"
Of course, this is opt-in in a SQL world, more's the pity. I've seen some nightmarish ActiveRecord spawned Postgres monstrosities.
I wonder how much of the attraction of schema-less DBs comes from the lack of friction between the largely guarantee-free idea of data storage precipitated by Rails misfeatures -- there's much less distance between a MySQL or Postgres database as "designed" by ActiveRecord and a NoSQL instance. Having already opted out of your database's particular guarantees, there's very little keeping you there.
Re: PostgreSQL as Schemaless Database [pdf]
#45Where is taligent when we need him? MongoDB is pretty impressive considering its age to the market, but I'd still go with the relational version of PostgreSQL anyday. Not because of the benchmarks, but in general, most use-cases are covered well enough by our relational db's like MySQL and PostgreSQL. The most expensive mistake one could make is using a NoSQL db where an SQL db fits perfectly. I admittedly made this…
Why do you need me ? I am just that crazy troll who believes that no database is perfect for all use cases and that making blind generalisations like "all NoSQL is bad" is stupid. Especially since MongoDB is as different from Cassandra or Riak as it is from Spanner as that is from the other 120+ odd NoSQL databases. And if benchmarks impress you I suggest you take a look at Cassandra sometime. http://techblog.netflix…
I only tagged you because you seem to have experience running Mongodb in production (as claimed by you in one of the previous threads) and I honestly wanted your feedback about this. Also I was curious to see if you would evaluate this nifty PostgreSQL feature :)
Re: PostgreSQL as Schemaless Database [pdf]
#46I am always wondering why no-sql has better performance than SQL if we have same simple use case (no join etc.). If the data is well structured and no join is needed, can I assume that relational database should have better performance than no-SQL?
Depends what you mean by "NoSQL". MongoDB is pretty terrible overall, so don't even bother. Systems like Dynamo/Riak/Cassandra sacrifice consistency (most of the time) for performance, largely because a distributed setup (sharding in particular) is easier when you don't guarantee consistency. Note that none of them sacrifice durability. It is possible to have a distributed and consistent database, but you either have…
Thanks for your reply.
But I have one more question, if I need to manage bank account, then the database must be consistent. Lets say that I just need to keep balance and social security number for the account, and only need to query the balance. Can No-SQL like redis have better performance than relational database? (assume same on logs and transactions).
Re: PostgreSQL as Schemaless Database [pdf]
#47Where is taligent when we need him? MongoDB is pretty impressive considering its age to the market, but I'd still go with the relational version of PostgreSQL anyday. Not because of the benchmarks, but in general, most use-cases are covered well enough by our relational db's like MySQL and PostgreSQL. The most expensive mistake one could make is using a NoSQL db where an SQL db fits perfectly. I admittedly made this…
Why do you need me ? I am just that crazy troll who believes that no database is perfect for all use cases and that making blind generalisations like "all NoSQL is bad" is stupid. Especially since MongoDB is as different from Cassandra or Riak as it is from Spanner as that is from the other 120+ odd NoSQL databases. And if benchmarks impress you I suggest you take a look at Cassandra sometime. http://techblog.netflix…
I keep hearing Cassandra touted as fast, but I just don't see it. Instacluster brags about 17ms at the 99th percentile being fast, but where I come from that gets you thrown out of the running.[1] The Netflix benchmark linked above sees 10,000 ops/sec/node. Again, not impressive.
Skip to slide 22 of this comparative benchmark with Couchbase Server[2] and you'll see that I don't want to make this a speed contest, as there are a lot of good things about Cassandra. It just strikes me as odd that people sell Cassandra based on low latency. If you want consistent high-performance, don't use a database that runs on a language virtual machine. There are lots of great reasons to use Cassandra, standout benchmarks aren't one of them.
[1] https://www.instaclustr.com/solution#tco [2] http://www.slideshare.net/renatko/couchbase-performance-benc...
Re: PostgreSQL as Schemaless Database [pdf]
#48Damn. The "XML. It seemed a good idea at the time" slide caused me to spray coffee on my laptop.
See also "XML literals as a native syntax in Scala."
Re: PostgreSQL as Schemaless Database [pdf]
#49So, the problem that I have with PostgreSQL isn't that it doesn't have every datastore under the sun, but rather the lack of automated distribution, and fault-tolerance. This is not a hard thing to build though (continue reading please). I don't mean that it's an easy task, but that the semantics by which you may be able to build a fault-tolerant, distributed database on top of Postgresql are pretty straightforward.…
PostgreSQL today has synchronous and asynchronous master/slave replication built in. The dev team is working on master/master replication (or peer-to-peer, as you called it).
Re: PostgreSQL as Schemaless Database [pdf]
#50So, the problem that I have with PostgreSQL isn't that it doesn't have every datastore under the sun, but rather the lack of automated distribution, and fault-tolerance. This is not a hard thing to build though (continue reading please). I don't mean that it's an easy task, but that the semantics by which you may be able to build a fault-tolerant, distributed database on top of Postgresql are pretty straightforward.…
Hot Standby in postgres is pretty damn good for replication (like you said making failover occur properly takes a little bit of effort but its not too hard). Also pgpool2 helps a lot with partitioning and parallel queries. For a relational db, postgres does a pretty good job at distribution and fault tolerance.
Postgres won't let you perform any sufficiently long (read-only) queries on slaves. For example, I was unable to run pg_dumpall on a slave to have DB snapshots.
This is [well-explained](http://www.postgresql.org/message-id/201102272005.00234.jens...), but still inconvenient. This way, slaves are only useful for failover and possibly offloading very short read-only transactions, which is pretty limited.