Как лучше всего хранить медиафайлы в базе данных?

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

Вы можете сохранить их как BLOB-объекты (или LONGBLOB-объекты), а затем извлекать данные, когда вы действительно хотите получить доступ к медиафайлам.

или же

Вы можете просто хранить медиафайлы на диске и хранить метаданные в БД.

Я склоняюсь к последнему методу. Я не знаю, как это делается в целом в мире, но подозреваю, что многие другие поступили бы так же.

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

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

Вот как я это делаю. Я уверен, что у других тоже будут идеи.

Преимущества использования базы данных:

• Легко объединять звуковые файлы с другими биты данных.
• Избегайте операций ввода-вывода файлов, которые обойти безопасность базы данных.
• Нет необходимости в разделении на удалить звуковые файлы, когда база данных записи удаляются.

Недостатки использования базы данных:

• Раздутие базы данных
• Базы данных могут быть дороже файловых систем

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

http://www.dreamwerx.net/phpforum/?id=1

У меня было буквально 100 гигов, загруженных в базы данных mysql без каких-либо проблем. Дизайн и реализация являются ключевыми, сделайте это неправильно, и вы пострадаете.

Дополнительные преимущества БД (еще не упомянутые): - Лучше работает в среде со сбалансированной нагрузкой - Вы можете увеличить масштабируемость внутреннего хранилища

Каждая известная мне система, которая хранит большое количество больших файлов, хранит их вне базы данных. Вы сохраняете все запрашиваемые данные для файла (название, исполнитель, длину и т. д.) В базе данных вместе с частичным путем к файлу. Когда пришло время получить файл, вы извлекаете путь к файлу, добавляете к нему некоторый корень файла (или URL-адрес) и возвращаете его.

Итак, у вас будет столбец «местоположение» с частичным путем в нем, например «a / b / c / 1000», который вы затем сопоставите: «http: //myserver/files/a/b/c/1000.mp3»

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

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

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

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

Например, если вы храните XYZ.Wav в C: \ MyProgram \ Data \ Sounds \ X \, полный путь будет

C:\MyProgram\Data\Sounds\X\XYZ.Wav

Но вы бы сохранили путь и / или имя файла в базе данных как:

X\XYZ.Wav

В другом месте, в базе данных или в файлах конфигурации вашей программы, сохраните корневой путь, например SoundFilePath, равный

C: \ MyProgram \ Data \ Sounds \

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

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

Некоторые преимущества использования BLOB-объектов для хранения файлов

• Снижение накладных расходов на управление - используйте один инструмент для резервного копирования / восстановления и т. д.
• Нет возможности для базы данных и файловой системы быть не синхронизированными
• Транзакционные возможности (при необходимости)

Некоторые недостатки

• взрывает оперативную память ваших серверов баз данных бесполезным мусором, который может использоваться для хранения строк, индексов и т. д.
• Делает ваши резервные копии БД очень большими, а значит, менее управляемыми
• Не так удобно, как файловая система для обслуживания клиентов (например, с веб-сервером)

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

В любом случае не волнуйтесь, делайте то, что кажется лучшим в данный момент.

Некоторые базы данных предлагают встроенный веб-сервер для обслуживания больших двоичных объектов. На момент написания MySQL этого не делал.

Храните их как внешние файлы. Затем сохраните путь в поле varchar. Помещение больших двоичных объектов в реляционную базу данных обычно очень неэффективно - они только занимают место и замедляют работу, поскольку кеши заполнены и непригодны для использования. И тут ничего не добьешься - сами кляксы поискать нельзя. Однако вы можете захотеть сохранить метаданные мультимедиа в базе данных.

Лучший способ хранить аудио / видео файлы, вы можете использовать любое распределенное хранилище, которое может быть локальным или облачным.

https://min.io/

для облака: AWS S3