Empfehlungen für die Datenpartitionierung

Artikel
11/15/2023

Gilt für diese Empfehlung für die Zuverlässigkeitsprüfliste des Azure Well-Architected Framework:

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

Verwandte Anleitung: Skalierung

In diesem Leitfaden werden die Empfehlungen zum Entwerfen einer Datenpartitionierungsstrategie für die von Ihnen bereitgestellte Datenbank- und Datenspeichertechnologie beschrieben. Diese Strategie hilft Ihnen, die Zuverlässigkeit Ihrer Datenmenge zu verbessern.

Wichtige Entwurfsstrategien

In vielen umfangreichen Lösungen werden Partitionen verwendet, um Daten aufzuteilen, sodass sie separat verwaltet und darauf zugegriffen werden kann. Durch die Partitionierung von Daten wird die Skalierbarkeit verbessert, die Konflikte reduziert und die Leistung optimiert. Implementieren Sie die Datenpartitionierung, um Daten nach Verwendungsmuster zu dividieren. So können Sie beispielsweise ältere Daten in kostengünstigem Datenspeicher archiven. 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 der SQL Server-Tabellenpartitionierung.

Gründe für Datenpartitionierung

Verbesserung der Skalierbarkeit. Wenn Sie ein einzelnes Datenbanksystem skalieren, erreicht die Datenbank schließlich einen physischen Hardwaregrenzwert. Wenn Sie Daten über mehrere Partitionen aufteilen, können Sie mit jeder Partition, die auf einem separaten Server gehostet wird, das System nahezu unbegrenzt skalieren.
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 gestalten. 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 trennen und verschiedene Sicherheitssteuerelemente auf die vertraulichen Daten anwenden.
Bereitstellen von Flexibilität bei Vorgängen. Sie können Daten partitionieren, um Vorgänge zu optimieren, administrative Effizienz zu maximieren und 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 auf einer anderen Art von Datenspeicher basierend auf den Kosten und den integrierten Features bereitstellen, die der Datenspeicher bietet. Sie können beispielsweise große Binärdaten im BLOB-Speicher speichern und strukturierte Daten in einer Dokumentdatenbank speichern. Weitere Informationen finden Sie unter Grundlegendes zu Datenspeichermodellen.
Verbesserung der Verfügbarkeit Um einen einzelnen Fehlerpunkt zu vermeiden, können Sie Daten auf mehreren Servern trennen. 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 Plattform-as-a-Service-Datenspeicher 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 Kundenbestellungen.
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. In dieser Strategie werden Daten so aggregiert, wie jeder gebundene Kontext im System die Daten verwendet. Beispiel: Ein E-Commerce-System kann Rechnungsdaten in einer Partition und Daten zum Produktbestand in einer anderen speichern.

Erwägen Sie die Kombination dieser Strategien beim Entwerfen eines Partitionierungsschemas. 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 durchführen, verteilt sie die Last über mehr Computer, wodurch die Konflikte reduziert und die Leistung verbessert wird.

Der wichtigste Faktor ist der von Ihnen ausgewählte Shardingschlüssel. 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 in der Shard hat eine geringe Anzahl von Zugriffsvorgängen. Andere Shards sind möglicherweise kleiner, aber auf jedes Element in der Shard wird häufiger zugegriffen. Es ist auch wichtig, sicherzustellen, dass ein einzelner Shard die Skalierungsgrenzwerte im Hinblick auf Kapazität und Verarbeitungsressourcen des Datenspeichers nicht überschreitet.

Vermeiden Sie das Erstellen von Hot Partitionen, die sich auf die Leistung und Verfügbarkeit auswirken können. Wenn Sie beispielsweise den ersten Buchstaben eines Kundennamens verwenden, kann er eine unausgewogene Verteilung erstellen, da einige Buchstaben häufiger sind als andere. Verwenden Sie stattdessen einen Kundenbezeichnerhash, um Daten gleichmäßig über 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 einen oder mehrere Shards offline schalten.

Wenn Shards repliziert werden, können Sie einige der Replikate online halten, während andere geteilt, 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 Sharding-Muster.

Vertikale Partitionierung

