Lese-Schreib-Trennung
Wenn das Geschäft eines Unternehmens weiter wächst und die Zahl der Nutzer deutlich steigt, ist es wahrscheinlich, dass die ursprüngliche Datenbank sich nicht selbst aufrechterhalten kann. Dann ja
- Skalieren, was die Leistung der Hardware erhöht, aber es ist wahrscheinlich, dass die Zahl der Nutzer weiter wächst und die gesteigerte Leistung bald aufgefressen wird.
- Lese-Schreib-Trennung: Die Datenbank kann nicht halten, es ist nichts weiter als zu viel Lesen und Schreiben, besonders wenn es komplexe Abfragen gibt, wie die beliebtesten Produkte der letzten 24 Stunden. Es erfordert sehr komplexe SQL-Anweisungen und ist natürlich langsam zu laufen.
Um jedoch Lesen und Schreiben zu trennen, muss die Datenbank in Master- und Slave-Bibliotheken aufgeteilt werden.
Die wichtigsten relationalen Datenbanken auf dem Markt unterstützen Datenreplikation, sodass man eine Datenbank in zwei Rollen unterteilen kann: Master und Slave, Schreiboperationen auf dem Master und die Synchronisation des Masterservers mit anderen Slave-Servern.
Offline-Operationen wie Leseoperationen und Datenanalysen werden auf dem Slave-Server durchgeführt.
Wir wissen, dass viele Anwendungen im Internet gelesen werden, sodass mehrere Slaves die Last teilen und die Verfügbarkeit sowie Korrektheit der Daten sicherstellen können.
Allerdings muss auch der entsprechende ursprüngliche Anwendungscode geändert werden, und er muss so geändert werden, dass die Masterbibliothek zum Schreiben der Daten verwendet wird und die Slave-Bibliothek beim Lesen verwendet wird, was dem Umschreiben entspricht.
Komplexe Abfragen
Selbst nach dem Umschreiben des Codes stellte ich jedoch fest, dass sich die Leistung nicht signifikant verbesserte, weil zu viele komplexe Abfragen verwendet wurden, und wir haben in der Datenbankkomponente gesagt, dass Joins sehr leistungsintensiv sind.
Können wir also eine separate Tabelle verwenden, um die beliebten Produkte der letzten 24 Stunden zu speichern, sodass wir dafür nur noch einfaches SQL verwenden müssen?
Mit anderen Worten: Ein einziger Satz von Datenbanktabellen ist für verschiedene Verhaltensweisen wie Berichte, Suchen, Transaktionen usw. ungeeignet.
Die aktuelle Tabelle ist darauf ausgelegt, Daten hinzuzufügen und zu verändern, und ist für komplexe Abfragen nicht geeignet.
Aber wir müssen auch berücksichtigen, wie diese Abfragebasis aktualisiert wird oder ob wir diese Verzögerung tolerieren können, ob sie möglicherweise nicht in Echtzeit aktualisiert wird.
CQRS
Ob die Verzögerung tolerierbar ist, muss aus geschäftlicher Perspektive betrachtet werden, wie etwa die beliebten besten Produkte der letzten 24 Stunden; etwas veraltete Informationen haben wenig Auswirkung, es ist nur die endgültige Konsistenz erforderlich.
Wir können CQRS (Command Query Responsibility Segregation) verwenden, also die Trennung von Befehlen, um Befehle von Abfrageverantwortlichkeiten hinzuzufügen oder zu ändern.
Im CQRS liegt der Schwerpunkt auf der Trennung von Lesen (Abfrage) und Schreiben (Befehl), da die von den Nutzern gelesenen Daten meist veraltet sind, sodass man aus der Datenbank lesen sollte, man kann direkt eine Lesedatenquelle einrichten. Es kann Cache sein, XML, JSON usw.
Wie löst man das zuvor erwähnte Problem, wie man aktualisiert? Man kann Event, also ein Event, verwenden, zum Beispiel wenn ein Produkt verkauft wird, ein Event veröffentlichen, um das ursprüngliche Read Model zu modifizieren.
Auf diese Weise wird die Synchronisation durch den Ereignismechanismus asynchron.
Schließlich eignet sich diese Methode am besten nur für komplexe Abfragen, und die ursprünglichen einfachen Abfragen werden weiterhin in der relationalen Datenbank abgerufen. Warum? Da die Einführung einer neuen Technologie einen Preis erfordert, wie zum Beispiel synchrone Mutationsschritte und Ereignismechanismen, können wir nicht nur die Vorteile neuer Technologien und nicht die Nachteile sehen.
|
Veröffentlicht am 04.05.2020 09:58:50
|
|
|
|
