Einführung in MyCat, die Datenbank-Middleware

1. Mycat-Anwendungsszenarien

Mycat wurde für eine Vielzahl von Szenarien entwickelt und neue Benutzer bieten ständig neue und innovative Lösungen. Im Folgenden sind einige typische Anwendungsszenarien aufgeführt:

• 1. Einfache Lese-/Schreibtrennung. Die Konfiguration ist derzeit die einfachste. Sie unterstützt Lese-/Schreibtrennung und Master-Slave-Umschaltung.
• 2. Shard-Tabellen und -Datenbanken. Shard-Tabellen mit mehr als 10 Millionen Elementen. Unterstützt Sharding von bis zu 100 Milliarden Elementen pro Tabelle.
• 3. Mandantenfähige Anwendung: Jede Anwendung verfügt über eine Bibliothek, die Anwendung stellt jedoch nur eine Verbindung zu Mycat her, um das Programm selbst nicht zu ändern und Mandantenfähigkeit zu erreichen
• 4. Das Berichtssystem verarbeitet mithilfe der Tabellenpartitionierungsfunktion von Mycat Statistiken zu umfangreichen Berichten
• 5. Ersetzen Sie Hbase und analysieren Sie Big Data
• 6. Als einfache und effektive Lösung für die Echtzeitabfrage großer Datenmengen müssen beispielsweise 10 Milliarden häufig abgefragte Datensätze innerhalb von 3 Sekunden abgefragt werden. Neben primärschlüsselbasierten Abfragen kann es auch Bereichsabfragen oder andere Attributabfragen geben. In diesem Fall ist Mycat möglicherweise die einfachste und effektivste Wahl.

MYCAT kann einen Lastausgleich für Lesevorgänge unter Trennung von Lesen und Schreiben realisieren und eine große Anzahl von Lesevorgängen auf verschiedene Slave-Bibliotheken verteilen, was hauptsächlich bei einem Master und mehreren Slaves auftritt.

MYCAT kann eine hohe Verfügbarkeit der Datenbank erreichen. Wenn der Masterknoten der Datenbank verfügbar ist, wird ein beschreibbarer Slaveknoten konfiguriert. Beide Knoten werden in MYCAT konfiguriert. Wenn der Masterknoten ausfällt, leitet MyCAT den Schreibvorgang automatisch an den Backup-Knoten weiter, unterstützt jedoch nach dem Wechsel keine fortgesetzte Master-Slave-Synchronisierung.

Wenn die Lese- und Schreibtrennung dem kontinuierlich steigenden Zugriffsvolumen nicht mehr gerecht wird, kann MYCAT eine vertikale Aufteilung der Datenbank realisieren, indem alle Datenbanktabellen in Module unterteilt und verschiedene Tabellentypen auf verschiedene Datenbankserver aufgeteilt werden.

Wenn mit zunehmendem Geschäftsvolumen nach der vertikalen Aufteilung Leistungsprobleme der Datenbank auftreten, ist eine horizontale Aufteilung erforderlich, die allgemein als Datenbank- und Tabellen-Sharding bezeichnet wird. Die Tabellendaten mit großen Datenmengen werden auf verschiedene Serverbibliotheken aufgeteilt. Die Tabellenstruktur ist dieselbe, und MYCAT wird zur horizontalen Aufteilung verwendet. Es ist für die Front-End-Anwendung vollständig transparent und es ist nicht erforderlich, die Front-End-Logik anzupassen.

Laut Definition und Klassifizierung handelt es sich um ein Open-Source-verteiltes Datenbanksystem und einen Server, der das MySQL-Protokoll implementiert. Front-End-Benutzer können es als Datenbank-Proxy betrachten und über MySQL-Client-Tools und Befehlszeilen darauf zugreifen, während das Back-End über das native MySQL-Protokoll mit mehreren MySQL-Servern oder über das JDBC-Protokoll mit den meisten gängigen Datenbankservern kommunizieren kann. Seine Kernfunktion ist das Sharding von Tabellen und Datenbanken, d. h. das horizontale Aufteilen einer großen Tabelle in N kleine Tabellen und deren Speicherung auf dem Back-End-MySQL-Server oder in anderen Datenbanken.

