Leitfaden zur Datenpartitionierung

Azure Blob Storage

In vielen umfangreichen Lösungen werden Daten in Partitionen unterteilt, die separat verwaltet und darauf zugegriffen werden können. Partitionierung kann die Skalierbarkeit verbessern, Konflikte reduzieren und die Leistung optimieren. Sie kann auch einen Mechanismus für das Unterteilen von Daten nach Verwendungsmuster bereitstellen. Beispielsweise können Sie ältere Daten in kostengünstigeren Datenspeichern archivieren.

Die Partitionierungsstrategie muss jedoch sorgfältig ausgewählt werden, um die Vorteile zu maximieren und gleichzeitig nachteilige Auswirkungen zu minimieren.

Hinweis

In diesem Artikel bedeutet die Begriffpartitionierung den Prozess der physischen Aufteilung von Daten in separate Datenspeicher. Sie ist nicht identisch mit der SQL Server-Tabellenpartitionierung.

Warum Partitionsdaten?

• Verbessern Sie die Skalierbarkeit. Wenn Sie ein einzelnes Datenbanksystem skalieren, erreicht es schließlich ein physisches Hardwarelimit. Wenn Sie Daten über mehrere Partitionen aufteilen, können Sie jedes auf einem separaten Server gehostete System nahezu unbegrenzt skalieren.

• Verbessern der Leistung: Datenzugriffsvorgänge auf jeder Partition erfolgen über ein kleineres Datenvolumen. Richtig erledigt, kann die Partitionierung Ihr System effizienter gestalten. Vorgänge, die sich auf mehrere Partitionen auswirken, können parallel ausgeführt werden.

• Verbessern Sie die 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.

• Bieten Sie die betriebstechnische Flexibilität. Partitionierung bietet viele Möglichkeiten zum Optimieren von Vorgängen, zur Maximierung der Verwaltungseffizienz und zur Minimierung der Kosten. Sie können z. B. verschiedene Strategien für Verwaltung, Überwachung, Sicherung und Wiederherstellung sowie andere administrative Aufgaben basierend auf der Wichtigkeit der Daten in jeder Partition definieren.

• Ordnen Sie den Datenspeicher dem Verwendungsmuster zu. Mithilfe der Partitionierung kann jede Partition auf einer anderen Art von Datenspeicher bereitgestellt werden, basierend auf Kosten und den integrierten Features, die der Datenspeicher bietet. Beispielsweise können große Binärdaten im BLOB-Speicher gespeichert werden, während strukturiertere Daten in einer Dokumentdatenbank gespeichert werden können. Weitere Informationen finden Sie unter Auswählen des richtigen Datenspeichers.

• Verbessern Sie die Verfügbarkeit. Durch das Trennen von Daten über mehrere Server wird ein einzelner Fehlerpunkt vermieden. Wenn eine Instanz fehlschlägt, sind nur die Daten in dieser Partition nicht verfügbar. Vorgänge auf anderen Partitionen können fortgesetzt werden. Bei verwalteten Plattform-as-a-Service-Datenspeichern (PaaS) ist diese Überlegung weniger relevant, da diese Dienste mit integrierter Redundanz konzipiert sind.

Entwerfen von Partitionen

Es gibt drei typische Strategien für die Partitionierung von Daten:

• Horizontale Partitionierung (häufig als Sharding bezeichnet). In dieser Strategie ist jede Partition ein separater Datenspeicher, aber alle Partitionen haben dasselbe Schema. Jede Partition wird als Shard bezeichnet und enthält eine bestimmte Teilmenge der Daten, z. B. alle Bestellungen für eine bestimmte Gruppe von Kunden.

• Vertikale Partitionierung. In dieser Strategie enthält jede Partition eine Teilmenge der Felder für Elemente im Datenspeicher. Die Felder werden nach ihrem Einsatzmuster unterteilt. Häufig verwendete Felder können beispielsweise in einer vertikalen Partition und weniger häufig auf Felder in einem anderen zugegriffen werden.

• Funktionale Partitionierung. In dieser Strategie werden Daten so aggregiert, wie sie von jedem gebundenen Kontext im System verwendet werden. Beispielsweise kann ein E-Commerce-System Rechnungsdaten in einer Partition und Produktbestandsdaten in einer anderen speichern.

Diese Strategien können kombiniert werden, und es wird empfohlen, sie beim Entwerfen eines Partitionierungsschemas zu berücksichtigen. Beispielsweise können Sie Daten in Shards unterteilen und dann die vertikale Partitionierung verwenden, um die Daten in den einzelnen Shards weiter zu unterteilen.

Horizontale Partitionierung (Sharding)

Abbildung 1 zeigt horizontale Partitionierung oder Sharding. In diesem Beispiel werden Produktbestandsdaten basierend auf dem Product Key in Shards unterteilt. Jeder Shard enthält die Daten für einen zusammenhängenden Bereich von Shardschlüsseln (A-G und H-Z), organisiert alphabetisch. Durch Sharding wird die Last über mehr Computer verteilt, wodurch die Konflikte reduziert und die Leistung verbessert wird.

Abbildung 1: Horizontal partitionierende Daten (Sharding) basierend auf einem Partitionsschlüssel.

Der wichtigste Faktor ist die Wahl eines Shardingschlüssels. Es kann schwierig sein, den Schlüssel zu ändern, nachdem das System in Betrieb ist. Der Schlüssel muss sicherstellen, dass Daten partitioniert werden, um die Workload so gleichmäßig wie möglich über dieHards hinweg zu verteilen.

Die Scherben müssen nicht dieselbe Größe aufweisen. Es ist wichtiger, die Anzahl der Anforderungen abzuwägen. Einige Shards sind möglicherweise sehr groß, aber jedes Element verfügt über eine geringe Anzahl von Zugriffsvorgängen. Andere Scherben sind möglicherweise kleiner, aber auf jedes Element wird viel 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 "hot"-Partitionen, die sich auf die Leistung und Verfügbarkeit auswirken können. Die Verwendung des ersten Buchstabens eines Kundennamens verursacht beispielsweise eine unausgewogene Verteilung, da einige Buchstaben häufiger vorkommen. Verwenden Sie stattdessen einen Hash eines Kundenbezeichners, um Daten gleichmäßiger über Partitionen zu verteilen.

Wählen Sie einen Sharding-Schlüssel aus, der alle zukünftigen Anforderungen minimiert, um große Shards aufzuteilen, kleine Shards in größere Partitionen zusammenzugliedern oder das Schema zu ändern. Diese Vorgänge können sehr zeitaufwändig sein und erfordern möglicherweise eine oder mehrere Shards offline, während sie ausgeführt werden.

Wenn Shards repliziert werden, kann es möglich sein, einige der Replikate online zu halten, während andere geteilt, zusammengeführt oder neu konfiguriert werden. Möglicherweise muss das System 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 gekennzeichnet werden, um Dateninkonsistenzen zu verhindern.

Weitere Informationen zur horizontalen Partitionierung 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 von Elementen verbunden sind, auf die häufig zugegriffen wird. Abbildung 2 zeigt ein Beispiel für vertikale Partitionierung. In diesem Beispiel werden 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: die Lageranzahl und das Datum der letzten Bestellung.

Abbildung 2: Vertikale Partitionierung von Daten anhand des Verwendungsmusters.

