Как хранить миллионы мелких файлов максимально компактно и производительно?
Есть порядка 20 миллионов мелких файлов (10-100 кб в среднем, хотя бывают "пики" порядка 500 кб, но они редки). Они не перезаписываются, создали-уничтожили все. Будем считать, что это все read-only. Надежность и масшабируемость не нужна. Первоначально планировали просто разбить всю структуру на подкаталоги и так все хранить на сервере с SSD, отдавая при необходимости файл (нагрузки тоже небольшие). Но оказалось, что overhead получается слишком большим: файлы расползаются на блоки файловой системы. В идеале было бы здорово хранить все в одном файле, с какой-то легкой компрессией, в памяти - индексы (адреса) нужных "файлов" в этом едином блоке, и уже обращаться к ним при необходимости. Техническая реализация понятна и не очень сложна, но не хотелось бы переизобретать велосипед, а использовать какое-то готовое простое решение, пусть и не точно соответствующее описанному выше, но позволяющее хранить все эти файлы с минимальным overhead'ом.
Минимальный оверхед на файл вот тут, насколько мне известно: code.google.com/p/weed-fs
НЕТ поддержки POSIX (HTTP-only)
Там же в описании проекта есть несколько альтернатив, с плюсами и минусами.
спасибо за ссылку, практически то что нужно. Опасения вызвал только какой-то мутный баг в issues, якобы данные могут теряться при параллельной записи. Подожду пока ситуация прояснится, в целом все нравится
попробуйте squashfs. Минус - это то что нужно будет периодически пересоздавать её для обновления данных, т.к. эта fs - Read-Only. Плюс - компрессия.
Попробуйте хранить в БД данные. Например у MySQL есть тип таблиц Archive - осуществляется поиск по 1 primary key, в свою очередь данные также сжимаются, и также таблица read-only, записи могут добавляться, но не изменяться.
Вы можете организовать несколько томов\таблиц, и обновлять их по мере необходимости, перегоняя данные из одной таблицы\тома в другой.
К mysql у меня весьма критическое отношение, несколько раз наблюдал ее глюки и внезапные падения, которые исчезли полностью после перехода на postgres с теми же данными. На squashfs посмотрю, спасибо.
У Postgres один движок БД, соотвественно вы можете хранить все данные там, но забудьте о компрессии. Далее, у если вы изменяете данных (удаляете записи), но периодически вам нужно вызывать vacuum (что может отрицательно сказаться на производительности)
Средний