Die aktuelle Version von MyCat ist kein einfacher MySQL-Proxy mehr. Sein Backend unterstützt gängige Datenbanken wie MySQL, SQL Server, Oracle, DB2, PostgreSQL und auch neue NoSQL-Speichermethoden wie MongoDB. In Zukunft werden weitere Speichertypen unterstützt. Aus Sicht des Endbenutzers handelt es sich bei MyCat, unabhängig von der verwendeten Speichermethode, um eine herkömmliche Datenbanktabelle, die standardmäßige SQL-Anweisungen zum Bearbeiten von Daten unterstützt. Dies kann den Entwicklungsaufwand erheblich verringern und die Entwicklungsgeschwindigkeit für das Front-End-Geschäftssystem verbessern.

2. Einschränkungen traditioneller relationaler Datenbanken

Herkömmliche relationale Datenbanken weisen aufgrund ihrer mangelnden Skalierbarkeit große Mängel bei der Verarbeitung großer Datenmengen auf, doch relationale Modelle und Transaktionsmechanismen sind für die meisten Systeme unverzichtbar. Die derzeit gängige Praxis in der Branche besteht darin, herkömmliche Datenbanken aufzuteilen (einschließlich vertikaler Aufteilung, horizontaler Aufteilung usw.), um die Skalierbarkeit der Datenbank zu verbessern. Die Aufspaltung brachte jedoch neue Probleme mit sich, beispielsweise die Verwaltung mehrerer Datenquellen, knotenübergreifende Verknüpfungen und verteilte Transaktionsprobleme. Lassen Sie uns untersuchen, wie Mycat diese Probleme löst.

Probleme bei der Verwaltung mehrerer Datenquellen

Für das Problem der Verwaltung mehrerer Datenquellen gibt es zwei Hauptlösungen. Die erste ist der Client-Modus, der eine (oder mehrere) von jedem Anwendungsmodul benötigte Datenquellen konfiguriert und verwaltet, direkt auf jede Datenbank zugreift und die Datenintegration innerhalb des Moduls durchführt. Zweitens: Alle Datenquellen werden einheitlich über die zwischengeschaltete Proxy-Schicht verwaltet und der Back-End-Datenbankcluster ist für die Front-End-Anwendung transparent. Die erste Methode ist nicht universell. Jede Anwendung muss ihre eigene Datenintegrationsfunktion entwickeln und der Code des bereits erstellten Systems muss überarbeitet werden, was für die Werbung nicht geeignet ist. Derzeit wird hauptsächlich die zweite Methode verwendet. Das Prinzip von Mycat lautet wie folgt: Das wichtigste Verb im Prinzip von Mycat ist „abfangen“. Es fängt die vom Benutzer gesendeten SQL-Anweisungen ab und führt zunächst eine bestimmte Analyse der SQL-Anweisungen durch: z. B. Sharding-Analyse, Routing-Analyse, Lese-/Schreibtrennungsanalyse, Cache-Analyse usw., sendet dieses SQL dann an die reale Datenbank im Backend, verarbeitet die zurückgegebenen Ergebnisse entsprechend und gibt sie schließlich an den Benutzer zurück.

Das Prinzip von Mycat ist dem anderer verteilter Datenbank-Middleware sehr ähnlich, es gibt jedoch immer noch Unterschiede in der Architektur. Mycat ist von Cobar abgeleitet, wurde jedoch auf seiner Basis erheblich verbessert. Die Architektur von Mycat ist wie folgt:

