为什么我看到2个看似相同的CosmosDb集合之间的索引行为不同 [英] Why am I seeing different index behaviour between 2 seemingly identical CosmosDb Collections

查看:84
本文介绍了为什么我看到2个看似相同的CosmosDb集合之间的索引行为不同的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试调试2个单独的cosmos db集合之间的一个非常奇怪的差异,该差异在表面上被配置为相同.

I'm trying to debug a very strange discrepency between 2 seperate cosmos db collection that on face value are configured the same.

我们最近修改了一些执行以下查询的代码.

We recently modified some code that executed the following query.

旧查询

SELECT * FROM c 
WHERE c.ProductId = "CODE" 
AND c.PartitionKey = "Manufacturer-GUID"

新查询

SELECT * FROM c
WHERE (c.ProductId = "CODE" OR ARRAY_CONTAINS(c.ProductIdentifiers, "CODE")) 
AND c.PartitionKey = "Manufacturer-GUID"

在生产环境中引入Array_Contains调用使此查询的性能从〜3 RU/s == >>〜6000 RU/s下降.但仅在生产环境中.

The introduction of that Array_Contains call in the production environment has tanked the performance of this query from ~3 RU/s ==> ~6000 RU/s. But only in the production environment.

原因似乎是在Production中,它没有达到索引.有关这两种环境,请参见下面的输出.

And the cause seems to be that in Production, it's not hitting an index. See output below for the two environments.

DEV配置

收集规模:2000 RU/s

Collection Scale: 2000 RU/s

索引策略:(请注意ETag的排除路径)

Index Policy: (Notice the Exclude path for ETags)

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Range",
                    "dataType": "String",
                    "precision": -1
                },
                {
                    "kind": "Spatial",
                    "dataType": "Point"
                }
            ]
        }
    ],
    "excludedPaths": [
        {
            "path": "/\"_etag\"/?"
        }
    ]
}

产品配置

收集规模:10,000 RU/s

Collection Scale: 10,000 RU/s

索引政策:(请注意,与DEV相比,缺少ETag的排除路径)

Index Policy: (Notice the absense of an Exclude path for ETags compared to DEV)

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Range",
                    "dataType": "String",
                    "precision": -1
                },
                {
                    "kind": "Spatial",
                    "dataType": "Point"
                }
            ]
        }
    ],
    "excludedPaths": []
}

在比较两种环境的输出结果时,尽管索引策略之间没有显着差异,但DEV显示的是索引命中,而PROD的是显示索引未命中.

When comparing the Output results from both environments, DEV is showing an index hit, while PROD is showing an index miss, despite no noticeable difference between the index policies.

DEV中的结果

Request Charge:           3.490 RUs
Showing Results:          1 - 1
Retrieved document count: 1
Retrieved document size:  3118 bytes
Output document count:    1
Output document size:     3167 bytes
Index hit document count: 1

产生PROD的结果

Request Charge:           6544.870 RUs
Showing Results:          1 - 1
Retrieved document count: 124199
Retrieved document size:  226072871 bytes
Output document count:    1
Output document size:     3167 bytes
Index hit document count: 0

我唯一能在网上找到的东西是文档中对Cosmos Collection中发生的一些更改的引用,该更改指出"New Index Layout"正在用于较新的collection,但是没有其他提及Index布局是一个概念,我可以在文档的任何地方找到它.

The only thing I've been able to find online is a reference in the documents to some change that occurred within Cosmos Collection stating that a "New Index Layout" is being used for newer collections, but there's no other mention of Index Layouts as a concept that I can find anywhere in the docs.

https://docs.microsoft. com/en-us/azure/cosmos-db/index-types#index-kind

任何人都知道我可以从这里调试或解决此问题.

Anyone got any idea where I can go from here in terms of debugging/addressing this issue.

推荐答案

您的开发容器是较新的,并且使用了我们的v2索引,该索引具有显着的改进,包括Array_Contains().要了解有关如何升级PROD容器的更多信息,请通过microsoft dot com上的askcosmosdb向我们发送电子邮件.

Your Dev container is newer and using our v2 Index which has significant improvements including on Array_Contains(). To learn more on how to upgrade your PROD container please email us at askcosmosdb at microsoft dot com.

谢谢.

这篇关于为什么我看到2个看似相同的CosmosDb集合之间的索引行为不同的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