Konkret sind die beiden Optimierungsstrategien, die ich vergleichen möchte, die Optimierung von MySQL und Caching. Weisen Sie im Voraus darauf hin, dass diese Optimierungen orthogonal sind und der einzige Grund, warum Sie sich für eine der anderen entscheiden sollten, darin besteht, dass beide Ressourcen, nämlich Entwicklungszeit, kosten.
MySQL optimieren
Bei der Optimierung von MySQL überprüfen Sie normalerweise zuerst die an MySQL gesendete Abfrageanweisung und führen dann den Befehl EXPLAIN aus. Ein gängiger Ansatz nach einer kleinen Überprüfung besteht darin, Indizes hinzuzufügen oder einige Anpassungen am Schema vorzunehmen.
Vorteile
1. Eine optimierte Abfrage ist für alle Benutzer der Anwendung schnell. Weil der Index Daten mit logarithmischer Komplexitätsgeschwindigkeit abruft (auch bekannt als Fraktionierung, wenn Sie ein Telefonbuch durchsuchen, wodurch der Suchbereich schrittweise eingeschränkt wird) und eine gute Leistung beibehält, wenn die Datenmenge zunimmt. Das Zwischenspeichern der Ergebnisse einer nicht indizierten Abfrage kann manchmal schlechter funktionieren, wenn die Daten wachsen. Wenn die Datenmenge wächst, kann es für Benutzer, die den Cache vermissen, zu einer schlechten Erfahrung kommen und die Anwendung ist nicht mehr verfügbar.
2. Bei der Optimierung von MySQL müssen Sie sich keine Gedanken über die Ungültigmachung des Caches oder den Ablauf der zwischengespeicherten Daten machen.
3. Die Optimierung von MySQL kann die technische Architektur vereinfachen und das Kopieren und Arbeiten in der Entwicklungsumgebung erleichtern.
Nachteile
1. Einige Abfragen können die Leistung nicht allein durch Indizierung verbessern und müssen möglicherweise auch den Modus ändern. In einigen Fällen kann dies für einige Anwendungen sehr problematisch sein.
2. Einige Schemaänderungen können zur Denormalisierung (Datensicherung) verwendet werden. Obwohl dies eine gängige Technik für Datenbankadministratoren ist, erfordert sie die Eigentümerschaft, um sicherzustellen, dass alles von der Anwendung aktualisiert wird, oder es müssen Trigger installiert werden, um solche Änderungen zu gewährleisten.
3. Einige Optimierungsmethoden gelten möglicherweise nur für MySQL. Das heißt, wenn die zugrunde liegende Software so portiert wird, dass sie auf mehreren Datenbanken funktioniert, ist es schwierig sicherzustellen, dass einige der komplexeren Optimierungstechniken außer dem Hinzufügen von Indizes universell sind.
Caching verwenden
Diese Art der Optimierung erfordert, dass Benutzer die tatsächliche Situation der Anwendung analysieren und dann die teuren Verarbeitungsteile von MySQL trennen und durch Caches von Drittanbietern wie Memcached ersetzen oder Redis.
Vorteile
1. Caching funktioniert gut für einige Abfragen, die für MySql selbst schwer zu optimieren sind, z. B. umfangreiche Aggregations- oder Gruppierungsabfragen.
2. Caching kann eine gute Lösung sein, um die Durchsatzrate des Systems zu verbessern. Beispielsweise ist die Reaktionsgeschwindigkeit sehr langsam, wenn mehrere Personen gleichzeitig auf die Anwendung zugreifen.
3. Der Cache lässt sich möglicherweise einfacher auf einer anderen Anwendung aufbauen. Beispiel: Ihre Anwendung ist möglicherweise das Frontend eines anderen Softwarepakets, das MySQL zum Speichern von Daten verwendet, und es ist sehr schwierig, Datenbankänderungen an diesem Softwarepaket vorzunehmen.
Nachteile
1. Wenn die Daten mehrere externe Zugriffsparadigmen bieten (z. B. in verschiedenen Formen auf verschiedenen Seiten angezeigt), kann es schwierig sein, den Cache abzulaufen oder zu aktualisieren Es kann erforderlich sein, abgelaufene Daten zu tolerieren. Eine praktikable Alternative besteht darin, einen ausgefeilteren Caching-Mechanismus zu entwickeln. Dies hat natürlich auch den Nachteil, dass das mehrfache Abrufen des Caches die Latenz erhöht.
2. Das Zwischenspeichern eines teuren Objekts kann einen potenziellen Leistungsunterschied für Benutzer haben, die den Cache vermissen (siehe Vorteile der Optimierung von MySQL Nr. 1). Einige gute Leistungspraktiken legen nahe, dass Sie versuchen sollten, die Unterschiede zwischen Benutzern zu minimieren, anstatt sie nur zu mitteln (was bei Caches in der Regel der Fall ist).
3. Die naive Cache-Implementierung ist nicht in der Lage, einige subtile Schwachstellen wie den Lawineneffekt zu bewältigen. Erst letzte Woche habe ich einem Mann geholfen, dessen Datenbankserver durch mehrere Benutzeranfragen überlastet war, die versuchten, denselben zwischengespeicherten Inhalt gleichzeitig neu zu generieren. Die richtige Strategie besteht darin, eine gewisse Sperrstufe einzuführen, um Cache-Regenerationsanforderungen zu serialisieren.
Zusammenfassung
Generell würde ich Benutzern empfehlen, MySQL zuerst zu optimieren, da dies meiner Meinung nach zu Beginn die am besten geeignete Lösung ist. Aber auf lange Sicht wird es bei den meisten Anwendungen einige Anwendungsfälle geben, die die gleichzeitige Implementierung der oben genannten Lösungen in gewissem Umfang erfordern.