Data :用于自定义分区策略的大量区段
我们运行一个相当小的V2 Kusto集群(2-3个节点，目前是L4s)。该表有15 in的总数据，400 in的热缓存。热数据设置为31天。
由于查询延迟较高，我们通过device_id和时间戳对数据进行了分区。这是一年前发生的。然而，我们现在看到了这样的警告：
"AttentionRequiredReason"：总范围>= 500000，表'mydb.mytable‘每台机器拥有比推荐的(30693 >= 5000)更多的范围
更仔细地看，这个表有接近2,500,000扩展(“总范围计数”)。
这是我们的分区策略：
"PartitionKeys": [
{
"ColumnName": "device_id",
"Kind": "Hash",
"Properties": {
"Function": "XxHash64",
"MaxPartitionCount": 256,
"Seed": 1,
"PartitionAssignmentMode": "Default"
}
},
{
"ColumnName": "customTimestampField",
"Kind": "UniformRange",
"Properties": {
"Reference": "1970-01-01T00:00:00",
"RangeSize": "1.00:00:00",
"OverrideCreationTime": false
}
}
],时间戳字段的示例值为2021-06-15T17:51:54.7401603Z。
我稍微研究了一下，发现"MaxPartitionCount": 256可能太高了，因为我们只配置了2-3个实例。
我的主要问题是：，为什么我们有这么多的学位？我们目前每天获得大约2.000个新学位。考虑到分区策略，难道我们不应该因为散列而每天只获得最大的256吗？这是否与这样一个事实有关:即使我们有250万个范围分布在两个实例中，但警告显示每台机器都有30693个区段？
.show table mytable extents
| where MaxCreatedOn > ago(90d)
| summarize count() by bin(MaxCreatedOn, 1d)
| render timechart 回答 1
Stack Overflow用户
发布于 2021-07-11 19:19:37
在Azure的一些支持和更多调查的支持下，我们发现了原因：
我们收到了许多带有自定义时间戳的消息，该时间戳不是当前日期。当这种情况发生时，Kusto无法像往常一样合并这些区段，我们已经找到了很多这样的方法。解决方案是在分区策略中设置"OverrideCreationTime": true。这可以称为回填或无序摄入。
在修复这个问题之后，过去几天我们一直在获取数据，这使得我们看起来有很多地方，尽管集群无法跟上合并的足够快。我们通过使用不同的时间戳字段来改进这一点，该字段保证接近当前日期。
https://stackoverflow.com/questions/67989608
复制相似问题
腾讯云开发者
