DocumentDB中的标识列

Question

是否可以在documentDB中使用标识列进行自动增量,这对于ID来说通常很方便？任何与之相关的链接或提示都很有用.

谢谢.

Answer 1

AFAIK,DocumentDB没有这种概念.DocumentDB中的每个文档都有一个id唯一标识文档的属性,但该id字段的类型为字符串.创建文档时,您可以选择不为此字段指定值,DocumentDB会自动分配ID,但此值为GUID.因此,如果您希望实现自动增量类型功能,则需要自己处理.但是请记住它是一个字符串类型的属性,所以即使你自己处理它,你需要用零填充你的字符串,以便以正确的顺序返回值,即1,2,3等.而不是1,10,11,...... 19,2,20 ....

Answer 2

仍然(截至2016年8月)没有内置Identity功能; 在DocumentDB的反馈论坛上有一个请求,可以在这里投票 .但请记住,自动计数器在某种程度上违背了大多数NoSQL设计理念.

但是,有几种方法可以作为解决方法,并且都有一个警告; 第一种方法是Counter Document在存储过程中使用更新:

存储过程和计数器文件

1. 创建一个包含数值属性的文档.要么缓存它的自我链接,要么最好使用已知的id创建它,例如"__ DocumentType _Counter",然后你可以使用UriFactory构建一个文档链接,它允许有效地"直接"访问它Counter Document.

2. 创建一个存储过程,接受要插入的文档和Uri Counter Document.在此存储过程中,选择计数器的值,将其递增,将其分配给要插入的文档的相关属性,如果成功保留,则将增加的值保存为计数器文档的更新.

这种方法可行,因为存储过程自动作为事务执行.

警告:但是,事务目前仅限于集合的边界内 - Counter Document在将文档插入另一个集合时,不能将此方法与一个集合中使用.

Redis的

第二个探索选项,增加了一点复杂性和一点额外成本,并且在文档的增量和插入方面不是完全事务性的(但在我个人的经验中提供了更大的吞吐量),就是创建一个Azure Redis缓存,并将Counter值保存在Redis Key Value存储中,然后使用LUA脚本查询并递增.

这可以确保查询Counter值及其增量是一个原子事务,因为Redis是单线程的,LUA脚本基本上阻塞直到完成(但执行速度非常快).

也可以使用MULTI-EXEC命令......这些命令有其自身的问题,需要进行调查以确定它们是否与您相关.

有关Redis交易的更多信息,请参阅此处 - Redis中的交易

警告:如果持续存档您的文档失败,则会出现"鬼"ID,这可能是您可能接受的,也可能是不可接受的.

更新:响应关于"为每个创建操作添加RU成本"的注释,以及"序列化所有写入" - 是的,显然,当使用该Counter Document方法时,创建需要增加Identity属性的文档时就是这种情况; 没有其他插入会受到影响.

在使用DocumentDB时,这些"成本"都是满足所需功能所必需的 - 这本身并不支持Identity属性的概念; 持久化到Document以确保恢复/连续性,序列化以保持一致性.在通常的使用中,RU成本可以忽略不计,并且可以使用诸如批处理之类的技术来抵消这种情况.

目前没有DocumentDB替代方案不会持久存在计数器或序列化写入,同时保证来自多个调用方的递增计数器的完整性.

事实上,DocumentDB团队的Andrew Liu的建议是使用aCounter Document,如链接问题中所述 - 请注意安德鲁答案下面的评论.

由于存储过程是在DocumentDB中预编译的,因此它们是执行"> 1"操作的有效方式.它们目前也是执行交易的最佳方式."某处"必须是柜台的唯一真相来源; 如前所述,一个选项是Redis,但正如我所指出的那样,如果文档插入失败,这不会被回滚的事务的一部分,这可能是也可能是不可接受的; 例如,在事件采购中,事实并非如此.