Zwei Ideen zur Implementierung der horizontalen Datenbanksegmentierung

Einführung

Aufgrund der zunehmenden Popularität von Internetanwendungen sind die Speicherung und der Zugriff auf große Datenmengen zu Engpässen bei der Systemgestaltung geworden. Bei einer groß angelegten Internetanwendung stellen Milliarden von PVs pro Tag zweifellos eine sehr hohe Belastung der Datenbank dar. Dies hat große Probleme hinsichtlich der Stabilität und Skalierbarkeit des Systems verursacht. Die Verbesserung der Website-Leistung durch Datensegmentierung und horizontale Erweiterung der Datenebene ist für Architekturentwickler zur bevorzugten Methode geworden.

• Horizontale Aufteilung der Datenbank: Dadurch kann die Belastung einer einzelnen Maschine reduziert und die durch Ausfallzeiten verursachten Verluste minimiert werden.
• Lastausgleichsstrategie: kann die Zugriffslast einer einzelnen Maschine reduzieren und die Möglichkeit von Ausfallzeiten verringern;
• Cluster-Lösung: löst das Problem der Nichterreichbarkeit einer Einzelpunktdatenbank, das durch Datenbankausfallzeiten verursacht wird.
• Strategie zur Trennung von Lesen und Schreiben: maximiert die Geschwindigkeit und Gleichzeitigkeit beim Lesen von Daten in der Anwendung;

Warum Datensegmentierung?

Oben finden Sie eine kurze Beschreibung und Erklärung der Datensegmentierung. Die Leser fragen sich vielleicht, warum Datensegmentierung notwendig ist. Reicht eine ausgereifte und stabile Datenbank wie Oracle aus, um die Speicherung und Abfrage großer Datenmengen zu unterstützen? Warum brauchen wir Daten-Slicing?

Zwar ist die Datenbank von Oracle sehr ausgereift und stabil, doch die hohen Nutzungsgebühren und der High-End-Hardware-Support sind nicht für jedes Unternehmen erschwinglich. Man stelle sich nur die jährlichen Nutzungsgebühren in zweistelliger Millionenhöhe vor, und die Hardware-Supportkosten für die Minicomputer betragen ebenfalls zweistellige Millionenbeträge. Kann sich ein durchschnittliches Unternehmen das leisten? Selbst wenn wir es uns leisten können: Wenn es eine bessere Lösung gibt, eine günstigere Lösung mit besserer horizontaler Skalierbarkeit, warum entscheiden wir uns nicht dafür?

Wir wissen, dass jede Maschine, egal wie gut sie konfiguriert ist, ihre eigenen physikalischen Grenzen hat. Wenn unsere Anwendung also eine bestimmte Grenze einer einzelnen Maschine erreicht oder weit überschritten hat, bleibt uns keine andere Wahl, als Hilfe von anderen Maschinen zu suchen oder unsere Hardware weiter zu aktualisieren. Die übliche Lösung ist jedoch die horizontale Erweiterung durch Hinzufügen weiterer Maschinen, um den Druck zu verteilen. Wir müssen außerdem berücksichtigen, ob unsere Maschinen bei kontinuierlichem Wachstum unserer Geschäftslogik die Nachfrage durch lineares Wachstum decken können. Durch Sharding lassen sich Rechenleistung, Speicherkapazität und E/A problemlos parallel auf mehrere Maschinen verteilen. Dadurch können die unterschiedlichen Verarbeitungskapazitäten mehrerer Maschinen voll ausgenutzt werden, während gleichzeitig einzelne Ausfallpunkte vermieden, die Systemverfügbarkeit verbessert und eine gute Fehlerisolierung erreicht wird.

Unter Berücksichtigung der oben genannten Faktoren ist eine Datensegmentierung erforderlich. Wir verwenden kostenloses MySQL und günstige Server oder sogar PCs, um einen Cluster zu erstellen. Dadurch erzielen wir den Effekt eines Minicomputers + einer großen kommerziellen Datenbank, reduzieren die Kapitalinvestitionen und senken die Betriebskosten. Warum nicht?

Bei großen und mittelgroßen Projekten wird beim Entwurf der Datenbank unter Berücksichtigung der maximalen Datenmenge, die die Datenbank verarbeiten kann, die Datenbank oder die Datentabelle normalerweise horizontal aufgeteilt, um den Druck auf eine einzelne Datenbank oder eine einzelne Tabelle zu verringern. Hier stellen wir die in zwei Projekten häufig verwendeten Methoden zur Datentabellensegmentierung vor. Natürlich sind diese Methoden alle im Programm enthalten? Verwenden Sie bestimmte Techniken, um zu bestimmten Tabellen zu leiten. Zunächst müssen wir festlegen, worauf die horizontale Aufteilung basieren soll. In unserem System (SNS) läuft die UID des Benutzers durch das System und ist eindeutig und selbsterhöhend. Am besten teilt man die Tabelle nach diesem Feld auf.

