Производительность TokuDB в MariaDB

Я проводил некоторые тесты производительности на движке TokuDB (я использовал mariadb-5.5.30-tokudb-7.0.4 с веб-сайта Tokutek на Dell PowerEdge R720 со 128 ГБ памяти и с выделением памяти по умолчанию для TokuDB, которое составляет 64 ГБ — tokudb_cache_size) и получилось что-то очень неожиданное.

В тестовом сценарии я вставил около 90 миллионов строк в пустую таблицу (33 столбца, 1 первичный ключ автоинкремента, 5 индексов), и хотя я заметил значительную скорость работы и компрессию данных по сравнению с движком MyISAM, то есть с 15K до 20K записей/сек и 30G данных до 7G с TokuDB, производительность запросов резко снижается (индекс не кластеризуется).

В частности, простой запрос: выберите количество(*) из таблицы test_table; для MyISAM потребовалось 0,0001 сек., а для TokuDB — до 20 сек.. Также запросы, которые сканируют всю таблицу строк 90M (где column_not_indexed = something) и занимают около 2 минут для MyISAM, с TokuDB их продолжительность была выше 5 минут ! Все остальные запросы также имели ухудшение производительности. Ни один из них не был лучше, чем 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

Пахнет жуком?


mysql sql performance mariadb
person John    schedule 09.09.2013    source источник
comment
Хотя данные умещаются в памяти, индексы фрактального дерева не превзойдут InnoDB или MyISAM. Кроме того, поскольку при использовании TokuDB данные сжимаются, неудивительно, что последовательный поиск занимает больше времени по сравнению с MyISAM. Что делает фрактальное дерево, так это поддерживает производительность, когда вам нужно включить жесткий диск в игру (когда ваш рабочий набор данных больше не помещается в памяти). Вы должны увидеть повышение производительности при использовании запросов, которые сильно зависят от индексов, а в ваших примерах эти запросы не таковы.   -  person N.B.    schedule 09.09.2013
comment
Что @N.B. упомянутый выше плюс: SELECT COUNT(*) FROM table; (без WHERE, без GROUP BY) — это одна из очень немногих вещей, которые MyISAM делает мгновенно и, следовательно, намного лучше, чем InnoDB (он хранит это число где-то в памяти). Не беспокойтесь об этом, потому что редко кому нужен общее и точное количество строк.   -  person ypercubeᵀᴹ    schedule 09.09.2013
comment
Мне очень нужен count(*) в моем приложении, но TokuDB, я думаю, не помогает.   -  person John    schedule 09.09.2013
comment
Вы можете сохранить этот номер где-нибудь, как это делает MyISAM. Нетрудно создать триггер счетчика, который делает это, если вам нужно подсчитать общее количество строк в таблице базы данных. TokuDB великолепен, потому что он соответствует скорости записи. Но, как видите, это не та магия. Это, вероятно, улучшится в будущем. Он по-прежнему имеет много преимуществ перед MyISAM.   -  person N.B.    schedule 10.09.2013
comment
Пробую триггер! Я не совсем понял, почему запрос с подобным занимает гораздо больше по сравнению с MyISAM. Это из-за сжатия, которое предлагает TokuDB?   -  person John    schedule 10.09.2013
comment
Также для запроса count (*) я показал процессор профиля, который я добавил к вопросу.   -  person John    schedule 10.09.2013
comment
Что ж, судя по внешнему виду вашего запроса LIKE, он не может использовать индекс. Почему бы не создать еще один столбец, который является ОБРАТНЫМ, и создать для него индекс. Таким образом, вы можете иметь подстановочный знак в конце запроса (если есть лучший подход, кто-нибудь, пожалуйста, поправьте меня, я действительно набираю это в спешке). Это вероятно медленнее из-за необходимости распаковывать данные, но я действительно не уверен в этом (хотя я не вижу другой причины).   -  person N.B.    schedule 10.09.2013

Ответы (1)


arrow_upward
3
arrow_downward

MyISAM превосходит InnoDB и TokuDB при полном сканировании таблиц, поскольку в основном просто последовательно сканирует файл.

person tmcallaghan    schedule 13.09.2013