In diesem Beispiel fragt die Anwendung regelmäßig den Produktnamen, die Beschreibung und den Preis ab, wenn die Produktdetails den Kunden angezeigt werden. Die Lageranzahl und das Datum der letzten Reihenfolge werden in einer separaten Partition gespeichert, da diese beiden Elemente häufig zusammen verwendet werden.

Weitere Vorteile der vertikalen Partitionierung:

• Relativ langsame Daten (Produktname, Beschreibung und Preis) können von den dynamischeren Daten (Lagerstand und datum der letzten Bestellung) getrennt werden. Langsam verschiebende Daten sind ein guter Kandidat für eine Anwendung, die im Arbeitsspeicher zwischengespeichert werden kann.

• Vertrauliche Daten können in einer separaten Partition mit zusätzlichen Sicherheitskontrollen gespeichert werden.

• Die vertikale Partitionierung kann die Anzahl gleichzeitiger Zugriffe verringern, die benötigt werden.

Die vertikale Partitionierung erfolgt auf Entitätsebene innerhalb eines Datenspeichers, wobei eine Entität teilweise normalisiert wird, um sie von einem breiten Element in eine Gruppe schmaler Elemente aufzuteilen. Es eignet sich ideal für spaltenorientierte Datenspeicher wie HBase und Cassandra. Wenn die Daten in einer Sammlung von Spalten nicht geändert werden können, können Sie auch die Verwendung von Spaltenspeichern in SQL Server in Betracht ziehen.

Funktionale Partitionierung

Wenn es möglich ist, einen gebundenen Kontext für jeden einzelnen Geschäftsbereich in einer Anwendung zu identifizieren, ist die funktionale Partitionierung eine Möglichkeit, isolations- und Datenzugriffsleistung zu verbessern. Eine weitere häufige Verwendung für die funktionale Partitionierung besteht darin, Lese-/Schreibdaten von schreibgeschützten Daten zu trennen. Abbildung 3 zeigt eine Übersicht über die funktionale Partitionierung, bei der Bestandsdaten von Kundendaten getrennt sind.

Abbildung 3: Funktionale Partitionierung von Daten durch gebundenen Kontext oder Unterdomäne.

Diese Partitionierungsstrategie kann dazu beitragen, den Datenzugriffskonflikt in verschiedenen Teilen eines Systems zu reduzieren.

Entwerfen von Partitionen zur Skalierbarkeit

Es ist wichtig, Größe und Arbeitsauslastung für jede Partition zu berücksichtigen und sie auszugleichen, damit 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 beim Entwerfen von Partitionen zur Skalierbarkeit die folgenden Schritte aus:

1. Analysieren Sie die Anwendung, um die Datenzugriffsmuster zu verstehen, z. B. die Größe des von jeder Abfrage zurückgegebenen Resultsets, die Häufigkeit des Zugriffs, die inhärente Latenz und die serverseitigen Computeverarbeitungsanforderungen. In vielen Fällen benötigen einige hauptentitäten die meisten Verarbeitungsressourcen.
2. Verwenden Sie diese Analyse, um die aktuellen und zukünftigen Skalierbarkeitsziele zu ermitteln, z. B. Datengröße und Arbeitsauslastung. Verteilen Sie dann die Daten über die Partitionen, um das Skalierbarkeitsziel zu erfüllen. Für die horizontale Partitionierung ist die Auswahl des richtigen Shardschlüssels wichtig, um sicherzustellen, dass die Verteilung sogar erfolgt. Weitere Informationen finden Sie im Sharding-Muster.
3. Stellen Sie sicher, dass jede Partition über genügend Ressourcen verfügt, um die Skalierbarkeitsanforderungen im Hinblick auf Die Datengröße und den Durchsatz zu erfüllen. Je nach Datenspeicher gibt es möglicherweise einen Grenzwert für die Menge an Speicherplatz, Verarbeitungsleistung oder Netzwerkbandbreite pro Partition. Wenn die Anforderungen diese Grenzwerte wahrscheinlich überschreiten, müssen Sie möglicherweise Ihre Partitionierungsstrategie verfeinern oder Daten weiter austeilen, möglicherweise zwei oder mehr Strategien kombinieren.
4. Überwachen Sie das System, um zu überprüfen, ob Daten wie erwartet verteilt werden und dass die Partitionen die Last verarbeiten können. Die tatsächliche Verwendung stimmt nicht immer mit dem überein, was eine Analyse voraussagt. Wenn ja, kann es möglich sein, die Partitionen neu auszubalancieren oder andere Teile des Systems neu zu gestalten, um das erforderliche Gleichgewicht zu erzielen.

Einige Cloudumgebungen weisen Ressourcen in Bezug auf Infrastrukturgrenzen zu. Stellen Sie sicher, dass die Grenzwerte Ihrer ausgewählten Grenze genügend Platz für ein erwartetes Wachstum des Datenvolumens in Bezug auf Datenspeicher, Verarbeitungsleistung und Bandbreite bieten.

Wenn Sie beispielsweise Azure-Tabellenspeicher verwenden, gibt es eine Beschränkung auf das Volumen von Anforderungen, die von einer einzelnen Partition in einem bestimmten Zeitraum behandelt werden können. (Weitere Informationen finden Sie unter Azure Storage-Skalierbarkeit und Leistungsziele.) Eine ausgelastete Shard erfordert möglicherweise mehr Ressourcen als eine einzelne Partition kann verarbeitet werden. Wenn ja, muss der Shard möglicherweise neu partitioniert werden, 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 zusätzliche Speicherkonten erstellen und die Tabellen auf diese Konten verteilen.

Entwerfen von Partitionen für die Abfrageleistung

Die Abfrageleistung kann häufig mithilfe kleinerer Datensätze und durch Ausführen paralleler Abfragen erhöht werden. 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 zum Entwerfen und Konfigurieren einer Datenbank. Stellen Sie beispielsweise sicher, dass die erforderlichen Indizes vorhanden sind.

Führen Sie beim Entwerfen von Partitionen für die Abfrageleistung die folgenden Schritte aus:

1. Überprüfen Sie die Anwendungsanforderungen und -leistung:

   • Verwenden Sie geschäftliche Anforderungen, um die kritischen Abfragen zu ermitteln, die immer schnell ausgeführt werden müssen.
   • Überwachen Sie das System, um alle Abfragen zu identifizieren, die langsam ausgeführt werden.
   • Suchen Sie, welche Abfragen am häufigsten ausgeführt werden. Auch wenn eine einzelne Abfrage minimale Kosten aufweist, kann der kumulierte Ressourcenverbrauch erheblich sein.

2. Partitionieren Sie die Daten, die zu einer langsamen Leistung führen:

   • Beschränken Sie die Größe jeder Partition so, dass die Abfrageantwortzeit innerhalb des Ziels liegt.
   • Wenn Sie die horizontale Partitionierung verwenden, entwerfen Sie den Shardschlüssel so, dass die Anwendung ganz einfach die richtige Partition auswählen kann. Dadurch wird verhindert, dass die Abfrage jede Partition durchsucht werden muss.
   • Berücksichtigen Sie den Speicherort einer Partition. Wenn möglich, versuchen Sie, Daten in Partitionen zu speichern, die geografisch nah an den Anwendungen und Benutzern sind, die darauf zugreifen.

