【问题标题】:how can I generate a partially unique and sequential field in a couchdb document?如何在 couchdb 文档中生成部分唯一且连续的字段?
【发布时间】:2017-08-17 08:33:16
【问题描述】:

我对 couchdb 很陌生,我想知道如何创建看起来像这样的 ID。

Employee:DBX-**0001**-SP

数字部分 0001 必须是唯一且连续的。我怎样才能在 couchdb 中实现这样的目标?我搜索了所有内容,但找不到任何简单的解决方案。

如果我可以在 couchdb 中而不是在客户端生成顺序部分,那将是最好的,以避免在复制过程中发生冲突。

我目前的解决方案是我获取一个我存储的文档,看起来像这样 {"_id": "EmployeeAutoIncrement", value: 1} 在检索时我增加值并将其发送回服务器,如果那些成功然后我返回新的增量值并将其用作我的自动增量值以成为 ID Employee:DBX-AUTO_INCREMENT_VALUE_HERE-SP

的一部分

这样的问题是,如果两个人同时向 EmployeeAutoIncrement 发出请求并且他们都更新它会不会引起冲突?另外,如果一个人提出请求,然后他们下线了,那么他们又回来了,那不会也产生冲突吗?

【问题讨论】:

  • 如果我是你,我会尝试通过 JSON.stringify(new Date()) 使用 UTC 日期作为自动增量。它是唯一的、连续的,并且作为奖励存储创建的日期。我不确定如何在服务器端完成此操作,因此多个客户端尝试在同一毫秒内创建文档可能会出现问题。如果由于 _id 已经存在而失败,您可以重试一次,这应该占大多数情况。
  • 抱歉,我不明白如何从中获取序列号。它应该像 0001 0002 0003 0004 0005 这样的顺序。请详细说明 JSON.stringify(new Date()) 将如何给我 0001 0002 ...
  • 它不会给你一个没有间隙的序列,但如果你需要的话,它可以很容易地按升序排序
  • 是的,我就是这么想的。好主意,但是...我确实需要一个没有间隙的序列,因为这是要求。顺便说一句,您的意思是我必须使用 unix 时间戳作为序列还是完整的 UTC 日期字符串?
  • @ManiMuridi 如果你想显示正确的数字并有分区的客户端,你试图违反 CAP 定理。你必须找出你的要求的优先级。

标签: couchdb pouchdb


【解决方案1】:

使用多个客户端时,客户端无法满足所有要求,其中一些可能离线。

这是一个导致 id 单调递增的过程:

  1. 每个客户端都保存一个具有唯一 ID 的记录。记录应包含一个标记,将记录标记为临时记录。
  2. 构建一个external process,用于侦听changes feed 中标记为临时的记录。更改提要按“应用时间顺序”输出记录。
  3. 外部进程应创建一个具有正确 ID 的新记录,并将其标记为永久记录。由于只有该进程创建“永久”记录,因此它可以读取和写入 EmployeeAutoIncrement 值而不会发生冲突。
  4. 然后外部进程可以删除临时记录。

数据库的记录数将增加一倍,因此它会增长得更快,如果空间存在问题,则需要尽快压缩。员工记录上的任何视图/查询都需要检查永久标志,以防在外部进程添加新记录时运行查询。

【讨论】:

    【解决方案2】:

    虽然我建议您考虑一下您的设计选择以及为什么要在分布式数据库上完成此操作,但它可以(在某种程度上)完成——它可能最好在您可以控制序列生成器的序列化的客户端上完成.

    如果您想至少部分在服务器上执行此操作,则需要实现所谓的 CRDT 计数器,如下文所述:

    http://hal.upmc.fr/docs/00/55/55/88/PDF/techreport.pdf

    您可以在此处找到其中一些想法的 Ruby 实现:

    https://github.com/aphyr/meangirls

    还有一个简单的 Couch 特定的计数器实现(你需要的那个)和一个集合:

    https://github.com/drsm79/couch-crdt

    后者虽然是用 Python 编写的,但如果您遵循以下示例中所示的模式,几乎可以完全按照您的意愿行事:

    https://github.com/drsm79/couch-crdt/blob/master/examples/counter.py

    这将为您提供单调序列。从那里,创建您的文档_id。

    翻译成 JavaScript 和 PouchDB 留给读者作为练习。

    【讨论】:

    • 虽然我仍然没有很好的可靠解决方案,但您确实提供了很多有用的链接,这些链接给了我尝试的想法。因此,我选择给你赏金的原因。非常感谢! (y)
    猜你喜欢
    • 2012-07-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-09
    • 1970-01-01
    • 2014-09-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多