我听说Couchbase和其他NoSQL数据库最常见的问题是如何为记录生成唯一键 - 或者更具体地说 - 如何复制常见关系数据库的AUTO INCREMENT功能.
经常提到的Couchbase中的解决方案是增量函数,您可以在数字键上调用增量,它将按顺序生成一个新的唯一编号.
我的问题是,我无法理解我在复制方面遇到的大问题.
假设您有一个包含三个Couchbase节点的集群,并且您正在存储请求日志.您想要键入此日志,以便创建名为"requestlog_counter"的条目.
现在说我们有4个web节点,每个节点每秒接收20个请求,每个节点需要记录为"request :: {ID})".这是80秒的请求.
假设节点1和3具有一点点网络延迟,但两者都在同一时间接收这40个请求中的一个.您的脚本会递增请求计数器(假设此示例当前为1500)并获取ID.当然,BOTH Couchbase实例现在可以将1501返回到Web节点1和3,并且两个服务器现在都将尝试将它们正在处理的请求存储为"request:1501".
现在,复制将处理这一点,基本上最新的将赢得.但是你现在已经丢失了一个请求的记录.
那么现在是否意味着实际上你需要一种更好的方式来键入重要数据,并且在NoSQL集群环境中应该避免使用自动增量来获取绝对值和唯一密钥生成？
或者 - 作为密钥生成过程的一部分,您可以做些什么使100%可靠.
还请考虑使用跨数据中心复制的多集群环境.
谢谢.
麦克风
我有这种情况,我不认为这种情况并不常见,但我正在努力寻找一个如何在网上正确完成的例子.
我们有我们的项目,有一个主分支.对于我的例子,我们可以说master的当前状态标识了项目的v1.5.0.
现在我们决定编写v2.0.0,将发生大规模的更改和重写,文件将被完全删除和删除.这个重写现在发生在我们称之为不稳定的新分支上.
在一段时间内开发不稳定的功能和/或修补程序需要添加到v1.5.0,没问题我们说新的分支 - 写入功能 - 与主服务器合并.主人现在是v1.6.0.
现在,此修复/功能不适用于项目的新版本,因为整个项目正在被重写.
我们在不稳定的分支上完成了v2.0.0,这个分支最初是基于主分支的v1.5.0,现在说是... v1.8.4 - 如何在不使用主分支的情况下合并不稳定分支:破坏版本1.5到1.8.4的历史记录,或者在合并的分支中保留2.0.0之前版本的伪像,并可能破坏在v2.0.0中编写的新代码？