可能的重复：
音频和视频等大文件的数据库
我正在寻找存储大量二进制数据（图像、视频、文档等）的最佳（或至少足够好）方法。该解决方案必须具有可扩展性，并且在 X 数据量之后不会陷入困境。
我想要一个地方，例如 MySQL 数据库，其中保存所有数据。当 Web 前端之一需要它时（根据请求），它可以从数据库获取它并永久缓存以供以后使用。
从这里我可以在http://dev.mysql.com/doc/refman/5.0/en/table-size-limit.html上看到MySQL 表每个表不能存储超过 4TB 的数据。是否有更合适的东西，比如 nosql 数据库，或者最好将所有内容存储在一台服务器上的文件中并将其传播到所有 Web 前端？
小智 5
您通常不想在关系数据库中存储大文件——这不是它们的设计目的。我还建议不要使用 NoSQL 解决方案，因为它们通常也不是为此设计的，尽管有一些例外（见下文）。
您的最后一个想法，将文件存储在文件系统上（请注意，这是文件系统的设计目的；）很可能是正确的方法。根据您的可扩展性要求，这可能有点困难，但您可能希望采用以下其中一项：
SAN。SAN 在网络内提供冗余、高可用性的存储解决方案。多个服务器可以连接到 SAN 提供的存储并在彼此之间共享文件。请注意，此解决方案通常是面向企业的，并且可靠地实施起来相当昂贵（您至少需要物理硬件以及 RAID 控制器和大量磁盘）。
CDN。内容交付网络是一种远程、全球分布式系统，用于通过 Internet 向最终用户提供文件服务。您通常将文件放在服务器上的某个位置，然后将其复制到 CDN 以进行实际分发。CDN 的工作方式是，如果它没有用户请求的文件，它会自动尝试从您的服务器获取该文件；一旦它拥有该文件的副本，它就会将该文件缓存一段时间。如果您通常受到带宽成本或同时提供大量文件的处理开销的限制，那么它确实很有帮助。
云产品（Amazon S3、Rackspace 云文件）。它们与 CDN 类似，但可以与您现有的云基础设施（如果您正在使用的话）配合良好。您向云 API 发出请求来存储您的文件，随后该文件就可以通过 Internet 访问，就像 CDN 一样。主要区别在于您必须手动发出任何存储请求（创建、删除或更新）。
如果您提供的文件数量很少，您也可以使用内部解决方案。将文件存储在两个或三个服务器上（可能有一组更大的服务器，如果空间成为问题，则使用哈希计算进行分片）。为您的前端服务器构建一个小型 API，以从存储服务器请求文件，如果备用服务器不可用，则返回到备用服务器。
我差点忘记的一个解决方案（尽管除了研究目的我从未使用过）是 Riak 的Luwak项目。Luwak 是 Riak 的扩展，Riak 是一种高效的分布式键/值存储，它通过将大文件分成大小一致的段，然后将这些段存储在树结构中以便快速访问来提供大文件支持。这可能是值得研究的事情，因为它免费为您提供了我在上一段中提到的冗余、分片和 API。