Couchbase：将视图与存储桶同步答案

【问题标题】：Couchbase: Synchronizing views with a bucketCouchbase：将视图与存储桶同步
【发布时间】：2012-07-18 12:29:42
【问题描述】：

我有一个问题要问沙发库专家：是否可以将文档子集（例如视图中的文档）与其他存储桶同步？

所以其他存储桶文档始终是“主”存储桶的直接子集？如果是这样，就性能而言，这不是很昂贵吗？还是 couchbase 有什么功能可以只创建文档的深层链接而不是复制它？

或者：是否可以在视图上编写视图？

提前谢谢你！

--- 编辑 ----

假设我想要两组（存储桶）文档 S1 和 S2。 S2 是 S1 的子集。每个集合都包含相同的视图 V1、V2 和 V3，因为我希望能够使用相同的逻辑/接口查询它们中的任何一个。在我的例子中，集合 S2 是按用户/公司/商店/任何东西构建的，在生产中应该有大约 1000 个子集 S2 - 为了保持抽象，我们称它们为 S2a S2b 和 S2c。

要包含在任何子集中的文档的选择由过滤实例（例如视图）完成。让我们将这些过滤实例称为 F1，用于过滤 S1 到 S2，因此称为 F1a、F1b 和 F1c。

因此，根据我对 couchbase 的实际了解，这导致了以下设计/视图架构：我有三个“基本”视图来显示 V1、V2 和 V3，并且要实现 S2a、S2b 和 S2c，我必须创建设计视图 S2aV1、S2aV2、S2aV3、S2bV1、S2bV2 等（9 个视图）。

有人可能会说“明智地选择你的键，你可以避免子视图”，但在我看来这并不容易，因为以下情况：在最坏的情况下，过滤器参数每分钟都会改变并且包含许多 WHERE IN在查询 k/v 列表时可能（在我的实际观点）无法有效处理的约束。

这导致了以下想法和我最初提出的问题。如果我在任何子集（由过滤器定义）中使用相同的视图，是否应该建立一个帮助我处理复杂过滤的实体？例如，在生成视图输出时在运行时调用的函数？这可能看起来像 /design/view?filter=F1 或类似的东西。

或者你有其他解决这个问题的想法吗？或者我应该使用 SQL，因为它更能处理频繁变化的过滤器？

【问题讨论】：

你能补充一点关于开发环境的问题吗？ Java/C#/PHP 等？这可能会影响答案。
由于环境/客户端语言不会影响沙发底座的工作方式，我认为这并不重要。但是，如果您需要此信息来回答问题，请随意选择您选择的环境。我很高兴有任何建议。
如果您需要在外部执行其中的某些部分（这就是我问的原因），它可以做到，但讨论已经在 scalabl3 的答案中得到澄清，所以我们会看看我们结束的地方向上。 :)

标签： nosql couchdb couchbase

【解决方案1】：

一般来说，对于大多数模型，您实际上并不需要存储桶“子集”，您尝试这样做是否有特殊原因，以及为什么您希望将这些数据分解？您还可以查询您的视图，或者代替视图上的视图，您可以只创建一个单独的视图，根据您的需要进一步映射/过滤（即与视图上的视图执行相同的工作）。

【讨论】：

是的，我也认为一些设计良好的设计文档应该使任何子集变得不必要。但是在我的实际用例中，我必须过滤许多属性的文档，例如 attr1 > 10、attr2
我认为你的逻辑是合理的。我认为您对存储桶子集的概念是，一个视图是。您在@JChris 的评论中提到了深层链接。您可以做参考链接，但 Couchbase 本身不跟随它们，但您可以在客户端跟随它们。我不确定您要完成的工作是否需要存储桶副本。我的理解是否正确：您希望能够不断地拥有与基于 json k/v 的某些特征匹配的文档子集，并根据这些减少存储桶上的数据集以获取额外的 m/r？
执行此子过滤器的另一种方法是使用复合视图键，其中第一个元素（在数组中）是您要分组的子集。从视图请求的角度来看，功能结果几乎相同，因此无需对事物进行子集化。要在一般领域获得良好的阅读，请查看来自 CouchConf Boston 的 Bradley Holt 的演示文稿。不正确，但可能会引发一个想法。
感谢您的建议，我会检查演示文稿！我在 couchbase 论坛中发布了更清晰的描述和对 scalabl3 问题的回复：couchbase.com/forums/thread/…，因此非常欢迎您对此发表评论。

【解决方案2】：

我们正在开发 Elastic Search 集成。可能更适合您的用例

【讨论】：

如果那真的是你，J 克里斯，而不是冒名顶替者，;) 你能否在你的答案中添加更多细节，以及指向大量信息的链接？（我给了你+1，因为它是有用的信息，而且因为只有 1 个代表点你几乎什么都做不了，但这里通常首选更具话语性的答案。）感谢您的回答，感谢您在 CouchDB 上所做的所有出色工作和沙发床！

【解决方案3】：

我认为您要做的是在原始存储桶上编写一个视图，然后从该视图复制键/值，作为新存储桶中的文档。

编写一个自动化框架来管理它应该不难，这样您就可以近乎实时地使派生数据保持最新。

【讨论】：

是的，我今天也是这么想的。问题是我不知道这种方法意味着多少性能损失。假设您有一个包含 500 万个文档的存储桶，每秒进行大量的 CRUD。将对这些文档所做的所有更改复制到另一个存储桶中也会导致另一个存储桶中的大量设计/视图/映射/缩减。恕我直言，最好的方法应该是为 couchbase 编写一个插件，该插件允许诸如深层链接到另一个存储桶中的现有文档之类的东西。你怎么看？
我们避免深度链接，因为在集群上，没有跨越单个文档的所有 ACID 保证。因此，例如，不可能在单个事务中创建一条记录并从另一条记录添加到它的链接。因此，文档之间的所有链接都必须是“软”的，因此最好由应用程序代码处理。