App Engine-Standorte
App Engine ist regional, was bedeutet, dass sich die Infrastruktur, in der Ihre Anwendungen ausgeführt werden, in einer bestimmten Region befindet und Google sie so verwaltet, dass sie redundant in allen Zonen innerhalb dieser Region verfügbar ist.
Die Erfüllung der Latenz-, Verfügbarkeits- oder Langlebigkeitsanforderungen ist der wichtigste Gesichtspunkt bei der Auswahl der Region, in der Ihre Anwendungen ausgeführt werden sollen. Sie können normalerweise die Region auswählen, die den Nutzern Ihrer Anwendung am nächsten ist. Sie sollten jedoch die Standorte, an denen App Engine verfügbar ist und die Standorte der anderen Google Cloud-Produkte und -Dienste berücksichtigen, die Ihre Anwendung nutzt. Eine Nutzung von Diensten über mehrere Standorte kann die Latenz der Anwendung sowie die Preise beeinflussen.
Sie können die Region einer Anwendung nicht mehr ändern, nachdem Sie sie festgelegt haben.
Wenn Sie bereits eine App Engine-Anwendung erstellt haben, können Sie die Region mit einer der folgenden Methoden aufrufen:
Führen Sie den Befehl
gcloud app describe
aus:Öffnen Sie das App Engine-Dashboard in der Google Cloud Console. Die Region wird oben auf der Seite angezeigt.
Cloud NDB ist eine Clientbibliothek für Python, die App Engine NDB ersetzt.
Mit App Engine NDB können Python 2-Anwendungen Daten in Firestore-Datenbanken im Datastore-Modus (Datastore) speichern und abfragen. Mit Cloud NDB lassen sich mit Python 3-Anwendungen Daten in denselben Datenbanken speichern und abfragen. Datastore verwendet das Produkt, das diese Datenbanken verwaltet. Obwohl die Cloud NDB-Bibliothek auf alle mit App Engine NDB erstellten Daten zugreifen kann, ist ein Zugriff auf einige in Cloud NDB gespeicherte strukturierte Datentypen nicht möglich. Aus diesem Grund sollte die Migration zu Cloud NDB nicht wieder rückgängig gemacht werden.
Neuere Versionen von Cloud NDB unterstützen nur Python 3. Frühere Versionen haben sowohl Python 2 als auch Python 3 unterstützt. Zum Migrieren Ihrer Python 2-Anwendung zu Python 3 empfehlen wir Folgendes:
- Migration zu Cloud NDB, Version 1.11.2 Dies ist der letzte Release, der Python 2 unterstützt.
- Führen Sie ein Upgrade Ihrer Anwendung auf Python 3 durch.
- Führen Sie ein Upgrade auf die neueste stabile Version von Cloud NDB durch.
Durch diesen inkrementell ausgerichteten Migrationsansatz haben Sie im gesamten Migrationsprozess die Möglichkeit, eine funktionierende und testfähige Anwendung zu nutzen.
Cloud NDB ist für Python-Entwickler gedacht, die mit App Engine NDB vertraut sind und ihre Anwendung modernisieren möchten. Die Migration zu Cloud NDB hilft Ihnen bei der Vorbereitung der Python 2-Anwendung für Python 3 und bietet Ihnen die Möglichkeit, bei Bedarf später die App Engine zu deaktivieren.
Weitere Informationen zu Cloud NDB finden Sie auf den folgenden Seiten:
App Engine NDB und Cloud NDB im Vergleich
Gemeinsamkeiten:
- Cloud NDB unterstützt fast alle Features, die von App Engine NDB unterstützt werden. Es bestehen nur geringfügige Unterschiede im Hinblick auf die Methodensyntax.
Unterschiede:
App Engine NDB APIs, die auf laufzeitspezifischen Python 2.7-Diensten von App Engine beruhen, wurden entweder aktualisiert oder aus Cloud NDB entfernt.
Durch neue Features in Python 3 und Django ist
google.appengine.ext.ndb.django_middleware
nicht mehr erforderlich. Stattdessen können Sie mit nur wenigen Codezeilen Ihre eigene Middleware schreiben.Bei App Engine NDB mussten Anwendungen und die Datastore-Datenbank im selben Google Cloud-Projekt enthalten sein, wobei App Engine die Anmeldedaten automatisch bereitgestellt hat. Cloud NDB kann in jedem Projekt auf Datenbanken im Datastore-Modus zugreifen, solange Ihr Client ordnungsgemäß authentifiziert ist. Dies entspricht anderen Google Cloud APIs und Clientbibliotheken.
Cloud NDB verwendet den App Engine-Memcache-Dienst zum Zwischenspeichern von Daten nicht.
Stattdessen kann Cloud NDB Daten in einem Redis-In-Memory-Datenspeicher zwischenspeichern, der von Memorystore, Redis Labs oder anderen Systemen verwaltet wird. Während derzeit nur Redis-Datenspeicher unterstützt werden, bietet Cloud NDB ein allgemeines definiertes Caching in der abstrakten
GlobalCache
-Schnittstelle, mit der zusätzliche konkrete Implementierungen unterstützt werden können.Für den Zugriff auf Memorystore for Redis muss Ihre Anwendung den serverlosen VPC-Zugriff verwenden.
Weder Memorystore for Redis noch der serverlose VPC-Zugriff bieten eine kostenlose Stufe. Darüber hinaus sind diese Produkte möglicherweise nicht in der Region Ihrer Anwendung verfügbar. Weitere Informationen finden Sie unter Vorbereitung der Migration.
Die vollständige Liste der Unterschiede finden Sie in den Migrationshinweisen für das Cloud NDB-GitHub-Projekt.
Codebeispiele:
Grundlegende Datenbankvorgänge mit Cloud NDB
Grundlegende Datenbankvorgänge mit App Engine NDB
Vorbereitung der Migration
Vorbereitung der Migration:
Wenn Sie Daten zwischenspeichern müssen, achten Sie darauf, dass die Region Ihrer Anwendung vom serverlosen VPC-Zugriff und Memorystore for Redis unterstützt wird.
Informieren Sie sich über Berechtigungen im Datastore-Modus.
Ermitteln, ob Daten im Cache gespeichert werden müssen
Sie sollten darauf achten, dass für Ihre Anwendung ein Caching erforderlich ist, da Memorystore for Redis und der serverlose VPC-Zugriff keine kostenlose Stufe haben und nicht alle Google Cloud-Regionen unterstützen.
Allgemein gilt:
Wenn Ihre Anwendung häufig dieselben Daten liest, kann Caching die Latenz verringern.
Je mehr Anfragen Ihre Anwendung verarbeitet, desto größer ist die Auswirkung auf das Caching.
Wenn Sie prüfen möchten, wie viele Daten Sie derzeit im Cache speichern, sehen Sie sich im Memcache-Dashboard das Verhältnis von Cache-Treffern zu Fehlern an. Wenn das Verhältnis hoch ist, sollten Sie eventuell einen Datencache verwenden, um die Latenz Ihrer Anwendung zu reduzieren.
Informationen zu den Preisen finden Sie unter Memorystore-Preise und Preise für serverlosen VPC-Zugriff.
Region Ihrer Anwendung bestätigen
Wenn Sie Daten im Cache speichern müssen, prüfen Sie, ob die Region Ihrer Anwendung von Memorystore for Redis und dem serverlosen VPC-Zugriff unterstützt wird:
Schauen Sie sich die Region Ihrer Anwendung an, die oben im App Engine-Dashboard in der Google Cloud Console angezeigt wird.
Die Region wird oben auf der Seite direkt unter der URL Ihrer Anwendung angezeigt.
Prüfen Sie, ob sich Ihre Anwendung in einer der Regionen befindet, die vom serverlosen VPC-Zugriff unterstützt werden.
Prüfen Sie, ob sich Ihre Anwendung in einer von Memorystore for Redis unterstützten Region befindet. Rufen Sie dazu die Seite „Connector erstellen“ auf und sehen Sie sich die Regionen in der Liste Regionen an.
Wenn sich Ihre Anwendung nicht in einer Region befindet, die von Memorystore for Redis und dem serverlosen VPC-Zugriff unterstützt wird:
Google Cloud-Projekt erstellen.
Erstellen Sie eine neue App Engine-Anwendung im Projekt und wählen Sie eine unterstützte Region aus.
Erstellen Sie die Google Cloud-Dienste, die Ihre Anwendung im neuen Projekt verwendet.
Sie können Ihre Anwendung auch so anpassen, dass sie die vorhandenen Dienste in Ihrem alten Projekt verwendet. Die Preise und die Ressourcennutzung können jedoch unterschiedlich ausfallen, wenn Sie Dienste in einem anderen Projekt und einer anderen Region verwenden. Weitere Informationen finden Sie in der Dokumentation zu den einzelnen Diensten.
Stellen Sie die Anwendung im neuen Projekt bereit.
Informationen zu Berechtigungen im Datastore-Modus
Jede Interaktion mit einem Google Cloud-Dienst muss autorisiert werden. Wenn beispielsweise Daten in einer Datenbank im Datastore-Modus gespeichert oder abgefragt werden sollen, muss Ihre Anwendung die Anmeldedaten eines Kontos bereitstellen, das für den Zugriff auf die Datenbank autorisiert ist.
Standardmäßig stellt Ihre Anwendung die Anmeldedaten für das Standarddienstkonto von App Engine bereit, das zum Zugriff auf Datenbanken in demselben Projekt wie Ihre Anwendung berechtigt ist.
In den folgenden Situationen benötigen Sie eine andere Authentifizierungsmethode, mit der Anmeldedaten explizit bereitgestellt werden:
Ihre Anwendung und die Datenbank im Datastore-Modus befinden sich in verschiedenen Google Cloud-Projekten.
Sie haben die Rollen geändert, die dem App Engine-Standarddienstkonto zugewiesen sind.
Informationen zu alternativen Authentifizierungsmethoden finden Sie unter Authentifizierung für Server-zu-Server-Produktionsanwendungen einrichten.
Übersicht über den Migrationsprozess
So migrieren Sie von App Engine NDB zu Cloud NDB:
Aktualisieren Sie die Python-Anwendung:
Installieren Sie die Cloud NDB-Clientbibliothek.
Aktualisieren Sie die Importanweisungen, um Module aus Cloud NDB zu importieren.
Fügen Sie Code hinzu, mit dem ein Cloud NDB-Client erstellt wird. Der Client kann die Umgebungsvariablen Ihrer Anwendung lesen und die Daten zum Authentifizieren im Datastore-Modus nutzen.
Fügen Sie Code hinzu, in dem der Laufzeitkontext des Clients verwendet wird, um das Caching und die Transaktionen zwischen Threads zu trennen.
Entfernen oder aktualisieren Sie Code, der nicht mehr unterstützte Methoden und Attribute verwendet.
Stellen Sie die Anwendung in App Engine bereit.
Wie bei jeder Änderung, die Sie an Ihrer Anwendung vornehmen, sollten Sie Traffic möglicherweise aufteilen, um ihn langsam zu erhöhen. Überwachen Sie die Anwendung genau in Bezug auf Datenbankprobleme, bevor Sie zusätzlichen Traffic an die aktualisierte Anwendung weiterleiten.
Python-Anwendung aktualisieren
Cloud NDB-Bibliothek für Python 2-Anwendungen installieren
Erstellen Sie ein Verzeichnis, in dem Sie die Bibliotheken von Drittanbietern speichern können, beispielsweise
lib/
.Erstellen Sie im Ordner mit der Datei
app.yaml
eine Dateirequirements.txt
und fügen Sie den Namen der Clientbibliothek hinzu:google-cloud-ndb==1.11.2
Verwenden Sie
pip
(ab Version 6) mit dem Flag-t <directory>
, um die Bibliotheken in dem Ordner zu installieren, den Sie im vorherigen Schritt erstellt haben. Beispiel:pip install -t lib -r requirements.txt
Geben Sie die RPC- und
setuptools
-Bibliotheken im Abschnittlibraries
Ihrer Dateiapp.yaml
an:libraries: - name: grpcio version: 1.0.0 - name: setuptools version: 36.6.0
Erstellen Sie eine Datei
appengine_config.py
im selben Ordner wie die Dateiapp.yaml
, falls Sie noch keine haben. Fügen Sie der Dateiappengine_config.py
Folgendes hinzu:# appengine_config.py import pkg_resources from google.appengine.ext import vendor # Set path to your libraries folder. path = 'lib' # Add libraries installed in the path folder. vendor.add(path) # Add libraries to pkg_resources working set to find the distribution. pkg_resources.working_set.add_entry(path)
Achten Sie darauf, dass das Modul
pkg_resources
verwendet wird. Dieses Modul sorgt dafür, dass Ihre Anwendung die richtige Verteilung der Clientbibliotheken nutzt.Bei der Datei
appengine_config.py
im obigen Beispiel wird davon ausgegangen, dass sich der Ordnerlib
im aktuellen Arbeitsverzeichnis befindet. Wenn Sie nicht garantieren können, dass sichlib
immer im aktuellen Arbeitsverzeichnis befindet, geben Sie den vollständigen Pfad zum Ordnerlib
an. Beispiel:import os path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
Wenn Sie Ihre Anwendung bereitstellen, lädt App Engine alle Bibliotheken in das Verzeichnis hoch, das Sie in der Datei appengine_config.py
angegeben haben.
Cloud NDB-Bibliothek für Python 3-Anwendungen installieren
Die App Engine-Python 3-Laufzeit ermittelt auf der Grundlage der Datei requirements.txt
einer Anwendung, welche Pakete und Versionen für die Anwendungen installiert werden sollen. Zum Installieren der Cloud NDB-Bibliothek in der Python 3-Laufzeit fügen Sie der Datei requirements.txt
Ihrer Anwendung die folgende Zeile hinzu:
google-cloud-ndb
App Engine lädt automatisch alle Bibliotheken in der Datei requirements.txt
der Anwendung hoch, wenn Sie die Anwendung bereitstellen.
Abhängigkeiten lokal installieren
Wenn Sie Ihre Anwendung lokal entwickeln und testen, sollten Sie unbedingt eine virtuelle Umgebung verwenden, um die Abhängigkeiten Ihrer Anwendung von Ihren Systempaketen zu isolieren. Dadurch gewährleisten Sie, dass Ihre Anwendung nur die Abhängigkeiten lädt, die Sie in der Datei requirements.txt
Ihrer Anwendung deklariert haben. Außerdem synchronisiert die Anwendung dadurch Abhängigkeitsversionen zwischen Ihrer lokalen Umgebung und der Produktionsumgebung.
In Python 2 können Sie mit virtualenv eine virtuelle Umgebung erstellen.
Für Python 3 empfehlen wir zum Erstellen einer virtuellen Umgebung venv.
Importanweisungen aktualisieren
Der Speicherort des NDB-Moduls wurde nach google.cloud.ndb
verschoben. Aktualisieren Sie deshalb die Importanweisungen Ihrer Anwendung wie im Folgenden dargestellt:
Entfernen | Ersetzen durch |
---|---|
from google.appengine.ext import ndb |
from google.cloud import ndb |
Cloud NDB-Client erstellen
Wie bei anderen Clientbibliotheken, die auf Google Cloud APIs beruhen, muss im ersten Schritt zur Verwendung von Cloud NDB ein Client
-Objekt erstellt werden. Der Client enthält Anmeldedaten und andere Daten, die für das Herstellen einer Verbindung zum Datastore-Modus erforderlich sind. Beispiel:
from google.cloud import ndb
client = ndb.Client()
Im zuvor beschriebenen Standardszenario für die Autorisierung enthält der Cloud NDB-Client Anmeldedaten aus dem Standarddienstkonto von App Engine, das zur Interaktion mit dem Datastore-Modus berechtigt ist. Wenn Sie nicht in diesem Standardszenario arbeiten, finden Sie unter Standardanmeldedaten für Anwendungen Informationen zum Bereitstellen von Anmeldedaten.
Laufzeitkontext des Clients verwenden
Zusätzlich zu den Anmeldedaten, die für die Interaktion mit dem Datastore-Modus erforderlich sind, enthält der Cloud NDB-Client die Methode context()
, die einen Laufzeitkontext zurückgibt.
Der Laufzeitkontext trennt Caching- und Transaktionsanfragen von anderen gleichzeitig stattfindenden Interaktionen mit dem Datastore-Modus.
Alle Interaktionen mit dem Datastore-Modus müssen innerhalb eines NDB-Laufzeitkontexts erfolgen. Da beim Erstellen einer Modelldefinition nicht mit dem Datastore-Modus interagiert wird, können Sie Ihre Modellklasse definieren, bevor Sie einen Cloud NDB-Client erstellen und einen Laufzeitkontext abrufen, und dann mit dem Laufzeitkontext im Anfrage-Handler Daten aus der Datenbank abrufen.
Beispiel:
Multithread-Anwendungen
Der Laufzeitkontext, den der Cloud NDB-Client zurückgibt, gilt nur für einen einzelnen Thread. Wenn Ihre Anwendung mehrere Threads für eine einzelne Anfrage nutzt, müssen Sie für jeden Thread, der die Cloud NDB-Bibliothek verwendet, einen separaten Laufzeitkontext abrufen.
Laufzeitkontext mit WSGI-Frameworks verwenden
Wenn Ihre Webanwendung ein WSGI-Framework verwendet, können Sie automatisch einen neuen Laufzeitkontext für jede Anfrage erstellen. Dazu legen Sie ein Middleware-Objekt an, das den Laufzeitkontext abruft, und binden dann die Anwendung in das Middleware-Objekt ein.
Im folgenden Beispiel für die Verwendung von Middleware mit Flask gilt Folgendes:
Die Methode
middleware
erstellt ein WSGI-Middleware-Objekt im Laufzeitkontext des NDB-Clients.Die Flask-Anwendung ist in das Middleware-Objekt eingebunden.
Flask leitet dann jede Anfrage über das Middleware-Objekt weiter, das einen neuen NDB-Laufzeitkontext für jede Anfrage abruft.
Laufzeitkontext mit Django verwenden
Die von der App Engine NDB-Bibliothek bereitgestellte Django-Middleware wird von der Cloud NDB-Bibliothek nicht unterstützt. Wenn Sie diese Middleware (google.appengine.ext.ndb.django_middleware
) in Ihrer Anwendung nutzen, müssen Sie sie so aktualisieren:
Verwenden Sie das Middleware-System von Django, um für jede Anfrage einen neuen Laufzeitkontext zu erstellen.
Im folgenden Beispiel gilt:
Mit der Methode
ndb_django_middleware
wird ein Cloud NDB-Client erstellt.Mit der Methode
middleware
wird ein Middleware-Objekt im Laufzeitkontext des NDB-Clients angelegt.
Ändern Sie in der Django-Datei „settings.py“ die Einstellung
MIDDLEWARE
, damit die neue Middleware angezeigt wird, die Sie anstelle vongoogle.appengine.ext.ndb.NdbDjangoMiddleware
erstellt haben.
Django leitet dann jede Anfrage über das Middleware-Objekt weiter, das Sie in der Einstellung MIDDLEWARE
aufgelistet haben. Dieses Objekt ruft für jede Anfrage einen neuen NDB-Laufzeitkontext ab.
Code für entfernte oder geänderte NDB APIs aktualisieren
NDB APIs, denen App Engine-spezifische APIs und Dienste zugrunde liegen, wurden entweder aktualisiert oder aus der Cloud NDB-Bibliothek entfernt.
Sie müssen deshalb Ihren Code entsprechend ändern, wenn darin eine der folgenden NDB APIs verwendet wird:
google.appengine.ext.ndb.Model
und Modellattributegoogle.appengine.ext.ndb.Key
google.appengine.ext.ndb.query.QueryOptions
undPropertyOrder
google.appengine.ext.ndb.utils
google.appengine.api.namespacemanager
google.appengine.api.ext.ndb.tasklets
google.appengine.api.datastore_errors
Modelle und Modellattribute
Die in der folgenden Tabelle aufgeführten Methoden aus google.appengine.ext.ndb.Model
sind in der Cloud NDB-Bibliothek nicht verfügbar, da sie App Engine-spezifische APIs verwenden, die nicht mehr zur Verfügung stehen.
Entfernte API | Ersetzen |
---|---|
Model.get_indexes und Model.get_indexes_async |
– |
Model._deserialize und Model._serialize |
– |
Model.make_connection
|
– |
In der folgenden Tabelle sind die einzelnen google.appengine.ext.ndb.Model
-Attribute dargestellt, die sich in der Cloud NDB-Bibliothek geändert haben:
Attribut | Ändern |
---|---|
TextProperty
|
google.cloud.ndb.TextProperty kann nicht indexiert werden. Wenn Sie versuchen, google.cloud.ndb.TextProperty.indexed festzulegen, wird der Fehler NotImplementedError ausgelöst.
|
StringProperty
|
StringProperty wird immer indexiert. Wenn Sie versuchen, google.cloud.ndb.StringProperty.indexed festzulegen, wird der Fehler NotImplementedError ausgelöst.
|
Alle Attribute mit den Argumenten name oder kind im Konstruktor |
name oder kind müssen den Datentyp str haben, da unicode in Python 3 durch str ersetzt wurde. |
Die Klassen und Methoden in der folgenden Tabelle sind nicht mehr verfügbar, da sie App Engine-spezifische Ressourcen verwenden, die nicht mehr zur Verfügung stehen.
Entfernte API | Ersetzen |
---|---|
google.appengine.ext.ndb.msgprop.MessageProperty und google.appengine.ext.ndb.msgprop.EnumProperty |
–
Wenn Sie versuchen, diese Objekte zu erstellen, wird der Fehler |
von
google.appengine.ext.ndb.model.Property :_db_get_value _db_set_value _db_set_compressed_meaning _db_set_uncompressed_meaning __creation_counter_global |
–
Diese Methoden beruhen auf Protokollzwischenspeichern im Datastore-Modus, die geändert wurden. |
Model.make_connection
|
– |
Schlüssel
Die unten aufgeführten Methoden aus google.appengine.ext.ndb.Key
sind in der Cloud NDB-Bibliothek nicht verfügbar. Diese Methoden wurden verwendet, um Schlüssel an die DB Datastore API zu übergeben und daraus zu übernehmen. Dies wird nicht mehr unterstützt (DB war der Vorgänger von App Engine NDB).
Entfernte API | Ersetzen |
---|---|
Key.from_old_key und Key.to_old_key |
– |
Beachten Sie außerdem die folgenden Änderungen:
App Engine NDB | Cloud NDB |
---|---|
Arten und String-IDs müssen kleiner als 500 Byte sein. | Arten und String-IDs müssen kleiner als 1.500 Byte sein. |
Key.app() gibt die Projekt-ID zurück, die Sie beim Erstellen des Schlüssels angegeben haben. |
Der von google.cloud.ndb.Key.app() zurückgegebene Wert weicht möglicherweise von der ursprünglichen ID ab, die an den Konstruktor übergeben wurde. Das liegt daran, dass Anwendungs-IDs mit einem Präfix wie s~example Legacy-IDs von App Engine sind.
Sie wurden durch entsprechende Projekt-IDs wie example ersetzt.
|
Abfragen
Wie App Engine NDB bietet Cloud NDB eine QueryOptions
-Klasse (google.cloud.ndb.query.QueryOptions
), mit der Sie einen bestimmten Satz von Abfrageoptionen wiederverwenden können, anstatt sie für jede Abfrage neu zu definieren. Allerdings erfolgt für QueryOptions
in Cloud NDB keine Übernahme von google.appengine.datastore.datastore_rpc.Configuration
und es werden daher auch keine ...datastore_rpc.Configuration
-Methoden unterstützt.
Darüber hinaus wurde google.appengine.datastore.datastore_query.Order
durch google.cloud.ndb.query.PropertyOrder
ersetzt. Wie mit Order
können Sie mit der Klasse PropertyOrder
die Sortierreihenfolge für mehrere Abfragen festlegen. Der Konstruktor PropertyOrder
ist mit dem Konstruktor für Order
identisch. Nur der Name der Klasse hat sich geändert.
Entfernte API | Ersetzen |
---|---|
von google.appengine.datastore.datastore_rpc.Configuration :deadline(value) on_completion(value) read_policy(value) force_writes(value) max_entity_groups_per_rpc(value) max_allocate_ids_keys(value) max_rpc_bytes(value) max_get_keys(value) max_put_entities(value) max_delete_keys(value) Eine Beschreibung dieser Methoden finden Sie im Quellcode. |
– |
google.appengine.ext.ndb.Order Zum Beispiel: order=Order(-Account.birthday, Account.name) |
google.cloud.ndb.PropertyOrder Zum Beispiel: google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name) |
Utils
Das Modul ndb.utils
(google.appengine.ext.ndb.utils
) ist nicht mehr verfügbar. Die meisten Methoden in diesem Modul waren interne Methoden von App Engine NDB. Einige Methoden wurden aufgrund von Implementierungsunterschieden in der neuen NDB verworfen, während andere Methoden aufgrund von neuen Python 3-Features veraltet sind. Eine kleine Anzahl der Methoden bleibt verfügbar, um die Migration zu erleichtern.
Beispielsweise wurde durch den positionellen Dekorator im alten utils
-Modul festgelegt, dass nur die ersten n Argumente einer Funktion oder Methode positionell sein dürfen. Mit Python 3 ist dies jedoch mit Nur-Schlüsselwort-Argumenten möglich. Bisher sah der Code so aus:
@utils.positional(2)
def function1(arg1, arg2, arg3=None, arg4=None)
pass
In Python 3 kann dies so geschrieben werden:
def function1(arg1, arg2, *, arg3=None, arg4=None)
pass
Namespaces
Mit Namespaces können mehrinstanzenfähige Anwendungen separate Datensilos für jeden Mandanten nutzen und dafür dieselbe Datenbank im Datastore-Modus verwenden. Das bedeutet, dass jeder Mandant Daten in seinem eigenen Namespace speichert.
Statt eines App Engine-spezifischen google.appengine.api.namespacemanager
geben Sie beim Erstellen eines Cloud NDB-Clients einen Standard-Namespace an und nutzen diesen dann durch Aufrufen von Cloud NDB-Methoden im Laufzeitkontext des Clients. Dies entspricht dem Ansatz anderer Google Cloud APIs, die Namespaces unterstützen.
Entfernte API | Ersetzen |
---|---|
google.appengine.api.namespace_manager.namespace_manager.set_namespace(str)
und google.appengine.api.namespacemanager.getnamespace() |
client=google.cloud.ndb.Client(namespace="my namespace") with client.context() as context: key = ndb.Key("SomeKind", "SomeId") key-non-default-namespace=ndb.Key("SomeKind," "AnotherId", namespace="non-default-nspace") |
Alle anderen google.appengine.api.namespacemanager -Methoden |
– |
Tasklets
Mit Tasklets kann jetzt eine standardmäßige return
-Anweisung verwendet werden, um ein Ergebnis zurückzugeben, anstatt eine Return
-Ausnahme auszulösen. Beispiel:
App Engine NDB-Bibliothek | Cloud NDB-Bibliothek |
---|---|
@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() raise Return(cart) |
@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() return cart |
Beachten Sie, dass Sie in Cloud NDB durch Auslösen einer Return
-Ausnahme weiterhin Ergebnisse zurückgeben können. Dies wird aber nicht empfohlen.
Außerdem sind die folgenden Methoden und abgeleiteten Klassen für Tasklets
nicht mehr verfügbar, hauptsächlich aufgrund von Änderungen in Bezug auf das Erstellen und Verwenden eines NDB-Kontexts in der Cloud NDB-Bibliothek.
Entfernte API | Ersetzen |
---|---|
aus
google.appengine.api.ext.ndb.tasklets :add_flow_exception make_context make_default_context set_context |
– |
von
google.appengine.api.ext.ndb.tasklets :QueueFuture ReducedFuture SerialQueueFuture |
– |
Ausnahmen
Das Modul google.cloud.ndb.exceptions
in der Cloud NDB-Bibliothek enthält immer noch viele Ausnahmen aus der App Engine NDB-Bibliothek. In der neuen Bibliothek sind aber nicht mehr alle alten Ausnahmen verfügbar. In der folgenden Tabelle sind die Ausnahmen aufgeführt, die nicht mehr zur Verfügung stehen:
Entfernte API | Ersetzen |
---|---|
von
google.appengine.api.datastore_errors :BadKeyError BadPropertyError CommittedButStillApplying EntityNotFoundError InternalError NeedIndexError QueryNotFoundError ReferencePropertyResolveError Timeout TransactionFailedError TransactionNotFoundError |
google.cloud.ndb.exceptions |
Daten-Caching aktivieren
Cloud NDB kann Daten in einem Redis-In-Memory-Datenspeicher zwischenspeichern, der von Memorystore, Redis Labs oder anderen Systemen verwaltet wird. In diesem Leitfaden wird gezeigt, wie Sie mit Memorystore for Redis Daten im Cache zwischenspeichern:
Serverlosen VPC-Zugriff einrichten
Ihre Anwendung kann mit Memorystore nur über einen Connector für serverlosen VPC-Zugriff kommunizieren. So richten Sie einen Connector für serverlosen VPC-Zugriff ein:
Memorystore for Redis einrichten
So richten Sie Memorystore for Redis ein:
Erstellen Sie eine Redis-Instanz in Memorystore. Wenn Sie die Instanz erstellen:
Wählen Sie unter Region die gleiche Region aus, in der sich Ihre App Engine-Anwendung befindet.
Wählen Sie unter Autorisiertes Netzwerk dasselbe Netzwerk aus, das Ihr Connector für serverlosen VPC-Zugriff verwendet.
Notieren Sie sich die IP-Adresse und die Portnummer der von Ihnen erstellten Redis-Instanz. Sie benötigen diese Informationen zum Aktivieren des Daten-Caching für Cloud NDB.
Achten Sie darauf, die Anwendungs-Updates mit dem Befehl
gcloud beta
bereitzustellen. Ihre Anwendung kann nur durch den Beta-Befehl für die Verwendung eines VPC-Connectors aktualisiert werden.
Redis-Verbindungs-URL hinzufügen
Sie können eine Verbindung zum Redis-Cache herstellen. Fügen Sie dafür die Umgebungsvariable REDIS_CACHE_URL
zur Datei app.yaml
der Anwendung hinzu. Der Wert für REDIS_CACHE_URL
hat folgendes Format:
redis://IP address for your instance:port
Beispielsweise können Sie der Datei app.yaml
Ihrer Anwendung die folgenden Zeilen hinzufügen:
env_variables:
REDIS_CACHE_URL: redis://10.0.0.3:6379
Redis-Cache-Objekt erstellen und anwenden
Wenn Sie REDIS_CACHE_URL
als Umgebungsvariable festgelegt haben, können Sie mit einer einzelnen Codezeile ein RedisCache-Objekt erstellen und den Cache dann beim Einrichten des Laufzeitkontexts an Client.context()
übergeben:
client = ndb.Client()
global_cache = ndb.RedisCache.from_environment()
with client.context(global_cache=global_cache):
books = Book.query()
for book in books:
print(book.to_dict())
Wenn Sie REDIS_CACHE_URL
nicht als Umgebungsvariable angegeben haben, müssen Sie einen Redis-Client erstellen und den Client an den Konstruktor ndb.RedisCache()
übergeben. Beispiel:
global_cache = ndb.RedisCache(redis.StrictRedis(host=IP-address, port=redis_port))
Beachten Sie, dass Sie keine Abhängigkeit in Bezug auf die Redis-Clientbibliothek deklarieren müssen, da die Cloud NDB-Bibliothek bereits auf der Redis-Clientbibliothek beruht.
Ein Beispiel für das Erstellen eines Redis-Clients finden Sie in der Memorystore-Beispielanwendung.
Aktualisierungen testen
So richten Sie eine Testdatenbank ein und führen Ihre Anwendung lokal aus, bevor Sie sie in App Engine bereitstellen:
Führen Sie den lokalen Datastore-Modus-Emulator aus, um Daten zu speichern und abzurufen.
Folgen Sie der Anleitung zum Festlegen von Umgebungsvariablen, damit Ihre Anwendung eine Verbindung zum Emulator statt zur Produktionsumgebung für den Datastore-Modus herstellt.
Sie können auch Daten in den Emulator importieren, wenn Sie Ihren Test mit Daten starten möchten, die vorab in die Datenbank geladen wurden.
Verwenden Sie den lokalen Entwicklungsserver, um Ihre Anwendung auszuführen.
Damit die Umgebungsvariable
GOOGLE_CLOUD_PROJECT
für die lokale Entwicklung korrekt festgelegt ist, müssen Siedev_appserver
mit dem folgenden Parameter initialisieren:--application=PROJECT_ID
PROJECT_ID sollte Ihre Google Cloud-Projekt-ID sein. Sie finden Ihre Projekt-ID mit dem Befehl
gcloud config list project
oder auf Ihrer Projektseite in der Google Cloud Console.
Anwendung bereitstellen
Sobald Ihre Anwendung auf dem lokalen Entwicklungsserver fehlerfrei ausgeführt wird:
Wenn die Anwendung fehlerfrei ausgeführt wird, verwenden Sie die Trafficaufteilung, um den Traffic für die aktualisierte Anwendung langsam hochzufahren. Prüfen Sie die Anwendung genau auf mögliche Datenbankprobleme, bevor Sie mehr Traffic zur aktualisierten Anwendung leiten.