BerkeleyDB написать проблемы с производительностью

Question

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

Я пробую библиотеку C BerkeleyDB (5.1.25) из java и вижу серьезные проблемы с производительностью.

В течение короткого времени я получаю твердые 14K документов / с, но как только я достигаю нескольких сотен тысяч документов, производительность падает как скала, затем она восстанавливается на некоторое время, затем снова падает и т. Д. Это происходит чаще и более часто, вплоть до того момента, когда большую часть времени я не могу получить более 60 документов в секунду с несколькими изолированными пиками 12 тысяч документов в секунду после 10 миллионов документов. Мой тип базы данных - HASH, но я также пробовал BTREE, и он такой же.

Я пытался использовать пул из 10 дБ и хэшировать документы между ними, чтобы сгладить падение производительности; это увеличило пропускную способность записи до 50 Кбайт / с, но не помогло с падением производительности: все 10 дБ одновременно замедлились до сканирования.

Я предполагаю, что файлы реорганизуются, и я попытался найти параметр конфигурации, который влияет на то, когда происходит эта реорганизация, поэтому каждая из объединенных баз данных будет реорганизована в разное время, но я не смог найти ничего, что сработало , Я пробовал разные размеры кеша, зарезервировав пространство с помощью опции конфигурации setHashNumElements, чтобы не тратить время на увеличение файла, но каждый твик делал его намного хуже.

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

Кто-нибудь здесь с опытом достижения стабильной производительности записи с помощью berkeleydb?

Редактировать 1 :

Я уже пробовал несколько вещей:

1. Сокращение записи до 500 / с (меньше, чем в среднем я получил после записи 30 миллионов документов за 15 часов, что указывает на то, что аппаратное обеспечение способно записывать 550 документов / с). Не сработало: после написания определенного количества документов производительность падает независимо от этого.
2. Запись входящих элементов в очередь. У этого есть две проблемы: A) Это побеждает цель освобождения барана. Б) Очередь в конечном итоге блокируется, потому что периоды, в течение которых BerkeleyDB останавливается, становятся длиннее и чаще.

Другими словами, даже если я ограничу поступающие данные, чтобы остаться ниже аппаратных возможностей, и использую оперативную память для хранения элементов, в то время как BerkeleyDB требуется некоторое время, чтобы адаптироваться к росту, поскольку это время становится все длиннее, производительность приближается к 0.

Это удивляет меня, потому что я видел утверждения, что он может обрабатывать терабайты данных, но мои тесты показывают иначе. Я все еще надеюсь, что я делаю что-то не так ...

Редактировать 2 :

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

Но периодическая реорганизация файлов BerkeleyDB снижает производительность намного раньше, чем это, и гораздо худшим способом: он просто перестает отвечать на запросы все дольше и дольше, в то время как он перемешивает вещи. Использование более быстрых дисков или распространение файлов базы данных между различными дисками не помогает. Мне нужно найти способ обойти эти сквозные дыры.

Answer 1

Что я видел с высокой скоростью записи на диск, так это то, что системный кэш будет заполняться (что приведет к повышению производительности до этой точки), но как только он заполняет приложение, даже вся система может резко замедлиться, даже остановиться.

Ваш физический диск должен поддерживать не менее 100 операций записи в секунду. Более того, это иллюзия, поддерживаемая более четким кэшированием. ;) Однако, когда система кеширования исчерпана, вы увидите очень плохое поведение.

Я предлагаю вам рассмотреть кэш контроллера диска. Его резервная память должна быть размером с ваши данные.

Другой вариант - использовать SSD-накопители, если обновления носят пакетный характер (они могут выполнять 10K + записей в секунду, поскольку у них нет движущихся частей) с кэшированием, это должно дать вам больше, чем нужно, но SSD имеет ограниченное количество записей. .

Answer 2

Это старый вопрос, и проблема, вероятно, исчезла, но у меня недавно были подобные проблемы (скорость вставки резко падала после нескольких сотен тысяч записей), и они были решены путем предоставления большего объема кэша для базы данных (DB-> set_cachesize).).С 2 ГБ кеш-памяти скорость вставки была очень хорошей и более или менее постоянной до 10 миллионов записей (я не тестировал дальше).

Answer 3

Мы использовали BerkeleyDB (BDB) на работе и, похоже, имели схожие тенденции производительности.BerkeleyDB использует Btree для хранения своих пар ключ / значение.Когда количество записей продолжает увеличиваться, глубина дерева увеличивается.Кэширование BerkeleyDB работает при загрузке деревьев в оперативную память, поэтому при обходе дерева не происходит ввод-вывод файла (чтение с диска).

Answer 4

BerkeleyDB не выполняет реорганизацию файлов, если вы не вызываете утилиту сжатия вручную. Есть несколько причин замедления:

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

Когда вы говорите «документы», вы хотите сказать, что используете BDB для хранения записей размером более нескольких килобайт? Страницы переполнения BDB имеют больше накладных расходов, поэтому вам следует рассмотреть возможность использования большего размера страницы.

Answer 5

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

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