Случайное чтение LevelDB, почему так хорош официальный тест?

Согласно этому официальному тесту, он выполняет 129 000 операций в секунду при произвольном чтении. . Но, как я знаю, для произвольного чтения требуется как минимум ОДИН произвольный доступ к диску (кэш не помогает при произвольном чтении, потому что вся база данных намного больше, чем кеш), а одному диску с произвольным доступом требуется около 10 мс для поиска диска. Это должно сделать случайное чтение медленнее, чем 100 операций в секунду.

Я провел простой тест со 100000000 строками MD5 на своей медленной машине. произвольная запись выполняет около 50 000 операций в секунду (что недалеко от официального эталона), а произвольное чтение - около 20 операций в секунду.

Возникает вопрос: почему официальный тест leveldb дает такой высокий результат? Я не вижу особых оптимизаций в коде теста, и тест не использует что-то вроде SSD-диска.


person richselian    schedule 05.06.2013    source источник


Ответы (3)


Официальные результаты тестов, с которыми вы связались, относятся к настолько маленькому набору данных, что он полностью умещается в оперативной памяти их тестовой машины. То есть кеш файловой системы содержал все данные, даже если кеш LevelDB не содержал их.

Вот тест, показывающий, как HyperLevelDB работает, когда набор данных был в 5 и 50 раз больше, чем ОЗУ. (HyperLevelDB - это форк LevelDB, разработанный специалистами HyperDex, с улучшенной пропускной способностью записи по сравнению с оригиналом. Однако все это намного медленнее, чем LMDB.) http://symas.com/mdb/hyperdex/

person hyc    schedule 09.12.2013

Я думаю, это потому, что вы запускаете тест чтения сразу после теста записи. После теста записи leveldb может выполнить сжатие, что приведет к интенсивному вводу-выводу диска и замедлению чтения. Так что после теста записи вам следует немного подождать. При записи 100000000 строк MD5, я думаю, вам следует подождать минуты.

person ideawu    schedule 27.08.2013

В презентации Ricon East 2013 по пропускной способности есть несколько хороших графиков и описаны проблемы с огромной пропускной способностью и как они это исправили в Riak.

person Andy Dent    schedule 08.10.2013