Strategien zur Lösung technischer Schwierigkeiten in MySQL-Datenbank-Unterdatenbanken und Tabellen-Untertabellen

MySQL-Datenbank-Sub-Datenbank-Sub-Tabellenlösung: Sobald die Datenbank zu groß ist, insbesondere wenn Schreibvorgänge zu häufig sind und es schwierig ist, sie von einem Host zu unterstützen, werden wir immer noch mit Erweiterungsengpässen konfrontiert. Zu diesem Zeitpunkt müssen wir andere technische Mittel finden, um diesen Engpass zu lösen, bei dem es sich um die schlechte Datensegmentierungstechnologie handelt, die wir in diesem Kapitel vorstellen werden.

MySQL-Datenbanksegmentierung

Vorwort

Die durch die MySQLReplication-Funktion erreichte Erweiterung wird immer durch die Größe der Datenbank begrenzt. Sobald die Datenbank zu groß ist, insbesondere wenn die Schreibvorgänge zu häufig sind und es schwierig ist, sie von einem Host zu unterstützen, wird es immer noch zu Erweiterungsengpässen kommen. Zu diesem Zeitpunkt müssen wir andere technische Mittel finden, um diesen Engpass zu lösen, bei dem es sich um die schlechte Datensegmentierungstechnologie handelt, die wir in diesem Kapitel vorstellen werden.

Was ist Datensegmentierung?

Viele Leser haben möglicherweise schon oft verwandte Artikel über Datensegmentierung im Internet oder in Zeitschriften gesehen, aber in einigen Artikeln wird es einfach als Datensegmentierung bezeichnet. Tatsächlich ist das Konzept dasselbe, egal ob man es Sharding von Daten oder Segmentierung von Daten nennt.

Einfach ausgedrückt bedeutet dies, die Daten, die wir in derselben Datenbank speichern, unter bestimmten spezifischen Bedingungen auf mehrere Datenbanken (Hosts) zu verteilen, um den Effekt der Lastverteilung auf ein einzelnes Gerät zu erzielen. Die Datensegmentierung kann auch die Gesamtverfügbarkeit des Systems nach dem Absturz eines einzelnen Geräts verbessern. Nur ein Teil der Gesamtdaten ist nicht verfügbar, nicht alle Daten.

Das Sharding von Daten basiert auf der Art der Sharding-Regel. Es kann in zwei Segmentierungsmodi unterteilt werden.

Eine davon ist die Aufteilung in verschiedene Datenbanken (Hosts) nach verschiedenen Tabellen (oder Schemas). Diese Art der Aufteilung kann als vertikale (vertikale) Aufteilung der Daten bezeichnet werden. Die andere besteht darin, die Daten in derselben Tabelle gemäß bestimmten Bedingungen basierend auf der logischen Beziehung der Daten in der Tabelle auf mehrere Datenbanken (Hosts) aufzuteilen. Eine solche Segmentierung wird als horizontale (horizontale) Segmentierung von 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 eine sehr geringe Kopplung zwischen verschiedenen Unternehmen. Ein System mit sehr wenig Interaktion und sehr klarer Geschäftslogik. In einem solchen System ist es sehr einfach, die von verschiedenen Geschäftsmodulen verwendeten Tabellen in verschiedene Datenbanken aufzuteilen. Aufteilung nach verschiedenen Tabellen. Auch die Auswirkungen auf die Anwendung werden geringer und die Aufteilungsregeln werden einfacher und klarer.

Die horizontale Segmentierung wird mit der vertikalen Segmentierung verglichen. Relativ gesehen ist es etwas komplizierter. Da verschiedene Daten in derselben Tabelle in verschiedene Datenbanken aufgeteilt werden müssen, sind die Aufteilungsregeln selbst komplizierter als die Aufteilung basierend auf Tabellennamen, und auch die spätere Datenpflege wird komplizierter.

Wenn die Datenmenge und der Zugriff auf eine (oder mehrere) unserer Tabellen besonders groß sind und die Leistungsanforderungen nach dem vertikalen Slicing auf einem unabhängigen Gerät immer noch nicht erfüllt werden können, müssen wir das vertikale und horizontale Slicing durchführen kombiniert werden. Zuerst vertikal, dann horizontal schneiden. Nur so können wir das Leistungsproblem einer so großen Tabelle lösen.

Nachfolgend führen wir eine entsprechende Analyse der Architekturimplementierung der drei Datensegmentierungsmethoden der vertikalen, horizontalen und kombinierten Segmentierung sowie der Integration der segmentierten Daten durch.

Vertikale Segmentierung von Daten

Schauen wir uns zunächst an, was die vertikale Segmentierung von Daten ist. Vertikale Aufteilung der Daten. Man kann es auch als vertikale Segmentierung bezeichnen. Stellen Sie sich eine Datenbank vor, die aus vielen „Datenblöcken“ (Tabellen) besteht, jeweils ein Block. Wir schneiden diese „Datenblöcke“ vertikal auf und verteilen sie auf mehrere Datenbankhosts. Eine solche Segmentierungsmethode ist eine vertikale (längsgerichtete) Datensegmentierung.

Ein Anwendungssystem mit besserem architektonischen Design. Seine Gesamtfunktion muss aus vielen Funktionsmodulen bestehen. Die von jedem Funktionsmodul benötigten Daten entsprechen einer oder mehreren Tabellen in der Datenbank.

Je einheitlicher und weniger Interaktionspunkte zwischen den einzelnen Funktionsmodulen im Architekturdesign sind, desto geringer ist die Kopplung des Systems und desto besser ist die Wartbarkeit und Skalierbarkeit jedes Moduls des Systems. So ein System. Es wird einfacher sein, eine vertikale Segmentierung der Daten zu erreichen.

Wenn unsere Funktionsmodule klarer sind und die Kopplung geringer ist, lassen sich die Regeln für die vertikale Datensegmentierung leichter definieren. Die Daten können nach Funktionsmodulen segmentiert werden. Die Daten verschiedener Funktionsmodule werden auf verschiedenen Datenbankhosts gespeichert, wodurch das Vorhandensein datenbankübergreifender Verknüpfungen leicht vermieden werden kann. Gleichzeitig ist auch die Systemarchitektur sehr klar.

