我创建了一个 POC 来测试 Cosmos Db。为此,我创建了一个容器。每个分区键有 120 个项目。我提供了 500 个“分区”,这意味着我有 60k 个文档加载到容器中。
我的文档如下所示:
{
"id": // id
"SteamId": // partition key as string
"Profile": {
// object
}
}
一个文档大小为 5kb。
对于这种情况,我准备了适合我的需求的索引策略:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/SteamId/?"
}
],
"excludedPaths": [
{
"path": "/*"
},
{
"path": "/\"_etag\"/?"
}
]
}
当我在门户中执行查询时:
SELECT c.Profile FROM c where c.SteamId = "76561198053126645"
所以它看起来非常快速和高效。我尝试下载完整分区,即 500kb 的数据。
现在我准备了非常简单的 C# 代码:
public async Task<IActionResult> test(string steamid)
{
CosmosClient client = new(
accountEndpoint: "endpoint",
tokenCredential: new DefaultAzureCredential()
);
Database database = client.GetDatabase("items");
Container container = database.GetContainer("items3");
var stopwatch = new Stopwatch();
var queryDefinition = new QueryDefinition($"SELECT c.Profile FROM c where c.SteamId = {steamid}");
var iterator = container.GetItemQueryIterator<aaa>(queryDefinition,
requestOptions: new QueryRequestOptions()
{
PartitionKey = new PartitionKey(steamid),
});
var results = new List<aaa>();
stopwatch.Start();
while (iterator.HasMoreResults)
{
var result = await iterator.ReadNextAsync();
results.AddRange(result.Resource);
}
stopwatch.Stop();
return Ok(new { items = results, time = stopwatch.ElapsedMilliseconds });
}
通过 SDK 的请求需要 10 秒才能加载门户中需要 1 毫秒的相同查询。我在 SDK 中做错了什么,导致在本地环境中花费了这么多时间?我住在配置 Cosmos Db 资源的同一区域。我正在使用
SDK version 3.36
来表示 Microsoft.Azure.Cosmos
在这里分析帖子的延迟是相当不可能的,因为这不是一个编程问题。应在比 1 次操作更长的时间内分析延迟。
特别是因为连接总是有一个预热阶段,并且根据 https://learn.microsoft.com/azure/cosmos-db/nosql/sdk-connection-modes#direct-mode,第一次操作您确实使用路由请求所需的所有信息初始化并引导客户端,它将始终具有较高的延迟。这通常称为“冷启动”。 服务以 P99 为基础测量延迟。
一般来说,在查看延迟故障排除时,主要文章是:
https://learn.microsoft.com/azure/cosmos-db/nosql/troubleshoot-dotnet-sdk-slow-request?tabs=cpu-new