Übersicht über Memcache

Diese Seite bietet eine Übersicht über den Memcache-Dienst von App Engine. Leistungsfähige, skalierbare Webanwendungen verwenden für einige Aufgaben häufig einen verteilten speicherinternen Datencache vor einem robusten nichtflüchtigen Speicher oder anstelle dieses Speichers. App Engine bietet für diesen Zweck einen Speichercachedienst. Informationen zum Konfigurieren, Überwachen und Verwenden des Memcache-Dienstes finden Sie unter Memcache verwenden.

Gründe für die Verwendung eines Memcache

Ein Speichercache dient u. a. dazu, häufige Datenspeicherabfragen zu beschleunigen. Wenn viele Requests dieselbe Abfrage mit denselben Parametern senden und Änderungen an den Ergebnissen nicht sofort auf der Website angezeigt werden müssen, kann die Anwendung die Ergebnisse im Memcache zwischenspeichern. Nachfolgende Requests können den Memcache prüfen und erst dann die Datenspeicherabfrage ausführen, wenn Ergebnisse nicht vorhanden oder abgelaufen sind. Sitzungsdaten, Nutzereinstellungen und andere Daten, die von Abfragen für Webseiten zurückgegeben werden, eignen sich gut für das Caching.

Memcache kann für andere temporäre Werte nützlich sein. Wenn Sie jedoch erwägen, einen Wert ausschließlich im Memcache zu speichern und nicht in einem anderen nichtflüchtigen Speicher zu sichern, müssen Sie dafür sorgen, dass Ihre Anwendung bei plötzlicher Nichtverfügbarkeit des Werts auf angemessene Weise reagiert. Werte im Memcache können jederzeit ablaufen und vor dem für den Wert festgelegten Ablauftermin erlöschen. Wenn beispielsweise Sitzungsdaten eines Nutzers plötzlich nicht mehr verfügbar sind und dies zu einer fehlerhaften Sitzung führen würde, sollten diese Daten möglicherweise nicht nur im Memcache, sondern auch im Datenspeicher gespeichert werden.

Dienstebenen

App Engine unterstützt zwei Ebenen des Memcache-Dienstes:

  • Freigegebener Memcache ist der kostenlose Standard für App Engine-Anwendungen. Er bietet Cachekapazität auf Best-Effort-Basis und richtet sich nach der allgemeinen Nachfrage aller App Engine-Anwendungen, die den freigegebenen Memcache-Dienst nutzen.

  • Dedizierter Memcache bietet eine feste Cachekapazität, die exklusiv Ihrer Anwendung zugewiesen ist. Er wird nach Cachegröße in GB/Stunde in Rechnung gestellt und erfordert, dass die Abrechnung aktiviert ist. Wenn Sie Kontrolle über die Cachegröße haben, kann Ihre Anwendung vorhersehbarer und mit weniger Lesevorgängen aus dem teureren langlebigen Speicher ausgeführt werden.

Beide Memcache-Dienstebenen nutzen dieselbe API. Informationen zum Konfigurieren des Memcache-Dienstes für Ihre Anwendung finden Sie unter Memcache verwenden.

In der folgenden Tabelle werden die Unterschiede zwischen den beiden Memcache-Dienstklassen zusammengefasst:

Option Dedizierter Memcache Freigegebener Memcache
Preis 0,06 $ pro GB/Stunde Kostenlos
Kapazität
us-central
1 bis 100 GB
andere Regionen
1 bis 20 GB
Keine garantierte Kapazität
Leistung Bis zu 10.000 Lesevorgänge oder 5.000 Schreibvorgänge (exklusiv) pro Sekunde und GB (Elemente < 1 KB). Weitere Einzelheiten finden Sie unter Cachestatistiken. Nicht garantiert
Langlebige Speicherung Nein Nein
SLA

Die Abrechnung des dedizierten Memcache erfolgt in 15-Minuten-Schritten. Wenn Sie in einer anderen Währung als USD bezahlen, gelten die Preise, die in Cloud Platform SKUs in Ihrer Währung angegeben sind.

Wenn Ihre Anwendung mehr Memcache-Kapazität benötigt, wenden Sie sich an unser Vertriebsteam.

Limits

Folgende Limits gelten für die Verwendung des Memcache-Dienstes:

  • Die maximale Größe eines im Cache gespeicherten Datenwerts beträgt 1 MB (10^6 Byte).
  • Ein Schlüssel darf nicht größer als 250 Byte sein. In der Python-Laufzeit werden Schlüssel, bei denen es sich um Strings mit mehr als 250 Byte handelt, gehasht. (Andere Laufzeiten verhalten sich anders.)
  • "Multi"-Batchvorgänge können eine beliebige Anzahl von Elementen haben. Die Gesamtgröße des Aufrufs und der abgerufenen Daten darf 32 Megabyte nicht überschreiten.
  • Ein Memcache-Schlüssel darf kein Nullbyte enthalten.

Ablauf von Daten im Cache

Memcache enthält Schlüssel/Wert-Paare. Die im Speicher enthaltenen Paare ändern sich, wenn Elemente in den Cache geschrieben und aus diesem abgerufen werden.