Natürlich. Für ein System ist es sehr schwierig, die von allen Funktionsmodulen verwendeten Tabellen völlig unabhängig zu machen, ohne dass für Join-Operationen auf die Tabellen des anderen Moduls oder auf die Tabellen zweier Module zugegriffen werden muss. In diesem Fall müssen wir anhand des tatsächlichen Anwendungsszenarios bewerten und abwägen. Entscheiden Sie, ob Sie die Anwendung so einrichten möchten, dass sie alle zugehörigen Daten von Tabellen speichert, die in derselben Datenbank zusammengeführt werden müssen, oder ob Sie die Anwendung viele andere Aufgaben ausführen lassen möchten, d. h. das Programm ruft Daten aus verschiedenen Datenbanken vollständig über die Modulschnittstelle ab dann im Programm Der Join-Vorgang ist abgeschlossen.

Im Allgemeinen. Angenommen, es handelt sich um ein System mit relativ geringer Auslastung und Tabellenzuordnungen sind sehr häufig. Dann könnte die Datenbank nachgeben. Die Lösung, mehrere zusammengehörige Module zusammenzuführen, um die Arbeit der Anwendung zu reduzieren, kann den Arbeitsaufwand noch weiter reduzieren. ist eine praktikable Lösung.

Natürlich. Durch die Konzession der Datenbank, die es mehreren Modulen ermöglicht, Datenquellen zentral zu teilen, wird tatsächlich kurzzeitig die Entwicklung einer verstärkten Kopplung der einzelnen Modularchitekturen eingeleitet, was die zukünftige Architektur immer schlechter machen kann. Insbesondere wenn ein bestimmtes Entwicklungsstadium erreicht ist, stellt sich heraus, dass die Datenbank dem durch diese Tabellen verursachten Druck nicht standhalten kann. Ich muss mich wieder der Zeit der Trennung stellen. Die Kosten des Strukturwandels können viel höher sein als die anfänglichen Kosten.

Also. Wenn die Datenbank vertikal segmentiert ist, ist es ein herausforderndes Problem, wie und in welchem ​​Umfang sie segmentiert wird. Dies kann nur durch die Abwägung von Kosten und Nutzen aller Aspekte in tatsächlichen Anwendungsszenarien erreicht werden. Nur dann können Sie einen Split-Plan analysieren, der wirklich zu Ihnen passt.

Lassen Sie uns beispielsweise kurz die Beispieldatenbank des in diesem Buch verwendeten Demonstrationssystems analysieren. Entwerfen Sie dann eine einfache Segmentierungsregel, um eine vertikale Aufteilung durchzuführen.

Systemfunktionen lassen sich grundsätzlich in vier Funktionsmodule unterteilen: Benutzer, Gruppennachrichten, Fotoalben und Ereignisse. Sie entsprechen beispielsweise den folgenden Tabellen:

1. Benutzermodultabelle: user, user_profile, user_group, user_photo_album

2. Gruppendiskussionstabelle: groups, group_message, group_message_content, top_message

3. Fotoalbum-bezogene Tabelle: Foto, Fotoalbum, Fotoalbum_Beziehung, Fotokommentar

4. Ereignisinformationstabelle: Ereignis

Auf den ersten Blick kann kein Modul unabhängig von anderen Modulen existieren. Es gibt Beziehungen zwischen Modulen. Könnte es sein, dass es nicht geteilt werden kann?

Natürlich nicht. Lassen Sie uns eine etwas tiefergehende Analyse durchführen und wir werden 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 Schnittstellen zwischen Modulen wird keine allzu großen Probleme bereiten.

◆ Das Fotoalbum-Modul ist nur über den Benutzer mit dem Benutzermodul verbunden. Die Zuordnung zwischen diesen beiden Modulen hängt im Wesentlichen mit dem Inhalt über die Benutzer-ID zusammen. Einfach und klar, die Schnittstelle ist klar;

◆ Das Ereignismodul kann sich auf jedes Modul beziehen, es konzentriert sich jedoch nur auf die ID-Informationen der Objekte in jedem Modul. Es kann auch sehr einfach aufgeteilt werden.

Also. Unser erster Schritt kann darin bestehen, die Datenbank vertikal nach Tabellen aufzuteilen, die sich auf Funktionsmodule beziehen. Die an jedem Modul beteiligten Tabellen werden in einer separaten Datenbank gespeichert, und die Tabellenbeziehungen zwischen Modulen werden über Schnittstellen auf der Seite des Anwendungssystems verwaltet. Zum Beispiel, wie Sie im Bild unten sehen können:

Nach einer solchen vertikalen Segmentierung. Dienste, die bisher nur über eine Datenbank verfügbar waren. Zur Bereitstellung von Diensten wurde es in vier Datenbanken aufgeteilt, und die Dienstfunktionen wurden natürlich um ein Vielfaches erhöht.

Vorteile der vertikalen Segmentierung

◆ Die Datenbankaufteilung ist einfach und klar, und die Aufteilungsregeln sind klar

◆ Anwendungsmodule sind klar und leicht zu integrieren.

◆ Die Datenpflege ist bequem und leicht zu finden.

Nachteile des vertikalen Shardings

◆ Einige Tabellenzuordnungen können nicht auf Datenbankebene abgeschlossen werden. Es muss im Programm abgeschlossen werden.

◆ Bei Tabellen, auf die extrem häufig zugegriffen wird und die große Datenmengen aufweisen, kommt es immer noch zu einer Leistungsflaute, die möglicherweise nicht unbedingt den Anforderungen entspricht.

◆ Die Transaktionsverarbeitung ist relativ komplexer.

◆ Nachdem das Sharding ein bestimmtes Niveau erreicht hat, stößt die Skalierbarkeit auf Einschränkungen.

◆ Übermäßiges Sharding kann dazu führen, dass Systemübergänge komplex werden und schwer zu pflegen.

Für die vertikale Segmentierung, bei der es zu Datensegmentierungs- und Transaktionsproblemen kommen kann, 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 dadurch tatsächlich die Gesamtzahl der Vorgänge in der Datenbank erhöht wird, ist dies im Hinblick auf die allgemeine Skalierbarkeit des Systems und die Modularisierung der Architektur beabsichtigt. Die Einzelreaktionszeit einiger Vorgänge kann sich geringfügig verlängern. Es ist jedoch sehr wahrscheinlich, dass die Gesamtleistung des Systems bis zu einem gewissen Grad verbessert wird. Und das Problem des Erweiterungsengpasses. Dies kann nur überwunden werden, indem man sich auf die horizontale Datensegmentierungsarchitektur verlässt, die im nächsten Abschnitt vorgestellt wird.