Die häufigste Verwendung für die vertikale Partitionierung besteht darin, die E/A- und Leistungskosten zu reduzieren, die mit dem Abrufen häufig aufgerufener Elemente verbunden sind. Die folgende Abbildung zeigt ein Beispiel für 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 Lageranzahl und des letzten bestellten Datums.

In diesem Beispiel fragt die Anwendung regelmäßig den Produktnamen, die Beschreibung und den Preis ab, wenn die Produktdetails für Kunden angezeigt werden. Die Lageranzahl und das datum der letzten Reihenfolge 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 verschiebende Daten (Produktname, Beschreibung und Preis) von dynamischeren Daten (Aktienniveau und datum der letzten Bestellung) trennen. Langsam verschiebende Daten sind ein guter Kandidat für eine Anwendung, die im Arbeitsspeicher zwischengespeichert werden kann.
Sie können vertrauliche Daten in einer separaten Partition mit zusätzlichen Sicherheitssteuerelementen 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, z. B. HBase und Cassandra. Wenn die Daten in einer Sammlung von Spalten nicht geändert werden können, erwägen Sie die Verwendung von Spaltenspeichern in SQL Server.

Funktionale Partitionierung

Wenn ein gebundener Kontext für jeden einzelnen Geschäftsbereich in einer Anwendung identifiziert werden kann, kann die funktionale Partitionierung die Isolations- und Datenzugriffsleistung 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 mit Bestandsdaten, die 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 sie so, dass 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 überschreitet.

Führen Sie die folgenden Schritte aus, wenn Sie Partitionen zur Skalierbarkeit entwerfen:

Analysieren Sie die Anwendung, um die Datenzugriffsmuster zu verstehen, z. B. die Größe des Resultsets, das von jeder Abfrage zurückgegeben wird, die Häufigkeit des Zugriffs, die inhärente Latenz und serverseitige Computeverarbeitungsanforderungen. In vielen Fällen benötigen einige große Entitäten die meisten Verarbeitungsressourcen.
Verwenden Sie diese Analyse, um die aktuellen und zukünftigen Skalierbarkeitsziele zu ermitteln, z. B. die Datengröße und die Arbeitsauslastung. 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 Sharding-Muster.
Stellen Sie sicher, dass jede Partition über genügend Ressourcen verfügt, um die Skalierbarkeitsanforderungen hinsichtlich der Datengröße und des Durchsatzes zu erfüllen. Je nach Datenspeicher kann es für jede Partition einen Grenzwert für die Menge an Speicherplatz, Verarbeitungsleistung oder Netzwerkbandbreite geben. Wenn die Anforderungen diese Grenzwerte wahrscheinlich überschreiten, müssen Sie möglicherweise Ihre Partitionierungsstrategie verfeinern oder Daten weiter austeilen. 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 Verwendung stimmt nicht immer mit dem überein, was eine Analyse voraussagt. Möglicherweise müssen Sie die Partitionen neu ausgleichen oder einige Teile des Systems neu gestalten, um das erforderliche Gleichgewicht zu erzielen.

Einige Cloudumgebungen weisen Ressourcen basierend auf Infrastrukturgrenzen zu. Stellen Sie sicher, dass die Grenzwerte Ihrer 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 ein Limit für das Volumen von Anforderungen, die 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 dem geeigneten Datenbankentwurf und der entsprechenden 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:

Überprüfen 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.
- Ermitteln Sie die Abfragen, die am häufigsten ausgeführt werden. Auch wenn eine einzelne Abfrage minimale Kosten aufweist, kann der kumulierte 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 durchsucht.
- Berücksichtigen Sie den Speicherort einer Partition. Versuchen Sie, Daten in Partitionen zu speichern, die geografisch nah an den Anwendungen und Benutzern sind, die darauf zugreifen.
Wenn eine Entität Durchsatz- und Abfrageleistungsanforderungen aufweist, verwenden Sie die funktionale Partitionierung, die auf dieser Entität basiert. Wenn diese Zuordnung die Anforderungen weiterhin nicht erfüllt, können Sie eine horizontale Partitionierung hinzufügen. Eine einzelne Partitionierungsstrategie ist in der Regel ausreichend, aber in einigen Fällen ist es effizienter, beide Strategien zu kombinieren.
Führen Sie Abfragen parallel über Partitionen aus, um die Leistung zu verbessern.

