Pull to refresh

MemcacheDB против Kyoto Tycoon — экспресс тестирование

Reading time 4 min
Views 3.4K
Недавно, чисто случайно, попался на глаза продукт от FAL LabsKyoto Tycoon, легкий сервер данных. В основе данного продукта — QDBM (Quick Database Manager) — хранилище данных типа ключ-значение. Зацепило меня то, что с этим «Магнатом из Киото» можно общаться по memcached-like протоколу.
Поскольку уже некоторое время использую MemcacheDB, захотелось сравнить их характеристики (протокол общения один, и там и там NoSQL-хранилище ключ-значение). Недавно подвернулся удобный случай — экспортировал некоторый объем данных из одного самопального хранилища в MemcacheDB. Для тестирования осталось только развернуть на том-же сервере Kyoto Tycoon.
Вот что у меня получилось:

Сервер, на котором тестировалось — Opteron-2218, 2.6GHz, 8G ОП, HDD 73G+143G sas.
На 73-гиговом диске лежал файл с импортируемыми данными, а на 143-гиговом базы MemcacheDB и Kyoto Tycoon.
Исходные данные — 10226086 записи, суммарным объемом (ключ+значение) 1.4G.

Сервера данных запущены командами:
$ ktserver -port 11114 -tout 10 -log /var/db_tests/kyoto/ktserver.log -ls -dmn -pid /var/db_tests/kyoto/ktserver.pid -plsv /usr/local/libexec/ktplugservmemc.so -plex port=11115 '/var/db_tests/kyoto/data.kch#opts=l#bnum=20000000#msiz=2g#dfunit=8'

$ memcachedb -p11117 -d -r -u sen -H /var/db_tests/mcdb/db/ -N -v -P /var/db_tests/mcdb/mcdb_tests.pid

Результаты:
1. Импорт данных:
— Kyoto Tycoon — 18 мин 52 сек.
— MemcacheDB — 32 мин 39 сек
2. Чтение данных (по списку ключей из лога выбирались данные из соответствующей базы, для сверки считались контрольные суммы):
— Kyoto Tycoon — 9 мин 46 сек. (рестартанул демона, чтобы обнулить его кэш, результат ухудшился на 4 секунды)
— MemcacheDB — 19 мин 35 сек
3. «Наперегонки» (одновременно запустил оба скрипта импорта данных):
— Kyoto Tycoon — 1час.
— MemcacheDB — 1 час 38 мин.
К моменту финиша «японца» в MemcacheDB была загружена треть от общего количества записей.
В столь большом времени общего «забега» судя по всему была виновата возросшая дневная нагрузка на сервер. К сожалению абсолютно чистого сервера у меня не было. Но остальные тесты, кроме данного, я запускал в более свободные часы и дважды, чтобы хоть немного сгладить посторонние воздействия на процесс.

И еще пара характеристик:
1. Размер файлов данных:
— Kyoto Tycoon — 2.15G (на следующий день он «усох» до 1.87G без потери данных, видимо освободил пустые блоки).
— MemcacheDB — 4.56G
2. Размер занимаемой оперативной памяти:
— Kyoto Tycoon — 2.45G. Честно занял сколько ему разрешили, плюс код и личные потребности.
— MemcacheDB — 208Mb.