Horizontale Segmentierung von Daten

Im obigen Abschnitt wird die vertikale Segmentierung von Daten analysiert und vorgestellt. Unter vertikaler Segmentierung von Daten kann im Grunde genommen einfach die Segmentierung von Daten nach Tabellen und Modulen verstanden werden, während bei der horizontalen Segmentierung nicht mehr nach Tabellen oder Funktionsmodulen segmentiert wird. Im Allgemeinen besteht einfaches horizontales Sharding hauptsächlich darin, eine Tabelle mit äußerst mittelmäßigem Zugriff gemäß bestimmten Regeln eines bestimmten Felds in mehrere Tabellen aufzuteilen. Jede Tabelle enthält einen Teil der Daten.

Einfach gesagt. Wir können die horizontale Segmentierung von Daten als Segmentierung nach Datenzeilen verstehen. Dies bedeutet, dass einige Zeilen in der Tabelle in eine Datenbank aufgeteilt werden und einige andere Zeilen in andere Datenbanken aufgeteilt werden. Um leicht zu bestimmen, in welche Datenbank jede Datenzeile unterteilt ist, muss die Aufteilung natürlich immer nach bestimmten Regeln durchgeführt werden.

Wenn ein numerisches Feld modulo eine bestimmte Zahl ist, der Bereich eines Zeitfelds. Oder der Hashwert eines Zeichentypfelds. Es wird davon ausgegangen, dass die meisten Kerntabellen im gesamten System über ein bestimmtes Feld verknüpft werden können. Dann ist dieses Feld natürlich die beste Wahl für die horizontale Partitionierung. Wenn es sehr speziell ist und nicht verwendet werden kann, können Sie natürlich nur ein anderes auswählen.

Generell sind Websites vom Typ Web2.0 heute im Internet sehr beliebt. Grundsätzlich können die meisten Daten über Mitgliedsbenutzerinformationen verknüpft werden, und viele Kerntabellen eignen sich möglicherweise sehr gut für die horizontale Segmentierung von Daten über Mitglieds-IDs.

Und wie ein Forum-Community-Diskussionssystem. Noch einfacher ist die Segmentierung. Es ist sehr einfach, die Daten horizontal nach der Forumsnummer zu segmentieren.

Nach der Segmentierung findet grundsätzlich keine Interaktion zwischen Bibliotheken statt.

Wie zum Beispiel unser Demosystem. Alle Daten sind den Benutzern zugeordnet. Dann können wir eine horizontale Aufteilung basierend auf Benutzern durchführen und die Daten verschiedener Benutzer in verschiedene Datenbanken aufteilen. Der einzige Unterschied besteht natürlich darin, dass die Gruppentabelle im Benutzermodul keinen direkten Bezug zu Benutzern hat. Daher können Gruppen nicht horizontal nach Benutzern aufgeteilt werden. Bei Tischen unter solch besonderen Umständen können wir völlig alleine dastehen. Separat in einer separaten Datenbank abgelegt.

Tatsächlich kann man sagen, dass dieser Ansatz die im vorherigen Abschnitt eingeführte Methode der „vertikalen Segmentierung von Daten“ nutzt. Im nächsten Abschnitt werde ich die gemeinsame Segmentierungsmethode, die gleichzeitig für die vertikale Segmentierung und die horizontale Segmentierung verwendet wird, detaillierter vorstellen.

Für unsere Demo-Beispieldatenbank können die meisten Tabellen basierend auf der Benutzer-ID horizontal segmentiert 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 segmentiert werden. Auf diese Weise werden grundsätzlich alle nutzerbezogenen Daten erfasst. Sie befinden sich alle in derselben Datenbank, und selbst wenn sie verknüpft werden müssen, können sie sehr einfach verknüpft werden.

Mithilfe der folgenden Abbildung können wir die relevanten Informationen der horizontalen Segmentierung intuitiver anzeigen: Vorteile der horizontalen Segmentierung

◆ Die Tabellenzuordnung kann grundsätzlich in erfolgen Datenbank Alle End-to-End-Anwendungen sind abgeschlossen.

◆ Bei einigen sehr großen Datenmengen und Hochlasttabellen treten keine Engpässe auf.

◆ Es gibt relativ wenige Änderungen an die Gesamtarchitektur des Anwendungsendes;

◆ Die Transaktionsverarbeitung ist relativ einfach

◆ Solange die Segmentierungsregeln definiert werden können. Grundsätzlich ist es schwierig, auf Skalierbarkeitseinschränkungen zu stoßen.

Nachteile des horizontalen Shardings

◆ Die Sharding-Regeln sind relativ komplexer und es ist sehr schwierig, eine Sharding-Regel zu abstrahieren, die das Ganze erfüllen kann Datenbank;

◆ Die Schwierigkeit, Daten in der späteren Zeit zu verwalten, hat zugenommen, und es ist schwieriger, die Daten manuell zu lokalisieren.

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

Die kombinierte Verwendung von vertikaler und horizontaler Segmentierung

In den beiden obigen Abschnitten. Wir haben jeweils etwas über die Implementierung der beiden Segmentierungsmethoden „vertikal“ und „horizontal“ sowie die Architekturinformationen nach der Segmentierung gelernt. Gleichzeitig wurden auch die Vor- und Nachteile der beiden Architekturen analysiert. Aber in tatsächlichen Anwendungsszenarien ist die Last außer diesen nicht zu groß. Systeme mit relativ einfacher Geschäftslogik können Skalierbarkeitsprobleme durch eine der beiden oben genannten Segmentierungsmethoden lösen. Ich befürchte, dass die meisten anderen Systeme mit einer etwas komplexeren Geschäftslogik und einer größeren Systemlast durch keine der oben genannten Datensegmentierungsmethoden eine bessere Skalierbarkeit erreichen können. Es ist notwendig, die beiden oben genannten Segmentierungsmethoden zu kombinieren und in verschiedenen Szenarien unterschiedliche Segmentierungsmethoden zu verwenden.

In diesem Abschnitt. Ich werde die Vor- und Nachteile von vertikalem und horizontalem Slicing kombinieren, um unsere Gesamtarchitektur weiter zu verbessern und die Skalierbarkeit des Systems weiter zu verbessern.