3. Wenn eine Entität Durchsatz- und Abfrageleistungsanforderungen aufweist, verwenden Sie die funktionale Partitionierung basierend auf dieser Entität. Wenn dies weiterhin nicht den Anforderungen entspricht, wenden Sie auch horizontale Partitionierung an. In den meisten Fällen reicht eine einzelne Partitionierungsstrategie aus, aber in einigen Fällen ist es effizienter, beide Strategien zu kombinieren.

4. Erwägen Sie, Abfragen parallel über Partitionen hinweg auszuführen, um die Leistung zu verbessern.

Entwerfen von Partitionen für die Verfügbarkeit

Partitionierungsdaten können die Verfügbarkeit von Anwendungen verbessern, indem sichergestellt wird, dass das gesamte Dataset keinen einzigen Fehlerpunkt darstellt und dass einzelne Teilmengen des Datasets unabhängig voneinander verwaltet werden können.

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

Wie wichtig die Daten für Geschäftsvorgänge sind. Ermitteln Sie, welche Daten wichtige Geschäftsinformationen sind, z. B. Transaktionen, und welche Daten weniger kritische Betriebsdaten sind, z. B. Protokolldateien.

• Erwägen Sie das Speichern wichtiger Daten in hoch verfügbaren Partitionen mit einem geeigneten Sicherungsplan.

• Richten Sie separate Verwaltungs- und Überwachungsverfahren für die verschiedenen Datasets ein.

• Platzieren Sie Daten mit derselben Kritischen Ebene in derselben Partition, damit sie in einer geeigneten Häufigkeit gesichert werden kann. Beispielsweise müssen Partitionen, die Transaktionsdaten enthalten, häufiger gesichert werden als Partitionen, die Protokollierungs- oder Ablaufverfolgungsinformationen enthalten.

Wie einzelne Partitionen verwaltet werden können. Das Entwerfen von Partitionen zur Unterstützung unabhängiger Verwaltung und Wartung bietet mehrere Vorteile. Beispiel:

• Wenn eine Partition fehlschlägt, kann sie unabhängig von Anwendungen wiederhergestellt werden, die auf Daten in anderen Partitionen zugreifen.

• 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 zu groß sind, um zu verhindern, dass geplante Wartungen während dieses Zeitraums abgeschlossen werden.

Gibt an, ob kritische Daten partitionsübergreifend repliziert werden sollen. Diese Strategie kann die Verfügbarkeit und Leistung verbessern, aber auch Konsistenzprobleme mit sich bringen. Es dauert Zeit, um Änderungen mit jedem Replikat zu synchronisieren. In diesem Zeitraum enthalten unterschiedliche Partitionen unterschiedliche Datenwerte.

Überlegungen zum Anwendungsentwurf

Die Partitionierung fügt dem Entwurf und der Entwicklung Ihres Systems Komplexität hinzu. Erwägen Sie die Partitionierung als grundlegender Bestandteil des Systemdesigns, auch wenn das System anfänglich nur eine einzelne Partition enthält. Wenn Sie die Partitionierung als Nachherein behandeln, ist dies schwieriger, da Sie bereits über ein Livesystem verfügen, um Folgendes zu verwalten:

• Die Datenzugriffslogik muss geändert werden.
• Große Mengen vorhandener Daten müssen möglicherweise migriert werden, um sie über Partitionen zu verteilen.
• Benutzer erwarten, dass das System während der Migration weiterhin verwendet werden kann.

In einigen Fällen gilt die Partitionierung nicht als wichtig, da das anfängliche Dataset klein ist und von einem einzelnen Server problemlos verarbeitet werden kann. Dies kann bei einigen Workloads der Fall sein, aber viele kommerzielle Systeme müssen sich erweitern, da die Anzahl der Benutzer steigt.

Darüber hinaus ist es nicht nur große Datenspeicher, die von der Partitionierung profitieren. Beispielsweise kann ein kleiner Datenspeicher von Hunderten gleichzeitiger Clients stark aufgerufen werden. Die Partitionierung der Daten in dieser Situation kann dazu beitragen, den Inhalt zu reduzieren und den Durchsatz zu verbessern.

Berücksichtigen Sie beim Entwerfen eines Datenpartitionierungsschemas die folgenden Punkte:

Minimieren Sie partitionsübergreifende Datenzugriffsvorgänge. Behalten Sie nach Möglichkeit Daten für die am häufigsten verwendeten Datenbankvorgänge in jeder Partition bei, um partitionsübergreifende Datenzugriffsvorgänge zu minimieren. Das Abfragen über Partitionen hinweg kann zeitaufwändiger sein als abfragen innerhalb einer einzelnen Partition, aber das Optimieren von Partitionen für eine Gruppe von Abfragen kann sich negativ auf andere Abfragengruppen auswirken. Wenn Sie eine Abfrage über Partitionen hinweg durchführen müssen, minimieren Sie die Abfragezeit, indem Sie parallele Abfragen ausführen und die Ergebnisse innerhalb der Anwendung aggregieren. (Dieser Ansatz ist in einigen Fällen möglicherweise nicht möglich, z. B. wenn das Ergebnis aus einer Abfrage in der nächsten Abfrage verwendet wird.)

Erwägen Sie, statische Referenzdaten zu replizieren. 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 werden, mit starkem Datenverkehr aus dem gesamten System. Es gibt jedoch zusätzliche Kosten für die Synchronisierung von Änderungen an den Referenzdaten.

Minimieren Sie partitionsübergreifende Verknüpfungen. Minimieren Sie nach Möglichkeit anforderungen an die referenzielle Integrität über vertikale und funktionale Partitionen hinweg. In diesen Schemas ist die Anwendung für die Aufrechterhaltung der referenziellen Integrität über Partitionen verantwortlich. Abfragen, die Daten über mehrere Partitionen hinweg verknüpfen, sind ineffizient, da die Anwendung in der Regel aufeinander folgende Abfragen basierend auf einem Schlüssel und dann einen Fremdschlüssel ausführen muss. Erwägen Sie stattdessen, die relevanten Daten zu replizieren oder zu normalisieren. Wenn partitionsübergreifende Verknüpfungen erforderlich sind, führen Sie parallele Abfragen über die Partitionen aus, und verknüpfen Sie die Daten innerhalb der Anwendung.

Übernehmen Sie letztendliche Konsistenz. Bewerten Sie, ob eine starke Konsistenz tatsächlich eine Anforderung ist. Ein gemeinsamer Ansatz in verteilten Systemen besteht darin, letztendliche Konsistenz zu implementieren. Die Daten in jeder Partition werden separat aktualisiert, und die Anwendungslogik stellt sicher, dass die Updates alle erfolgreich abgeschlossen werden. Außerdem werden die Inkonsistenzen behandelt, die sich aus dem Abfragen von Daten ergeben können, während ein schließlich konsistenter Vorgang ausgeführt wird.

Überlegen Sie, wie Abfragen die richtige Partition finden. Wenn eine Abfrage alle Partitionen durchsuchen muss, um die erforderlichen Daten zu finden, wirkt sich dies erheblich auf die Leistung aus, auch wenn mehrere parallele Abfragen ausgeführt werden. Mit vertikaler und funktionaler Partitionierung können Abfragen die Partition natürlich angeben. Die horizontale Partitionierung kann das Auffinden eines Elements erschweren, da jeder Shard dasselbe Schema aufweist. Eine typische Lösung zum Verwalten einer Karte, die verwendet wird, um den Speicherort für bestimmte Elemente nachzuschlagen. Diese Zuordnung kann in der Shardinglogik der Anwendung implementiert oder vom Datenspeicher verwaltet werden, wenn sie transparente sharding unterstützt.

