DocumentDb GUID索引精度

Dav*_*New 3 azure azure-cosmosdb

假设我们的文档中有一个非唯一的GUID/UUID值:

[
  {
    "id": "123456",
    "Key": "117dfd49-a71d-413b-a9b1-841e88db06e8"
    "Name": "Kaapstad",
  },
  ...
]
Run Code Online (Sandbox Code Playgroud)

我们只想通过平等来对此进行查询.无需查询范围或命令.例如:

SELECT * FROM c where c.Key = "117dfd49-a71d-413b-a9b1-841e88db06e8"
Run Code Online (Sandbox Code Playgroud)

下面是索引定义.这是一个哈希索引(因为不会执行范围查询)使用String数据类型(因为Javascript本身不支持Guid)

collection.IndexingPolicy.IncludedPaths.Add(
    new IncludedPath { 
        Path = "/Key/?", 
        Indexes = new Collection<Index> { 
            new HashIndex(DataType.String) { Precision = -1 }
        }
    });
Run Code Online (Sandbox Code Playgroud)

但是这个最好的索引精度是多少?

这个MSDN页面并没有让我明白哪个精度值最适合这样的值:

索引精度配置对字符串范围更有用.由于字符串可以是任意长度,因此索引精度的选择会影响字符串范围查询的性能,并影响所需的索引存储空间量.字符串范围索引可以配置为1-100或-1("最大").如果要对字符串属性执行Order By查询,则必须为相应的路径指定精度-1.

And*_*Liu 10

您可以根据预期包含属性键路径的文档数量(Key在您的示例中恰好是属性)来微调索引精度值.

哈希索引的索引精度指示要将属性值哈希的字节数.因此,降低精度值有助于优化存储索引所需的存储量.提高精度值(在哈希索引的上下文中)有助于防止索引上的哈希冲突.

例如,假设路径上的哈希索引精度值为3 foo.

3字节= 3*8 = 24位.

24位可以支持:2 ^ 24 = 16,777,216个值

通过归类原理,当您使用foo属性存储> 16,777,216个文档时,可以保证发生哈希冲突.在哈希冲突时,DocumentDB将需要对找到的文档子集执行扫描.例如,如果您有30,000,000个带有foo属性的文档- 您可以平均扫描2个文档.