Der Stamm ist nicht spezifisch genug, um einen eindeutigen Vorschlag zu machen, aber die vollständige Liste dessen, was getan werden könnte, lautet wie folgt:
- Datenbankcluster :Geeignet für Situationen, in denen Sie Ihre Anwendungsschicht nicht ändern möchten und die Datenbank alles ist, was Sie berühren. Es gibt eine Grenze dafür, wie viel Sie aus einem Datenbank-Cluster herausholen können. Wenn Ihr Anfragevolumen weiter wächst, wird auch diese Lösung irgendwann scheitern. Aber die gute Nachricht ist, dass Sie alle Funktionen haben, die Sie bereits in einem gewöhnlichen Einzelinstanz-MySQL hatten.
- Sharding :Da Ihre Frage mit MySQL getaggt ist und Sharding allein nicht unterstützt, müssen Sie diese Lösung in Ihrer Anwendungsschicht implementieren, wenn Sie diese Lösung verwenden möchten. Bei dieser Lösung verteilen Sie Ihre Daten logisch über mehrere Datenbanken (vorzugsweise in mehreren MySQL-Instanzen auf separater Hardware). Es liegt in Ihrer Verantwortung, die geeignete Datenbank mit Ihren angegebenen Daten zu finden. Es ist eine der effektivsten Lösungen überhaupt, aber es ist nicht immer machbar. Sein größter Fehler ist, dass Daten, die über zwei oder mehr Datenbanken verstreut sind, nicht in eine Transaktion aufgenommen werden können.
- Replikation :Abhängig von Ihrem Szenario können Sie möglicherweise eine Datenbankreplikation integrieren und Kopien Ihrer Daten darauf haben. Auf diese Weise können Sie sich mit ihnen anstelle der Master-Datenbank verbinden und die Belastung reduzieren. Die Standardreplikationsdefinition ist ein Master/Slave-Szenario, in dem der Datenfluss nur in eine Richtung erfolgt, vom Master zum Slave. Änderungen, die Sie am Slave vornehmen, werden also auf den Slave angewendet, sie wirken sich nicht auf den Master aus. Es gibt aber auch eine Master/Master-Replikationskonfiguration, bei der der Datenfluss in beide Richtungen erfolgt. Sie können jedoch keine atomare Integrität für gleichzeitige Datenänderungen zwischen beiden Mastern annehmen. Letztendlich ist diese Lösung am effektivsten, wenn Sie planen, sie im Master/Slave-Modus zu verwenden und Slaves für Nur-Lese-Zugriff zu verwenden.
- Caching :Vielleicht sollte diese Lösung hier nicht enthalten sein, aber da Ihr Vorbau sie nicht ablehnt, hier ist sie. Eine Möglichkeit, die Datenbanklast zu reduzieren, besteht darin, die extrahierten Daten zwischenzuspeichern. Diese Lösung kann besonders dann von Vorteil sein, wenn das Extrahieren von Daten teuer ist. Es gibt viele Cache-Server, wie memcached oder redis . Auf diese Weise können Sie viele der Datenbankverbindungen weglassen, aber nur zum Extrahieren von Daten.
- Andere Speicher-Engines :Sie können jederzeit auf leistungsstärkere Engines umsteigen, wenn Ihre aktuelle Engine nicht das bietet, was Sie benötigen. Dies ist natürlich nur möglich, wenn Ihre Bedürfnisse es zulassen. Heutzutage gibt es NoSQL-Engines, viel performanter als RDBMS, die Sharding nativ unterstützen und mit minimalem Aufwand linear skaliert werden können. Es gibt auch Lucene-basierte Lösungen mit leistungsstarken Volltextsuchfunktionen, die Ihnen dasselbe automatische Sharding bieten. Tatsächlich ist der einzige Grund, warum Sie ein herkömmliches RDBMS verwenden sollten, das atomare Verhalten von Transaktionen. Aber wenn Transaktionen kein Muss sind, gibt es viel bessere Lösungen als RDBMS.
