Häufig gestellte Fragen zu Azure Cosmos DB for Table

  • Häufig gestellte Fragen

GILT FÜR: Tabelle

Vergleich von Azure Cosmos DB for Table und Azure Table Storage

Inwiefern unterscheidet sich das Verhalten der API für Table von Azure Table Storage?

Benutzer, die mit Azure Table Storage vertraut sind und Tabellen mit Azure Cosmos DB for Table erstellen möchten, müssen sich auf einige Unterschiede hinsichtlich des Verhaltens einstellen:

  • Azure Cosmos DB for Table verwendet zur Gewährleistung der garantierten Leistung ein Modell mit reservierter Kapazität. Das bedeutet allerdings, dass für die Kapazität Kosten anfallen, sobald die Tabelle erstellt wird – auch wenn die Kapazität gar nicht genutzt wird. Bei Azure Table Storage wird dagegen nur die genutzte Kapazität in Rechnung gestellt. Dies erklärt, warum bei der API für Table eine SLA mit einer Lesegeschwindigkeit von 10 ms und einer Schreibgeschwindigkeit von 15 ms im 99. Perzentil möglich ist, während Azure Table Storage nur eine SLA mit 10 Sekunden bietet. Bei API für Table-Tabellen fallen dafür jedoch auch Kosten für leere Tabellen ohne jegliche Anforderungen an, um sicherzustellen, dass gemäß der SLA von Azure Cosmos DB die erforderliche Kapazität für mögliche Tabellenanforderungen zur Verfügung steht.

  • Von der API für Table zurückgegebene Abfrageergebnisse werden nicht wie bei Azure Table Storage nach Partitionsschlüssel/Zeilenschlüssel sortiert.

  • Die Größe von Zeilenschlüsseln ist auf 255 Bytes begrenzt.

  • Batches können nur bis zu 2 MB enthalten.

  • CORS wird derzeit nicht unterstützt.

  • Bei Tabellennamen in Azure Table Storage wird die Groß- und Kleinschreibung nicht berücksichtigt, bei Azure Cosmos DB for Table dagegen schon.

  • Einige der internen Azure Cosmos DB-Formate für Codierungsinformationen (etwa binäre Felder) sind derzeit nicht so wie effizient wie möglicherweise gewünscht. Daher können unerwartete Einschränkungen in Bezug auf die Datengröße auftreten. Beispiel: Derzeit kann zum Speichern der Binärdaten die Kapazität einer Tabellenentität von 1 MB nicht vollständig genutzt werden, da die Codierung den Datenumfang vergrößert.

  • Die Entitätseigenschaftsnamen ID, rid, etag und ResourceId sind für die Verwendung durch Cosmos DB reserviert und werden derzeit nicht unterstützt.

  • „TakeCount“ von „TableQuery“ ist nicht auf 1.000 beschränkt.

  • In Bezug auf die REST-API werden die folgenden Endpunkte/Abfrageoptionen von Azure Table Storage unterstützt ( aber nicht von Azure Cosmos DB for Table):

    Rest-Methoden REST-Endpunkt/-Abfrageoption Dokumentations-URLs Erklärung In Table Storage unterstützt Unterstützt in der API für Table
    GET, PUT /?Restype=service@comp=properties Set Table Service Properties (Festlegen von Tabellendiensteigenschaften) und Get Table Service Properties (Abrufen von Tabellendiensteigenschaften) Dieser Endpunkt dient zum Festlegen von CORS-Regeln, Storage Analytics-Konfiguration und Protokollierungseinstellungen. CORS wird derzeit nicht unterstützt. Analyse und Protokollierung werden in Azure Cosmos DB anders behandelt als in Azure Storage-Tabellen. Ja Nein
    OPTIONS /<table-resource-name> Pre-flight CORS table request (Preflight-CORS-Tabellenanforderung) Dies ist Teil von CORS und wird daher derzeit von Azure Cosmos DB nicht unterstützt. Ja Nein
    GET /?Restype=service@comp=stats Get Table Service Stats (Abrufen der Tabellendienststatistik) Gibt Aufschluss über die Replikationsgeschwindigkeit von Daten zwischen primärer Datenbank und sekundären Datenbanken. Wird in Azure Cosmos DB nicht benötigt, da hier die Replikation Teil der Schreibvorgänge ist. Ja Nein
    GET, PUT /mytable?comp=acl Get Table ACL (Tabellen-ACL abrufen) und Set Table ACL (Tabellen-ACL festlegen) Dient zum Abrufen und Festlegen der gespeicherten Zugriffsrichtlinien, die für die Verwaltung von Shared Access Signatures (SAS) verwendet werden. Ja Nein

  • Azure Cosmos DB for Table unterstützt nur das JSON-Format und nicht das ATOM-Format.

  • Beim .NET SDK werden einige Klassen und Methoden derzeit nicht von Azure Cosmos DB unterstützt.

    • CloudTableClient-Klasse
      • \ServiceProperties
      • \ServiceStats
    • CloudTable-Klasse
      • SetPermissions
      • GetPermissions

