每个桶的最大沙发基础视图数

Question

假设存储桶中有大量数据（＆gt; 100GB，> 100M文档，> 12种文档类型），并假设每个视图仅适用于一种文档类型，那么每个存储区的视图数量是多少？或者问另一种方式，在什么时候应该将某些文档类型拆分成单独的存储桶，以节省处理所有文档类型的所有视图的开销？

我很难决定如何将数据拆分成couchbase存储桶，以及数据所需视图的性能影响。我的数据由十几个关系数据库组成，其中至少有一半在数个表中有数亿行。

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

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

Answer 1

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和对您自己的数据集的测试比我能写的任何多页面响应更好; - ）

希望有所帮助，如果您对自己不希望发布的特定用例有具体问题，请随时与我们联系。

佩里

Answer 2

从Couchbase文档中可以看出，实际上不可能提供“通用”规则来为您提供确切的成员。

但根据您使用的最佳实践文档和一些讨论（此处），您应该能够正确设计数据库/视图。

让我们从最后一个问题开始：

是的，Couchbase建议拥有少量存储桶的原因是性能 - 更重要的是资源消耗 - 原因。我邀请您阅读这些有助于了解Couchbase“内部”内容的博客文章：

• 调整大小1：http://blog.couchbase.com/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster
• 调整大小2：http://blog.couchbase.com/how-many-nodes-part-2-sizing-couchbase-server-20-cluster
• 压实：http://blog.couchbase.com/compaction-magic-couchbase-server-20

因此，您将看到大多数“操作”都是由存储桶完成的。

现在让我们看一下原来的问题：

• 是大多数时候您将根据文档类型组织设计文档/视图。
• 将所有文档“类型”放在一个（少数）存储桶中并不是一个问题，这实际上是您使用Couchbase的方式
• 最重要的部分是，你的doc的大小（看看JSON的解析将如何“长”）以及文件创建/更新和删除的频率，因为JS代码仅在创建/更改文档时执行视图。

那么你应该做什么：

• 1个单斗
• 有多少设计文件？ （你有多少种类型？）
• 您将拥有每份文件中的任何观点？

事实上，最昂贵的部分不是在索引或查询期间，当你必须重新平衡节点之间的数据和索引（添加，删除，节点故障）时，它就更多了

最后，但看起来你已经知道了，本章非常适合理解视图的工作原理（如何创建和使用索引）： http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-operation.html

如果需要，请随时添加更多信息。