Entwerfen von Partitionen für die Verfügbarkeit

Partitionieren Sie Daten, um die Verfügbarkeit von Anwendungen zu verbessern. Durch die Partitionierung wird sichergestellt, dass das gesamte Dataset keinen einzelnen Fehlerpunkt 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 Kritischität der Daten. Identifizieren Sie die kritischen Geschäftsdaten, z. B. Transaktionen, und die weniger kritischen Betriebsdaten, z. B. Protokolldateien.

Speichern Sie wichtige Daten in hochverwendten Partitionen, und erstellen Sie einen geeigneten Sicherungsplan.
Richten Sie separate Verwaltungs- und Überwachungsverfahren für verschiedene Datasets ein.
Platzieren Sie Daten mit derselben Kritischen Ebene in derselben Partition, sodass sie mit derselben Häufigkeit gesichert werden kann. 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 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.
Durch die Partitionierung von Daten nach geografischem Gebiet können geplante Wartungsaufgaben zu Spitzenzeiten für jeden Standort erfolgen. Stellen Sie sicher, dass Partitionen nicht so groß sind, dass sie die geplante Wartung während dieses Zeitraums verhindern.

Replizieren kritischer Daten über Partitionen hinweg. Diese Strategie verbessert die 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 unterschiedliche Partitionen unterschiedliche Datenwerte.

Überlegungen zum Anwendungsentwurf

Durch Partitionierung werden der Entwurf und die Entwicklung des Systems komplexer. Partitionieren von Daten als grundlegender Bestandteil Des Systemdesigns auch dann, wenn das System anfänglich nur eine einzelne Partition enthält. Wenn Sie die Partitionierung als Nachherein behandeln, ist dies eine Herausforderung, da Sie bereits über ein Livesystem verfügen, das verwaltet werden kann. Sie könnten:

Müssen Sie die Datenzugriffslogik ändern.
Sie müssen große Mengen vorhandener Daten migrieren, um sie über Partitionen zu verteilen.
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 gehen, aber viele kommerzielle Systeme müssen sich erweitern, wenn die Anzahl der Benutzer steigt.

Einige kleine Datenspeicher profitieren auch 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, den Inhalt 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 am häufigsten verwendeten Datenbankvorgänge in einer Partition zusammenzuhalten, um partitionsübergreifende Datenzugriffsvorgänge zu minimieren. Es kann zeitaufwändiger sein, zwischen Partitionen abzufragen, anstatt innerhalb einer einzelnen Partition abzufragen. Das Optimieren von Partitionen für eine Gruppe 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 aus einer Abfrage in der nächsten Abfrage verwendet wird.

Replizieren statischer Referenzdaten. Wenn Abfragen relativ statische Referenzdaten wie Postleitzahlentabellen oder Produktlisten verwenden, sollten Sie diese Daten in allen Partitionen 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 starkem Datenverkehr über das gesamte System hinweg werden. Es gibt zusätzliche Kosten für die Synchronisierung von Änderungen an den Referenzdaten.

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 verknüpfen, sind ineffizient, da die Anwendung in der Regel aufeinander folgende 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 eine Anforderung 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 behandelt auch die Inkonsistenzen, die sich aus dem Abfragen von Daten ergeben, 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 auch dann erheblich auf die Leistung aus, wenn mehrere parallele Abfragen ausgeführt werden. Mit vertikaler und funktionaler Partitionierung können Abfragen die Partition angeben. Andererseits kann die horizontale Partitionierung das Auffinden eines Elements erschweren, da jeder Shard dasselbe Schema aufweist. Eine typische Lösung besteht darin, eine Karte zu verwalten, die zum Nachschlagen derHardposition von Elementen verwendet wird. Implementieren Sie diese Zuordnung in der Shardinglogik der Anwendung. Sie kann auch vom Datenspeicher verwaltet werden, wenn der Datenspeicher transparente Sharding unterstützt.

Rebalance shards periodisch. Bei horizontaler Partitionierung können Rebalancing-Shards helfen, die Daten gleichmäßig nach Größe und Workload zu verteilen. Ausgleichen Sie Shards, 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 bereitzustellen. Wenn ein einzelnes Replikat fehlschlägt, werden Abfragen an eine Arbeitskopie weitergeleitet.

