Bewährte Methoden für die Wahl einer Zeitreihen-ID

Dieser Artikel fasst die Wichtigkeit der Time Series-ID für Ihre Azure Time Series Insights Gen2-Umgebung zusammen sowie bewährte Methoden für deren Auswahl.

Auswählen einer Time Series-ID

Die Auswahl einer geeigneten Time Series-ID ist entscheidend. Das Auswählen einer Time Series-ID ist wie das Auswählen eines Partitionsschlüssels für eine Datenbank. Dies ist erforderlich, wenn Sie eine Azure Time Series Insights Gen2-Umgebung erstellen.

Sehen Sie sich das Tutorial zur Umgebungsbereitstellung an, das eine ausführliche Erläuterung der Zeitreihen-ID umfasst. Sie sehen zwei verschiedene Beispiele für JSON-Telemetrienutzdaten mit jeweils der richtigen Auswahl der Zeitreihen-ID.

Zu den wichtigsten bewährten Methoden gehören:

• Wählen Sie einen Partitionsschlüssel mit vielen unterschiedlichen Werten (z. B. Hunderten oder Tausenden) aus. In vielen Fällen kann dies die Geräte-ID, die Sensor-ID oder die Tag-ID in Ihrem JSON sein.
• Die Time Series-ID sollte auf Blattknotenebene Ihres Zeitreihenmodells eindeutig sein.
• Das Zeichenlimit für die Zeichenfolge des Eigenschaftsnamens der Time Series-ID ist 128. Für den Eigenschaftswert der Time Series-ID ist das Zeichenlimit 1.024.
• Wenn ein eindeutiger Eigenschaftswert für die Time Series-ID fehlt, wird er als Nullwert behandelt und folgt derselben Regel der Eindeutigkeitseinschränkung.
• Ist Ihre Zeitreihen-ID (Time Series-ID) in einem komplexen JSON-Objekt geschachtelt, müssen Sie gemäß den eingangsbezogenen Vereinfachungsregeln vorgehen, wenn Sie den Eigenschaftsnamen angeben. Sehen Sie sich das Beispiel B an.
• Darüber hinaus können Sie bis zu drei Schlüsseleigenschaften als Ihre Time Series-ID auswählen. Deren Kombination ergibt einen zusammengesetzten Schlüssel, der die Time Series-ID darstellt.

  Hinweis

  Ihre drei Schlüsseleigenschaften müssen Zeichenfolgen sein. Sie müssten dann diesen zusammengesetzten Schlüssel abfragen, anstatt jede Eigenschaft einzeln.

Auswählen mehrerer Schlüsseleigenschaften

Die folgenden Szenarien beschreiben die Auswahl von mehr als einer Schlüsseleigenschaft als Ihre Time Series-ID.

Beispiel 1: Time Series-ID mit einem eindeutigen Schlüssel

• Sie besitzen Legacygruppen von Ressourcen. Jede besitzt einen eindeutigen Schlüssel.
• Eine Gruppe wird eindeutig durch die Eigenschaft deviceId identifiziert. Für eine andere Gruppe ist die eindeutige Eigenschaft objectId. Keine der Gruppen enthält die eindeutige Eigenschaft der jeweils anderen Gruppe. In diesem Beispiel würden Sie zwei Schlüssel, deviceId und die objectId, als eindeutige Schlüssel auswählen.
• Wir akzeptieren Nullwerte, und das Fehlen einer Eigenschaft in der Ereignisnutzlast zählt als ein Nullwert. Dies ist auch die geeignete Methode, um das Senden von Daten an zwei Ereignisquellen zu handhaben, wobei die Daten in jeder Ereignisquelle eine eindeutige Time Series-ID haben.

Beispiel 2: Time Series-ID mit einem zusammengesetzten Schlüssel

• Ihre Anforderung ist, dass mehrere Eigenschaften innerhalb derselben Gruppe von Ressourcen eindeutig sind.
• Sie sind ein Hersteller von intelligenten Gebäuden und stellen in jedem Raum Sensoren bereit. In jedem Raum haben Sie normalerweise dieselben Werte für sensorId. Beispiele sind sensor1, sensor2 und sensor3.
• Ihr Gebäude besitzt sich überlappende Stockwerk- und Raumnummern zwischen Standorten in der Eigenschaft flrRm. Diese Nummern haben Werte wie 1a, 2b und 3a.
• Sie haben eine Eigenschaft, location (Ort), die Werte wie Redmond, Barcelona und Tokio enthält. Um Eindeutigkeit herzustellen, legen Sie die folgenden drei Eigenschaften als Ihre Time Series-ID-Schlüssel fest: sensorId, flrRm und location.

Beispielrohereignis:

{
  "sensorId": "sensor1",
  "flrRm": "1a",
  "location": "Redmond",
  "temperature": 78
}

Im Azure-Portal können Sie diesen zusammengesetzten Schlüssel dann folgendermaßen eingeben:

Nächste Schritte

• Lesen Sie die JSON-Vereinfachungs- und -Escaperegeln, um zu verstehen, wie Ereignisse gespeichert werden.

• Planen Sie Ihre Azure Time Series Insights Gen2-Umgebung.