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

Question

У меня есть опыт работы с системами реляционных баз данных, которые хранят текстовые данные и создают приложения для них.Я слышал, что реляционные базы данных на самом деле не работают для аудио (мультимедиа) баз данных, и требуется некоторая схема кодирования.Таким образом, любое руководство в этом отношении было бы очень полезно.Я хочу транслировать аудио, получать его порциями, и планирую использовать кодек ogg vorbis для того же.Для потоковой передачи аудиоданных, я думаю, нельзя думать о сохранении файла на сервере и просто указать путь в базе данных, указывающий на них.Если я сделаю так, то: Аудиофайлы имеют большой размер, поэтому без их сжатия отправка их по каналу не будет работать для обычных подключений к Интернету, ни загрузка их не будет работать.

Answer 1

Когда вы слышите relational databases don't really work for audio(multimedia), это, вероятно, означает, что хранение большого количества двоичных данных непосредственно в базе данных приводит к низкой производительности и головной боли при обслуживании.Например, если в RDB имеются террабайты данных, будет сложно выполнить резервное копирование, перемещение и масштабирование.

Однако вы можете хранить BLOB-данные в RDB, но я бы порекомендовал вам рассмотреть файловое хранилище с указанием БД, простов файл.Вы можете использовать S3 (с хорошим сервером кеша) или локальную файловую систему.

Answer 2

Это может работать (см. BLOB http://en.wikipedia.org/wiki/Binary_large_object),, но вы также можете использовать файлы для фактических данных и просто хранить varchar, указывающий на файлы.

Следует избегать кодирования, поскольку это добавляетдополнительный шаг декодирования для каждого использования.

Answer 3

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

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

Некоторые базы данных (в частности, Oracle) могут хранить большие двоичные объекты «в автономном режиме», то есть не в табличном пространстве, а в виде файлов на других носителях. Это немного помогает производительности. Тем не менее, если вы храните аудиоданные как BLOB, вы можете получить к ним доступ только через интерфейс базы данных.

Если вы храните аудио отдельно, в БД вы можете просто хранить имена файлов. Вы можете передавать аудиоданные с использованием другого механизма, более подходящего для аудио или более простого для клиентов (например, http). Недостатком является то, что вы имеете меньший контроль над ними: ссылка может быть случайно разорвана, и у вас нет транзакций, которые удаляют файл или откатывают его. (Обычно вы запускаете периодический процесс сборки мусора, который удаляет файлы, на которые нет ссылок.)

Если вы не опишите ваше приложение более подробно, трудно дать более конкретный совет.