CouchDB 2.x下local_seq的行为是什么？

Question

在CouchDB 1.x中，文档具有一个“隐藏的” n字段，该字段在编写文档修订版时跟踪数据库的update sequence。视图可以通过在设计文档中包含._local_seq选项来由视图使用，或者由客户端使用文档GET请求中的{local_seq:true}查询选项来获取。

该字段在CouchDB 2.x中仍然可用，但尚不清楚其行为。由于存在集群，database update sequence现在是“不透明令牌”，而local_seq仍然是纯整数，在实践中似乎并不总是匹配。

有什么关系，特别是如果我将自己限制为单节点集群吗？

Answer 1

这是我到目前为止所发现的：

对于初学者来说，local_seq的目的在CouchDB 2.x下确实不那么明确。正如问题中已经提到的那样，在数据库/更改级别，序列号已被“不透明令牌”替换，该令牌与local_seq正式无关。

更糟糕的是，似乎与每个文档一起存储的local_seq值至少是 database 而不是 database 的本地文档，而对于 shard < / strong>！ （每个数据库在内部分为多个部分；有关详细信息，您可以在文档中阅读有关Shards and Replicas的更多信息。）

因此，在CouchDB 1.x中，例如，可以通过发出local_seq作为map-reduce索引键的一部分来进行自定义更改供稿，并且该匹配项将与map_reduce索引的?since=N值匹配数据库的_changes提要—在以群集为中心的CouchDB 2.x中，这样的视图将倾向于发出多个文档（每个分片最多一个），每个文档具有相同的._local_seq字段！

从另一个角度来看，在CouchDB 2.x下，即使与数据库级_changes提要中的特定文档相关联的"seq"也会因请求而异-前缀和/或较大的long乱成一团。我不确定是否有一种方法或任何有用的优点，即视图引擎是否可以像对本地序列一样向map函数提供“非本地序列”值。

---

也就是说，从CouchDB 2.3.0开始，我发现了一种“巧合”的方式来保留一些有用性：

1. 通过creating a database和PUT /newdb?n=1&q=1（即配置1个副本和仅1个分片），local_seq值最终在数据库中是唯一的。
2. 在这种情况下，数据库级_changes提要 中每个seq令牌的第一部分似乎也与每个已更改文档的local_seq相匹配。即如果您在'-'上拆分字符串标记并将第一部分转换为数字，则似乎获得了local_seq。

我会谨慎地依靠它，因为：

• 如果您需要进行扩展，并选择使用多节点集群功能来扩展，则依赖于上述条件的任何代码都会中断
• 绝不对它进行正式批准，并且从理论上讲，它最多可以破坏一点。 CouchDB开发人员已经非常清楚_changes级令牌是不透明的，您应该这样对待它们。

因此，洞穴黑客和所有这些，上述“巧合”确实与how these tokens work的描述相符：

  

前面的数字是第二部分中编码的各个更新序列的总和，其存在仅是为了诱骗较旧版本的Couchdb复制器建立检查点。

✅如果只有一个更新序列，则总和应为原始序列。

  

对于给定的碎片   [_changes提要] 是完全有序的（分片与带有整数序列的pre 2.0数据库相同），couchdb不会对输出进行随机排序[…]

✅仅带有一个分片[n.b. shard ，而不仅仅是一个 node / 副本]，您在2.0版之前的数据库行为中就已经差不多了。