So implementieren Sie die Datensegmentierung in MySQL

MySQL-Methode zum Implementieren der Datensegmentierung: 1. Verwenden Sie die vertikale Segmentierung der Daten. 3. Verwenden Sie den MySQL-Proxy, um die Datensegmentierung und -integration zu erreichen. 5. Verwenden Sie HiveDB um Datensegmentierung und -integration zu erreichen.

Weitere verwandte kostenlose Lernempfehlungen: MySQL-Tutorial(Video)

MySQL-Methode zur Implementierung der Datensegmentierung:

Was sind. Daten Schneiden

Einfach gesagt Dies bedeutet, dass die in derselben Datenbank gespeicherten Daten unter bestimmten Bedingungen auf mehrere Datenbanken (Hosts) verteilt werden, um die Last eines einzelnen Geräts zu verteilen. Data Slicing kann auch die Gesamtverfügbarkeit des Systems verbessern, da nach dem Absturz eines einzelnen Geräts nur ein bestimmter Teil der Gesamtdaten nicht verfügbar ist, nicht jedoch alle Daten.

Daten-Sharding kann entsprechend der Art der Sharding-Regeln in zwei Sharding-Modi unterteilt werden. Die eine besteht darin, sie entsprechend den Daten in der Tabelle (oder Schemata) aufzuteilen In einer logischen Beziehung werden die Daten in derselben Tabelle gemäß bestimmten Bedingungen in mehrere Datenbanken (Hosts) aufgeteilt. Diese Art der Segmentierung wird als horizontale (horizontale) Segmentierung der Daten bezeichnet.

Das größte Merkmal der vertikalen Segmentierung besteht darin, dass die Regeln einfach und die Implementierung bequemer sind. Sie eignet sich besonders für Systeme mit sehr geringer Kopplung zwischen verschiedenen Unternehmen, geringer gegenseitiger Beeinflussung und sehr klarer Geschäftslogik. In einem solchen System ist es einfach, die von verschiedenen Geschäftsmodulen verwendeten Tabellen in verschiedene Datenbanken aufzuteilen. Die Aufteilung nach verschiedenen Tabellen hat weniger Auswirkungen auf die Anwendung und die Aufteilungsregeln werden einfacher und klarer.

Die horizontale Segmentierung ist etwas komplizierter als die vertikale Segmentierung. Da unterschiedliche Daten in derselben Tabelle in verschiedene Datenbanken aufgeteilt werden müssen, sind die Aufteilungsregeln selbst für die Anwendung komplizierter als die Aufteilung basierend auf Tabellennamen, und auch die anschließende Datenpflege wird komplizierter.

Wenn das Datenvolumen und das Zugriffsvolumen einer bestimmten (oder einiger) Tabelle besonders groß sind und die Leistungsanforderungen nach dem vertikalen Schneiden und Platzieren auf einem unabhängigen Gerät immer noch nicht erfüllt sind, müssen vertikales Sharding und horizontales Schneiden kombiniert durchgeführt werden , zuerst vertikal und dann horizontal aufteilen, kann dies das Leistungsproblem dieser sehr großen Tabelle lösen.

Das Folgende ist eine entsprechende Analyse der Architekturimplementierung der drei Datensegmentierungsmethoden der vertikalen, horizontalen und kombinierten Segmentierung sowie der Integration der segmentierten Daten.

Vertikale Segmentierung von Daten

Werfen wir zunächst einen Blick darauf, wie die vertikale Segmentierung von Daten segmentiert wird. Die vertikale Segmentierung von Daten kann auch als vertikale Segmentierung bezeichnet werden. Stellen Sie sich eine Datenbank vor, die aus vielen „Datenblöcken“ (Tabellen) besteht, einen nach dem anderen. Schneiden Sie diese „Datenblöcke“ vertikal ab und verteilen Sie sie dann auf mehrere Datenbankhosts. Eine solche Slicing-Methode ist das vertikale (Längs-)Daten-Slicing.

Die Gesamtfunktion eines Anwendungssystems mit einer gut gestalteten Architektur muss aus vielen Funktionsmodulen bestehen, und die von jedem Funktionsmodul benötigten Daten entsprechen einer oder mehreren Tabellen in der Datenbank. Im Architekturdesign gilt: Je einheitlicher und weniger Interaktionspunkte zwischen den einzelnen Funktionsmodulen sind, desto geringer ist der Kopplungsgrad des Systems und desto besser ist die Wartbarkeit und Skalierbarkeit jedes Moduls des Systems. Ein solches System erleichtert die vertikale Segmentierung von Daten.

Je klarer die Funktionsmodule und je geringer die Kopplung, desto einfacher lassen sich die Regeln für die vertikale Datensegmentierung definieren. Daten können basierend auf Funktionsmodulen segmentiert werden. Die Daten verschiedener Funktionsmodule werden auf verschiedenen Datenbankhosts gespeichert. Datenbankübergreifende Verknüpfungen können leicht vermieden werden, und die Systemarchitektur ist ebenfalls sehr klar.

Natürlich ist es für ein System schwierig, die von allen Funktionsmodulen verwendeten Tabellen völlig unabhängig zu machen, und es besteht überhaupt keine Notwendigkeit, auf die Tabellen der anderen zuzugreifen, oder es ist notwendig, die Tabellen der beiden Module zu verbinden. In diesem Fall müssen Bewertungen und Kompromisse auf der Grundlage tatsächlicher Anwendungsszenarien erfolgen. Entscheiden Sie, ob Sie die Anwendung unterbringen und verwandte Module von Tabellen speichern möchten, die in derselben Datenbank verknüpft werden müssen, oder ob Sie die Anwendung mehr Aufgaben erledigen lassen möchten – Daten aus verschiedenen Datenbanken vollständig über die Modulschnittstelle abrufen und dann den Join-Vorgang im Programm abschließen .

