5 ms·
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 sup
by yxhuvud 15y ago
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.
- deleted 15y ago[deleted]
- derekorgan 15y agoprobably 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.
- spudlyo 15y agoWe 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.
- trimbo 15y agoExcept they didn't choose mysql -- they chose Percona. Bonus of going with Percona is that in the process you get a fantastic company to back you up.
- moe 15y agoA "fantastic" company and a crappy database. Sounds like a questionable set of priorities.
- JoachimSchipper 15y agoI don't like MySQL either, but they're basically using it as a networked hash table. It's not so bad that it can't do that.
- spudlyo 15y agoThis 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.
- papsosouid 15y agoWhy 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".
- spudlyo 15y agoPostgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. Both of those statements are not accurate, but hey, what's it matter? Without benchmarks we're both talking out our ass anyway.
- moe 15y agoThe postgres part of the statement is accurate; http://rhaas.blogspot.de/2012/04/did-i-say-32-cores-how-about-64.html http://rhaas.blogspot.de/2012/04/did-i-say-32-cores-how-abou...
- spudlyo 15y agoNo, 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. http://rhaas.blogspot.com/2011/07/read-scaling-out-to-32-cores.html http://rhaas.blogspot.com/2011/07/read-scaling-out-to-32-cor...
- scubaguy 15y agoThe 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.