Я хочу хранить большое количество звуковых файлов в базе данных, но я не знаю, является ли это хорошей практикой. Я хотел бы знать плюсы и минусы делать это таким образом.
Я также подумал о возможности иметь "ссылки" на эти файлы, но, возможно, это будет иметь больше проблем, чем решений. Любой опыт в этом направлении будет приветствоваться:)
Примечание. Базой данных будет MySQL.
Каждая система, которую я знаю, хранит большое количество больших файлов, хранит их извне в базу данных. Вы сохраняете все запрашиваемые данные для файла (название, исполнитель, длина и т.д.) В базе данных, а также частичный путь к файлу. Когда пришло время получить файл, вы извлекаете путь к файлу, добавляете к нему некоторый корень файла (или URL) и возвращаете это.
Итак, у вас будет столбец "location" с частичным путем в нем, например "a/b/c/1000", который вы затем сопоставляете с: " http://myserver/files/a/b/c/1000.mp3"
Убедитесь, что у вас есть простой способ указать базу данных мультимедиа в другом сервере/каталоге, если это необходимо для восстановления данных. Кроме того, может потребоваться процедура, которая повторно синхронизирует базу данных с содержимым файлового архива.
Кроме того, если вы собираетесь иметь тысячи медиафайлов, не храните их в одном гигантском каталоге - это узкое место в производительности некоторых файловых систем. Вместо этого разбивайте их на несколько сбалансированных поддеревьев.
Я думаю, что хранить их в базе данных в порядке, если вы используете хорошую реализацию. Вы можете прочитать эту более старую, но хорошую статью за идеи о том, как сохранить больший объем данных в базе данных от влияния производительности.
http://www.dreamwerx.net/phpforum/?id=1
У меня было буквально 100 концертов, загруженных в базы данных mysql без каких-либо проблем. Дизайн и реализация являются ключевыми, делайте это неправильно, и вы будете страдать.
Дополнительные преимущества БД (еще не упомянуты): - Работает лучше в сбалансированной нагрузке среде - Вы можете создать более масштабируемую систему хранения данных
Я экспериментировал в разных проектах, делая это в обоих направлениях, и мы наконец решили, что проще использовать файловую систему. В конце концов, файловая система уже оптимизирована для хранения, извлечения и индексирования файлов.
Единственный совет, который я хотел бы получить, - это сохранить только путь "корневой относительный" к файлу в базе данных, а затем ваша программа или ваши запросы/хранимые процедуры/промежуточное изделие используют параметр установки, специфичный для root, для получить файл.
Например, если вы храните XYZ.Wav в C:\MyProgram\Data\Sounds\X \, полный путь будет
C:\MyProgram\Data\Sounds\X\XYZ.Wav
Но вы сохранили бы путь и/или имя файла в базе данных как:
X\XYZ.Wav
В другом месте, в базе данных или в файлах конфигурации программы, сохраните корневой путь, например SoundFilePath, равный
C:\MyProgram\Data\Sounds\
Конечно, если вы разделили корень из пути базы данных до вас. Таким образом, если вы переместите свою установку программы, вам не нужно обновлять базу данных.
Кроме того, если будет много файлов, найдите способ хэширования путей, чтобы вы не закончили работу с одним каталогом, содержащим сотни или тысячи файлов (в моем маленьком примере есть подкаталоги, основанные на первый символ имени файла, но вы можете пойти глубже или использовать случайные хэши). Это также делает поисковые индексы счастливыми.
Преимущества использования базы данных:
Недостатки использования базы данных:
Вы можете хранить их как BLOB (или LONGBLOB), а затем извлекать данные, когда хотите получить доступ к медиафайлам.
или
Вы можете просто сохранить медиафайлы на диске и сохранить метаданные в БД.
Я склоняюсь к последнему методу. Я не знаю, как это делается в целом в мире, но я подозреваю, что многие другие будут делать то же самое.
Вы можете хранить ссылки (частичные пути к данным), а затем извлекать эту информацию. Легко перемещать вещи на дисках и все еще получать к ним доступ.
Я сохраняю относительный путь каждого файла в БД вместе с другими метаданными о файлах. Базовый путь может быть изменен "на лету", если мне нужно переместить фактические данные на другой диск (локальный или через UNC-путь).
Как я это делаю. Я уверен, что у других тоже будут идеи.
Некоторые преимущества использования блобов для хранения файлов
Некоторые недостатки
Как насчет производительности? Ваш пробег может отличаться. Файловые системы чрезвычайно разнообразны, поэтому базы данных в своей производительности. В некоторых случаях файловая система будет выигрывать (возможно, с меньшим количеством файлов). В некоторых случаях БД может быть лучше (возможно, с очень большим количеством небольших файлов).
В любом случае, не волнуйтесь, делайте то, что кажется лучшим в то время.
В некоторых базах данных имеется встроенный веб-сервер для обслуживания блобов. На момент написания статьи MySQL не работает.
Храните их как внешние файлы. Затем сохраните путь в поле varchar. Помещение больших двоичных блоков в реляционную базу данных, как правило, очень неэффективно - они используют только пространство и замедляют работу, поскольку заполненные кэши непригодны. И ничего не получится - самим блобам не удастся обыскать. Возможно, вы захотите сохранить метаданные в метаданных в базу данных.
Простым решением было бы просто сохранить относительные местоположения файлов в виде строк и позволить файловой системе обрабатывать его. Я пробовал его в проекте (мы хранили файлы вложений в офисный файл), и он работал нормально.
Лучший способ хранения аудио/видео файлов, вы можете использовать любое распределенное хранилище, которое может быть локальным или облачным.
для облака: AWS S3