Im Allgemeinen. Es ist sehr schwierig, alle Tabellen in unserer Datenbank über ein (oder mehrere) Felder zu verbinden, daher ist es sehr schwierig, alle Probleme einfach durch horizontale Segmentierung der Daten zu lösen. 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.

Wir müssen die „vertikalen“ und „horizontalen“ Aufteilungsmethoden gleichzeitig kombinieren, um die Stärken beider voll auszunutzen und ihre Mängel zu vermeiden.

Die Auslastung jedes Anwendungssystems nimmt Schritt für Schritt zu. Wenn es zu Leistungsengpässen kommt, entscheiden sich die meisten Architekten und Datenbankadministratoren zunächst für eine vertikale Aufteilung der Daten, da dies die höchsten Kosten darstellt. Es entspricht am ehesten dem in diesem Zeitraum angestrebten maximalen Input-Output-Verhältnis. Jedoch. Da das Geschäft weiter expandiert. Wenn die Systemlast weiter zunimmt und das System eine Zeit lang stabil ist, kann es sein, dass der vertikal geteilte Datenbankcluster erneut überlastet wird und ein Leistungsengpass auftritt.

Wie sollen wir in dieser Zeit wählen? Sollten wir die Module noch einmal weiter unterteilen oder nach anderen Lösungen suchen? Unter der Annahme, dass wir weiterhin Module unterteilen und die Daten vertikal segmentieren, wie wir es zu Beginn getan haben, könnten wir in naher Zukunft auf dieselben Probleme stoßen, mit denen wir heute konfrontiert sind. Und mit der kontinuierlichen Weiterentwicklung der Module wird die Architektur des Anwendungssystems immer komplexer und es kann durchaus sein, dass das gesamte System außer Kontrolle gerät.

Zu diesem Zeitpunkt müssen wir die horizontale Segmentierung von Daten nutzen, um die hier aufgetretenen Probleme zu lösen. Darüber hinaus müssen wir die bisherigen Ergebnisse der vertikalen Datensegmentierung nicht aufheben, wenn wir die horizontale Datensegmentierung verwenden. Stattdessen nutzen wir die Vorteile der horizontalen Segmentierung, um die Nachteile der vertikalen Segmentierung zu vermeiden. Lösen Sie das Problem der zunehmenden Systemkomplexität.

Die Nachteile der horizontalen Aufteilung (die Regeln sind schwer zu vereinheitlichen) wurden auch durch die bisherige vertikale Aufteilung gelöst. Erleichtern Sie das horizontale Teilen.

Für unsere Demo-Beispieldatenbank. Nehmen Sie am Anfang an. Wir führten eine vertikale Segmentierung der Daten durch. Da das Unternehmen jedoch weiter wuchs, kam es zu Engpässen im Datenbanksystem, weshalb wir uns für eine Neukonstruktion der Datenbankcluster-Architektur entschieden. Wie umgestalten? In Anbetracht dessen, dass die vertikale Segmentierung der Daten bereits durchgeführt wurde und die Modulstruktur klar ist.

Und die Dynamik des Geschäftswachstums wird immer stärker. Auch wenn die Module jetzt noch weiter aufgeteilt werden, wird es nicht lange halten.

Wir haben uns für eine horizontale Aufteilung basierend auf der vertikalen Segmentierung entschieden.

Nach der vertikalen Aufteilung verfügt jeder Datenbankcluster nur über ein Funktionsmodul. Grundsätzlich sind alle Tabellen in jedem Funktionsmodul einem bestimmten Feld zugeordnet. Beispielsweise können alle Benutzermodule nach Benutzer-ID segmentiert werden, und Gruppendiskussionsmodule können alle nach Gruppen-ID segmentiert werden. Das Fotoalbummodul ist anhand der Album-ID segmentiert. Die endgültige Ereignisbenachrichtigungsinformationstabelle berücksichtigt das Zeitlimit der Daten (nur auf die Informationen eines aktuellen Ereignissegments wird zugegriffen) und wird daher als durch Zeit geteilt betrachtet.

Die folgende Abbildung zeigt die gesamte Architektur nach der Segmentierung:

Tatsächlich sind in vielen großen Anwendungssystemen vertikale Segmentierung und horizontale Segmentierung diese beiden Datensegmentierungsmethoden existieren grundsätzlich nebeneinander. Und es wird oft abwechselnd durchgeführt, um die Erweiterungsmöglichkeiten des Systems kontinuierlich zu erweitern. Wenn wir uns mit unterschiedlichen Anwendungsszenarien befassen, müssen wir auch die Einschränkungen und Vorteile dieser beiden Segmentierungsmethoden vollständig berücksichtigen. Verwenden Sie unterschiedliche Klebemethoden zu unterschiedlichen Zeiten (Belastungsdruck).

Vorteile des Joint Sharding

◆ Kann die Vorteile des vertikalen und horizontalen Slicings voll ausnutzen, um ihre jeweiligen Mängel zu vermeiden;

◆ Maximierung der kulturellen Verbesserung der Systemskalierbarkeit.

Nachteile des Gewerkschaftssplittings

◆ Die Datenbanksystemarchitektur ist relativ komplex. Die Wartung ist schwieriger.

◆ Die Anwendungsarchitektur ist auch relativ komplexer;

Datensegmentierungs- und Integrationslösung

Durch die vorherigen Kapitel. Wir haben bereits sehr deutlich gemacht, dass die Datensegmentierung durch die Datenbank die Skalierbarkeit des Systems erheblich verbessern kann. Nachdem die Daten in der Datenbank jedoch durch vertikale und/oder horizontale Segmentierung auf verschiedenen Datenbankhosts gespeichert wurden, besteht das größte Problem für das Anwendungssystem darin, diese Datenquellen besser zu integrieren. Vielleicht ist dies auch ein Thema, das viele Leser sehr beschäftigt. Unser Hauptaugenmerk in diesem Abschnitt liegt auf der Analyse der verschiedenen Gesamtlösungen, die uns bei der Datensegmentierung und Datenintegration helfen können.

Bei der Datenintegration ist es sehr schwierig, diesen Effekt zu 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. Es ist jedoch sehr schwierig, es in tatsächlichen Anwendungsszenarien gut zu nutzen. Wie integrieren wir also diese auf verschiedenen MySQL-Hosts verstreuten Datenquellen?

