performance - 每个存储桶的最大沙发床 View 数

Question

假设存储桶中有大量数据(> 100GB，> 100M文档，> 12种文档类型)，并且每个 View 仅适用于一种文档类型，则每个存储桶有多少个 View 太多？或以另一种方式问到，应在什么时候将某些文档类型拆分为单独的存储桶，以节省处理所有文档类型的所有 View 的开销？

我很难决定如何将我的数据拆分为“基于基准”的存储桶，以及如何确定数据所需的 View 对性能的影响。我的数据由十几个关系数据库组成，其中至少有一半包含许多表中的亿万行。

http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-bestpractice.html doc部分的“使用文档类型”似乎暗示在同一存储桶中具有多个文档类型不是理想的，因为针对所有文档更新了特定文档类型的 View ，即使是那些永远不会与该 View 匹配的 View 。实际上，它建议将数据分成多个存储桶以避免这种开销。

但是出于性能原因，每个群集最多只能有10个存储桶。因此，我唯一的结论是，每个集群最多可以有效处理10个大型文档集合。这是正确的吗？

Answer 1

Tug的建议是正确的，并允许我也添加一些观点。

可以将存储桶视为与RDMS世界中的“数据库实例化”最密切相关(尽管不完全相同)。该“数据库”中将有多个表/方案，并且它们都可以在存储桶中组合。

将存储桶看作是逻辑数据分组，它们都共享一些公共(public)配置参数(RAM配额，副本计数等)，并且仅在需要单独控制某些数据集时才需要将数据拆分为多个存储桶。其他原因与不同数据集的工作量非常不同，或者与能够分别跟踪这些数据集的工作量有关。

一些例子:

-我要控制一组数据的缓存行为与另一组数据不同。例如，许多客户有一个“ session ”存储桶，他们一直希望在RAM中，而他们可能有一个较大的“用户配置文件”存储桶，不需要所有在RAM中缓存的数据。从技术上讲，这两个数据集可以驻留在一个存储桶中，并允许Couchbase明智地将哪些数据保留在RAM中，但是您没有太多保证或控制该 session 数据不会被推出...因此它在自己的存储桶中可让您强制执行该操作。它还给您带来了额外的好处，就是能够分别监视该流量。

-我希望某些数据比其他数据被复制更多次。虽然通常在大多数集群中建议只使用一个副本，但是有时我们的用户会选择他们想要复制额外时间的某些数据集。可以通过单独的铲斗进行控制。

-沿着同一行，我只希望将某些数据复制到另一个群集/数据中心。每个存储桶也对此进行了控制，因此可以将数据拆分到一个单独的存储桶中。

-当您在给定数据集的工作量(尤其是写入量)方面存在相当大的差异时，从 View /索引的角度来看，将数据分成单独的存储桶确实是有意义的。我提到这一点是因为这是事实，但我也想明确一点，这不是常见的情况。您应该在发现问题之后而不是在您认为可能会出现之前使用此方法。

关于最后一点，是的，索引引擎将提取对存储桶的每次写入，但是通过使用JSON中的文档类型，您可以非常快速地中止对给定文档的处理，这实际上不会对包含大量数据，不适用于某些 View 。如果您不介意的话，我特别好奇文档的哪些部分暗示了其他内容，因为那当然不是我们的意图。

因此，一般而言，我们看到大多数部署的存储桶数量很少(2-3)，而存储桶数量很少，只有5个以上。我们限制为10，这是由于我们内部跟踪统计信息(负载或负载)的一些已知CPU和磁盘IO开销在此处缺少存储区无关紧要)。我们当然计划在将来的发行版中减少这种开销，但这仍然不会改变我们建议只使用几个存储桶的建议。能够将多个“方案”组合到一个逻辑分组中并在其中始终应用 View /索引的优点仍然存在。

我们现在正在提出更具体的指南并确定建议大小(直到我们这样做之前，我都是将前两个博客写成一个权宜之计)。

作为初始方法，您希望尝试将设计文档的数量保持在4个左右，因为默认情况下，我们最多并行处理4个文档。您可以增加此数字，但是应该与增加的CPU和磁盘IO容量相匹配。然后，您将希望使每个文档中的 View 数量相对较少，可能远低于10，因为它们都是按顺序处理的。

最近，我与一个拥有大量 View (大约8个设计文档，而一些dd拥有近20个 View )的用户一起工作，并且我们能够通过将多个 View 组合为一个 View 而大大降低了使用率。显然，它非常依赖于应用程序，但是您应该尝试根据一个索引生成多个不同的“查询”。通过使用归约，键前缀(在 View 内)和排序规则，将它们与不同的范围和分组查询结合使用，可以使单个索引乍看起来可能很拥挤，但实际上非常灵活。

设计文档和 View 越少，所需的磁盘空间，IO和CPU资源就越少。不幸的是，永远不会有神奇的子弹或一成不变的准则数字。最后，YMMV和在您自己的数据集上进行的测试比我能写的任何多页响应都要好；-)

希望对您有所帮助，如果您对不想发布的特定用例有特定疑问，请不要犹豫，直接与我们联系。

佩里