Slashdot Mirror
PostgreSQL Outperforms MongoDB In New Round of Tests
New submitter RaDag writes: PostgreSQL outperformed MongoDB, the leading document database and NoSQL-only solution provider, on larger workloads than initial performance benchmarks. Performance benchmarks conducted by EnterpriseDB, which released the framework for public scrutiny on GitHub, showed PostgreSQL outperformed MongoDB in selecting, loading and inserting complex document data in key workloads involving 50 million records. This gives developers the freedom to combine structured and unstructured data in a single database with ACID compliance and relational capabilities.
Because Postgres isn't web-scale. I want web-scale.
I am confused. If they are testing the performance of ACID and BASE database systems, why did they use a data load that can easily fit on a single computer? The data size for both databases was under 150 GB which can easily sit on a single hard drive let alone a single server. Why would a BASE database have any edge over an ACID one for a data set that does not require distribution between multiple servers?
It is still important to see how much faster a more established DBMS is than a relative newcomer for smaller loads, but I still feel this comparison is a bit lacking.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
I tried MongoDB and I even tried to like it. I do love NoSQL but what I came to realize was that MongoDB was trying to tell me how to solve my problems instead of just storing my damned data.
But the real problem with MongoDB was that nearly everything, while appearing simple, required a google search to figure out how to do it. A mark of a very well designed API is that you soon start guessing the commands and your guesses are really close or right on. But with MongoDB I found that nothing really made sense. Only after carefully crafted "debate team" arguments could any unusual aspect of MongoDB defend itself. Whereas redis is the opposite, it just works. Or even simpler systems like Memcache, that couldn't be simpler, when read the API for either of those they just made sense. There is no layer upon layer upon layer of complexity. It is data goes in, and data comes out.
In fact redis would be a good example of ease of use mixed with advanced capabilities. The basic commands are things like get, append, save, while more advanced commands are more esoteric such as PEXPIREAT which has to do with timestamp expiries. So you can happily use redis like a simple minded fool and it is wonderful. Or you can dig in deeper and only mildly shake your head at some of the command names. But with MongoDB it is just a pain in the ass from the first moment you truly have even vaguely complicated data.
But back to PostgresSQL. The JSON related features are mildly complex but appear to be solving the most common problems. Also by using PostgresSQL it solves the entire debate of relational vs NoSQL. Use PostgresSQL and you can just do both without giving it a second thought. And I for one can certainly say that I have data that demands NoSQL and I have other data that demands relational; all in the same project. But oddly enough the technique that I use is MariaDB for the relational and redis for everything else. This is ideal for me as the relational data is very simple and won't need to scale much whereas the redis stuff needs to run at rocket speeds and will be the first to scale to many machines.
But as for MongoDB, it has been deleted from all machines, development and deployment and will never be revisited regardless of this weeks propaganda.
I've done research against these database programs, and this is really really old news for anyone who has done testing. If you have a single machine, then Oracle is the best performing database, followed by Postgres. When you need more than 4 dedicated servers hosting a database, then mongo can handle about 180% of the volume that oracle can, and about 220% the volume of postgres, and about 110% the volume of Casandra.
As soon as you need more than one machine to host your database (which usually happens around 1000 active users on your website at any given time, depending on your application), consider switching off of an SQL database.
Anything but read a computer science textbook
Can PostgreSQL do replication? Not really.
That's news to me, I guess the data on our read servers just magically appear and what more magically appear to be the same data we need there.
... because of the way MongoDB actually stores records and parses them. It is more or less a simple tree or linked list, and hence doing almost anything involves decending branches to the leaves. This is horrendously inefficient in many contexts, while still being perfectly lovely in others. Just doing a match, though, can involve a non-polynomial time search. Maybe they've improved this from when I was trying to use Mongo to drive modelling, but I doubt it as it would have involved substantially changing the way the data is actually stored and dereferenced. I had to cheat substantially in order to get anything like decent performance, and any of the SQLs outperformed it handily.
Note well that it was strictly a scaling issue. For small trees and DBs, it probably works well enough. For large DBs with millions of records and substantial structure, it is like molasses. Only worse.
rgb
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.
I've worked extensively on both kinds of systems over the past decade. Under a particular workload that is exactly what an RDBMS is designed for, an RDBMS has the best performance? Wow, who would have bet on that one?
Then again, I've had workloads (my go-to example is writing several billion records in a matter of hours for statistical analysis, with live intermediate results) where a NoSQL solution had the best performance.
NoSQL isn't some rebellion against traditional databases. Engineering isn't a contest. Rather, NoSQL, column-stores, distributed warehousing, or any other term you'd like to throw out all just point to an additional option for how to manage your data. Pick the right choice for your project, and use it. Don't worry about "web-scale" or "ACID compliance" talking points unless your project needs them. For the past few decades, we've been forced into the assumption that data must perfectly normalized, arranged in tables, and must be queried as relations. For some projects, massaging the data into that form will damage your performance far more than your database engine ever will, so a different engine makes a better choice.
Stop listening to hype, deserved or not, and use the right tool for the job.
You do not have a moral or legal right to do absolutely anything you want.
"Engineering isn't a contest."
But...but...I have a hammer. I KNOW how to use a hammer. A hammer is the best! FUCK YOU SCREW! TAKE THAT SCREW! Job complete!