Empfehlungen für die Datenpartitionierung

Artikel
11/15/2023

Gilt für diese Empfehlung der Prüfliste für die Zuverlässigkeit von Azure Well-Architected Framework:

RE:06	Implementieren Sie eine zeitnahe und zuverlässige Skalierungsstrategie auf Anwendungs-, Daten- und Infrastrukturebene.

Verwandter Leitfaden:Skalieren

In diesem Leitfaden werden die Empfehlungen für das Entwerfen einer Strategie für die Datenpartitionierung für die von Ihnen bereitgestellte Datenbank- und Datenspeichertechnologie beschrieben. Diese Strategie hilft Ihnen, die Zuverlässigkeit Ihres Datenbestands zu verbessern.

Wichtige Entwurfsstrategien

In vielen umfangreichen Lösungen werden Partitionen verwendet, um Daten aufzuteilen, sodass sie separat verwaltet und darauf zugegriffen werden kann. Die Partitionierung von Daten verbessert die Skalierbarkeit, reduziert Konflikte und optimiert die Leistung. Implementieren Sie die Datenpartitionierung, um Daten nach Verwendungsmuster zu unterteilen. Beispielsweise können Sie ältere Daten in kostengünstigem Datenspeicher archivieren. Wählen Sie Ihre Partitionierungsstrategie sorgfältig aus, um die Vorteile zu maximieren und negative Auswirkungen zu minimieren.

Hinweis

In diesem Artikel steht der Begriff Partitionierung für den Prozess der physischen Unterteilung von Daten in separate Datenspeicher. Sie unterscheidet sich von SQL Server Tabellenpartitionierung.

Gründe für Datenpartitionierung

Verbesserung der Skalierbarkeit. Wenn Sie ein Einzeldatenbanksystem hochskalieren, erreicht die Datenbank schließlich ein physisches Hardwarelimit. Wenn Sie Daten auf mehrere Partitionen aufteilen, wobei jede Partition auf einem separaten Server gehostet wird, können Sie das System nahezu unbegrenzt aufskalieren.
Verbessern der Leistung In jeder Partition werden Datenzugriffsvorgänge über ein kleineres Datenvolumen im Vergleich zu Daten ausgeführt, die nicht partitioniert sind. Partitionieren Sie Daten, um Ihr System effizienter zu machen. Vorgänge, die mehr als eine Partition betreffen, können parallel ausgeführt werden.
Verbesserung der Sicherheit In einigen Fällen können Sie vertrauliche und nicht sensible Daten in verschiedene Partitionen unterteilen und unterschiedliche Sicherheitskontrollen auf die vertraulichen Daten anwenden.
Bereitstellen von Flexibilität bei Vorgängen. Sie können Daten partitionieren, um Vorgänge zu optimieren, die Verwaltungseffizienz zu maximieren und die Kosten zu minimieren. Sie können z. B. Strategien für Verwaltung, Überwachung, Sicherung und Wiederherstellung sowie andere administrative Aufgaben basierend auf der Wichtigkeit der Daten in jeder Partition definieren.
Übereinstimmung der Daten mit dem Anwendungsmuster Sie können jede Partition basierend auf den Kosten und den integrierten Features, die der Datenspeicher bietet, in einem anderen Datenspeichertyp bereitstellen. Sie können z. B. große Binärdaten im Blobspeicher speichern und strukturierte Daten in einer Dokumentdatenbank speichern. Weitere Informationen finden Sie unter Grundlegendes zu Datenspeichermodellen.
Verbesserung der Verfügbarkeit Um einen single point of failure zu vermeiden, können Sie Daten auf mehrere Server verteilen. Wenn eine Instanz ausfällt, sind nur die Daten in dieser Partition nicht verfügbar. Vorgänge werden in anderen Partitionen fortgesetzt. Diese Überlegung ist für verwaltete PaaS-Datenspeicher (Platform-as-a-Service) weniger relevant, da sie über integrierte Redundanz verfügen.

Entwerfen von Partitionen

Es gibt drei typische Strategien zum Partitionieren von Daten:

Horizontale Partitionierung (häufig als Sharding bezeichnet). Bei dieser Strategie stellt jede Partition einen separaten Datenspeicher dar, wobei jedoch alle Partitionen das gleiche Schema aufweisen. Jede Partition wird als Shard bezeichnet und enthält eine Teilmenge der Daten, z. B. eine Reihe von Kundenaufträgen.
Vertikale Partitionierung Bei dieser Strategie enthält jede Partition eine Teilmenge der Felder für Elemente im Datenspeicher. Die Felder werden gemäß ihrem Verwendungsmuster unterteilt. Beispielsweise können häufig verwendete Felder in einer vertikalen Partition und weniger häufig verwendete Felder in einer anderen Partition platziert werden.
Funktionale Partitionierung. Bei dieser Strategie werden Die Daten entsprechend der Verwendung der Daten durch jeden begrenzten Kontext im System aggregiert. Beispiel: Ein E-Commerce-System kann Rechnungsdaten in einer Partition und Daten zum Produktbestand in einer anderen speichern.

Erwägen Sie, diese Strategien zu kombinieren, wenn Sie ein Partitionierungsschema entwerfen. Beispielsweise könnten Sie Daten in Shards unterteilen und dann die Daten mittels vertikaler Partitionierung innerhalb der einzelnen Shards weiter unterteilen.

Horizontale Partitionierung (Sharding)