Im Allgemeinen gibt es zwei Lösungen:

1. 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.

2. Vereinheitlichen Sie die Verwaltung aller Datenquellen über die Zwischen-Proxy-Schicht. Der Back-End-Datenbankcluster ist für die Front-End-Anwendung transparent.

Vielleicht neigen mehr als 90 % der Menschen dazu, sich für die andere zu entscheiden, wenn sie mit den beiden oben genannten Lösungen konfrontiert werden, insbesondere wenn das System immer größer wird und komplexer wann.

In der Tat. Dies ist eine sehr richtige Wahl, obwohl die kurzfristigen Kosten relativ höher sein können, ist sie für die Skalierbarkeit des gesamten Systems sehr hilfreich.

Daher werde ich hier nicht zu viel auf die erste Lösung eingehen. Im Folgenden werde ich mich auf die Analyse einiger Lösungen in einer anderen Lösung konzentrieren.

★ Selbst entwickelte Zwischen-Proxy-Schicht

Nach der Entscheidung, die Zwischen-Proxy-Schicht der Datenbank zu verwenden, um die architektonische Richtung der Datenquellenintegration zu lösen, haben sich viele Unternehmen (oder Unternehmen) für die Entwicklung entschieden es selbst. Proxy-Layer-Anwendungen, die bestimmte Anwendungsszenarien erfüllen.

Durch die Entwicklung Ihrer eigenen Zwischen-Proxy-Schicht können Sie optimal auf die Besonderheiten Ihrer eigenen Anwendungen reagieren. Maximale Anpassungsmöglichkeiten erfüllen individuelle Bedürfnisse und können flexibel auf Änderungen reagieren. Dies sollte als der größte Vorteil der Entwicklung einer eigenen Proxy-Schicht angesehen werden.

Während Sie sich dafür entscheiden, selbst zu entwickeln und den Spaß an der Maximierung der personalisierten Anpassung zu genießen, müssen Sie natürlich viele andere Kosten in frühe Forschung und Entwicklung und anschließende kontinuierliche Upgrades und Verbesserungen investieren. Und die technische Schwelle selbst kann höher sein als die einfacher Webanwendungen. Daher müssen Sie vor der Entscheidung, es selbst zu entwickeln, noch eine umfassendere Bewertung durchführen.

Da Sie bei der Selbstentwicklung oft darüber nachdenken, wie Sie sich besser an Ihr eigenes Anwendungssystem anpassen und Ihre eigenen Geschäftsszenarien bewältigen können, ist es nicht einfach, hier zu viel zu analysieren. Später werden wir hauptsächlich mehrere derzeit beliebte Datenquellen-Integrationslösungen analysieren.

★ Verwenden Sie MySQLProxy, um Datensegmentierung und -integration zu erreichen

MySQLProxy ist ein offiziell von MySQL bereitgestelltes Datenbank-Proxy-Layer-Produkt und ist wie MySQLServer auch ein Open-Source-Produkt, das auf der GPL-Open-Source-Vereinbarung basiert . Kann zur Überwachung, Analyse oder Übertragung von Kommunikationsinformationen zwischen ihnen verwendet werden. Dank seiner Flexibilität können Sie es optimal nutzen. Zu den aktuellen Funktionen gehören hauptsächlich Verbindungsrouting, Abfrageanalyse, Abfragefilterung und -änderung sowie Lastausgleich. Sowie der Haupt-HA-Mechanismus usw.

Tatsächlich verfügt MySQLProxy selbst nicht über alle oben genannten Funktionen. Stattdessen stellt es die Grundlage für die Implementierung der oben genannten Funktionen dar.

Um diese Funktionen zu realisieren, müssen wir unsere eigenen LUA-Skripte schreiben.

MySQLProxy stellt tatsächlich einen Verbindungspool zwischen der Clientanforderung und MySQLServer her. Alle Client-Anfragen werden an MySQLProxy gesendet und anschließend wird die entsprechende Analyse über MySQLProxy durchgeführt. Es wird abgeleitet, ob es sich um einen Lesevorgang oder einen Schreibvorgang handelt, und an den entsprechenden MySQL-Server verteilt. Für Slave-Cluster mit mehreren Knoten kann auch ein Lastausgleich erreicht werden. Das Folgende ist das grundlegende Architekturdiagramm von MySQLProxy:

Durch das obige Architekturdiagramm. Wir können die Position von MySQLProxy in praktischen Anwendungen und die grundlegenden Dinge, die es tun kann, sehr deutlich erkennen.

Zu den spezifischeren Implementierungsdetails von MySQLProxy gibt es in der offiziellen MySQL-Dokumentation sehr spezifische Einführungen und Demonstrationsbeispiele. Interessierte Leser können es direkt kostenlos von der offiziellen MySQL-Website herunterladen oder online lesen. Ich werde hier nicht auf Papierverschwendung eingehen.

★Verwenden Sie Amoeba, um Datensegmentierung und -integration zu erreichen

Amoeba ist ein auf Java basierendes Open-Source-Framework, das sich auf die Lösung verteilter Datenbank-Datenquellen-Integration-Proxy-Programme 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.

Amoeba löst hauptsächlich die folgenden Probleme:

1. Integrieren Sie komplexe Datenquellen nach der Datensegmentierung.

2. Stellen Sie Datensegmentierungsregeln bereit die Datenbank.

3. Reduzieren Sie die Anzahl der Verbindungen zwischen der Datenbank und dem Client.

4. Lese-Schreib-Trennung-Routing

Wir können sehen, dass das, was Amoeba tut, genau das ist, was wir brauchen, um die Skalierbarkeit der Datenbank durch Datensegmentierung zu verbessern.

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

AmoebaForMySQL ist hauptsächlich 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 AmoebaForMySQL und einer MySQL-Datenbank. Jede Client-Anfrage, die das MySQL-Protokoll verwendet, kann von AmoebaForMySQL analysiert und entsprechend verarbeitet werden. Im Folgenden erfahren Sie mehr über die Architekturinformationen von AmoebaForMySQL (aus dem Amoeba-Entwicklerblog):

AmoebaForAladin ist eine breiter anwendbare Version. Ein leistungsfähigeres Proxy-Programm.

