哪种数据库和编码方案适合音频数据存储？

Question

我有关系数据库系统存储文本数据以及为它们构建应用程序的经验。我听说关系数据库并不适用于音频（多媒体）数据库，也需要一些编码方案。因此，这方面的任何指导都会非常有帮助。 我想流式传输音频，将其分块，并计划使用ogg vorbis编解码器。对于流式音频数据，我认为人们不会想到将文件存储在服务器上，只是在数据库中提供指向它们的路径。如果我这样做那么：音频文件很大，所以不压缩它们，通过频道发送它们不适用于正常的互联网连接，也不能上传它们。

Answer 1

它可以工作（参见BLOB http://en.wikipedia.org/wiki/Binary_large_object），但您也可以使用文件存储实际数据，只需存储指向文件的varchar。

应该避免编码，因为这会为每次使用添加额外的解码步骤。

Answer 2

当您听到relational databases don't really work for audio(multimedia)时，可能意味着将大量二进制数据直接存储在数据库中会导致性能下降和维护问题。例如，如果您在RDB中有数TB的数据，则很难进行备份，移动和扩展。

但是，您可以将BLOB数据存储在RDB中，但我建议您考虑使用DB指向该文件的文件存储。您可以使用S3（具有良好的缓存服务器）或本地文件系统。

Answer 3

有关音频剪辑的各种元信息可以直接存储在数据库中，这是有道理的，因为您可以合理地查询它。

音频片段本身通常很大（几个megs），通常你不能索引它们。所以没有必要将它们直接存储在数据库中，如果这样做，它会减慢速度。直接在数据库中存储音频数据的唯一好处是事务/锁定，这在大多数情况下都是不太可能的优势。

某些数据库（特别是Oracle）可以存储BLOB'离线'，即不在表空间中，而是存储在其他媒体上的文件中。这有助于提高性能。如果您将音频数据存储为BLOB，则只能通过数据库接口访问它们。

如果您单独存储音频，则可以在数据库中存储文件名。您可以使用不同的机制提供音频数据，更适合音频或更容易为客户端（例如http）。缺点是您对它们的控制较少：链接可能会意外中断，并且您没有删除文件或回滚文件的事务。 （通常运行定期垃圾收集过程，删除未引用的文件。）

除非您更详细地描述您的申请，否则很难提供更具体的建议。