MariaDB 中的 TokuDB 性能答案

【问题标题】：TokuDB performance in MariaDBMariaDB 中的 TokuDB 性能
【发布时间】：2013-09-12 20:56:23
【问题描述】：

我正在对 TokuDB 引擎进行一些性能测试（我在 Dell PowerEdge R720 上使用了来自 Tokutek 网站的 mariadb-5.5.30-tokudb-7.0.4，内存为 128GB，TokuDB 的默认内存分配为 64GB - tokudb_cache_size) 并且出现了一些非常出乎意料的事情。

在测试场景中，我在空表（33 列，1 个主 auto_increment 键，5 个索引）上插入了大约 90M 行，同时我注意到显着的速度性能和 MyISAM 引擎相比数据压缩，即使用 TokuDB 从 15K 到 20K 记录/秒和 30G 数据到 7G，查询性能急剧下降（没有索引聚类）。

特别是简单的查询：select count(*) from test_table; MyISAM 耗时 0.0001 秒，而 TokuDB 达到 20 秒。还有扫描所有 90M 行表的查询（where column_not_indexed = something），MyISAM 花费了大约 2min，TokuDB 的持续时间超过 5min ！所有其他查询也有性能下降。没有一个比具有相同大小表的 MyISAM 更好。

因此，虽然我了解到 TokuDB 使用的分形树索引在查询速度方面具有出色的性能，但这并没有发生。有没有人测试过 TokuDB 有同样的问题，或者可以给出如何提高查询性能的提示？

创建表语句为：

CREATE TABLE `table` (
`Event` bigint(20) NOT NULL AUTO_INCREMENT,
`TimeStamp` bigint(20) NOT NULL DEFAULT '0',
`Field_1` smallint(4) NOT NULL DEFAULT '0',
`Field_2` bigint(12) NOT NULL DEFAULT '0',
`Field_3` varchar(40) NOT NULL DEFAULT '',
`Field_4` bigint(15) DEFAULT NULL,
(...)
PRIMARY KEY (`Event`) USING BTREE,
KEY `Index_ts` (`Timestamp`),
KEY `Index_1` (`Field_1`),
KEY `Index_2` (`Field_2`),
KEY `Index_3` (`Field_3`)
)ENGINE=TokuDB DEFAULT CHARSET=latin1

一些查询是：

SELECT count(*) FROM table  
**MyISAM:0.00981429   TokuDB:21.40218998**
SELECT Field_2, Timestamp FROM table IGNORE KEY (Index_3, Index_1) WHERE (Field_3 LIKE "%asweb.be") AND (Field_1 < 42) ORDER BY Timestamp LIMIT 2000
**MyISAM:125.9707183  TokuDB:356.6146628**
SELECT Field_2, Timestamp FROM table IGNORE KEY (Index_1) WHERE (Field_4 = "206012216849912") AND (Field_1 < 42) ORDER BY Timestamp LIMIT 2000
**MyISAM:120.0966643  TokuDB:293.2259202**
SELECT Field_2, Timestamp FROM table IGNORE KEY (Index_1) WHERE (Field_2 = "32475731333") AND (Field_1 < 42) ORDER BY Timestamp LIMIT 100000
**MyISAM:0.00552937   TokuDB:0.18659729**

还有：