Er kann gleichzeitig eine Verbindung zu Datenquellen in verschiedenen Datenbanken herstellen, um Dienste für Front-End-Anwendungen bereitzustellen, akzeptiert jedoch nur Client-Anwendungsanfragen, die dem MySQL-Protokoll entsprechen. Mit anderen Worten: Solange die Front-End-Anwendung über das MySQL-Protokoll verbunden ist, analysiert AmoebaForAladin aktiv die Abfrageanweisung und identifiziert automatisch die Datenquelle der Abfrage basierend auf den in der Abfrageanweisung angeforderten Daten. Die folgende Abbildung zeigt die architektonischen Details von AmoebaForAladin (aus dem Amoeba-Entwicklerblog):

Auf den ersten Blick scheinen die beiden genau gleich zu sein. Bei genauerem Hinsehen werden Sie feststellen, dass der Hauptunterschied zwischen den beiden erst nach der Verarbeitung durch MySQLProtocalAdapter besteht. Die Datenquellendatenbank wird basierend auf den Analyseergebnissen abgeleitet. Wählen Sie dann einen bestimmten JDBC-Treiber und das entsprechende Protokoll aus, um eine Verbindung zur Back-End-Datenbank herzustellen.

Tatsächlich haben Sie anhand der beiden oben genannten Architekturdiagramme möglicherweise die Eigenschaften von Amoeba entdeckt. Es handelt sich lediglich um ein Entwicklungsframework. Zusätzlich zu den beiden von ihm bereitgestellten Produkten ForMySQL und ForAladin. Es kann auch entsprechende Sekundärentwicklungen auf der Grundlage seiner eigenen Bedürfnisse durchführen. Holen Sie sich ein Proxy-Programm, das besser zu unseren eigenen Anwendungsmerkmalen passt.

Bei Verwendung einer MySQL-Datenbank. Sowohl AmoebaForMySQL als auch AmoebaForAladin können sehr gut verwendet werden. Wenn man bedenkt, dass ein System natürlich mit zunehmender Komplexität einen gewissen Leistungsverlust erleidet und die Wartungskosten natürlich relativ höher sind. Wenn Sie also nur die MySQL-Datenbank verwenden müssen, empfehle ich dennoch die Verwendung von AmoebaForMySQL.

AmoebaForMySQL ist sehr einfach zu verwenden. Alle Konfigurationsdateien sind Standard-XML-Dateien und es gibt insgesamt vier Konfigurationsdateien. Dies sind:

◆ amoeba.xml: Hauptkonfigurationsdatei, konfiguriert alle Datenquellen und Amoebas eigene Parametereinstellungen.

◆ Rule.xml: Konfigurieren Sie alle Informationen zur Abfrage-Routingregel.

◆ functionMap.xml: Konfigurieren Sie die Java-Implementierungsklasse, die der Funktion in Query entspricht.

◆ rullFunctionMap.xml: Konfigurieren Sie die Implementierungsklasse bestimmter Funktionen, die in Routing-Regeln verwendet werden müssen.

Vorausgesetzt, Ihre Regeln sind nicht zu kompliziert, müssen Sie im Grunde nur die ersten beiden der oben genannten vier Konfigurationsdateien verwenden, um die gesamte Arbeit abzuschließen. Zu den von Proxy-Programmen häufig verwendeten Funktionen gehört die Trennung von Lesen und Schreiben. Lastausgleich und andere Konfigurationen werden in amoeba.xml durchgeführt. Auch. Amoeba unterstützt bereits sein eigenes aktives Routing, das vertikales und horizontales Sharding von Daten implementiert. Routing-Regeln können in der Datei „rule.xml“ festgelegt werden.

Die größten Mängel von Amoeba sind derzeit seine Online-Verwaltungsfunktionen und die Unterstützung für Transaktionen. Ich habe in der Vergangenheit während des Kommunikationsprozesses mit relevanten Entwicklern relevante Vorschläge gemacht und hoffe, ein System bereitzustellen, das diese Leistung erbringen kann Online-Wartung und -Verwaltung Das Befehlszeilen-Verwaltungstool ist praktisch für die Online-Wartung. Das erhaltene Feedback besagt, dass ein spezielles Verwaltungsmodul in den Entwicklungsplan aufgenommen wurde. Darüber hinaus ist Amoeba im Hinblick auf die Transaktionsunterstützung immer noch nicht in der Lage, dies zu tun. Selbst wenn die an Amoeba übermittelte Anfrage Transaktionsinformationen enthält, ignoriert Amoeba die transaktionsbezogenen Informationen. Nach kontinuierlicher Verbesserung glaube ich natürlich, dass die Transaktionsunterstützung definitiv eine Funktion ist, die Amoeba hinzufügen wird.

