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

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

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

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

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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