3 ms·
Many important databases do contain 100-byte rows. Sometimes the biggest tables contain 100-byte rows, and then smaller tables contain larger rows. I'd have t
by bradleykuszmaul 12y ago
Many important databases do contain 100-byte rows. Sometimes the biggest tables contain 100-byte rows, and then smaller tables contain larger rows.
I'd have to disagree with your assessment of the value of math.
It's nice to see someone trying to do performance benchmarks, but there are some serious problems with the benchmark presented at symas.com.
1) The benchmark hardware used fusion I/O. If you can afford fusion I/O, and you don't care about compression, you should use InnoDB. But you didn't measure InnoDB. If you use fusion I/O you probably actually care about compression, which you didn't measure, since you disabled compression. Why even report space used if you've disabled compression?
2) You used libc malloc to try to make a "uniform test". TokuDB recommends the use of JEmalloc, and you mentioned that some other storage engine requires TCmalloc. There's a reason to use a better memory allocator, and some storage engines need it. You've misconfigured at least two of the storage engines.
3) You wrote TokuDB code using the embedded API without passing the flags that make the high-ingestion rate possible. I'll be the first to admit that the documentation is poor for Tokutek's embedded API (the API that looks like Berkeley DB), but that doesn't change the fact that you are misusing the software. In particular, it appears that you used `0' for the flag argument to the DB->put() operations, meaning that every write is preceeded by a query. Since you apparently didn't mess up the LSM-based API's, it's not a fair comparision.
4) You ran your benchmarks for 20 minutes on each storage engine. That's not nearly long enough. For example, the system won't have aged at all. Interesting things start happening when the the database has been running for a long time. Interesting things that are predicted by the math.
- hyc_symas 12y agoI'm sure there are many important databases with 100 byte rows. But very few of these will be SQL databases, and very few of these will be using InnoDB. 1) re: InnoDB - sorry, but your constant comparison to InnoDB only reminds me of the old joke about the snail that got run over by a turtle - while waking up in the recovery room, the snail says "I don't remember what happened, it all happened so fast!" Beating InnoDB at anything says nothing useful. http://symas.com/mdb/memcache/ http://symas.com/mdb/memcache/ We tested compression. http://symas.com/mdb/inmem/compress/ http://symas.com/mdb/inmem/compress/ 2) We tested with multiple malloc libraries as well. http://symas.com/mdb/inmem/malloc/ http://symas.com/mdb/inmem/malloc/ If your storage engine needs a particular memory allocator, You're Doing It Wrong. 3) I didn't write the TokuDB code, Leif Walsh did. https://gist.github.com/leifwalsh/8378154#file-db_bench_ydb-cc-L459-L485 https://gist.github.com/leifwalsh/8378154#file-db_bench_ydb-... https://github.com/hyc/leveldb/commits/benches/doc/bench/db_bench_tokudb.cc?author=leifwalsh https://github.com/hyc/leveldb/commits/benches/doc/bench/db_... I also didn't write the LSM-based programs, their respective authors did. I trusted each of them to use their own APIs correctly. That may have been a mistake in the case of the TokuDB code, but given the lack of documentation I didn't have much better alternatives. 4) We have much longer benchmark runs published as well. But as noted here http://symas.com/mdb/hyperdex/ http://symas.com/mdb/hyperdex/ what really matters is the total number of ops executed. "Running for a long time" is only a requirement when your DB engine is ... slow.
- mdcallag 12y agoWelcome, Bradley and Leif, to the club of people whom Howard has declared are doing it wrong. You are in fine company as I am also a member of that club. Although I do prefer snark from Turing Award winners. I don't think there is reason to pursue a discussion. It won't end well. But I do understand the desire to address the claims once. https://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate-worse-than-death/ https://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate...