Каков наилучший способ хранения медиа-файлов в базе данных?

Question

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

Я также думал о возможности иметь «ссылки» на эти файлы, но, возможно, это принесет больше проблем, чем решений. Любой опыт в этом направлении будет приветствоваться:)

Примечание. База данных будет MySQL.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

X\XYZ.Wav

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

C: \ MyProgram \ Data \ Sounds \

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

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

Answer 4

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

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

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

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

Answer 5

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

или

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

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

Вы можете хранить ссылки (частичные пути к данным) и затем извлекать эту информацию. Упрощает перемещение объектов на дисках и возможность доступа к ним.

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

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

Answer 6

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

Answer 7

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

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

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

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

---

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

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

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

Answer 8

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

Answer 9

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

https://min.io/

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