Leser können über das Benutzerhandbuch im Amoeba-Entwicklerblog (http://amoeba.sf.net) eine spezifischere Verwendung von Amoeba erfahren, die hier nicht im Detail beschrieben wird.

★Verwenden Sie HiveDB, um Datensegmentierung und -integration zu erreichen

Wie das vorherige MySQLProxy und Amoeba ist auch HiveDB ein Java-basiertes Open-Source-Framework für MySQL-Datenbanken, das Datensegmentierung und -integration ermöglicht. HiveDB unterstützt derzeit nur die horizontale Segmentierung von Daten.

Löst hauptsächlich das Problem der Datenbankskalierbarkeit und des leistungsstarken Datenzugriffs bei großen Datenmengen und unterstützt gleichzeitig Datenredundanz und den Haupt-HA-Mechanismus.

Der Implementierungsmechanismus von HiveDB unterscheidet sich etwas von MySQLProxy und Amoeba. Es verwendet nicht die Replikationsfunktion von MySQL, um Datenredundanz zu erreichen, sondern implementiert seinen eigenen Datenredundanzmechanismus, und die zugrunde liegende Schicht basiert hauptsächlich auf HibernateShards Datensegmentierungsarbeit.

In HiveDB werden Daten über verschiedene vom Benutzer definierte Partitionsschlüssel auf mehrere MySQL-Server verteilt (tatsächlich dient dies der Formulierung von Datensegmentierungsregeln). Zum Zeitpunkt des Besuchs. Beim Ausführen einer Abfrageanforderung. Es analysiert aktiv die Filterbedingungen selbst, liest Daten von mehreren MySQL-Servern parallel, führt die Ergebnismengen zusammen und gibt sie an die Clientanwendung zurück.

Rein in Bezug auf die Funktionalität ist HiveDB möglicherweise nicht so leistungsfähig wie MySQLProxy 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 Folgende ist ein Bild aus dem ersten Kapitel der offiziellen HiveDB-Website, das die grundlegenden Informationen darüber beschreibt, wie HiveDB Daten organisiert. Obwohl nicht zu viele Architekturinformationen angezeigt werden können, kann es grundsätzlich deren Verwendung in Daten zeigen . Ein einzigartiger Aspekt der Segmentierung.

★ mycat-Datenintegration: Details http://www.songwie.com/articlelist/11

★ Weitere Lösungen für Datensegmentierungs- und Integrationsmethoden

Zusätzlich zu den oben vorgestellten Gesamtlösungen für die Datensegmentierung und -integration gibt es viele andere Lösungen, die die gleiche Datensegmentierung und -integration bieten. Beispielsweise wird HSCALE basierend auf MySQLProxy weiter ausgebaut und SpockProxy wird über Rails erstellt. Sowie Pathon-basierte Pyshards und mehr.

Egal für welche Lösung Sie sich entscheiden, die Gesamtidee des Designs sollte sich im Grunde überhaupt nicht ändern. Dies dient dazu, die allgemeinen Servicefunktionen der Datenbank durch vertikale und horizontale Segmentierung der Daten zu verbessern, sodass die Gesamtskalierbarkeit des Anwendungssystems so weit wie möglich verbessert werden kann. Die Erweiterungsmethode ist so bequem wie möglich.

Solange wir die Proxy-Anwendung der mittleren Ebene verwenden, können wir die Probleme der Datensegmentierung und Datenquellenintegration besser überwinden. Dann wird die lineare Skalierbarkeit der Datenbank sehr einfach sein und genauso praktisch sein wie unsere Anwendung. Allein durch das Hinzufügen eines kostengünstigen PCServerservers kann die Gesamtdienstkapazität des Datenbankclusters linear erhöht werden, sodass die Datenbank nicht mehr so ​​leicht zum Leistungsengpass des Anwendungssystems wird.

Mögliche Probleme bei der Datensegmentierung und -integration

Hier. Jeder sollte ein gewisses Verständnis für die Implementierung der Datensegmentierung und -integration haben. Vielleicht haben viele Leser und Freunde grundsätzlich eine Lösung ausgewählt, die für ihre eigenen Anwendungsszenarien geeignet ist, basierend auf den Vor- und Nachteilen der jeweiligen Eigenschaften verschiedener Lösungen. Die anschließende Arbeit dient hauptsächlich der Vorbereitung der Implementierung.

Bevor wir den Datensegmentierungsplan implementieren, müssen wir noch einige mögliche Probleme analysieren.

Im Allgemeinen sind die Hauptprobleme, auf die wir stoßen können, die folgenden:

◆ Das Problem der Einführung verteilter Transaktionen.

◆ Das Problem der knotenübergreifenden Verknüpfung

◆ Das Problem der knotenübergreifenden Zusammenführung und Paging.

1. Das Problem der Einführung verteilter Transaktionen

Sobald die Daten segmentiert und auf mehreren MySQL-Servern gespeichert sind, egal wie perfekt unsere Segmentierungsregeln sind (eigentlich nicht). Es gibt kein Perfekt Segmentierungsregel) kann es dazu kommen, dass sich die an einigen früheren Transaktionen beteiligten Daten nicht mehr auf demselben MySQL-Server befinden.

Gehen Sie in diesem Szenario davon aus, dass unsere Anwendung immer noch der alten Lösung folgt. Dann ist es notwendig, verteilte Transaktionen einzuführen, 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. Nicht nur das. Auch wenn wir zufällig eine MySQL-Version verwenden, die verteilte Transaktionen unterstützt. Gleichzeitig wurde auch die Innodb-Speicher-Engine verwendet. Verteilte Transaktionen selbst verbrauchen viele Systemressourcen und die Leistung selbst ist nicht zu hoch. Und die Einführung verteilter Transaktionen selbst wird weitere Faktoren mit sich bringen, die im Hinblick auf die Ausnahmebehandlung schwer zu kontrollieren sind.

Was tun? Tatsächlich können wir dieses Problem durch einen Workaround lösen. Als erstes muss man sich fragen: Ist die Datenbank der einzige Ort, an dem Transaktionen aufgelöst werden können? Tatsächlich ist dies nicht der Fall. Wir können das Problem vollständig lösen, indem wir sowohl die Datenbank als auch die Anwendung kombinieren. Jede Datenbank verwaltet ihre eigenen Angelegenheiten. Verwenden Sie dann die Anwendung, um Transaktionen in mehreren Datenbanken zu steuern.

Das heißt. Nur wenn wir wollen. Es ist durchaus möglich, eine über mehrere Datenbanken verteilte Transaktion in mehrere kleine Transaktionen aufzuteilen, die nur in einer einzigen Datenbank vorhanden sind. Und nutzen Sie die Anwendung, um verschiedene kleine Transaktionen zu steuern.

Voraussetzung hierfür ist natürlich, dass unsere russische Anwendung robust genug sein muss. Natürlich wird es auch einige technische Schwierigkeiten bei der Anwendung mit sich bringen.

2. Probleme bei der knotenübergreifenden Verknüpfung

Im Folgenden werden die Probleme vorgestellt, die zu verteilten Transaktionen führen können.

Nach der Datensegmentierung. Dies kann dazu führen, dass einige alte Join-Anweisungen nicht mehr verwendet werden. Da die von Join verwendete Datenquelle möglicherweise auf mehrere MySQL-Server aufgeteilt ist.

Was soll ich tun? Wenn dieses Problem aus Sicht der MySQL-Datenbank direkt auf der Datenbankseite gelöst werden muss, kann es meiner Meinung nach nur durch 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 DBLink ähneln.

Der Hauptunterschied zu OracleDBLink 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 den knotenübergreifenden Join. Aber wir sollten uns auch darüber im Klaren sein, dass sich die Definitionsinformationen der lokalen Tabelle nicht entsprechend ändern, wenn sich die Struktur der Remote-Tabelle ändert. Es wird davon ausgegangen, dass die lokalen Definitionsinformationen der föderierten Tabelle nicht aktualisiert werden, wenn die Remote-Tabellenstruktur aktualisiert wird. Es ist sehr wahrscheinlich, dass bei der Abfrageausführung Fehler auftreten und keine korrekten Ergebnisse erzielt werden.

