Live data from Hacker News

Learn to stop using shiny new things and love MySQL

engineering.pinterest.com

51–60 of 64 posts

Re: Learn to stop using shiny new things and love MySQL

#51
post #30

Earlier quoted context omitted.

I don't know why anyone in 2015 would pick mysql when postgres is an option. Live postgres. So nice to work with. It's json support is amazing too

Depends on your data. Sometimes (particularly when you have only 1-3 tables) MySQL is much faster and you have to go out of your way writing stored procedures to make Postgres compete. Example: select COUNT(1), status FROM some_table GROUP BY status ORDER BY status; -- Postgres 10x slower. Also, mysql CLI is IMO much nicer than the postgres version. Better and faster autocompletes.

Regarding CLI: mycli and pgcli are both much nicer than the built in alternatives.

Re: Learn to stop using shiny new things and love MySQL

#53
post #46
post #20

Earlier quoted context omitted.

I agree. MySQL has been one problem after another. Postgres isn't perfect either, but it is constantly improving and normally does the right thing. The idea of Postgres being a "shiny new toy" is... an interesting viewpoint.

> MySQL has been one problem after another. Please elaborate. MySQL/MaraiaDB can be pretty relaxed when it comes to SQL standards (which you can disable/tweak), but I've yet to have data loss or data corruption. And speaking from experience - the system would be at it's knees and MySQL would happily do it's best to answer queries. I'm not saying Postgres isn't stable (haven't really used it) - I'm just rather suspici…

Same here. I've been a MySQL DBA for over 10 years and I've never had data loss or corruption even with power supplies dying and servers shutting down completely.

I've also used PG in quite a few projects and I can't say I find it better or faster at least for my usage. If anything it's more difficult to manage, there are way less decent tools to monitor, profiling is a PIA and those backslash commands just drive me nuts. I hate stuff like "\dt".

Re: Learn to stop using shiny new things and love MySQL

#55
post #5

I agree, I've found through painful experience that the shiny and new, while incredibly fun, tends to cost more than it's worth. With that said, if you're going to take the prudent route and use an established database platform, why in the name of all that is holy would you pick MySQL over Postgres? Granted, I am rather biased, but I do have extensive experience using both in anger. Every time I have to use MySQL I w…

The most scaled websites are written on PHP/MySQL today. Facebook, Wikipedia, Tumblr, Wordpress, Baidu, Yahoo...

I know it doesn't look cool to defend the popular technology, but it's hard to do for now.

(Hope Rust will crush on web performance so I can hipster around about it :)

Re: Learn to stop using shiny new things and love MySQL

#56
post #55
post #5

I agree, I've found through painful experience that the shiny and new, while incredibly fun, tends to cost more than it's worth. With that said, if you're going to take the prudent route and use an established database platform, why in the name of all that is holy would you pick MySQL over Postgres? Granted, I am rather biased, but I do have extensive experience using both in anger. Every time I have to use MySQL I w…

The most scaled websites are written on PHP/MySQL today. Facebook, Wikipedia, Tumblr, Wordpress, Baidu, Yahoo... I know it doesn't look cool to defend the popular technology, but it's hard to do for now. (Hope Rust will crush on web performance so I can hipster around about it :)

I have a friend at Wikipedia who was looking into writing some their PHP extensions in Rust, so hipster away. :P

Re: Learn to stop using shiny new things and love MySQL

#57
post #30

Earlier quoted context omitted.

I don't know why anyone in 2015 would pick mysql when postgres is an option. Live postgres. So nice to work with. It's json support is amazing too

Depends on your data. Sometimes (particularly when you have only 1-3 tables) MySQL is much faster and you have to go out of your way writing stored procedures to make Postgres compete. Example: select COUNT(1), status FROM some_table GROUP BY status ORDER BY status; -- Postgres 10x slower. Also, mysql CLI is IMO much nicer than the postgres version. Better and faster autocompletes.

I'd like to see your full setup for your claim about 10x slower, because I suspect you're doing something wrong.

Re: Learn to stop using shiny new things and love MySQL

#58
post #40
post #24

Earlier quoted context omitted.

MySQL is popular because it's easy to use (in the same sense as PHP), easy to setup, and has a lot of tutorials written for it. Also speed used to be a pretty big factor, but that was only because MyISAM took shortcuts with data consistency. If you care about your data and would rather not deal with the many problems MySQL inevitably brings, then Postgres is the better option. I can't say I've seen many compelling re…

That may be why MySQL is popular for small installations, but that's not why it's popular with companies like Facebook, Google, Twitter, and Pinterest who run replicated clusters that number in the thousands. It's popular at scale because unlike Postgres, it has replication that is well understood, is reliable, and isn't a massive pain in the ass to operate.

Please point me to the well-understood, reliable replication solution for MySQL (I'll agree about pain in the ass to operate re: Postgres, but you might want to check out aphyr's recent posts).

Re: Learn to stop using shiny new things and love MySQL

#59

Earlier quoted context omitted.

mySQL has more baked in solutions for replication that don't require a support contract or a convoluted mess of choosing between half a dozen half baked options for higher availability? Honestly, it's the one area that I feel that open-source PostgreSQL is really lacking, and that is a good replication/automagic-failover story. I think MS-SQL is probably the best (but almost as expensive as EnterpriseDB support contr…

As someone who took a stab at automating slony deployment and configuration, I have to agree that the replication situation is not quite there yet. There are maybe 2-3 examples online on how to use some of those tools, and maybe half a dozen people who actually would be able to answer questions about them. Betting your business's scaling future on that kind of tooling is terrifying. Would be great to have both out of…

You can go a long way with read-only replication, as long as you have a good failover strategy for writes before you need sharding... The only time you really need sharding is once either your reads or writes require more than a single system in you cluster could keep up with in terms of requests.

That said, using something like RethinkDB (not sql) from the start isn't a bad thing... And depending on your needs Cassandra, ElasticSearch and others are viable options... beyond that there's no need to stick with a single database for different types of data. It should be a case by case basis.

As to the comments about Postgres replciation/failover, it's a pretty sad state imho for an otherwise very respectible database.

Re: Learn to stop using shiny new things and love MySQL

#60
post #30

Earlier quoted context omitted.

Depends on your data. Sometimes (particularly when you have only 1-3 tables) MySQL is much faster and you have to go out of your way writing stored procedures to make Postgres compete. Example: select COUNT(1), status FROM some_table GROUP BY status ORDER BY status; -- Postgres 10x slower. Also, mysql CLI is IMO much nicer than the postgres version. Better and faster autocompletes.

I'd like to see your full setup for your claim about 10x slower, because I suspect you're doing something wrong.

Sure, here's the pastebin of the postgres one: http://pastebin.com/Phc8KnYU

I thought I was doing something wrong, so I asked on SO:

http://stackoverflow.com/questions/32755348/group-by-count-q...

This is a very simple example, but I always run into major performance issues with Postgres. Some of them are my fault, from not knowing that array aggregation is a slow operation.

MySQL advantages for me are that there is an actual UPSERT operation (an inferior version of which might be added to Postgres 9.5), that the CLI is miles ahead, and that it's much faster for a small number of tables with a lot of data and with non-complex operations.

Post reply on HN