Erwägen Sie in regelmäßigen Abständen die Rebalancing-Shards. Bei horizontaler Partitionierung können Rebalancing-Shards dazu beitragen, die Daten gleichmäßig nach Größe und Workload zu verteilen, um Hotspots zu minimieren, die Abfrageleistung zu maximieren und physische Speichereinschränkungen zu umgehen. Dies ist jedoch eine komplexe Aufgabe, die häufig die Verwendung eines benutzerdefinierten Tools oder Prozesses erfordert.

Replizieren sie Partitionen. Wenn Sie jede Partition replizieren, bietet sie zusätzlichen Schutz vor Fehlern. Wenn ein einzelnes Replikat fehlschlägt, können Abfragen auf eine Arbeitskopie gerichtet werden.

Wenn Sie die physischen Grenzen einer Partitionierungsstrategie erreichen, müssen Sie die Skalierbarkeit möglicherweise auf eine andere Ebene erweitern. Wenn sich die Partitionierung beispielsweise auf Datenbankebene befindet, müssen Sie möglicherweise Partitionen in mehreren Datenbanken suchen oder replizieren. Wenn die Partitionierung bereits auf Datenbankebene erfolgt und physische Einschränkungen ein Problem sind, bedeutet dies möglicherweise, dass Sie Partitionen in mehreren Hostingkonten suchen oder replizieren müssen.

Vermeiden Sie Transaktionen, die auf Daten in mehreren Partitionen zugreifen. Einige Datenspeicher implementieren Transaktionskonsistenz und Integrität für Vorgänge, die Daten ändern, jedoch nur, wenn sich die Daten in einer einzelnen Partition befinden. Wenn Sie transaktionsübergreifende Unterstützung für mehrere Partitionen benötigen, müssen Sie dies wahrscheinlich als Teil Der Anwendungslogik implementieren, da die meisten Partitionierungssysteme keine systemeigene Unterstützung bieten.

Für alle Datenspeicher sind einige Betriebsverwaltungs- und Überwachungsaktivitäten erforderlich. Die Aufgaben können vom Laden von Daten, sichern und Wiederherstellen von Daten, Neuorganisieren von Daten und sicherstellen, dass das System ordnungsgemäß und effizient ausgeführt wird.

Berücksichtigen Sie die folgenden Faktoren, die sich auf das operative Management auswirken:

• Implementieren geeigneter Verwaltungs- und Betriebsaufgaben, wenn die Daten partitioniert werden. Zu diesen Aufgaben gehören u. U. Sicherung und Wiederherstellung, Archivierungsdaten, Überwachung des Systems und andere verwaltungstechnische Aufgaben. Die Aufrechterhaltung der logischen Konsistenz bei Sicherungs- und Wiederherstellungsvorgängen kann beispielsweise eine Herausforderung darstellen.

• Laden der Daten in mehrere Partitionen und Hinzufügen neuer Daten, 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.

• So archivieren und löschen Sie die Daten regelmäßig. Um das übermäßige Wachstum von Partitionen zu verhindern, müssen Sie Daten regelmäßig archivieren und löschen (z. B. monatlich). Es kann erforderlich sein, die Daten so zu transformieren, dass sie einem anderen Archivschema entsprechen.

• So finden Sie Probleme mit der Datenintegrität. Erwägen Sie, einen regelmäßigen Prozess auszuführen, um Probleme mit der Datenintegrität zu finden, z. B. Daten in einer Partition, die auf fehlende Informationen in einer anderen verweist. Der Prozess kann entweder versuchen, diese Probleme automatisch zu beheben oder einen Bericht zur manuellen Überprüfung zu generieren.

Neubalancieren von Partitionen

Wenn ein System reift, müssen Sie möglicherweise das Partitionierungsschema anpassen. Beispielsweise können einzelne Partitionen damit beginnen, ein unverhältnismäßiges Datenverkehrsvolumen zu erhalten und heiß zu 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 einige Partitionen an Kapazitätsgrenzen herangehen.

Einige Datenspeicher, z. B. Azure Cosmos DB, können Partitionen automatisch neu ausgleichen. In anderen Fällen ist die Rebalancing eine verwaltungstechnische Aufgabe, die aus zwei Phasen besteht:

1. Bestimmen Sie eine neue Partitionierungsstrategie.

   • Welche Partitionen müssen geteilt (oder möglicherweise kombiniert) werden?
   • Was ist der neue Partitionsschlüssel?

2. Migrieren Sie Daten aus dem alten Partitionierungsschema in den neuen Satz von Partitionen.

Je nach Datenspeicher können Sie möglicherweise Daten zwischen Partitionen migrieren, während sie verwendet werden. Dies wird als Onlinemigration bezeichnet. Wenn dies nicht möglich ist, müssen Sie möglicherweise Partitionen nicht verfügbar machen, während die Daten verschoben werden (Offlinemigration).

Offlinemigration

Die Offlinemigration ist in der Regel einfacher, da dadurch die Wahrscheinlichkeit reduziert wird, dass Konflikte auftreten. Konzeptionell funktioniert die Offlinemigration wie folgt:

1. Markieren Sie die Partition offline.
2. Teilen Sie die Daten, und verschieben Sie die Daten in die neuen Partitionen.
3. Überprüfen Sie die Daten.
4. Bringen Sie die neuen Partitionen online.
5. Entfernen Sie die alte Partition.

Optional können Sie eine Partition in Schritt 1 als schreibgeschützt markieren, sodass Anwendungen die Daten während des Verschiebens weiterhin lesen können.

Onlinemigration

Die Onlinemigration ist komplexer, aber weniger störend. Der Prozess ähnelt der Offlinemigration, mit der Ausnahme, dass die ursprüngliche Partition nicht offline markiert ist. Abhängig von der Granularität des Migrationsprozesses (z. B. Element nach Element und Shard durch Shard), muss der Datenzugriffscode in den Clientanwendungen möglicherweise das Lesen und Schreiben von Daten verarbeiten, die an zwei Speicherorten gespeichert sind, die ursprüngliche Partition und die neue Partition.

Nächste Schritte

• Erfahren Sie mehr über Partitionierungsstrategien für bestimmte Azure-Dienste. Weitere Informationen finden Sie unter Datenpartitionierungsstrategien.
• Skalierbarkeits- und Leistungsziele für Azure-Speicher

Verwandte Ressourcen

• Auswählen des richtigen Datenspeichers

Die folgenden Entwurfsmuster sind möglicherweise für Ihr Szenario relevant:

• Das Shardingmuster beschreibt einige gängige Strategien für Sharding-Daten.

• Das Indextabellenmuster zeigt, wie sekundäre Indizes über Daten erstellt werden. Eine Anwendung kann mit diesem Ansatz schnell Daten abrufen, indem Abfragen verwendet werden, die nicht auf den Primärschlüssel einer Auflistung verweisen.

• Das materialisierte Ansichtsmuster beschreibt, wie vorab aufgefüllte Ansichten generiert werden, die Daten zusammenfassen, um schnelle Abfragevorgänge zu unterstützen. Dieser Ansatz kann in einem partitionierten Datenspeicher nützlich sein, wenn die Partitionen, die die zusammengefassten Daten enthalten, auf mehrere Standorte verteilt werden.

