Grundprinzipien des skalierbaren MySQL-Designs

Vorwort

Mit der rasanten Zunahme der Informationsmenge kann die Entwicklung der Hardwareausstattung allmählich nicht mehr mit den Anforderungen der Anwendungssysteme an die Rechenleistung Schritt halten. Wie gehen wir an diesem Punkt auf die Leistungsanforderungen des Systems ein?

Es gibt nur einen Weg, nämlich die Skalierbarkeit des Systems zu verbessern, indem man die Systemarchitektur umwandelt und mehrere Hardwaregeräte mit geringer Verarbeitungsleistung kombiniert, um ein System mit hoher Verarbeitungsleistung zu erhalten. Mit anderen Worten: Wir müssen ein skalierbares Design umsetzen.

1. Was ist Skalierbarkeit?

Bevor wir über Skalierbarkeit sprechen, fragen sich viele Freunde vielleicht: Wir hören oft, wie gut eine bestimmte Website oder ein bestimmtes System im Hinblick auf Skalierbarkeit konzipiert ist und wie hervorragend seine Architektur ist, aber was genau ist Skalierbarkeit? Was ist skalierbar? Was ist Skalierbarkeit? Tatsächlich sind dies die drei Wörter, die wir am häufigsten hören: Skalierung, skalierbar und Skalierbarkeit.

Aus Sicht der Datenbank bedeutet Skalierung, dass unsere Datenbank stärkere Servicefunktionen und stärkere Verarbeitungskapazitäten bereitstellen kann. Skalierbar bedeutet, dass das Datenbanksystem nach entsprechenden Upgrades (einschließlich der Erhöhung der Verarbeitungsleistung einer einzelnen Maschine oder der Erhöhung der Anzahl der Server) stärkere Verarbeitungsfunktionen bereitstellen kann. Theoretisch ist jedes Datenbanksystem skalierbar, aber die erforderlichen Implementierungsmethoden sind unterschiedlich.

Schließlich bezeichnet Skalierbarkeit die Schwierigkeit, die Verarbeitungsleistung eines Datenbanksystems durch entsprechende Upgrades zu verbessern. Obwohl theoretisch jedes System durch entsprechende Upgrades eine verbesserte Verarbeitungsleistung erreichen kann, sind die Upgrade-Kosten (Geldmittel und Arbeitskräfte), die zur Verbesserung derselben Verarbeitungsleistung für verschiedene Systeme erforderlich sind, unterschiedlich. Dies ist, was wir als große Unterschiede in der Skalierbarkeit verschiedener Datenbankanwendungssysteme bezeichnen.

Die von mir erwähnten unterschiedlichen Datenbankanwendungssysteme beziehen sich hier nicht auf die Unterschiede in der Datenbanksoftware selbst (obwohl unterschiedliche Datenbanksoftware auch unterschiedliche Skalierbarkeit aufweisen kann), sondern auf unterschiedliche Anwendungsarchitekturdesigns derselben Datenbanksoftware.

Zunächst müssen wir verstehen, dass sich die Skalierbarkeit eines Datenbanksystems tatsächlich hauptsächlich in zwei Aspekten widerspiegelt: Einer ist die horizontale Erweiterung und der andere die vertikale Erweiterung, die wir oft als Scale-Out und Scale-Up bezeichnen.

Scale Out bezieht sich auf horizontale Erweiterung, Erweiterung nach außen, d. h. die Erhöhung der Gesamtverarbeitungskapazität durch Hinzufügen von Verarbeitungsknoten. Praktischer ausgedrückt bedeutet es, die Gesamtverarbeitungskapazität durch Hinzufügen von Maschinen zu erhöhen.

Scale Up bezieht sich auf vertikale Erweiterung, d. h. die Erhöhung der Gesamtverarbeitungskapazität durch Erhöhung der Verarbeitungskapazität der aktuellen Verarbeitungsknoten. Einfach ausgedrückt wird dies durch die Aktualisierung der Konfiguration vorhandener Server erreicht, z. B. durch Erhöhung des Arbeitsspeichers, Erhöhung der CPU, Erhöhung der Hardwarekonfiguration des Speichersystems oder durch direkten Austausch durch Server mit stärkeren Verarbeitungsfunktionen und fortschrittlicheren Speichersystemen.

