Azure 时序 (TSI) 初始注意事项和最佳做法

Question

对于这个糟糕的标题，我深表歉意！

我正处于设计 Azure 时序解决方案的初始阶段，我遇到了许多不确定因素。进入 TSI 的背景是，我们目前有一个设计相当糟糕的 cosmos db，其中包含接近 1TB 的物联网数据，而且还在不断增长。 “糟糕”是指分区键的设计方式使得我们无法控制分区的大小。知道有 10GB(?) pr 分区键的限制，我们很快就会用完空间，需要想出一个新的解决方案。此外，在 cosmos db 上运行历史查询时，它不会在可接受的时间范围内响应。任何有关吞吐量计算和更改的实验都不会将响应时间缩短到可接受的时间范围。

我们的业务是记录物联网时间序列数据，包括来自不同传感器的元数据。我们有许多客户端，每个客户端都有 30 到 300 个传感器 - 越来越小的客户端。在客户端，传感器分为位置和子位置。

一个事件的例子可能是这样的：

{
  deviceId,
  datetime,
  clientId,
  locationId,
  sub-locationId,
  sensor,
  value,
  metadata{}
}

了解如何在 CosmosDB 中更好地设计分区键后，在 TSI 中编写 TimeSeriesId 时，是否可以将下面描述的相同方法视为一种好的做法？

• 在一个完全不同的 cosmosdb 解决方案中，我们将 eventDate.datepart(YYYY-MM) 作为分区键的一部分，以防止它超出界限并更好地预测一个分区内查询的响应时间。李>

或者 TSI 会以不同的方式处理时间序列数据，从而使 TimeSeriesId 中的日期部分过时？

考虑到 TSI API 查询，我是否也应该考虑组合 TimeSeriesId 的简单性？ TimeSeriesId 必须在每个 API 请求的正文中提供 - 据我所知，在后端服务中编写查询时，我确实可以访问我们所有的客户 ID 和位置/子位置 ID。而且这些比 deviceId 更容易访问

最后，在为多个客户端存储 IoT 数据时，最佳做法是为每个客户端配置新的 TSI 解决方案，还是 TSI 支持 CosmosDB 中的集合？

Answer 1

如this article 中所述，当使用复合键时，您需要查询所有键属性，而不是其中一个或部分属性。在决定使用单个键或复合键时，这是一个考虑因素。此外，正如文章中所述，作为提示，

如果您的事件源是 IoT 中心，您的时序 ID 可能是 iothub-connection-device-id。

因此，我假设您将至少有一个 IoT 中心获取设备报告的事件，在这种情况下，您可以使用 iothub-connection-device-id。