What really don't understand is why they chose mysql over postgresql - postgres already have hstore as a column type to store schemaless data. This includes support for indexes on the field.
probably because as they stated they are familar with MySQL. After getting hurt trying out a new technology to them it makes sense they go back to something they know. Will probably lead to more uptime which is what they want.
We were excited to try a NoSQL db, having spent too many years using MySQL in ways that the designers of relational databases never imagined.
...
Given that we had experience with MySQL and knew it was adequate for our needs, it was hard to justify any other choice.
Agreed. It seems pretty clear from reading the article why they went with MySQL, which you wouldn't know from all of the Postgres butthurt in the comments.
The author mentioned one of the reasons for choose MySQL is that they are familiar with MySQL. They could've went with PostgreSQL and EnterpriseDB, also a great company. It's not like you can't get commercial support with PostgreSQL.
This is InnoDB's sweet spot really -- a mostly read-only in memory data set where the lookups are done primarily by PK. MySQL 5.5 can scale this kind of workload to 32 cores.
I'm pretty sure given this kind of workload MySQL will outperform PostgreSQL handily.
And PostgreSQL 9.2 will be able to scale this workload linearly to 64 cores. So while MySQL may or may not win it will certainly not "outperform PostgreSQL handily".
The key is that PostgreSQL 9.2 will be able to handle a 64 core workload, but current released versions of PG do not.
The fact is current versions of PG are unable to use more than 60% CPU on a 24 core machine. Do you know anyone who uses a dev version of an RDBMS in production?
I believe that MySQL 5.5 scales to 32 cores but not linearly, while PostgreSQL 9.1 caps at 24 cores. As I said in my last comment: I do not doubt much that MySQL would beat PostgreSQL 9.1, but it wont beat it "handily".
Why do you say this like it is impressive? Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. It is very unlikely that mysql will be able to match postgresql for this workload, much less outperform it "handily".
No, it's not. The referenced article is talking about Postgres 9.2devel. Version 9.2 isn't out yet, and even if it was, it still wouldn't be true due to the clause "and has done so for a few years".
The lock manager bottlenecks that stopped PG from using more than 60% of the cpu power on a 24 core box were discovered a little less than a year ago.
You are making assumptions about one scenario based on limitations encountered in a very different scenario. The problems that occur around 24 cores occur on benchmarks consisting entirely of select statements against a single table. As I said, postgresql has scaled to 32 cores for real workloads for a few years. Real workloads have more than one table.
Your MySQL example isn't exactly relevant. It was in 2007, yet you said "MySQL still tanks at 8 cores". Furthermore it was on FreeBSD, with a flawed libpthread.
In terms of "real" workloads, I'm not going to bother getting into it, as this is quickly devolving in to a true Scotsman argument.
Instead of arguing pointlessly about it, maybe our energy would be better spent publishing some benchmarks.