Die folgende Abbildung zeigt ein Beispiel für horizontale Partitionierung oder Sharding. In diesem Beispiel werden Produktbestandsdaten in Shards unterteilt, die auf dem Product Key basieren. Jedes Shard enthält die Daten für einen zusammenhängenden Bereich von Shard-Schlüsseln (A-G und H-Z) in alphabetischer Anordnung. Wenn Sie Sharding ausführen, wird die Last auf mehr Computer verteilt, wodurch Konflikte reduziert und die Leistung verbessert wird.

Der wichtigste Faktor ist der Shardingschlüssel, den Sie auswählen. Es kann schwierig sein, den Schlüssel zu ändern, nachdem das System in Betrieb ist. Der Schlüssel muss sicherstellen, dass Daten auf eine Weise partitioniert werden, die die Workload möglichst gleichmäßig über die Shards hinweg verteilt.

Die Shards müssen nicht dieselbe Größe aufweisen. Es ist wichtiger, die Anzahl der Anforderungen auszugleichen. Einige Shards sind möglicherweise groß, aber jedes Element im Shard verfügt über eine geringe Anzahl von Zugriffsvorgängen. Andere Shards sind möglicherweise kleiner, aber auf jedes Element im Shard wird häufiger zugegriffen. Es ist auch wichtig sicherzustellen, dass ein einzelner Shard die Skalierungsgrenzwerte in Bezug auf Kapazität und Verarbeitungsressourcen des Datenspeichers nicht überschreitet.

Vermeiden Sie das Erstellen von heißen Partitionen, die sich auf Leistung und Verfügbarkeit auswirken können. Wenn Sie beispielsweise den ersten Buchstaben des Kundennamens verwenden, kann dies zu einer unausgewogenen Verteilung führen, da einige Buchstaben häufiger sind als andere. Verwenden Sie stattdessen einen Kundenbezeichnerhash, um Daten gleichmäßig auf Partitionen zu verteilen.

Wählen Sie einen Shardingschlüssel aus, der die zukünftige Notwendigkeit minimiert, große Shards aufzuteilen, kleine Shards in größere Partitionen zu kombinieren oder das Schema zu ändern. Diese Vorgänge sind zeitaufwändig und erfordern möglicherweise, dass Sie mindestens einen Shard offline schalten.

Wenn Shards repliziert werden, können Sie einige der Replikate online halten, während andere aufgeteilt, zusammengeführt oder neu konfiguriert werden. Das System kann jedoch die Vorgänge einschränken, die während der Neukonfiguration ausgeführt werden können. Beispielsweise können die Daten in den Replikaten als schreibgeschützt markiert werden, um Inkonsistenzen der Daten zu verhindern.

Weitere Informationen finden Sie unter Shardingmuster.

Vertikale Partitionierung

Die häufigste Verwendung für vertikale Partitionierung besteht darin, die E/A- und Leistungskosten zu senken, die mit dem Abrufen häufig aufgerufener Elemente verbunden sind. Die folgende Abbildung zeigt ein Beispiel für die vertikale Partitionierung. In diesem Beispiel sind verschiedene Eigenschaften eines Elements in verschiedenen Partitionen gespeichert. Eine Partition enthält Daten, auf die häufiger zugegriffen wird, einschließlich Produktname, Beschreibung und Preis. Eine andere Partition enthält Bestandsdaten, einschließlich der Bestandsanzahl und des Datums der letzten Bestellung.

In diesem Beispiel fragt die Anwendung regelmäßig den Produktnamen, die Beschreibung und den Preis ab, wenn sie den Kunden die Produktdetails anzeigt. Die Bestandsanzahl und das Datum der letzten Bestellung befinden sich in einer separaten Partition, da diese beiden Elemente häufig zusammen verwendet werden.

Sehen Sie sich die folgenden Vorteile der vertikalen Partitionierung an:

Sie können relativ langsam verschobene Daten (Produktname, Beschreibung und Preis) von dynamischeren Daten (Lagerbestand und Datum der letzten Bestellung) trennen. Langsam verschobene Daten sind ein guter Kandidat für eine Anwendung zum Zwischenspeichern im Arbeitsspeicher.
Sie können vertrauliche Daten in einer separaten Partition mit zusätzlichen Sicherheitskontrollen speichern.
Eine vertikale Partitionierung kann die erforderlichen gleichzeitigen Zugriffe verringern.

Vertikale Partitionierung findet auf der Entitätsebene in einem Datenspeicher statt, wobei eine Entität teilweise normalisiert wird, um sie von einem breiten Element in einen Satz schmaler Elemente aufzuschlüsseln. Es eignet sich ideal für spaltenorientierte Datenspeicher wie HBase und Cassandra. Wenn sich die Daten in einer Auflistung von Spalten wahrscheinlich nicht ändern, sollten Sie die Verwendung von Spaltenspeichern in SQL Server in Betracht ziehen.

Funktionale Partitionierung

Wenn für jeden einzelnen Geschäftsbereich in einer Anwendung ein begrenzter Kontext identifiziert werden kann, kann die funktionale Partitionierung die Isolation und die Leistung des Datenzugriffs verbessern. Darüber hinaus wird die funktionale Partitionierung häufig verwendet, um Lese/Schreibdaten von schreibgeschützten Daten zu trennen. Die folgende Abbildung zeigt eine Übersicht über die funktionale Partitionierung, bei der Bestandsdaten von Kundendaten getrennt sind.

