我很想听听您对couchdb的看法，并会处理我的用例。
我会做什么，我将有数据库，我存储大小约20kb的文件，每个附件1-10MB。
将使用我的架构在每个服务器上处理数据库10TB或更多？（在4u情况下，每个沙发节点可以放置24个2TB驱动器吗？读取的次数会少得多，所以我需要速度）
将能够复制带附件的所有文件
如何将所有数据拆分到多个服务器（例如4个节点）？会处理那么多附件吗？
需要更多信息请询问：）
答案 0 :(得分：3)
我认为你不会对10TB文件造成物理限制，也就是说我不认为沙发有一些内置的“不能使用大于X的文件”，其中X为＆lt; 10TB。
然而
最大的问题是文件压缩。为了回收空间，Couch想要压缩文件。这实际上意味着复制文件。因此，至少在某些方面，10TB需要为20TB，因为它复制了新副本中的实时数据。
如果你主要是附加到文件，那就是你只是添加新数据而不是更新或覆盖旧数据，那么这将不是一个问题，因为压缩不会让你获得那么多。如果您的数据基本上是静态的，那么我将构建该文件并在最后一次压缩它并使用它。
Couch有“第三方”分片解决方案，休息室很受欢迎。
当我接近沙发解决方案时，首要考虑的是您的查询标准。真的，Couch是关于观点的。你在看什么样的观点？如果您只是通过一些简单的密钥（文件名，日期或其他）存储数据，那么简单地使用文件系统和合适的目录结构可能会更好。坦率地说。
所以我想更多地了解您打算使用的观点，因为您不打算进行大量阅读。
附录：
您还没有提到您正在寻找什么样的查询。这些查询实际上是设计组件，特别是对于Couch DB，因为在大型数据集上添加新查询变得越来越困难。
当你说附件时，我认为你的意思是Couch DB有效载荷的附件（因为它可以处理附件）。
所以，总而言之，您可以轻松创建元数据文档，捕获您想要捕获的所有信息，并作为该文档的一部分，为存储在文件系统上的实际文件添加路径名。这将大大减少Couch文件的整体大小，从而使维护更快，更高效。当然，你会失去一些“自包含”的部分，将它全部放在一个文档中。