Weitere häufig gestellte Fragen

Benötige ich für die Verwendung der API für Table ein neues SDK?

Nein. Vorhandene Storage SDKs sollten auch weiterhin funktionieren. Es empfiehlt sich allerdings immer, die neuesten SDKs zu verwenden, um eine optimale Unterstützung zu gewährleisten und in vielen Fällen eine bessere Leistung zu erzielen. Eine Liste mit den verfügbaren Sprachen finden Sie in der Einführung in Azure Cosmos DB for Table.

Welche Verbindungszeichenfolge muss ich zum Herstellen einer Verbindung mit der API für Table verwenden?

Die Verbindungszeichenfolge lautet:

DefaultEndpointsProtocol=https;AccountName=<AccountNamefromCosmosDB;AccountKey=<FromKeysPaneofCosmosDB>;TableEndpoint=https://<AccountName>.table.cosmosdb.azure.com

Die Verbindungszeichenfolge können Sie im Azure-Portal auf der Seite „Verbindungszeichenfolge“ ermitteln.

Wie setze ich die Konfigurationseinstellungen für die Anforderungsoptionen im .NET SDK für die API für Table außer Kraft?

Einige Einstellungen werden über die CreateCloudTableClient-Methode behandelt, andere über „app.config“ im appSettings-Abschnitt der Clientanwendung. Informationen zu Konfigurationseinstellungen finden Sie unter Azure Cosmos DB-Funktionen.

Müssen Kunden, die die vorhandenen Azure Table Storage SDKs verwenden, Änderungen vornehmen?

Keine. Für Bestands- oder Neukunden, die die vorhandenen Azure Table Storage-SDKs verwenden, ergeben sich keine Änderungen.

Wie zeige ich in Azure Cosmos DB gespeicherte Tabellendaten für die Verwendung mit der API für Table an?

Sie können das Azure-Portal verwenden, um die Daten zu durchsuchen. Außerdem können Sie den Code der API für Table oder die in der nächsten Antwort erwähnten Tools verwenden.

Welche Tools kann ich mit der API für Table verwenden?

Sie können den Azure Storage-Explorer verwenden.

Tools, die eine Verbindungszeichenfolge im weiter oben angegebenen Format akzeptieren, können die neue API für Table unterstützen. Eine Liste mit Tabellentools steht auf der Seite Azure Storage-Clienttools zur Verfügung.

Ist die Parallelität im Betrieb gesteuert?

Ja. Die optimistische Nebenläufigkeit wird über den Einsatz des ETag-Mechanismus bereitgestellt.

Wird das OData-Abfragemodell für Entitäten unterstützt?

Ja. Die API für Table unterstützt OData-Abfragen und LINQ-Abfragen.

Kann in einer Anwendung gleichzeitig eine Verbindung mit Azure Table Storage und Azure Cosmos DB for Table hergestellt werden?

Ja. Sie können Verbindungen herstellen, indem Sie zwei separate CloudTableClient-Instanzen erstellen, die über die Verbindungszeichenfolge jeweils auf ihren eigenen URI verweisen.

Wie migriere ich eine bereits vorhandene Azure Table Storage-Anwendung zu diesem Angebot?

AzCopy wird unterstützt.

Wie erfolgt die Erweiterung der Speichergröße für diesen Dienst, wenn ich beispielsweise mit „n“ GB Daten beginne und meine Daten im Laufe der Zeit auf 1 TB anwachsen?

Azure Cosmos DB wurde dafür ausgelegt, mithilfe von horizontaler Skalierung unbeschränkten Speicherplatz zu bieten. Der Dienst kann Ihren Speicher überwachen und effektiv vergrößern.

