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

Question

[Артем Немцов]

Всем привет!
Используя технологию ASP.NET.CORE с MVC, необходимо разработать сервер для прослушивание аудио файлов, который будут использовать множество пользователей. Как правильно организовать хранение аудио файлов?

Имеется несколько вариантов:
1) Хранить аудио в папках, сохраняя значения путей в БД (Что на мой взгляд не правильно!)
2) Хранить в NO-SQL базе данных, например MongoDB. Если выбрать этот путь, можно ли удобно использовать только эту базу данных для работы всего сервера, без дополнительной sql базы данных , такой как Postgres итд.
3) Использовать сторонний сервер, например Minio.
4) Другой вариант

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

Comments

[Дмитрий]

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

Answer 1

[ArgosX]

1) Хранить аудио в папках, сохраняя значения путей в БД (Что на мой взгляд не правильно!)

именно ваш взгляд не правильный

Comments

[Артем Немцов]

Почему вы считаете, что именно хранение аудио в папках будет лучшим решением?

[ArgosX]

Артем Немцов, ответ лежит в принципах работы баз данных. как вы себе представляете хранить аудиофайлы или скажем графику в текстовых файлах?
Кроме того достаточно посмотреть как это реализовано в корпоротивных системах например Незабудка, Фантом, drag-net (запись телефонных переговоров и их дальнейшее прослушивание). Файлы там просто лежат в папках а в бд хранится инфа по ним (название путь дата итд итп)

PS я так понимаю проблема в том что бы пользователи не могли просто удалить эти файлы? Для того что бы этому помешать есть разные способы

[Артем Немцов]

ArgosX, Благодарю за ответ!

[raiboon]

Хранение в файловой системе значительно усложняет вопрос масштабирования, шардированмя, репликации и других слов, о которых вы вряд-ли слышали.
Зато слышали о незабудках, забавно.
Сейчас не 90ые, неиспользование minio, Gridfs и тп - уже пошлятина

[Дмитрий]

raiboon, как бы база тоже не в космосе хранит данные

[raiboon]

Дмитрий, ну вы же не пишите каждый раз драйвер для работы с жёстким диском?
Так и тут, абстрагируйтесь от низкоуровневых деталей.

[Дмитрий]

raiboon, забрать файл с жёсткого это целая проблема?

[raiboon]

Дмитрий, проблема в масштабировании хранилища, шардированмя, репликации данных.

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

Это не всегда надо, раскатал какой-нибудь ВордПресс или ларавел на шареде и радуешься.

Но в production проектах это все нужно

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

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

Answer 2

[raiboon]

Просто хранить на жёстких дисках - неудобно и не сильно надёжно.
Для кого разрабатывали ceph, minio, Gridfs, riakcs, etc?

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

Comments

[Артем Немцов]

Благодарю за ответ!

Answer 3

[d'Ivan]

Хранить аудио-файлы локально на сервере в отдельной папке - это плохо масштабируемое решение, хотя для старта сойдет.
Как отметил raiboon , лучше использовать протокол S3. Лучше облачный хостинг, потому что нужно еще правильно отдавать контент, чтобы отдачей контента занимался отдельный сервер (или сервера), ответственный за раздачу контента и всё это было быстро масштабируемо. Бизнес-логика веб-приложения тогда будет находиться отдельно от серверов отдачи контента.
При создании объекта аудио-файла можно генерировать GUID и его использовать как идентификатор для поиска в коллекции. Отдельный компонент может быть ответственным за построение пути к файловому объекту в S3 по искомому GUID, будет также включать bucket , регион.
Префикс пути будет постоянным, наподобие такого:
"<bucket>.<region>.hostname/<parent_dir>/"
Суффикс - <GUID>

Если все делать по-малому (в домашних условиях), то можно хранить файлы в СУБД, конечно. Файлы лучше отдавать кэширующим сервером: Nginx, Varnish и др. При выборе Minio, RiakCS, Ceph, развертывание и поддержка инфраструктуры ложится на плечи сис. админа и это нужно учитывать.