Wenn es sich um ein System mit relativ geringer Auslastung und sehr häufigen Tabellenkorrelationen handelt, kann es sein, dass die Datenbank nachgibt und mehrere verwandte Module zusammenführt, um die Anwendungsarbeit zu reduzieren. Dies ist eine praktikable Lösung.

Natürlich wird durch die Konzession der Datenbank, die es mehreren Modulen ermöglicht, Datenquellen zentral zu teilen, tatsächlich indirekt die Entwicklung einer verstärkten Kopplung der einzelnen Modularchitekturen hingenommen, was zukünftige Architekturen verschlechtern kann. Insbesondere wenn es ein bestimmtes Entwicklungsstadium erreicht und sich herausstellt, dass die Datenbank dem durch diese Tabellen verursachten Druck nicht standhalten kann und sich erneut einer Segmentierung stellen muss, können die Kosten für die Architekturtransformation weitaus höher sein als für den ursprünglichen Architekturentwurf mit Segmentierung.

Wenn die Datenbank also vertikal segmentiert ist, ist die Frage, wie und in welchem ​​Umfang sie segmentiert wird, ein herausforderndes Problem. Nur wenn wir Kosten und Nutzen aller Aspekte in tatsächlichen Anwendungsszenarien abwägen, können wir einen Split-Plan analysieren, der wirklich zu uns passt.

Zum Beispiel analysieren wir die Beispieldatenbank des in diesem Artikel verwendeten Beispielsystems kurz und entwerfen dann eine einfache Segmentierungsregel, um eine vertikale Aufteilung durchzuführen.

Die Systemfunktionen lassen sich grundsätzlich in 4 Funktionsmodule unterteilen: Benutzer, Gruppennachrichten, Fotoalben und Ereignisse, die den folgenden Tabellen entsprechen:

• Benutzermodultabelle: Benutzer, Benutzerprofil, Benutzergruppe, Benutzerfotoalbum

• Gruppe Gruppendiskussionstabelle: groups, group_message, group_message_content, top_message

• Albumbezogene Tabelle: photo, photo_album, photo_album_relation, photo_comment

• Event-Informationstabelle: event

Auf den ersten Blick kann kein Modul davon getrennt werden Die anderen Module existieren unabhängig voneinander und es besteht eine Beziehung zwischen den Modulen. Ist es unmöglich, sie zu trennen?

Natürlich nicht. Nach einer etwas eingehenderen Analyse können Sie feststellen, dass die von den einzelnen Modulen verwendeten Tabellen zwar miteinander in Beziehung stehen, die Beziehung jedoch relativ klar und einfach ist.

Das Gruppendiskussionsmodul und das Benutzermodul sind hauptsächlich durch Benutzer- oder Gruppenbeziehungen miteinander verbunden. Im Allgemeinen erfolgt die Zuordnung über die Benutzer-ID oder den Spitznamen und die Gruppen-ID. Die Implementierung über die Schnittstelle zwischen Modulen verursacht keine allzu großen Probleme.

Das Fotoalbum-Modul hat nur eine Benutzerzuordnung zum Benutzermodul. Die Verbindung zwischen diesen beiden Modulen besteht im Wesentlichen nur aus dem mit der Benutzer-ID verknüpften Inhalt, der einfach und klar ist, und die Benutzeroberfläche ist klar.

Das Ereignismodul bezieht sich möglicherweise auf jedes Modul, konzentriert sich jedoch nur auf die ID-Informationen der Objekte in jedem Modul, was auch einfacher aufzuteilen ist.

Der erste Schritt kann also darin bestehen, die Datenbank entsprechend den Tabellen, die sich auf die Funktionsmodule beziehen, in eine separate Datenbank aufzuteilen. Die Tabellenzuordnungen zwischen Modulen werden alle auf der Seite des Anwendungssystems übergeben .Schnittstelle zur Handhabung. Wie im schematischen Diagramm der vertikalen Datensegmentierung dargestellt (Abbildung 1):

Nach einer solchen vertikalen Segmentierung wurden Dienste, die zuvor nur über eine Datenbank bereitgestellt werden konnten, in vier Datenbanken aufgeteilt, um Dienste bereitzustellen. Die Servicefunktionen sind natürlich um ein Vielfaches gestiegen mal.

Vorteile der vertikalen Segmentierung:

• Die Aufteilung der Datenbank ist einfach und klar, und die Aufteilungsregeln sind klar;

• Die Anwendungsmodule sind klar und deutlich und die Integration ist einfach; Die Wartung ist bequem und leicht zu finden.

• Nachteile des vertikalen Slicings:

Einige Tabellenzuordnungen können nicht auf Datenbankebene abgeschlossen werden und müssen im Programm abgeschlossen werden;

• Es besteht immer noch ein Leistungsengpass für Tabellen, auf die extrem häufig zugegriffen wird große Datenmengen, die möglicherweise nicht der Fall sind; machen das System zu komplex und schwer zu warten.

• Angesichts der Datensegmentierungs- und Transaktionsprobleme, die bei der vertikalen Segmentierung auftreten können, ist es wirklich schwierig, eine bessere Lösung auf Datenbankebene zu finden. In tatsächlichen Anwendungsfällen entspricht die vertikale Segmentierung der Datenbank meist den Modulen des Anwendungssystems. Die Datenquellen desselben Moduls werden in derselben Datenbank gespeichert, wodurch das Problem der Datenzuordnung innerhalb des Moduls gelöst werden kann. Zwischen den Modulen werden die benötigten Daten einander über Anwendungsprogramme in Form von Serviceschnittstellen zur Verfügung gestellt. Obwohl dies tatsächlich die Gesamtzahl der Vorgänge in der Datenbank erhöht, ist es im Hinblick auf die allgemeine Skalierbarkeit des Systems und die Modularisierung der Architektur von Vorteil. Die einzelne Reaktionszeit einiger Vorgänge kann sich geringfügig verlängern, die Gesamtleistung des Systems wird jedoch wahrscheinlich bis zu einem gewissen Grad verbessert. Das Problem des Erweiterungsengpasses kann nur gelöst werden, indem man sich auf die im nächsten Abschnitt vorgestellte horizontale Datensegmentierungsarchitektur verlässt.

