Мне нужна быстрая, надежная и эффективная для памяти база данных ключевых значений для Linux. Мои ключи составляют около 128 байт, а максимальный размер может быть 128 КБ или 256 КБ. Подсистема базы данных не должна использовать более 1 МБ ОЗУ. Общий размер базы данных составляет 20 Гб (!), Но одновременно осуществляется доступ к небольшой случайной доле данных. При необходимости я могу перенести некоторые данные из базы данных (в обычные файлы), поэтому размер уменьшается до 2 ГБ. База данных должна выдерживать системный сбой без каких-либо потерь в недавно измененных данных. У меня будет примерно в 100 раз больше чтений, чем пишет. Это плюс, если он может использовать блок-устройство (без файловой системы) в качестве хранилища. Мне не нужны функции клиент-сервер, просто библиотека. Мне нужны привязки Python (но я могу реализовать их, если они недоступны).
Какие решения следует учитывать, и какой из них вы рекомендуете?
Кандидаты, о которых я знаю, могут работать:
- Токийский кабинет (привязки Python pytc, см. также код примера pytc, поддерживает хэши и деревья B +, файлы журнала транзакций и т.д., размер массива ведра фиксирован во время создания базы данных, автор должен закрыть файл, чтобы дать другим шанс, много мелких записей с повторным открытием файла для каждого из них очень медленное, сервер Tyrant может помочь с множеством небольших записей: сравнение скорости между Tokyo Cabinet, Tokyo Tyrant и Berkeley DB)
- VSDB (безопасно даже на NFS, без блокировки, а что касается барьеров?), обновления происходят очень медленно, но не так медленно, как в cdb, последняя версия в 2003 году)
- BerkeleyDB (обеспечивает восстановление при сбоях, предоставляет транзакции, модуль
bsddbPython предоставляет привязки) - Samba TDB (с транзакциями и привязками Python, некоторые пользователи опытная коррупция, иногда
mmap()весь файл, операцияrepackиногда удваивает размер файла, создает таинственные сбои, если база данных больше 2G (даже в 64-битных системах), реализация кластера (CTDB), файл становится слишком большим после многих модификаций, после слишком много хеш-хартов, файл становится слишком медленным, нет встроенного способа перестроить файл, очень быстрые параллельные обновления путем блокировки отдельных хэш-кодов) - aodbm (append-only так выживает сбой системы, с привязками Python)
- hamsterdb (с привязками Python)
- C-tree (зрелое, универсальное коммерческое решение с высокой производительностью имеет бесплатную версию с ограниченной функциональностью).
- старый TDB (с 2001 года)
- bitcask (построена в журнале, написана в Erlang)
- различные другие реализации DBM (такие как GDBM, NDBM, QDBM, Perl SDBM или Ruby, возможно, они не имеют надлежащего восстановления после сбоя).
Я не буду использовать их:
- MemcacheDB (клиент-сервер использует BereleleyDB как бэкэнд)
- cdb (необходимо восстановить всю базу данных при каждой записи)
- http://www.wildsparx.com/apbcdb/ (ditto)
- Redis (хранит всю базу данных в памяти)
- SQLite (он становится очень медленным без периодического вакуумирования, см. автозаполнение в строке местоположения в Firefox 3.0, хотя версии 3.1 и более поздние из sqlite позволяют
auto_vacuuming: будьте осторожны: небольшие транзакции записи могут быть очень медленными, будьте осторожны: если занятый процесс выполняет много транзакций, другие процессы голодают, и они никогда не смогут получить блокировку) - MongoDB (слишком тяжелый, обрабатывает значения как объекты с внутренней структурой)
- Firebird (SQL-based RDBMS, слишком тяжелый)
FYI, недавняя статья о базах данных с ключом в журнале Linux.
FYI, более старый список программ
FYI, сравнение скорости MemcacheDB, Redis и Tokyo Cabinet Tyrant
Связанные вопросы по StackOverflow:
