Freigeben über

Optimieren der Anforderungskosten in Azure Cosmos DB

APPLIES TO: NoSQL MongoDB Kassandra Kobold Tabelle

In diesem Artikel wird beschrieben, wie Lese- und Schreibanforderungen in Anforderungseinheiten (RU) übersetzt werden und wie Sie die Kosten dieser Anforderungen optimieren. Lesevorgänge umfassen Punktlesevorgänge und Abfragen. Schreibvorgänge umfassen Einfüge-, Ersetzungs-, Lösch- und Upsert-Vorgänge für Elemente.

Azure Cosmos DB bietet eine umfangreiche Sammlung von Datenbankvorgängen, die für die Elemente in einem Container ausgeführt werden. Die Kosten im Zusammenhang mit diesen Vorgängen variieren basierend auf dem CPU-, E/A- und Speicheraufwand, der für den jeweiligen Vorgang erforderlich ist. Anstatt hardwarebasierte Ressourcen zu berücksichtigen und zu verwalten, können Sie sich eine RU als einzelnes Maß für die Ressourcen vorstellen, die zum Ausführen verschiedener Datenbankvorgänge zur Bereitstellung einer Anforderung erforderlich sind.

Messen der RU-Belastung einer Anforderung

Es ist wichtig, die RU-Belastung Ihrer Anforderungen zu messen, um ihre tatsächlichen Kosten zu verstehen und auch die Effektivität Ihrer Optimierungen zu bewerten. Sie können diese Kosten über das Azure-Portal abrufen oder die von Azure Cosmos DB zurückgesendete Antwort über eine der SDKs überprüfen. Ausführliche Anweisungen dazu finden Sie unter Ermitteln der Gebühr für eine Anforderungseinheit in Azure Cosmos DB.

Lesen von Daten: Punktlesevorgänge und Abfragen

Lesevorgänge in Azure Cosmos DB werden in der Regel (absteigend von den schnellsten/effizientesten zu den langsameren/weniger effizienten Vorgängen) in Bezug auf den RU-Verbrauch wie folgt sortiert:

  • Punktlesevorgänge (Schlüssel-/Wertsuche für eine einzelne Element-ID und einen Partitionsschlüssel)
  • Abfrage mit einer Filterklausel innerhalb eines einzelnen Partitionsschlüssels
  • Abfrage ohne Gleichheits- oder Bereichsfilterklausel für eine Eigenschaft
  • Abfrage ohne Filter

Rolle der Konsistenzebene

When using either the strong or bounded stalenessconsistency levels, the RU cost of any read operation (point read or query) is doubled.

Point reads

Der einzige Faktor, der sich auf die RU-Gebühr für einen Punktlesevorgang auswirkt (neben der verwendeten Konsistenzebene), ist die Größe des abgerufenen Elements. Die folgende Tabelle enthält die RU-Kosten von Punktlesevorgängen für Elemente mit einer Größe von 1 KB und 100 KB.

Item size Kosten eines Punktlesevorgangs
1 KB 1 RU
100 KB 10 RUs

Da Punktlesevorgänge (Schlüssel/Wert-Lookups anhand der Element-ID und des Partitionsschlüssels) die effizientesten Lesevorgänge sind, sollten Sie sicherstellen, dass Ihre Element-ID einen aussagekräftigen Wert aufweist, damit Sie die Elemente nach Möglichkeit mit einem Punktlesevorgang (anstelle einer Abfrage) abrufen können.

Note

In der API für NoSQL können Punktlesevorgänge nur mithilfe der REST-API oder SDKs durchgeführt werden. Abfragen, die nach der ID und dem Partitionsschlüssel eines Elements filtern, gelten nicht als Punktlesevorgänge. Ein Beispiel mit dem .NET SDK finden Sie unter Lesen eines Elements in Azure Cosmos DB für NoSQL.

Queries

