Задать вопрос

Как хранить миллионы мелких файлов максимально компактно и производительно?

Есть порядка 20 миллионов мелких файлов (10-100 кб в среднем, хотя бывают "пики" порядка 500 кб, но они редки). Они не перезаписываются, создали-уничтожили все. Будем считать, что это все read-only. Надежность и масшабируемость не нужна. Первоначально планировали просто разбить всю структуру на подкаталоги и так все хранить на сервере с SSD, отдавая при необходимости файл (нагрузки тоже небольшие). Но оказалось, что overhead получается слишком большим: файлы расползаются на блоки файловой системы. В идеале было бы здорово хранить все в одном файле, с какой-то легкой компрессией, в памяти - индексы (адреса) нужных "файлов" в этом едином блоке, и уже обращаться к ним при необходимости. Техническая реализация понятна и не очень сложна, но не хотелось бы переизобретать велосипед, а использовать какое-то готовое простое решение, пусть и не точно соответствующее описанному выше, но позволяющее хранить все эти файлы с минимальным overhead'ом.
  • Вопрос задан
  • 3743 просмотра
Подписаться 5 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 2
@justthefish
Минимальный оверхед на файл вот тут, насколько мне известно:
code.google.com/p/weed-fs
НЕТ поддержки POSIX (HTTP-only)
Там же в описании проекта есть несколько альтернатив, с плюсами и минусами.
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
попробуйте squashfs. Минус - это то что нужно будет периодически пересоздавать её для обновления данных, т.к. эта fs - Read-Only. Плюс - компрессия.

Попробуйте хранить в БД данные. Например у MySQL есть тип таблиц Archive - осуществляется поиск по 1 primary key, в свою очередь данные также сжимаются, и также таблица read-only, записи могут добавляться, но не изменяться.

Вы можете организовать несколько томов\таблиц, и обновлять их по мере необходимости, перегоняя данные из одной таблицы\тома в другой.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы