4 ms·

You cannot get 750K transactions/second with durability for writes, or for reads when they go out of RAM. An HDD drive operates at roughly 250 ops/second, an SD

You cannot get 750K transactions/second with durability for writes, or for reads when they go out of RAM. An HDD drive operates at roughly 250 ops/second, an SDD at roughly 10k ops/second (huge oversimplification, but roughly correct). Even when you batch things and sacrifice a little bit of latency, you can't get even close to 750K QPS. InnoDB is a great engine, but we need to know exactly what the benchmarking number means before we can start relying on it.

arethuza 16y ago
I guess the only thing that might easily give you that kind of performance is a high end storage device like a RamSan-630: http://www.ramsan.com/products/2 http://www.ramsan.com/products/2 Although in this context it would be cheating!
amalcon 16y ago
It doesn't necessarily need to be all on one disk. Of course, 75 independent SDDs is pretty unreasonable to expect.
morgo 16y ago
Right: It's very workload sensitive how this is going to help. If your data set fits in memory, it's probably very good. If you're waiting on IO, the cost of SQL parsing becomes trivial in comparison. What is actually interesting, is that InnoDB actually has some optimizations around writing that NoSQL databases do not (configure multiple read/write threads - required for raid controllers and faster SSDs). So while the benchmark does show the absolute best case, it's not like everything else is a write off. A B+Tree index (assuming hot spots) can usually scale quite well for out of memory fit. This is different for example, from a hash index which aims to have random distribution to each bucket. (Disclaimer: I work for Percona, the company that releases Percona Server).
br1 16y ago
You can get more writes than the number of ops/second of your disk by abandoning B-Trees for TokuDB. (I don't work for them. I'm just a fanboy).
foobarbazetc 16y ago
Put a RAID card with a BBU into your machine and 250 ops/second is irrelevant.

arethuza 16y ago

I guess the only thing that might easily give you that kind of performance is a high end storage device like a RamSan-630: http://www.ramsan.com/products/2 http://www.ramsan.com/products/2 Although in this context it would be cheating!

amalcon 16y ago

It doesn't necessarily need to be all on one disk. Of course, 75 independent SDDs is pretty unreasonable to expect.

morgo 16y ago

Right: It's very workload sensitive how this is going to help. If your data set fits in memory, it's probably very good. If you're waiting on IO, the cost of SQL parsing becomes trivial in comparison. What is actually interesting, is that InnoDB actually has some optimizations around writing that NoSQL databases do not (configure multiple read/write threads - required for raid controllers and faster SSDs). So while the benchmark does show the absolute best case, it's not like everything else is a write off. A B+Tree index (assuming hot spots) can usually scale quite well for out of memory fit. This is different for example, from a hash index which aims to have random distribution to each bucket. (Disclaimer: I work for Percona, the company that releases Percona Server).

br1 16y ago

You can get more writes than the number of ops/second of your disk by abandoning B-Trees for TokuDB. (I don't work for them. I'm just a fanboy).

foobarbazetc 16y ago

Put a RAID card with a BBU into your machine and 250 ops/second is irrelevant.