4 ms·

5.1 scales better, and I would bet they're looking into XtraDB (if not already using it) which will go even further on multi-core machines. edit - 5.1 (recent

5.1 scales better, and I would bet they're looking into XtraDB (if not already using it) which will go even further on multi-core machines. edit - 5.1 (recent releases) scales better mostly due to InnoDB 1.0.4 which incorporates a number of patches from Google (Mark Callagan), Percona and more.

catch23 17y ago
but still, it doesn't scale as linearly as other databases like Oracle or PostgreSQL. Even compared against MySQL 5.1, PostgreSQL scales linearly all the way up to 128 cores -- so it seems like for big databases, you'd want to use something that can actually utilize all 128 cores. I'm pretty sure they're using MySQL because it's popular, not because it scales. I figure when people hit 10 million rows in a MySQL table, they start looking at sharding/partitioning instead of buying a bigger machine.
- spudlyo 17y ago
  MySQL scales for reads pretty well since it has a well understood and mature replication system. In contrast, the PostgreSQL replication landscape is somewhat muddy. Scaling writes is a challenge of course, and PostgreSQL might be the better choice there for getting the most out of big hardware. Scaling up can really cost though, as the price-to-performance ratio gets outside of the sweet spot when the hardware you're buying gets more exotic.
  - catch23 17y ago
    I'm not debating which database scales better. I'm questioning why anyone would use a "big" server for mysql. If you're going to do replication with mysql, you don't need 10 servers with 68 gigs of memory -- you'd probably be better off with 100 servers with 4 gigs of memory. However, if you're going to go with "big" database servers, one should use Oracle or PostgreSQL since they can actually make use of the memory & cpu cores.
    - spudlyo 17y ago
      Any 64-bit MySQL will do fine with big memory. It is with > 16 cores that modern MySQL suffers from concurrency problems with mutex contention. These AMZN big memory instances have 4/8 cores, well within the area where MySQL performs well.
- jrockway 17y ago
  Is 10 million rows really the number? I have log files on my disk that are much bigger than that, and I manage them fine with "grep". Inside a database, I would consider this amount of data "trivial".

catch23 17y ago

but still, it doesn't scale as linearly as other databases like Oracle or PostgreSQL. Even compared against MySQL 5.1, PostgreSQL scales linearly all the way up to 128 cores -- so it seems like for big databases, you'd want to use something that can actually utilize all 128 cores. I'm pretty sure they're using MySQL because it's popular, not because it scales. I figure when people hit 10 million rows in a MySQL table, they start looking at sharding/partitioning instead of buying a bigger machine.

spudlyo 17y ago
MySQL scales for reads pretty well since it has a well understood and mature replication system. In contrast, the PostgreSQL replication landscape is somewhat muddy. Scaling writes is a challenge of course, and PostgreSQL might be the better choice there for getting the most out of big hardware. Scaling up can really cost though, as the price-to-performance ratio gets outside of the sweet spot when the hardware you're buying gets more exotic.
- catch23 17y ago
  I'm not debating which database scales better. I'm questioning why anyone would use a "big" server for mysql. If you're going to do replication with mysql, you don't need 10 servers with 68 gigs of memory -- you'd probably be better off with 100 servers with 4 gigs of memory. However, if you're going to go with "big" database servers, one should use Oracle or PostgreSQL since they can actually make use of the memory & cpu cores.
  - spudlyo 17y ago
    Any 64-bit MySQL will do fine with big memory. It is with > 16 cores that modern MySQL suffers from concurrency problems with mutex contention. These AMZN big memory instances have 4/8 cores, well within the area where MySQL performs well.
jrockway 17y ago
Is 10 million rows really the number? I have log files on my disk that are much bigger than that, and I manage them fine with "grep". Inside a database, I would consider this amount of data "trivial".