Anforderungseinheiten für Abfragen sind von vielen Faktoren abhängig, z. B. die Anzahl der geladenen oder zurückgegebenen Azure Cosmos DB-Elemente, die Anzahl der Nachschlagevorgänge für den Index und die Abfragekompilierungszeit. Azure Cosmos DB garantiert, dass dieselbe Abfrage, wenn sie auf denselben Daten ausgeführt wird, immer dieselbe Anzahl von Anforderungseinheiten nutzt, auch bei wiederholten Ausführungen. Das Abfrageprofil, das Abfrageausführungsmetriken verwendet, bietet Ihnen einen guten Überblick darüber, wie die Anforderungseinheiten verbraucht werden.

In einigen Fällen werden möglicherweise eine Abfolge von 200 und 429 Antworten und variablen Anforderungseinheiten in einer seitenseitigen Ausführung von Abfragen angezeigt, da Abfragen so schnell wie möglich basierend auf den verfügbaren RUs ausgeführt werden. Möglicherweise wird ein Abfrageausführungswechsel in mehrere Seiten/Roundtrips zwischen Server und Client angezeigt. Beispielsweise können 10.000 Elemente als mehrere Seiten zurückgegeben werden, die jeweils auf der Berechnung basieren, die für diese Seite ausgeführt wurde. Wenn Sie die Summen dieser Seiten addieren, erhalten Sie die gleiche Anzahl an Anforderungseinheiten, die Sie für die gesamte Abfrage erhalten würden.

Metriken für Abfragen zur Problembehandlung

Die von Abfragen verbrauchte Leistung und der Durchsatz (einschließlich benutzerdefinierter Funktionen) hängen hauptsächlich vom Funktionsrumpf ab. Wie lange die Ausführung der Abfrage in der benutzerdefinierten Funktion (UDF) dauert und wie viele Anforderungseinheiten verbraucht werden, können Sie am einfachsten herausfinden, indem Sie die Abfragemetriken aktivieren. Wenn Sie das .NET-SDK verwenden, finden Sie hier einige Beispiele für Abfragemetriken, die vom SDK zurückgegeben werden:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Bewährte Methoden zum Optimieren der Abfragekosten

Berücksichtigen Sie bei der Kostenoptimierung von Abfragen die folgenden bewährten Methoden:

  • Zusammenstellen von mehreren Entitätstypen

    Versuchen Sie, mehrere Entitätstypen in einem oder einigen wenigen Containern zusammenzustellen. Diese Methode bietet nicht nur Vorteile aus preislicher Sicht, sondern wirkt sich auch positiv auf die Ausführung von Abfragen und Transaktionen aus. Abfragen werden auf einen einzelnen Container begrenzt, und atomische Transaktionen für mehrere Datensätze über gespeicherte Prozeduren/Trigger hinweg werden auf einen Partitionsschlüssel in einem einzelnen Container begrenzt. Durch das Zusammenstellen von Entitäten im selben Container können Sie die Anzahl der Netzwerk-Roundtrips zum Auflösen von Beziehungen zwischen den Datensätzen reduzieren. Dadurch erhöht sich die End-to-End-Leistung und ermöglicht atomische Transaktionen über mehrere Datensätze für ein größeres Dataset. In Folge sinken die Kosten. Wenn das Kolocieren mehrerer Entitätstypen innerhalb einer einzelnen oder kleineren Anzahl von Containern für Ihr Szenario schwierig ist, in der Regel, da Sie eine vorhandene Anwendung migrieren und keine Codeänderungen vornehmen möchten, sollten Sie dann den Bereitstellungsdurchsatz auf Datenbankebene in Betracht ziehen.

  • Messen und Optimieren (Senken) der Anzahl von Anforderungseinheiten pro Sekunde

    Die Komplexität einer Abfrage wirkt sich auf die Anzahl der für einen Vorgang verbrauchten RUs aus. zum Beispiel die Anzahl von Prädikaten, die Art der Prädikate, die Anzahl von UDFs und die Größe des Quelldatasets. All diese Faktoren beeinflussen die Kosten von Abfragevorgängen.