Methode 1: Verwenden von MD5-Hash

Die Methode besteht darin, die UID mit MD5 zu verschlüsseln, dann die ersten paar Ziffern zu nehmen (wir nehmen hier die ersten beiden Ziffern) und dann können verschiedene UIDs in verschiedene Benutzertabellen (user_xx) gehasht werden.

Funktion getTable( $uid ){
 $ext = substr(md5($uid),0,2);
 gibt "Benutzer_".$ext zurück;
}

Mit diesem Trick können wir verschiedene UIDs auf 256 Benutzertabellen verteilen, nämlich user_00, user_01 ... user_ff. Da die UID eine Zahl ist und gemäß dem MD5-Algorithmus ansteigt, können Benutzerdaten nahezu gleichmäßig auf verschiedene Benutzertabellen verteilt werden.

Hier gibt es jedoch ein Problem. Wenn unser System immer mehr Benutzer hat, wird die Datenmenge in einer einzelnen Tabelle zwangsläufig immer größer, und die Tabelle kann nicht gemäß diesem Algorithmus erweitert werden, was uns zum Problem am Anfang des Artikels zurückbringt.

Methode 2: Umschalttaste verwenden

Die konkrete Methode ist:

öffentliche Funktion getTable( $uid ) {
 returniere "Benutzer_". sprintf( "d", ($uid >> 20) );
}

Hier verschieben wir die UID um 20 Bits nach rechts, sodass wir die ersten 1 Million Benutzerdaten in die erste Tabelle user_0000 und die zweiten 1 Million Benutzerdaten in die zweite Tabelle user_0001 usw. einfügen können. Wenn wir immer mehr Benutzer haben, können wir einfach eine Benutzertabelle hinzufügen. Da das von uns reservierte Tabellensuffix vierstellig ist, können wir hier 10.000 Benutzertabellen hinzufügen, nämlich user_0000, user_0001 ... user_9999. Mit 10.000 Tabellen und 1 Million Daten in jeder Tabelle können wir 10 Milliarden Benutzerdatensätze speichern. Wenn Ihre Benutzerdaten größer sind, spielt das natürlich keine Rolle. Sie müssen nur das reservierte Tabellensuffix ändern, um erweiterbare Tabellen hinzuzufügen. Wenn es beispielsweise 100 Milliarden Datenelemente gibt und jede Tabelle 1 Million speichert, benötigen Sie 100.000 Tabellen. Wir müssen das Tabellensuffix nur auf 6 Ziffern belassen.

Der obige Algorithmus kann flexibler geschrieben werden:

/**
 * Basierend auf dem UID-Partitionierungsalgorithmus* @param int $uid //Benutzer-ID
 * @param int $bit //Wie viele Bits sind im Tabellensuffix reserviert?* @param int $seed //Wie viele Bits sollen nach rechts verschoben werden?*/
Funktion getTable( $uid, $bit, $seed){
 returniere "Benutzer_". sprintf( "%0{$bit}d" , ($uid >> $seed) );
}

Zusammenfassung

Beide der oben genannten Methoden erfordern, dass wir die Menge der Benutzerdaten in unserem aktuellen System so weit wie möglich schätzen und die maximale Belastung abschätzen, die eine einzelne Tabelle in der Datenbank verarbeiten kann.

Wenn wir beispielsweise bei der zweiten Lösung davon ausgehen, dass unser System 10 Milliarden Benutzer hat und die optimale Datenmenge für eine einzelne Tabelle 1 Million beträgt, müssen wir die UID um 20 verschieben, um sicherzustellen, dass jede Tabelle 1 Million Daten enthält, und vier Ziffern der Benutzertabelle (user_xxxx) beibehalten, um 10.000 Tabellen zu erweitern.

Ein weiteres Beispiel ist die erste Lösung. Wenn jede Tabelle 1 Million Daten enthält und die ersten beiden Ziffern nach MD5 genommen werden, gibt es nur 256 Tabellen. Die gesamte Datenbank des Systems ist: 256*1 Million. Wenn das gesamte Datenvolumen Ihres Systems größer ist, müssen Sie MD5 verwenden, um die ersten drei, vier oder sogar mehr Ziffern zu nehmen.

Beide Methoden teilen die Daten horizontal in verschiedene Tabellen auf. Im Vergleich zur ersten Methode ist die zweite Methode skalierbarer.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an