假设桶中有大量数据（>100GB、>100M 文档、>12 种文档类型），并且假设每个视图只适用于一种文档类型，那么每个桶有多少视图太多了？或者换一种方式问，什么时候应该将某些文档类型拆分为单独的存储桶，以节省处理所有文档类型的所有视图的开销？
我很难决定如何将我的数据拆分为 couchbase 存储桶，以及数据所需视图的性能影响。我的数据由十几个关系数据库组成，其中至少有一半在多个表中包含数亿行。
http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-bestpractice.html文档部分“使用文档类型”似乎暗示在同一个存储桶中有多个文档类型并不理想，因为针对所有文档更新特定文档类型的视图，即使是那些永远不会匹配视图的文档。实际上，它建议将数据分成桶以避免这种开销。
然而，出于性能原因，每个集群有 10 个桶的限制。因此，我唯一的结论是每个集群最多可以有效地处理 10 个大型文档集合。这是准确的吗？
Tug 的建议是正确的，也允许我添加一些观点。
可以认为存储桶与 RDMS 世界中的“数据库实例化”最密切相关（尽管不完全相关）。该“数据库”中将有多个表/模式，并且这些表/模式都可以在一个存储桶中组合。
将存储桶视为共享一些通用配置参数（RAM 配额、副本计数等）的数据的逻辑分组，当您需要单独控制某些数据集时，您只需要将数据拆分为多个存储桶。其他原因与不同数据集的工作负载非常不同或希望能够分别跟踪这些数据集的工作负载有关。
一些例子：
-我想控制一组数据的缓存行为与另一组不同。例如，许多客户有一个他们希望始终在 RAM 中的“会话”存储桶，而他们可能有一个更大的“用户配置文件”存储桶，不需要缓存在 RAM 中的所有数据。从技术上讲，这两个数据集可以驻留在一个存储桶中，并允许 Couchbase 智能地知道哪些数据要保存在 RAM 中，但是您没有太多保证或控制会话数据不会被推出......所以把它在自己的存储桶中允许您强制执行。它还为您提供了能够单独监控该流量的额外好处。
-我希望一些数据比其他数据被复制更多次。虽然我们通常在大多数集群中只推荐一个副本，但有时我们的用户会选择他们希望额外复制时间的某些数据集。这可以通过单独的存储桶进行控制。
- 同样，我只希望将一些数据复制到另一个集群/数据中心。这也是按桶控制的，因此可以将数据拆分到单独的桶中。
- 当您对给定数据集的工作负载（尤其是写入量）存在相当大的差异时，从视图/索引的角度来看，将数据分离到单独的存储桶中确实开始有意义。我提到这一点是因为这是真的，但我也想明确一点，这不是常见的情况。您应该在发现问题后使用此方法，而不是在您认为可能之前使用此方法。
关于最后一点，是的，对存储桶的每次写入都会被索引引擎拾取，但是通过使用 JSON 中的文档类型，您可以非常快速地中止对给定文档的处理，并且它确实不应该对有大量数据不适用于某些视图。如果您不介意，我特别好奇文档的哪些部分暗示了其他内容，因为这当然不是我们的意图。
所以一般来说，我们看到大多数部署的桶数（2-3）很少，只有少数超过 5 个。我们 10 的限制来自我们内部跟踪统计信息的一些已知 CPU 和磁盘 IO 开销（负载或桶上缺少它在这里无关紧要）。我们当然计划在未来的版本中减少这种开销，但这仍然不会改变我们只使用几个存储桶的建议。无论如何，能够将多个“模式”组合成一个逻辑分组并在其中应用视图/索引的优势仍然存在。
我们现在正在提出更具体的指导方针和规模建议（我写前两个博客作为权宜之计，直到我们这样做）。
作为初始方法，您希望尝试将设计文档的数量保持在 4 左右，因为默认情况下我们最多并行处理 4 个。您可以增加这个数字，但这应该与增加的 CPU 和磁盘 IO 容量相匹配。然后，您需要将每个文档中的视图数量保持在相对较低的水平，可能远低于 10，因为它们都是按顺序处理的。
我最近与一位拥有大量视图的用户合作（大约 8 个设计文档和一些具有近 20 个视图的 dd），我们能够通过将多个视图合并为一个来大幅降低这一点。显然它非常依赖于应用程序，但您应该尝试从一个索引生成多个不同的“查询”。使用归约、键前缀（在视图内）和排序规则，所有这些都与不同的范围和分组查询相结合，可以使单个索引起初看起来很拥挤，但实际上非常灵活。
您拥有的设计文档和视图越少，您需要的磁盘空间、IO 和 CPU 资源就越少。不幸的是，永远不会有灵丹妙药或硬性准则。最后，YMMV 和在您自己的数据集上进行的测试比我能写的任何多页响应都要好；-)
希望对您有所帮助，如果您对不想发布的特定用例有具体问题，请随时直接与我们联系。
佩里
正如您从 Couchbase 文档中看到的那样，实际上不可能提供“通用”规则来为您提供确切的成员。
但是根据您使用的最佳实践文档和一些讨论（此处），您应该能够正确设计您的数据库/视图。
让我们从最后一个问题开始：
是的，Couchbase 建议使用少量存储桶的原因是为了性能 - 更重要的是资源消耗 - 原因。我邀请您阅读这些有助于了解“内部”Couchbase 的博客文章：
所以你会看到大部分的“操作”都是通过bucket来完成的。
那么现在让我们看看原来的问题：
所以你应该怎么做：
事实上，最昂贵的部分不是在索引或查询期间，而是在您必须重新平衡节点之间的数据和索引时（添加、删除、节点故障）
最后，但看起来你已经知道了，这一章很好理解视图是如何工作的（索引是如何创建和使用的）： http: //www.couchbase.com/docs/couchbase-manual-2.0/couchbase -views-operation.html
如果需要，请随时添加更多信息。