Durch die Verwendung eines Modells mit bereitgestelltem Durchsatz bietet Azure Cosmos DB eine vorhersagbare Leistung in Hinblick auf Durchsatz und Latenz. Der bereitgestellte Durchsatz wird in Bezug auf RUs pro Sekunde oder RU/s dargestellt. Ein RU ist eine logische Abstraktion über Rechenressourcen wie CPU, Arbeitsspeicher, E/A usw., die zum Ausführen einer Anforderung erforderlich sind. Der bereitgestellte Durchsatz (RUs/Sek.) wird reserviert und fest dem Container oder der Datenbank zugeordnet, um vorhersagbaren Durchsatz und vorhersehbare Latenz bereitzustellen. Mit dem bereitgestellten Durchsatz kann Azure Cosmos DB für eine vorhersagbare und konsistente Leistung sorgen, die niedrige Latenzzeiten und eine hohe Verfügbarkeit auf jeder Skalierungsstufe garantiert. RUs stellen die normalisierte Währung dar, die die Gründe dafür vereinfacht, wie viele Ressourcen eine Anwendung benötigt.

Die im Header der Anforderung zurückgegebene Anforderungsgebühr gibt die Kosten für eine bestimmte Abfrage an. Wenn eine Abfrage beispielsweise 1000 KB-Elemente zurückgibt, beträgt die Kosten für den Vorgang 1000. Somit werden vom Server innerhalb einer Sekunde nur zwei solcher Anforderungen berücksichtigt, und für weitere Anforderungen wird die Rate begrenzt. Weitere Informationen finden Sie unter Anforderungseinheiten in Azure Cosmos DB und dem Anforderungseinheitsrechner.

Write data

Die RU-Kosten für das Schreiben eines Elements hängen von Folgendem ab:

  • Die Elementgröße
  • The number of properties covered by the indexing policy and needed to be indexed

Das Einfügen eines 1-KB-Elements ohne Indizierung kostet ca. 5,5 RUs. Das Ersetzen eines Elements kostet zweimal so viel wie das Einfügen desselben Elements.

Optimize writes

Die beste Möglichkeit, die RU-Kosten von Schreibvorgängen zu optimieren, ist das Anpassen der Elementgröße und der Anzahl der indizierten Eigenschaften.

  • Das Speichern sehr großer Elemente in Azure Cosmos DB führt zu hohen RU-Gebühren und kann als Antimuster angesehen werden. Speichern Sie insbesondere keine Binärinhalte oder großen Textblöcke, die nicht abgefragt werden müssen. Es hat sich bewährt, diese Art von Daten in Azure Blob Storage abzulegen und einen Verweis (oder Link) auf das Blob in dem Element zu speichern, das Sie in Azure Cosmos DB schreiben.
  • Wenn Sie die Indizierungsrichtlinie so optimieren, dass nur die Eigenschaften indiziert werden, nach denen Ihre Abfragen filtern, kann dies in Bezug auf die von Schreibvorgängen verbrauchten RUs einen großen Unterschied machen. Wenn Sie einen neuen Container erstellen, wird mit der Standardindizierungsrichtlinie jede in den Elementen gefundene Eigenschaft indiziert. Dies ist zwar ein guter Standardwert für Entwicklungsaktivitäten, es wird jedoch dringend empfohlen, Ihre Indizierungsrichtlinie beim Produktionsbetrieb neu zu bewerten und anzupassen oder wenn Ihre Arbeitsauslastung mit erheblichem Datenverkehr beginnt.

Bei der Massenaufnahme von Daten empfiehlt es sich auch, die Azure Cosmos DB-Massenausführerbibliothek zu verwenden, da sie entwickelt wurde, um den RU-Verbrauch solcher Vorgänge zu optimieren. Optional können Sie auch Azure Data Factory verwenden, das auf derselben Bibliothek basiert.

Next steps

Als Nächstes können Sie mithilfe der folgenden Artikel mehr über die Kostenoptimierung in Azure Cosmos DB erfahren:

Versuchen Sie, die Kapazitätsplanung für eine Migration zu Azure Cosmos DB durchzuführen? Sie können Informationen zu Ihrem vorhandenen Datenbankcluster für die Kapazitätsplanung verwenden.