Как хранить аудиофайлы на сервере (во время хостинга)

Question

Я думал о создании приложения для аудиоконтента .Первый вопрос, который я получаю, - как его хранить.Имеются два очевидных решения:

1. Дамп в базе данных как BLOB
2. Дамп в файловой системе и путь хранения в БД

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

Кроме того, я хотел знать, как оба решения будут работать с точки зрения масштабируемости.

Кто-нибудь знает, как это делает flickr или youtube?

Или у кого-то есть еще более креативные (масштабируемые :)) идеи?

Answer 1

В вашей файловой системе должны быть настроены процедуры резервного копирования и восстановления, если эти данные важны. (Остальная часть приложения резервируется правильно?). Поэтому вам не следует использовать базу данных только для резервного копирования и восстановления.

Хранение файлов за пределами базы данных позволяет разделить базу данных и файловые серверы, что будет плюсом в плане масштабируемости.

Answer 2

Хранение файлов в файловой системе позволит использовать сети доставки контента. Аутсорсинг хранилища может принести несколько преимуществ .

Answer 3

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

Answer 4

Это классический вопрос. И классический аргумент, с хорошими баллами за оба решения. Масштабируемость может быть достигнута с обоими решениями. Распределенные базы данных, как правило, легче обрабатывать, чем распределенные файловые системы, если вы достигнете размера, когда все мультимедийные данные не помещаются на одном сервере (но даже это открыто для обсуждения). Представьте себе MongoDB или другие масштабируемые базы данных NoSQL.

Это сводится к тому, какие функции вам нужны. Очень сложно реализовать транзакционность в файловой системе, поэтому, если это вас беспокоит, вам следует использовать базу данных.

Answer 5

Резервное копирование и восстановление файловой системы гораздо проще осуществить, чем правильное и согласованное резервное копирование базы данных.Также, если вы потеряете файл на диске, это просто файл.Если вы потеряете часть огромной таблицы, это потеря всех файлов, содержащихся или на которые есть ссылки в этой таблице (так как таблица становится нечитаемой).

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

Answer 6

Я думаю, что оба пути жизнеспособны. Но проблема резервного копирования у меня определенно есть. Оба решения являются масштабируемыми при правильном дизайне. Но большие файлы, вероятно, лучше в файловой системе.

С уважением, Morten