Azure时间序列（TSI）初始注意事项和最佳实践

我为这个糟糕的标题道歉

我正处于设计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中的datepart过时

<>有TSI API查询，我是否应该考虑组成的TimeSeriSID的Simpistic性？TimeSeriesId必须在每个API请求的主体中提供——据我所知，在后端服务中编写查询时，我确实可以访问我们所有的客户端id和位置/子位置id。这些比设备ID更容易接受

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

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

如果您的事件源是IoT集线器，则您的时间序列ID可能是iothub-connection-device-ID

---

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

是的，我确实看到了这篇文章。我担心的是设备的数量是100和1000，而设备id本身并没有真正告诉我它是哪个客户端、位置、子位置或传感器。这就是为什么我在研究复合密钥，并认为它应该包含客户端、位置和子位置id以及传感器类型（明文）。这样，当在后端服务中构建针对特定TimeSeriesId（客户端数据）的API查询时，我可以轻松地插入id。关于这种方法，我的问题是，我是否应该将月份（例如YYYYMM）作为TimeSeriesIdWell的一部分，如果您可以限制每个客户机、位置和子位置的查询，那么使用复合键也可以。月份我认为你不需要把它包括在id中，因为你在事件中有时间戳，所以你可以提取月份和年份，以及aggreggate。