[DB] Kriterien für die Cache-Einstellung

Hallo? Ich bin Jayon.

Heute möchte ich Ihnen die Kriterien für die Cache-Konfiguration erläutern. Da es sich um einen Beitrag handelt, den ich aufgrund meiner persönlichen Praxiserfahrung verfasse, sollten Sie ihn bitte nur als Referenz betrachten. ㅎㅎ

Was ist Cache?

Cache bedeutet, die Ergebnisse zukünftiger Anfragen im Voraus zu speichern und schnell bereitzustellen. Das heißt, Ergebnisse werden im Voraus gespeichert und bei einer späteren Anfrage wird nicht auf die Datenbank oder die API zugegriffen, sondern auf den Cache, um die Anfrage zu verarbeiten. Der Hintergrund für die Einführung dieses Caches ist das Pareto-Prinzip.

Das Pareto-Prinzip besagt, dass 80 % der Ergebnisse auf 20 % der Ursachen zurückzuführen sind. Ich empfehle Ihnen, sich das folgende Bild anzusehen!

Das heißt, es ist nicht erforderlich, alle Ergebnisse zu cachen. Indem nur die 20 %, die am häufigsten beim Service verwendet werden, gecached werden, kann die Gesamteffizienz gesteigert werden.

Welche Daten sollten gecached werden?

Aufgrund des Pareto-Prinzips sollten nicht beliebige Daten gecached werden, sondern nur die unbedingt notwendigen. Welche Daten sollten also gecached werden?

Daten, die häufig gelesen, aber selten geschrieben werden

Theoretisch wird oft gesagt, dass „Daten, die häufig gelesen, aber selten geschrieben werden, gecached werden sollten“. Allerdings waren die Kriterien für „häufig gelesen“ und „selten geschrieben“ ziemlich vage.

Deshalb untersuche ich die zu cachenden Daten in den folgenden Schritten.

• Überprüfung der Top 5 der RDB-Abfrageprotokolle mithilfe eines APM wie DataDog.
• Darunter werden die Abfrage-Queries gesucht und überprüft, aus welcher Tabelle die Abfrage stammt.
• Überprüfung der Häufigkeit, mit der Update-Queries für die jeweilige Tabelle aufgerufen werden.

Bei diesem Prozess wird geprüft, ob viele Abfragen, aber wenige Update-Queries auftreten. Bei einer Tabelle, die ich in der Praxis überprüft habe, wurden täglich 1,74 Millionen Abfragen, aber maximal 500 Update-Queries ausgeführt. Das sind meiner Meinung nach eindeutig geeignete Voraussetzungen für den Cache. ㅎㅎ

Aktualisierungsempfindliche Daten

Bei aktualisierungsempfindlichen Daten muss die Inkonsistenz zwischen RDB und Cache kurz sein. Beispielsweise sind Informationen im Zusammenhang mit Zahlungen sehr aktualisierungsempfindlich, sodass die Anwendung des obigen Cache-Kriteriums sorgfältig geprüft werden muss.

Ich musste für eine mit der Zahlung zusammenhängende Tabelle, die die beiden oben genannten Merkmale erfüllt, einen Cache implementieren. Daher habe ich den Cache nicht auf alle Logiken angewendet, die diese Tabelle verwenden, sondern mich entschieden, den Cache nur teilweise auf relativ sichere Logiken anzuwenden, bei denen keine Zahlungen stattfinden.

Lokaler Cache vs. globaler Cache

Nachdem wir nun die zu cachenden Daten und den Umfang des Cachings festgelegt haben, müssen wir uns überlegen, „wo“ die zu cachenden Daten gespeichert werden sollen. Im Allgemeinen können diese entweder im lokalen Speicher oder auf einem separaten Server wie Redis gespeichert werden.

Lokaler Cache

Beim lokalen Caching werden die zu cachenden Daten im Speicher des Anwendungsservers gespeichert. In der Regel werden dafür Guava Cache oder Caffeine Cache verwendet.

Vorteile

• Da der Cache während der Ausführung der Anwendungslogik direkt aus dem Speicher auf demselben Server abgerufen wird, ist er sehr schnell.
• Einfache Implementierung.

Nachteile

• Bei mehreren Instanzen treten verschiedene Probleme auf.

Globaler Cache

Beim globalen Caching wird ein separater Server, wie z. B. Redis, für die Speicherung der Cache-Daten verwendet.

Vorteile

• Da der Cache zwischen den Instanzen gemeinsam genutzt wird, kann jede Instanz den gleichen Cache-Wert erhalten, auch wenn der Cache in einer Instanz geändert wird.
• Wenn eine neue Instanz erstellt wird, muss sie nur auf den vorhandenen Cache-Speicher zugreifen, sodass keine neuen Cache-Daten eingefügt werden müssen.

Nachteile

