Ressourcenmodell, Durchsatz und Request Units

Die Kladde bleibt bei Azure SQL (K3, Lektion 3.6.4). Daneben entsteht Kladde.Verlauf: ein Dienst, der aus der Kladde gespeist wird und Cosmos DB for NoSQL nutzt, weil dort die Auslöser aus K3 vorliegen. Diese Lektion legt das Fundament: Welche Ressourcen gibt es, was stellen Sie auf welcher Ebene ein, und wie viel Durchsatz bekommt welcher Container?

Vorwissen. Die fünf Begriffe (Partitionsschlüssel, Request Units, Konsistenzstufen, Elementgrenze, Änderungsfeed) und die Emulatoren stehen in „K3, Lektion 3.6.4" und werden nicht wiederholt; die Konsistenzstufen vertieft „K4, Lektion 4.11.4".

Was ausgeführt wurde. Die C#-Programme dieser Lektion wurden mit Microsoft.Azure.Cosmos 3.64.0 (neueste stabile Fassung am Schreibtag) und Newtonsoft.Json 13.0.4 übersetzt; die Rechenprogramme liefen ohne Konto, das Bicep-Beispiel wurde mit Bicep 0.43.8 übersetzt. Gegen Azure ausgeführt wurde nichts; jede Stelle, die ein Konto braucht, sagt es. Zahlen in Tabellen sind Annahmen der Aufgabe, keine Messwerte.

Das Ressourcenmodell

Ein Konto enthält Datenbanken, eine Datenbank Container, ein Container Elemente. Learn nennt die Datenbank die Verwaltungseinheit und den Container die Einheit der Skalierung für Durchsatz und Speicher. Am Konto stellen Sie Regionen, Standard-Konsistenzstufe, Anmeldung (Schlüssel oder Entra), Netzwerk und Sicherung ein, am Container den Partitionsschlüssel (später nicht änderbar), den Durchsatz, die Indexrichtlinie, die Ablaufzeit (TTL) und eindeutige Schlüssel.