In vielen umfangreichen Lösungen werden Daten in Partitionen unterteilt, die separat verwaltet und darauf zugegriffen werden können. Partitionierung kann die Skalierbarkeit verbessern, Konflikte reduzieren und die Leistung optimieren. Sie kann auch einen Mechanismus für das Unterteilen von Daten nach Verwendungsmuster bereitstellen. Beispielsweise können Sie ältere Daten in kostengünstigeren Datenspeichern archivieren.

Die Partitionierungsstrategie muss jedoch sorgfältig ausgewählt werden, um die Vorteile zu maximieren und gleichzeitig nachteilige Auswirkungen zu minimieren.

Hinweis

In diesem Artikel bedeutet die Begriffpartitionierung den Prozess der physischen Aufteilung von Daten in separate Datenspeicher. Sie ist nicht identisch mit der SQL Server-Tabellenpartitionierung.

Warum Partitionsdaten?

• Verbessern Sie die Skalierbarkeit. Wenn Sie ein einzelnes Datenbanksystem skalieren, erreicht es schließlich ein physisches Hardwarelimit. Wenn Sie Daten über mehrere Partitionen aufteilen, können Sie jedes auf einem separaten Server gehostete System nahezu unbegrenzt skalieren.

• Verbessern der Leistung: Datenzugriffsvorgänge auf jeder Partition erfolgen über ein kleineres Datenvolumen. Richtig erledigt, kann die Partitionierung Ihr System effizienter gestalten. Vorgänge, die sich auf mehrere Partitionen auswirken, können parallel ausgeführt werden.

• Verbessern Sie die 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.

• Bieten Sie die betriebstechnische Flexibilität. Partitionierung bietet viele Möglichkeiten zum Optimieren von Vorgängen, zur Maximierung der Verwaltungseffizienz und zur Minimierung der Kosten. Sie können z. B. verschiedene Strategien für Verwaltung, Überwachung, Sicherung und Wiederherstellung sowie andere administrative Aufgaben basierend auf der Wichtigkeit der Daten in jeder Partition definieren.

• Ordnen Sie den Datenspeicher dem Verwendungsmuster zu. Mithilfe der Partitionierung kann jede Partition auf einer anderen Art von Datenspeicher bereitgestellt werden, basierend auf Kosten und den integrierten Features, die der Datenspeicher bietet. Beispielsweise können große Binärdaten im BLOB-Speicher gespeichert werden, während strukturiertere Daten in einer Dokumentdatenbank gespeichert werden können. Weitere Informationen finden Sie unter Auswählen des richtigen Datenspeichers.

• Verbessern Sie die Verfügbarkeit. Durch das Trennen von Daten über mehrere Server wird ein einzelner Fehlerpunkt vermieden. Wenn eine Instanz fehlschlägt, sind nur die Daten in dieser Partition nicht verfügbar. Vorgänge auf anderen Partitionen können fortgesetzt werden. Bei verwalteten Plattform-as-a-Service-Datenspeichern (PaaS) ist diese Überlegung weniger relevant, da diese Dienste mit integrierter Redundanz konzipiert sind.

Entwerfen von Partitionen

Es gibt drei typische Strategien für die Partitionierung von Daten:

• Horizontale Partitionierung (häufig als Sharding bezeichnet). In dieser Strategie ist jede Partition ein separater Datenspeicher, aber alle Partitionen haben dasselbe Schema. Jede Partition wird als Shard bezeichnet und enthält eine bestimmte Teilmenge der Daten, z. B. alle Bestellungen für eine bestimmte Gruppe von Kunden.

• Vertikale Partitionierung. In dieser Strategie enthält jede Partition eine Teilmenge der Felder für Elemente im Datenspeicher. Die Felder werden nach ihrem Einsatzmuster unterteilt. Häufig verwendete Felder können beispielsweise in einer vertikalen Partition und weniger häufig auf Felder in einem anderen zugegriffen werden.

• Funktionale Partitionierung. In dieser Strategie werden Daten so aggregiert, wie sie von jedem gebundenen Kontext im System verwendet werden. Beispielsweise kann ein E-Commerce-System Rechnungsdaten in einer Partition und Produktbestandsdaten in einer anderen speichern.

Diese Strategien können kombiniert werden, und es wird empfohlen, sie beim Entwerfen eines Partitionierungsschemas zu berücksichtigen. Beispielsweise können Sie Daten in Shards unterteilen und dann die vertikale Partitionierung verwenden, um die Daten in den einzelnen Shards weiter zu unterteilen.

Horizontale Partitionierung (Sharding)

Abbildung 1 zeigt horizontale Partitionierung oder Sharding. In diesem Beispiel werden Produktbestandsdaten basierend auf dem Product Key in Shards unterteilt. Jeder Shard enthält die Daten für einen zusammenhängenden Bereich von Shardschlüsseln (A-G und H-Z), organisiert alphabetisch. Durch Sharding wird die Last über mehr Computer verteilt, wodurch die Konflikte reduziert und die Leistung verbessert wird.

Abbildung 1: Horizontal partitionierende Daten (Sharding) basierend auf einem Partitionsschlüssel.

Der wichtigste Faktor ist die Wahl eines Shardingschlüssels. Es kann schwierig sein, den Schlüssel zu ändern, nachdem das System in Betrieb ist. Der Schlüssel muss sicherstellen, dass Daten partitioniert werden, um die Workload so gleichmäßig wie möglich über dieHards hinweg zu verteilen.

Die Scherben müssen nicht dieselbe Größe aufweisen. Es ist wichtiger, die Anzahl der Anforderungen abzuwägen. Einige Shards sind möglicherweise sehr groß, aber jedes Element verfügt über eine geringe Anzahl von Zugriffsvorgängen. Andere Scherben sind möglicherweise kleiner, aber auf jedes Element wird viel 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 "hot"-Partitionen, die sich auf die Leistung und Verfügbarkeit auswirken können. Die Verwendung des ersten Buchstabens eines Kundennamens verursacht beispielsweise eine unausgewogene Verteilung, da einige Buchstaben häufiger vorkommen. Verwenden Sie stattdessen einen Hash eines Kundenbezeichners, um Daten gleichmäßiger über Partitionen zu verteilen.

Wählen Sie einen Sharding-Schlüssel aus, der alle zukünftigen Anforderungen minimiert, um große Shards aufzuteilen, kleine Shards in größere Partitionen zusammenzugliedern oder das Schema zu ändern. Diese Vorgänge können sehr zeitaufwändig sein und erfordern möglicherweise eine oder mehrere Shards offline, während sie ausgeführt werden.

Wenn Shards repliziert werden, kann es möglich sein, einige der Replikate online zu halten, während andere geteilt, zusammengeführt oder neu konfiguriert werden. Möglicherweise muss das System 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 gekennzeichnet werden, um Dateninkonsistenzen zu verhindern.

Weitere Informationen zur horizontalen Partitionierung 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 von Elementen verbunden sind, auf die häufig zugegriffen wird. Abbildung 2 zeigt ein Beispiel für vertikale Partitionierung. In diesem Beispiel werden 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: die Lageranzahl und das Datum der letzten Bestellung.

Abbildung 2: Vertikale Partitionierung von Daten anhand des Verwendungsmusters.

