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

    Недавно, чисто случайно, попался на глаза продукт от 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 Гиг. Сэкономил всего пару гигабайт, разница уже не в разы. Экономия сильно зависит от типа данных. В тестах использовались текстовые данные, которые хорошо ужимаются, а в новом проекте — блоки двоичных данных. Про скорость работы в данном случае ничего сказать не могу. При заполнении БД данные проходят обработку, которая занимает время, большее, чем собственно работа базы
    .
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 24

      +6
      Всегда было интересно. Вот в Японии люди работают почти 24/7/365… даже умирают от усталости на работе…
      Наверняка в Японии есть софтверные конторы…

      Но почему известно так мало программных продуктов, сделанных японцами?

      Это из-за повернутости на внутренний рынок? Или из-за традиционной закрытости, когда каждая корпорация сама пишет софт для себя и ни с кем не делится… почему?

      Или это просто так получилось, что я знаю кучу всемирно известных проектов из России, США, Австралии, Канады, Германии, Польши, и других стран а из Японии не знаю ни одного.
        +5
        Мммм, Ruby?
        +3
        Видимо дело в их закрытости. Основные направления разработки ПО заняли Штаты и японцы видимо сосредоточились на прикладном программировании для нужд своих корпораций. А то, что в Японии специалисты в области программирования есть и не слабые — можно судить по косвенным признакам.
        Программа «компьютеры пятого поколения». была разработана в начале 80х японцами. Очень амбициозная программа была. По софтверной части упор делался на системах искусственного интеллекта. Японская корпорация NEC до недавнего времени была одним из лидеров суперкомпьютерного фронта. Просто мы действительно очень мало знаем об этой стране.
          +1
          Как минимум один японец в разработке PostgreSQL активно участвует. В других проектах тоже часто видел японские имена. Припоминаю, что для Emacs очень много библиотек и программ (например, почтовые клиенты mew и wunderlust) написаны японцами.
            0
            У Hudson/Jenkins CI разработчик японец.
              +1
              Достаточно, но можно использовать софт, не зная о нём. Пример: самая используемая ОС в мире (2003 год).
                0
                Есть еще библиотека регулярных выражений Oniguruma и ставшая легендарной indie-игра Cave Story.
                  0
                  Вот в Японии люди работают почти 24/7/365… даже умирают от усталости на работе…
                  Стереотип из разряда «в России по улицам медведи в ушанках и валенках с балалайками ходят пьяные».
                  Но почему известно так мало программных продуктов, сделанных японцами?
                  Потому что большая их часть существует только на японском языке. Как пример — достаточно известный и популярный в определённых кругах графический редактор SAI. До 2008 существовал исключительно на японском, а переводом озаботились только потому, что фанаты не вытерпели и сделали сами.
                  +2
                  У вас в тестрировании есть 2 особенности, одна нейтральная, а 2я — довольно сильно влияющая на результат.

                  1) При объёме памяти сервера 8гб и датасете 2гб — у вас идёт тестирование только эффективности распределения памяти внутри кэша, и совершенно нет нагрзуки на hdd. Всё, что только можно, будет браться из файлового кэша. Это вполне распространённый вариант нагрузки, но он только из многих — неплохо бы это указать. Как только объём данных превысит размен оперативной памяти — могут появиться совершенно неожиданные эффекты.
                  2) По размеру памяти под «прямой» кэш — вы даёте tyrant 2GB, оставляюю memcached дефолтные 64MB. И, получается, что для 1го вы тестируете прямую отдачу из внутренних буфферов, а для 2го — эффективность перекачки данных буфферы<->кэш ОС. Ай-ай-ай-ай.
                    0
                    В процессе работы Kyoto Tycoon постоянно сбрасывает обновления на диск. По окончании записи я рестартовал сервер и выполнял контрольное чтение — потерь данных не было. Если вы просмотрели все результаты тестов, я запускал и вариант с дефолтными настройками, которые достаточно скромны, говорить там о кэше памяти нельзя, и всеравно результат ухудшился не сильно и был заметно лучше, чем у MemcacheDB.
                      0
                      Я не про тест записи. Там они в одинаковых условиях. Я про тест чтения. Размер внутреннего кэша вы уменьшали только до 500MB, у memcachedb же:
                      -m in-memmory cache size of BerkeleyDB in megabytes, default is 64MB
                        0
                        А tokio по умолчанию съел у вас 400 мб — это, кстати, может оказать влияние на выбор, когда свободной памяти мало — vds и т.п.
                          0
                          Запустил с кэшем 64 мега — посмотрим :)
                          У меня не стоит задача расхвалить Kyoto Tycoon. Подвернулся случай пощупать этот софт, результаты показались интересными, решил поделиться. Если бы он проиграл MemcacheDB, я бы об этом тоже написал. Честное пионерское!
                            0
                            Сделал тест с msiz=64m — уравнял размеры кэша с дефолтным MemcacheDB
                            Результат:
                            — запись — 25 мин 43 сек
                            — чтение — 12 мин 26 сек
                            Т.е. всеравно скорости выше. Но оперативки он сожрал 400 Mb — в два раза больше.
                            Поэтому по оперативке — проигрыш, по скорости и размеру БД на диске — выигрыш.
                            Наверняка выигрыш по скорости и из-за более компактного хранилища — меньше дисковых операций.
                      0
                      Во время теста, когда я рестартовал сервер с новыми параметрами и сразу начал слать ему данные — было потеряно порядка 16 тысяч первых записей.

                      Это без сообщения об ошибке что ли? Он принимал данные и тихо терял их? Если так, то вряд ли такую систему стоит использовать. Мало ли что она где затеряет…
                        0
                        Сообщения были. Функция сохранения данных возвращала код ошибки. Просто когда я запустил несколько тестов пакетом — отправил свой лог в /dev/null, чтобы диск не засорять. На последнем тесте чтения увидел ошибку, что считано меньше записей, чем сохранено. Прогнал еще пару тестов, уже с сохранением логов, и обнаружил причину.
                        +5
                        Что то не понял я результатов :-\

                        сами по себе:
                        — Kyoto Tycoon — 18 мин 52 сек.
                        — MemcacheDB — 32 мин 39 сек

                        «Наперегонки»
                        — Kyoto Tycoon — 1час.
                        — MemcacheDB — 1 час 38 мин.

                        То есть Kyoto Tycoon отработал час, а потом MemcacheDB еще 38 минут дорабатывал?

                        Как же так, если он в одиночку делает импорт за 32 минуты?
                          +1
                          В столь большом времени общего «забега» судя по всему была виновата возросшая дневная нагрузка на сервер. К сожалению абсолютно чистого сервера у меня не было.

                          В утренние часы я получал лучшие по времени результаты, ближе к вечеру — худшие.
                          Поэтому самые первые тесты я повторил несколько раз, в разной очередности и в разное время суток. А парный забег повторять не стал, поскольку тут они работали в одинаковых условиях.
                          0
                          кстати ни сколько не удивительно

                          memcacheDb базируется на berkeleyDB в качестве хранилища, ну и технология немного устарела
                          + memcache в качестве буферного кеша.

                          Kyoto Tycoon — разработана современная компактная комбинированная hash/b-tree таблица. Скорость быстрее и время доступа меньше. Сам собираюсь использовать Kyoto Кабинет (чисто одно хранилище) в поисковых целях.
                            0
                            На самом деле технология одна и та-же — hash/b-tree в различных вариантах. Ничего более быстрого и удобного вроде не придумали с тех пор. Вопрос скорее в реализации.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое