Tug 的建议是正确的，也让我添加了一些观点。
存储桶可以被认为与 RDMS 世界中的“数据库实例化”最密切相关（尽管不完全）。该“数据库”内将有多个表/模式，并且这些表/模式都可以组合在一个存储桶中。
将存储桶视为数据的逻辑分组，所有数据共享一些通用配置参数（RAM 配额、副本数量等），并且当您需要单独控制某些数据集时，只需将数据拆分到多个存储桶中。其他原因与不同数据集的非常不同的工作负载或希望能够单独跟踪这些数据集的工作负载有关。
一些例子：
-我想以不同于另一组数据的方式控制一组数据的缓存行为。例如，许多客户有一个“会话”存储桶，他们希望始终将其存储在 RAM 中，而他们可能有一个更大的“用户配置文件”存储桶，不需要将所有数据缓存在 RAM 中。从技术上讲，这两个数据集可以驻留在同一个存储桶中，并允许 Couchbase 智能地决定将哪些数据保留在 RAM 中，但是您没有太多保证或控制会话数据不会被推出......所以把它在自己的桶中允许您强制执行。它还为您带来了能够单独监控流量的额外好处。
-我希望某些数据比其他数据复制更多次。虽然我们通常建议在大多数集群中只使用一个副本，但有时我们的用户会选择他们想要额外复制一次的某些数据集。这可以通过单独的桶来控制。
-同样，我只想将一些数据复制到另一个集群/数据中心。这也是按存储桶进行控制的，以便数据可以分割到单独的存储桶中。
-当给定数据集的工作负载（尤其是写入量）存在相当大的差异时，从视图/索引的角度来看，将数据分离到单独的存储桶中确实开始有意义。我提到这一点是因为这是事实，但我也想澄清这不是常见情况。您应该在发现问题之后使用此方法，而不是因为您认为可能之前才使用。
关于最后一点，是的，对存储桶的每次写入都会被索引引擎拾取，但是通过使用 JSON 中的文档类型，您可以非常快速地中止给定文档的处理，并且它确实不会对有大量数据不适用于某些视图。如果您不介意，我特别好奇文档的哪些部分暗示了其他情况，因为这肯定不是我们的意图。
因此，一般来说，我们看到大多数部署的存储桶数量较少 (2-3)，只有少数超过 5 个。我们对 10 个的限制来自我们内部统计跟踪的一些已知的 CPU 和磁盘 IO 开销（负载或桶上缺少的东西在这里并不重要）。我们当然计划在未来的版本中减少这种开销，但这仍然不会改变我们仅拥有几个存储桶的建议。无论如何，能够将多个“模式”组合成单个逻辑分组并跨其应用视图/索引的优点仍然存在。
我们现在正在制定更具体的指导方针和尺寸建议（我写了前两篇博客作为我们这样做之前的权宜之计）。
作为初始方法，您希望尝试将设计文档的数量保持在 4 个左右，因为默认情况下我们最多并行处理 4 个文档。您可以增加此数字，但这应该与增加的 CPU 和磁盘 IO 容量相匹配。然后，您需要将每个文档中的视图数量保持在相对较低的水平，可能远低于 10 个，因为它们都是串行处理的。
我最近与一位拥有相当大量视图（大约 8 个设计文档和一些 dd 具有近 20 个视图）的用户合作，我们能够通过将多个视图合并为一个视图来彻底降低这一点。显然，它非常依赖于应用程序，但您应该尝试从一个索引生成多个不同的“查询”。使用缩减、键前缀（在视图内）和排序规则，所有这些与不同的范围和分组查询相结合，可以创建一个最初可能显得拥挤的索引，但实际上非常灵活。
您拥有的设计文档和视图越少，您需要的磁盘空间、IO 和 CPU 资源就越少。不幸的是，永远不会有灵丹妙药或硬性指导数字。最后，YMMV 和在您自己的数据集上进行的测试比我可以编写的任何多页响应都要好;-)
希望这对您有所帮助，如果您对您不想发布的特定用例有具体问题，请随时直接与我们联系。
Perry
