Оптимальное key-value хранилище как backend для объектов git?
Экспериментирую над новым проектом, подбираю БД для использования в качестве backend-а для объектов в git репозитории (данные будут храниться в виде git репозиториев для истории и стандартного импорта/экспорта данных).
Заниматься надстройками над привычным git с файловой системой не хочется, думаю над тем, чтобы с libgit2 соорудить подходящую инфраструктуру поверх какого-то key-value хранилища.
Требования:
* ключ-значение, по хэшу (строка) хранится бинарник, никаких сложных типов данных, вложенных структур и так далее
* чтение данных по первичному ключу (здорово если в виде потоков, а не всё вместе)
* запись данных (данные после записи не изменяются)
* удаление данных по первичному ключу (весьма редко)
* легкое построение кластера (желательно что-то вроде указания диска где хранить, одну из нод кластера - а там само пусть на основании конфигурации реплицирует и мигрирует данные как ему угодно, максимально plug-and-play)
* желательно чтобы читать и писать данные можно было на любой ноде, пусть само разбирается как ему удобно
* простой API
Раньше с такими вещами не работал, так что на основании опыта выбор сделать не могу.
Пока смотрю на Voldemort.
Cassandra и Riak кажутся избыточными для такой задачи.
У меня с ним есть печальный опыт обновления Debian с одной мажорной версии на другую, после чего всё содержимое Redis переместилось в /dev/null. Не уверен что именно могло привести к таким последствиям, но куча остального софта, включая MariaDB продолжают работать нормально. И это без кластера. Там только очередь задач была, не сильно критичная, но тем не менее.
К тому же читал что Redis быстро работает с данными в памяти, как только дело доходит до диска, всё грустно становится.
Не уверен после этого что хочу туда совать много-много данных.
aol-nnov: Ну норм 100 тб памяти, но это не нужно для хранения git объектов, потому что дальше последнего коммита уже на порядок меньше обращений, достаточно последние коммиты и некоторые популярные репозитории кэшировать, остальное пусть на диске будет. Но доступ к диску должен быть вменяемым.
