Какой наилучший способ хранения большого количества небольших файлов?

Question

[FiTADiNE]

Доброго времени суток!

Ежедневно стандартными средствами NodeJS будет создаваться порядка ~100k архивов zip в день.
Размер каждого архива <1кб.
Хранить каждый из них нужно порядка месяца.

Вопросы:
1. SSD или HDD лучше для этого использовать?
2. Какая файловая система подойдет наилучшим образом?
3. Как быстро диск от подобного погибнет?

Каждый архив должен быть доступен для скачивания по ссылке и с конкретным названием, поэтому способ с хэшэм не шибко годится (./e3/b0/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855).

Answer 1

[Евгений Вольф]

SSD или HDD лучше для этого использовать?

HDD обычно служат дольше и дешевле за единицу объёма, SSD - быстрее. По этому, "лучше" зависит от контекста.

2. Какая файловая система подойдет наилучшим образом?

Можно попробовать Btrfs, там ограничения на кол-во файлов нет. Не могу пока ничего сказать кардинально хорошего или плохого про эту ФС... для пробы поставил на одну боевую машину, где-то с год с небольшим стоит, полёт нормальный.

3. Как быстро диск от подобного погибнет?

У меня в обычном сервере (небольшая однопроцессорная машина в 4 ядра) лет 5 HDD'шник простоял, под приличной нагрузкой, обычный WD. Потом "от греха подальше" я его сменил.

Comments

[FiTADiNE]

Спасибо!
Какой контекст нужен? 100к файлов в течение дня будут создаваться постепенно, но не равномерно. Возможно больше, возможно меньше.

[roswell]

Кстати, да, WD Red -- отличная серия для таких затей. Я уже системник сменил, а оба винта до сих пор живы.

[Евгений Вольф]

FiTADiNE, думаю HDD Вам должен подойти

[FiTADiNE]

Евгений Вольф, ну, тут говорят, что, по всей видимости, лучше все в БД пихать, а не тупо в файловой системе оставлять... А Mongo на SSD будет.

[Евгений Вольф]

FiTADiNE, бинарные данные в БД? Не уверен, что это глобально добавит производительности. У нас вместо "много маленьких файлов" будет один (или несколько) большой файл. Плюс во время скачивания файлы будут доставаться из базы, а это ещё одно промежуточное звено... Единственная проблема, которую отчасти решает база - это "количество файлов в одной папке", само хранение в БД - думаю скорости глобально не добавит.

[FiTADiNE]

Евгений Вольф, поэтому и сделал тут пост, чтобы найти самый оптимальный, быстрый и "безболезненный" вариант. А мнений столько, сколько и людей, а я до сих пор не нашел ответа)

[Евгений Вольф]

FiTADiNE, HDD + 100k файлов в одну папку - вполне себе нормально должно работать.

[Евгений Вольф]

FiTADiNE, хотя... тут ещё вопрос в том, насколько часто Вы будете эти файлы скачивать. Если не очень часто - можно их перекодировать в Base64 и хранить в любой БД, в MySQL или PostgreSQL например (в колонке формата CHAR), не обязательно в Mongo. А при выдаче соотв. декодировать обратно и отдавать скриптом. С учётом объёма файла в ~1Кб - это будут довольно мизерные накладные расходы памяти и как бонус - можно будет прикручивать к файлам мета-данные, например дату создания, имя, автора и т.д. Но, как я уже говорил выше - всё зависит от того, как часто Вы эти файлы скачивать будете.

[FiTADiNE]

Евгений Вольф, 100к файлов это примерная нагрузка. Вполне вероятно, что будет больше (Не исключено, что 500к в день x 30 дней хранения [возможно вплоть до 180 дней]). Насчет частоты скачивания - далеко не все 100к будут скачивать хотя бы 1 раз. Вряд ли вообще будут часто скачивать, но наличие очень важно. + архивы будут запаролены, это имеет значение какое-то?

[Евгений Вольф]

