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

2 回答

• 4

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

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

  佩里

  回复于 2024-06-02T13:12:59+08:00
• 10

  从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

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

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

  • 是大多数时候您将按文档类型组织设计文档/和视图 .

  • 将所有文档"types"放在一个（少数）存储桶中不是问题，这实际上是您使用Couchbase的方式

  • 最重要的部分是，你的doc的大小（看看"long"将如何解析JSON）以及文档创建/更新和删除的频率，因为视图的JS代码是仅在创建/更改文档时执行 .

  所以你应该做的：

  • 1单桶

  • 有多少设计文件？ （你有几种类型？）

  • 您将拥有每份文件中的任何观点？

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

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

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

  回复于 2024-06-02T13:12:59+08:00