Альтернатива BerkeleyDB?
Я ищу dbm-подобную библиотеку, которую я могу использовать вместо Berkeley DB, которую я использую в настоящее время. Моя основная причина перехода заключается в том, что лицензионные сборы для BDB довольно высоки (бесплатно для приложений с открытым исходным кодом, но мой работодатель не хочет открывать исходный код этого конкретного приложения по разным причинам).
Я бегло просмотрел qdbm, но не похоже, что он удовлетворит мои потребности - много ключей (несколько миллионов) и большие элементы данных (> 1-5 мегабайт). Прежде чем продолжить поиск, я решил, что спрошу, потому что, похоже, существует масса библиотек, подобных dbm.
Ответы 9
SQLite является общественным достоянием, что означает, что вы можете использовать его для любых целей, и он широко используется и поддерживается.
Другая проблема заключается в том, что BDB - это не СУБД SQL, а механизм хранения. Так что, если он не написал реализацию SQL поверх BDB, кажется, что будет немного больше работы по переносу на SQL, а не на другой механизм хранения.
@Ferruccio, ему не нужно портировать на SQL, он может просто реализовать BDB-подобный API поверх SQL. с легкостью.
Berkeley DB теперь поддерживает SQL, а также API ключ / значение. Фактически, он использует код SQLite поверх B-дерева Berkeley DB, поэтому теперь вы можете запускать базы данных SQLite размером в ТБ не только в тех случаях, когда «несколько десятков ГБ» вполне достаточно. (Отказ от ответственности: я являюсь менеджером по продукту Berkeley DB в Oracle.)
Похоже, что SQLite поддерживает базы данных размером ТБ - sqlite.org/features.html
Я обнаружил, что блокировка Berkeley DB ненадежна по сравнению с SQLite.
@Greg Hewgill Почему нет официально протестированной вещи для встраивания sqlite в Java-приложение. Не могли бы вы пролить свет на этот вопрос. Это было бы большим подспорьем.
db4o довольно дешевый и быстрый, но его можно использовать только с java или .net.
db4o - совершенно неподходящая альтернатива BerkeleyDB. Кроме того, db4o не предлагает модели лицензирования без лицензионных отчислений. Они взимают плату за каждое развертывание.
Жар-птица - ваш лучший друг.
Firebird - очень хорошая база данных SQL. Не очень хорош в качестве БД для хранения, но, вероятно, лучше, чем у большинства из-за очень хорошей поддержки BLOB.
Не могли бы вы подробнее рассказать о том, что «не очень хорош в качестве БД для хранения»? Кроме того, я хотел бы узнать больше о том, чем Firebird НЕ хорош (цена? Размер? :))
Вы можете посмотреть Токийский кабинет. Это преемник qdbm / gdbm, и если вы решите масштабировать его, у вас будет хороший сетевой интерфейс.
Редактировать:
Другой вариант - Киотский кабинет; разработан одним и тем же человеком, но якобы проще в использовании.
Postgres или HSQLDB и возможно даже База данных H2
Вы можете значительно повысить производительность любого dbm (даже qdbm) и улучшить параллелизм с помощью простого уровня косвенности: просто возьмите свои ключи и хешируйте их, а затем используйте data_dir/H(key)/ в качестве базы данных для хранения этих ключей. Для достижения наилучших результатов ограничьте вывод хэша небольшим значением (скажем) 255.
Этот подход имеет ряд преимуществ, которые легко подытожить:
- Концептуально простой
- Легко внедрить и протестировать
- Не блокирует всю базу данных для обновлений
- Может поддерживать гораздо большие базы данных
- Легко заменить компонент DBM
Вероятно, хэш даже не обязательно должен быть криптографически защищенным; просто в основном униформа. DJB cdb хеш работает хорошо в большинстве случаев.
Интересное предложение, но оно немного противоречит вопросу. Достоинства использования хеш-таблицы по сравнению с сортированной структурой типа btree - это отдельная тема.
Если вы работаете в Windows, вы можете использовать встроенный движок базы данных esent. http://blogs.msdn.com/windowssdk/archive/2008/10/23/esent-extensible-storage-engine-api-in-the-windows-sdk.aspx
Вы можете попробовать JDBM. Это бесплатное (Apache 2) хранилище ключей и значений с сохранением на диске. Простой API и высокая производительность
C / C++
- http://sphia.org/ - хранилище ключей / значений, написанное на языке C и лицензированное BSD.
- https://code.google.com/p/leveldb/ Написано на C++, также под лицензией BSD
- http://luxio.sourceforge.net/ Написано на C++, LGPL, быстрее, чем Berkeley DB
- http://symas.com/mdb/ Написано на C, лицензия - Общественная лицензия OpenLDAP (BSD-Like)
- https://github.com/davidar/sdbm Написано на C, общественное достояние, повторная реализация «ndbm»
- http://repetae.net/computer/vsdb/ Написано на C, Лицензия неизвестна, Экспериментальная
- https://github.com/stevedekorte/skipdb Написано на C, под лицензией BSD, хранилище ключей и значений с использованием индексов Skip-List
- http://unqlite.org/ написано на C / C++, Embedded NoSQL Database Engine, под лицензией BSD, аналогично SQLite.
- http://hamsterdb.com/ Написано на C / C++, Embedded NoSQL Database Engine, Apache License 2.0.
Ява
- https://github.com/dain/leveldb Порт Java для LevelDB, лицензия Apache 2.0
- https://github.com/jingwei/krati Бывший проект LinkedIn, лицензия Apache 2.0
- http://www.mapdb.org/ Встроенная база данных Java, лицензия Apache License 2.0, поддерживает хранилище значений ключей, очень эффективную сериализацию объектов
- https://github.com/OpenHFT/Chronicle-Map, LGPL v3, встроенное хранилище ключей и значений на чистом Java, быстрее, чем Berkeley DB
- https://github.com/jetbrains/xodus, Apache License 2.0, встроенная база данных без транзакционной схемы Java, быстрее, чем Berkeley DB
- https://github.com/lmdbjava/lmdbjava, привязка JNI для LMDB, лицензия Apache 2.0
Хорошая идея, но SQLite явно не рекомендуется для больших баз данных. У нас будет около 50 ГБ; извините, вероятно, это не было ясно в исходном сообщении.