Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL - Do Not Pass This Way Again

grimoire.ca

Post reply on HN
Print view View original

141–150 of 164 posts

Re: MySQL - Do Not Pass This Way Again

#141

Post by pnathan »

dangrossman wrote: post #2

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…

One of my colleagues has been involved in rearchictecting a reasonably large database on MySQL; his complaints ran along the same lines as the article. Many bad defaults, many subtle edge cases of wrong. E.g., the encoding based on connection string problem is very real. :-/

Re: MySQL - Do Not Pass This Way Again

#142

Post by ucee054 »

contingencies wrote: post #49
jacques_chester wrote: post #45

Earlier quoted context omitted.

Any central service is going to be a point of failure. This isn't unique to RBMSes (the other classic SPOF is message buses). The idea that RDBMSes are unsuitable for HA applications is ... well to be charitable, I'll call it "inaccurate". Most of the techniques that are used for HA were first invented for conventional databases and/or their best friends, mainframes and midrange systems. I agree however that it is a…

I agree with the historical point. But I think you miss mine: show me an open source RDBMS (I don't want to drop $annual_profit_margin on Oracle) with major-version upgrade capable HA while under load. My view: it doesn't exist. You could try to make it happen somehow, but it would be a huge project on its own. On your somewhat loaded financial example, as someone who is designing some financial systems at the moment…

1) "24x7x365 service on a mission-critical system"

2) "(I don't want to drop $annual_profit_margin on Oracle)"

If it's critical, you're willing to pay for it.

If you're not willing to pay for it, it's not critical.

This comes naturally from the definition of mission critical.

Re: MySQL - Do Not Pass This Way Again

#143

Post by themonk »

toast0 wrote: post #71
jacques_chester wrote: post #35

Earlier quoted context omitted.

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…

> LIMIT OFFSET queries are always going to be hard because you have to generate lots of rows only to throw them away There are ways to avoid that: http://www.slideshare.net/suratbhati/efficient-pagination-us...

Re: MySQL - Do Not Pass This Way Again

#144

Post by jeffdavis »

pippy wrote: post #82

I've been hearing bad things about MySQL, so I've been avoiding it as of late. So far my experience has been subpar. PostgreSQL is pedantic with data insertion, almost to a fault. This costs me development time. (Also I have no idea what my users will do, and I'd rather have faulty data inserted than none at all. If it's for a client asking about a product, this could cost money). Yet purists claim this is a great fe…

"PostgreSQL is pedantic with data insertion, almost to a fault."

The PostgreSQL philosophy isn't about being "pedantic", but it is very different from MySQL. I assume that you have much more experience with MySQL; maybe you are trying too hard to use postgres in the mysql way rather than the postgres way?

Personally, I don't think it's a good idea to migrate usually for this reason. The entire project development always has lots of built-in assumptions about how the DB will be used, so the new system is almost never quite the right fit. It can only work in trivial cases, or when you have the right expectations.

Re: MySQL - Do Not Pass This Way Again

#145

Post by MichaelGG »

16s wrote: 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.

As I've said before, MySQL's data handling is very much like VB's "On Error Resume Next".

Re: MySQL - Do Not Pass This Way Again

#146

Post by twerquie »

taligent wrote: post #29
simonw wrote: post #7

Earlier quoted context omitted.

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/

Just wanted to confirm something. You say you have no single point of failure but you are running everything in one data center ?

There is always a single point of failure if you zoom out far enough.

Re: MySQL - Do Not Pass This Way Again

#147

Post by twerquie »

taligent wrote: post #30
16s wrote: 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.

I really don't know where to begin with such a stupid comment. How about you start with listing which of these companies needs educating: http://www.mysql.com/customers/ Facebook ? Twitter ? Amazon ? Flickr ?

He's clearly talking about people new to databases who choose MySQL because of its ubiquity, not seasoned engineers and large companies operating legacy applications.

> Facebook ? Twitter ? Amazon ? Flickr ?

I imagine none of these companies would choose MySQL if starting from scratch today.

Re: MySQL - Do Not Pass This Way Again

#149

Post by twerquie »

pippy wrote: post #82

I've been hearing bad things about MySQL, so I've been avoiding it as of late. So far my experience has been subpar. PostgreSQL is pedantic with data insertion, almost to a fault. This costs me development time. (Also I have no idea what my users will do, and I'd rather have faulty data inserted than none at all. If it's for a client asking about a product, this could cost money). Yet purists claim this is a great fe…

> PostgreSQL is pedantic with data insertion

Better to deal with the exceptions up-front, than to discover months down the line that your database has been silently chopping long strings, silently casting types and coercing values into useless junk.

Re: MySQL - Do Not Pass This Way Again

#150

Post by armored_mammal »

dangrossman wrote: post #2

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…

Perhaps most companies prefer to keep the press positive? Mine certainly does. (And it'll probably stick with MySQL until its dying day despite it causing problems repeatedly.)
Post reply on HN