Zu Cloud NDB migrieren

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:

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:

  1. Migration zu Cloud NDB, Version 1.11.2 Dies ist der letzte Release, der Python 2 unterstützt.
  2. Führen Sie ein Upgrade Ihrer Anwendung auf Python 3 durch.
  3. 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:

Vorbereitung der Migration

Vorbereitung der Migration:

  1. Ermitteln Sie, ob Sie Daten im Cache speichern müssen.

  2. 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.

  3. 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.

Memcache-Dashboard anzeigen

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:

  1. Schauen Sie sich die Region Ihrer Anwendung an, die oben im App Engine-Dashboard in der Google Cloud Console angezeigt wird.

    Dashboard öffnen

    Die Region wird oben auf der Seite direkt unter der URL Ihrer Anwendung angezeigt.

  2. Prüfen Sie, ob sich Ihre Anwendung in einer der Regionen befindet, die vom serverlosen VPC-Zugriff unterstützt werden.

  3. 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.

    Zur Seite „Connector erstellen“

Wenn sich Ihre Anwendung nicht in einer Region befindet, die von Memorystore for Redis und dem serverlosen VPC-Zugriff unterstützt wird:

  1. Google Cloud-Projekt erstellen.

  2. Erstellen Sie eine neue App Engine-Anwendung im Projekt und wählen Sie eine unterstützte Region aus.

  3. 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.

  4. 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:

  1. Aktualisieren Sie die Python-Anwendung:

    1. Installieren Sie die Cloud NDB-Clientbibliothek.

    2. Aktualisieren Sie die Importanweisungen, um Module aus Cloud NDB zu importieren.

    3. 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.

    4. Fügen Sie Code hinzu, in dem der Laufzeitkontext des Clients verwendet wird, um das Caching und die Transaktionen zwischen Threads zu trennen.

    5. Entfernen oder aktualisieren Sie Code, der nicht mehr unterstützte Methoden und Attribute verwendet.

  2. Aktivieren Sie das Caching.

  3. Testen Sie Ihre Aktualisierungen.

  4. 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

  1. Erstellen Sie ein Verzeichnis, in dem Sie die Bibliotheken von Drittanbietern speichern können, beispielsweise lib/.

  2. Erstellen Sie im Ordner mit der Datei app.yaml eine Datei requirements.txt und fügen Sie den Namen der Clientbibliothek hinzu:

    google-cloud-ndb==1.11.2

  3. 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

  4. Geben Sie die RPC- und setuptools-Bibliotheken im Abschnitt libraries Ihrer Datei app.yaml an:

    libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

  5. Erstellen Sie eine Datei appengine_config.py im selben Ordner wie die Datei app.yaml, falls Sie noch keine haben. Fügen Sie der Datei appengine_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 Ordner lib im aktuellen Arbeitsverzeichnis befindet. Wenn Sie nicht garantieren können, dass sich lib immer im aktuellen Arbeitsverzeichnis befindet, geben Sie den vollständigen Pfad zum Ordner lib 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:

datastore/cloud-ndb/quickstart.py
from google.cloud import ndb

class Book(ndb.Model):
    title = ndb.StringProperty()

client = ndb.Client()

def list_books():
    with client.context():
        books = Book.query()
        for book in books:
            print(book.to_dict())

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.

datastore/cloud-ndb/flask_app.py
from flask import Flask

from google.cloud import ndb

client = ndb.Client()

def ndb_wsgi_middleware(wsgi_app):
    def middleware(environ, start_response):
        with client.context():
            return wsgi_app(environ, start_response)

    return middleware

app = Flask(__name__)
app.wsgi_app = ndb_wsgi_middleware(app.wsgi_app)  # Wrap the app in middleware.

class Book(ndb.Model):
    title = ndb.StringProperty()

@app.route('/')
def list_books():
    books = Book.query()
    return str([book.to_dict() for book in books])

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:

  1. 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.

    datastore/cloud-ndb/django_middleware.py
    from google.cloud import ndb

# Once this middleware is activated in Django settings, NDB calls inside Django
# views will be executed in context, with a separate context for each request.
def ndb_django_middleware(get_response):
    client = ndb.Client()

    def middleware(request):
        with client.context():
            return get_response(request)

    return middleware

  2. Ändern Sie in der Django-Datei „settings.py“ die Einstellung MIDDLEWARE, damit die neue Middleware angezeigt wird, die Sie anstelle von google.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:

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 NotImplementedError ausgelöst.
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")
oder 

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:

  1. Richten Sie einen serverlosen VPC-Zugriff ein.

  2. Richten Sie Memorystore for Redis ein.

  3. Fügen Sie die Redis-Verbindungs-URL zu Ihrer Anwendung hinzu.

  4. Erstellen Sie ein RedisCache-Objekt.

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:

  1. Erstellen Sie einen Connector für serverlosen VPC-Zugriff.

  2. Konfigurieren Sie Ihre Anwendung für die Verwendung des Connectors.

Memorystore for Redis einrichten

So richten Sie Memorystore for Redis ein:

  1. Erstellen Sie eine Redis-Instanz in Memorystore. Wenn Sie die Instanz erstellen:

  2. 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:

  1. 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.

  2. 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 Sie dev_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:

  1. Testen Sie die Anwendung in App Engine.

  2. 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.