Wie kann ich das API für Table-Angebot überwachen?

Anforderungen und Speicherverwendung können im Bereich Metriken der API für Table überwacht werden.

Wie kann ich den erforderlichen Durchsatz berechnen?

Sie können den Kapazitätskalkulator verwenden, um den für die Vorgänge erforderlichen TableThroughput zu berechnen. Weitere Informationen finden Sie unter Estimate Request Units and Data Storage (Schätzen von Anforderungseinheiten und Datenspeicher). Im Allgemeinen können Sie Ihre Entität als JSON-Code darstellen und die Zahlen für Ihre Vorgänge eingeben.

Kann ich das SDK der API für Table lokal mit dem Emulator verwenden?

Derzeit leider nicht.

Kann ich meine bereits vorhandene Anwendung mit API für Table verwenden?

Ja. Die gleiche API wird unterstützt.

Muss ich meine vorhandenen Azure Table Storage-Anwendungen zum SDK migrieren, wenn ich die Funktionen der API für Table nicht nutzen möchte?

Nein. Sie können den vorhandenen Azure Table Storage-Bestand ohne irgendwelche Unterbrechungen erstellen und verwenden. Wenn Sie die API for Table nicht nutzen, können Sie allerdings nicht von der automatischen Indizierung, der zusätzlichen Konsistenzoption oder der globalen Verteilung profitieren.

Wie füge ich in der API für Table eine Datenreplikation in mehr als einer Azure-Region hinzu?

Sie können die globalen Replikationseinstellungen im Azure Cosmos DB-Portal verwenden, um Regionen hinzuzufügen, die sich für Ihre Anwendung eignen. Beim Entwickeln einer global verteilten Anwendung sollten Sie Ihre Anwendung darüber hinaus mit einem auf die lokale Region festgelegten Wert von PreferredLocation hinzufügen, um für eine niedrige Leselatenz zu sorgen.

Wie ändere ich die primäre Schreibregion für das Konto in der API für Table?

Sie können den Portalbereich für globale Azure Cosmos DB-Replikation verwenden, um eine Region hinzuzufügen, und dann ein Failover in die benötigte Region durchführen. Anweisungen finden Sie unter Entwickeln für Azure Cosmos DB-Konten für mehrere Regionen.

Wie lassen sich beim Verteilen meiner Daten meine bevorzugten Leseregionen konfigurieren, um niedrige Latenz zu erreichen?

Verwenden Sie den Schlüssel PreferredLocation in der Datei „app.config“, um das Lesen vom lokalen Standort zu unterstützen. Bei bereits vorhandenen Anwendungen gibt die API für Table einen Fehler aus, wenn „LocationMode“ festgelegt ist. Entfernen Sie diesen Code, da die API für Table diese Information aus der Datei „app.config“ abruft.

Wie kann ich mir die Konsistenzebenen in der API für Table vorstellen?

Azure Cosmos DB bietet einen wohlüberlegten Kompromiss zwischen Konsistenz, Verfügbarkeit und Wartezeit. Azure Cosmos DB bietet fünf Konsistenzebenen für Entwickler, die die API für Table nutzen. Sie können also auf Tabellenebene das passende Konsistenzmodell auswählen und beim Abfragen der Daten individuelle Anforderungen verwenden. Wenn ein Client eine Verbindung herstellt, kann er eine Konsistenzebene angeben. Die Ebene kann über das consistencyLevel-Argument von „CreateCloudTableClient“ geändert werden.

Die API für Table bietet Lesevorgänge mit geringer Wartezeit und die Garantie „Eigene Schreibvorgänge lesen“ mit begrenzter Veraltung als Standardeinstellung. Weitere Informationen finden Sie unter Konsistenzebenen.

Standardmäßig wird für Azure-Tabellenspeicher „Starke Konsistenz“ innerhalb einer Region und „Letztliche Konsistenz“ an den sekundären Standorten verwendet.

Bietet Azure Cosmos DB for Table mehr Konsistenzebenen als Azure Table Storage?

Ja. Informationen dazu, wie Sie von der weiten Verteilung von Azure Cosmos DB profitieren können, finden Sie unter Einstellbare Datenkonsistenzebenen in Azure Cosmos DB. Da für die Konsistenzebenen Garantien gegeben werden, können Sie sie vertrauensvoll nutzen.

