MemcacheDB Quick Benchmarks

Рубрика: Development | 3 March 2010, 18:43 | Vadim Voituk

Эта заметка увидела свет в результате небольшого исследования, проведенного мною в процессе работы на оптимизацией проекта www.savevid.com и призвана поделиться моим скромным опытом миграции на key-value базы дынных (БД) .

Предистория состоит в том, что в процессе естественной эволюции кода и оптимизации запросов к MySQL RDBMS,  работа с “центральной” таблицей всей схемы БД (как несложно догадаться – это таблица videos), свелась к простому алгоритму:

  1. выбрать сложным запросом из разных таблиц все video_id, удовлетворяющие нужным критериям
  2. по полученному списку video_id, выбрать информацию о видео (aka SELECT … FROM videos WHERE id IN (…))

Причиной появления подобного use-case стал внушительный размер той самой videos.  А о катастрофичности любых JOIN-ов на большие (10Gb+) InnoDB-таблицы уже было написано немало. Хотя бы на том же MysqlPerfomanceBlog.com.

Следовательно, если у нас есть выборки из таблицы ТОЛЬКО по primary key – то это первый кандидат на миграцию в key-value RDBMS.  Что мы, собственно, и пытались опробовать.

Среди массы кандидатов (а их оказалось действительно много), для первоначальных проб выбрали MemcacheDB.
Причины весьма прозаичны, и были надиктованы “путем наименьшего сопротивления”:

  • В проекте уже активно используется Memcached, клиент которого уже 100% совместим с MemcacheDB.
    Следовательно никаких сторонних библиотек “тянуть” в проект не нужно
  • Реализации клиентов для Memcached/MemcacheDB есть почти под все мыслимые и немыслимые платформы и языки программирования. Тут конечно огромное спасибо Бреду Фицпатрику и его Danga.com.
  • Memcached клиенты предоставляют базовый развномерный (хоть документация  и говорит о weight-based распределении) шардинг. В результате и MemcacheDB это перенял.
  • В основе backend-a MemcachedDB лежит BerkleyDB – одна из старейших и надежнейших key-value RDBMS, которая до сих под активно поддерживается Oracle Corp.
  • BerkleyDB поддерживает репликацию. И что самое приятное – как синхронную, так полу-синхронную и асинхронную.
  • Memcached-клиенты поддерживают сжатие данных, что является немаловажым фактором при использовании дорогостоящих SSD-винчестеров.

В результате всего вышесказанного был проведен небольшой performance benchmark test.

Железо:

Использовался тестовый сервер 2 x Core2Quad / 16GB of RAM / 4 x 146Gb SAS HDD in RAID10
MySQL: v5.4.2 , InnoDB, innodb_buffer_pool=6Gb, по максимуму оптимизирован для интерсивной записи.
MemcaheDB: 1Gb of RAM, index type – hash, skip transaction support

Производительность записи:

Создание 1 000 000  записей.
MySQL: среднее время записи – 5.6 sec / 10k  (5.6 секунд на 10 000 записей)
MemcacheDB: среднее время записи – 4.1 sec / 10k
При включенном transaction support в MemcacheDB – около 7 sec/ 10k

Как видно MySQL не сильно отстает на записи, но при этом предоставляет полноценный ACID.

Производительность чтения:

Из ранее созданного миллиона записей случайным образом выбиралась одна запись по primary key.
MySQL: среднее время чтения – 1.7 sec / 10K
MemcacheDB: среднее время чтения – 0.7 sec / 10K

Т.е. в данном случае MemcacheDB более чем в 2 раза опережает MySQL.
Думаю если заняться тюннингом первого, то можно этот разрыв увеличить куда существеннее.

Размер данных:

Соотношение размеров файлов с данными (и индексами) получилось 1.5Gb  (MemcacheDB) против 2.3Gb (MySQL), т.е.  в 1.5 раза в пользу MemcacheDB.
Сравнение проводилось без использования сжатия в MemcacheDB и без использования MySQL ROW_FORMAT=COMPRESSED.

Вот такой вот небольшой sidenote вышел. В результате, пока еще мне не совсем понятно нужно ли оно мне или нет.
Если все-таки решеним испольовать MemcacheDB в production environment -  обязательно отпишусь о результатах.

Комментариев: 7

7 Responses to “MemcacheDB Quick Benchmarks”

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

  1. Igor

    > (хоть документация и говорит о weight-based распределении)
    может у вас везде одинаково памяти/диска – тогда вам конечно weight-based и не нужно.

    а вообще конечно вы яблоки (SQL) с апельсинами (NoSQL) сравниваете.

    > В результате, пока еще мне не совсем понятно нужно ли оно мне или нет.

    очевидно, что если write speed вашего single MySQL host вас устраивает то никакой NoSQL вам не нужен.

  2. Vadim Voituk

    Игорь,
    Про weigh-based я писал в контексте того, что документация врет. Веса почти ни на что не влияют. И это очень плохо в нашем случае.

    Что же касается сравнения NoSQL c SQL – так вроде с этого начинается процесс перехода на NoSQL. Как минимум начинает приходить понимание того, ЧТО можно с этого получить.

    Ну write-speed меня устраивает, если бы небыло read-IO :)

  3. Denis Bazhenov

    Спасибо за заметку. Мне кажется это очень правильно что к решению использовать KV модель приходят именно через “паттерны доступа к данным” (http://dotsid.blogspot.com/2010/01/kv.html).

    Хотелось бы узнать каков feedback от внедрения MemcacheDB в production :)

  4. Kefir

    Интересно сравнить с RDBMS посаженной на Hibernate с кэшем 2го уровня. Конечно, 1й запрос к объекту будет долгим, но последующие будут брать его из кэша.

  5. Vadim Voituk

    @Kefir,
    Ну если бы я мог иметь кеш достаточного размера перед RDBMS, то я бы использовал Memcached и вообще не парился по этому поводу, а вся эта ерунда с KV-стораджами была была бы неактуальной.
    Но как ты сам понимаешь 20G записей в кеш не запихнешь.

  6. Kefir

    Это в память не запихнешь, а в дисковый можно. Вот это то как раз и интересно: сравнить MemcachedDB со “стандартными” кэшами (EhCache, OSCache, JBoss cache). потому как очевидным недостатком первого является то что его надо непосредственно встраивать в приложение. А использование “стандартных” кэшей достаточно прозрачно.

    И потом, неужто все 20G нужны?

  7. Vadim Voituk

    Ааа… Ты про дисковый кеш. Теперь понял.
    Ну как-бы MemcacheDB это не кеш – это KV-persistent storage, потому сравнивать его с кешами – не очень правильно.
    Хотя на результаты я бы поглядел.

    Кстати в качестве альтернативы MemcacheDB хочу попробовать MemBase (от создателей Memcached) и Tokio Tyrant

Leave a Reply