Um diese Art von Problem zu lösen, empfehle ich dennoch, es über das Anwendungsprogramm zu behandeln. Rufen Sie zunächst den entsprechenden Treiberergebnissatz vom MySQL-Server ab, auf dem sich die Treibertabelle befindet. Rufen Sie dann basierend auf dem Treiberergebnissatz die entsprechenden Daten vom MySQL-Server ab, auf dem sich die gesteuerte Tabelle befindet. Viele Leser denken vielleicht, dass dies einen gewissen Einfluss auf die Leistung haben wird. Ja, es wird tatsächlich einen gewissen negativen Einfluss auf die Leistung haben, aber abgesehen von dieser Methode gibt es im Grunde nicht viele andere bessere Lösungen.

Und da die Datenbank besser erweitert ist, kann die Auslastung jedes MySQL-Servers besser kontrolliert werden. Bei einer einzelnen Abfrage kann die Antwortzeit höher sein als vor der Segmentierung, sodass die negativen Auswirkungen auf die Leistung nicht allzu groß sind. ganz zu schweigen. Es gibt nicht allzu viele Anforderungen für einen knotenübergreifenden Join wie diesen. Bezogen auf die Gesamtleistung dürfte es nur ein sehr kleiner Teil sein. Im Interesse der Gesamtleistung sollten Sie also gelegentlich ein wenig Abstriche machen. Es lohnt sich tatsächlich. Schließlich ist die Systemoptimierung selbst ein Prozess mit vielen Kompromissen und Abwägungen.

3. Sortier- und Paging-Probleme bei der knotenübergreifenden Zusammenführung

Sobald die Daten horizontal aufgeteilt sind, kann nicht nur der knotenübergreifende Join nicht normal ausgeführt werden, sondern auch einige Sortier- und Paging-Abfrageanweisungen können auch in mehrere Knoten aufgeteilt werden. Die direkte Folge davon ist, dass diese Sortier- und Paging-Abfragen nicht normal weiter ausgeführt werden 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. Dabei handelt es sich um denselben Vorgang wie bei der knotenübergreifenden Verknüpfung. Ebenso kann Federated das Problem teilweise lösen. Natürlich gibt es auch Risiken.

Immer noch das gleiche Problem, was soll ich tun? Ich empfehle weiterhin, das Problem über die Anwendung zu lösen.

Wie kann man es lösen? Die Lösungsidee ähnelt im Allgemeinen der Lösung des knotenübergreifenden Joins, es gibt jedoch einen Unterschied zum knotenübergreifenden Join. Join hat oft eine treibergesteuerte Beziehung. Daher weist das Lesen von Daten zwischen mehreren am Join selbst beteiligten Tabellen im Allgemeinen eine sequentielle Beziehung auf. Beim Sortieren von Paging handelt es sich jedoch grundsätzlich um eine Tabelle (oder eine Ergebnismenge). Da an sich keine sequentielle Beziehung besteht, kann der Prozess des Datenabrufs aus mehreren Datenquellen vollständig parallelisiert werden.

Hier entlang. Wir können beim Abrufen sortierter Paging-Daten eine höhere Effizienz erzielen als beim datenbankübergreifenden Join. Daher ist der verursachte Leistungsverlust relativ gering und in einigen Fällen möglicherweise effizienter als in der Originaldatenbank ohne Datensegmentierung.

Natürlich, egal ob es sich um knotenübergreifendes Joinen oder knotenübergreifendes Sortieren und Paging handelt. Dies führt dazu, dass unser Anwendungsserver viele andere Ressourcen verbraucht, insbesondere Speicherressourcen, da der Prozess des Lesens, Zugreifens und Zusammenführens von Ergebnismengen erfordert, dass wir viel mehr Daten als zuvor verarbeiten.

Nach der Analyse dieses Punktes stellen viele Leser möglicherweise fest, dass alle oben genannten Probleme im Wesentlichen durch Anwendungen gelöst werden. Jeder fängt vielleicht an, in seinem Herzen zu murren. Liegt es daran, dass ich DBA bin und viele Dinge den Anwendungsarchitekten und Entwicklern überlasse?

Tatsächlich ist dies überhaupt nicht der Fall. Erstens liegt die Anwendung an ihrer Besonderheit. Es ist sehr einfach, eine sehr gute Skalierbarkeit zu erreichen, aber die Datenbank ist anders. Die Expansion muss auf vielen anderen Wegen erreicht werden. Und in diesem Erweiterungsprozess ist es sehr schwierig, Situationen zu vermeiden, die in einer zentralisierten Datenbank gelöst werden können, aber nach der Aufteilung in einen Datenbankcluster zu einem schwierigen Problem werden.

Um die Gesamtsystemerweiterung zu maximieren, können wir der Anwendung nur erlauben, viele andere Dinge zu tun. Um Probleme zu lösen, die durch Datenbankcluster nicht gut gelöst werden können.

Zusammenfassung

Teilen Sie einen großen MySQLServer mithilfe der Datensegmentierungstechnologie in mehrere kleine MySQLServer auf, wodurch nicht nur das Problem des Schreibleistungsengpasses überwunden wird, sondern auch die Skalierbarkeit des gesamten Datenbankclusters noch einmal verbessert wird. Ob durch vertikale Segmentierung oder horizontale Segmentierung. All dies kann die Wahrscheinlichkeit verringern, dass das System auf Engpässe stößt. Insbesondere wenn wir eine Kombination aus vertikalen und horizontalen Slicing-Methoden verwenden, werden wir theoretisch nicht mehr auf Erweiterungsengpässe stoßen.

Verwandte Empfehlungen:

MySQL-Datenbank-Unterdatenbank und Untertabellenmethode (häufig verwendet)_MySQL

MySQL-Master-Slave-Datenbank , Unterdatenbank Unterdatenbank Hinweise zu Tabellen_MySQL

Old Boy MySQL-Video: MySQL-Datenbank-Multiinstanz-Startproblem-Fehlerbehebungsmethoden und praktische Methoden Fehlerbehebung

Das obige ist der detaillierte Inhalt vonStrategien zur Lösung technischer Schwierigkeiten in MySQL-Datenbank-Unterdatenbanken und Tabellen-Untertabellen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!