Wie viel Zeit wird für die Replikation der Daten benötigt, wenn die globale Verteilung aktiviert ist?

Azure Cosmos DB führt für die Daten dauerhaft einen Commit in der lokalen Region durch und überträgt die Daten innerhalb von Millisekunden sofort in andere Regionen. Diese Replikation ist nur von der Roundtripzeit (Round-Trip Time, RTT) des Datencenters abhängig. Weitere Informationen zur Funktion für die globale Verteilung von Azure Cosmos DB finden Sie unter Globale Datenverteilung mit Azure Cosmos DB.

Kann die Konsistenzebene für Leseanforderungen geändert werden?

Mit Azure Cosmos DB können Sie die Konsistenzebene auf Containerebene (in der Tabelle) festlegen. Mit dem .NET SDK können Sie die Ebene ändern, indem Sie den Wert für den TableConsistencyLevel-Schlüssel in der Datei „app.config“ angeben. Mögliche Werte: „Stark“, „Begrenzte Veraltung“, „Sitzung“, „Präfixkonsistenz“ und „Letztlich“ Weitere Informationen finden Sie unter Einstellbare Datenkonsistenzebenen in Azure Cosmos DB. Der Hauptaspekt hierbei ist, dass Sie die Konsistenzebene für Anforderungen nicht auf einen höheren Wert als für die Einstellung für die Tabelle festlegen können. Beispielsweise ist es nicht möglich, die Konsistenzebene für die Tabelle auf „Letztlich“ und die Konsistenzebene für die Anforderung auf „Sicher“ festzulegen.

Wie läuft mit der API für Table das Failover beim Ausfall einer Region ab?

Die API for Table nutzt die global verteilte Plattform von Azure Cosmos DB. Um sicherzustellen, dass Ihre Anwendung Ausfallzeiten des Datencenters tolerieren kann, sollten Sie für das Konto mindestens eine weitere Region im Azure Cosmos DB-Portal aktivieren: Entwickeln für Azure Cosmos DB-Konten für mehrere Regionen. Sie können die Priorität der Region mithilfe des Portals festlegen: Entwickeln für Azure Cosmos DB-Konten für mehrere Regionen.

Sie können für das Konto beliebig viele Regionen hinzufügen und steuern, wohin das Failover erfolgen kann, indem Sie eine Failoverpriorität festlegen. Für die Verwendung der Datenbank müssen Sie dafür eine Anwendung bereitstellen. Wenn Sie so vorgehen, treten für Ihre Kunden keine Ausfallzeiten auf. Das neueste .NET-Client-SDK verfügt über Auto-Homing, die anderen SDKs dagegen nicht. Es kann also die ausgefallene Region erkennen und automatisch das Failover in die neue Region durchführen.

Können mit der API für Table Sicherungen erstellt werden?

Ja. Die API for Table nutzt für Sicherungen die Plattform von Azure Cosmos DB. Sicherungen werden automatisch erstellt. Weitere Informationen finden Sie unter Automatische Onlinesicherung und -wiederherstellung mit Azure Cosmos DB.

Indiziert die API für Table standardmäßig alle Attribute einer Entität?

Ja, alle Attribute einer Entität werden standardmäßig indiziert. Weitere Informationen finden Sie unter Azure Cosmos DB: Indizierungsrichtlinien.

Bedeutet dies, dass ich nicht mehrere Indizes erstellen muss, um Abfragen zu bedienen?

Ja. Azure Cosmos DB for Table ermöglicht die automatische Indizierung aller Attribute ganz ohne Schemadefinition. Dank dieser Automatisierung können sich Entwickler auf die Anwendung konzentrieren und verlieren keine Zeit mehr mit der Indexerstellung und -verwaltung. Weitere Informationen finden Sie unter Azure Cosmos DB: Indizierungsrichtlinien.

Kann ich die Indizierungsrichtlinie ändern?

Ja. Sie können die Indizierungsrichtlinie ändern, indem Sie die Indexdefinition bereitstellen. Sie müssen die Einstellungen richtig codieren und mit Escapezeichen versehen.

Die Indizierungsrichtlinie kann nur im Portal über den Data Explorer festgelegt werden: Navigieren Sie zu der spezifischen Tabelle, die Sie ändern möchten. Navigieren Sie dann zu Skalierung und Einstellungen > „Indizierungsrichtlinie“, nehmen Sie die gewünschte Änderung vor und klicken Sie anschließend auf Speichern.

Azure Cosmos DB als Plattform verfügt scheinbar über viele Funktionen, z.B. Sortierung, Aggregate, Hierarchie und andere. Werden diese Funktionen der API für Table hinzugefügt?

Die API für Table bietet die gleichen Abfragefunktionen wie Azure Table Storage. Azure Cosmos DB unterstützt auch Sortieren, Aggregieren, räumliche Abfrage, Hierarchie und eine Vielzahl von integrierten Funktionen. Weitere Informationen finden Sie unter SQL-Abfragen.

Wann sollte ich „TableThroughput“ für die API für Table ändern?

Sie sollten TableThroughput ändern, wenn eine der folgenden Bedingungen gilt:

  • Sie führen das Extrahieren, Transformieren und Laden (ETL) für die Daten durch, oder Sie möchten innerhalb eines kurzen Zeitraums zahlreiche Daten hochladen.
  • Sie benötigen für den Container oder mehrere Container auf dem Back-End mehr Durchsatz. Beispielsweise erkennen Sie, dass der genutzte Durchsatz den bereitgestellten Durchsatz übersteigt, und es kommt zu einer Drosselung. Weitere Informationen finden Sie unter Festlegen von Durchsatz für Azure Cosmos DB-Container.

Kann ich den Durchsatz meiner API für Table-Tabelle hoch- oder herunterskalieren?

Ja. Sie können den Skalierungsbereich des Azure Cosmos DB-Portals verwenden, um den Durchsatz zu skalieren. Weitere Informationen finden Sie unter Festlegen von Durchsatz für Azure Cosmos DB-Container.

Wird für neu bereitgestellte Tabellen ein TableThroughput-Standardwert festgelegt?

Ja. Wenn Sie TableThroughput nicht mithilfe von „app.config“ außer Kraft setzen und keinen vorkonfigurierten Container in Azure Cosmos DB verwenden, erstellt der Dienst eine Tabelle mit einem Durchsatz von 400.

Müssen Bestandskunden des Azure Table Storage-Diensts mit Preisänderungen rechnen?

Keine. Es gibt keine Preisänderungen für Bestandskunden von Azure Table Storage.

Wie errechnet sich der Preis für die API für Table?

Der Preis hängt vom zugewiesenen TableThroughput-Wert ab.

Wie kann ich beim API für Table-Angebot eine ggf. auftretende Ratenbegrenzung behandeln?

Wenn die Anforderungsrate die Kapazität des bereitgestellten Durchsatzes für die zugrunde liegenden Container übersteigt, erhalten Sie einen Fehler, und das SDK wiederholt den Aufruf, indem die Wiederholungsrichtlinie angewendet wird.

Warum muss ich zusätzlich zu „PartitionKey“ und „RowKey“ einen Durchsatz festlegen, um das API für Table-Angebot von Azure Cosmos DB nutzen zu können?

Azure Cosmos DB legt einen Standarddurchsatz für Ihren Container fest, wenn Sie in der Datei „app.config“ oder über das Portal keinen Durchsatz angeben.

Azure Cosmos DB bietet Garantien für Leistung und Latenz mit Obergrenzen im Betrieb. Diese Garantie ist möglich, wenn die Engine die Kontrolle für die Vorgänge des Mandanten erzwingen kann. Durch das Festlegen von TableThroughput wird sichergestellt, dass Sie den garantierten Durchsatz und die Wartezeit auch erhalten, da diese Kapazität von der Plattform reserviert wird und somit der Erfolg des Vorgangs sichergestellt ist.

Mithilfe der Durchsatzspezifikation können Sie dies flexibel ändern, um von der Saisonalität Ihrer Anwendung zu profitieren, die Durchsatzanforderungen zu erfüllen und Kosten zu sparen.

Azure Table Storage war für mich kostengünstig, da ich nur für die Speicherung der Daten zahle und nur selten Abfragen durchführe. Beim Azure Cosmos DB for Table-Angebot fallen für mich aber offenbar auch Kosten an, wenn ich keine einzige Transaktion durchgeführt und nichts gespeichert habe. Gibt es dafür eine Erklärung?

Azure Cosmos DB wurde als global verteiltes, SLA-basiertes System mit Garantien für Verfügbarkeit, Wartezeit und Durchsatz entwickelt. Wenn Sie den Durchsatz in Azure Cosmos DB reservieren, ist er – im Gegensatz zum Durchsatz anderer Systeme – garantiert. Mit Azure Cosmos DB werden weitere Funktionen bereitgestellt, die von Kunden gefordert wurden, z. B. sekundäre Indizes und globale Verteilung.

Ich habe die Benachrichtigung „Kontingent erschöpft“ (als Information, dass eine Partition voll ist) beim Erfassen von Daten in Azure Table Storage nie erhalten. Bei der API für Table wird diese Meldung aber angezeigt. Schränkt mich dieses Angebot ein, und zwingt es mich zum Ändern meiner vorhandenen Anwendung?

Azure Cosmos DB ist ein SLA-basiertes System, das unbeschränkte Skalierung mit Garantien für Wartezeit, Durchsatz, Verfügbarkeit und Konsistenz bietet. Achten Sie darauf, dass Ihre Datengröße und der Index verwaltbar und skalierbar sind, um sicherzustellen, dass Sie die garantierte Premium-Leistung erhalten. Mit dem 20 GB-Grenzwert für die Anzahl von Entitäten bzw. Elementen pro Partitionsschlüssel wird dafür gesorgt, dass wir eine hervorragende Such- und Abfrageleistung bieten können. Um sicherzustellen, dass Ihre Anwendung gut skaliert werden kann, raten wir Ihnen auch bei Azure Storage, keine Hot Partition zu erstellen, indem Sie alle Informationen in einer Partition speichern und abfragen.

Also benötige ich „PartitionKey“ und „RowKey“ auch bei der API für Table?

Ja. Da die Oberfläche der API für Table der des Azure Table Storage SDK ähnelt, ermöglicht der Partitionsschlüssel eine effiziente Datenverteilung. Der Zeilenschlüssel ist innerhalb dieser Partition eindeutig. Der Zeilenschlüssel muss vorhanden sein und darf nicht wie beim Standard-SDK NULL sein. Die RowKey-Länge beträgt 255 Bytes. Die PartitionKey-Länge beträgt 1 KB.

Welche Fehlermeldungen gibt es für die API für Table?

Da Azure Table Storage und Azure Cosmos DB for Table die gleichen SDKs verwenden, sind auch die Fehler größtenteils gleich.

Warum kommt es zu einer Drosselung, wenn ich versuche, über die API für Table nacheinander eine große Anzahl von Tabellen zu erstellen?

Azure Cosmos DB ist ein SLA-basiertes System mit Garantien für Wartezeit, Durchsatz, Verfügbarkeit und Konsistenz. Da es sich um ein bereitgestelltes System handelt, werden Ressourcen reserviert, um diese Anforderungen zu garantieren. Eine hohe Erstellungsrate von Tabellen in rascher Folge wird erkannt und gedrosselt. Es wird empfohlen, dass Sie sich die Erstellungsrate der Tabellen ansehen und auf weniger als „5 pro Minute“ reduzieren. Bedenken Sie, dass es sich bei der API für Table um ein bereitgestelltes System handelt. Ab dem Moment, in dem Sie die Lösung bereitstellen, werden Gebühren fällig.

Wie kann ich Feedback zum SDK und zu Bugs geben?

Sie können Ihr Feedback wie folgt mitteilen:

Sicherheit

Was ist die rollenbasierte Zugriffssteuerung (RBAC)?

Rollenbasierte Zugriffssteuerung (RBAC) ist eine Methode zur Regulierung des Zugriffs auf Computer- oder Netzwerkressourcen basierend auf den Rollen einzelner Benutzer innerhalb eines Unternehmens. In Azure Cosmos DB wird RBAC verwendet, um Benutzern und Anwendungen Datenebenenzugriff zu gewähren.

Wie aktiviere ich die rollenbasierte Zugriffssteuerung auf der Datenebene für Azure Cosmos DB for Table?

Verwenden Sie das systemeigene Azure Cosmos DB-Feature für die rollenbasierte Zugriffssteuerung (RBAC), um Benutzern und Anwendungen Datenebenenzugriff zu gewähren.

Zugehöriger Inhalt

Nächster Schritt

Häufig gestellte Fragen zu Azure Cosmos DB