In diesem Beispiel fragt die Anwendung regelmäßig den Produktnamen, die Beschreibung und den Preis ab, wenn die Produktdetails den Kunden angezeigt werden. Die Lageranzahl und das Datum der letzten Reihenfolge werden in einer separaten Partition gespeichert, da diese beiden Elemente häufig zusammen verwendet werden.

Weitere Vorteile der vertikalen Partitionierung:

• Relativ langsame Daten (Produktname, Beschreibung und Preis) können von den dynamischeren Daten (Lagerstand und datum der letzten Bestellung) getrennt werden. Langsam verschiebende Daten sind ein guter Kandidat für eine Anwendung, die im Arbeitsspeicher zwischengespeichert werden kann.

• Vertrauliche Daten können in einer separaten Partition mit zusätzlichen Sicherheitskontrollen gespeichert werden.

• Die vertikale Partitionierung kann die Anzahl gleichzeitiger Zugriffe verringern, die benötigt werden.

Die vertikale Partitionierung erfolgt auf Entitätsebene innerhalb eines Datenspeichers, wobei eine Entität teilweise normalisiert wird, um sie von einem breiten Element in eine Gruppe schmaler Elemente aufzuteilen. Es eignet sich ideal für spaltenorientierte Datenspeicher wie HBase und Cassandra. Wenn die Daten in einer Sammlung von Spalten nicht geändert werden können, können Sie auch die Verwendung von Spaltenspeichern in SQL Server in Betracht ziehen.

Funktionale Partitionierung

Wenn es möglich ist, einen gebundenen Kontext für jeden einzelnen Geschäftsbereich in einer Anwendung zu identifizieren, ist die funktionale Partitionierung eine Möglichkeit, isolations- und Datenzugriffsleistung zu verbessern. Eine weitere häufige Verwendung für die funktionale Partitionierung besteht darin, Lese-/Schreibdaten von schreibgeschützten Daten zu trennen. Abbildung 3 zeigt eine Übersicht über die funktionale Partitionierung, bei der Bestandsdaten von Kundendaten getrennt sind.

Abbildung 3: Funktionale Partitionierung von Daten durch gebundenen Kontext oder Unterdomäne.

Diese Partitionierungsstrategie kann dazu beitragen, den Datenzugriffskonflikt in verschiedenen Teilen eines Systems zu reduzieren.

Entwerfen von Partitionen zur Skalierbarkeit

Es ist wichtig, Größe und Arbeitsauslastung für jede Partition zu berücksichtigen und sie auszugleichen, damit 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 beim Entwerfen von Partitionen zur Skalierbarkeit die folgenden Schritte aus:

1. Analysieren Sie die Anwendung, um die Datenzugriffsmuster zu verstehen, z. B. die Größe des von jeder Abfrage zurückgegebenen Resultsets, die Häufigkeit des Zugriffs, die inhärente Latenz und die serverseitigen Computeverarbeitungsanforderungen. In vielen Fällen benötigen einige hauptentitäten die meisten Verarbeitungsressourcen.
2. Verwenden Sie diese Analyse, um die aktuellen und zukünftigen Skalierbarkeitsziele zu ermitteln, z. B. Datengröße und Arbeitsauslastung. Verteilen Sie dann die Daten über die Partitionen, um das Skalierbarkeitsziel zu erfüllen. Für die horizontale Partitionierung ist die Auswahl des richtigen Shardschlüssels wichtig, um sicherzustellen, dass die Verteilung sogar erfolgt. Weitere Informationen finden Sie im Sharding-Muster.
3. Stellen Sie sicher, dass jede Partition über genügend Ressourcen verfügt, um die Skalierbarkeitsanforderungen im Hinblick auf Die Datengröße und den Durchsatz zu erfüllen. Je nach Datenspeicher gibt es möglicherweise einen Grenzwert für die Menge an Speicherplatz, Verarbeitungsleistung oder Netzwerkbandbreite pro Partition. Wenn die Anforderungen diese Grenzwerte wahrscheinlich überschreiten, müssen Sie möglicherweise Ihre Partitionierungsstrategie verfeinern oder Daten weiter austeilen, möglicherweise zwei oder mehr Strategien kombinieren.
4. Überwachen Sie das System, um zu überprüfen, ob Daten wie erwartet verteilt werden und dass die Partitionen die Last verarbeiten können. Die tatsächliche Verwendung stimmt nicht immer mit dem überein, was eine Analyse voraussagt. Wenn ja, kann es möglich sein, die Partitionen neu auszubalancieren oder andere Teile des Systems neu zu gestalten, um das erforderliche Gleichgewicht zu erzielen.

Einige Cloudumgebungen weisen Ressourcen in Bezug auf Infrastrukturgrenzen zu. Stellen Sie sicher, dass die Grenzwerte Ihrer ausgewählten Grenze genügend Platz für ein erwartetes Wachstum des Datenvolumens in Bezug auf Datenspeicher, Verarbeitungsleistung und Bandbreite bieten.

Wenn Sie beispielsweise Azure-Tabellenspeicher verwenden, gibt es eine Beschränkung auf das Volumen von Anforderungen, die von einer einzelnen Partition in einem bestimmten Zeitraum behandelt werden können. (Weitere Informationen finden Sie unter Azure Storage-Skalierbarkeit und Leistungsziele.) Eine ausgelastete Shard erfordert möglicherweise mehr Ressourcen als eine einzelne Partition kann verarbeitet werden. Wenn ja, muss der Shard möglicherweise neu partitioniert werden, 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 zusätzliche Speicherkonten erstellen und die Tabellen auf diese Konten verteilen.

Entwerfen von Partitionen für die Abfrageleistung

Die Abfrageleistung kann häufig mithilfe kleinerer Datensätze und durch Ausführen paralleler Abfragen erhöht werden. 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 zum Entwerfen und Konfigurieren einer Datenbank. Stellen Sie beispielsweise sicher, dass die erforderlichen Indizes vorhanden sind.

Führen Sie beim Entwerfen von Partitionen für die Abfrageleistung die folgenden Schritte aus:

1. Überprüfen Sie die Anwendungsanforderungen und -leistung:

   • Verwenden Sie geschäftliche Anforderungen, um die kritischen Abfragen zu ermitteln, die immer schnell ausgeführt werden müssen.
   • Überwachen Sie das System, um alle Abfragen zu identifizieren, die langsam ausgeführt werden.
   • Suchen Sie, welche Abfragen am häufigsten ausgeführt werden. Auch wenn eine einzelne Abfrage minimale Kosten aufweist, kann der kumulierte Ressourcenverbrauch erheblich sein.

2. Partitionieren Sie die Daten, die zu einer langsamen Leistung führen:

   • Beschränken Sie die Größe jeder Partition so, dass die Abfrageantwortzeit innerhalb des Ziels liegt.
   • Wenn Sie die horizontale Partitionierung verwenden, entwerfen Sie den Shardschlüssel so, dass die Anwendung ganz einfach die richtige Partition auswählen kann. Dadurch wird verhindert, dass die Abfrage jede Partition durchsucht werden muss.
   • Berücksichtigen Sie den Speicherort einer Partition. Wenn möglich, versuchen Sie, Daten in Partitionen zu speichern, die geografisch nah an den Anwendungen und Benutzern sind, die darauf zugreifen.

