LINUX.ORG.RU

Berkeley DB всегда была глючной?

 , ,


0

2

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

Но на простом сценарии с несколькими писателями и одним потребителем на Hash хранилище дедлок ловится буквально в первые секунды, при каждом запуске. Btree хранилище на том же сценарии вываливается, портя базу данных.

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

Погружение в документацию приоткрывает врата в ужас. В документации повсеместно упоминаются взаимные блокировки, как будто они — нормальное явление. Вызов функции в одном процессе может просто подвесить все остальные процессы, навсегда. И это предлагается решать запуском отдельной утилиты db_deadlock! Логи транзакций, кстати, тоже надо чистить. Без вызовов специальных функций или запуска соответствующих утилит эти файлы просто займут всё место на диске, сколько есть. Писать по кругу в один файл эта библиотека, похоже, просто не умеет.

Berkeley DB всегда была таким глюкодромом?

★★★★★

Дедлоков не видел, но вообще столкновение с BDB оставило неприятные впечатления.

На 4.x при внезапном падении приложения в некоторых случаях базу заклинивало, вообще не открывалась с какой-то невнятной ошибкой. Плюс у нее были проблемы с совместимостью, не получилось взять файлы с линукса и открыть их в венде (оба на x86-64), при том что мажорная версия была та же

Сейчас этих библиотек вагон и маленькая тележка

Да ну. Те которые умеют сортировать ключи и не держат базу целиком в RAM, можно на пальцах пересчитать. Если с транзакциями, то вообще остается полторы библиотеки вместе с SQLite

Deleted ()
Ответ на: комментарий от Deleted

Да ну

Напишу немного подробнее о библиотеках которые пришлось поковырять:

Аналог BDB который на слуху это LMDB (Lightning Memory-Mapped Database). Там даже похожее API и фичи. Но он mmap-ит всю базу целиком, для 32-битного железа это накладывает ограничения на размер. Сам автор пишет что на 32 битах можно держать максимум сотни мегабайт

Tokyo/Kyoto кабинеты - заброшены, последние обновления 2012 года (см. глагне http://fallabs.com/ )

LevelDB и форки - невнятный статус вендового порта и нет поддержки транзакций

SQLite4 LSM ( https://www.sqlite.org/src4/doc/trunk/www/lsmusr.wiki ) - не работает на 32 битах, за последние 2 года 2 коммита Fix typo

Ну и какие-то несерьезные проекты типа «вот мы выдрали btree из SQLite3»

Непонятно, может пропустил какую-то жемчужину, но то что видел не очень впечатлило

Deleted ()
Ответ на: комментарий от anonymous

Экстрасенс/10. Ещё за тебя угадаю, что всё это происходит на x86*.

anonymous ()
Ответ на: комментарий от Deleted

Но он mmap-ит всю базу целиком

К счастью для меня, о 32х битных системах можно не думать, уже залочились на 64 бита, так что LMDB меня спасло. Не понятно, правда, какие грабли лежат впереди.

i-rinat ★★★★★ ()
Ответ на: комментарий от Jopich

Спасибо за варианты.

Но этот тред не столько для поиска альтернатив, сколько просто пожаловаться. То, во что я верил, разрушилось, когда я к нему наконец-то прикоснулся. Я до конца верил, что ошибка где-то у меня в коде. У меня и сейчас ещё теплится какая-то странная надежда на то, что при «правильном» использовании библиотеки она будет работать нормально.

i-rinat ★★★★★ ()

Проверенная годами надженость - это форк bdb 1.86 в бздях

annulen ★★★★★ ()
Ответ на: комментарий от Jopich

RocksDB

Это же форк раннего LevelDB?

PerconaFT, WiredTiger, ForestDB

Интересно было бы почитать живых пользователей (точнее, разработчиков которые используют) этих хранилищ. Судя по issues и pull requests им тоже бывает непросто

Вот несмотря на жуткую лицензию и баги BDB все равно довольно популярен. http://db-engines.com/en/ranking/key-value store - 9-е место по упоминаниям в интернетах, не кот чихнул

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

Deleted ()
Ответ на: комментарий от i-rinat

LMDB меня спасло. Не понятно, правда, какие грабли лежат впереди.

Держи нас в курсе.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.