Проблемы с производительностью записи BerkeleyDB
Мне нужно хранилище ключей и значений на диске, которое может поддерживать высокую производительность записи и чтения для больших наборов данных. Я знаю, что это очень большая проблема.
Я пробую библиотеку C BerkeleyDB (5.1.25) из java и вижу серьезные проблемы с производительностью.
На короткое время я получаю 14 КБ документов в секунду, но как только я набираю несколько сотен тысяч документов, производительность падает как скала, потом на какое-то время восстанавливается, затем снова падает и т. Д. Это происходит все чаще и чаще, до такой степени, что большую часть времени я могу ' t получить более 60 документов / с с несколькими изолированными пиками по 12 тыс. документов / с после 10 миллионов документов. Мой тип базы данных - HASH, но я также пробовал BTREE, и это то же самое.
Я пробовал использовать пул из 10 дБ и хешировать документы среди них, чтобы сгладить падение производительности; это увеличило пропускную способность записи до 50 КБ документов / с, но не помогло с падением производительности: все 10 дБ замедлились до сканирования одновременно.
Я предполагаю, что файлы реорганизуются, и я попытался найти параметр конфигурации, который влияет на то, когда происходит эта реорганизация, чтобы каждая из объединенных баз данных реорганизовывалась в разное время, но я не смог найти ничего, что работало . Я пробовал разные размеры кеша, зарезервировав место с помощью параметра конфигурации setHashNumElements, чтобы он не тратил время на увеличение файла, но каждая настройка делала это намного хуже.
Я собираюсь отказаться от berkeleydb и попробовать гораздо более сложные решения, такие как cassandra, но я хочу убедиться, что я не делаю что-то не так в berkeleydb, прежде чем списывать его.
Кто-нибудь из присутствующих, у кого есть опыт достижения устойчивой записи производительность с berkeleydb?
Редактировать 1 :
Я уже пробовал несколько вещей:
- Регулировка скорости записи до 500 / с (меньше, чем в среднем после написания 30 миллионов документов за 15 часов, что указывает, что оборудование способно писать 550 документов / с). Не сработало: после написания определенного количества документов производительность все равно падает.
- Записывать входящие элементы в очередь. У этого есть две проблемы: A) Он не позволяет освободить барана. Б) Очередь в конечном итоге блокируется, потому что периоды зависания BerkeleyDB становятся длиннее и чаще.
Другими словами, даже если я ограничиваю входящие данные, чтобы они оставались ниже аппаратных возможностей, и использую RAM для хранения элементов, в то время как BerkeleyDB требуется некоторое время, чтобы адаптироваться к росту, поскольку это время становится все больше, производительность приближается к нулю
Это меня удивляет, потому что я ' Мы видели утверждения, что он может обрабатывать терабайты данных, но мои тесты показывают обратное. Я все еще надеюсь, что делаю что-то не так ...
Редактировать 2 :
Поразмыслив еще немного и с помощью Питера, я теперь понимаю, что по мере того, как файл становится больше, пакет операций записи будет распространяются дальше друг от друга, и вероятность их падения в один и тот же дисковый цилиндр падает, пока в конечном итоге не достигнет ограничения диска в поисках / секундах.
Но периодические реорганизации файлов BerkeleyDB убивают производительность гораздо раньше, чем это, и гораздо хуже: он просто перестает отвечать на все более длительные периоды времени, пока перемешивает вещи. Использование более быстрых дисков или распространение файлов базы данных между разными дисками не помогает. Мне нужно найти способ обойти эти пропускные отверстия.