3. Wenn eine Entität Durchsatz- und Abfrageleistungsanforderungen aufweist, verwenden Sie die funktionale Partitionierung basierend auf dieser Entität. Wenn dies weiterhin nicht den Anforderungen entspricht, wenden Sie auch horizontale Partitionierung an. In den meisten Fällen reicht eine einzelne Partitionierungsstrategie aus, aber in einigen Fällen ist es effizienter, beide Strategien zu kombinieren.

4. Erwägen Sie, Abfragen parallel über Partitionen hinweg auszuführen, um die Leistung zu verbessern.

Entwerfen von Partitionen für die Verfügbarkeit

Partitionierungsdaten können die Verfügbarkeit von Anwendungen verbessern, indem sichergestellt wird, dass das gesamte Dataset keinen einzigen Fehlerpunkt darstellt und dass einzelne Teilmengen des Datasets unabhängig voneinander verwaltet werden können.

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

Wie wichtig die Daten für Geschäftsvorgänge sind. Ermitteln Sie, welche Daten wichtige Geschäftsinformationen sind, z. B. Transaktionen, und welche Daten weniger kritische Betriebsdaten sind, z. B. Protokolldateien.

• Erwägen Sie das Speichern wichtiger Daten in hoch verfügbaren Partitionen mit einem geeigneten Sicherungsplan.

• Richten Sie separate Verwaltungs- und Überwachungsverfahren für die verschiedenen Datasets ein.

• Platzieren Sie Daten mit derselben Kritischen Ebene in derselben Partition, damit sie in einer geeigneten Häufigkeit gesichert werden kann. Beispielsweise müssen Partitionen, die Transaktionsdaten enthalten, häufiger gesichert werden als Partitionen, die Protokollierungs- oder Ablaufverfolgungsinformationen enthalten.

Wie einzelne Partitionen verwaltet werden können. Das Entwerfen von Partitionen zur Unterstützung unabhängiger Verwaltung und Wartung bietet mehrere Vorteile. Beispiel:

• Wenn eine Partition fehlschlägt, kann sie unabhängig von Anwendungen wiederhergestellt werden, die auf Daten in anderen Partitionen zugreifen.

• 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 zu groß sind, um zu verhindern, dass geplante Wartungen während dieses Zeitraums abgeschlossen werden.

Gibt an, ob kritische Daten partitionsübergreifend repliziert werden sollen. Diese Strategie kann die Verfügbarkeit und Leistung verbessern, aber auch Konsistenzprobleme mit sich bringen. Es dauert Zeit, um Änderungen mit jedem Replikat zu synchronisieren. In diesem Zeitraum enthalten unterschiedliche Partitionen unterschiedliche Datenwerte.

Überlegungen zum Anwendungsentwurf

Die Partitionierung fügt dem Entwurf und der Entwicklung Ihres Systems Komplexität hinzu. Erwägen Sie die Partitionierung als grundlegender Bestandteil des Systemdesigns, auch wenn das System anfänglich nur eine einzelne Partition enthält. Wenn Sie die Partitionierung als Nachherein behandeln, ist dies schwieriger, da Sie bereits über ein Livesystem verfügen, um Folgendes zu verwalten:

• Die Datenzugriffslogik muss geändert werden.
• Große Mengen vorhandener Daten müssen möglicherweise migriert werden, um sie über Partitionen zu verteilen.
• Benutzer erwarten, dass das System während der Migration weiterhin verwendet werden kann.

In einigen Fällen gilt die Partitionierung nicht als wichtig, da das anfängliche Dataset klein ist und von einem einzelnen Server problemlos verarbeitet werden kann. Dies kann bei einigen Workloads der Fall sein, aber viele kommerzielle Systeme müssen sich erweitern, da die Anzahl der Benutzer steigt.

Darüber hinaus ist es nicht nur große Datenspeicher, die von der Partitionierung profitieren. Beispielsweise kann ein kleiner Datenspeicher von Hunderten gleichzeitiger Clients stark aufgerufen werden. Die Partitionierung der Daten in dieser Situation kann dazu beitragen, den Inhalt zu reduzieren und den Durchsatz zu verbessern.

Berücksichtigen Sie beim Entwerfen eines Datenpartitionierungsschemas die folgenden Punkte:

Minimieren Sie partitionsübergreifende Datenzugriffsvorgänge. Behalten Sie nach Möglichkeit Daten für die am häufigsten verwendeten Datenbankvorgänge in jeder Partition bei, um partitionsübergreifende Datenzugriffsvorgänge zu minimieren. Das Abfragen über Partitionen hinweg kann zeitaufwändiger sein als abfragen innerhalb einer einzelnen Partition, aber das Optimieren von Partitionen für eine Gruppe von Abfragen kann sich negativ auf andere Abfragengruppen auswirken. Wenn Sie eine Abfrage über Partitionen hinweg durchführen müssen, minimieren Sie die Abfragezeit, indem Sie parallele Abfragen ausführen und die Ergebnisse innerhalb der Anwendung aggregieren. (Dieser Ansatz ist in einigen Fällen möglicherweise nicht möglich, z. B. wenn das Ergebnis aus einer Abfrage in der nächsten Abfrage verwendet wird.)

Erwägen Sie, statische Referenzdaten zu replizieren. 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 werden, mit starkem Datenverkehr aus dem gesamten System. Es gibt jedoch zusätzliche Kosten für die Synchronisierung von Änderungen an den Referenzdaten.

Minimieren Sie partitionsübergreifende Verknüpfungen. Minimieren Sie nach Möglichkeit anforderungen an die referenzielle Integrität über vertikale und funktionale Partitionen hinweg. In diesen Schemas ist die Anwendung für die Aufrechterhaltung der referenziellen Integrität über Partitionen verantwortlich. Abfragen, die Daten über mehrere Partitionen hinweg verknüpfen, sind ineffizient, da die Anwendung in der Regel aufeinander folgende Abfragen basierend auf einem Schlüssel und dann einen Fremdschlüssel ausführen muss. Erwägen Sie stattdessen, die relevanten Daten zu replizieren oder zu normalisieren. Wenn partitionsübergreifende Verknüpfungen erforderlich sind, führen Sie parallele Abfragen über die Partitionen aus, und verknüpfen Sie die Daten innerhalb der Anwendung.

Übernehmen Sie letztendliche Konsistenz. Bewerten Sie, ob eine starke Konsistenz tatsächlich eine Anforderung ist. Ein gemeinsamer Ansatz in verteilten Systemen besteht darin, letztendliche Konsistenz zu implementieren. Die Daten in jeder Partition werden separat aktualisiert, und die Anwendungslogik stellt sicher, dass die Updates alle erfolgreich abgeschlossen werden. Außerdem werden die Inkonsistenzen behandelt, die sich aus dem Abfragen von Daten ergeben können, während ein schließlich konsistenter Vorgang ausgeführt wird.

Überlegen Sie, wie Abfragen die richtige Partition finden. Wenn eine Abfrage alle Partitionen durchsuchen muss, um die erforderlichen Daten zu finden, wirkt sich dies erheblich auf die Leistung aus, auch wenn mehrere parallele Abfragen ausgeführt werden. Mit vertikaler und funktionaler Partitionierung können Abfragen die Partition natürlich angeben. Die horizontale Partitionierung kann das Auffinden eines Elements erschweren, da jeder Shard dasselbe Schema aufweist. Eine typische Lösung zum Verwalten einer Karte, die verwendet wird, um den Speicherort für bestimmte Elemente nachzuschlagen. Diese Zuordnung kann in der Shardinglogik der Anwendung implementiert oder vom Datenspeicher verwaltet werden, wenn sie transparente sharding unterstützt.