Standardmäßig werden im Memcache gespeicherte Daten so lange wie möglich beibehalten. Werte können aus dem Cache entfernt werden, wenn dem Cache ein neuer Wert hinzugefügt wird und nicht genügend Speicher vorhanden ist. In diesem Fall werden die Werte, deren letzte Verwendung am längsten zurückliegt, zuerst entfernt.

Die Anwendung kann beim Speichern eines Werts eine Ablaufzeit festlegen, und zwar entweder als Sekundenzahl ab dem Zeitpunkt des Hinzufügens des Werts oder als absolute Sekundenzahl seit der Unix-Epoche, also dem 1. Januar 1970, Mitternacht. Der Wert wird spätestens zu diesem Zeitpunkt entfernt, er kann jedoch aus anderen Gründen auch früher entfernt werden. Wenn Sie den Wert erhöhen, der für einen vorhandenen Schlüssel gespeichert ist, wird dessen Ablaufzeit nicht aktualisiert.

In seltenen Fällen können Werte auch aus anderen Gründen als Speicherauslastung vor dem Ablauf aus dem Cache entfernt werden. Memcache kann zwar Serverfehlern standhalten, doch werden Memcache-Werte nicht auf einem Laufwerk gespeichert. Somit können Dienstfehler dazu führen, dass Werte nicht mehr verfügbar sind.

Im Allgemeinen sollte eine Anwendung nicht davon ausgehen, dass im Cache gespeicherte Werte immer zur Verfügung stehen.

Sie können den gesamten Cache einer Anwendung über die API oder im Memcache-Bereich der Google Cloud Platform Console löschen.

Cachestatistiken

Vorgänge pro Sekunde nach Elementgröße

Dedizierter Memcache wird in Vorgängen pro Sekunde und GB bemessen, wobei ein Vorgang als einzelner Zugriff auf ein Cacheelement definiert ist (z. B. get, set oder delete). Die Vorgangsrate variiert in Abhängigkeit von der Elementgröße, wie der folgenden Tabelle zu entnehmen ist. Ein Überschreiten dieser Werte kann zu erhöhten API-Latenzzeiten oder Fehlern führen.

Die folgenden Tabellen enthalten die maximale Anzahl von kontinuierlichen, exklusiven get-hit- oder set-Vorgängen pro GB an Cache. Ein get-hit-Vorgang ist ein get-Aufruf, der einen gespeicherten Wert mit dem angegebenen Schlüssel vorfindet und diesen Wert zurückgibt.

Elementgröße (KB) Maximale get-hit-OPS/s Maximale set-OPS/s
≤1 10.000 5.000
100 2.000 1.000
512 500 250

Eine Anwendung, die für mehrere GB an Cache konfiguriert ist, kann theoretisch eine Gesamtvorgangsrate erzielen, die sich aus der Anzahl von GB multipliziert mit der Rate pro GB berechnet. Beispiel: Eine Anwendung, die für 5 GB an Cache konfiguriert ist, kann 50.000 Memcache-Vorgänge pro Sekunde für Elemente von 1 KB erreichen. Das Erreichen dieses Levels erfordert eine gute Lastverteilung im Memcache-Schlüsselraum, wie unter Best Practices für App Engine-Memcache beschrieben.

Die oben aufgeführten Limits beziehen sich auf Lese- oder Schreibvorgänge für jedes E/A-Schema. Bei gleichzeitigen Lese- und Schreibvorgängen bewegen sich die Limits auf einer Gleitskala. Je mehr Lesevorgänge stattfinden, desto weniger Schreibvorgänge können ausgeführt werden und umgekehrt. Alle der folgenden Werte sind Beispiel-IOPS-Limits für gleichzeitige Lese- und Schreibvorgänge von 1 KB großen Werten pro 1 GB Cache:

Lese-IOPS Schreib-IOPS
10.000 0
8.000 1.000
5.000 2.500
1.000 4.500
0 5.000

Memcache-Recheneinheiten (MCU)

Der Memcache-Durchsatz kann abhängig von der Größe des Elements, auf das Sie zugreifen, und dem Vorgang, den Sie für das Element ausführen möchten, variieren. Mit einer Einheit namens Memcache-Recheneinheit (Memcache Compute Unit, MCU) können Sie Vorgängen ungefähre Kosten zuordnen und die von einem dedizierten Memcache zur erwartende Zugriffskapazität schätzen. Die MCU ist so definiert, dass Sie 10.000 MCU pro Sekunde und GB an dediziertem Memcache erwarten können. In der Google Cloud Platform Console ist zu sehen, wie viele MCUs derzeit von Ihrer Anwendung verwendet werden.

MCU ist eine grobe statistische Schätzung und außerdem keine lineare Einheit. Jeder Cachevorgang, der einen Wert liest oder schreibt, ist mit entsprechenden MCU-Kosten verbunden, die von der Größe des Werts abhängen. Wie viel MCU ein set-Vorgang beansprucht, hängt von der Größe des Werts ab. Er kostet zweimal so viel wie ein erfolgreicher get-hit-Vorgang.

