MySQL 20-Designprinzipien für Hochleistungsarchitekturen (es lohnt sich, sie zu sammeln)

Designprinzipien für die Open-Source-Datenbankarchitektur

01. Technologieauswahl

Wählen Sie ausgereifte Plattformen und Technologien, mit denen Sie am besten vertraut sind und die Sie optimal nutzen können. Verwenden Sie das Gute statt des Schlechten und das Vertraute statt des Neuen. Zu den in der Branche derzeit gängigen MySQL-Zweigversionen gehören die offizielle MySQL-Version von Oracle, Percona Server und MariaDB.

02. Hochverfügbarkeitsoptionen

Das Wesentliche bei Hochverfügbarkeitslösungen besteht darin, Lösungen mit geringen Ausfallzeiten zu finden. Es ist verständlich, dass das Gegenteil von Hochverfügbarkeit Nichtverfügbarkeit ist. In den meisten Fällen führt eine Datenbankausfallzeit zu einer Nichtverfügbarkeit der Datenbank. Mit der Entwicklung der Technologie gibt es in Open-Source-Datenbanken viele Hochverfügbarkeitskomponenten (Master-Slave-Replikation, Halbsynchronisierung, MGR, MHA, Galera Cluster). Für entsprechende Szenarien gibt es nur eine geeignete, kein Allheilmittel. Es ist notwendig, die Vor- und Nachteile jeder Hochverfügbarkeitskomponente zu verstehen.

03. Tischgestaltung

Die Prinzipien, die derzeit bei der Tabellengestaltung konsequent eingehalten und propagiert werden, sind:

• Datenvolumen einer einzelnen Tabelle
  

Alle Tabellen müssen mit Anmerkungen versehen werden. Es wird empfohlen, die Datenmenge in einer einzelnen Tabelle auf 30 Millionen zu begrenzen.

• Keine großen Felddaten speichern
  

Speichern Sie keine großen Datenmengen wie Bilder und Dateien in der Datenbank

• Richtlinien zur Tabellenverwendung

Teilen Sie große Felder und Felder mit geringer Zugriffshäufigkeit auf, um heiße und kalte Daten zu trennen

Die Anzahl der Felder in einer einzelnen Tabelle sollte auf 20 begrenzt werden.

• Indexspezifikation
  

1. Die Anzahl der Indizes in einer einzelnen Tabelle überschreitet nicht 5

2. Die Anzahl der Felder in einem einzelnen Index überschreitet nicht 5

3. Für INNODB-Primärschlüssel wird empfohlen, Auto-Increment-Spalten zu verwenden. Primärschlüssel sollten nicht geändert werden und Zeichenfolgen sollten nicht als Primärschlüssel verwendet werden.

Wenn Sie keinen Primärschlüssel angeben, verwendet INNODB stattdessen einen eindeutigen und nicht leeren Werteindex.

4. Wenn es sich um einen zusammengesetzten Index handelt, setzen Sie das Feld mit dem größten Unterschied an den Anfang des Index

5. Vermeidung redundanter oder doppelter Indizes: Erstellen Sie gemeinsame Indizes entsprechend (Vermeidung von Redundanz)

6. Erstellen Sie keine Indizes für Spalten mit niedriger Kardinalität, wie etwa „Geschlecht“.

7. Führen Sie keine mathematischen Operationen oder Funktionsoperationen an Indexspalten durch

• Zeichensatz utf8mb4 (ungewöhnliche Zeichen, Emoticons)
  

04. Optimierungsprinzipien

05. Kopiermethode

Die MySQL-Replikation bietet asynchronen Modus, halbsynchronen Modus, starke Konsistenz globaler Transaktionen und Binglog-Synchronisierung. Zwischen verschiedenen Geschäftssystemen oder zwischen zwei Datenbanken ist eine Synchronisierung erforderlich. Die asynchrone Methode kann die Ausbreitung und Ausweitung von Fehlern und Effizienzproblemen verhindern. Allerdings wird eine starke Konsistenz komplizierter und Parallelität sowie Transaktionsgröße werden begrenzt.

06. Trennungsprinzip

Unterscheiden Sie Geschäftssysteme für Kerngeschäft, wichtiges Geschäft, Kanäle und internes Geschäft und richten Sie unterschiedliche Architekturen für unterschiedliche Systeme ein. Für Kerngeschäfte ist die Nutzung von Unterdatenbanken und dedizierten Multi-Active-Highways die beste Einstellung, während andere Geschäfte die Trennung von Lese- und Schreibzugriffen sowie die Zwischenspeicherung nutzen können.

