Live data from Hacker News

MySQL - Do Not Pass This Way Again

grimoire.ca

71–80 of 164 posts

Re: MySQL - Do Not Pass This Way Again

#71
post #15

Earlier quoted context omitted.

Many of the complaints I hear people make about the entire concept of an "RDBMS" (often then to motivate why the NoSQL solution they decided to start using is better) are actually MySQL-specific issues that do not affect PostgreSQL (or Oracle, or usually SQL Server; I only mention PostgreSQL, as you wanted a concrete experience); one key example is "if you want to change your schema, it requires locking the entire sy…

Or "joins are too slow". Well, yes, they can be. But some database systems have smarter plan builders than others. Take, for example, this gem: > Joining and ordering by rows from multiple tables often forces MySQL to dump the whole join to a temporary table, then sort it -- awful, especially if you then use LIMIT BY to paginate the results. This describes just about every standard page-with-comments schema ever devi…

Is it MySQLs fault that wordpress asks it to do something that's hard?

LIMIT OFFSET queries are always going to be hard because you have to generate lots of rows only to throw them away, but there are ways to organize the data, and write the queries so that you avoid temporary tables. I don't think Wordpress is MySQL specific; and maybe they use an ORM layer anyway, but if you want to get the most performance out of MySQL, you need to know how it works and write your queries accordingly. Sometimes that means get all the data unsorted from MySQL and sort it yourself, which is unfortunate, but frontend cpu + memory is cheaper than database I/O to make a temp table and sort it

Re: MySQL - Do Not Pass This Way Again

#73
post #7

I appreciate this well-argued piece of persuasive writing for not choosing MySQL, but the premise is surprising -- I don't recall seeing, on Hacker News or elsewhere, any writeups from companies that chose MySQL then ran into significant problems they had to architect around, nor writeups from companies that chose MySQL then had to rip everything out to switch to something in the same family of solutions (Postgres, O…

We migrated Lanyrd from MySQL to PostgreSQL, primarily to reduce the pain involved in running schemes alterations against large tables but we've since been enjoying some if the more advanced PostgreSQL features (pg_trgm indexes for example). You can read about our migration here: http://lanyrd.com/blog/2012/lanyrds-big-move/

Thanks for being clear and detailed about your DB migration.

I've been involved in a few and they've generally been brought on by DBAs convincing the bosses that "everything is wrong"...once it was done the DBAs wanted to blame the developers again.

Re: MySQL - Do Not Pass This Way Again

#74
post #11

Earlier quoted context omitted.

But you can trust the fork started by the guy who sold it to Sun in the first place, then followed it to Oracle, then led the exodus from Oracle to capitalize on anti-Oracle feeling by starting a fork? Riiiiiiiiiight....

Then there is always the Percona or Twitter or millions of other forks around.

Percona Server is good. The ability to monitor is great and the supporting tools are very helpful.

Re: MySQL - Do Not Pass This Way Again

#75

This person doesn't even offer a solution? How is it that people who have blogs that take 30 seconds to load continue to give performance advice that gets upvoted? The funny thing is that this blog's performance is based on some cookie. If I reload in Chrome? 2 sec. If I reload in "Incognito Chrome", it's again really slow. So seriously, just stop with these authoritative blog posts when you don't even know what you'…

It took less than a second for it to load on my browser. And why should he offer a solution? The point of his rant isn't that you should use a particular solution, but rather that you should avoid MySQL at all costs.

Re: MySQL - Do Not Pass This Way Again

#76
post #50

Earlier quoted context omitted.

Oh just blame Wordpress. My self-written software has no performance issues on MySQL, but Wordpress loading times are over two seconds with a default installation.

> Oh just blame Wordpress. I usually do. But in this case it looks as though MySQL's underwhelming query planner might be at fault.

MySQL's query planner is actually pretty good, but there are some things that are just not going to be fast; most of which is documented, almost all of which can be seen with describe select ...; if it uses a temporary table, it's probably necessary, and it's definitely going to be slow once you have enough rows. If WordPress uses any of these things, it's not MySQL's fault.

Re: MySQL - Do Not Pass This Way Again

#77
post #10

MySQL is the visual basic of SQL databases. Anyone can set one up and use it. The problem is that many non-technical people use MySQL and then think they know all about DBs. Ask them what ACID is, or about foreign key constraints. You'll get blank stares. If you know what those things are and value them, you probably don't use MySQL.

[deleted]

Re: MySQL - Do Not Pass This Way Again

#78

This person doesn't even offer a solution? How is it that people who have blogs that take 30 seconds to load continue to give performance advice that gets upvoted? The funny thing is that this blog's performance is based on some cookie. If I reload in Chrome? 2 sec. If I reload in "Incognito Chrome", it's again really slow. So seriously, just stop with these authoritative blog posts when you don't even know what you'…

the solution is Postgres

Re: MySQL - Do Not Pass This Way Again

#79

Earlier quoted context omitted.

Can you provide some citations to this claim? I know a lot of people who understand ACID, Foreign Keys, and have experience with other DBs (like PostgreSQL) and still often choose MySQL based on its merits.

I think he is talking about "people who use mysql only because it was the easiest thing to learn" don't know these things, not "experienced DBAs/devs who happen to be using MySQL".

Yeah, he's not talking about DBAs who work at Facebook, Yahoo, YouTube, Wikipedia or Twitter. Just because half the Alexa top 10 uses MySQL in production doesn't mean it's not just used by non-technical noobs who don't know any better.

Re: MySQL - Do Not Pass This Way Again

#80

Earlier quoted context omitted.

If you have to be a jerk about it, it may interest you that relatively static blog content can be cached on the server. I'm genuinely interested to learn which use cases are more dependent on query planning than caching methodologies.

> I'm genuinely interested to learn which use cases are more dependent on query planning than caching methodologies. I'll reply to this separately, it's a good discussion to have. My basic problem is that caching comes with a coordination cost and I prefer the originating data source to be as performant as possible. My own use case is a small Wordpress multisite installation. Even with a relatively trivial amount of…

As you described it, the query/caching strategy sounds too complicated.

mysql proxy might help you out, or mysql triggers, or plenty of easy indexing strategies.

i agree, caching strategies are not easy, but that is not the fault of databases. IMHO keeping your data layers separate is best.

if you have a multi-site installation, set some kind of prefix within the app that makes sense to you for each application, before it goes into whatever cache.

this will work for you whether it is shared memory, memcached, or some kinda file situation.

Post reply on HN