TokuDB 并不比 MySQL 快多少

Question

我已将具有 80.000.000 行的 MySQL 数据库转换为 TokuDB。

现在当我运行时：

 select count(id) from xxx where active=1

它占用了正常 MySQL 请求的 90% 的时间。

我需要进一步优化什么才能让它运行得更快？

---

表定义：

CREATE TABLE `adsDelivered` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `uid` varchar(40) NOT NULL,
  `_adsDelivered` bigint(20) NOT NULL DEFAULT '0',
  `_campaign` bigint(20) NOT NULL DEFAULT '0',
  `_ad` bigint(20) NOT NULL DEFAULT '0',
  `session` varchar(44) NOT NULL,
  `referer` text NOT NULL,
  `refererDomain` varchar(256) NOT NULL,
  `pageTime` int(11) NOT NULL DEFAULT '0',
  `pageVisibleTime` int(11) NOT NULL DEFAULT '0',
  `browser` varchar(256) NOT NULL,
  `ip` varchar(15) NOT NULL,
  `clicks` int(11) NOT NULL DEFAULT '0',
  `clickTimeLast` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `tag` varchar(256) NOT NULL,
  `countryShort` varchar(2) NOT NULL,
  `timeCreated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `timeUpdated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',

  PRIMARY KEY (`id`),
  UNIQUE KEY `uid` (`uid`),
  KEY `_campaign` (`_campaign`),
  KEY `_ad` (`_ad`),
  KEY `_adsDelivered` (`_adsDelivered`),
  KEY `session` (`session`),
  KEY `tag` (`tag`),
  KEY `ip` (`ip`),
  KEY `countryShort` (`countryShort`),
  KEY `refererDomain` (`refererDomain`)
) ENGINE=TokuDB AUTO_INCREMENT=7420143 DEFAULT CHARSET=utf8;

Answer 1

我为 Tokutek 工作。这里的答案大多是好的。正如贾斯汀所说，您需要正确的索引，而您的架构可能没有正确的索引。我很高兴听到 TokuDB 比 InnoDB 快一点，但是对于表扫描，假设表没有老化，它可以采用任何一种方式。

这是我关于索引的演讲，您可能会觉得有帮助：http : //www.youtube.com/watch?v=vaGAoK66ctM。

前半部分是索引，后半部分是对白板上分形树的技术性探讨。希望这可以帮助您进行索引设计。我强烈建议您了解 TokuDB 提供的集群二级索引。

在其他方面。RolandoMySQLDBA 关于 InnoDB 和 TokuDB 的执行方式大体上是正确的。下面是如何思考 TokuDB 的性能。虽然数据集适合内存，但与 InnoDB 或其他基于 B-Tree 的存储引擎相比，TokuDB 的分形树没有任何固有的优势。当数据很大并且不适合主内存时，瓶颈，或者更确切地说是悬崖。InnoDB 的写入性能和其他基于 B-tree 的存储引擎的写入性能下降了悬崖，TokuDB 的性能保持水平。这表明您正在从 TokuDB 中获得一些东西。TokuDB 不会利用一些运行良好的现有系统并增强其性能。TokuDB 将使系统在内存中运行良好，但在内存不足时开始崩溃，并确保这些系统随着数据的增长而运行良好。http://www.tokutek.com/resources/benchmarks/#iiBench）。

将这种写入性能与 TokuDB 的压缩相结合，集群索引突然变得相对便宜，正如索引讨论中所解释的那样。维护更多更好的索引变得更便宜。使用更好的索引，来自查询的大量 I/O 可能会消失，并且查询吞吐量会提高。这就是人们可以从 TokuDB 中受益的方式。

Answer 2

你没有active索引。对于此查询，tokudb 比 InnoDB 或 MyISAM 更快的唯一原因是，如果表具有会减少总 IO 的异常压缩，因为您正在检查整个表。

如果表中一小部分行（少于 30% 的给予或接受）的值为 active=1，则添加索引会有所帮助。

如果表中的大多数行都是 active=1，并且此查询很重要，那么您可以考虑改为维护汇总表。您还可以考虑使用 Shard-Query 对表进行分区并并行访问分区。

http://code.google.com/p/shard-query

对于具有许多非唯一索引的大型表，TokuDB 在 INSERTIONS 上应该比 InnoDB 更快，但在 SELECT 查询上不一定更快。来自 Facebook 的 Mark Callaghan 在 Facebook 图形基准测试中发现，与 InnoDB 相比，查询性能提高了 3 倍，存储空间减少了 50%。

如果只是追加数据，你也可以考虑Infobright Community Edition，这是一个列存储，或者如果你更学术，Fastbit。

http://infobright.org

https://sdm.lbl.gov/fastbit/

Answer 3

它占用了正常 mysql 请求时间的 90%。

如果花费的时间更少，那么速度会更快吗？

TokuDB 的核心是 SSD 的高效使用，特别是写入性能和寿命 - 如果大部分数据都适合内存，那么 MyISAM 和 InnoDB 获取数据的速度会快得多。对于单线程基准测试来说，它不会更快。您似乎没有采取任何措施来重现 TokuDB 明显优于其他引擎的情况，并要求解释它应该更慢的情况。