Diese Partitionierungsstrategie kann helfen, Datenzugriffskonflikte über verschiedene Teile eines Systems hinweg zu reduzieren.

Entwerfen von Partitionen für Skalierbarkeit

Es ist wichtig, die Größe und Workload für jede Partition zu berücksichtigen. Ausgleichen sie, sodass die Daten verteilt werden, um eine maximale Skalierbarkeit zu erzielen. Sie müssen die Daten jedoch auch partitionieren, damit sie die Skalierungsgrenzwerte eines einzelnen Partitionsspeichers nicht überschreiten.

Führen Sie die folgenden Schritte aus, wenn Sie Partitionen aus Gründen der Skalierbarkeit entwerfen:

Analysieren Sie die Anwendung, um die Datenzugriffsmuster zu verstehen, z. B. die Größe des Resultsets, das jede Abfrage zurückgibt, die Zugriffshäufigkeit, inhärente Latenz und serverseitige Computeverarbeitungsanforderungen. In vielen Fällen erfordern einige Hauptentitäten die meisten Verarbeitungsressourcen.
Verwenden Sie diese Analyse, um die aktuellen und zukünftigen Skalierbarkeitsziele zu bestimmen, z. B. die Datengröße und die Workload. Anschließend verteilen Sie die Daten auf die Partitionen, um das Skalierbarkeitsziel zu erreichen. Wählen Sie für die horizontale Partitionierung den richtigen Shardschlüssel aus, um eine gleichmäßige Verteilung sicherzustellen. Weitere Informationen finden Sie unter Shardingmuster.
Stellen Sie sicher, dass jede Partition über genügend Ressourcen verfügt, um die Skalierbarkeitsanforderungen in Bezug auf Datengröße und Durchsatz zu bewältigen. Je nach Datenspeicher kann es für jede Partition eine Beschränkung für die Menge des Speicherplatzes, der Verarbeitungsleistung oder der Netzwerkbandbreite geben. Wenn die Anforderungen diese Grenzwerte wahrscheinlich überschreiten, müssen Sie möglicherweise Ihre Partitionierungsstrategie verfeinern oder Die Daten weiter aufteilen. Möglicherweise müssen Sie zwei oder mehr Strategien kombinieren.
Überwachen Sie das System, um sicherzustellen, dass Daten wie erwartet verteilt werden und die Partitionen die Last verarbeiten können. Die tatsächliche Nutzung stimmt nicht immer mit dem überein, was eine Analyse vorhersagt. Möglicherweise müssen Sie die Partitionen neu ausbalancieren oder einige Teile des Systems neu entwerfen, um das erforderliche Gleichgewicht zu erzielen.

Einige Cloudumgebungen weisen Ressourcen basierend auf Infrastrukturgrenzen zu. Stellen Sie sicher, dass die Grenzwerte der ausgewählten Grenze genügend Platz für das erwartete Wachstum von Datenvolumen, Datenspeicher, Verarbeitungsleistung und Bandbreite bieten.

Wenn Sie beispielsweise Azure Table Storage verwenden, gibt es eine Beschränkung für das Anforderungsvolumen, das eine einzelne Partition in einem bestimmten Zeitraum verarbeiten kann. Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für Storage Standard-Konten. Ein ausgelasteter Shard erfordert möglicherweise mehr Ressourcen, als eine einzelne Partition verarbeiten kann. Möglicherweise müssen Sie den Shard neu partitionieren, um die Last zu verteilen. Wenn die Gesamtgröße oder der Durchsatz dieser Tabellen die Kapazität eines Speicherkontos überschreitet, müssen Sie möglicherweise weitere Speicherkonten erstellen und die Tabellen auf diese Konten verteilen.

Entwerfen von Partitionen für die Abfrageleistung

Sie können die Abfrageleistung steigern, indem Sie kleine Datasets verwenden und parallele Abfragen ausführen. Jede Partition sollte einen kleinen Teil des gesamten Datasets enthalten. Diese Reduzierung des Volumens kann die Leistung von Abfragen verbessern. Die Partitionierung ist jedoch keine Alternative zu einem geeigneten Datenbankentwurf und -konfiguration. Stellen Sie sicher, dass Sie die erforderlichen Indizes implementieren.

Führen Sie die folgenden Schritte aus, wenn Sie Partitionen für die Abfrageleistung entwerfen:

Untersuchen Sie die Anwendungsanforderungen und die Leistung.
- Bestimmen Sie die kritischen Anfragen, die stets schnell ausgeführt werden müssen, anhand von Unternehmensanforderungen.
- Überwachen Sie das System, um Abfragen zu identifizieren, die langsam ausgeführt werden.
- Bestimmen Sie die Abfragen, die am häufigsten ausgeführt werden. Auch wenn eine einzelne Abfrage nur minimale Kosten verursacht, kann der kumulative Ressourcenverbrauch erheblich sein.
Partitionieren Sie die Daten, die zu einer langsamen Leistung führen.
- Beschränken Sie die Größe der einzelnen Partitionen, sodass die Abfrageantwortzeit innerhalb des Ziels liegt.
- Wenn Sie die horizontale Partitionierung verwenden, entwerfen Sie den Shardschlüssel so, dass die Anwendung problemlos die entsprechende Partition auswählen kann. Diese Spezifikation verhindert, dass die Abfrage jede Partition überprüft.
- Berücksichtigen Sie den Speicherort einer Partition. Versuchen Sie, Daten in Partitionen zu speichern, die sich geografisch in der Nähe der Anwendungen und Benutzer befinden, die darauf zugreifen.
Wenn für eine Entität Durchsatz- und Abfrageleistungsanforderungen gelten, verwenden Sie die funktionale Partitionierung, die auf dieser Entität basiert. Wenn diese Zuordnung immer noch nicht den Anforderungen entspricht, können Sie horizontale Partitionierung hinzufügen. Eine einzelne Partitionierungsstrategie ist in der Regel angemessen, aber in einigen Fällen ist es effizienter, beide Strategien zu kombinieren.
Führen Sie Abfragen partitionsübergreifend parallel aus, um die Leistung zu verbessern.

Entwerfen von Partitionen für Verfügbarkeit

Partitionieren von Daten, um die Verfügbarkeit von Anwendungen zu verbessern. Durch die Partitionierung wird sichergestellt, dass das gesamte Dataset keinen Single Point of Failure aufweist, und Sie können einzelne Teilmengen des Datasets unabhängig verwalten.

Berücksichtigen Sie die folgenden Faktoren, die sich auf die Verfügbarkeit auswirken:

Bestimmen Sie die Wichtigkeit der Daten. Identifizieren Sie die kritischen Geschäftsdaten, z. B. Transaktionen, und die weniger kritischen Betriebsdaten, z. B. Protokolldateien.

Speichern Sie kritische Daten in hochverfügbaren Partitionen, und erstellen Sie einen geeigneten Sicherungsplan.
Richten Sie separate Verwaltungs- und Überwachungsverfahren für verschiedene Datasets ein.
Platzieren Sie Daten, die die gleiche Wichtigkeitsstufe aufweisen, in derselben Partition, damit sie mit der gleichen Häufigkeit gesichert werden können. Beispielsweise müssen Sie möglicherweise Partitionen sichern, die Transaktionsdaten häufiger enthalten als Partitionen, die Protokollierungs- oder Ablaufverfolgungsinformationen enthalten.

Verwalten einzelner Partitionen. Entwerfen Sie Partitionen, um eine unabhängige Verwaltung und Wartung zu unterstützen. Diese Vorgehensweise bietet mehrere Vorteile, z. B.:

Wenn eine Partition ausfällt, kann sie ohne Anwendungen, die auf Daten in anderen Partitionen zugreifen, unabhängig wiederhergestellt werden.
Die Partitionierung von Daten nach geografischem Bereich ermöglicht geplante Wartungsaufgaben außerhalb der Spitzenzeiten für jeden Standort. Stellen Sie sicher, dass Partitionen nicht so groß sind, dass sie verhindern, dass die geplante Wartung während dieses Zeitraums abgeschlossen wird.

Replizieren sie kritische Daten partitionsübergreifend. Diese Strategie verbessert Verfügbarkeit und Leistung, kann aber auch Konsistenzprobleme mit sich bringen. Das Synchronisieren von Änderungen mit allen Replikaten kostet Zeit. Während der Synchronisierung enthalten verschiedene Partitionen unterschiedliche Datenwerte.

Überlegungen zum Anwendungsentwurf

Durch Partitionierung werden der Entwurf und die Entwicklung des Systems komplexer. Partitionieren Sie Daten als grundlegenden Teil Ihres Systementwurfs, auch wenn das System anfänglich nur eine einzelne Partition enthält. Wenn Sie die Partitionierung nachträglich behandeln, ist dies eine Herausforderung, da Sie bereits über ein Livesystem verfügen, das verwaltet werden muss. Sie könnten:

Die Datenzugriffslogik muss geändert werden.
Sie müssen große Mengen vorhandener Daten migrieren, um sie partitionsübergreifend zu verteilen.
Es treten Herausforderungen auf, da Benutzer erwarten, dass das System während der Migration weiterhin verwendet wird.

In einigen Fällen ist die Partitionierung nicht wichtig, da das anfängliche Dataset klein ist und ein einzelner Server es problemlos verarbeiten kann. Einige Workloads können ohne Partitionen auskommen, aber viele kommerzielle Systeme müssen erweitert werden, wenn die Anzahl der Benutzer zunimmt.

Einige kleine Datenspeicher profitieren ebenfalls von der Partitionierung. Beispielsweise können Hunderte gleichzeitiger Clients auf einen kleinen Datenspeicher zugreifen. Wenn Sie die Daten in dieser Situation partitionieren, kann dies dazu beitragen, Konflikte zu reduzieren und den Durchsatz zu verbessern.

Beachten Sie beim Entwerfen eines Schemas für die Datenpartitionierung folgende Punkte:

Minimieren Sie partitionsübergreifende Datenzugriffsvorgänge. Versuchen Sie, Daten für die gängigsten Datenbankvorgänge zusammen in einer Partition zu speichern, um partitionsübergreifende Datenzugriffsvorgänge zu minimieren. Es kann zeitaufwändiger sein, partitionsübergreifende Abfragen zu erstellen, anstatt innerhalb einer einzelnen Partition abzufragen. Das Optimieren von Partitionen für einen Satz von Abfragen kann sich jedoch negativ auf andere Abfragen auswirken. Wenn Sie partitionsübergreifende Abfragen ausführen müssen, minimieren Sie die Abfragezeit, indem Sie parallele Abfragen ausführen und die Ergebnisse innerhalb der Anwendung aggregieren. In einigen Fällen können Sie diesen Ansatz nicht verwenden, z. B. wenn das Ergebnis einer Abfrage in der nächsten Abfrage verwendet wird.

