Für ähnliche Funktionen wie Amazon Timestream für sollten Sie Amazon Timestream for LiveAnalytics InfluxDB in Betracht ziehen. Es bietet eine vereinfachte Datenaufnahme und Antwortzeiten im einstelligen Millisekundenbereich für Analysen in Echtzeit. [Erfahren](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html) Sie hier mehr. Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Verwenden von Abfrageerkenntnissen zur Optimierung von Abfragen in Amazon Timestream Query Insights ist eine Funktion zur Leistungsoptimierung, mit der Sie Ihre Abfragen optimieren, ihre Leistung verbessern und Kosten senken können. Mit Query Insights können Sie die Effizienz Ihrer Abfragen anhand von Schlüsseln anhand der zeitlichen, zeitbasierten und räumlichen Partition beurteilen. Mithilfe von Abfrageerkenntnissen können Sie auch Bereiche identifizieren, in denen Verbesserungspotenzial besteht, um die Abfrageleistung zu verbessern. Darüber hinaus können Sie mit Query Insights bewerten, wie effektiv Ihre Abfragen die zeitbasierte und partitionsschlüsselbasierte Indizierung nutzen, um den Datenabruf zu optimieren. Um die Abfrageleistung zu optimieren, ist es wichtig, sowohl die zeitlichen als auch die räumlichen Parameter, die die Abfrageausführung steuern, zu optimieren. **Topics** + [Vorteile von Query Insights](#query-insights-benefits) + [Optimieren des Datenzugriffs in Amazon Timestream](query-insights-optimize-data-access-pattern.md) + [Aktivierung von Query-Insights in Amazon Timestream](enable-query-insights.md) + [Optimierung von Abfragen mithilfe von Query Insights Response](optimize-query-using-query-insights.md) ## Vorteile von Query Insights Im Folgenden sind die wichtigsten Vorteile der Verwendung von Query Insights aufgeführt: + **Identifizierung ineffizienter Abfragen** — Query Insights bietet Informationen zur zeit- und attributbasierten Bereinigung der Tabellen, auf die mit der Abfrage zugegriffen wird. Anhand dieser Informationen können Sie die Tabellen identifizieren, auf die nicht optimal zugegriffen wird. + **Optimierung Ihres Datenmodells und Partitionierung** — Sie können die Informationen aus den Query-Insights verwenden, um auf Ihr Datenmodell und Ihre Partitionierungsstrategie zuzugreifen und diese zu optimieren. + **Optimieren von Abfragen** — Query Insights zeigt Möglichkeiten auf, Indizes effektiver zu nutzen. # Optimieren des Datenzugriffs in Amazon Timestream Sie können die Datenzugriffsmuster in Amazon Timestream mithilfe des Timestream-Partitionierungsschemas oder der Datenorganisationstechniken optimieren. **Topics** + [Timestream-Partitionierungsschema](#query-insights-optimize-data-access-partitioning-scheme) + [Datenorganisation](#query-insights-optimize-data-access-data-org) ## Timestream-Partitionierungsschema Amazon Timestream verwendet ein hoch skalierbares Partitionierungsschema, bei dem jede Timestream-Tabelle Hunderte, Tausende oder sogar Millionen unabhängiger Partitionen haben kann. Ein hochverfügbarer Dienst zur Partitionsverfolgung und Indizierung verwaltet die Partitionierung, minimiert die Auswirkungen von Ausfällen und macht das System widerstandsfähiger. ![\[Timestream-Partitionierungsschema\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/images/QueryInsights/ts-partitioning-scheme.png) ## Datenorganisation Timestream speichert jeden Datenpunkt, den es aufnimmt, in einer einzigen Partition. Wenn Sie Daten in eine Timestream-Tabelle aufnehmen, erstellt Timestream automatisch Partitionen auf der Grundlage der Zeitstempel, des Partitionsschlüssels und anderer Kontextattribute in den Daten. Neben der zeitlichen Partitionierung der Daten (zeitliche Partitionierung) partitioniert Timestream die Daten auch auf der Grundlage des ausgewählten Partitionierungsschlüssels und anderer Dimensionen (räumliche Partitionierung). Dieser Ansatz ist darauf ausgelegt, den Schreibverkehr zu verteilen und eine effektive Bereinigung von Daten für Abfragen zu ermöglichen. Die Funktion für Abfrageerkenntnisse bietet wertvolle Einblicke in die Effizienz der Bereinigung von Abfragen, einschließlich der räumlichen Abdeckung von Abfragen und der zeitlichen Abdeckung von Abfragen. **Topics** + [QuerySpatialCoverage](#query-insights-data-org-query-spatial-cvg) + [QueryTemporalCoverage](#query-insights-data-org-query-temporal-cvg) ### QuerySpatialCoverage Die [QuerySpatialCoverage](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_QuerySpatialCoverage.html)Metrik bietet Einblicke in die räumliche Abdeckung der ausgeführten Abfrage und in die Tabelle mit der ineffizientesten räumlichen Bereinigung. Diese Informationen können Ihnen helfen, Bereiche zu identifizieren, in denen die Partitionierungsstrategie verbessert werden kann, um die räumliche Kürzung zu verbessern. Der Wert für die `QuerySpatialCoverage` Metrik liegt zwischen 0 und 1. Je niedriger der Wert der Metrik ist, desto optimaler ist die Bereinigung der Abfrage auf der räumlichen Achse. Ein Wert von 0,1 gibt beispielsweise an, dass die Abfrage 10% der räumlichen Achse scannt. Ein Wert von 1 gibt an, dass die Abfrage 100% der räumlichen Achse scannt. **Example Verwenden von Abfrageerkenntnissen zur Analyse der räumlichen Abdeckung einer Abfrage** Angenommen, Sie haben eine Timestream-Datenbank, die Wetterdaten speichert. Gehen Sie davon aus, dass die Temperatur jede Stunde von Wetterstationen in verschiedenen Bundesstaaten der Vereinigte Staaten aufgezeichnet wird. Stellen Sie sich vor, Sie wählen `State` den [benutzerdefinierten Partitionsschlüssel](customer-defined-partition-keys.md) (CDPK), um die Daten nach Status zu partitionieren. Angenommen, Sie führen eine Abfrage aus, um die Durchschnittstemperatur aller Wetterstationen in Kalifornien zwischen 14 Uhr und 16 Uhr an einem bestimmten Tag abzurufen. Das folgende Beispiel zeigt die Abfrage für dieses Szenario. ``` SELECT AVG(temperature) FROM "weather_data"."hourly_weather" WHERE time >= '2024-10-01 14:00:00' AND time < '2024-10-01 16:00:00' AND state = 'CA'; ``` Mithilfe der Funktion Query Insights können Sie die räumliche Abdeckung der Abfrage analysieren. Stellen Sie sich vor, dass die `QuerySpatialCoverage` Metrik einen Wert von 0,02 zurückgibt. Das bedeutet, dass die Abfrage nur 2% der räumlichen Achse gescannt hat, was effizient ist. In diesem Fall war die Abfrage in der Lage, den räumlichen Bereich effektiv zu kürzen, indem nur Daten aus Kalifornien abgerufen und Daten aus anderen Bundesstaaten ignoriert wurden. Im Gegenteil, wenn die `QuerySpatialCoverage` Metrik einen Wert von 0,8 zurückgibt, würde dies bedeuten, dass die Abfrage 80% der räumlichen Achse gescannt hat, was weniger effizient ist. Dies könnte darauf hindeuten, dass die Partitionierungsstrategie verfeinert werden muss, um die räumliche Bereinigung zu verbessern. Sie können den Partitionsschlüssel beispielsweise als Stadt oder Region statt als Bundesland auswählen. Durch die Analyse der `QuerySpatialCoverage` Metrik können Sie Möglichkeiten zur Optimierung Ihrer Partitionierungsstrategie und zur Verbesserung der Leistung Ihrer Abfragen identifizieren. Die folgende Abbildung zeigt eine schlechte räumliche Bereinigung. ![\[Ergebnis der QuerySpatialCoverage Metrik, die eine schlechte räumliche Bereinigung zeigt.\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/images/QueryInsights/QuerySpatialCoverageMetricResult.png) Um die Effizienz beim räumlichen Beschneiden zu verbessern, können Sie eine oder beide der folgenden Aktionen ausführen: + Fügen Sie `measure_name` den Standard-Partitionierungsschlüssel hinzu, oder verwenden Sie die CDPK-Prädikate in Ihrer Abfrage. + Wenn Sie die im vorherigen Punkt genannten Attribute bereits hinzugefügt haben, entfernen Sie Funktionen rund um diese Attribute oder Klauseln, z. B. `LIKE` ### QueryTemporalCoverage Die `QueryTemporalCoverage` Metrik bietet Einblicke in den Zeitbereich, der von der ausgeführten Abfrage gescannt wurde, einschließlich der Tabelle mit dem größten gescannten Zeitraum. Der Wert für die `QueryTemporalCoverage` Metrik ist der Zeitbereich, der in Nanosekunden dargestellt wird. Je niedriger der Wert dieser Metrik ist, desto optimaler ist die Abfragebereinigung im Zeitbereich. Beispielsweise ist eine Abfrage, die Daten der letzten Minuten scannt, leistungsfähiger als eine Abfrage, die den gesamten Zeitraum der Tabelle scannt. **Example** Angenommen, Sie haben eine Timestream-Datenbank, in der IoT-Sensordaten gespeichert werden, wobei jede Minute Messungen von Geräten in einer Produktionsstätte durchgeführt werden. Gehen Sie davon aus, dass Sie Ihre Daten nach partitioniert haben. `device_ID` Angenommen, Sie führen eine Abfrage aus, um den durchschnittlichen Sensorwert für ein bestimmtes Gerät in den letzten 30 Minuten abzurufen. Das folgende Beispiel zeigt die Abfrage für dieses Szenario. ``` SELECT AVG(sensor_reading) FROM "sensor_data"."factory_1" WHERE device_id = 'DEV_123' AND time >= NOW() - INTERVAL 30 MINUTE and time < NOW(); ``` Mithilfe der Funktion für Abfrageerkenntnisse können Sie den von der Abfrage gescannten Zeitbereich analysieren. Stellen Sie sich vor, die `QueryTemporalCoverage` Metrik gibt einen Wert von 1800000000000 Nanosekunden (30 Minuten) zurück. Das bedeutet, dass die Abfrage nur die Daten der letzten 30 Minuten gescannt hat, was ein relativ enger Zeitbereich ist. Dies ist ein gutes Zeichen, da es darauf hinweist, dass die Abfrage die zeitliche Partitionierung effektiv bereinigen konnte und nur die angeforderten Daten abgerufen hat. Im Gegenteil, wenn die `QueryTemporalCoverage` Metrik einen Wert von 1 Jahr in Nanosekunden zurückgibt, bedeutet dies, dass die Abfrage einen Zeitraum von einem Jahr in der Tabelle gescannt hat, was weniger effizient ist. Dies könnte darauf hindeuten, dass die Abfrage nicht für die zeitliche Bereinigung optimiert ist, und Sie könnten sie verbessern, indem Sie Zeitfilter hinzufügen. Die folgende Abbildung zeigt ein schlechtes zeitliches Beschneiden. ![\[Ergebnis der QueryTemporalCoverage Metrik, die ein schlechtes zeitliches Beschneiden zeigt.\]](http://docs.aws.amazon.com/de_de/timestream/latest/developerguide/images/QueryInsights/QueryTemporalCoverageMetricResult.png) Um den zeitlichen Schnitt zu verbessern, empfehlen wir Ihnen, einen oder alle der folgenden Schritte durchzuführen: + Fügen Sie der Abfrage die fehlenden Zeitprädikate hinzu und stellen Sie sicher, dass die Zeitprädikate das gewünschte Zeitfenster bereinigen. + Entfernen Sie Funktionen wie etwa `MAX()` Zeitprädikate. + Fügen Sie allen Unterabfragen Zeitprädikate hinzu. Dies ist wichtig, wenn Ihre Unterabfragen große Tabellen verknüpfen oder komplexe Operationen ausführen. # Aktivierung von Query-Insights in Amazon Timestream Sie können Query-Insights für Ihre Abfragen mithilfe von Erkenntnissen aktivieren, die direkt über die Abfrageantwort bereitgestellt werden. Für die Aktivierung von Query Insights ist keine zusätzliche Infrastruktur erforderlich und es fallen keine zusätzlichen Kosten an. Wenn Sie Query Insights aktivieren, werden zusätzlich zu den Abfrageergebnissen als Teil Ihrer Abfrageantwort Metadatenfelder zurückgegeben, die sich auf die Abfrageleistung beziehen. Sie können diese Informationen verwenden, um Ihre Abfragen zu optimieren, um die Abfrageleistung zu verbessern und die Abfragekosten zu senken. Informationen zur Aktivierung von Query Insights finden Sie unter[Ausführen einer -Abfrage](console_timestream.md#console_timestream.queries.using-console). Beispiele für Antworten, die durch die Aktivierung von Query Insights zurückgegeben wurden, finden Sie unter [Beispiele für geplante Abfragen](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_ExecuteScheduledQuery.html#API_query_ExecuteScheduledQuery_Examples). **Anmerkung** Wenn Sie Query Insights aktivieren, begrenzt die Rate die Abfrage auf 1 Abfrage pro Sekunde (QPS). Um Leistungseinbußen zu vermeiden, empfehlen wir dringend, Query Insights nur während der Evaluierungsphase Ihrer Abfragen zu aktivieren, bevor Sie sie in der Produktion einsetzen. Die in Query Insights bereitgestellten Erkenntnisse sind letztlich konsistent, was bedeutet, dass sie sich ändern können, wenn kontinuierlich neue Daten in die Tabellen aufgenommen werden. # Optimierung von Abfragen mithilfe von Query Insights Response Angenommen, Sie verwenden Amazon Timestream LiveAnalytics , um den Energieverbrauch an verschiedenen Standorten zu überwachen. Stellen Sie sich vor, Sie haben zwei Tabellen in Ihrer Datenbank mit dem Namen `raw-metrics` und`aggregate-metrics`. Die `raw-metrics` Tabelle speichert detaillierte Energiedaten auf Geräteebene und enthält die folgenden Spalten: + Zeitstempel + Bundesstaat, zum Beispiel Washington + Geräte-ID + Energieverbrauch Die Daten für diese Tabelle werden mit einer bestimmten minute-by-minute Granularität gesammelt und gespeichert. Die Tabelle wird `State` als CDPK verwendet. In der `aggregate-metrics` Tabelle wird das Ergebnis einer geplanten Abfrage gespeichert, um die Energieverbrauchsdaten aller Geräte stündlich zu aggregieren. Diese Tabelle enthält die folgenden Spalten: + Zeitstempel + Bundesstaat, zum Beispiel Washington + Gesamter Energieverbrauch In der `aggregate-metrics` Tabelle werden diese Daten mit stündlicher Granularität gespeichert. Die Tabelle wird `State` als CDPK verwendet. **Topics** + [Der Energieverbrauch der letzten 24 Stunden wird abgefragt](#query-energy-consumption-data) + [Optimierung der Abfrage für den Zeitbereich](#optimize-query-temporal-range) + [Optimierung der Abfrage im Hinblick auf die räumliche Abdeckung](#optimize-query-spatial-coverage) + [Die Abfrageleistung wurde verbessert](#improved-query-performance) ## Der Energieverbrauch der letzten 24 Stunden wird abgefragt Angenommen, Sie möchten den gesamten Energieverbrauch in Washington in den letzten 24 Stunden ermitteln. Um diese Daten zu finden, können Sie die Stärken der beiden Tabellen nutzen: `raw-metrics` und`aggregate-metrics`. Die `aggregate-metrics` Tabelle enthält stündliche Energieverbrauchsdaten für die letzten 23 Stunden, während die `raw-metrics` Tabelle minutengenaue Daten für die letzte Stunde enthält. Wenn Sie beide Tabellen abfragen, können Sie sich ein vollständiges und genaues Bild vom Energieverbrauch in Washington in den letzten 24 Stunden machen. ``` SELECT am.time, am.state, am.total_energy_consumption, rm.time, rm.state, rm.device_id, rm.energy_consumption FROM "metrics"."aggregate-metrics" am LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state WHERE rm.time >= ago(1h) and rm.time < now() ``` Diese Beispielabfrage dient nur zur Veranschaulichung und funktioniert möglicherweise nicht so, wie sie ist. Sie soll das Konzept veranschaulichen, aber Sie müssen es möglicherweise an Ihren spezifischen Anwendungsfall oder Ihre Umgebung anpassen. Nach der Ausführung dieser Abfrage stellen Sie möglicherweise fest, dass die Antwortzeit der Abfrage langsamer als erwartet ist. Um die Ursache für dieses Leistungsproblem zu ermitteln, können Sie die Query Insights-Funktion verwenden, um die Leistung der Abfrage zu analysieren und ihre Ausführung zu optimieren. Das folgende Beispiel zeigt die Antwort auf Query Insights. ``` queryInsightsResponse={ QuerySpatialCoverage: { Max: { Value: 1.0, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/raw-metrics, PartitionKey: [State] } }, QueryTemporalRange: { Max: { Value:31540000000000000 //365 days, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics } }, QueryTableCount: 2, OutputRows: 83, OutputBytes: 590 ``` Die Query Insights-Antwort enthält die folgenden Informationen: + **Zeitlicher Bereich**: Die Abfrage hat einen zu großen Zeitbereich von 365 Tagen für die `aggregate-metrics` Tabelle durchsucht. Dies deutet auf eine ineffiziente Verwendung der zeitlichen Filterung hin. + **Räumliche Abdeckung**: Die Abfrage hat den gesamten räumlichen Bereich (100%) der `raw-metrics` Tabelle gescannt. Dies deutet darauf hin, dass die räumliche Filterung nicht effektiv genutzt wird. Wenn Ihre Abfrage auf mehr als eine Tabelle zugreift, liefert Query Insights die Metriken für die Tabelle mit den suboptimalsten Zugriffsmustern. ## Optimierung der Abfrage für den Zeitbereich Basierend auf der Query Insights-Antwort können Sie die Abfrage für den Zeitbereich optimieren, wie im folgenden Beispiel gezeigt. ``` SELECT am.time, am.state, am.total_energy_consumption, rm.time, rm.state, rm.device_id, rm.energy_consumption FROM "metrics"."aggregate-metrics" am LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state WHERE am.time >= ago(23h) and am.time < now() AND rm.time >= ago(1h) and rm.time < now() AND rm.state = 'Washington' ``` Wenn Sie den `QueryInsights` Befehl erneut ausführen, wird die folgende Antwort zurückgegeben. ``` queryInsightsResponse={ QuerySpatialCoverage: { Max: { Value: 1.0, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics, PartitionKey: [State] } }, QueryTemporalRange: { Max: { Value: 82800000000000 //23 hours, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics } }, QueryTableCount: 2, OutputRows: 83, OutputBytes: 590 ``` Diese Antwort zeigt, dass die räumliche Abdeckung der `aggregate-metrics` Tabelle immer noch 100% beträgt, was ineffizient ist. Im folgenden Abschnitt wird gezeigt, wie die Abfrage für die räumliche Abdeckung optimiert werden kann. ## Optimierung der Abfrage im Hinblick auf die räumliche Abdeckung Auf der Grundlage der Query Insights-Antwort können Sie die Abfrage im Hinblick auf die räumliche Abdeckung optimieren, wie im folgenden Beispiel gezeigt. ``` SELECT am.time, am.state, am.total_energy_consumption, rm.time, rm.state, rm.device_id, rm.energy_consumption FROM "metrics"."aggregate-metrics" am LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state WHERE am.time >= ago(23h) and am.time < now() AND am.state ='Washington' AND rm.time >= ago(1h) and rm.time < now() AND rm.state = 'Washington' ``` Wenn Sie den `QueryInsights` Befehl erneut ausführen, wird die folgende Antwort zurückgegeben. ``` queryInsightsResponse={ QuerySpatialCoverage: { Max: { Value: 0.02, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics, PartitionKey: [State] } }, QueryTemporalRange: { Max: { Value: 82800000000000 //23 hours, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics } }, QueryTableCount: 2, OutputRows: 83, OutputBytes: 590 ``` ## Die Abfrageleistung wurde verbessert Nach der Optimierung der Abfrage bietet Query Insights die folgenden Informationen: + Der Zeitaufwand für die `aggregate-metrics` Bereinigung der Tabelle beträgt 23 Stunden. Dies bedeutet, dass nur 23 Stunden des Zeitbereichs gescannt werden. + Der räumliche Schnitt für die `aggregate-metrics` Tabelle beträgt 0,02. Dies bedeutet, dass nur 2% der räumlichen Bereichsdaten der Tabelle gescannt werden. Die Abfrage scannt nur einen sehr kleinen Teil der Tabellen, was zu einer schnelleren Leistung und einer geringeren Ressourcenauslastung führt. Die verbesserte Bereinigungseffizienz deutet darauf hin, dass die Abfrage jetzt leistungsoptimiert ist.