Этой тройкой тестов я решил закончить сравнение двух продуктов и еще немного помучал Kyoto Tycoon меняя настройки. Поскольку используемая схема хранения данных — хэш (возможен и вариант с двоичным деревом), в описании говорится, что на быстродействие влияет базовый размер хэш-таблицы и рекомендуется задавать его примерна раза в 2 больше хранимого количества записей. Поскольку в моей задаче количество записей постоянно растет, важно, насколько сильны потери в скорости, если это количество значительно превысит заданный размер базового хэша.
Итоги тестирования Kyoto Tycoon с разными параметрами (буду указывать только то, что изменял в приведенной выще команде):
1. bnum=5000000 (уменьшил в 4 раза, в 2 раза меньше количества записей) — 17 мин 28 сек
2. bnum=2000000 — 17 мин 45 сек
3. bnum=5000000#msiz=1g (ополовинил размер захватываемой оперативки) — 18 мин 23 сек
4. bnum=5000000#msiz=500m (еще ополовинил) — 19 мин 15 сек.
5. без параметров по файлу данных (вариант, когда пользователь не заморачиваясь тюнингом запустил сервер скопировав команду из руководства):
— импорт данных — 22 мин. 4 сек.
— чтение данных — 11 мин. 47 сек.
Данный пакет тестов я прогнал один раз. Разницы в результатах невелики, в пределах погрешностей. Пожалуй немного выбивается результат при отсутствии параметров файла данных (установленных по умолчанию). Судя по всему настройки по умолчанию довольно скромные — сервер в памяти занимает всего около 400 мегабайт.
Больше с ограничениями я возиться не стал. Будет время позверствовать, поиграю с настройками, посмотрю, на каком этапе хранилище начнет задыхаться. Для себя я вывод сделал — мои нагрузки Kyoto Tycoon держит лучше, чем MemcacheDB. Возможно в следующем проекте я буду использовать его.

Кроме того, Kyoto Tycoon можно использовать и как чистый кэш памяти, как и Memcached. Разработчики утверждают, что в ряде случаев он даже выигрывает, но сравнительных тестов нет, хорошо бы погонять-проверить.

Что особенно понравилось в описании, так это «improves robustness: database file is not corrupted even under catastrophic situation» — вряд ли разработчики заявляют это голословно, наверняка найдется желающий проверить.

PS. Фактически у меня получилось небольшое поверхностное сравнение MemcacheDB и Kyoto Tycoon, и чуть более подробное тестирование — Kyoto Tycoon. В любом случае я не притягивал результаты за уши, работал с реальными данными одного из поддерживаемых мной проектов.

PPS. Помимо Kyoto Tycoon у FAL Labs есть еще несколько интересных проектов. Например Estraier — персональный полнотекстовый поисковик, Hyper Estraier — поисковик для комьюнити (в чем разница, я не разбирался), Tokyo Promenade — легкая CMS-ка. Было бы интересно разобрать, насколько хороши эти продукты.

UPDT. Разбирая результаты последнего теста обнаружил, что после старта сервера Kyoto Tycoon желательно выждать 5-10 секунд, прежде чем отправлять ему данные на сохранение. Во время теста, когда я рестартовал сервер с новыми параметрами и сразу начал слать ему данные — было потеряно порядка 16 тысяч первых записей. Т.е. первые 2 секунды загрузчик данных бился головой об стену. При работе с уже работающим сервером потерь не наблюдалось. Такая задержка нормальна — разметка полей данных, подготовка к работе.

UPDT2.Поскольку дефолтный размер кэша у MemcacheDB 64 Mb, сделал тест с msiz=64m — уравнял размеры кэша.
Результат:
— запись — 25 мин 43 сек
— чтение — 12 мин 26 сек
Т.е. всеравно скорости выше. Но оперативки он сожрал при этом 400 Mb — в два раза больше, чем MemcacheDB.
Поэтому по оперативке — проигрыш, по скорости и размеру БД на диске — выигрыш (по размеру БД примерно в 2.5 раза).
Наверняка выигрыш по скорости в том числе и из-за более компактного хранилища — меньше дисковых операций.

UPDT3 (от 01.03.2011). Обрадованный заметно меньшим размером файла БД, полученном при вышеописанном тестировании, поставил Kyoto Tycoon на другой проект, где BerkeleyDB (с MemcacheDB во фронтэнде) достигла размера в 32 Гига. Сейчас файл базы Kyoto Tycoon «весит» 30 Гиг. Сэкономил всего пару гигабайт, разница уже не в разы. Экономия сильно зависит от типа данных. В тестах использовались текстовые данные, которые хорошо ужимаются, а в новом проекте — блоки двоичных данных. Про скорость работы в данном случае ничего сказать не могу. При заполнении БД данные проходят обработку, которая занимает время, большее, чем собственно работа базы
.
Tags:
Hubs:
+35
Comments 24
Comments Comments 24

Articles