Когда возникает потребность хранить пары ключ-значение, Berkeley DB — первое, что приходит в голову. Сейчас этих библиотек вагон и маленькая тележка, но всё равно, если спросить про NOSQL хранилище, в числе первых советов будет именно Berkeley DB. Эта библиотека была, кажется, всегда. Сколько ей, лет 15? Её где только не использовали, уж казалось бы, все глюки должны были быть отловлены и исправлены. Пусть её в тестах только ленивый не обгонял, всегда казалось, что все эти новомодные движки — потенциальный глюкодром. А BDB — годами проверенная надёжность. И по докам умеет много всего. Работа из нескольких процессов, кеширование, транзакции, даже репликация.
Но на простом сценарии с несколькими писателями и одним потребителем на Hash хранилище дедлок ловится буквально в первые секунды, при каждом запуске. Btree хранилище на том же сценарии вываливается, портя базу данных.
Окей, включаем журналирование, хотя по докам без него должно корректно блокироваться. Теперь ловится взаимная блокировка и в Btree! Разве транзакции не призваны были предотвратить эти блокировки? Хотя с транзакциями работает корректно чуть дольше, до минуты дотягивает.
Погружение в документацию приоткрывает врата в ужас. В документации повсеместно упоминаются взаимные блокировки, как будто они — нормальное явление. Вызов функции в одном процессе может просто подвесить все остальные процессы, навсегда. И это предлагается решать запуском отдельной утилиты db_deadlock! Логи транзакций, кстати, тоже надо чистить. Без вызовов специальных функций или запуска соответствующих утилит эти файлы просто займут всё место на диске, сколько есть. Писать по кругу в один файл эта библиотека, похоже, просто не умеет.
Berkeley DB всегда была таким глюкодромом?
