我正在建立一个网站，它依赖于很快提供大量的小mp3文件（每个大约10-15KB）。每个文件都包含一个单词发音，每个用户每次使用该网站时都会下载20-30个文件。每个用户可能每天下载200个，我预计会有50个并发用户。会有约。最终15,000个单独的文件。
根据需要存储，管理，调用和播放这些文件的最佳方法是什么？我是否需要专业托管来处理所有小文件，或者他们是否会在一个大文件夹（使用标准主机）中表现愉快？任何延误都会破坏这种感觉。
进行了更多搜索后，我认为问题可以通过以下方式解决：
有谁知道这样的产品？
答案 0 :(得分：3)
对于任何现代文件系统，一个目录中的15k文件应该不是问题。肯定不适合NTFS。你不想做的是在资源管理器或类似的东西中打开一个包含100k +文件的文件夹，因为填充列表框（GUI）是一个杀手。此外，您不希望重复迭代此类文件夹的内容。但是，如果您知道文件名（路径），那么只访问文件仍然非常快，而服务器通常只是这样做。
频率也听起来不太可怕。 50个用户* 30个请求/分钟/用户每秒25个请求。这不是你可以完全忽略的东西，但任何体面的网络服务器都应该能够以这种速度提供文件。此外，我认为不需要专门的内存服务器/数据库/数据存储。每个操作系统都有一个文件缓存，应该在内存中处理经常访问的文件。
如果您必须保证低（最坏情况）延迟，您可能仍需要内存数据存储。但是如果你必须保证延迟，那么事情就会变得复杂。
最后一件事：考虑反向代理。我发现能够在一个地方（我选择的）主要存储/更新数据非常方便，并且有反向代理可以处理其余的事情。如果您的文件永远不会更改（即相同的URL意味着相同的数据），这是一种非常简单的方法来提供真正良好的可伸缩性。如果文件确实可以冒险，那就让它们不能这样做:)通过将更改日期编码到文件名中（并删除“旧版本”）。
答案 1 :(得分：2)
如果您希望（或需要）将文件存储在磁盘上而不是数据库中的BLOB，那么您需要记住以下几点：
许多（但不一定是所有）文件系统对包含许多文件的文件夹不能很好地工作，因此您可能不希望将所有内容存储在一个大文件夹中 - 但这并不意味着您需要专家托管。
关键是根据一些哈希函数将文件分发到文件夹层次结构中。举个例子，我们在这里使用文件名的MD5，但是你使用哪种算法或者你正在散列什么数据并不是特别重要，只要你是一致的并且在你需要找到文件时有数据可用
通常，散列函数的输出格式为十六进制字符串：例如，“foo.mp3”的MD5为10ebb1120767e9de166e0f5905077cb1。
您可以创建16个文件夹，每个文件夹对应一个可能的十六进制字符 - 因此您有一个目录0，一个名为1，依此类推至f。
在这16个文件夹中的每个文件夹中，重复此结构，因此您有两个级别。 （0/0 /，0/1 /，...，f / f /）
然后你做的只是将文件放在由其哈希指示的文件夹中。您可以使用第一个字符来确定第一个文件夹，使用第二个字符来确定子文件夹。使用该方案，foo.mp3将进入1/0 /，bar.mp3进入b / 6 /，而baz.mp3进入1 / b /。
由于这些散列函数旨在均匀分布其值，因此您的文件将在这256个文件夹中相当均匀地分布，从而减少任何单个文件夹中的文件数量;从统计上来说，15000个文件会导致每个文件夹平均接近60个，这应该没问题。
如果你运气不好，你选择的哈希函数最终会在一个文件夹中聚集太多文件，你可以将层次结构扩展到2个以上的级别，或者你可以简单地使用不同的哈希函数。在这两种情况下，您都需要重新分发文件，但是您只需要执行一次，编写脚本来为您执行此操作应该不会太麻烦。
为了管理您的文件，您可能需要一个小型数据库索引您当前拥有的文件，但这不一定需要用于管理它们以外的任何其他内容 - 如果您知道文件的名称，并且您使用作为哈希函数输入的文件名，你可以再次计算哈希并找到它的位置。
答案 2 :(得分：0)
我会从内存数据库15ksize * 15000 = 225Mb的原始数据中提供这些服务，即使有很大的开销，它也很容易适合中型宿主计划。这里基于磁盘的缓存可能很优雅，例如memcachedb，ehcache或类似的，那么你只有一个API和一些配置。
你应该在启动时预热缓存。
元数据可以是mysql或类似的。您可以在那里保留一个mastercopy以便于管理，也可以作为缓存的后端。