0

我为糟糕的标题道歉！

我正处于设计 Azure 时序解决方案的初始阶段，并且遇到了许多不确定性。进入 TSI 的背景是，我们目前有一个设计相当糟糕的 cosmos db，其中包含接近 1TB 的 IoT 数据，而且还在不断增长。“糟糕”是指分区键的设计方式使得我们无法控制分区的大小。知道有 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 中的集合？

4

1 回答 1

0

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

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

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

于 2020-03-18T00:06:39.447 回答