Выбор между Berkeley DB Core и Berkeley DB JE

Question

Я разрабатываю веб-приложение на основе Java, и мне нужно хранилище значений ключей. Berkeley DB кажется достаточно подходящим для меня, но, похоже, есть две БД Berkeley на выбор: Berkeley DB Core, реализованный на C, и Berkeley DB Java Edition, реализованный на чистой Java.

Вопрос в том, как выбрать, какой использовать? С веб-приложениями масштабируемость и производительность очень важны (кто знает, может быть, моя идея станет следующим Youtube), и я не мог легко найти какие-либо значимые ориентиры между ними. Я еще не знаком с Cores Java API, но мне трудно поверить, что он может быть намного хуже, чем Java Editions, что выглядит довольно неплохо.

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

Answer 1

У меня довольно большой опыт использования как BDB-JE, так и BDB-core с Java. Решить, какой из них использовать, довольно просто: если вы хотите параллелизма, используйте BDB-JE. Если вам нужна масштабируемость, используйте ядро ​​BDB.

BDB-JE снижает производительность по сравнению с большими базами данных из-за своего формата файлов и использования сборки мусора Java для очистки удаленных записей кэша. Ожидайте длительных пауз сборки мусора или потратьте много времени на настройку волшебных настроек ГХ. У формата файла также есть проблемы, потому что потоки очистителя фона должны тратить много времени на очистку мусора, созданного в результате раннего удаления кэша. Если ваша база данных помещается в ОЗУ, BDB-JE работает достаточно хорошо.

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

Answer 2

Я столкнулся с той же проблемой и решил перейти на версию Java, в основном из-за ее переносимости (мне нужно что-то, что работало бы даже на мобильных устройствах). Существует также API-интерфейс Direct Persistence Layer (DPL), и тот факт, что весь БД представляет собой один jar, делает его развертывание довольно простым.

В последней версии 4 улучшены высокая доступность и производительность. Также существует тот факт, что долго работающие java-приложения могут достичь такой оптимизации, что в некоторых сценариях они будут превосходить производительность собственных приложений на C.

Это естественно подходит для любого Java-приложения - рабочего стола или Интернета.

Answer 3

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

Я предлагаю вам сделать свои собственные тесты для ожидаемых объёмов хранилища и решить, достаточно ли быстрое издание Java.

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

Кстати: моим тестом была проверка скорости запроса случайных ключей из 20 000 000 записей, где ключ - это строка, а значение - целое число (4 байта). Я видел, что вставки (заполнение эталона) были намного быстрее с нативной версией, а запросы были в два раза быстрее.

(Это связано не с недостатком Java, а с тем, что версия Java не совпадает с версией нативной версии - 4.0 против 4.8 IIRC).

Answer 4

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

Answer 5

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

Если вы создаете веб-приложение, то параллелизм может быть очень важен для вас в долгосрочной перспективе.