Replizieren statischer Verweisdaten. Wenn Abfragen relativ statische Verweisdaten verwenden, z. B. Postleitzahltabellen oder Produktlisten, sollten Sie erwägen, diese Daten in allen Partitionen zu replizieren, um separate Nachschlagevorgänge in verschiedenen Partitionen zu reduzieren. Dieser Ansatz kann auch die Wahrscheinlichkeit verringern, dass die Referenzdaten zu einem heißen Dataset mit hohem Datenverkehr aus dem gesamten System werden. Beim Synchronisieren von Änderungen an den Referenzdaten fallen zusätzliche Kosten an.

Minimieren Sie partitionsübergreifende Verknüpfungen. Minimieren Sie nach Möglichkeit die Anforderungen für referenzielle Integrität über vertikale und funktionale Partitionen hinweg. In diesen Schemen ist die Anwendung für die Wahrung der referenziellen Integrität über Partitionen hinweg verantwortlich. Abfragen, die Daten über mehrere Partitionen hinweg verbinden, sind ineffizient, da die Anwendung in der Regel aufeinanderfolgende Abfragen ausführt, die auf einem Schlüssel und dann einem Fremdschlüssel basieren. Ziehen Sie stattdessen in Betracht, die relevanten Daten zu replizieren oder zu denormalisieren. Wenn partitionsübergreifende Verknüpfungen notwendig sind, führen Sie parallele Abfragen über die Partitionen hinweg aus, und verknüpfen Sie die Daten innerhalb der Anwendung.

Implementieren Sie die letztliche Konsistenz. Bewerten Sie, ob eine starke Konsistenz erforderlich ist. Eine gängige Vorgehensweise in verteilten Systemen ist das Implementieren von letztendlicher Konsistenz. Die Daten in jeder Partition werden separat aktualisiert, und die Anwendungslogik stellt sicher, dass die Updates erfolgreich abgeschlossen werden. Die Anwendungslogik verarbeitet auch die Inkonsistenzen, die durch das Abfragen von Daten entstehen, während ein schließlich konsistenter Vorgang ausgeführt wird.

Überlegen Sie, wie Abfragen die richtige Partition finden. Wenn eine Abfrage alle Partitionen überprüfen muss, um die erforderlichen Daten zu finden, wirkt sich dies erheblich auf die Leistung aus, selbst wenn mehrere parallele Abfragen ausgeführt werden. Bei vertikaler und funktionaler Partitionierung können Abfragen die Partition angeben. Andererseits kann die horizontale Partitionierung die Suche nach einem Element erschweren, da jeder Shard das gleiche Schema aufweist. Eine typische Lösung besteht darin, eine Karte zu verwalten, die verwendet wird, um die Shardposition von Elementen zu suchen. Implementieren Sie diese Zuordnung in der Shardinglogik der Anwendung. Sie kann auch vom Datenspeicher verwaltet werden, wenn der Datenspeicher transparentes Sharding unterstützt.

Ausgleichen von Shards in regelmäßigen Abständen. Bei horizontaler Partitionierung können Shards neu ausgeglichen werden, um die Daten gleichmäßig nach Größe und Workload zu verteilen. Balancieren Sie Shards neu aus, um Hotspots zu minimieren, die Abfrageleistung zu maximieren und physische Speichereinschränkungen zu umgehen. Diese Aufgabe ist komplex und erfordert häufig ein benutzerdefiniertes Tool oder einen benutzerdefinierten Prozess.

Replizieren Sie Partitionen. Replizieren Sie jede Partition, um zusätzlichen Schutz vor Fehlern zu bieten. Wenn ein einzelnes Replikat fehlschlägt, werden Abfragen an eine funktionierende Kopie weitergeleitet.

Erweitern Sie die Skalierbarkeit auf eine andere Ebene. Wenn die physischen Grenzen einer Partitionierungsstrategie erreicht sind, müssen Sie die Skalierbarkeit auf eine andere Ebene erweitern. Wurde die Partitionierung beispielsweise auf Datenbankebene implementiert, müssen Sie möglicherweise Partitionen in mehreren Datenbanken suchen oder replizieren. Wenn die Partitionierung bereits auf Datenbankebene erfolgt und physische Einschränkungen bestehen, müssen Sie möglicherweise Partitionen in mehreren Hostingkonten suchen oder replizieren.

Vermeiden Sie Transaktionen, die auf Daten in mehreren Partitionen zugreifen. Einige Datenspeicher implementieren Transaktionskonsistenz und Integrität für Vorgänge, die Daten ändern, aber nur, wenn sich die Daten in einer einzelnen Partition befinden. Wenn Sie Transaktionsunterstützung für mehrere Partitionen benötigen, implementieren Sie sie als Teil Ihrer Anwendungslogik, da die meisten Partitionierungssysteme keine native Unterstützung bieten.

Alle Datenspeicher erfordern ein gewisses Maß an Betriebsverwaltung und Überwachung. Zu diesen Aufgaben gehören das Laden von Daten, das Sichern und Wiederherstellen von Daten, das Reorganisieren von Daten und die Sicherstellung, dass das System ordnungsgemäß und effizient funktioniert.

Berücksichtigen Sie die folgenden Faktoren, die sich auf die Betriebsverwaltung auswirken:

