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

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

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

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

53
audio database multimedia mysql

8 ответов

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

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

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

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

86

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

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

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

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

16

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

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

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

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

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

X\XYZ.Wav

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

C:\MyProgram\Data\Sounds\

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

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

9

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

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

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

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

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

или

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

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

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

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

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

4

некоторые преимущества использования blobs для хранения файлов

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

недостатки

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

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

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

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

3

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

2

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

1