Erwägen Sie in regelmäßigen Abständen die Rebalancing-Shards. Bei horizontaler Partitionierung können Rebalancing-Shards dazu beitragen, die Daten gleichmäßig nach Größe und Workload zu verteilen, um Hotspots zu minimieren, die Abfrageleistung zu maximieren und physische Speichereinschränkungen zu umgehen. Dies ist jedoch eine komplexe Aufgabe, die häufig die Verwendung eines benutzerdefinierten Tools oder Prozesses erfordert.

Replizieren sie Partitionen. Wenn Sie jede Partition replizieren, bietet sie zusätzlichen Schutz vor Fehlern. Wenn ein einzelnes Replikat fehlschlägt, können Abfragen auf eine Arbeitskopie gerichtet werden.

Wenn Sie die physischen Grenzen einer Partitionierungsstrategie erreichen, müssen Sie die Skalierbarkeit möglicherweise auf eine andere Ebene erweitern. Wenn sich die Partitionierung beispielsweise auf Datenbankebene befindet, müssen Sie möglicherweise Partitionen in mehreren Datenbanken suchen oder replizieren. Wenn die Partitionierung bereits auf Datenbankebene erfolgt und physische Einschränkungen ein Problem sind, bedeutet dies möglicherweise, dass Sie Partitionen in mehreren Hostingkonten suchen oder replizieren müssen.

Vermeiden Sie Transaktionen, die auf Daten in mehreren Partitionen zugreifen. Einige Datenspeicher implementieren Transaktionskonsistenz und Integrität für Vorgänge, die Daten ändern, jedoch nur, wenn sich die Daten in einer einzelnen Partition befinden. Wenn Sie transaktionsübergreifende Unterstützung für mehrere Partitionen benötigen, müssen Sie dies wahrscheinlich als Teil Der Anwendungslogik implementieren, da die meisten Partitionierungssysteme keine systemeigene Unterstützung bieten.

Für alle Datenspeicher sind einige Betriebsverwaltungs- und Überwachungsaktivitäten erforderlich. Die Aufgaben können vom Laden von Daten, sichern und Wiederherstellen von Daten, Neuorganisieren von Daten und sicherstellen, dass das System ordnungsgemäß und effizient ausgeführt wird.

Berücksichtigen Sie die folgenden Faktoren, die sich auf das operative Management auswirken:

• Implementieren geeigneter Verwaltungs- und Betriebsaufgaben, wenn die Daten partitioniert werden. Zu diesen Aufgaben gehören u. U. Sicherung und Wiederherstellung, Archivierungsdaten, Überwachung des Systems und andere verwaltungstechnische Aufgaben. Die Aufrechterhaltung der logischen Konsistenz bei Sicherungs- und Wiederherstellungsvorgängen kann beispielsweise eine Herausforderung darstellen.

• Laden der Daten in mehrere Partitionen und Hinzufügen neuer Daten, 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.

• So archivieren und löschen Sie die Daten regelmäßig. Um das übermäßige Wachstum von Partitionen zu verhindern, müssen Sie Daten regelmäßig archivieren und löschen (z. B. monatlich). Es kann erforderlich sein, die Daten so zu transformieren, dass sie einem anderen Archivschema entsprechen.

• So finden Sie Probleme mit der Datenintegrität. Erwägen Sie, einen regelmäßigen Prozess auszuführen, um Probleme mit der Datenintegrität zu finden, z. B. Daten in einer Partition, die auf fehlende Informationen in einer anderen verweist. Der Prozess kann entweder versuchen, diese Probleme automatisch zu beheben oder einen Bericht zur manuellen Überprüfung zu generieren.

Neubalancieren von Partitionen

Wenn ein System reift, müssen Sie möglicherweise das Partitionierungsschema anpassen. Beispielsweise können einzelne Partitionen damit beginnen, ein unverhältnismäßiges Datenverkehrsvolumen zu erhalten und heiß zu 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 einige Partitionen an Kapazitätsgrenzen herangehen.

Einige Datenspeicher, z. B. Azure Cosmos DB, können Partitionen automatisch neu ausgleichen. In anderen Fällen ist die Rebalancing eine verwaltungstechnische Aufgabe, die aus zwei Phasen besteht:

1. Bestimmen Sie eine neue Partitionierungsstrategie.

   • Welche Partitionen müssen geteilt (oder möglicherweise kombiniert) werden?
   • Was ist der neue Partitionsschlüssel?

2. Migrieren Sie Daten aus dem alten Partitionierungsschema in den neuen Satz von Partitionen.

Je nach Datenspeicher können Sie möglicherweise Daten zwischen Partitionen migrieren, während sie verwendet werden. Dies wird als Onlinemigration bezeichnet. Wenn dies nicht möglich ist, müssen Sie möglicherweise Partitionen nicht verfügbar machen, während die Daten verschoben werden (Offlinemigration).

Offlinemigration

Die Offlinemigration ist in der Regel einfacher, da dadurch die Wahrscheinlichkeit reduziert wird, dass Konflikte auftreten. Konzeptionell funktioniert die Offlinemigration wie folgt:

1. Markieren Sie die Partition offline.
2. Teilen Sie die Daten, und verschieben Sie die Daten in die neuen Partitionen.
3. Überprüfen Sie die Daten.
4. Bringen Sie die neuen Partitionen online.
5. Entfernen Sie die alte Partition.

Optional können Sie eine Partition in Schritt 1 als schreibgeschützt markieren, sodass Anwendungen die Daten während des Verschiebens weiterhin lesen können.

Onlinemigration

Die Onlinemigration ist komplexer, aber weniger störend. Der Prozess ähnelt der Offlinemigration, mit der Ausnahme, dass die ursprüngliche Partition nicht offline markiert ist. Abhängig von der Granularität des Migrationsprozesses (z. B. Element nach Element und Shard durch Shard), muss der Datenzugriffscode in den Clientanwendungen möglicherweise das Lesen und Schreiben von Daten verarbeiten, die an zwei Speicherorten gespeichert sind, die ursprüngliche Partition und die neue Partition.

Nächste Schritte

• Erfahren Sie mehr über Partitionierungsstrategien für bestimmte Azure-Dienste. Weitere Informationen finden Sie unter Datenpartitionierungsstrategien.
• Skalierbarkeits- und Leistungsziele für Azure-Speicher

Verwandte Ressourcen

• Auswählen des richtigen Datenspeichers

Die folgenden Entwurfsmuster sind möglicherweise für Ihr Szenario relevant:

• Das Shardingmuster beschreibt einige gängige Strategien für Sharding-Daten.

• Das Indextabellenmuster zeigt, wie sekundäre Indizes über Daten erstellt werden. Eine Anwendung kann mit diesem Ansatz schnell Daten abrufen, indem Abfragen verwendet werden, die nicht auf den Primärschlüssel einer Auflistung verweisen.

• Das materialisierte Ansichtsmuster beschreibt, wie vorab aufgefüllte Ansichten generiert werden, die Daten zusammenfassen, um schnelle Abfragevorgänge zu unterstützen. Dieser Ansatz kann in einem partitionierten Datenspeicher nützlich sein, wenn die Partitionen, die die zusammengefassten Daten enthalten, auf mehrere Standorte verteilt werden.