Erstellen skalierbarer und leistungsfähiger Tabellen
Tipp
Der Inhalt in diesem Artikel gilt für den ursprünglichen Azure-Tabellenspeicher. Die gleichen Konzepte gelten jedoch für das neuere Azure Cosmos DB for Table, das höhere Leistung und Verfügbarkeit, globale Verteilung und automatische sekundäre Indizes bietet. Sie kann auch im nutzungsbasierten serverlosen Modus verwendet werden. Es gibt einige Featureunterschiede zwischen der Tabellen-API in Azure Cosmos DB und Azure Table Storage. Weitere Informationen finden Sie unter Azure Cosmos DB for Table. Zur einfacheren Entwicklung stellen wir jetzt ein einheitliches Azure Tables-SDK bereit, das sowohl für Azure Table Storage als auch für Azure Cosmos DB for Table verwendet werden kann.
Beim Entwerfen von skalierbaren und leistungsfähigen Tabellen müssen Sie Faktoren wie Leistung, Skalierbarkeit und Kosten beachten. Wenn Sie früher schon Schemas für relationale Datenbanken entworfen haben, werden Sie mit diesen Überlegungen vertraut sein. Aber trotz einigen Ähnlichkeiten zwischen dem Modell des Azure-Tabellenspeicherdienstes und relationalen Modellen gibt es auch wichtige Unterschiede. Diese Unterschiede führen in der Regel zu unterschiedlichen Entwürfen, die einer mit relationalen Datenbanken vertrauten Person kontraproduktiv oder falsch erscheinen mögen, aber sinnvoll sind, wenn Sie einen Entwurf für einen NoSQL-Schlüssel-Wert-Speicher wie z. B. den Azure-Tabellenspeicherdienst durchführen. Viele der Unterschiede im Entwurf spiegeln die Tatsache wider, dass der Tabellenspeicherdienst zur Unterstützung von Cloudanwendungen konzipiert ist, die Milliarden von Entitäten (Zeilen in der Terminologie für relationale Datenbanken) aus Daten oder Datensätzen beinhalten und sehr hohe Transaktionsvolumen unterstützen müssen. Aus diesem Grund müssen Sie andere Überlegungen anstellen, wie Sie Ihre Daten speichern, und verstehen, wie der Tabellenspeicherdienst funktioniert. Ein gut konzipierter NoSQL-Datenspeicher kann bei Ihrer Lösung eine viel tiefere Skalierung ermöglichen (und zu geringeren Kosten), als dies bei einer Lösung möglich ist, die eine relationale Datenbank verwendet. Dieses Handbuch unterstützt Sie bei folgenden Themen.
Informationen zum Azure-Tabellenspeicherdienst
In diesem Abschnitt werden einige der wichtigsten Funktionen des Tabellenspeicherdienstes beleuchtet, die für den Entwurf mit Leistung und Skalierbarkeit besonders relevant sind. Wenn Sie noch nicht mit Azure Storage und dem Tabellenspeicherdienst vertraut sind, lesen Sie zuerst Erste Schritte mit Azure Table Storage mit .NET, bevor Sie den restlichen Teil dieses Artikels lesen. Obwohl der Schwerpunkt dieses Handbuchs auf dem Tabellenspeicherdienst liegt, werden auch Azure-Warteschlange und Blob-Dienste und deren Verwendung mit dem Tabellenspeicherdienst in einer Lösung erörtert.
Was ist der Tabellenspeicherdienst? Wie aus dem Namen zu ersehen ist, verwendet der Tabellenspeicherdienst ein tabellarisches Format zum Speichern von Daten. In der Standard-Terminologie stellt jede Zeile der Tabelle eine Entität dar und die Spalten speichern die verschiedenen Eigenschaften dieser Entität. Jede Entität besitzt zur eindeutigen Identifizierung ein Schlüsselpaar und eine Zeitstempelspalte, anhand welcher der Tabellenspeicherdienst nachverfolgt, wann die Entität zuletzt aktualisiert wurde. Der Zeitstempel wird automatisch angewendet; Sie können den Zeitstempel nicht manuell mit einem beliebigen Wert überschreiben. Der Tabellenspeicherdienst verwendet diesen Zeitstempel der letzten Änderung (Last-Modified Timestamp, LMT) zum Verwalten der optimistischen Nebenläufigkeit.
Hinweis
Die REST-API-Vorgänge des Tabellenspeicherdiensts geben auch einen ETag-Wert zurück, den sie aus dem LMT abgeleitet haben. In diesem Dokument werden die Begriffe ETag und LMT austauschbar verwendet, da sie auf dieselben zugrundeliegenden Daten verweisen.
Das folgende Beispiel zeigt einen einfachen Tabellenentwurf zum Speichern von Mitarbeiter- und Abteilungsentitäten. Viele der in diesem Handbuch weiter unten gezeigten Beispiele basieren auf diesem einfachen Entwurf.
| PartitionKey | RowKey | Timestamp | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | Department | 2014-08-22T00:50:30Z |
|
||||||||
| Sales | 00010 | 2014-08-22T00:50:44Z |
|
Bisher gleichen diese Daten einer Tabelle in einer relationalen Datenbank, wobei die wesentlichen Unterschiede in den Pflichtspalten und in der Fähigkeit liegen, mehrere Entitätstypen in derselben Tabelle zu speichern. Darüber hinaus verfügen alle benutzerdefinierten Eigenschaften wie Vorname oder Alter über einen Datentyp wie „ganze Zahl“ oder „Zeichenfolge“ – genau wie bei einer Spalte in einer relationalen Datenbank. Obwohl dies bei einer relationalen Datenbank unwahrscheinlich ist, bedeutet die Art der Tabelle ohne Schema, dass eine Eigenschaft nicht denselben Datentyp bei jeder Entität haben muss. Um komplexe Datentypen in einer einzelnen Eigenschaft zu speichern, müssen Sie ein serialisiertes Format wie z. B. JSON oder XML verwenden. Weitere Informationen zum Tabellenspeicherdienst (beispielsweise unterstützte Datentypen, unterstützte Datumsbereiche, Namensregeln und Größenbeschränkungen) finden Sie unter Grundlegendes zum Tabellendienst-Datenmodell.
Ihre Auswahl für PartitionKey und RowKey bildet die Grundlage für einen guten Tabellenentwurf. Jede in einer Tabelle gespeicherte Entität muss eine eindeutige Kombination aus PartitionKey und RowKey besitzen. Wie Schlüssel in einer relationalen Datenbanktabelle sind die Werte PartitionKey und RowKey indiziert, um einen gruppierten Index für schnelle Suchen zu erstellen. Allerdings erstellt der Tabellenspeicherdienst keine sekundären Indizes. Daher sind PartitionKey und RowKey die einzigen indizierten Eigenschaften. Einige der in Entwurfsmuster für die Tabelle beschriebenen Muster veranschaulichen, wie Sie diese offensichtliche Einschränkung umgehen können.
Eine Tabelle besteht aus mindestens einer Partition. Viele der von Ihnen zu treffenden Entwurfsentscheidungen zur Optimierung der Lösung hängen mit der Auswahl eines geeigneten Werts für PartitionKey und RowKey zusammen. Eine Lösung könnte aus einer einzelnen Tabelle bestehen, die alle Entitäten, in Partitionen unterteilt, enthält. In der Regel besteht eine Lösung aber aus mehreren Tabellen. Tabellen helfen Ihnen bei der logischen Organisation Ihrer Entitäten, bei der Verwaltung des Zugriffs auf die Daten mithilfe von Zugriffssteuerungslisten und Sie können eine komplette Tabelle mit einem einzelnen Speichervorgang ablegen.
Tabellenpartitionen
Kontoname, Tabellenname und PartitionKey bestimmen zusammen die Partition innerhalb des Tabellenspeicherdiensts, in der der Tabellenspeicherdienst die Entität speichert. Partitionen sind Teil des Adressierungsschemas für Entitäten und legen zusätzlich einen Bereich für Transaktionen fest (siehe Entitätsgruppentransaktionen weiter unten). Außerdem bilden sie die Grundlage für die Skalierung des Tabellenspeicherdiensts. Weitere Informationen zu Partitionen finden Sie unter Checkliste zu Leistung und Skalierbarkeit für Table Storage.
Im Tabellenspeicherdienst bedient ein einzelner Knoten eine oder mehrere komplette Partitionen und skaliert durch dynamischen Lastenausgleich Partitionen über Knoten hinweg. Wenn ein Knoten ausgelastet ist, kann der Tabellenspeicherdienst den Partitionsbereich teilen, der von diesem Knoten aus andere Knoten bedient. Wenn der Datenverkehr abnimmt, kann der Dienst die Partitionsbereiche von nicht ausgelasteten Knoten wieder auf einem einzelnen Knoten zusammenführen.
Weitere Informationen über die internen Details des Tabellenspeicherdiensts und insbesondere zur Verwaltung der Partitionen durch den Dienst finden Sie im Dokument Microsoft Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency(in englischer Sprache).
Entitätsgruppentransaktionen
Im Tabellenspeicherdienst sind Entitätsgruppentransaktionen (EGTs) der einzige integrierte Mechanismus, mit dem atomische Aktualisierungen für mehrere Entitäten durchgeführt werden können. EGTs werden manchmal auch als Batchtransaktionen bezeichnet. EGTs können nur für Entitäten ausgeführt werden, die in derselben Partition gespeichert sind (d. h., sie teilen sich den gleichen Partitionsschlüssel in einer bestimmten Tabelle). Jedes Mal, wenn Sie ein atomisches Transaktionsverhalten über mehrere Entitäten hinweg benötigen, müssen Sie daher sicherstellen, dass sich diese Entitäten in derselben Partition befinden. Dies ist häufig der Grund, dass mehrere Entitätstypen in derselben Tabelle (und Partition) gehalten werden und nicht mehrere Tabellen für verschiedene Entitätstypen verwendet werden. Eine einzelne EGT kann mit höchstens 100 Entitäten verwendet werden. Wenn Sie gleichzeitig mehrere EGTs zur Verarbeitung übermitteln, müssen Sie sicherstellen, dass diese EGTs nicht für EGT-übergreifende Entitäten verwendet werden, da andernfalls die Verarbeitung verzögert werden kann.
EGTs führen möglicherweise auch zu einem Kompromiss, den Sie in Ihrem Entwurf berücksichtigen müssen. Das heißt, wenn Sie mehr Partitionen verwenden, erhöht sich die Skalierbarkeit der Anwendung, da Azure mehr Möglichkeiten für den Lastenausgleich von Anforderungen zwischen verschiedenen Knoten hat. Der Einsatz von mehr Partitionen kann aber auch die Fähigkeit Ihrer Anwendung einschränken, atomische Transaktionen auszuführen und eine hohe Konsistenz Ihrer Daten aufrechtzuerhalten. Darüber hinaus gibt es auf Partitionsebene bestimmte Skalierbarkeitsziele, die möglicherweise den Transaktionsdurchsatz einschränken, den Sie für einen Einzelknoten erwarten können. Weitere Informationen zu Skalierbarkeitszielen für Azure-Standardspeicherkonten finden Sie unter Skalierbarkeitsziele für Standardspeicherkonten. Weitere Informationen zu den Skalierbarkeitszielen für den Tabellenspeicherdienst finden Sie unter Skalierbarkeits- und Leistungsziele für Table Storage.
Überlegungen zur Kapazität
In der folgenden Tabelle sind die Kapazitäts-, Skalierbarkeits- und Leistungsziele für den Tabellenspeicher beschrieben.
| Resource | Ziel |
|---|---|
| Anzahl von Tabellen in einem Azure Storage-Konto | Begrenzung nur durch die Kapazität des Speicherkontos |
| Anzahl von Partitionen in einer Tabelle | Begrenzung nur durch die Kapazität des Speicherkontos |
| Anzahl von Entitäten in einer Partition | Begrenzung nur durch die Kapazität des Speicherkontos |
| Maximale Größe einer einzelnen Tabelle | 500 TiB |
| Maximale Größe einer einzelnen Entität, einschließlich aller Eigenschaftswerte | 1 MiB |
| Maximale Anzahl von Eigenschaften in einer Tabellenentität | 255 (einschließlich der drei Systemeigenschaften PartitionKey, RowKey und Timestamp) |
| Maximale Gesamtgröße einer individuellen Eigenschaft in einer Entität | Variiert je nach Eigenschaftstyp. Weitere Informationen finden Sie unter Eigenschaftstypen in Grundlegendes zum Tabellendienst-Datenmodell. |
| Größe von PartitionKey | Eine Zeichenfolge mit maximal 1.024 Zeichen |
| Größe von RowKey | Eine Zeichenfolge mit maximal 1.024 Zeichen |
| Größe einer Entitätsgruppentransaktion | Eine Transaktion kann höchstens 100 Entitäten umfassen, und die Nutzlast muss weniger als 4 MiB groß sein. Eine Entitätsgruppentransaktion kann ein Update für eine Entität nur einmal einschließen. |
| Maximale Anzahl gespeicherter Zugriffsrichtlinien pro Tabelle | 5 |
| Maximale Anforderungsrate pro Speicherkonto | 20.000 Transaktionen pro Sekunde, ausgehend von einer Entitätsgröße von 1KiB |
| Zieldurchsatz für eine einzelne Tabellenpartition (Entitäten von 1KiB) | Bis zu 2.000 Entitäten pro Sekunde |
Überlegungen zu Kosten
Tabellenspeicher ist relativ günstig, aber Sie sollten die Kostenschätzungen für Kapazitätsauslastung und Transaktionsmenge als Bestandteil Ihrer Auswertung bei allen Tabellenspeicherdienstlösungen aufnehmen. In vielen Szenarien ist jedoch die Speicherung denormalisierter oder doppelter Daten zur Verbesserung der Leistung oder der Skalierbarkeit für Ihre Lösung ein zulässiger Ansatz. Weitere Informationen zu den Preisen finden Sie unter Preise für Azure Storage.