Elliptics backend: smack vs leveldb

LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
Smack is a low-level backend for elliptics created with HBase sorted table in mind for maximum write performance.

Anton Kortunov wrote leveldb backend last friday, and here are performance results of both.
Smack was not tuned for maximum write performance, instead I tried to increase read speed, write performance can easily be 20 krps, but with 300-500 read rps only. Smack uses default zlib compression, LevelDB uses Snappy.

We wrote about 70 millions of records (300-900 compressable bytes) into single node with 64 Gb of ram. Above numbers correspond pretty much to page cache IO (leveldb directory is about 30Gb in size).

I’m curious whether we might drop smack backend in favour of well-supported leveldb code?..

6 thoughts on “Elliptics backend: smack vs leveldb

  1. Anton Gerasimov

    Очень странные результаты по записи в liveDB получились.
    Могли бы вы выложить конфигурацию тестового стенда и настроек обоих бекендов?
    Как себя вело время ответа liveDB в зависимости от объема данных?

    1. zbr Post author

      Насколько странные?

      Аппаратная конфигурация такая: 64 Gb памяти, 32 ядра AMD 6274, гигабитная сеть
      2.19 эллиптикс с 20120125.git3c8be10 leveldb

      Конфигурация именно leveldb такая:
      backend = leveldb
      sync = 0
      root = /opt/elliptics/leveldb
      log = /var/log/elliptics/leveldb.log
      cache_size = 100000
      write_buffer_size = 100000
      block_size = 4096
      block_restart_interval = 8
      compression = snappy

      Данных записано немного – около 70 миллионов, размер директории leveldb – около 30 гигабайт, т.е. помещается в память

      1. Vadim Skipin

        1. WriteBuffer стоит выставить побольше. Сколько ставить – надо выяснять конкретно для тестовых данных, но думаю не меньше 64 MB.
        2. BlockSize довольно маленький, возможно стоит поднять (64KB-128KB)
        3. CacheSize тоже стоит увеличить – меньше будет нагрузка на CPU.
        4. BloomFilter применялся? Чтению он весьма помогает :)

        1-2 про запись, 3-4 про чтение (не так актуально в силу маленькой БД).

        Оптимальность настроек можно проверить по логу – поискать там ‘waiting’. В идеале, WriteBuffer надо подбирать так, чтобы за то время, пока накопится 8 файлов в L0 уже закончилась сборка мусора на старших уровнях. Тогда писатели не будут утыкаться в заполненный L0 и не будут ждать.

        1. Vadim Skipin

          ‘Сборка мусора’ == compaction. Ну вы меня поняли :)

      2. Vadim Skipin

        Еще кое-что по конфигурации: по умолчанию в настройках стоит лимит на количество открытых файлов – 1000. 30 GB очевидно не лезет в 1000 файлов по 2 MB, так что стоит увеличить лимит. Думается для современных ОС 20K файлов – не проблема :)

Comments are closed.