Azure 数据资源管理器 (ADX)：多少范围标签“过多”？ + 按范围标签下降

Question

我们目前正在使用 Azure Data Explorer (ADX) 来存储来自多个 IOT 设备的传感器数据。数据深度长达数年。

我们的问题是，某个给定的传感器甚至一组传感器有时会出现问题，导致摄取错误的值。

我正在考虑重新设计我们的摄取以更智能地使用范围标签🤨。我们已经使用了一些标签，但最终几个标签被合并到范围中。因此，如果按标签删除范围

.drop extents <| .show table MyTable extents where tags has "capturedevice01"

(doc) 有效数据可能会与错误数据一起删除 😬.

所以我正在考虑使用

drop-by

(doc) 标签来限制这种现象。 尽管如此，文档说：“避免过度使用 drop-by 标签。”。

那么，“过度”是多少呢😅？有什么想法吗？

对于我们的用例，我们将有 20 个、4000 个 drop-by 标签，具体取决于我们如何定义它们。这两个值是否过高？

另一个问题是关于

drop table extent tags

表演的。您知道对于高达几 GB 的数据量（压缩，初始数据多 5 到 10 倍），删除数十个标签会如何？有使用该命令的 REX 吗？

这个话题很难，所以真的非常感谢任何帮助🙏

Answer 1

因此，如果执行 .drop 表范围标记（doc），则有效数据可能会与错误数据一起被删除😬。

您要删除范围（基于其标签）还是范围标签？从你的措辞来看，听起来你正在删除范围，在这种情况下，这里引用了错误的命令语法。

那么，“过度”是多少呢😅？有什么想法吗？

这个推荐的理由太太多了：

1. 不要对系统合并范围施加严格的限制。如果您最终这样做，那么您最终会得到小于理想的范围，在这种情况下查询性能可能会降低。

2. 不要过度“膨胀”元数据 - 范围标签存储为数据库元数据的一部分。如果数据库元数据变得非常大，也可能会导致性能下降。

关键是不要过度，根据你的场景使用可用的工具。

• 例如，如果您很少需要更新一些（但不是大多数）记录，您可能更喜欢使用 ".update" 命令，而不是使用 drop-by 标签。
• 如果必须使用“drop-by”标签，请尝试使其尽可能短（例如，可以使用“240501”而不是“2024-05-01T00:00:00.0000000”）。
• 如果您知道“drop-by”标签不再发挥作用（例如，导致在一定时间段后重新处理数据的机会为 0） - 制定一个“范围标签保留策略”，这将导致它们被自动删除。

另一个问题是关于删除表范围标签的性能。您知道对于高达几 GB 的数据量（压缩后的数据是初始数据的 5 到 10 倍），删除数十个标签会如何？有使用该命令的 REX 吗？

删除范围或删除标签的命令（我不确定您指的是哪一个）都作用于元数据而不是数据。它们应该是轻量级的，只要您不一次处理 10-100 个数千个分片。

对于我们的用例，我们将有大约 4000 个下拉标签。是不是太过分了？

不知道就很难说 -

• 数据库中有多少个这样的表？
• 这些碎片的大小是多少？
• 您的数据库中的分片总数是多少？
• 这个数字 (4000) 是上限吗？还是随着数据的增长，您会发现自己会不断增加该数字？

无论哪种方式，上面提供的指南都应该引导您走向正确的方向。