Größe des Wertelements (KB) MCU-Kosten für get-hit MCU-Kosten für set
≤1 1,0 2,0
2 1,3 2,6
10 1,7 3,4
100 5,0 10,0
512 20,0 40,0
1.024 50,0 100,0

Vorgänge, die keinen Wert lesen oder schreiben, haben feste MCU-Kosten:

Vorgang MCU
get-miss 1,0
delete 2,0
increment 2,0
flush 100,0
stats 100,0

Ein get-miss-Vorgang ist ein get-Vorgang, der keinen gespeicherten Wert für den angegebenen Schlüssel vorfindet.

Compare-and-Set (Vergleichen und Einstellen)

Compare-and-Set ist eine Funktion, die zulässt, dass mehrere gleichzeitig verarbeitete Anfragen den Wert desselben Memcache-Schlüssels unteilbar aktualisieren können. Auf diese Weise werden Race-Bedingungen vermieden.

Wichtige logische Komponenten von Compare-and-Set

Wenn Sie den Wert eines Memcache-Schlüssels aktualisieren, der andere gleichzeitige Schreib-Requests erhalten kann, müssen Sie das Memcache-Objekt Client verwenden. Dieses Objekt enthält bestimmte Statusinformationen, die von den Methoden verwendet werden, die Compare-and-Set unterstützen. Sie können die Memcache-Funktionen get() oder set() verwenden, da sie zustandslos sind. Die Klasse Client selbst ist nicht threadsicher, daher sollten Sie dasselbe Objekt Client nicht in mehreren Threads verwenden.

Beim Abrufen von Schlüsseln müssen Sie die Memcache-Client-Methoden verwenden, die Compare-and-Set unterstützen: gets() oder get_multi(), wobei der Parameter for_cas auf True eingestellt ist.

Beim Aktualisieren von Schlüsseln müssen Sie die Memcache-Client-Methoden verwenden, die Compare-and-Set unterstützen: cas() oder cas_multi().

Die andere wichtige logische Komponente ist der Memcache-Dienst von App Engine und dessen Verhalten in Bezug auf Compare-and-Set. Der Memcache-Dienst von App Engine selbst verhält sich unteilbar. Das heißt, wenn zwei gleichzeitige Requests (für dieselbe App-ID) Memcache verwenden, werden sie zur gleichen Memcache-Dienstinstanz weitergeleitet. Der Memcache-Dienst hat genügend interne Sperren, sodass gleichzeitige Requests für denselben Schlüssel ordnungsgemäß serialisiert werden. Das bedeutet insbesondere, dass zwei cas()-Requests für denselben Schlüssel nicht parallel ausgeführt werden. Der Dienst schließt die Verarbeitung des Requests, der zuerst einging, vollständig ab (d. h. Aktualisieren des Werts und Zeitstempels), bevor der zweite Request verarbeitet wird.

Weitere Informationen zum Verwenden von Compare-and-Set in Python finden Sie unter Gleichzeitige Schreibvorgänge verwalten.

Best Practices

Im Folgenden finden Sie einige Best Practices für die Verwendung von Memcache:

  • Behandeln Sie Memcache API-Fehler ordnungsgemäß. Memcache-Vorgänge können aus verschiedenen Gründen fehlschlagen. Anwendungen sollten so konzipiert werden, dass fehlgeschlagene Vorgänge abgefangen werden, ohne diese Fehler den Endnutzern anzuzeigen. Diese Empfehlung gilt insbesondere für Set-Vorgänge.

  • Verwenden Sie nach Möglichkeit die Batchfunktion der API, insbesondere für kleine Elemente. Hierdurch wird die Leistung und Effizienz Ihrer Anwendung erhöht.

  • Verteilen Sie die Last über Ihren Memcache-Schlüsselraum. Wenn ein einzelnes Memcache-Element oder ein kleiner Satz Memcache-Elemente ein unverhältnismäßiges Volumen an Zugriffen darstellt, wird die Skalierung Ihrer Anwendung beeinträchtigt. Diese Empfehlung gilt sowohl für Vorgänge pro Sekunde als auch für die Bandbreite. Sie können dieses Problem häufig beheben, indem Sie Ihre Daten explizit fragmentieren.

    Sie können beispielsweise einen häufig aktualisierten Zähler auf mehrere Schlüssel aufteilen, sie zurücklesen und nur addieren, wenn Sie eine Gesamtsumme benötigen. Ebenso lassen sich 500 KB an Daten, die bei jedem HTTP-Request gelesen werden müssen, auf mehrere Schlüssel aufteilen und dann mit einem einzigen API-Batchaufruf zurücklesen. (Noch besser ist es, den Wert im Instanzspeicher zwischenzuspeichern.) Bei dediziertem Memcache sollte die maximale Zugriffsrate für einen einzelnen Schlüssel um ein bis zwei Größenordnungen unter der Pro-GB-Rate liegen.

Weitere Einzelheiten und Best Practices für Gleichzeitigkeit, Leistung und Migration, einschließlich der Freigabe von Memcache für verschiedene Programmiersprachen, finden Sie im Artikel Best Practices für App Engine-Memcache.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

App Engine-Standardumgebung für Python