So lösen Sie das Problem der hohen Parallelität in der MySQL-Datenbank

Vorwort

Wir alle wissen, dass Startups zunächst monolithische Anwendungen als primäre Architektur verwenden, normalerweise in Form einer einzelnen monolithischen Datenbank. Mit der Iteration der Versionen muss die Datenbank jedoch einer höheren Parallelität standhalten, was zu einem Punkt geworden ist, der bei der Architekturgestaltung berücksichtigt werden muss.

Um das Problem zu lösen, müssen wir über Lösungen reden. Aber es gibt viele Optionen. Wie sollen wir uns entscheiden?

Optimierung und Lösungen

Grundsätzlich sollte unsere Optimierung mit mehreren Schlüsselwörtern beginnen: kurze Entfernung, weniger Daten und verteilter Druck.

Kurze Distanz

Die sogenannte kurze Distanz bedeutet, dass der Weg vom Front-End zur Datenbank kurz sein sollte.

1. Seite statisch. Die Daten mancher Seiten bleiben während bestimmter Zeiträume unverändert, daher kann diese Seite statisch gemacht werden, was die Zugriffsgeschwindigkeit erhöhen kann.
2. Cache verwenden. Jeder kennt den Cache. Und er ist deshalb so schnell, weil er auf dem Speicher basiert. Daher kann die Verwendung eines speicherbasierten Caches den Zugriff auf die Datenbank reduzieren und den Zugriff beschleunigen.
3. Stapellesen. In Situationen mit hoher Parallelität können mehrere Abfragen kombiniert und gleichzeitig ausgeführt werden, um die Geschwindigkeit des Datenbankzugriffs zu verringern.
4. Verzögerte Änderung. Verzögerte Änderung bedeutet, dass in Situationen mit hoher Parallelität die mehrfach geänderten Daten in den Cache gestellt werden können und die Daten im Cache dann regelmäßig in der Datenbank aktualisiert werden können oder durch Analyse mithilfe der Cache-Synchronisierungsstrategie asynchron mit der Datenbank synchronisiert werden können.
5. Verwenden Sie einen Index. Es versteht sich von selbst, dass es viele Arten von Indizes gibt, z. B. normale Indizes/Primärschlüsselindizes/kombinierte Indizes/Volltextindizes usw.
   

Weniger Daten

Die sogenannten weniger Daten bedeuten tatsächlich, dass weniger Daten abgefragt werden müssen.

1. Untertabelle. Die sogenannte Tabellensegmentierung umfasst eigentlich eine horizontale Segmentierung und eine vertikale Aufteilung. Freunde, die schon eigenständige Spiele gespielt haben, wissen, dass einige historische Formen oft Hunderte Millionen Daten enthalten. In diesem Fall ist es bei MySQL schwierig, schnellere Abfragegeschwindigkeiten zu erreichen, selbst wenn Indizes hinzugefügt und SQL weiter optimiert wird. Dann können wir dies durch die Operation der Untertabelle erreichen. Die gängigste Methode besteht beispielsweise darin, die Tabelle horizontal basierend auf der Zeitdimension aufzuteilen, wobei die Daten dieses Jahres beibehalten und die Daten des letzten Jahres in einer anderen Tabelle gespeichert werden.
2. Aktive Daten trennen. Tatsächlich ähnelt dies ein wenig dem Caching, der Unterschied besteht jedoch darin, dass sich die Daten weiterhin auf MySQL befinden. Beispielsweise kann es in einem Produktabfragegeschäft eine aktive Tabelle für einige beliebte/häufig gesuchte Produkte geben. Fragen Sie bei der Abfrage zuerst die aktive Tabelle ab und fragen Sie, wenn diese nicht gefunden wird, die Gesamtprodukttabelle ab.
3. Zerstückeln. Diese Blockaufteilung ähnelt in gewisser Weise der „indexsequentiellen Suche“ im Algorithmus. Durch die Optimierung auf Datenebene werden die Daten in verschiedene Blöcke platziert und wir müssen nur die entsprechenden Blöcke berechnen und finden.
   

Druck verteilen

Die sogenannte Druckverteilung bedeutet eigentlich, den Druck auf verschiedene Datenbankserver zu verteilen.

1. Cluster. Ich glaube, jeder kennt das Konzept eines Clusters. Für Unternehmensserver bedeutet es eigentlich, mehrere Server mit demselben Geschäftsprozess einzusetzen und Anforderungen durch Lastenausgleich oder andere Methoden auf verschiedene Server zu verteilen. Gleiches gilt für Datenbanken, die über bestimmte Regelstrategien Daten an bestimmte Datenbankserver weiterleiten.
2. verteilt. Die sogenannte Verteilung bedeutet eigentlich, dass die ursprünglich im selben Prozess enthaltene Geschäftslogik zur Ausführung auf verschiedene Server verteilt wird, wodurch der Effekt einer „gleichzeitigen“ Ausführung erzielt und die Ausführung beschleunigt wird.
3. Teilen Sie die Datenbank und die Tabellen auf. Die wichtigsten Methoden zum Sharding von Datenbanken und Tabellen sind horizontales und vertikales Sharding. Bei einer einzelnen Tabelle mit hoher Zugriffsfrequenz und riesigem Datenvolumen können Sie die Daten in der einzelnen Tabelle reduzieren und sie horizontal nach bestimmten Dimensionen aufteilen, um den Datenbankdurchsatz zu erhöhen. Dies ist die horizontale Aufteilung der Tabelle. Bei mehreren Tabellen mit geringer Geschäftskopplung können verschiedene Tabellen in unterschiedlichen Datenbanken gespeichert werden und die Datenbank kann vertikal aufgeteilt werden, um die Datenbankschreibfähigkeit zu verbessern. Dies ist die vertikale Aufteilung der Datenbank.
4. Bauen Sie eine Master-Slave-Beziehung auf. Der Zweck der Etablierung einer Herr-Sklave-Beziehung besteht eigentlich darin, Lesen und Schreiben zu trennen. Wir alle wissen, dass, solange die Transaktionsebene der Datenbank hoch genug ist, gleichzeitiges Lesen keine Datenverwirrung verursacht, gleichzeitiges Schreiben jedoch schon. Beim Einrichten eines Master-Slave-Servers werden Schreibvorgänge im Allgemeinen auf dem Master-Server und Lesevorgänge auf dem Slave-Server ausgeführt. Lassen Sie also grundsätzlich den Master-Server die Transaktionsvorgänge ausführen und den Slave-Server die Auswahlabfragen. Auf diese Weise werden durch Transaktionsvorgänge (Hinzufügen/Löschen/Ändern) verursachte Änderungen mit den Slave-Datenbanken im Cluster synchronisiert.
   

Abschluss

Oben sind die Details, wie MySQL mit hoher Parallelität umgeht. Weitere Informationen zur hohen Parallelität von MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!