Implementieren Sie geeignete Verwaltungs- und Betriebsaufgaben, wenn die Daten partitioniert werden. Hierzu können Aufgaben zur Sicherung und Wiederherstellung, Datenarchivierung, Systemüberwachung sowie weitere administrative Aufgaben gehören. Beispielsweise kann es schwierig sein, bei Sicherungs- und Wiederherstellungsvorgängen die logische Konsistenz beizubehalten.
Laden Sie Daten in mehrere Partitionen, und fügen Sie neue Daten aus anderen Quellen hinzu. Einige Tools und Hilfsprogramme unterstützen möglicherweise keine Shardvorgänge für Daten, z. B. das Laden von Daten in die richtige Partition.
Daten regelmäßig archivieren und löschen. Um das übermäßige Wachstum von Partitionen zu verhindern, archivieren und löschen Sie Daten jeden Monat. Möglicherweise müssen Sie die Daten transformieren, um einem anderen Archivschema zu entsprechen.
Suchen Sie Nach Problemen mit der Datenintegrität. Erwägen Sie, einen regelmäßigen Prozess auszuführen, um Datenintegritätsprobleme zu finden, z. B. Daten in einer Partition, die auf fehlende Informationen in einer anderen verweisen. Der Prozess kann entweder automatisch versuchen, diese Probleme zu beheben, oder einen Bericht zur manuellen Überprüfung generieren.

Partitionen neu ausbalancieren

Im Zuge der Weiterentwicklung eines Systems müssen Sie möglicherweise das Partitionierungsschema anpassen. Beispielsweise können einzelne Partitionen ein unverhältnismäßiges Datenverkehrsvolumen empfangen und heiß werden, was zu übermäßigen Konflikten führt. Oder Sie haben möglicherweise das Datenvolumen in einigen Partitionen unterschätzt, was dazu führt, dass sich die Partitionen kapazitätsgrenzen nähern.

Einige Datenspeicher, wie z. B. Azure Cosmos DB, können Partitionen automatisch austarieren. In anderen Fällen können Sie Partitionen in zwei Phasen neu ausgleichen:

Bestimmen Sie eine neue Partitionierungsstrategie.
- Welche Partitionen müssen geteilt oder kombiniert werden?
- Was ist der neue Partitionsschlüssel?
Migrieren Sie Daten vom alten Partitionierungsschema in den neuen Satz von Partitionen.

Möglicherweise müssen Sie Partitionen nicht verfügbar machen, während Sie Daten verschieben, was als Offlinemigration bezeichnet wird. Je nach Datenspeicher können Sie Daten zwischen Partitionen migrieren, während sie verwendet werden. Diese Technik wird als Onlinemigration bezeichnet.

Offlinemigration

Die Offlinemigration verringert die Wahrscheinlichkeit, dass Konflikte auftreten. So führen Sie die Offlinemigration durch:

Markieren Sie die Partition als offline. Sie können eine Partition als schreibgeschützt markieren, sodass Anwendungen die Daten weiterhin lesen können, während Sie sie verschieben.
Teilen Sie die Daten auf bzw. führen Sie sie zusammen, und verschieben Sie sie in die neuen Partitionen.
Überprüfen Sie die Daten.
Schalten Sie die neuen Partitionen online.
Entfernen Sie die alte Partition.

Onlinemigration

Die Onlinemigration ist komplexer, aber weniger störend im Vergleich zur Offlinemigration. Der Prozess ähnelt der Offlinemigration, aber Sie markieren die ursprüngliche Partition nicht als offline. Abhängig von der Granularität des Migrationsprozesses, z. B. Element nach Element und Shard nach Shard, muss der Datenzugriffscode in den Clientanwendungen möglicherweise Daten lesen und schreiben, die sich an zwei Speicherorten befinden, der ursprünglichen Partition und der neuen Partition.

Azure-Erleichterung

In den folgenden Abschnitten werden Empfehlungen zum Partitionieren von Daten beschrieben, die in Azure-Diensten gespeichert sind.

Partitionieren in Azure SQL Datenbank

Eine einzelne SQL-Datenbank kann jeweils nur eine bestimmte Datenmenge enthalten. Der Durchsatz wird durch architekturbezogene Faktoren sowie die Anzahl von gleichzeitigen Verbindungen eingeschränkt, die von der Datenbank unterstützt werden.

Pools für elastische Datenbanken unterstützen die horizontale Skalierung für eine SQL-Datenbank. Verwenden Sie Pools für elastische Datenbanken, um Ihre Daten in Shards zu partitionieren, die auf mehrere SQL-Datenbanken verteilt sind. Sie können auch Shards hinzufügen oder entfernen, wenn die Datenmenge wächst und schrumpft. Pools für elastische Datenbanken können auch zur Verringerung von Konflikten beitragen, indem die Last auf mehrere Datenbanken verteilt wird.

Jedes Shard wird als SQL-Datenbank implementiert. Ein Shard kann mehrere Datasets enthalten. Jedes Dataset wird als Shardlet bezeichnet. Jede Datenbank verfügt über Metadaten, die die darin enthaltenen Shardlets beschreiben. Ein Shardlet kann ein einzelnes Datenelement oder eine Gruppe von Elementen sein, die denselben Shardletschlüssel verwenden. In einer mehrinstanzenfähigen Anwendung kann der Shardletschlüssel beispielsweise die Mandanten-ID sein, und alle Daten für einen Mandanten können sich im selben Shardlet befinden.