• Horizontale Segmentierung von Daten

Der obige Abschnitt analysiert und stellt die vertikale Segmentierung von Daten vor. Die vertikale Segmentierung von Daten kann grundsätzlich einfach als Aufteilung der Daten nach Tabellen oder Modulen verstanden werden, während die horizontale Segmentierung anders ist. Im Allgemeinen besteht einfaches horizontales Sharding hauptsächlich darin, eine Tabelle mit äußerst trivialem Zugriff gemäß bestimmten Regeln eines bestimmten Felds in mehrere Tabellen zu verteilen, und jede Tabelle enthält einen Teil der Daten.

• Einfach ausgedrückt kann die horizontale Segmentierung von Daten als Segmentierung nach Datenzeilen verstanden werden, dh die Segmentierung einiger Zeilen in der Tabelle in eine Datenbank und die Segmentierung anderer Zeilen in andere Datenbanken. Um leicht zu bestimmen, in welche Datenbank jede Datenzeile unterteilt wurde, muss die Aufteilung natürlich immer nach bestimmten Regeln durchgeführt werden: z. B. Nehmen eines Modulo basierend auf einer bestimmten Zahl basierend auf einem numerischen Feld, a bestimmte Zeit Der Bereich von Typfeldern oder der Hashwert eines Zeichentypfelds. Wenn die meisten Kerntabellen im gesamten System über ein bestimmtes Feld verknüpft werden können, ist dieses Feld natürlich die beste Wahl für die horizontale Partitionierung, außer natürlich in ganz besonderen Fällen, in denen es nicht verwendet werden kann.

  Im Allgemeinen können, wie bei den derzeit sehr beliebten Web 2.0-Websites, die meisten Daten über Mitgliedsbenutzerinformationen verknüpft werden. Möglicherweise eignen sich viele Kerntabellen sehr gut für die horizontale Segmentierung von Daten über Mitglieds-IDs. Beispielsweise ist das Forum-Community-Diskussionssystem einfacher zu segmentieren. Es kann horizontal nach der Forumsnummer segmentiert werden. Nach der Aufteilung erfolgt grundsätzlich keine Interaktion zwischen Bibliotheken.

  Wenn alle Daten im Beispielsystem Benutzern zugeordnet sind, können sie horizontal nach Benutzern aufgeteilt werden und die Daten verschiedener Benutzer können in verschiedene Datenbanken unterteilt werden. Der einzige Unterschied besteht natürlich darin, dass die Gruppentabelle im Benutzermodul keinen direkten Bezug zu Benutzern hat, sodass Gruppen nicht horizontal nach Benutzern aufgeteilt werden können. Für diesen Sonderfall kann die Tabelle vollständig abgetrennt und in einer unabhängigen Datenbank abgelegt werden. Tatsächlich kann man sagen, dass dieser Ansatz die im vorherigen Abschnitt eingeführte Methode der „vertikalen Segmentierung von Daten“ nutzt. Diese gemeinsame Segmentierungsmethode, die gleichzeitig vertikale Segmentierung und horizontale Segmentierung verwendet, wird im nächsten Abschnitt ausführlicher vorgestellt Abschnitt.

  Für die Beispieldatenbank können die meisten Tabellen basierend auf der Benutzer-ID horizontal aufgeteilt werden. Daten zu verschiedenen Benutzern werden segmentiert und in verschiedenen Datenbanken gespeichert. Beispielsweise werden alle Benutzer-IDs Modulo 2 übernommen und dann in zwei verschiedenen Datenbanken gespeichert. Jede mit einer Benutzer-ID verknüpfte Tabelle kann auf diese Weise aufgeteilt werden. Auf diese Weise befinden sich grundsätzlich alle benutzerbezogenen Daten in derselben Datenbank, und selbst wenn eine Korrelation erforderlich ist, ist die Implementierung sehr einfach.

  Sie können die relevanten Informationen der horizontalen Segmentierung intuitiver über das horizontale Segmentierungsdiagramm anzeigen (Abbildung 2):

  Vorteile der horizontalen Segmentierung:

  • Die Tabellenzuordnung kann grundsätzlich auf der Datenbankseite abgeschlossen werden.

  • Nein Bei einigen Tabellen kommt es zu Engpassproblemen.

  • Die Gesamtarchitektur der Anwendungsseite weist relativ wenige Änderungen auf.

  • Nur die Segmentierung Regeln Wenn es gut definiert werden kann, ist es grundsätzlich schwierig, auf Skalierbarkeitsbeschränkungen zu stoßen.

  • Nachteile der horizontalen Segmentierung:

  Die Segmentierungsregeln sind relativ komplex und es ist schwierig, eine Segmentierungsregel zu abstrahieren, die die gesamte Datenbank erfüllen kann erhöht, und eine manuelle Positionierung ist schwieriger.

  • Der Kopplungsgrad jedes Moduls des Anwendungssystems ist hoch, was zu gewissen Schwierigkeiten bei der Migration und Aufteilung nachfolgender Daten führen kann.

  • Die Verwendung der vertikalen und horizontalen Gelenksegmentierung

  • In den beiden vorherigen Abschnitten haben wir die Implementierung der beiden Segmentierungsmethoden „vertikal“ und „horizontal“ sowie die Architekturinformationen nach der Segmentierung kennengelernt Die beiden Architekturen haben jeweils ihre eigenen Vor- und Nachteile. In tatsächlichen Anwendungsszenarien befürchte ich jedoch, dass die meisten anderen Systeme komplex sind, mit Ausnahme der Systeme, bei denen die Last nicht zu groß und die Geschäftslogik relativ einfach ist und das Skalierbarkeitsproblem durch eine der beiden oben genannten Segmentierungsmethoden gelöst werden kann Geschäftslogik und komplexe Geschäftslogik können das Skalierbarkeitsproblem nicht durch eine der oben genannten Datensegmentierungsmethoden lösen. Dies erfordert eine Kombination der beiden oben genannten Segmentierungsmethoden, und verschiedene Szenarien verwenden unterschiedliche Segmentierungsmethoden.

  In diesem Abschnitt werden die Vor- und Nachteile des vertikalen und horizontalen Slicings kombiniert, um die Gesamtarchitektur weiter zu verbessern und die Skalierbarkeit des Systems zu verbessern.

  • Im Allgemeinen ist es schwierig, alle Tabellen in der Datenbank über bestimmte (oder einige wenige) Felder zu verbinden, sodass nur eine horizontale Segmentierung der Daten nicht alle Probleme lösen kann. Vertikales Sharding kann nur einen Teil des Problems lösen. Bei Systemen mit sehr hoher Auslastung kann nicht einmal eine einzelne Tabelle ihre Last durch einen einzelnen Datenbankhost tragen. Es ist notwendig, die beiden Segmentierungsmethoden „vertikal“ und „horizontal“ zu kombinieren, um die Vorteile beider voll auszunutzen und ihre Nachteile zu vermeiden.

  Die Auslastung jedes Anwendungssystems nimmt Schritt für Schritt zu. Wenn Leistungsengpässe auftreten, entscheiden sich die meisten Architekten und Datenbankadministratoren zunächst für die vertikale Aufteilung der Daten, da dies die geringsten Kosten verursacht und am besten mit der maximalen Eingabe-Ausgabe übereinstimmt während des Berichtszeitraums angestrebte Verhältnis. Wenn das Unternehmen jedoch weiter wächst und die Systemlast weiter zunimmt, kann es nach einer gewissen Zeit der Stabilität des Systems dazu kommen, dass der vertikal geteilte Datenbankcluster erneut überlastet wird und ein Leistungsengpass auftritt.

  Wie wählt man zu diesem Zeitpunkt? Sollten wir das Modul noch einmal weiter unterteilen oder nach anderen Lösungen suchen? Wenn wir weiterhin Module unterteilen und eine vertikale Segmentierung der Daten durchführen, wie wir es am Anfang getan haben, könnten wir in naher Zukunft auf die gleichen Probleme stoßen, mit denen wir jetzt konfrontiert sind. Darüber hinaus wird die Architektur des Anwendungssystems mit der Weiterentwicklung der Module immer komplexer und das gesamte System gerät wahrscheinlich außer Kontrolle.

  Zu diesem Zeitpunkt müssen Sie die horizontale Datensegmentierung nutzen, um die aufgetretenen Probleme zu lösen. Darüber hinaus besteht bei Verwendung der horizontalen Datensegmentierung keine Notwendigkeit, die bisherigen Ergebnisse der vertikalen Datensegmentierung zu verwerfen. Stattdessen können wir die Vorteile der horizontalen Segmentierung nutzen, um die Nachteile der vertikalen Segmentierung zu vermeiden und das Problem der ständig zunehmenden Komplexität zu lösen System. Frage. Die Nachteile der horizontalen Aufteilung (die Regeln sind schwer zu vereinheitlichen) wurden auch durch die vorherige vertikale Aufteilung gelöst, wodurch die horizontale Aufteilung einfacher wird.

  Für die Beispieldatenbank wird davon ausgegangen, dass die Daten zu Beginn vertikal segmentiert waren. Als das Unternehmen jedoch weiter wuchs, kam es zu Engpässen im Datenbanksystem, und wir entschieden uns für eine Neukonstruktion der Architektur des Datenbankclusters. Wie umgestalten? Wenn man bedenkt, dass die vertikale Segmentierung von Daten bereits zuvor durchgeführt wurde und die Modulstruktur klar und deutlich ist und die Dynamik des Geschäftswachstums immer stärker wird, wird dies nicht lange anhalten, selbst wenn die Module jetzt erneut aufgeteilt werden. Daher haben wir uns entschieden, die horizontale Segmentierung auf der Grundlage der vertikalen Segmentierung durchzuführen.

  Jede Datenbank im Datenbankcluster, die einer vertikalen Segmentierung unterzogen wurde, verfügt nur über ein Funktionsmodul, und alle Tabellen in jedem Funktionsmodul sind grundsätzlich einem bestimmten Feld zugeordnet. Beispielsweise können alle Benutzermodule nach Benutzer-ID segmentiert werden, Gruppendiskussionsmodule können nach Gruppen-ID segmentiert werden und Fotoalbummodule können nach Album-ID segmentiert werden. Die endgültige Informationstabelle für Ereignisbenachrichtigungen berücksichtigt das Zeitlimit der Daten. (Greifen Sie nur auf die Informationen eines aktuellen Ereignissegments zu), diese werden nach Zeit geteilt.

  Die kombinierte Segmentierung zeigt die gesamte Architektur nach der Segmentierung:

  Tatsächlich existieren in vielen großen Anwendungssystemen grundsätzlich vertikale Segmentierung und horizontale Segmentierung und werden häufig abwechselnd durchgeführt, um die Skalierbarkeit des Systems zu erhöhen. Wenn wir uns mit unterschiedlichen Anwendungsszenarien befassen, müssen wir auch die Einschränkungen und Vorteile dieser beiden Segmentierungsmethoden vollständig berücksichtigen und unterschiedliche Methoden zu unterschiedlichen Zeiten (Lastdruck) verwenden.

  Vorteile des Joint Slicing:

  • kann die jeweiligen Vorteile des vertikalen und horizontalen Slicings voll ausnutzen, um deren jeweilige Mängel zu vermeiden;

  • maximiert die Systemskalierbarkeit.

  Nachteile von Joint Sharding:

  • Die Datenbanksystemarchitektur ist komplexer und schwieriger zu warten;

  • Die Anwendungsarchitektur ist auch komplexer.

  • Datensegmentierungs- und Integrationslösung

  In den vorherigen Kapiteln wurde deutlich, dass die Datensegmentierung über die Datenbank die Skalierbarkeit des Systems erheblich verbessern kann. Nachdem die Daten in der Datenbank jedoch nach vertikaler und/oder horizontaler Segmentierung auf verschiedenen Datenbankhosts gespeichert wurden, besteht das größte Problem für das Anwendungssystem darin, diese Datenquellen besser zu integrieren. Dies kann für viele Leser ebenfalls von großer Bedeutung sein. Eine Frage. Der Hauptinhalt dieses Abschnitts besteht darin, verschiedene Gesamtlösungen zu analysieren, die uns bei der Datensegmentierung und Datenintegration helfen können.

  Die Datenintegration lässt sich nur schwer erreichen, indem man sich auf die Datenbank selbst verlässt. Obwohl MySQL über eine Federated Storage Engine verfügt, die einige ähnliche Probleme lösen kann, ist es schwierig, sie in tatsächlichen Anwendungsszenarien gut zu nutzen. Wie können also diese auf verschiedenen MySQL-Hosts verstreuten Datenquellen integriert werden?

  Im Allgemeinen gibt es zwei Lösungen:

  Konfigurieren und verwalten Sie eine (oder mehrere) Datenquellen, die Sie in jedem Anwendungsmodul benötigen, greifen Sie direkt auf jede Datenbank zu und vervollständigen Sie die Datenintegration innerhalb des Moduls;

  Alle Datenquellen sind wird einheitlich über die Zwischen-Proxy-Schicht verwaltet, und der Back-End-Datenbankcluster ist für die Front-End-Anwendungen transparent.

  Vielleicht neigen mehr als 90 % der Menschen dazu, sich bei diesen beiden Lösungen für die zweite Lösung zu entscheiden, insbesondere wenn das System immer größer und komplexer wird. Dies ist in der Tat eine sehr richtige Wahl. Obwohl die kurzfristigen Kosten relativ hoch sein können, ist sie für die Skalierbarkeit des gesamten Systems sehr hilfreich.

  Ich werde also nicht zu viel über die erste Lösung analysieren. Konzentrieren wir uns auf die Analyse einiger Lösungen in der zweiten Idee.

  Entwickeln Sie Ihre eigene Zwischen-Proxy-Schicht

  Nachdem Sie sich entschieden haben, die Zwischen-Proxy-Schicht der Datenbank zu verwenden, um die Architekturrichtung der Datenquellenintegration zu lösen, haben viele Unternehmen (oder Unternehmen) ihre eigenen Proxy-Schicht-Anwendungen entwickelt, die ihren spezifischen Anforderungen entsprechen Anwendungsszenarien Programm.

  Die selbst entwickelte Zwischen-Proxy-Schicht kann optimal auf die Merkmale ihrer eigenen Anwendung reagieren, die Anpassung an personalisierte Anforderungen maximieren und flexibel auf Änderungen reagieren. Dies sollte der größte Vorteil der Entwicklung einer eigenen Proxy-Schicht sein.

  Wenn Sie sich dafür entscheiden, es selbst zu entwickeln und den maximalen Spaß an personalisierter Anpassung zu genießen, müssen Sie natürlich mehr Kosten in frühe Forschung und Entwicklung und anschließende kontinuierliche Upgrades und Verbesserungen investieren, und der technische Schwellenwert kann höher sein als der von eine einfache Webanwendung höher. Bevor Sie sich für eine eigene Entwicklung entscheiden, müssen Sie daher noch eine umfassendere Bewertung durchführen.

  Da bei der Selbstentwicklung oft darüber nachgedacht wird, wie man sich besser an das eigene Anwendungssystem anpassen und die eigenen Geschäftsszenarien bewältigen kann, ist es hier nicht einfach, zu viel zu analysieren. Im Folgenden werden hauptsächlich einige derzeit beliebte Lösungen zur Datenquellenintegration analysiert.

  Verwenden Sie MySQL Proxy, um Datensegmentierung und -integration zu erreichen.

  MySQL Proxy ist ein offiziell von MySQL bereitgestelltes Datenbank-Proxy-Layer-Produkt und ist wie MySQL Server auch ein Open-Source-Produkt, das auf der Open-Source-Vereinbarung GPL basiert. Kann zur Überwachung, Analyse oder Übertragung der Kommunikation zwischen ihnen verwendet werden. Seine Flexibilität ermöglicht eine maximale Nutzung und seine aktuellen Funktionen umfassen hauptsächlich Verbindungsrouting, Abfrageanalyse, Abfragefilterung und -änderung, Lastausgleich und grundlegende HA-Mechanismen.

  Tatsächlich verfügt MySQL Proxy selbst nicht über alle oben genannten Funktionen, bietet jedoch die Grundlage für die Implementierung der oben genannten Funktionen. Um diese Funktionen zu realisieren, müssen wir auch selbst LUA-Skripte schreiben.

  MySQL Proxy stellt tatsächlich einen Verbindungspool zwischen der Clientanforderung und MySQL Server her. Alle Clientanforderungen werden an MySQL Proxy gesendet. Anschließend führt MySQL Proxy eine entsprechende Analyse durch, um festzustellen, ob es sich um Lesevorgänge oder Schreibvorgänge handelt, und verteilt sie an den entsprechenden MySQL-Server. Bei Slave-Clustern mit mehreren Knoten kann auch ein Lastausgleich erreicht werden. Wie zum Beispiel das grundlegende Architekturdiagramm von MySQL Proxy (Abbildung 4):

  Anhand des obigen Architekturdiagramms können Sie die Position von MySQL Proxy in praktischen Anwendungen und seine grundlegenden Funktionen deutlich erkennen. Die detaillierten Implementierungsdetails von MySQL Proxy werden ausführlich und in Beispielen in der offiziellen MySQL-Dokumentation vorgestellt. Interessierte Leser können es direkt von der offiziellen MySQL-Website kostenlos herunterladen oder online lesen, daher werde ich hier nicht auf Details eingehen.

  Verwenden Sie Amoeba, um eine Datensegmentierung zu erreichen.

  Amoeba ist ein Open-Source-Framework, das auf Java basiert und sich auf die Lösung von Proxy-Programmen für die Integration verteilter Datenbankdatenquellen konzentriert. Es basiert auf der Open-Source-Vereinbarung GPL3. Derzeit verfügt Amoeba bereits über Abfragerouting, Abfragefilterung, Lese-/Schreibtrennung, Lastausgleich und HA-Mechanismus sowie andere verwandte Inhalte, wie in Abbildung 5 dargestellt.

  Amoeba löst hauptsächlich die folgenden Probleme:

  • Integration komplexer Datenquellen nach der Datensegmentierung;

  • Bereitstellung von Datensegmentierungsregeln und Reduzierung der Auswirkungen von Datensegmentierungsregeln auf die Datenbank;

  • Reduzierung der Anzahl Verbindungen zwischen der Datenbank und dem Client;

  • Getrenntes Routing für Lesen und Schreiben.

  Es ist ersichtlich, dass Amoeba genau das tut, was benötigt wird, um die Skalierbarkeit der Datenbank durch Datensegmentierung zu verbessern.

  Amoeba ist kein Proxy-Programm für die Proxy-Ebene, sondern ein Framework für die Entwicklung von Proxy-Programmen für die Datenbank-Proxy-Ebene. Derzeit werden zwei Proxy-Programme auf Basis von Amoeba entwickelt: Amoeba für MySQL und Amoeba für Aladin.

  Amoeba For MySQL ist eine Lösung speziell für MySQL-Datenbanken. Das von der Front-End-Anwendung angeforderte Protokoll und die Datenquellendatenbank für die Back-End-Verbindung müssen MySQL sein. Für jede Client-Anwendung gibt es keinen Unterschied zwischen Amoeba For MySQL und einer MySQL-Datenbank. Jede Client-Anfrage, die das MySQL-Protokoll verwendet, kann von Amoeba For MySQL analysiert und entsprechend verarbeitet werden. Amoeba For kann uns die Architekturinformationen von Amoeba For MySQL nennen (aus dem Amoeba-Entwicklerblog):

  Amoeba For Aladin ist ein Proxy-Programm, das umfassender anwendbar und leistungsfähiger ist. Es kann gleichzeitig eine Verbindung zu Datenquellen in verschiedenen Datenbanken herstellen, um Dienste für Front-End-Anwendungen bereitzustellen, akzeptiert jedoch nur Client-Anwendungsanforderungen, die dem MySQL-Protokoll entsprechen. Mit anderen Worten: Solange die Front-End-Anwendung über das MySQL-Protokoll verbunden ist, analysiert Amoeba For Aladin automatisch die Query-Anweisung und identifiziert anhand der angeforderten Daten automatisch, auf welchem ​​physischen Host welcher Art von Datenbank sich die Query-Datenquelle befindet die Query-Anweisung. Das Architekturdiagramm von Amoeba For Aladdin (Abbildung 6) zeigt die Architekturdetails von Amoeba For Aladin (aus dem Amoeba Developer Blog).

  Auf den ersten Blick scheinen die beiden genau gleich zu sein. Wenn Sie genau hinschauen, werden Sie feststellen, dass der Hauptunterschied zwischen den beiden darin besteht, dass nach der Verarbeitung durch den MySQL-Protokolladapter die Datenquellendatenbank anhand der Analyseergebnisse bestimmt wird und dann ein bestimmter JDBC-Treiber und ein entsprechendes Protokoll für die Verbindung ausgewählt werden die Backend-Datenbank.

  Tatsächlich haben Sie die Eigenschaften von Amoeba möglicherweise anhand der beiden oben genannten Architekturdiagramme entdeckt. Zusätzlich zur Auswahl der beiden bereits bereitgestellten Produkte, Für MySQL und Für Aladin, können wir dies auch basierend tun Durch die sekundäre Entwicklung können Sie ein Proxy-Programm erhalten, das besser zu Ihren eigenen Anwendungsmerkmalen passt.

  Aber für die Verwendung einer MySQL-Datenbank können sowohl Amoeba For MySQL als auch Amoeba For Aladin gut verwendet werden. Wenn man bedenkt, dass ein System natürlich mit zunehmender Komplexität einen gewissen Leistungsverlust erleidet und die Wartungskosten natürlich höher ausfallen. Wenn Sie nur die MySQL-Datenbank verwenden müssen, wird daher empfohlen, Amoeba für MySQL zu verwenden.

  Amoeba für MySQL ist sehr einfach zu verwenden. Es gibt insgesamt 4 Dateien:

  • amoeba.xml – die Hauptkonfigurationsdatei, die alle Datenquellen und Amoeba selbst konfiguriert ;

  • rule.xml – Konfigurieren Sie die Informationen aller Abfrage-Routing-Regeln;

  • functionMap.xml – Konfigurieren Sie die Java-Implementierungsklasse, die der Funktion in Query entspricht;

  • rullFunctionMap.xml – Konfigurieren Sie die Implementierung Klasse spezifischer Funktionen, die in Routing-Regeln verwendet werden müssen.

  Wenn Ihre Regeln nicht zu komplex sind, genügt im Grunde die Verwendung der ersten beiden der vier oben genannten Profile. Häufig verwendete Funktionen von Proxy-Programmen, wie Lese-/Schreibtrennung, Lastausgleich und andere Konfigurationen, werden alle in amoeba.xml konfiguriert. Darüber hinaus unterstützt Amoeba bereits das automatische Routing für die vertikale und horizontale Segmentierung von Daten. Routing-Regeln können in der Datei „rule.xml“ festgelegt werden.

  Verwenden Sie HiveDB, um Datensegmentierung und -integration zu erreichen

  Wie der vorherige MySQL-Proxy und Amoeba ist auch HiveDB ein Java-basiertes Open-Source-Framework, das Datensegmentierung und -integration für MySQL-Datenbanken ermöglicht. Das aktuelle HiveDB unterstützt jedoch nur die horizontale Segmentierung von Daten. Es löst hauptsächlich die Probleme der Datenbankskalierbarkeit und des leistungsstarken Datenzugriffs bei großen Datenmengen und unterstützt gleichzeitig Datenredundanz und grundlegende HA-Mechanismen.

  Der Implementierungsmechanismus von HiveDB unterscheidet sich etwas von MySQL Proxy und Amoeba. Es verwendet nicht die Replikationsfunktion von MySQL, sondern implementiert einen eigenen Datenredundanzmechanismus, und die zugrunde liegende Schicht basiert hauptsächlich auf der Datensegmentierung im Ruhezustand arbeiten.

  In HiveDB werden Daten über verschiedene benutzerdefinierte Partitionsschlüssel (d. h. die Formulierung von Datensegmentierungsregeln) auf mehrere MySQL-Server verteilt. Wenn Sie während des Zugriffs eine Abfrageanforderung ausführen, werden die Filterbedingungen automatisch analysiert, Daten werden von mehreren MySQL-Servern parallel gelesen und die Ergebnismenge wird zusammengeführt und an die Clientanwendung zurückgegeben.

  Rein aus funktionaler Sicht ist HiveDB möglicherweise nicht so leistungsfähig wie MySQL Proxy und Amoeba, aber seine Datensegmentierungsideen unterscheiden sich nicht wesentlich von den beiden vorherigen. Darüber hinaus handelt es sich bei HiveDB nicht nur um Inhalte, die von Open-Source-Enthusiasten geteilt werden, sondern um ein Open-Source-Projekt, das von kommerziellen Unternehmen unterstützt wird.

  Das HiveDB-Architekturdiagramm (Abbildung 7) auf der offiziellen HiveDB-Website beschreibt die grundlegenden Informationen zur Datenorganisation von HiveDB. Obwohl es die Architekturinformationen nicht im Detail anzeigen kann, kann es grundsätzlich seine einzigartigen Funktionen in der Datensegmentierung zeigen.

  Andere Lösungen für die Datensegmentierung und -integration

  Zusätzlich zu den verschiedenen oben vorgestellten Gesamtlösungen für die Datensegmentierung und -integration gibt es viele andere Lösungen, wie z. B. basierend auf MySQL Proxy. Weitere Erweiterungen für HSCALE, Spock Proxy, erstellt mit Rails , Pyshards basierend auf Pathon und mehr.

  Unabhängig davon, für welche Lösung Sie sich entscheiden, sollte sich die allgemeine Designidee grundsätzlich überhaupt nicht ändern. Das heißt, durch die vertikale und horizontale Segmentierung der Daten sollten die allgemeinen Servicefunktionen der Datenbank verbessert werden, sodass die gesamten Erweiterungsmöglichkeiten verbessert werden des Anwendungssystems maximiert und so komfortabel wie möglich erweitert werden.

  Solange die Probleme der Datensegmentierung und Datenquellenintegration durch die Proxy-Anwendung der mittleren Schicht gut gelöst werden, ist die lineare Erweiterungsfähigkeit der Datenbank genauso praktisch wie die Anwendung: einfach durch Hinzufügen eines kostengünstigen PC-Serverservers, der Datenbank kann linear erhöht werden. Die gesamten Servicefunktionen des Clusters verhindern, dass die Datenbank leicht zum Leistungsengpass des Anwendungssystems wird.

  Mögliche Probleme bei der Datensegmentierung und -integration

  Hier sollte jeder ein gewisses Verständnis für die Implementierung der Datensegmentierung und -integration haben. Vielleicht haben viele Leser grundsätzlich verschiedene Lösungen ausgewählt, nachdem sie eine geeignete Lösung gefunden haben Für Ihr eigenes Anwendungsszenario besteht der nächste Schritt hauptsächlich darin, die Implementierung vorzubereiten.

  Vor der Umsetzung des Datensegmentierungsplans müssen noch einige mögliche Probleme analysiert werden. Im Allgemeinen können folgende Hauptprobleme auftreten:

  • Das Problem der Einführung verteilter Transaktionen;

  • Das Problem der knotenübergreifenden Zusammenführungssortierung; Paging.

  • Einführung in das Problem verteilter Transaktionen

  • Sobald die Daten aufgeteilt und auf mehreren MySQL-Servern gespeichert werden, kann dies dazu führen, egal wie perfekt die Aufteilungsregeln gestaltet sind (es gibt tatsächlich keine perfekte Aufteilungsregel). Die an einigen früheren Transaktionen beteiligten Daten befinden sich nicht mehr auf demselben MySQL-Server.

  Wenn die Anwendung in einem solchen Szenario immer noch der alten Lösung folgt, müssen verteilte Transaktionen eingeführt werden, um das Problem zu lösen. Unter den verschiedenen MySQL-Versionen bieten nur Versionen ab MySQL 5.0 Unterstützung für verteilte Transaktionen, und derzeit bietet nur Innodb Unterstützung für verteilte Transaktionen. Selbst wenn wir jedoch eine Version von MySQL verwenden, die verteilte Transaktionen unterstützt, und auch die Innodb-Speicher-Engine verwenden, verbraucht die verteilte Transaktion selbst viele Systemressourcen und die Leistung ist in Bezug auf die Ausnahmebehandlung nicht sehr hoch Es wird viele Probleme mit sich bringen, die schwer zu kontrollieren sind.

  Was tun? Tatsächlich kann dieses Problem durch eine Problemumgehung gelöst werden. Die erste zu berücksichtigende Frage ist: Ist die Datenbank der einzige Ort, an dem Transaktionen gelöst werden können? Tatsächlich ist dies nicht der Fall. Dies kann durch die Kombination von Datenbank und Anwendung gelöst werden. Jede Datenbank löst ihre eigenen Transaktionen auf und Anwendungen steuern Transaktionen in mehreren Datenbanken.

  Mit anderen Worten: Solange wir dazu bereit sind, können wir eine über mehrere Datenbanken verteilte Transaktion in mehrere kleine Transaktionen aufteilen, die sich nur in einer einzigen Datenbank befinden, und jede kleine Transaktion über die Anwendung steuern. Dies setzt natürlich voraus, dass die Anwendung ausreichend robust ist, und bringt natürlich auch einige technische Schwierigkeiten mit sich.

  Probleme mit knotenübergreifendem Join

  Das Obige hat die Probleme vorgestellt, die zu verteilten Transaktionen führen können. Schauen wir uns nun die Probleme an, die einen knotenübergreifenden Join erfordern. Nach der Aufteilung der Daten können einige alte Join-Anweisungen möglicherweise nicht mehr verwendet werden, da die vom Join verwendete Datenquelle möglicherweise auf mehrere MySQL-Server aufgeteilt wird.

  Was tun? Wenn dieses Problem aus Sicht der MySQL-Datenbank direkt auf der Datenbankseite gelöst werden muss, kann es meiner Meinung nach nur über Federated, eine spezielle Speicher-Engine von MySQL, gelöst werden. Die Federated Storage Engine ist MySQLs Lösung für Probleme, die denen von Oracles DB Link ähneln. Der Hauptunterschied zu Oracle DB Link besteht darin, dass Federated eine Kopie der Definitionsinformationen der Remote-Tabellenstruktur lokal speichert. Auf den ersten Blick ist Federated tatsächlich eine sehr gute Lösung für knotenübergreifendes Joinen. Wir sollten uns aber auch darüber im Klaren sein, dass sich die Definitionsinformationen der lokalen Tabelle nicht entsprechend ändern, wenn sich die Struktur der Remote-Tabelle ändert. Wenn die Definitionsinformationen der lokalen föderierten Tabelle beim Aktualisieren der Remote-Tabellenstruktur nicht aktualisiert werden, wird die Abfrage möglicherweise falsch ausgeführt und es können keine korrekten Ergebnisse erzielt werden.

  Um diese Art von Problem zu lösen, wird empfohlen, es über das Anwendungsprogramm zu lösen. Rufen Sie zunächst den Treiberergebnissatz vom MySQL-Server ab, auf dem sich die Treibertabelle befindet, und rufen Sie dann die entsprechenden Daten vom MySQL-Server ab wo sich die gesteuerte Tabelle basierend auf dem steuernden Ergebnissatz befindet. Viele Leser denken vielleicht, dass dies gewisse Auswirkungen auf die Leistung haben wird. Ja, es wird tatsächlich gewisse negative Auswirkungen haben, aber ansonsten gibt es im Grunde nicht viele andere bessere Lösungen. Darüber hinaus kann die Auslastung jedes MySQL-Servers besser kontrolliert werden, nachdem die Datenbank gut erweitert wurde. Bei einer einzelnen Abfrage kann die Antwortzeit etwas höher sein als vor der Nichtsegmentierung, sodass die Leistung beeinträchtigt wird zu groß. Darüber hinaus ist die Nachfrage nach solchen knotenübergreifenden Verknüpfungen nicht allzu groß und kann im Vergleich zur Gesamtleistung nur einen kleinen Teil ausmachen. Daher lohnt es sich im Interesse der Gesamtleistung tatsächlich, gelegentlich ein wenig zu opfern. Schließlich ist die Systemoptimierung selbst ein Prozess mit vielen Kompromissen und Abwägungen.

  Knotenübergreifendes Zusammenführungs- und Paging-Problem

  Sobald die Daten horizontal aufgeteilt sind, kann es sein, dass nicht nur der knotenübergreifende Join nicht normal ausgeführt werden kann, sondern auch die Datenquelle einiger Abfrageanweisungen zum Sortieren und Paging Bei mehreren Knoten hat dies auch zur Folge, dass diese Sortier- und Paging-Abfragen nicht normal weiterlaufen können. Tatsächlich ist dies dasselbe wie ein knotenübergreifender Join. Die Datenquelle ist auf mehreren Knoten vorhanden und muss durch eine Abfrage gelöst werden, bei der es sich um einen knotenübergreifenden Join-Vorgang handelt. Ebenso kann Federated das Problem teilweise lösen, die Risiken sind jedoch dieselben. Es gibt jedoch einen Unterschied: Join hat häufig eine treibergesteuerte Beziehung, sodass das Lesen von Daten zwischen den mehreren beteiligten Tabellen im Allgemeinen eine sequentielle Beziehung aufweist. Beim Sortieren und Paging handelt es sich jedoch grundsätzlich um eine Tabelle (oder eine Ergebnismenge), und es besteht keine sequentielle Beziehung, sodass der Prozess des Abrufens von Daten aus mehreren Datenquellen vollständig parallel erfolgen kann . Auf diese Weise kann die Datenabrufeffizienz sortierter Paging-Daten höher sein als bei datenbankübergreifendem Join, sodass der verursachte Leistungsverlust relativ gering ist. In einigen Fällen kann es effizienter sein als in der Originaldatenbank ohne Datensegmentierung. Unabhängig davon, ob es sich um eine knotenübergreifende Verknüpfung oder eine knotenübergreifende Sortierung und Paging handelt, verbraucht der Anwendungsserver natürlich mehr Ressourcen, insbesondere Speicherressourcen, da für das Lesen, Zugreifen und Zusammenführen der Ergebnismenge mehr Daten erforderlich sind als ohne Verarbeitung der Zusammenführung . .

Das obige ist der detaillierte Inhalt vonSo implementieren Sie die Datensegmentierung in MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!