07. Skalierbarkeit

Skalierbarkeit ist für das System sehr wichtig und eine horizontale Erweiterung sollte so weit wie möglich erreicht werden. Vermeiden Sie eine übermäßige Abhängigkeit von vertikaler Expansion und behalten Sie die Möglichkeit, sowohl vertikal als auch horizontal zu expandieren. Beispielsweise sollten zustandslose Anwendungen mit mehreren Lastausgleichssätzen und einer Multi-Active-Datenbankarchitektur bereitgestellt werden.

08. Lese-/Schreibtrennung

• Szenario mit mehr Lese- und weniger Schreibvorgängen (10 % Schreibvorgänge und 90 % Lesevorgänge)
• Bei der Replikation kommt es zu Verzögerungen, das Unternehmen reagiert jedoch nicht empfindlich auf Verzögerungen
• Durchführung:

1. Konfigurieren Sie die Lese-/Schreibtrennung über den Anwendungscode.

2. Routing schreibgeschützter Bibliotheken über einen Zwischenproxy

3. Business und Datenbank als Einheit

09. Separate Datenbanken und Tabellen

• Wenn die Anzahl der Datensätze in einer Tabelle 30 Millionen übersteigt, können selbst die besten Indizes die Geschwindigkeit der Datenabfrage nicht verbessern. Zu diesem Zeitpunkt muss die Tabelle in mehrere kleinere Tabellen aufgeteilt werden, um die Leistung und Flexibilität zu erhöhen und Datenbankabstürze zu vermeiden.
• Die Einführung des Zwischenpreises erfordert eine Berücksichtigung der Leistungskosten und der Aggregationsnachfrage.
• Das Prinzip der Datenbankaufteilung besteht darin, die Datenbank auf der oberen Ebene der App, also den Datenverkehr, so weit wie möglich aufzuteilen.
• Die passende Punktzahl: Verfügbarkeit und Leistung erfüllen TPS.
• Routing: In die Konfigurationsdatei schreiben oder Tabelle oder Zookeeper einfügen.
  

10. Grundsätze der Archivierung

Historische Daten werden regelmäßig archiviert oder auf andere Big Data-Plattformen verschoben. Dadurch können leichte Datenbanken mehr nützliche Daten zwischenspeichern.

Vermeiden Sie in partitionierten MySQL-Tabellen sorgfältig Partitionssperren und Szenarien mit schreibgeschütztem Lesezugriff.

11. Anforderungen an den Verbindungspool

Lange Verbindung, automatische Neuverbindung, Verzögerungs- und Ausnahmeaufzeichnung, elastische Verbindung, vollständige Erkennung, abnormaler Alarm, erweiterte Anforderungen

Es zeichnet alle Zugriffssituationen auf und kann viele Funktionen erweitern.

Einstellungen für den Anwendungs- und Datenbankverbindungspool, Festlegen der von der Datenbank zugelassenen Anzahl von Verbindungen und häufige Probleme.

A) Der Datenbankverbindungspool der Anwendung ist zu klein eingestellt. Sobald die Datenbank langsam antwortet (neue Anwendung, fehlender Index usw.), sollte sie

Es kommt zu erheblichen Warteschlangen und sogar Lawinen und die Kapazität der Datenbank ist leider noch lange nicht erschöpft.

B) Es ist nicht möglich, Fehler rechtzeitig zu erkennen und die Verbindung zur Datenbank wiederherzustellen.

C) Einstellung der Isolationsstufe: Unterschiedliche Leistung unter RR und RC.

12. Anwendungsentkopplung

Greifen Sie über Anwendungen auf die Datenbank zu, nicht direkt. Wichtige Unternehmen können sich nicht auf Systeme mit niedrigen Sicherheitsstufen verlassen. Wichtige Unternehmen und normale Unternehmen sind auf der Anwendungsebene entkoppelt, und Schlüsselunternehmen müssen unabhängig sein.

13. Immunität gegen Komponentenausfälle

Die Funktionen zur Notfallwiederherstellung, zur Geschäftsbeeinflussung und zur Fehlerbehebung für einzelne Anwendungen, einzelne Hardware oder sogar einzelne Infrastrukturen und einzelne Standorte sollten vierteljährlich geübt werden.

14. Reduzieren Sie die Belastung durch Keyword-Komponenten

