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

Question

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

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

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

然而,出于性能原因,每个群集限制为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和你自己的数据集测试比我能写的任何多页面响应更好;-)

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

佩里