Хранение множества мелких и средних файлов, как оптимально: файловая система или база данных?

Question

[ErichZann]

Как оптимально хранить CSV файлы на сервере: в базе данных Postgres или локально на сервере, а в базе хранить просто путь к файлу (файлы будут в zip архиве и архивы размером от 5 КБ до 250кб, изредка 1-2 мб)?
В CSV файле данные из базы на основе 5-10 фильтров (в итоге возвращает от 5 до 5000 записей, где для каждой записи около 120 столбцов из разных таблиц). На фронтенде есть таблица c 5 столбцами (имя, фильтры, дата создания, столбец с иконками скачивания и удаления) , где при клике по иконке скачивания должен скачиваться архив с данными для заранее заданных фильтров (архив нужен, так как может быть много мелких файлов, до 20-40, например отдельный CSV файл для каждой компании производителя техники )

Ежемесячно будет формироваться около 5000-10000 файлов, храниться они будут 6 месяцев, после чего удаляться, то есть более 100 000 файлов в базе или файловой системе не ожидается.

Хранить готовые файлы на сервере хочу из-за скорости. Мне кажется, что гораздо быстрее повторно скачать уже сформированный файл который хранится на сервере, чем каждый раз при скачивании файла 1. отправлять запрос к базе данных с фильтрами 2. на основе отфильтрованных данных сформировать CSV файл(ы) 3. заархивировать файл(ы) и 4. затем скачать. Или я неправильно думаю?

Сам склоняюсь хранить файлы в файловой системе основываясь на данной теме: https://softwareengineering.stackexchange.com/a/150724

Comments

[Армянское Радио]

А точно ли нужно выборки из БД сохранять в CSV и потом обратно складывать в БД уже в виде файлов?

Выглядит как ОЧЕНЬ СИЛЬНО преждевренменная оптимизация, особенно, если выборка занимает пару сотен миллисекунд.

[ErichZann]

Армянское Радио, там есть тонкость, что база постоянно меняется (записи обновляются, добавляются, кое-какие удаляются) , и данные которые пользователь условно запросил 1 августа и 1 сентября, будуте отличаться. Файлы хранятся как подобие архива, что можно будет скачать файл от 1 августа из БД/файловой системы и сравнить с файлом за 1 сентября (как изменилось количество записей и пара ключевых полей).

[Армянское Радио]

ErichZann, Добавить к данным колонку с датой, и получится магическое чудо - данные обретут историчность.

[Slava Rozhnev]

Read about Materialized Views

Answer 1

[Dimonchik]

Хранить готовые файлы на сервере хочу из-за скорости. Мне кажется, что гораздо быстрее повторно скачать уже сформированный файл который хранится на сервере, чем каждый раз при скачивании файла 1. отправлять запрос к базе данных с фильтрами 2. на основе отфильтрованных данных сформировать CSV файл(ы) 3. заархивировать файл(ы) и 4. затем скачать. Или я неправильно думаю?

правильно думаешь
но - случаи когда "хранить не в ФС" - есть, банальные - доступ с разных серверов, там уже иногда проще запросить файл одним запросом, чем вначале запросить базу, а потом файл по микросервису или NFS, однако - и в этом случае их не хранят чисто в БД, а хранят в object store, Amazon S3 и все такое (Есть и локальное) - obj store, конечно, похоже на FS но не совсем FS - этакая смесь алгоритмов рейда, БД и микросервиса

это я все написал к тому, что файлы ВСЕГДА хранят в FS, быстрее и наименее нагруженного решения нет,
КРОМЕ - случаев см. выше

Comments

[ErichZann]

Спасибо за подробный ответ

Answer 2

[mayton2019]

(файлы будут в zip архиве и архивы размером от 5 КБ до 250кб, изредка 1-2 мб)?

Да здесь файловая система будет лучше. Zip-архив для БД будет все равно балластом. Движки БД обычно не способны загядывать внутрь сложного архива-блоба. Поэтому фаза вычитывания и распаковки все равно будет. А если такой фазы нет - то тогда и БД выглядит ненужным балластом. Ведь ее суммарная стоимость владения (TCO) всегда выше чем у файловой системы.

Очень зрелой выглядит идея использования облачных файловых систем (Amazon S3, Azure Blob Storage) но тут надо смотреть просто в цены и в удобство поисковых операций. Например S3 вобщем то является скорее хеш-таблицей на диске чем файловой системой. Поэтому группировать файлы в фолдеры для листинга будет так себе идея. Вообще эти ФС строго расчитаны на знание path. В идеале если ваше приложение изначально знает формулу как path формируется.

Хранить готовые файлы на сервере хочу из-за скорости. Мне кажется, что гораздо быстрее повторно скачать уже сформированный файл который хранится на сервере, чем каждый раз при скачивании файла 1. отправлять запрос к базе данных с фильтрами 2. на основе отфильтрованных данных сформировать CSV файл(ы)

Верное направление мысли. Почитай еще как NGinx работает с атрибутами ETag, If-Modified-Since. Это потребует изменения логики клиента, но результат будет более оптимизированный чем просто даже с кешом.

Comments

[Армянское Радио]

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

[mayton2019]

Армянское Радио, S3 масштабируется бесконечно. А база в какой-то момент может стать узким местом и (я готов спорить ведь я был DBA) что ничегошеньки вы тут не поделаете. В чем-то архитектурный шаблон автора напоминает facebook и vk. Они тоже быстро поняли что база не вытягивает и просто вынесли контент в статическую форму и на более примитивные хранилища.

[ErichZann]

Спасибо за подробный ответ

Answer 3

[Александр Ананьев]

Я бы выступил за использование файловой системы. При использовании базы данных надо продумывать как и куда делать бэкапы, т.к. если полетит файл бд, то его придется откуда-то восстанавливать.

Comments

[Akina]

При использовании базы данных надо продумывать как и куда делать бэкапы, т.к. если полетит файл бд, то его придется откуда-то восстанавливать.

Ну да... а если БД полетит при хранении файлов в ФС, то базу типа не надо восстанавливать? какое-то весьма сомнительное обоснование...

[Александр Ананьев]

Akina, Ну бд с файлами будет занимать много больше места, чем бд, просто содержащая пути к файлам.

Answer 4

[Griboks]

Конечно база данных. Где же еще хранить свои данные?) Файлы используются в просты проектах, когда лень поднимать бд. А у вас уже есть готовые структурированные данные, которые осталось только загрузить. Скорость советую измерить на сыром запросе и сравнить с файлами.

Comments

[Dimonchik]

тонко! АГОНЬ!