Erweitern Der 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 sich die Partitionierung bereits auf Datenbankebene befindet 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 einzigen Partition befinden. Wenn Sie transaktionsübergreifende Unterstützung für mehrere Partitionen benötigen, implementieren Sie sie als Teil Der Anwendungslogik, da die meisten Partitionierungssysteme keine systemeigene 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 Neuorganisieren von Daten und die Sicherstellung, dass das System ordnungsgemäß und effizient ausgeführt wird.

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, logische Konsistenz bei Sicherungs- und Wiederherstellungsvorgängen aufrechtzuerhalten.
Laden Sie Daten in mehrere Partitionen, und fügen Sie neue Daten hinzu, die aus anderen Quellen stammen. Einige Tools und Dienstprogramme unterstützen möglicherweise keine shardierten Datenvorgänge, z. B. das Laden von Daten in die richtige Partition.
Regelmäßiges Archiven und Löschen von Daten. Um das übermäßige Wachstum von Partitionen zu verhindern, archivieren und löschen Sie Daten jeden Monat. Möglicherweise müssen Sie die Daten so transformieren, dass sie einem anderen Archivschema 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 zu generieren.

Neuausbalancieren von Partitionen

Im Zuge der Weiterentwicklung eines Systems müssen Sie möglicherweise das Partitionierungsschema anpassen. Beispielsweise können einzelne Partitionen mit einem unverhältnismäßigen Datenverkehrsvolumen beginnen und heiß werden, was zu übermäßigem Inhalt führt. Oder Sie haben möglicherweise das Datenvolumen in einigen Partitionen unterschätzt, was dazu führt, dass die Partitionen an Kapazitätsgrenzen herangehen.

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 aufgeteilt 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, die als Offlinemigration bezeichnet werden. Je nach Datenspeicher können Sie Daten zwischen Partitionen migrieren, während sie verwendet werden. Diese Technik wird als Onlinemigration bezeichnet.

Offlinemigration

Die Offlinemigration reduziert die Wahrscheinlichkeit, dass Konflikte auftreten. So führen Sie die Offlinemigration aus:

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. Je nach Granularität des Migrationsprozesses, z. B. Element nach Element und Shard durch 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 für die Partitionierung von Daten beschrieben, die in Azure-Diensten gespeichert sind.

Partition 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 elastische Pools, um Ihre Daten in Shards zu partitionieren, die sich auf mehrere SQL-Datenbanken erstrecken. Sie können auch Shards hinzufügen oder entfernen, wenn das Datenvolumen wächst und verkleinern wird. 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 gemeinsam verwenden. Beispielsweise kann der Shardletschlüssel in einer mehrinstanzenfähigen Anwendung die Mandanten-ID sein, und alle Daten für einen Mandanten können sich im gleichen Shardlet befinden.

Anwendungen sind für die Zuordnung eines Datasets mit einem Shardletschlüssel verantwortlich. 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. Sie speichert die Shardmap lokal zwischen und verwendet die Karte, um Datenanforderungen an die entsprechende Shard-Datei weiterzuleiten. Diese Funktionalität ist hinter einer Reihe von APIs verborgen, die in der Clientbibliothek des Features "Elastic Database" von SQL-Datenbank enthalten sind, das für Java und .NET verfügbar ist.

Weitere Informationen zu elastischen Pools finden Sie unter Skalieren 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-Preisstufen 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 über Regionen hinweg zu replizieren. Diese Replikationsform wird regelmäßig ausgeführt und ist besser geeignet, wenn sich die shard map selten ändert und die Premium-Stufe nicht erfordert.

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

Eine Listenshardkarte 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 Bereichsshardmap ordnet eine Reihe zusammenhängender Schlüsselwerte einem Shardlet zu. Sie können beispielsweise die Daten für eine Gruppe von Mandanten gruppieren, jeweils mit ihrem eigenen Schlüssel innerhalb desselben Shardlets. Dieses Schema ist weniger teuer als eine Listenshardzuordnung, da Mandanten die Datenspeicherung teilen, sie bietet jedoch weniger Isolation.

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 Bereichsshardlets und Listenshardlets in demselben Shard mischen, aber dann werden sie über verschiedene Karten adressiert. Dieser Ansatz wird im folgenden Diagramm veranschaulicht:

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