Query 1: SHOW PROFILE CPU FOR QUERY 1;          
Status  Duration    CPU_user    CPU_system
Queried about 88450000 rows 0.001905    0   0
Queried about 88460000 rows 0.001902    0.004   0
Queried about 88470000 rows 0.001906    0   0
Queried about 88480000 rows 0.001905    0.004   0
Queried about 88490000 rows 0.001664    0   0
Queried about 88500000 rows 0.001907    0.004   0
Queried about 88510000 rows 0.001898    0   0
Queried about 88520000 rows 0.001903    0.004001    0
Queried about 88530000 rows 0.001902    0   0
Queried about 88540000 rows 0.001903    0.004   0
Queried about 88550000 rows 0.001661    0   0
Queried about 88560000 rows 0.001905    0   0
Queried about 88570000 rows 0.001901    0.004   0
Queried about 88580000 rows 0.001912    0   0
Queried about 88590000 rows 0.001902    0.004   0
Queried about 88600000 rows 0.001908    0   0
Queried about 88610000 rows 0.001664    0.004001    0
Queried about 88620000 rows 0.001899    0   0
Queried about 88630000 rows 0.001905    0.004   0
Queried about 88640000 rows 0.001901    0   0
Queried about 88650000 rows 0.0019  0.004   0
Queried about 88660000 rows 0.001661    0   0
Queried about 88670000 rows 0.001906    0.004   0
Queried about 88680000 rows 0.001895    0   0
Queried about 88690000 rows 0.001907    0   0
Queried about 88700000 rows 0.001907    0.004001    0
Queried about 88710000 rows 0.001905    0   0
Queried about 88720000 rows 0.001663    0.004   0
Queried about 88730000 rows 0.001905    0   0
Queried about 88740000 rows 0.001903    0.004   0
Queried about 88750000 rows 0.001899    0   0
Queried about 88760000 rows 0.001898    0.004   0
Queried about 88770000 rows 0.001898    0   0
Queried about 88780000 rows 0.001665    0.004001    0
Queried about 88790000 rows 0.0019  0   0
Queried about 88800000 rows 0.001903    0.004   0
Queried about 88810000 rows 0.001909    0   0
Queried about 88820000 rows 0.001903    0.004   0
Queried about 88830000 rows 0.001663    0   0
Queried about 88840000 rows 0.001902    0   0
Queried about 88850000 rows 0.001901    0.004   0
Queried about 88860000 rows 0.001903    0   0
Queried about 88870000 rows 0.0019  0.004001    0
Queried about 88880000 rows 0.001904    0   0
Queried about 88890000 rows 0.001662    0.004   0
Queried about 88900000 rows 0.001903    0   0
Queried about 88910000 rows 0.001901    0.004   0
Queried about 88920000 rows 0.001905    0   0
Queried about 88930000 rows 0.001904    0.004   0
Queried about 88940000 rows 0.001898    0   0
Queried about 88950000 rows 0.001666    0.004001    0
Queried about 88960000 rows 0.001901    0   0
Queried about 88970000 rows 0.001905    0.004   0
Queried about 88980000 rows 0.001899    0   0
Queried about 88990000 rows 0.001907    0   0
Queried about 89000000 rows 0.00166 0.004   0
Queried about 89010000 rows 0.001903    0   0
Queried about 89020000 rows 0.001899    0.004   0
Queried about 89030000 rows 0.001905    0   0
Queried about 89040000 rows 0.0019  0.004001    0
Queried about 89050000 rows 0.0019  0   0
Queried about 89060000 rows 0.001662    0.004   0
Queried about 89070000 rows 0.001897    0   0
Queried about 89080000 rows 0.001901    0.004   0
Queried about 89090000 rows 0.001894    0   0
Queried about 89100000 rows 0.001897    0.004   0
Queried about 89110000 rows 0.001891    0   0
Queried about 89120000 rows 0.001667    0   0
Queried about 89130000 rows 0.001899    0.004001    0
Queried about 89140000 rows 0.001901    0   0
Queried about 89150000 rows 0.001903    0.004   0
Queried about 89160000 rows 0.00191 0   0
Queried about 89170000 rows 0.001662    0.004   0
Queried about 89180000 rows 0.001906    0   0
Queried about 89190000 rows 0.001903    0.004   0
Queried about 89200000 rows 0.0019  0   0
Queried about 89210000 rows 0.001904    0.004001    0
Queried about 89220000 rows 0.001897    0   0
Queried about 89230000 rows 0.001663    0.004   0
Queried about 89240000 rows 0.001902    0   0
Queried about 89250000 rows 0.001906    0   0
Queried about 89260000 rows 0.001905    0.004   0
Queried about 89270000 rows 0.001903    0   0
Queried about 89280000 rows 0.001894    0.004   0
Queried about 89290000 rows 0.00166 0   0
Queried about 89300000 rows 0.001903    0.004001    0
Queried about 89310000 rows 0.001901    0   0
Queried about 89320000 rows 0.0019  0.004   0
Queried about 89330000 rows 0.001904    0   0
Queried about 89340000 rows 0.001661    0.004   0
Queried about 89350000 rows 0.001892    0   0
Queried about 89360000 rows 0.001808    0.004   0
Queried about 89370000 rows 0.000027    0   0
end 0.000008    0   0
query end   0.000008    0   0
closing tables  0.000008    0   0
freeing items   0.000007    0   0
updating status 0.000029    0   0
logging slow query  0.000005    0   0
cleaning up 0.000005    0   0

闻起来像虫子？

【问题讨论】：

虽然数据适合内存，但分形树索引的性能不会优于 InnoDB 或 MyISAM。此外，由于在使用 TokuDB 时数据会被压缩，因此与 MyISAM 相比，顺序搜索需要更多时间也就不足为奇了。分形树的作用是在您必须在游戏中包含 HDD 时保持性能（当您的工作数据集不再适合内存时）。当您使用严重依赖索引的查询时，您应该会看到性能提升，而在您的示例中 - 这些查询并非如此。
什么@N.B.上面说加上：SELECT COUNT(*) FROM table;（没有 WHERE，没有 GROUP BY）是 MyISAM 立即执行的极少数事情之一，因此比 InnoDB 好得多（它将这个数字保存在某个地方。）不用担心，因为很少有需要总行数和确切行数。
我的应用程序中完全需要 count(*)，但我猜 TokuDB 并没有做到这一点。
您可以将该号码存储在某个地方，就像 MyISAM 一样。如果您的要求是计算数据库表中的总行数，那么创建一个计数器触发器并不难。 TokuDB 很棒，因为它与写入速度一致。但正如你所看到的，这并不是那么神奇。这可能会在未来有所改善。它仍然比 MyISAM 有很多优势。
我会试试扳机的！我还不太明白为什么与 MyISAM 相比，类似的查询需要更多的时间。是因为 TokuDB 提供的压缩吗？

标签： mysql sql performance mariadb

【解决方案1】：

MyISAM 在全表扫描方面胜过 InnoDB 和 TokuDB，因为它基本上只是按顺序扫描文件。

【讨论】：