Если верить тестам производительности Berkeley DB от Оракл,
http://www.oracle.com/technology/products/berkeley-db/pdf/berkeley-db-perf.pdf
то скорость одиночной записи на различных системах (Single-record write) измеряется десятками тысяч операций в секунду на типичном настольном компьютере.

Решили воссоздать ситуацию:
Машина Ubuntu Linux 64, core2quad 2.5Ghz, 8Gb RAM, 4kb cluster,
винт - SSD PATRIOT 128Gb
Версия базы Berkeley db 4.6

Суть теста –
Создаем базу с доступом по хэшу.
В цикле в базу инсертим случайный ключ 64байта длиной и килобайт данных.
Раз в 5 секунд выводим среднюю производительность на экран.

В начале теста
результате теста, когда количество данных в базе невелико, вставка происходит быстро

starting, DB_HASH
cache: 0/267072/1 ----------дефолтный кеш
pagesize: 2048
TimeInterval: 5000000, KEY64, DATA1024
random keys, seed = 12345
281738 56347 / sec
403267 24305 / sec
435074 6361 / sec
461809 5347 / sec
491495 5937 / sec

Дойдя до трех миллионов ключей, скорость записи падает критично
скорость падает пропорционально росту базы данных.

3248817 179 / sec
3253905 1017 / sec
3257165 652 / sec
3258585 284 / sec
d
3262057 694 / sec

Когда ставили на выходные тест – получили вообще смешные цифры
53443487 8 / sec
53443524 7 / sec
53443550 5 / sec

Обнаружили зависимость – большой кэш базы (2-3 гигабайта) данных приводит к резкому падению производительности уже к миллиону записей.

Вопрос – в чем может быть проблема? Двойное кеширование – и Беркли, и операционной системой?
Что можно подкрутить-настроить, чтобы добиться хотя бы близких результатов к тестам от Оракл?
Может быть, у кого-то есть опыт эксплуатации Беркли на больших объемах данных?
Поделитесь, пожалуйста.

Piecrusts and virginity are made to be broken(с)
PS.
По скорости чтения тоже есть вопросы.

Код теста в приложении.

Хэш - потому что нужен только доступ по случайному ключу, никакого сканирования индекса не будет. Не принципиально, но в документации базы утверждалось, что для большой базы , в которой доступ сугубо случайный, хэш лучше дерева.

Сейчас я, почитав форум Беркли и еще немного доков, грешу на установки размера кэша.
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_conf/cachesize.html
http://www.oracle.com/technology/documentation/berkeley-db/db/api_cxx/env_set_cachesize.html
http://forums.oracle.com/forums/thread.jspa?threadID=718303&tstart=135

Т.к. нам нужна работа с сотней миллионов строк по килобайту данных в каждой, то никакого разумного размера кеша не хватит. Завтра попробуем выставить кеш минимальный и посмотреть, что будет с производительностью.

Piecrusts and virginity are made to be broken(с)

Собрали мы статистику по базе - строках на 300 000 и на 1000000, сравнивал количество баскетов, оверфлоу блоков и т.д. Пропорция относительно общего количества строк сохраняется, да и функция хеша у разработчиков заявлена как адаптирующаяся под объем.
Т.е. это все не гарантия, конечно, но в качестве основного виновника тормозов сейчас не
рассматриваю.
Попробуем на дереве тоже, отчего не попробовать.
Завтра покручу размер кеша, результат выложу.


Piecrusts and virginity are made to be broken(с)

Попробовали.
Неоднократно даже, и дерево, и хэш.
При ключах 64 б и 1 кб данных самая приличная производительность при размере базы в 3-5 миллионов при размере блока в 2 кб и дефолтном размере кеша.

А нам нужно на два порядка большие объемы.
Так что миллионы строк, длинные ключи и килобайтные данные, высокая производительность: выбирайте любые два.



Piecrusts and virginity are made to be broken(с)

Размер кластера ФС и страницы DBD не обязательно одинаковые, это просто в общем случае рекомендованно.
С обычным SATA все провисает гораздо быстрее, но "железячной" стороной вопроса мы действительно озаботились, там действительно могут быть затыки.

авторс SSD могут быть различные проблемы.
Например?


Piecrusts and virginity are made to be broken(с)