• Da ein Netzwerk-Traffic erforderlich ist, ist er langsamer als der lokale Cache.
• Da ein separater Cache-Server benötigt wird, entstehen Infrastrukturkosten.

Welche Lösung habe ich gewählt?

Der Anwendungsserver meines aktuellen Unternehmens verwendet eine Architektur mit mehreren Instanzen, aber ich habe mich für einen lokalen Cache entschieden.

Dafür gibt es hauptsächlich drei Gründe.

• Die zu cachenden Daten, die in der RDB gespeichert sind, umfassen knapp 40.000 Einträge. Wenn alle diese Daten im Speicher abgelegt werden, beträgt der Speicherbedarf weniger als 4 MB.
• Die Abfrageleistung für mit der Zahlung zusammenhängende Daten musste verbessert werden.
• Redis ist zwar bereits vorhanden, aber die Speicherung eines neuen Caches in Redis würde zusätzliche Infrastrukturkosten verursachen.

Wie wird der Cache aktualisiert?

Wenn mehrere Anwendungsserver vorhanden sind und ein lokaler Cache implementiert ist, können die in den einzelnen Anwendungsservern gespeicherten Cache-Werte unterschiedlich sein. Beispielsweise kann der in Server A gespeicherte Cache-Wert „1“ sein, während der in Server B gespeicherte Cache-Wert durch eine Änderung in Server B auf „2“ gesetzt wurde. In diesem Fall erhält der Benutzer bei einer Anfrage an den Load Balancer unterschiedliche Werte von Server A und Server B.

Daher muss für jeden Server der Cache automatisch entfernt und eine Abfrage von der RDB durchgeführt werden. Dazu wird hauptsächlich TTL verwendet.

Wie hoch sollte der TTL-Wert sein?

TTL steht für Time To Live (Zeit bis zum Ablauf) und ist eine Einstellung, mit der der Cache nach einer bestimmten Zeit gelöscht wird. Wenn beispielsweise TTL auf 5 Sekunden eingestellt ist, wird der Cache nach 5 Sekunden automatisch gelöscht. Wenn dann ein Cache-Fehler auftritt, werden die Daten aus der RDB abgerufen und gespeichert.

Wie hoch sollte der TTL-Wert also sein?

Lesen/Schreiben erfolgt auf einem Cache-Server

Wenn das Lesen/Schreiben auf einem globalen Cache-Server wie Redis oder auf einem Anwendungsserver mit lokalem Cache erfolgt, kann der TTL-Wert auch über Stunden oder Tage liegen. Beim Schreiben wird der vorhandene Cache ohnehin aktualisiert und der Server, der Daten aus diesem Cache abruft, erhält immer die aktuellsten Daten.

In diesem Fall kann TTL auch weggelassen werden und der Cache-Server kann durch den LRU-Algorithmus schrittweise automatisch geleert werden, wenn er voll ist.

Lesen/Schreiben erfolgt auf mehreren Cache-Servern

Wenn das Lesen/Schreiben auf mehreren globalen Cache-Servern oder auf mehreren Anwendungsservern mit lokalem Cache erfolgt, ist es ratsam, TTL im Bereich von Sekunden bis Minuten anzugeben. Dies liegt daran, dass möglicherweise veraltete Daten von einem Cache-Server gelesen werden, der die aktualisierten Daten noch nicht übernommen hat.

In diesem Fall hängt TTL von verschiedenen Kontexten ab. Je wichtiger die Aktualität und je höher die Wahrscheinlichkeit einer Wertänderung ist, desto kürzer sollte TTL sein. Je weniger wichtig die Aktualität und je geringer die Wahrscheinlichkeit einer Wertänderung ist, desto länger kann TTL sein.

Wie habe ich TTL konfiguriert?

Die zu cachenden Daten beziehen sich auf Zahlungsdaten. Selbst wenn der Cache nicht auf die strenge Logik angewendet wird, bei der tatsächlich Zahlungen stattfinden, ist die Aktualität aufgrund der Zahlungsmerkmale wichtig. Da die Wahrscheinlichkeit von Aktualisierungen jedoch gering ist, habe ich TTL vorsichtshalber auf 5 Sekunden festgelegt.

Fazit

Zusammenfassend lässt sich sagen, dass meine gewählte Cache-Methode wie folgt aussieht:

• Zahlungsdaten
• Sehr häufige Abfragen, aber kaum Änderungen.
• Cache wird nur auf Logiken angewendet, bei denen keine Zahlungen stattfinden, aber Abfragen ausgeführt werden.
• Lokaler Cache wird verwendet und TTL ist auf 5 Sekunden festgelegt.

Als Nächstes werde ich Leistungstests für die tatsächlich implementierte Cache-Methode durchführen. Wie genau die Leistungstests durchgeführt werden, überlege ich mir noch. Ich werde darüber in einem zukünftigen Beitrag berichten!