Durch den Vergleich der beiden Skalierungsmethoden können wir leicht ihre jeweiligen Vor- und Nachteile erkennen.

Vorteile der Skalierung:

1. Niedrige Kosten. Mit einem kostengünstigen PC-Server lässt sich problemlos ein Computercluster mit sehr leistungsstarken Verarbeitungsfunktionen erstellen.
2. Weniger anfällig für Engpässe, da die Verarbeitungsleistung durch Hinzufügen von Hosts problemlos erhöht werden kann;
3. Der Ausfall eines einzelnen Knotens hat kaum Auswirkungen auf das Gesamtsystem, bringt jedoch auch Nachteile mit sich. Mehrere Rechenknoten sind die meiste Zeit Server-Hosts, was natürlich die Komplexität der Wartung des gesamten Systems erhöht. In mancher Hinsicht wird dies definitiv die Wartungskosten erhöhen, und die Architekturanforderungen für das Anwendungssystem werden höher sein als bei Scale Up, was die Zusammenarbeit mit Cluster-Management-Software erfordert.
   

Nachteile der Skalierung:

1. Die große Anzahl von Verarbeitungsknoten erhöht die Gesamtkomplexität der Systemarchitektur und die Komplexität des Anwendungsprogramms.
2. Die Clusterwartung ist schwieriger und kostspieliger;

Vorteile der Skalierung:

1. Es gibt nur wenige Verarbeitungsknoten und die Wartung ist relativ einfach;
2. Alle Daten sind zentralisiert, die Architektur des Anwendungssystems ist einfach und die Entwicklung ist relativ einfach;
   

Nachteile der Skalierung:

Hochwertige Geräte sind teuer, es gibt wenig Konkurrenz und sie werden leicht von den Herstellern eingeschränkt.
Aufgrund der Geschwindigkeit der Hardwaregeräteentwicklung ist die Verarbeitungsleistung eines einzelnen Hosts immer begrenzt und es können leicht Leistungsengpässe auftreten, die sich letztendlich nicht lösen lassen.
Geräte und Daten sind konzentriert, daher sind die Auswirkungen eines Ausfalls größer;
Kurzfristig bietet Scale Up größere Vorteile, da es die Betriebs- und Wartungskosten sowie die Systemarchitektur und Anwendungssystementwicklung vereinfachen kann und einfachere technische Anforderungen stellt.

Langfristig gesehen bietet Scale Out jedoch die größeren Vorteile und ist zudem ein unvermeidlicher Trend, sobald das System eine bestimmte Größe erreicht hat. Denn egal was passiert, die Verarbeitungsleistung einer einzelnen Maschine wird immer durch die Hardwaretechnologie begrenzt sein, und auch die Entwicklungsgeschwindigkeit der Hardwaretechnologie ist immer begrenzt, und es ist oft schwierig, mit der Geschwindigkeit der Geschäftsentwicklung Schritt zu halten. Darüber hinaus gilt: Je höher die Verarbeitungsleistung von High-End-Geräten, desto schlechter ist stets das Preis-Leistungs-Verhältnis. Daher wird der Aufbau eines verteilten Clusters mit hoher Verarbeitungsleistung unter Verwendung mehrerer kostengünstiger PC-Server für Unternehmen immer ein Ziel sein, um Kosten zu sparen und die allgemeine Verarbeitungskapazität zu verbessern. Obwohl Sie beim Erreichen dieses Ziels auf verschiedene technische Probleme stoßen können, lohnt es sich immer, sich damit zu befassen und zu üben.

Im Folgenden konzentrieren wir uns auf den Scale-Out-Aspekt für Analyse und Design. Um eine gute Skalierung zu erreichen, ist ein verteiltes Systemdesign erforderlich. Wenn wir bei Datenbanken eine bessere Skalierung erreichen möchten, haben wir nur zwei Möglichkeiten. Eine besteht darin, eine Erweiterung durch kontinuierliche Datenreplikation zu erreichen, um viele völlig identische Datenquellen zu realisieren. Die andere besteht darin, eine Erweiterung durch Aufteilung einer zentralisierten Datenquelle in viele Datenquellen zu erreichen.

Als Nächstes werfen wir einen Blick auf die Prinzipien, die beim Entwurf einer Datenbankanwendungssystemarchitektur mit guter Skalierbarkeit befolgt werden müssen.

2. Prinzip der Minimierung der Transaktionskorrelation

Beim Aufbau eines verteilten Datenbankclusters machen sich viele Leute Sorgen über Transaktionsprobleme. Schließlich sind Transaktionen eine ganz zentrale Funktion der Datenbank.

In der traditionellen zentralisierten Datenbankarchitektur lassen sich Transaktionsprobleme sehr einfach lösen und können vollständig gewährleistet werden, indem man sich auf den sehr ausgereiften Transaktionsmechanismus der Datenbank verlässt. Wenn unsere Datenbank jedoch als verteilte Architektur verwendet wird, müssen viele Transaktionen, die ursprünglich in einer einzigen Datenbank abgeschlossen wurden, nun möglicherweise mehrere Datenbankhosts umfassen. Auf diese Weise müssen die ursprünglichen Einzelmaschinentransaktionen möglicherweise das Konzept verteilter Transaktionen einführen.

Aber jeder muss verstehen, dass verteilte Transaktionen selbst ein sehr komplexer Mechanismus sind. Ob es sich nun um ein großes kommerzielles Datenbanksystem oder verschiedene Open-Source-Datenbanksysteme handelt, obwohl die meisten Datenbankhersteller diese Funktion grundsätzlich implementiert haben, gibt es mehr oder weniger verschiedene Einschränkungen. Es gibt auch einige Fehler, die dazu führen können, dass bestimmte Transaktionen nicht richtig gewährleistet sind oder nicht reibungslos abgeschlossen werden.

Zu diesem Zeitpunkt müssen wir möglicherweise nach anderen Alternativen suchen, um dieses Problem zu lösen. Schließlich können Transaktionen nicht ignoriert werden. Egal, wie wir sie implementieren, sie müssen immer implementiert werden.

Derzeit gibt es drei Hauptlösungen:

Entwerfen Sie beim Entwurf von Scale Out zunächst sinnvolle Segmentierungsregeln, um sicherzustellen, dass sich die von der Transaktion benötigten Daten möglichst auf demselben MySQL-Server befinden, um verteilte Transaktionen zu vermeiden.

Wenn wir beim Entwerfen von Datensegmentierungsregeln sicherstellen können, dass alle Transaktionen auf einem einzigen MySQL-Server abgeschlossen werden können, lassen sich unsere Geschäftsanforderungen leichter erfüllen und die Anwendung kann Architekturänderungen mit minimalen Anpassungen bewältigen, was die Gesamtkosten erheblich senkt. Schließlich ist die Transformation der Datenbankarchitektur nicht nur die Aufgabe des DBA, sondern erfordert auch viel externe Zusammenarbeit und Unterstützung. Selbst wenn wir ein brandneues System entwerfen, müssen wir immer noch die Gesamtinvestition in jede Umgebung und jede Arbeit berücksichtigen, nicht nur die Kosteninvestition in die Datenbank selbst, sondern auch die entsprechenden Entwicklungskosten. Wenn zwischen den verschiedenen Verbindungen ein Interessenkonflikt besteht, müssen wir einen Kompromiss auf der Grundlage der späteren Erweiterung und der Gesamtkosten eingehen, um einen Gleichgewichtspunkt zu finden, der für die aktuelle Phase am besten geeignet ist.

Allerdings ist es selbst bei gut konzipierten Sharding-Regeln schwierig, alle für alle Transaktionen erforderlichen Daten auf demselben MySQL-Server zu haben. Obwohl diese Lösung die geringsten Kosten verursacht, kann sie in den meisten Fällen nur die meisten Kernangelegenheiten berücksichtigen und ist keine perfekte Lösung.

Zweitens werden große Transaktionen in mehrere kleine Transaktionen aufgeteilt. Die Datenbank stellt die Integrität jeder einzelnen kleinen Transaktion sicher, und die Anwendung kontrolliert die Gesamtintegrität der Transaktionen zwischen den kleinen Transaktionen.

Im Vergleich zur vorherigen Lösung bringt diese Lösung mehr Anwendungsmodifikationen mit sich und stellt strengere Anforderungen an die Anwendung. Die Anwendung muss nicht nur viele der ursprünglichen großen Transaktionen aufteilen, sondern auch die Integrität jeder kleinen Transaktion sicherstellen. Mit anderen Worten: Die Anwendung selbst muss über bestimmte Transaktionsfunktionen verfügen, was den technischen Schwierigkeitsgrad der Anwendung zweifellos erhöht.

Allerdings hat auch diese Lösung viele eigene Vorteile. Erstens werden unsere Regeln zur Datensegmentierung einfacher sein und es wird weniger wahrscheinlich sein, dass wir auf Einschränkungen stoßen. Und einfacher bedeutet geringere Wartungskosten. Zweitens ist die Datenbank ohne zu viele Einschränkungen bei den Datensegmentierungsregeln skalierbarer und unterliegt nicht zu vielen Einschränkungen. Bei Leistungsengpässen kann die vorhandene Datenbank schnell weiter aufgeteilt werden. Schließlich ist die Datenbank weiter von der eigentlichen Geschäftslogik entfernt, was einer späteren Architekturerweiterung förderlicher ist.

Drittens: Kombinieren Sie die beiden oben genannten Lösungen, integrieren Sie ihre jeweiligen Vorteile und vermeiden Sie ihre jeweiligen Nachteile.

Die beiden vorherigen Lösungen haben ihre eigenen Vor- und Nachteile und widersprechen sich grundsätzlich. Wir können ihre jeweiligen Vorteile voll ausnutzen, die Designprinzipien der beiden Lösungen anpassen und im gesamten Architekturdesign ein Gleichgewicht herstellen. Beispielsweise können wir sicherstellen, dass sich die für einige Kerntransaktionen erforderlichen Daten auf demselben MySQL-Server befinden, während andere Transaktionen, die nicht besonders wichtig sind, in kleine Transaktionen aufgeteilt und mit dem Anwendungssystem kombiniert werden können. Darüber hinaus können wir bei einigen nicht besonders wichtigen Transaktionen auch eine eingehende Analyse durchführen, um zu sehen, ob die Verwendung von Transaktionen unvermeidlich ist.

Indem wir diesem Prinzip des ausgewogenen Designs folgen, können wir vermeiden, dass die Anwendung zu viele kleine Transaktionen verarbeiten muss, um ihre Gesamtintegrität zu gewährleisten. Gleichzeitig können wir die Situation vermeiden, dass zu viele komplexe Aufteilungsregeln den Schwierigkeitsgrad der nachfolgenden Wartung erhöhen und die Skalierbarkeit behindern.

Natürlich müssen nicht alle Anwendungsszenarien durch die Kombination der beiden oben genannten Lösungen gelöst werden. Beispielsweise können bei Anwendungen, die keine besonders strengen Transaktionsanforderungen haben oder bei denen die Transaktionen selbst sehr einfach sind, die entsprechenden Anforderungen durch leicht gestaltete Aufteilungsregeln erfüllt werden. Wir können einfach die erste Lösung verwenden, um zu vermeiden, dass die Anwendung die Gesamtintegrität bestimmter kleiner Transaktionen aufrechterhalten muss. Dadurch kann die Komplexität der Anwendung erheblich reduziert werden.

Bei Anwendungen mit sehr komplexen Transaktionsbeziehungen und hoher Korrelation zwischen Daten müssen wir uns nicht besonders anstrengen, um die Transaktionsdaten zentral zu halten. Denn egal, wie sehr wir uns bemühen, es ist schwierig, die Anforderungen zu erfüllen, und wir geraten meistens in eine Situation, in der wir den Überblick über das große Ganze verlieren. In diesem Fall können wir die Datenbank genauso gut so einfach wie möglich halten und der Anwendung einige Abstriche überlassen.

In vielen aktuellen groß angelegten Internetanwendungen gibt es Anwendungsfälle für alle der oben genannten Lösungen. Beispielsweise ist das jedem bekannte Ebay größtenteils eine Kombination der dritten Lösung. Beim Kombinationsprozess ist die zweite Option die Hauptoption und die erste Option die Hilfsoption. Der Grund für die Wahl dieser Architektur liegt neben den Anforderungen ihrer Anwendungsszenarien darin, dass ihre starken technischen Fähigkeiten auch eine Garantie für die Entwicklung eines ausreichend robusten Anwendungssystems bieten. Ein weiteres Beispiel ist ein großes inländisches BBS-Anwendungssystem (sein richtiger Name wird nicht bekannt gegeben), dessen Transaktionskorrelation nicht besonders komplex ist und dessen Datenkorrelation zwischen verschiedenen Funktionsmodulen nicht besonders hoch ist. Es übernimmt vollständig die erste Lösung und vermeidet vollständig die Transaktionsdatenquelle, die sich über mehrere MySQL-Server erstreckt, indem es vernünftige Datenaufteilungsregeln entwirft.

Schließlich müssen wir auch einen Punkt verstehen: Je mehr Transaktionen, desto besser, aber je weniger, desto besser und je kleiner, desto besser. Unabhängig davon, welche Lösung wir verwenden, müssen wir beim Entwurf unserer Anwendung die Transaktionsrelevanz der Daten verringern oder die Notwendigkeit der Transaktionsrelevanz sogar beseitigen. Natürlich ist das nur relativ und sicherlich können nur einige Daten dies leisten. Wenn jedoch ein bestimmter Teil der Daten keine Transaktionsrelevanz mehr hat, kann die Gesamtkomplexität des Systems erheblich reduziert werden, und sowohl die Anwendung als auch das Datenbanksystem verursachen möglicherweise deutlich geringere Kosten.

3. Prinzip der Datenkonsistenz

Unabhängig davon, ob wir hoch- oder hochskalieren und wie wir unsere Architektur gestalten, ist die Sicherstellung der endgültigen Datenkonsistenz ein Grundsatz, der nicht verletzt werden darf. Ich glaube, dass allen Lesern klar sein muss, wie wichtig die Sicherstellung dieses Grundsatzes ist.

Darüber hinaus ist die Gewährleistung der Datenkonsistenz dasselbe wie die Gewährleistung der Transaktionsintegrität. Wenn wir das System für eine Skalierung entwerfen, können auch wir auf einige Probleme stoßen. Natürlich dürften derartige Probleme seltener auftreten, wenn Sie die Skalierung erhöhen. Natürlich fällt in den Augen vieler Menschen auch die Datenkonsistenz bis zu einem gewissen Grad in die Kategorie der Transaktionsintegrität. Um jedoch seine Bedeutung und relevanten Eigenschaften hervorzuheben, werde ich es hier separat analysieren.

Wie können wir also beim Skalieren die Datenkonsistenz sicherstellen? Dieses Problem bereitet uns ebenso oft Kopfzerbrechen wie die Gewährleistung der Transaktionsintegrität und hat auch die Aufmerksamkeit vieler Architekten auf sich gezogen. Nach viel Übung haben schließlich alle das BASE-Modell zusammengefasst. Das heißt: grundsätzlich verfügbar, flexibler Zustand, grundsätzlich konsistent und letztendlich konsistent. Diese Worte mögen kompliziert und tiefgründig erscheinen, aber eigentlich kann man sie einfach als das Prinzip der Nicht-Echtzeit-Konsistenz verstehen.

Mit anderen Worten wird das Anwendungssystem durch entsprechende Technologien implementiert, sodass das gesamte System es den Daten ermöglicht, sich für einen kurzen Zeitraum in einem Nicht-Echtzeitzustand zu befinden und gleichzeitig die Anforderungen der Benutzer zu erfüllen. Anschließend werden Technologien verwendet, um sicherzustellen, dass sich die Daten letztendlich in einem konsistenten Zustand befinden. Dieses theoretische Modell klingt einfach, aber bei seiner tatsächlichen Umsetzung stoßen wir auf viele Schwierigkeiten.

Zunächst stellt sich die Frage, ob wir alle Daten in nicht-Echtzeit konsistent machen müssen. Ich denke, die meisten meiner Leser werden definitiv dagegen stimmen. Wenn nicht alle Daten nicht-Echtzeit-konsistent sind, wie können wir dann bestimmen, welche Daten in Echtzeit konsistent sein müssen und welche Daten lediglich eine nicht-Echtzeit-Eventualkonsistenz benötigen? Tatsächlich kann man dies im Grunde als eine Aufteilung der Geschäftsprioritäten für jedes Modul bezeichnen. Anwendungen mit höheren Prioritäten gehören natürlich zu dem Lager, das Echtzeitkonsistenz der Daten gewährleistet, während Anwendungen mit etwas niedrigeren Prioritäten dem Lager zugeordnet werden können, das Inkonsistenzen innerhalb eines kurzen Zeitraums zulässt, aber letztendlich Konsistenz erreicht. Dies ist ein sehr kniffliges Problem. Wir können Entscheidungen nicht einfach so treffen, sondern müssen sie auf der Grundlage sehr detaillierter Analysen und sorgfältiger Bewertungen treffen. Da nicht alle Daten für einen kurzen Zeitraum in einem inkonsistenten Zustand im System auftreten können und nicht alle Daten später verarbeitet werden können, um einen konsistenten Zustand zu erreichen, müssen zumindest diese beiden Datentypen in Echtzeit konsistent sein. Um zwischen diesen beiden Datentypen zu unterscheiden, müssen wir eine detaillierte Analyse der Geschäftsszenarien und kommerziellen Anforderungen durchführen und anschließend eine vollständige Auswertung vornehmen, um eine Schlussfolgerung zu ziehen.

Zweitens: Wie können inkonsistente Daten im System letztendlich konsistent gemacht werden? Generell müssen wir die für diese Art von Daten konzipierten Geschäftsmodule klar von den Geschäftsmodulen trennen, die konsistente Echtzeitdaten erfordern. Anschließend werden die derzeit inkonsistenten Daten mithilfe der entsprechenden asynchronen Mechanismustechnologie und des entsprechenden Hintergrundprozesses durch die Daten, Protokolle und anderen Informationen im System weiter verarbeitet, sodass die endgültigen Daten einen vollständig konsistenten Zustand aufweisen. Durch die Verwendung unterschiedlicher Hintergrundprozesse für unterschiedliche Module können Sie nicht nur Datenunordnung vermeiden, sondern auch eine gleichzeitige Ausführung ermöglichen, um die Verarbeitungseffizienz zu verbessern. Für Informationen wie Benutzernachrichtenbenachrichtigungen muss keine strikte Echtzeitkonsistenz erreicht werden. Es ist lediglich erforderlich, die zu verarbeitenden Nachrichten aufzuzeichnen und sie dann nacheinander vom Hintergrundverarbeitungsprozess verarbeiten zu lassen, um eine Überlastung des Vordergrundgeschäfts zu vermeiden.

Vermeiden Sie schließlich die Front-End-Online-Interaktion zwischen in Echtzeit konsistenten Daten und letztendlich konsistenten Daten. Aufgrund der Inkonsistenz der beiden Datenzustände ist es sehr wahrscheinlich, dass die beiden Datentypen während des Interaktionsprozesses durcheinander geraten. Alle nicht in Echtzeit konsistenten Daten und alle in Echtzeit konsistenten Daten sollten in der Anwendung so weit wie möglich effektiv isoliert werden. Sogar in einigen speziellen Szenarien ist es notwendig, Datensätze auf verschiedenen MySQL-Servern physisch zu isolieren.

4. Grundsätze für hohe Verfügbarkeit und Datensicherheit

Zusätzlich zu den beiden oben genannten Grundsätzen möchte ich auch die beiden Aspekte der Systemhochverfügbarkeit und der Datensicherheit erwähnen. Nach unserem Scale-Out-Design wird die Gesamtskalierbarkeit des Systems tatsächlich erheblich verbessert und die Gesamtleistung lässt sich natürlich problemlos steigern. Allerdings ist es schwieriger geworden als zuvor, die Gesamtverfügbarkeit des Systems aufrechtzuerhalten. Da die gesamte Systemarchitektur komplex ist, werden sowohl die Anwendungs- als auch die Datenbankumgebung größer und komplexer sein als zuvor. Die unmittelbarste Auswirkung hiervon besteht darin, dass die Wartung und die Systemüberwachung schwieriger werden.

Wenn eine solche Designänderung dazu führt, dass unser System häufig abstürzt und Ausfallzeiten hat, wird das meiner Meinung nach niemand akzeptieren können. Daher müssen wir verschiedene technische Maßnahmen ergreifen, um sicherzustellen, dass die Systemverfügbarkeit nicht abnimmt und möglicherweise sogar insgesamt verbessert wird.

Dies führt daher natürlich zu einem weiteren Prinzip in unserem Scale-Out-Designprozess, nämlich dem Prinzip der Hochverfügbarkeit. Unabhängig von der Anpassung der Systemarchitektur kann die Gesamtverfügbarkeit des Systems nicht verringert werden.

Tatsächlich ist es naheliegend, bei der Diskussion über Systemverfügbarkeit ein weiteres, eng damit verbundenes Prinzip zur Sprache zu bringen: das Prinzip der Datensicherheit. Um eine hohe Verfügbarkeit zu erreichen, müssen die Daten in der Datenbank sicher genug sein. Die hier angesprochene Sicherheit bezieht sich nicht auf böswillige Angriffe oder Diebstahl, sondern auf anormale Verluste. Mit anderen Worten: Wir müssen sicherstellen, dass unsere Daten bei einem Software-/Hardwarefehler nicht verloren gehen. Sind die Daten erst einmal verloren, ist ihre Verfügbarkeit völlig ausgeschlossen. Darüber hinaus sind die Daten selbst die Kernressource des Datenbankanwendungssystems und der Grundsatz, dass sie nicht verloren gehen dürfen, steht außer Zweifel.

Der beste Weg, eine hohe Verfügbarkeit und Datensicherheit zu gewährleisten, ist ein Redundanzmechanismus. Bei allen Software- und Hardwaregeräten werden Einzelpunktrisiken eliminiert und alle Daten sind in mehreren Kopien vorhanden. Nur so kann dieser Grundsatz besser gewährleistet werden. Technologisch können wir dies durch Technologien wie MySQL Replication und MySQL Cluster erreichen.

Zusammenfassen

Unabhängig davon, wie wir die Architektur gestalten und wie sich unsere Skalierbarkeit ändert, sind einige der in diesem Kapitel genannten Prinzipien sehr wichtig. Ob es sich um das Prinzip der Lösung bestimmter Probleme, das Prinzip der Zusicherung, das Prinzip der Gewährleistung der Verfügbarkeit oder das Prinzip der Gewährleistung der Datensicherheit handelt, wir sollten ihnen bei der Entwicklung stets Beachtung schenken und sie im Hinterkopf behalten.

Der Grund für die große Beliebtheit der MySQL-Datenbank in der Internetbranche liegt neben ihren Open-Source-Eigenschaften und ihrer Benutzerfreundlichkeit auch darin, dass sie einen großen Vorteil hinsichtlich der Skalierbarkeit bietet. Die Eigenschaften der verschiedenen Speicher-Engines können mit verschiedenen Anwendungsszenarien umgehen. Seine Replikations- und Clusterfunktionen sind sehr effektive Mittel zur Verbesserung der Skalierbarkeit.

Oben finden Sie ausführliche Informationen zu den Grundprinzipien des skalierbaren MySQL-Designs. Weitere Informationen zum skalierbaren MySQL-Design finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!