Grenzen laut Learn (Seite „service quotas and default limits"): höchstens 500 Datenbanken und Container zusammen je Konto (nicht erhöhbar), 1.000.000 RU/s je Container (mit Antrag mehr), 10.000 RU/s und 20 GB je logischer Partition. Für Verwaltungsaufrufe hat ein Konto nur 240 RU/s; deshalb gehören Namen in die Konfiguration, und Container werden nicht bei jeder Anfrage „geprüft" (Lektion 1.2).

Die Container der Kladde.Verlauf stehen als F-03 fest: appointments, events, conversations, knowledge, leases. Ein Container je Büro wäre ein Fehlmuster, das Learn für mandantenfähige Anwendungen nicht empfiehlt; Mandanten sind Werte des Partitionsschlüssels (Lektion 1.4).

Die Durchsatzmodi

	bereitgestellt (manuell)	Autoscale	serverlos
Sie legen fest	feste Zahl RU/s	Höchstwert `Tmax`	nichts
Kleinster Wert	400 RU/s	`Tmax` mindestens 1.000	–
Der Dienst nutzt	immer die Zahl	`0,1 × Tmax` bis `Tmax`, sofort	je Anfrage
Abgerechnet wird	je Stunde die Zahl	je Stunde der höchste erreichte Wert, mindestens `0,1 × Tmax`	verbrauchte RU und Speicher
Regionen	beliebig viele	beliebig viele	genau eine

Laut Learn am Schreibtag:

Autoscale kostet je RU/s in einem Konto mit einer Schreibregion das 1,5-fache des manuellen Satzes. Daraus folgt Learns Faustregel: Nutzen Sie den Höchstwert in weniger als etwa 66 % der Stunden aus, ist Autoscale günstiger, sonst die feste Zahl (1 ÷ 1,5 ≈ 0,67). Die Messgröße dafür ist die Metrik „Normalized RU Consumption".
Serverlos passt zu Entwicklung, Tests und Last mit langen Pausen (Learn: unter 10 % Verhältnis von Mittel zu Spitze). Ein serverloser Container beginnt mit 5.000 RU/s, je physischer Partition sind es bis zu 5.000 RU/s; Sie können den Durchsatz weder angeben noch lesen, und es gibt keine geteilte Datenbank.
Das kostenlose Kontingent aus K3 (1.000 RU/s, 25 GB) passt für das Testkonto.

Datenbank oder Container? Durchsatz kann auf der Datenbank liegen und wird dann von bis zu 25 Containern geteilt, oder auf dem Container, dem er dann allein gehört. Learn empfiehlt für die meisten Lasten den Durchsatz am Container, weil er vorhersehbar ist. Ein Container lässt sich nicht von eigenem auf geteilten Durchsatz umstellen oder umgekehrt; der Weg ist ein neuer Container und das Kopieren der Daten.

Die Wahl für F-05. Das Entwicklungskonto der Kladde.Verlauf ist serverlos. Die Produktivannahme ist Autoscale mit einem Höchstwert je Container. Grund: Die Last schwankt mit dem Arbeitstag der Büros (F-02) und mit nächtlichen Abgleichen aus der Kladde.

Request Units messen

Jede Antwort des SDK trägt ihren Verbrauch in RequestCharge, auch die FeedResponse einer Abfrage. Nach Learn kostet das Lesen eines Elements von etwa 1 KB über id und Partitionsschlüssel 1 RU. Den Verbrauch bestimmen Elementgröße, Zahl der Eigenschaften und indexierten Pfade, Punktlesen gegen Abfrage, der Aufbau der Abfrage und bei Strong und Bounded Staleness das Doppelte beim Lesen. Dieselbe Abfrage auf denselben Daten kostet jedes Mal gleich viel.

Messen heißt aufschreiben. Dieser Zähler sammelt die Kosten je Operation aus jedem Response<T>:

public void Record<T>(string operation, Response<T> response)
{
    _byOperation.TryGetValue(operation, out var current);
    _byOperation[operation] = (current.Count + 1, current.Total + response.RequestCharge);
}

Für den Test ohne Konto erbt eine Attrappe von ItemResponse<T> (das Antwortobjekt ist dafür gedacht) und setzt den Kopf, aus dem das SDK RequestCharge liest: new Headers { ["x-ms-request-charge"] = "5.5" }. Ein Lauf mit zwei Schreibvorgängen à 5,5 RU und einem Lesevorgang à 1 RU ergab:

read appointment   1 call(s), 1 RU
write appointment  2 call(s), 11 RU

Gegen ein Konto sehen Sie dieselbe Zahl im Portal (Data Explorer, Abfrage ausführen, „Query Stats") und im Diagnoseobjekt jeder Antwort (Lektion 1.2).

Den Bedarf vorab abschätzen

Learn bietet den Kostenrechner (cosmos.azure.com/costestimator). Rechnen Sie zusätzlich selbst, dann ist die Annahme Teil Ihres Entwurfs. Zwei Regeln von Learns Seite zu den Grenzen als Code in Rules: Der kleinste Höchstwert ist MAX(1000, 10 × GB, früherer Höchstwert ÷ 10), auf 1.000 aufgerundet; abgerechnet wird je Stunde MAX(0,1 × Tmax, höchster Wert der Stunde).

Mit den Beispielen aus Learn (50.000 RU/s als höchster früherer Wert):

manual minimum, 0 GB:          400 RU/s
manual minimum, 2000 GB:       2000 RU/s
autoscale max minimum, 20 GB:  5000 RU/s
autoscale max minimum, 2000 GB:20000 RU/s
autoscale max 4000, busiest hour 3500 -> billed 3500 RU/s
autoscale max 4000, idle hour          -> billed 400 RU/s

Das sind die Zahlen der Learn-Seiten. Merken Sie sich: Wer einmal viel bereitgestellt hat, kann nicht beliebig weit zurück, und jedes Gigabyte hebt die Untergrenze (1 RU/s je GB bei fester Zahl, 10 RU/s je GB bei Autoscale).

Die Annahme der Aufgabe (F-05)

Der Höchstwert je Container ergibt sich aus einer Spitzenlast, die Sie festhalten. Alle Werte sind Annahmen: 1 RU je Punktlesen eines Elements von etwa 1 KB (Learn), die übrigen RU je Operation schätzt die Aufgabe, bis ein Konto sie misst, und der Puffer ist der Faktor 3.

Container	Annahme der Spitze (je Sekunde)	RU/s Spitze	Höchstwert
`appointments`	100 Punktlesen à 1, 40 Schreiben à 6, 10 Monatsabfragen à 12	460	2.000
`events`	60 Schreiben à 6, 5 Tagesabfragen à 15	435	2.000
`conversations`	20 Schreiben à 8, 20 Punktlesen à 2	200	1.000
`knowledge`	10 Schreiben à 30, 5 Vektorabfragen à 50	550	2.000
`leases`	10 Aktualisierungen à 6	60	1.000

Das Programm rechnete Spitze mal 3, aufgerundet auf volle 1.000, mindestens 1.000, und gab 2.000, 2.000, 1.000, 2.000 und 1.000 aus, jeweils mit dem Bereich von einem Zehntel bis zum Höchstwert (bei 2.000 also 200 bis 2.000).

Diese Höchstwerte gelten für den ganzen Kurs unverändert (F-05). Spätere Lektionen rechnen mit ihnen. Reichen sie nicht, ändert die Lektion die Annahme ausdrücklich.

Anlegen: im SDK und in Bicep

Im SDK legen CreateDatabaseIfNotExistsAsync und CreateContainerIfNotExistsAsync an, einmal bei der Einrichtung (Learn: jeder Aufruf ist ein Verwaltungsaufruf). Der Code braucht ein Konto und wurde nur übersetzt, nicht gegen Azure ausgeführt:

using var client = new CosmosClient("https://<account>.documents.azure.com:443/", new DefaultAzureCredential());
Database database = await client.CreateDatabaseIfNotExistsAsync("kladde");

var properties = new ContainerProperties("appointments", ["/officeId", "/month"]);
Container appointments = await database.CreateContainerIfNotExistsAsync(
    properties, ThroughputProperties.CreateAutoscaleThroughput(autoscaleMaxThroughput: 2000));

Die Pfadliste ist der hierarchische Schlüssel (Lektion 1.4). ReadThroughputAsync liefert auch die Untergrenze, die der Dienst für den Container verlangt.

In Bicep (K3) gehört die Einrichtung in eine Datei. Auszug: Konto ohne Schlüssel (F-01), Standard-Konsistenz Session (F-04) und die Container aus F-03; die vollständige Datei wurde mit az bicep build übersetzt, nicht bereitgestellt:

bicep

resource account 'Microsoft.DocumentDB/databaseAccounts@2025-04-15' = {
  name: accountName
  location: 'germanywestcentral'
  kind: 'GlobalDocumentDB'
  properties: {
    databaseAccountOfferType: 'Standard'
    locations: [{ locationName: 'germanywestcentral', failoverPriority: 0 }]
    consistencyPolicy: { defaultConsistencyLevel: 'Session' }
    disableLocalAuth: true
    capabilities: serverless ? [{ name: 'EnableServerless' }] : []
  }
}

Je Container kommen partitionKey (hierarchisch: kind: 'MultiHash', version: 2, laut Learn), defaultTtl und, außer serverlos, autoscaleSettings mit dem Höchstwert aus der Tabelle dazu.

disableLocalAuth: true schaltet die Schlüssel ab (Rollen und Entra: Lektion 3.1). Die 90 Tage Ablaufzeit für events sind 90 × 86.400 = 7.776.000 Sekunden. Offen: Ob Autoscale, serverlos und hierarchische Schlüssel in germanywestcentral verfügbar sind, haben die gelesenen Seiten nicht entschieden; prüfen Sie die Regionenübersicht von Learn am Tag der Bereitstellung.

Die Konsistenzstufe als Einstellung

Die Standardstufe gehört zum Konto, hier Session (F-04), und gilt für alle Lesevorgänge und Abfragen. Ein Client darf sie nur abschwächen, mit CosmosClientOptions.ConsistencyLevel oder je Anfrage in ItemRequestOptions; wer stärkere Zusagen für eine einzelne Anfrage braucht, hat laut Learn seit dem .NET-SDK 3.46 die ReadConsistencyStrategy. Ändert sich die Standardstufe am Konto, starten Sie die Anwendung neu, damit das SDK sie übernimmt. Welche Stufe was zusagt, steht in „K4, Lektion 4.11.4".

Übung 1

Teil A, ohne Konto. Legen Sie ru.cs an: Rules nach den Formeln dieser Lektion (feste Zahl: MAX(400, 1 × GB, früherer Höchstwert ÷ 100)), ChargeMeter und die Annahmen der fünf Container.

Prüfen Sie die Beispiele aus Learn: Die Untergrenze bei fester Zahl muss bei 20 GB und einem früheren Höchstwert von 50.000 genau 500 sein, bei 2.000 GB genau 2.000.
Das nächtliche Befüllen von knowledge schreibt 2.000 Textabschnitte à 30 RU. Wie lange dauert es mit dem Höchstwert von 2.000 RU/s, wenn nichts anderes läuft, und was wird für diese Stunde abgerechnet?
Ein neuer Container audit soll 20 Schreibvorgänge je Sekunde à 6 RU aushalten. Welcher Höchstwert ergibt sich?

Teil B, mit einem Testkonto (nicht gegen Azure ausgeführt): Führen Sie create.cs in einem Konto mit bereitgestelltem Durchsatz aus. Ein serverloses Konto verträgt die Durchsatzangabe nicht (Learn: Fehler beim Anlegen und beim Lesen des Durchsatzes); lassen Sie sie dort weg und schreiben Sie nur die Kosten eines Schreibvorgangs auf. Aufräumen: await database.DeleteAsync() oder die Ressourcengruppe des Testkontos löschen.

So prüfen Sie es: Teil A endet mit Exit-Code 0 und den Zahlen der Lösung.

Lösung 1

Rules.MinManual(20, 50_000) ist MAX(400, 20, 500) = 500; bei 2.000 GB ist es 2.000 (der Lauf oben zeigt es; bei Autoscale 5.000 und 20.000).
2.000 × 30 = 60.000 RU, geteilt durch 2.000 RU/s ergibt 30 Sekunden, wenn nichts anderes läuft. Die Stunde wird mit 2.000 RU/s abgerechnet (BilledAutoscale(2000, 2000)), zehnmal so viel wie eine ruhige Stunde mit 200. Wer das vermeiden will, verteilt die Aufnahme; 429 wiederholt das SDK von selbst (Lektion 1.2).
20 × 6 = 120 RU/s, mal 3 sind 360, mindestens aber 1.000: also 1.000, gleich der Untergrenze eines leeren Containers (sie steigt mit 10 RU/s je GB).

Teil B bleibt hier ungeprüft. Die gemessene Zahl ersetzt Ihre Annahme von 6 RU in der Tabelle.

Was Sie jetzt können

Sie wählen zwischen bereitgestelltem Durchsatz, Autoscale und serverlos und begründen es mit Last, Regionen und der Regel von etwa 66 %.
Sie messen den Verbrauch mit RequestCharge und rechnen den Höchstwert je Container aus einer festgehaltenen Annahme.
Sie legen Datenbank und Container im SDK und in Bicep an und schalten die Schlüssel am Konto ab.
Sie wissen, dass der Client die Konsistenzstufe nur abschwächen darf.

Weiterlesen

Create containers and databases with autoscale: Tmax, Abrechnung je Stunde.
Azure Cosmos DB serverless account type: Anwendungsfälle und Grenzen.
Request Units in Azure Cosmos DB und Find the request unit charge: was den Verbrauch bestimmt, Messen im Portal und im SDK.
Service quotas and default limits: Untergrenzen, Verwaltungsgrenzen.
How to choose between manual and autoscale: die Rechnung hinter der 66-%-Regel.

Das lernen Sie in dieser Lektion