Live data from Hacker News

Learn to stop using shiny new things and love MySQL

engineering.pinterest.com

41–50 of 64 posts

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

#41

Earlier quoted context omitted.

You know what, about two weeks ago I was starting a new Rails hobby project, and I thought "all I've heard about for the past year is how everyone loves Postgres", and was about to throw it in there, when I saw a link to Google search trends comparing the two, and MySQL is still so far ahead: https://www.google.com/trends/explore#cmpt=q&q=mysql,+postgr... It's quite possible this is just due to people supporting exis…

Is google trends really how you should be choosing your stack?

Choose? I'd argue no. But inform your choice? Sure.

Looking at trends can help you:

- See how easy hiring people will be in the future.

- See the likelihood that your chosen framework will lose support.

- See the likelihood of third party support/addons/libraries/etc.

- How easy it will be to find help/tutorials/guides/etc.

But looking at it, to me, seems prudent.

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

#42
You have no idea how many developers I've wanted to hit in the testicles with a baseball bat for crying my ear off to use redis, mongo, etc... anything but mysql. Really you want to take our 99% relational data (billing/invoicing, crm, etc...) and put it in a key store? You're fucking retarded.

What I found is that I can browse the posts here in the AM and then by noon they will be asking me for whatever landed on the front page here. I just laugh and tell them to go back to work.

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

#43

As someone who's only briefly looked into Postgres, are there any disadvantages to going with it instead of MySQL? It seems (especially from the comments here) that Postgres is something to seriously consider in future projects, but I'm wondering if there are any reasons to stick with MySQL.

I've answered this question once before, and this is what I wrote. MySQL is battle tested and operationally sane to manage at scale; I'm talking specifically about replication.

I've been a DBA for thousands of MySQL hosts in production and just a handful of PostgreSQL clusters, so I'm not a PostgreSQL expert by any stretch. These PostgreSQL machines were also inherited from a company we acquired, so some of my negative impressions can likely be explained by them being set up poorly, which sadly seems to be the norm.

PostgreSQL's replication has evolved slowly over the years, and as a result it's idiosyncratic, complicated to get right, and hard to generalize about. There aren't a lot of great setup guides and tutorials on the subject either.

Postgres replication works by shipping WAL (transaction/redo) logs to slaves, and the slaves are in a constant state of DB recovery. Streaming replication does so as writes happen, and file based log shipping copies the logs when the 16MB segment is complete. Ours were set up to use streaming replication, without having a separate file-based archive log host to use to fetch older logs. Whenever the write load became too much and the slaves could no longer keep up with the master WAL logs on the master would expire and replication would break entirely, requiring you to rebuild all your slaves from backup. This was my introduction to PG replication. WAL logs were also applied without checksums or verification which corrupted the entire replication chain, and as I remember we didn't discover this until the corrupt pages got hit by a query. Software upgrades with PG seemed to be a huge pain as well, we could never figure out how long they were going to take, and even if the on-disk formats didn't change, somehow all the cardinality stats on our tables disappeared, and all our query plans went to shit until we ran some process to rebuild them, which took days.

Operationally there were some things that made our team angry. We couldn't figure out how to reparent a slave without completely re-cloning it from the new parent, even though it was completely up to date from the authoritative master at the time of the reparenting. Also, do you really have to take down the entire cluster to change max connections on a slave? Many such settings seemed to not be dynamic and must remain in sync across the entire chain. One of the things people seem to love about PG is how correct and proper it is respecting the sanctity of your data. As an ops person I'd much rather deal with slightly inconsistent replicas (common in MySQL) than have to fight with how rigid PG is.

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

#44
post #9

Please do not use MySQL,,, unless you've read the it's dual licenses. MariaDB was forked for good reason. MariaDB > MySQL

I agree. Also, MariaDB is being actively developed. A lot of Linux distributions are defaulting to MariaDB. The recent release of Debian stable (jessie) has MariaDB. So far I've only been using it on new machines, but I may even migrate my existing MySQL servers to MariaDB.

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

#45

As someone who's only briefly looked into Postgres, are there any disadvantages to going with it instead of MySQL? It seems (especially from the comments here) that Postgres is something to seriously consider in future projects, but I'm wondering if there are any reasons to stick with MySQL.

Run, and never look back.

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

#46
post #20

How big is the team over at pinterest managing the MySQL infrastructure? I think this is the big difference here. I have a particular project. The database has well over 1 billion rows in multiple tables which need joins to generate complex reporting. As the only tech here, there is only so much I can be working on. Before... time spent on trying to get MySQL to work, was time not well spent. I spent countless hours…

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 suspicious of the comments here. I find it hard to believe that it's as broken as people here claim when big businesses are using it [1].

[1] http://stackoverflow.com/questions/1113381/what-databases-do...

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

#47
Some similar articles and threads:

- Choose Boring Technology: http://mcfunley.com/choose-boring-technology, comments at https://news.ycombinator.com/item?id=9291215

- Chasing the Shiny and New: https://www.nemil.com/musings/shinyandnew.html, discussion at https://news.ycombinator.com/item?id=10279008

- Tech is moving too fast for me, I'm out: https://news.ycombinator.com/item?id=7947551

etc.

I especially liked the first one, which described the idea of "innovation tokens": every startup or project gets three innovation tokens. If you decide to use a new development language, you've just spent one. A new framework, you've just spent another, and so on. If you spend more than three, your chances of launching reach epsilon.

I find that as I'm getting to be an older (and older, sigh...) developer, I'm also more and more reluctant to keep throwing away all of the knowledge and hard-won skills I've developed in favor of picking up new ones. It seems enormously, almost criminally wasteful. How many times should I throw away tens of thousands of lines of code in polished, battle-tested libraries, and knowledge of edge cases and gotchas and little efficiencies and everything else, so that I can start over again with a blank slate and a new language and a long road of new bugs and edge cases to learn?

No other industry is as wasteful in terms of talent expended than ours is. Imagine if every single bridge ever built in this country was torn down and replaced every five years with a new bridge that featured new materials and new technology.

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

#49

OMG, that article had some serious common sense.

Dam, always getting down voting for stating an opinion. What's up with that. (By the way, I actually read the article.)

The correct response is not to give a damn about something so arbitrary.

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

#50

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

Agreed. I consider MySQL a red flag and avoid any projects or teams that choose it over Postgres. Postgres is reliable, flexible, fast, and well documented. It's one of the crowning achievements of the open source world.

What I love about Postgres is how it's the only remaining innovator in the SQL space. It's like Microsoft and Oracle were circa 1999 (the last true innovation out of either was sparse columns in MSSQL). Genetic algorithms, the works. Everything else is mostly stagnant and archaic.
Post reply on HN