Anwendungen sind dafür verantwortlich, ein Dataset einem Shardletschlüssel zuzuordnen. Eine separate SQL-Datenbank fungiert als globaler Shardzuordnungs-Manager. Diese Datenbank verfügt über eine Liste aller Shards und Shardlets im System. Die Anwendung stellt eine Verbindung mit der Shardzuordnungs-Manager-Datenbank her, um eine Kopie der Shardzuordnung zu erhalten. Es speichert die Shardzuordnung lokal zwischen und verwendet die Karte, um Datenanforderungen an den entsprechenden Shard weiterzuleiten. Diese Funktionalität ist hinter einer Reihe von APIs verborgen, die in der Clientbibliothek des Features elastische Datenbank von SQL-Datenbank enthalten sind, das für Java und .NET verfügbar ist.

Weitere Informationen zu Pools für elastische Datenbanken finden Sie unter Horizontales Hochskalieren mit SQL-Datenbank.

Sie können die globale Shardzuordnungs-Manager-Datenbank replizieren, um die Wartezeit zu verringern und die Verfügbarkeit zu verbessern. Mit den Premium-Tarifen können Sie die aktive Georeplikation so konfigurieren, dass Daten kontinuierlich in Datenbanken in verschiedenen Regionen kopiert werden.

Alternativ können Sie SQL-Datensynchronisierung für SQL-Datenbank oder Azure Data Factory verwenden, um die Shard map manager-Datenbank regionsübergreifend zu replizieren. Diese Form der Replikation wird in regelmäßigen Abständen ausgeführt und eignet sich besser, wenn sich die Shardzuordnung selten ändert und nicht der Premium-Tarif erforderlich ist.

Elastische Datenbanken bieten zwei Schemas für das Zuordnen von Daten zu Shardlets und deren Speicherung in Shards:

Eine Listenshardzuordnung ordnet einen einzelnen Schlüssel einem Shardlet zu. In einem mehrinstanzenfähigen System können beispielsweise die Daten für jeden Mandanten einem eindeutigen Schlüssel zugeordnet und in einem eigenen Shardlet gespeichert werden. Zur Gewährleistung der Isolation kann jedes Shardlet innerhalb seines eigenen Shards gespeichert werden.

Laden Sie eine Visio-Datei mit dieser Architektur herunter.
Eine Bereichs-Shardzuordnung ordnet einem Shardlet einen Satz zusammenhängender Schlüsselwerte zu. Beispielsweise können Sie die Daten für eine Gruppe von Mandanten gruppieren, die jeweils mit ihrem eigenen Schlüssel im selben Shardlet enthalten sind. Dieses Schema ist kostengünstiger als eine Listen-Shardzuordnung, da Mandanten den Datenspeicher gemeinsam nutzen, aber weniger Isolation bietet.

Laden Sie eine Visio-Datei mit diesem Diagramm herunter.

Ein einzelner Shard kann die Daten für mehrere Shardlets enthalten. Beispielsweise können Sie listenbasierte Shardlets verwenden, um Daten für verschiedene nicht zusammenhängende Mandanten im gleichen Shard zu speichern. Sie können auch Bereichs-Shardlets und Listen-Shardlets im gleichen Shard kombinieren, aber dann werden sie über verschiedene Zuordnungen adressiert. Dieser Ansatz wird im folgenden Diagramm veranschaulicht:

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

Mit Pools für elastische Datenbanken können Sie Shards hinzufügen und entfernen, wenn das Datenvolumen zunimmt und schrumpft. Clientanwendungen können Shards dynamisch und transparent erstellen und löschen, um den Shardzuordnungs-Manager zu aktualisieren. Das Entfernen eines Shards ist jedoch ein destruktiver Vorgang, der auch das Löschen aller Daten in diesem Shard erfordert.

Wenn eine Anwendung einen Shard in zwei separate Shards aufteilen oder Shards miteinander kombinieren muss, verwenden Sie das Split-Merge-Tool. Dieses Tool wird als Azure-Webdienst ausgeführt und migriert Daten sicher zwischen Shards.

Das Partitionierungsschema kann sich erheblich auf die Leistung des Systems auswirken. Es kann sich auch darauf auswirken, wie häufig Shards hinzugefügt oder entfernt oder Daten über Shards hinweg neu partitioniert werden müssen. Beachten Sie die folgenden Punkte:

Gruppieren Sie Daten, die zusammen im selben Shard verwendet werden, und vermeiden Sie Vorgänge, die auf Daten aus mehreren Shards zugreifen. Ein Shard ist eine eigene SQL-Datenbank, und datenbankübergreifende Verknüpfungen müssen auf Clientseite ausgeführt werden, wenn Vorgänge auf mehrere Shards zugreifen.

