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