Случайное чтение LevelDB — почему официальный тест так хорош?
Согласно этому официальный эталон, он выполняет 129 000 операций в секунду при случайном чтении. Но, как я знаю, для произвольного чтения требуется как минимум ОДИН случайный доступ к диску (кеш не помогает при случайном чтении, потому что вся база данных намного больше, чем кеш), а одному диску произвольного доступа требуется около 10 мс для поиска диска. Это должно сделать случайное чтение медленнее, чем 100 операций в секунду.
Я сделал простой тест с 100 000 000 строк MD5 на моей медленной машине. произвольная запись выполняет около 50 000 операций в секунду (что недалеко от официального теста), а произвольная запись — около 20 операций в секунду.
Вопрос в том, почему официальный тест leveldb дает такой высокий результат? Я не вижу специальных оптимизаций в коде теста, и тест не использует что-то вроде SSD-диска.
Решение
Официальные результаты тестов, к которым вы привязались, относятся к набору данных, настолько маленькому, что он полностью помещается в оперативную память их тестовой машины. То есть, кеш файловой системы содержит все данные, даже если кеш LevelDB этого не делает.
Вот тест, показывающий, как HyperLevelDB работал, когда набор данных был в 5 и 50 раз больше, чем ОЗУ. (HyperLevelDB — это разветвление LevelDB, разработанное людьми HyperDex, с улучшенной скоростью записи по сравнению с оригиналом. Все это намного медленнее, чем LMDB хоть.)
http://symas.com/mdb/hyperdex/
Другие решения
Я думаю, это потому, что вы запускаете тест чтения сразу после теста записи. После теста записи leveldb может выполнить сжатие, что приводит к интенсивному вводу-выводу на диск и замедлению чтения. Так что вы должны подождать некоторое время после теста записи. С 100 000 000 записей MD5 строк, я думаю, вы должны подождать минут.
Ricon East 2013 Презентация по пропускной способности имеет несколько хороших графиков и описывает проблемы с огромной пропускной способностью и то, как они исправили это в Riak.