Zu den gängigen Middleware-Produkten für verteilte Datenbanken zählen derzeit TDDL, Amoeba, Coba usw. TDDL unterscheidet sich von anderen Produkten. Es handelt sich nicht um eine eigenständige Middleware, sondern kann nur als Zwischenschicht betrachtet werden, die der Anwendung in Form eines Jar-Pakets bereitgestellt wird. Dies ist die Idee von JDBC Shard, und es gibt viele andere ähnliche Produkte im Internet. Amoeba stellt Dienste als wirklich unabhängige Middleware bereit, d. h. Anwendungen stellen eine Verbindung zu Amoeba her, um einen MySQL-Cluster zu betreiben, genau wie beim Betrieb eines einzelnen MySQL. An der Architektur lässt sich erkennen, dass Amoeba ein frühes Produkt in der Middleware ist und das Backend immer noch den JDBC-Treiber verwendet. Cobar ist eine weiterentwickelte Version, die auf Amoeba basiert. Eine wesentliche Änderung besteht darin, dass der JDBC-Treiber im Backend in die native MySQL-Kommunikationsprotokollschicht geändert wurde, was bedeutet, dass er gängige Datenbanken wie Oracle und ProstgreSQL nicht unterstützen kann. MyCat ist eine weitere auf Cobar basierende Version. Das Backend wurde von BI0 auf NIO geändert, die Parallelität wurde erheblich verbessert und Unterstützung für Aggregationsfunktionen wie Order By, GroupBy und Limit hinzugefügt. Es unterstützt die meisten aktuellen Mainstream-Datenbanken.

Knotenübergreifendes Join-Problem

Mycat unterstützt Inner Join, Leaf/Right Join, Cross Join, Full Join und andere Cross-Node-Join-Methoden, die hauptsächlich über globale Tabellen, ER-Sharding, Share Join und Catlet (künstliche Intelligenz) implementiert werden:

1. Globale Tabelle

In einem realen Geschäftssystem gibt es oft eine große Anzahl von Tabellen, die Wörterbuchtabellen ähneln. Sie können eine Beziehung zur Geschäftstabelle haben. Diese Beziehung kann eher als „Label“ als als die übliche „Master-Slave-Beziehung“ verstanden werden. Diese Tabellen ändern sich selten und können basierend auf der Primärschlüssel-ID zwischengespeichert werden. Die folgende Abbildung zeigt ein typisches „Label-Beziehungs“-Diagramm:

Beim Sharding wird die Verknüpfung zwischen der Geschäftstabelle und diesen angehängten Wörterbuchtabellen zu einem schwierigeren Problem, wenn die Geschäftstabelle aufgrund der Skalierung geteilt wird. Dabei ist zu berücksichtigen, dass die Wörterbuchtabelle die folgenden Merkmale aufweist:

• 1. Seltene Änderungen
• 2. Die Gesamtdatenmenge hat sich nicht wesentlich verändert
• 3. Die Datenmenge ist nicht groß und überschreitet selten Hunderttausende von Datensätzen.

Vor diesem Hintergrund definiert MyCAT eine spezielle Tabelle namens „globale Tabelle“, die über die folgenden Eigenschaften verfügt:

• 1. Einfüge- und Aktualisierungsvorgänge der globalen Tabelle werden auf allen Knoten in Echtzeit ausgeführt, um die Datenkonsistenz jedes Shards aufrechtzuerhalten
• 2. Die Abfrageoperation der globalen Tabelle wird nur von einem Knoten abgerufen
• 3. Globale Tabellen können J0IN-Operationen mit jeder Tabelle durchführen

Durch das Definieren von Wörterbuchtabellen oder einigen Tabellen, die die Eigenschaften von Wörterbuchtabellen erfüllen, als globale Tabellen kann das Problem des Daten-JOIN aus einem anderen Aspekt effektiv gelöst werden. Durch eine auf globalen Tabellen und ER-Beziehungen basierende Sharding-Strategie kann MyCAT mehr als 80 % der Anforderungen der Unternehmensanwendungsentwicklung erfüllen.

Die globale Tabelle ist wie folgt konfiguriert (die globale Tabelle wird in allen Knoten gespeichert):

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