Mit elastischen Pools können Sie Shards hinzufügen und entfernen, wenn das Datenvolumen wächst und schrumpft. Clientanwendungen können Shards dynamisch erstellen und löschen und den Shard-Karten-Manager transparent 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 in derselben Shard verwendet werden, und vermeiden Sie Vorgänge, die auf Daten von mehreren Shards zugreifen. Ein Shard ist eine SQL-Datenbank in eigener Berechtigung, und datenbankübergreifende Verknüpfungen müssen auf clientseitiger Seite ausgeführt werden, wenn Vorgänge auf mehrere Shards zugreifen.

Obwohl SQL-Datenbank datenbankübergreifende Verknüpfungen nicht unterstützt, können Sie elastic Database Tools verwenden, um Mehrshardabfragen 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 das Replizieren von Daten über Shards hinweg, wenn Sie Referenzdaten haben, die häufig von Abfragen verwendet werden. Bei diesem Ansatz kann es nicht erforderlich sein, Daten in Datenbanken zu verknüpfen. Im Idealfall sollten solche Daten statisch oder langsam sein, um den Replikationsaufwand zu minimieren und die Wahrscheinlichkeit zu verringern, dass sie veraltet wird.
Verwenden Sie dasselbe Schema für Shardlets, die zur gleichen Shardmap gehören. Diese Anleitung wird nicht durch 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 speichern, die zu verschiedenen Shardlets gehören.
Speichern Sie Daten in derselben Konsistenz, oder implementieren Sie die 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 Shards 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ärobjekte speichern. Verwenden Sie Block-Blobs in Szenarien, in denen Sie große Datenmengen schnell hochladen oder herunterladen müssen. Verwenden Sie Seitenblobs für Anwendungen, die zufälligen Zugriff auf Teile der Daten erfordern, statt auf serielle.

Jeder Block-Blob oder Seiten-Blob wird in einem Container in einem Azure-Speicherkonto gespeichert. Verwenden Sie Container, um verwandte Blobs zu gruppieren, die dieselben 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 sind im gesamten System lastenausgleich. Blobs können über viele Server verteilt werden, um den Zugriff auf sie zu skalieren. Ein einzelnes Blob kann nur von einem einzelnen Server bereitgestellt werden.

Wenn Ihr Benennungsschema Zeitstempel oder numerische Bezeichner verwendet, kann es zu übermäßigem Datenverkehr zu einer Partition führen. Es verhindert, dass das System einen effektiven Lastenausgleich hat. Wenn Sie z. B. tägliche Vorgänge haben, die ein BLOB-Objekt mit einem Zeitstempel verwenden, z . B. "jjjj-mm-dd", wird der gesamte Datenverkehr für diesen Vorgang an einen einzelnen Partitionsserver übertragen. Stellen Sie stattdessen dem Namen einen dreistelligen Hash voran. Weitere Informationen finden Sie unter Partitionsbenennungskonvention.

Die Aktionen zum Schreiben eines einzelnen Blocks oder einer einzelnen Seite sind atomisch, aber Vorgänge, die Blöcke, Seiten oder Blobs umfassen, sind 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 BLOB-Lease heraus.

Überlegungen

Die Datenpartitionierung führt zu einigen Herausforderungen und Komplexitäten, die Sie berücksichtigen müssen.

Die Datensynchronisierung zwischen den Partitionen kann zu einer Herausforderung werden. Stellen Sie sicher, dass Aktualisierungen oder Änderungen an einer Partition zeitnah und konsistent an die anderen Partitionen weitergegeben werden.
Failover- und Notfallwiederherstellungsprozesse werden komplex, wenn Sie die Sicherung und Wiederherstellung mehrerer Partitionen koordinieren müssen. Datenintegritätsprobleme 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übergreifend abfragen müssen, und wenn Sie die Partitionen neu ausgleichen, wenn die Daten ungleichmäßig wachsen.

Zuverlässigkeitsprüfliste

Lesen Sie den vollständigen Satz von Empfehlungen.

Zuverlässigkeitsprüfliste

Freigeben über

Empfehlungen für die Datenpartitionierung