我需要为数亿张图像准备一个存储空间（现在我有 7000 万张，而且这个数字还在增长）。每个图像有大约。20KB。当然，我可以将它们存储在文件系统中，但我害怕 inode 的数量。我已经测试过 MongoDB 和 Cassandra。它们都有缺点（我的硬盘资源有限）：
- MongoDB - 磁盘空间消耗是原始数据大小的 3 倍
- Cassandra - 磁盘空间消耗与原始数据的大小相似，但 Cassandra 需要大量可用空间来进行压缩过程
任何人都可以为此类问题提出适当的解决方案吗？
问问题
3655 次
2 回答
4
在我的生活中，我使用 S3（包括 Rackspace 云文件）和 MongoDB 完成了视频分发。
大多数人会毫不犹豫地选择 S3，但我发现两者都有其缺点。最大的问题之一是 S3 不是 CDN，它实际上是特定区域内的冗余存储，不会复制到其他 S3 区域，这意味着您需要在 S3 之上使用 cloudfront 之类的东西来 ping 您的图像如果您要在您的网站上获得严重的负载，请使用某种缓存。
S3 还具有其他功能，使其不像 CDN 那样多，而更像是一个存储仓库。话虽如此，对于不常访问的文件，S3 的速度非常快。
这种双层当然会产生复杂性，例如维护。不仅如此，CDN 还可以在 TTL 上工作，即使现在许多 CDN 都具有边缘清除能力，但它们仍然不是 100% 确保您的文件不可访问的方法。
因此，由于设置和访问（也应该删除的文件的可能访问），这可能很快就会变得非常昂贵。
这就是 MongoDB可以取胜的地方。根据您的情况，MongoDB 在这里实际上可能更便宜，因为您可以在 AWS 上使用一大堆微型实例来实际保存您的信息，为这些实例添加现场实例预留（非常便宜）以及您所需要的一切是单台机器上的大磁盘。
天哪，你甚至可以使用 S3 来存储图像，然后使用 MongoDB 作为云端的替代品。
当您想将图像 ping 到不同的区域时，您只需在该目标区域中创建几个 Spot 实例并让 MongoDB 复制它的数据。您也可以对复制做一些很酷的事情，以确保只将来自该区域的经常访问的文件放置在该区域中。
所以我不会抛弃 MongoDB（甚至是 Cassandra），而是会在两者之间进行经济状况测试。
编辑
作为关于 S3 定价的附加说明，如果您将文件存储在 RR（减少冗余）中，那么价格减半（大约），这使得 S3 非常便宜，但是，您仍然存在 S3 不是 CDN 的问题。
进一步编辑
因为我真的只是从@cirrus 的回答中继续，我实际上会重新评估你的问题，上面有点回答。
例如，Youtube 实际上将他们所有的图像存储在单个计算机上，然后分发，因此他们可以轻松地管理 200m 的缩略图和......嗯......每天从文件系统轻松获得很多视图。所以我认为你对文件系统的担心被高估了。
至于哪个数据库更好...我不知道，这取决于您的测试。
我的意思是你的问题的答案取决于你的场景和你的预算以及你的硬件和你的资源，即如果你有 AWS 服务器，这将是一个与专用内部服务器完全不同的答案。
于 2012-11-19T22:52:12.397 回答
1
为什么不将它们放在 Amazon 的 S3 或 Azure Blob 存储中？它们更合适，您不会遇到空间或内存问题，也不必管理部署。
于 2012-11-19T19:39:15.627 回答