Надежная и эффективная база данных ключ-значение для Linux?[закрыто]

https://stackoverflow.com/questions/1690605

18-09-2019
|

Вопрос

Мне нужна быстрая, надежная и экономичная по объему памяти база данных ключ-значение для Linux.Мои ключи имеют размер около 128 байт, а максимальный размер значения может составлять 128 КБ или 256 КБ.Подсистема базы данных не должна использовать более 1 МБ оперативной памяти.Общий размер базы данных составляет 20 ГБ (!), но одновременно осуществляется доступ только к небольшой случайной части данных.При необходимости я могу переместить некоторые большие двоичные объекты данных из базы данных (в обычные файлы), так что размер уменьшится максимум до 2 ГБ.База данных должна пережить системный сбой без каких-либо потерь в недавно неизмененных данных.У меня будет примерно в 100 раз больше операций чтения, чем записи.Это плюс, если он может использовать блочное устройство (без файловой системы) в качестве хранилища.Мне не нужна функциональность клиент-сервер, просто библиотека.Мне нужны привязки Python (но я могу реализовать их, если они недоступны).

Какие решения мне следует рассмотреть и какое из них вы рекомендуете?

Кандидаты, которых я знаю, которые могли бы сработать:

Токийский кабинет министров (Привязки Python являются пытк, смотрите также пример кода pytc, поддерживает хэши и B +-деревья, файлы журналов транзакций и многое другое, размер массива bucket фиксируется во время создания базы данных;автор должен закрыть файл, чтобы дать другим шанс;множество небольших операций записи с повторным открытием файла для каждой из них выполняются очень медленно;сервер Tyrant может помочь с большим количеством небольших записей; сравнение скорости между Tokyo Cabinet, Tokyo Tyrant и Berkeley DB)
VSDB (безопасно даже в NFS, без блокировки;а как насчет барьеров?;обновления происходят очень медленно, но не так медленно, как в cdb;последняя версия в 2003 году)
BerkeleyDB (обеспечивает аварийное восстановление;обеспечивает транзакции;в bsddb Модуль Python предоставляет привязки)
TDB от Samba's (с транзакциями и привязками Python некоторые пользователи опыт коррупции, иногда mmap()s весь файл, the repack операция иногда удваивает размер файла, приводит к загадочным сбоям, если размер базы данных превышает 2G (даже в 64-разрядных системах), кластерная реализация (CTDB) также доступно;файл становится слишком большим после множества изменений;файл становится слишком медленным после большого количества хэш-конфликтов;нет встроенного способа перестроить файл;очень быстрые параллельные обновления за счет блокировки отдельных сегментов хэша)
aodbm (append-only so выживает при сбое системы с привязками Python)
hamsterdb хомяк (с привязками к Python)
C-дерево (зрелое, универсальное коммерческое решение с высокой производительностью, имеет бесплатную версию с уменьшенной функциональностью)
старый TDB (с 2001 года)
биткойн - касса (логарифмически структурированный, написанный на Erlang)
различные другие реализации СУБД (такие как GDBM, NDBM, QDBM, SDBM Perl или Ruby;вероятно, у них нет надлежащего аварийного восстановления)

Я не буду ими пользоваться:

MemcacheDB - Память в кэше (клиент-сервер, использует BereleleyDB в качестве серверной части)
цкб (необходимо восстанавливать всю базу данных при каждой записи)
http://www.wildsparx.com/apbcdb/ (то же самое)
Редис (сохраняет всю базу данных в памяти)
Базы данных SQLite (это становится очень медленным без периодической очистки, см. автозаполнение в строке местоположения в Firefox 3.0, хотя версии 3.1 и более поздние версии sqlite позволяют auto_vacuuming;остерегайтесь:небольшие транзакции записи могут быть очень медленными;остерегайтесь:если загруженный процесс выполняет много транзакций, другие процессы испытывают голод, и они никогда не смогут получить блокировку)
MongoDB (слишком тяжелый вес, рассматривает значения как объекты с внутренней структурой)
Жар - Птица (СУБД на основе SQL, слишком тяжеловесная)

К вашему сведению, a недавняя статья о базах данных ключ-значение в журнале Linux magazine.

К вашему сведению, ан список более старого программного обеспечения

К вашему сведению, a сравнение скорости MemcacheDB, Redis и Tokyo Cabinet Tyrant

Связанные вопросы по StackOverflow:

Решение

Мне повезло с решением Tokyo Cabinet / pytc.Это очень быстро (немного быстрее, чем использование модуля shelve с использованием anydbm в моей реализации), как для чтения, так и для записи (хотя я тоже гораздо больше читаю).Проблемой для меня была спартанская документация по привязкам python, но есть достаточно примеров кода, чтобы понять, как сделать то, что вам нужно.Кроме того, tokyo cabinet довольно прост в установке (как и привязки к python), не требует сервера (как вы упомянули) ~~и, похоже, активно поддерживается~~ (стабильный, но больше не находится в активной разработке).Вы можете открывать файлы в режиме только для чтения, разрешающем параллельный доступ, или в режиме чтения / записи, запрещающем другим процессам доступ к базе данных.

Летом я рассматривал различные варианты, и совет, который я тогда получил, был таким:попробуйте различные варианты и посмотрите, что работает лучше всего для вас.Было бы неплохо, если бы существовал просто "лучший" вариант, но все ищут немного разные функции и готовы идти на разные компромиссы.Тебе виднее.

(Тем не менее, другим было бы полезно, если бы вы поделились тем, что в итоге сработало для вас лучше всего, и почему вы предпочли это решение другим!)

Другие советы

LMDB - это самая экономичная по объему памяти база данных в мире http://symas.com/mdb/inmem/

а также зарекомендовал себя как самый надежный - полностью защищенный от сбоев.http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf

Из тех, о которых вы упомянули, Токийский кабинет министров задокументировал проблемы с коррупцией https://www.google.com/search ?q=cfengine+ Токио+ кабинет министров + коррупция

BerkeleyDB также имеет хорошо документированные проблемы с коррупцией, как и Bitcask.(И в любом случае bitcask - это база данных только в памяти, поэтому она бесполезна для ваших требований к 1 МБ оперативной памяти.)

LMDB также хорошо поддерживается в Python, с несколькими доступными различными привязками.https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

Отказ от ответственности - я являюсь автором LMDB.Но это задокументированные факты:LMDB - это самое маленькое, наиболее эффективное и надежное хранилище ключей / значений в мире, и ничто другое не сравнится с ним.

cdb может обрабатывать любую базу данных объемом до 4 ГБ, что делает ее слишком маленькой для рассматриваемого объема в 20 ГБ.

Riak работает на Linux и позволяет вам динамически добавлять узлы

как насчет dbm.ndbm в Python 3.0 ?

Другое предложение заключается в TDB (часть проекта Samba).Я использовал его через tdb модуль, однако я не могу сказать, что я проверял его надежность при сбоях;проекты, в которых я его использовал, не имели таких требований, и я не могу найти соответствующую документацию.

как насчет SQLite?

Я использовал bsddb.hashlib() с Python, это сработало довольно хорошо.

Вам может понравиться djb's цкб, который обладает свойствами, о которых вы упоминаете.

В мой запрос к кроссплатформенной базе данных в стиле ISAM (аналогично), я также получил предложения по встроенной версии Жар - Птица и Бойкий.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow