Häufig gestellte Fragen zu Azure Cosmos DB for Table

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

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.

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.

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.

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

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.

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.

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

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

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

AzCopy wird unterstützt.

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.

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

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.

Derzeit leider nicht.

Ja. Die gleiche API wird unterstützt.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

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 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.

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.

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.

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

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.

Sie können Ihr Feedback wie folgt mitteilen:

• Frageseite von Microsoft Q&A (Fragen und Antworten)
• Stack Overflow. Stack Overflow eignet sich am besten für Fragen zur Programmierung. Vergewissern Sie sich, dass Ihre Frage themenbezogen ist und so viele Details wie möglich enthält, damit sie klar und beantwortbar ist.

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.

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

• Erstellen einer API für Table-App mit dem .NET SDK und Azure Cosmos DB
• Erstellen einer Java-App zum Verwalten von Azure Cosmos DB for Table-Daten

Nächster Schritt