Obwohl SQL-Datenbank keine datenbankübergreifenden Joins unterstützt, können Sie Tools für elastische Datenbanken verwenden, um Abfragen mit mehreren Shards auszuführen. Bei einer Multishardabfrage werden einzelne Abfragen an die individuellen Datenbanken gesendet und die Ergebnisse zusammengeführt.
Entwerfen Sie ein System, das keine Abhängigkeiten zwischen Shards aufweist. Referenzielle Integritätseinschränkungen, Trigger und gespeicherte Prozeduren in einer Datenbank können nicht auf Objekte in einer anderen datenbank verweisen.
Erwägen Sie die Replikation von Daten über Shards hinweg, wenn Sie über Verweisdaten verfügen, die häufig von Abfragen verwendet werden. Dieser Ansatz kann die Notwendigkeit einer datenbankübergreifenden Verknüpfung von Daten überflüssig machen. Im Idealfall sollten solche Daten statisch oder langsam verschoben werden, um den Replikationsaufwand zu minimieren und die Wahrscheinlichkeit zu verringern, dass sie veraltet sind.
Verwenden Sie das gleiche Schema für Shardlets, die zur gleichen Shardzuordnung gehören. Diese Anleitung wird nicht von SQL-Datenbank erzwungen, aber die Datenverwaltung und -abfrage ist komplex, wenn jedes Shardlet ein anderes Schema aufweist. Erstellen Sie stattdessen separate Shardzuordnungen für jedes Schema. Sie können Daten, die zu verschiedenen Shardlets gehören, im selben Shard speichern.
Speichern Sie Daten im gleichen Shard, oder implementieren Sie letztliche Konsistenz, wenn Ihre Geschäftslogik Transaktionen ausführen muss. Transaktionsvorgänge werden nur für Daten unterstützt, die sich in einem Shard befinden, und nicht für Shards. Transaktionen können Shardlets umfassen, wenn sie Teil desselben Shards sind.
Platzieren Sie Shards in der Nähe der Benutzer, die auf die Daten in diesen Shards zugreifen. Diese Strategie hilft dabei, Latenzen zu reduzieren.
Vermeiden Sie eine Kombination aus hochaktiven und relativ inaktiven Shards. Versuchen Sie, die Last gleichmäßig über Shards hinweg zu verteilen. Möglicherweise müssen Sie die Shardingschlüssel hashen. Wenn Sie Shards geoortieren, stellen Sie sicher, dass die Hashschlüssel Shardlets in Shards zugeordnet sind, die in der Nähe der Benutzer gespeichert sind, die auf diese Daten zugreifen.

Partition in Azure Blob Storage

Mit Blob Storage können Sie große binäre Objekte speichern. Verwenden Sie Blockblobs in Szenarien, in denen Sie große Datenmengen schnell hochladen oder herunterladen müssen. Verwenden Sie Seitenblobs für Anwendungen, die zufälligen und nicht seriellen Zugriff auf Teile der Daten erfordern.

Jedes Blockblob oder Seitenblob wird in einem Container in einem Azure-Speicherkonto gespeichert. Verwenden Sie Container, um verwandte Blobs zu gruppieren, die die gleichen Sicherheitsanforderungen haben. Diese Gruppierung ist nicht physischer, sondern logischer Art. In einem Container hat jedes Blob einen eindeutigen Namen.

Der Partitionsschlüssel für ein Blob ist der Kontoname, der Containername und der Blobname. Der Partitionsschlüssel wird verwendet, um Daten in Bereiche zu partitionieren. Diese Bereiche haben einen Lastenausgleich im gesamten System. Blobs können auf viele Server verteilt werden, um den Zugriff auf sie horizontal hochzuskalieren. Ein einzelnes Blob kann nur von einem einzelnen Server bereitgestellt werden.

Wenn Ihr Benennungsschema Zeitstempel oder numerische Bezeichner verwendet, kann dies zu übermäßigem Datenverkehr für eine Partition führen. Dadurch wird verhindert, dass das System einen effektiven Lastenausgleich hat. Wenn Sie für instance über tägliche Vorgänge verfügen, die ein Blobobjekt mit einem Zeitstempel verwenden, z. B. yyyyy-mm-tt, geht der gesamte Datenverkehr für diesen Vorgang an einen einzelnen Partitionsserver. Stellen Sie dem Namen stattdessen einen dreistelligen Hash voran. Weitere Informationen finden Sie unter Partitionsbenennungskonvention.

Die Aktionen zum Schreiben eines einzelnen Blocks oder einer einzelnen Seite sind atomar, Vorgänge, die sich über Blöcke, Seiten oder Blobs erstrecken, jedoch nicht. Wenn Sie die Konsistenz sicherstellen müssen, wenn Schreibvorgänge über Blöcke, Seiten und Blobs hinweg ausgeführt werden, nehmen Sie eine Schreibsperre mithilfe einer Bloblease auf.

Überlegungen

Die Datenpartitionierung bringt einige Herausforderungen und Komplexitäten mit sich, die Sie berücksichtigen müssen.

Die Datensynchronisierung zwischen den Partitionen kann zu einer Herausforderung werden. Stellen Sie sicher, dass Updates oder Änderungen an einer Partition rechtzeitig und konsistent an die anderen Partitionen weitergegeben werden.
Failover- und Notfallwiederherstellungsprozesse werden komplex, wenn Sie die Sicherung und Wiederherstellung mehrerer Partitionen koordinieren müssen. Probleme mit der Datenintegrität können auftreten, wenn einige Partitionen oder ihre Sicherungen beschädigt oder nicht verfügbar sind.
Die Datenpartitionierung kann sich auf die Leistung und Zuverlässigkeit auswirken, wenn Sie partitionsübergreifende Abfragen ausführen müssen und wenn Sie die Partitionen neu ausbalancieren, wenn die Daten ungleichmäßig wachsen.

Zuverlässigkeitsprüfliste

Sehen Sie sich den vollständigen Satz von Empfehlungen an.

Zuverlässigkeitsprüfliste

Share via

Empfehlungen für die Datenpartitionierung