LINUX.ORG.RU

Хранилище или СУБД для множества blob данных

 , , ,


0

1

Просьба посоветовать, что посмотреть из дисковых хранилищ/key-value СУБД со следующими требованиями:

  • Хранение blob значений по ключам или путям (число или строка, не важно).
  • Сущностей для хранения много (порядка 10 млн), все они - бинарные блобы разных размеров - от 100Кб до 1Гб.
  • Нужен быстрый random-access на чтение/запись. Намного быстрее, чем хранить каждую из сущностей в виде отдельного файла в фс (это проверено, очень медленно при росте числа файлов).
  • Все хранится на одной машине, не распределенно
  • Не слишком большой оверхед по занимаемому месту на диске
  • С или C++ API

Копалось в сторону штук типа leveldb, проприетарных хранилищ и собственного велосипеда, все показывает сильное падение скорости доступа при росте числа значений или просто константно-низкую скорость (порядка 0.1 от скорости диска)



Последнее исправление: CatsCantFly (всего исправлений: 1)

это проверено, очень медленно при росте числа файлов

Проверено на чём? Вряд ли можно придумать для решения что-то быстрее, чем ФС на базе b-tree.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Можно конечно. ФС очень общий механизм. BTree не самая быстрая штука, и призвана уменьшить число дискового I/O при lookup по файловой таблице. В моей же задаче можно просто всю таблицу ключ->смещение в хранилище держать в памяти все время работы, чего себе не может позволить ФС. ФС решает задачу минимального расхода дискового пространства, в том числе фрагментируя файлы. В моей задаче перерасход в разумных пределах допустим, фрагментация не нужна и ее быть не должно. Ну и тд.

CatsCantFly
() автор топика
Последнее исправление: CatsCantFly (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Вряд ли можно придумать для решения что-то быстрее, чем ФС на базе b-tree.

Очевидно, что нет. Это не имеет каких-либо основание.

anonymous
()
Ответ на: комментарий от CatsCantFly

В моей же задаче можно просто всю таблицу ключ->смещение в хранилище держать в памяти все время работы

фрагментация не нужна и ее быть не должно

Тогда не понятно, в чём вопрос? Работай с диском также как с оперативной памятью и всё.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.