FiTADiNE, нет, бинарная составляющая как такового значения не имеет (в том смысле с паролем архив или нет, и архив ли это вообще). 500k записей, с учётом размера записи в ~1Кб... условно говоря это будет 500Мб - вообще "пшик", а с учётом того, что Вы их храните какое-то время (т.е. не вечно) и с учётом того, что даже после перекодировки в Base64 размер файла будет больше на 1/3, это всё равно достаточно мало, даже если собрать по 500k файлов 180 дней подряд. Можно взять любую БД, например PostgreSQL, и писать всё это добро туда... Как я уже говорил ранее, с учётом размеров файлов (~1Кб до перекодировки и ~1.3Кб после) - операция перекодирования "туда-суда" будет занимать доли секунды. Кстати, подобный алгоритм активно применяется в электронной почте.

[FiTADiNE]

Евгений Вольф, большое спасибо!

Answer 2

[Vladimir Zhurkin]

Вопросы:
1. SSD или HDD лучше для этого использовать?
2. Какая файловая система подойдет наилучшим образом?
3. Как быстро диск от подобного погибнет?

Лучше использовать гибрид в вашем случаи.
SSD использовать как кэш для HDD + использовать часть памяти под кэш для SSD.
ZFS все это умеет делать.

Опять же ZFS или XFS . При XFS обязательно ИБП, хотя с ФС все стало лучше но все же.

Если делать связку, то нормальный SSD с нормальным сборщиком мусора , будет умирать очень долго.

Есть одно но>

Ежедневно стандартными средствами NodeJS будет создаваться порядка ~100k архивов zip в день.
Размер каждого архива <1кб.
Хранить каждый из них нужно порядка месяца.

При таком подходе, лично я бы все использовал в БД.

Comments

[roswell]

Из БД устроить файловую систему? *facepalm*

[Vladimir Zhurkin]

roswell, Передавать данные в БД , ваш КЭП.

[FiTADiNE]

В очередной раз убеждаюсь, что сколько людей, столько и мнений :)
Может есть какой-то прям наилучший вариант? Близкий к идеалу, что ли. В сервере будет несколько дисков, один из которых планировал использовать именно под это по большей части.

[Vladimir Zhurkin]

FiTADiNE,

Может есть какой-то прям наилучший вариант? Близкий к идеалу, что ли.

Близкое к идеалу, это все убирать в БД. У вас же смешные объемы, что бы насиловать ФС и вообще думать о ФС. Делать резервное копирование проще, поиск по инфе проще.
Вот, что выбрать в качестве БД, это уже другой вопрос и нужны тесты. Но я бы склонился в сторону PSQL или MongoDB. Пслд надо выбирать, если есть четкое понимание в чем отличие SQL vs NoSQL

[FiTADiNE]

Vladimir Zhurkin, в проекте будет использоваться MongoDB. Немного не понимаю, почему в БД убирать лучше? И как доступ конечному пользователю давать для скачивания?

[Vladimir Zhurkin]

FiTADiNE, Давать рекомендации , когда не ясна общая картина, очень плохо.

Почему лучше убирать в БД ? Тут мы сейчас затронем фундаментальное, а зачем вообще БД ? Почему бы нам все не хранить в файлах ? Как минимум вы для вас в вашем варианте снизите нагрузку на дисковую подсистему и сможете более гибко обрабатывать что угодно с этими данными. Да же сжатие даст вам больше результата в БД, чем то что вы задумали.

Для юзера, конечно надо будет делать что-то, где он может будет выбрать интересующиеся и ему этот список формировать и отдавать. Но и в этом случаи , тут точно нужна БД.
Потом окажется, что хранить надо не месяц. Прикрутить еще что-то итд итп.

[FiTADiNE]

Vladimir Zhurkin, юзер должен получать ссылку для скачивания на конкретный архив [кнопка "Скачать архив"]. Остальные ему видеть незачем. В общем, лучше пихать в БД, а ФС без разницы, верно? MongoDB нормально подойдет?

[Vladimir Zhurkin]

FiTADiNE,

В общем, лучше пихать в БД, а ФС без разницы, верно? MongoDB нормально подойдет?

Ну ФС уже подбирается для БД. Тут нет каких то универсальных решений.
Подойдет ли mongodb для вас? Ответ один - делайте прототип и смотрите как он будет работать.