Insbesondere beim Datenbankzugriff sind die Datenbankkosten am höchsten, die Skalierbarkeit am schwierigsten, die Verfügbarkeitssicherung am schwierigsten und die Wiederherstellung am schwierigsten und zeitaufwändigsten.

Reduzieren Sie den Aufwand: Vermeiden Sie ihn wenn möglich, verwenden Sie die einfachsten und kostengünstigsten Anweisungen, vermeiden Sie große Transaktionen und gehen Sie bei zweiphasigen Transaktionen mit Vorsicht vor.

15. Graustufendatenbank

Um die globalen Auswirkungen von Datenbankänderungen während der Veröffentlichung zu reduzieren, reicht es nicht aus, nur Anwendungsgraustufen, sondern auch eine dedizierte Graustufendatenbank zu haben. Mithilfe der Datenbankpartitionierung und der Lese-/Schreibtrennungsarchitektur wird eine vollständige Anwendungsarchitektur einschließlich einer Datenbank ganz selbstverständlich.

Die sogenannte Graustufenumgebung ist die Produktionsumgebung und die Produktionsdaten und wirkt sich auch auf die Produktionsumgebung aus, der Umfang ist jedoch breiter und realistischer als die Testumgebung. Tatsächlich handelt es sich um eine Produktionsumgebung im kleinen Maßstab. Ähnlich einer Spiele-Beta.

16. Hochsimulationsarchitektursystem

Aufbau eines hochsimulierten Architektursystems

• Datenbank- und Betriebssystem-Upgrades: ob Anwendungen angepasst werden und ob sich die Leistung verbessert oder verschlechtert
• Anwendungsstart und Systemänderungen (z. B. Plattformwechsel), um geschäftliche Auswirkungen und Leistungsengpässe vorherzusagen
• Um plötzliche Transaktionsvolumina, wie beispielsweise während des Double Eleven-Einkaufsbummels, bewältigen zu können, müssen wir verstehen, wo die Leistungsgrenzen und die Engpässe liegen.
  

17. Notfallwiederherstellung

Hohe Verfügbarkeit ist die Kernanforderung für Betrieb und Wartung, und die Notfallwiederherstellung ist die letzte Barriere

Beispielsweise ist Active-Active Dual besser als Active-Active Single, MGR ist besser als eine Replikationsarchitektur und wichtige Systeme müssen für hohe Verfügbarkeit und Notfallwiederherstellung aufgebaut sein.

18. Multicenter-Konstruktion

Redundanz bildet die Grundlage, und der Aufbau mehrerer Zentren dient der Verbesserung der Notfallwiederherstellung und Erweiterungsmöglichkeiten sowie der Geschäftssicherung.

19. Die Anwendung und die Datenbank sind integriert

Anwendungs- sowie Betriebs- und Wartungspersonal arbeiten zusammen, um Probleme wie Anwendungs- und Datenbankentkopplung, Inkasso und -auffüllung, Geschäftsüberwachung, Anwendungsrouting, Fehlerumschaltung usw. zu lösen. Verfügbarkeit, Effizienz, Fehlerbehebung und andere Aspekte müssen alle berücksichtigt werden.

20. Leistungsverbesserungen

Die Verwendung von Open-Source-Datenbanken sollte sinnvoll sein und effektiv mit anderen Arten umgebender Datenbanken kombiniert werden, um die Leistung zu maximieren. Zum Beispiel: Redis, MongoDB, ES, ClickHouse usw.

Zusammenfassen

1. Die am besten geeignete Architektur ist eine, die Softwarefunktionen und Geschäftsszenarien kombiniert und gleichzeitig ein Gleichgewicht zwischen Kosten und Nutzen erreicht;

2. Bei großen Datenmengen können Lese-/Schreibtrennung sowie Datenbank- und Tabellen-Sharding verwendet werden, es müssen jedoch die geeigneten ausgewählt werden.

3. Wenn es nicht für Datenbank-Sharding geeignet ist, sollten Sie die Kerndatenbank so klein wie möglich machen und dann die Kapazität durch vertikale Erweiterung erweitern.

4. Verwenden Sie verschiedene Technologien, Hochverfügbarkeit und Notfallwiederherstellungsmaßnahmen, um die Verfügbarkeit sicherzustellen.

Oben finden Sie den detaillierten Inhalt der Designprinzipien der MySQL 20-Hochleistungsarchitektur (es lohnt sich, sie zu sammeln). Weitere Informationen zum MySQL-Architekturdesign finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!