TokuDB 並不比 MySQL 快多少

我已將具有 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;

我為Tokutek工作。這裡的答案大多是好的。正如賈斯汀所說，您需要正確的索引，而您的架構可能沒有正確的索引。我很高興聽到 TokuDB 比 InnoDB 快一點，但是對於表掃描，假設表沒有老化，它可以採用任何一種方式。

這是我關於索引的演講，您可能會覺得有幫助：http ://www.youtube.com/watch?v=vaGAoK66ctM 。

前半部分是關於索引的，後半部分是對白板上分形樹的技術潛水。希望這可以幫助您進行索引設計。我強烈建議您了解 TokuDB 提供的集群二級索引。

關於其他點。RolandoMySQLDBA 在 InnoDB 和 TokuDB 的表現上基本正確。以下是如何考慮 TokuDB 的性能。雖然數據集適合記憶體，但 TokuDB 的分形樹與 InnoDB 或其他基於 B-Tree 的儲存引擎相比沒有任何固有優勢。當數據很大並且不適合主記憶體時，瓶頸，或者更確切地說是懸崖。在 InnoDB 的寫入性能和其他基於 B-tree 的儲存引擎的寫入性能跌落懸崖的地方，TokuDB 的性能保持不變。這表明你正在從 TokuDB 中獲得一些東西。TokuDB 不會佔用一些執行良好的現有系統並增強其性能。TokuDB 將讓系統在記憶體中執行良好，但在記憶體不足時開始崩潰，並確保這些系統在數據增長時表現良好。http://www.tokutek.com/resources/benchmarks/#iiBench ).

將這種寫入性能與 TokuDB 的壓縮相結合，突然聚集索引（如索引演講中所述）變得相對便宜。維護更好的索引變得更便宜。使用更好的索引，來自查詢的大量 I/O 可能會消失，並且查詢吞吐量會提高。這就是人們可以從 TokuDB 中受益的方式。

你沒有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/

引用自：https://dba.stackexchange.com/questions/41623