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