מעבר ל-Cloud NDB

מיקומים של App Engine

‫App Engine הוא אזורי, כלומר התשתית שמריצה את האפליקציות שלכם ממוקמת באזור ספציפי, ו-Google מנהלת אותה כך שהיא זמינה באופן יתירתי בכל התחומים באזור הזה.

הקריטריונים העיקריים לבחירת האזור שבו האפליקציות יפעלו הם זמן האחזור, הזמינות או העמידות. בדרך כלל אפשר לבחור את האזור הקרוב ביותר למשתמשי האפליקציה, אבל כדאי גם לעיין במיקומים שבהם App Engine זמין ובמיקומים של מוצרים ושירותים אחרים שלGoogle Cloud שבהם האפליקציה משתמשת. שימוש בשירותים בכמה מיקומים יכול להשפיע על זמן האחזור של האפליקציה וגם על התמחור שלה.

אחרי שמגדירים את האזור של אפליקציה, אי אפשר לשנות אותו.

אם כבר יצרתם אפליקציית App Engine, תוכלו לראות את האזור שלה באחת מהדרכים הבאות:

‫Cloud NDB היא ספריית לקוח ל-Python שמחליפה את NDB ב-App Engine. ‫NDB של App Engine מאפשר לאפליקציות לאחסן נתונים במסדי נתונים של Datastore ולבצע בהם שאילתות. ‫Cloud NDB מאפשר לאפליקציות Python 3 לאחסן נתונים ולשלוח שאילתות לגביהם באותם מסדי נתונים, אבל המוצר שמנהל את מסדי הנתונים האלה השתנה מ-Datastore ל-Firestore במצב Datastore. למרות שספריית Cloud NDB יכולה לגשת לכל הנתונים שנוצרו באמצעות App Engine NDB, לא ניתן לגשת לנתונים מובְנים מסוימים שאוחסנו באמצעות Cloud NDB באמצעות App Engine NDB. לכן, המעבר ל-Cloud NDB הוא בלתי הפיך.

‫Cloud NDB נועד להחליף את התכונות ב-App Engine NDB, ולכן הוא לא יתמוך בתכונות חדשות של Firestore במצב Datastore. מומלץ להשתמש בספריית הלקוח במצב Datastore באפליקציות חדשות במקום ב-Cloud NDB.

מידע נוסף על Cloud NDB זמין בדפים הבאים ב-GitHub:

השוואה בין App Engine NDB לבין Cloud NDB

תכונות דומות:

  • ‫Cloud NDB תומך כמעט בכל התכונות שנתמכות ב-App Engine NDB, עם הבדלים קלים בלבד בתחביר של השיטות.

הבדלים:

  • ממשקי API של App Engine NDB שמסתמכים על שירותים ספציפיים של זמן ריצה מדור קודם של App Engine עודכנו או הוסרו מ-Cloud NDB.

  • תכונות חדשות ב-Python 3 וב-Django מבטלות את הצורך ב-google.appengine.ext.ndb.django_middleware. אפשר לכתוב תוכנת ביניים משלכם בכמה שורות קוד בלבד.

  • כדי להשתמש ב-NDB ב-App Engine, האפליקציות ומסד הנתונים של Datastore צריכים להיות באותו פרויקט Google Cloud , ו-App Engine מספק את פרטי הכניסה באופן אוטומטי. ל-Cloud NDB יש גישה למסדי נתונים במצב Datastore בכל פרויקט, כל עוד הלקוח מאומת בצורה תקינה. השיטה הזו עקבית עם ממשקי API אחרים וספריות לקוח. Google Cloud

  • ‫Cloud NDB לא משתמש בשירות Memcache של App Engine כדי לשמור נתונים במטמון.

    במקום זאת, Cloud NDB שומר נתונים במטמון ב-Redis, שהוא מאגר נתונים בזיכרון שמנוהל על ידי Memorystore,‏ Redis או מערכות אחרות. אף על פי שרק מאגרי נתונים של Redis נתמכים, Cloud NDB הכללי והגדיר אחסון במטמון בממשק GlobalCacheמופשט, שיכול לתמוך בהטמעות קונקרטיות נוספות.

    כדי לגשת ל-Memorystore for Redis, האפליקציה צריכה להשתמש בחיבור לרשת (VPC) מאפליקציית serverless.

    ל-Memorystore for Redis ול-Serverless VPC Access אין רמת שימוש חינמית, ויכול להיות שהמוצרים האלה לא זמינים באזור של האפליקציה שלכם. מידע נוסף זמין במאמר לפני שמתחילים בהעברה.

הרשימה המלאה של ההבדלים זמינה בהערות ההעברה לפרויקט Cloud NDB GitHub.

דוגמאות קוד:

לפני ההעברה

לפני שמתחילים בהעברה:

  1. אם עדיין לא עשיתם זאת, צריך להגדיר סביבת פיתוח בשפת Python לשימוש בגרסת Python שתואמת ל- Google Cloud, ולהתקין כלי בדיקה ליצירת סביבות Python מבודדות.

  2. קובעים אם צריך לשמור נתונים במטמון.

  3. אם אתם צריכים לשמור נתונים במטמון, ודאו שהאזור של האפליקציה נתמך על ידי Serverless VPC Access ו-Memorystore for Redis.

  4. הסבר על ההרשאות במצב Datastore

האם צריך לשמור נתונים במטמון

אם האפליקציה שלכם צריכה לשמור נתונים במטמון, חשוב לדעת של-Memorystore for Redis ול-Serverless VPC Access אין רמת שירות בחינם, והם לא תומכים בכלGoogle Cloud האזורים.

באופן כללי:

  • אם האפליקציה קוראת את אותם נתונים לעיתים קרובות, שמירת נתונים במטמון יכולה להקטין את זמן האחזור.

  • ככל שהאפליקציה מציגה יותר בקשות, כך ההשפעה של השמירה במטמון גדולה יותר.

כדי לראות עד כמה אתם מסתמכים על נתונים במטמון, אפשר לעיין בלוח הבקרה של Memcache כדי לראות את היחס בין פגיעות במטמון לבין החמצות במטמון. אם היחס גבוה, סביר להניח שלשימוש במטמון נתונים תהיה השפעה גדולה על צמצום זמן האחזור של האפליקציה.

מעבר אל App Engine Memcache

למידע על תמחור, אפשר לעיין במאמרים בנושא תמחור של Memorystore ותמחור של גישה ל-VPC ללא שרתים.

אישור האזור

אם אתם צריכים לשמור נתונים במטמון, אתם צריכים לוודא שהאזור של האפליקציה נתמך על ידי Memorystore for Redis ו-Serverless VPC Access:

  1. אפשר לראות את האזור של האפליקציה, שמופיע בחלק העליון של לוח הבקרה של App Engine במסוף Google Cloud .

    מעבר אל App Engine

    האזור מופיע בחלק העליון של הדף, ממש מתחת לכתובת ה-URL של האפליקציה.

  2. מוודאים שהאפליקציה נמצאת באחד האזורים שנתמכים על ידי Serverless VPC Access.

  3. כדי לוודא שהאפליקציה שלכם נמצאת באחד מהאזורים שנתמכים על ידי Memorystore for Redis, נכנסים לדף Create connector (יצירת מחבר) ומסתכלים על האזורים ברשימה Regions (אזורים).

    מעבר אל חיבור לרשת (VPC) מאפליקציית serverless

אם האפליקציה לא נמצאת באזור שנתמך על ידי Memorystore for Redis וחיבור לרשת (VPC) מאפליקציית serverless:

  1. יוצרים Google Cloud פרויקט.

  2. יוצרים אפליקציית App Engine חדשה בפרויקט ובוחרים אזור נתמך.

  3. יוצרים את Google Cloud השירותים שהאפליקציה משתמשת בהם בפרויקט החדש.

    אפשרות אחרת היא לעדכן את האפליקציה כך שתשתמש בשירותים הקיימים בפרויקט הישן, אבל יכול להיות שהתמחור ושימוש המשאבים יהיו שונים כשמשתמשים בשירותים בפרויקט ובאזור אחרים. מידע נוסף זמין במסמכי התיעוד של כל שירות.

  4. פורסים את האפליקציה בפרויקט החדש.

הסבר על ההרשאות במצב Datastore

כל אינטראקציה עם שירות של Google Cloud צריכה להיות מאושרת. לדוגמה, כדי לאחסן נתונים במסד נתונים במצב Datastore או לשלוח אליו שאילתות, האפליקציה צריכה לספק את פרטי הכניסה של חשבון שיש לו הרשאה לגשת למסד הנתונים.

כברירת מחדל, האפליקציה מספקת את פרטי הכניסה של חשבון השירות שמוגדר כברירת מחדל ב-App Engine, שיש לו הרשאה לגשת למסדי נתונים באותו פרויקט שבו נמצאת האפליקציה.

אם אחד מהתנאים הבאים מתקיים, תצטרכו להשתמש בטכניקת אימות חלופית שמספקת פרטי כניסה באופן מפורש:

  • האפליקציה ומסד הנתונים במצב Datastore נמצאים בGoogle Cloud פרויקטים שונים.

  • שיניתם את התפקידים שהוקצו לחשבון השירות שמוגדר כברירת מחדל ב-App Engine.

מידע על טכניקות אימות חלופיות זמין במאמר הגדרת אימות לאפליקציות ייצור מסוג Server to Server.

סקירה כללית של תהליך המיגרציה

כדי לעבור ל-Cloud NDB:

  1. עדכון אפליקציית Python:

    1. מתקינים את ספריית הלקוח Cloud NDB.

    2. מעדכנים את הצהרות הייבוא כדי לייבא מודולים מ-Cloud NDB.

    3. מוסיפים קוד שיוצר לקוח Cloud NDB. הלקוח יכול לקרוא את משתני הסביבה של האפליקציה ולהשתמש בנתונים כדי לבצע אימות במצב Datastore.

    4. מוסיפים קוד שמשתמש בהקשר של זמן הריצה של הלקוח כדי להפריד בין מטמון ועסקאות בין השרשורים.

    5. מסירים או מעדכנים קוד שמשתמש בשיטות ובמאפיינים שכבר לא נתמכים.

  2. הפעלת שמירה במטמון.

  3. בודקים את העדכונים.

  4. פריסת האפליקציה ב-App Engine.

    כמו בכל שינוי שאתם מבצעים באפליקציה, כדאי להשתמש בפיצול תנועה כדי להגדיל את התנועה בהדרגה. לפני שמפנים עוד תנועה לאפליקציה המעודכנת, חשוב לעקוב מקרוב אחרי האפליקציה כדי לוודא שאין בעיות במסד הנתונים.

עדכון אפליקציית Python

כדי להעביר את האפליקציה ל-Cloud NDB, צריך להתקין את ספריית הלקוח ולעדכן את הקוד.

התקנת ספריית Cloud NDB לאפליקציות Python

כדי להתקין את ספריית הלקוח של Cloud NDB באפליקציית Python ב-App Engine:

  1. מעדכנים את הקובץ app.yaml. מציינים את רכיב runtime עם גרסת Python נתמכת. לדוגמה, קובץ app.yaml יכול להיראות כך:

    runtime: python310 # or another supported version

    סביבת זמן הריצה של Python מתקינה ספריות באופן אוטומטי, כך שלא צריך לציין ספריות מובנות. אם אפליקציית Python שלכם משתמשת בשירותים אחרים שצורפו לחבילה מדור קודם במהלך ההעברה, אל תשנו את הקובץ app.yaml.

  2. מעדכנים את הקובץ requirements.txt. מוסיפים את ספריות הלקוח של Cloud NDB לרשימת התלויות בקובץ requirements.txt.

    google-cloud-ndb

    ‫App Engine מתקין את התלויות האלה באופן אוטומטי במהלך פריסת האפליקציה, לכן צריך למחוק את התיקייה lib אם היא קיימת.

עדכון הצהרות ייבוא

המיקום של מודול ה-NDB הועבר אל google.cloud.ndb. מעדכנים את הצהרות הייבוא של האפליקציה כמו שמוצג בטבלה הבאה:

הסרה החלף ב
from google.appengine.ext import ndb from google.cloud import ndb

יצירת לקוח Cloud NDB

בדומה לספריות לקוח אחרות שמבוססות על ממשקי API, השלב הראשון בשימוש ב-Cloud NDB הוא ליצור אובייקטClient. Google Cloud הלקוח מכיל פרטי כניסה ונתונים אחרים שנדרשים כדי להתחבר למצב Datastore. לדוגמה:

from google.cloud import ndb

client = ndb.Client()

בתרחיש ההרשאה שמוגדר כברירת מחדל שמתואר למעלה, לקוח Cloud NDB מכיל פרטי כניסה מחשבון השירות שמוגדר כברירת מחדל ב-App Engine, שיש לו הרשאה ליצור אינטראקציה עם מצב Datastore. אם אתם לא עובדים בתרחיש ברירת המחדל הזה, תוכלו לקרוא את המאמר Application Default Credentials (ADC) כדי לקבל מידע על העברת פרטי כניסה.

שימוש בהקשר של זמן הריצה של הלקוח

בנוסף לאישורים שנדרשים לאינטראקציה עם מצב Datastore, לקוח Cloud NDB מכיל את ה-method‏ context() שמחזירה הקשר של זמן ריצה. ההקשר של זמן הריצה מבודד את בקשות השמירה במטמון ואת בקשות העסקאות מאינטראקציות מקבילות אחרות במצב Datastore.

כל האינטראקציות עם מצב Datastore צריכות להתרחש בהקשר של זמן ריצה של NDB. מכיוון שיצירת הגדרת מודל לא יוצרת אינטראקציה עם מצב Datastore, אפשר להגדיר את מחלקת המודל לפני שיוצרים לקוח Cloud NDB ומאחזרים הקשר של זמן ריצה, ואז להשתמש בהקשר של זמן הריצה ב-handler של הבקשה כדי לקבל נתונים ממסד הנתונים.

לדוגמה:

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())

אפליקציות מרובות-הליכים

הקשר של זמן הריצה שמוחזר על ידי לקוח Cloud NDB רלוונטי רק לשרשור יחיד. אם האפליקציה משתמשת בכמה שרשורים לבקשה אחת, צריך לאחזר הקשר נפרד של זמן הריצה לכל שרשור שישתמש בספריית Cloud NDB.

שימוש בהקשר של זמן ריצה עם מסגרות WSGI

אם אפליקציית האינטרנט שלכם משתמשת במסגרת WSGI, אתם יכולים ליצור באופן אוטומטי הקשר חדש של זמן ריצה לכל בקשה. לשם כך, צריך ליצור אובייקט של תוכנת ביניים שמחלץ את ההקשר של זמן הריצה, ואז לעטוף את האפליקציה באובייקט של תוכנת הביניים.

בדוגמה הבאה לשימוש בתוכנת ביניים עם Flask:

  • השיטה middleware יוצרת אובייקט של תוכנת ביניים WSGI בהקשר של זמן הריצה של לקוח NDB.

  • אפליקציית Flask עטופה באובייקט של תוכנת ביניים.

  • לאחר מכן, Flask יעביר כל בקשה דרך אובייקט התוכנה, שיאחזר הקשר חדש של זמן ריצה של NDB לכל בקשה.

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])

שימוש בהקשר של זמן ריצה עם Django

תוכנת הביניים של Django שמסופקת על ידי ספריית App Engine NDB לא נתמכת על ידי ספריית Cloud NDB. אם השתמשתם בתוכנת הביניים הזו (google.appengine.ext.ndb.django_middleware) באפליקציה שלכם, צריך לפעול לפי השלבים הבאים כדי לעדכן את האפליקציה:

  1. משתמשים במערכת התוכנה של Django כדי ליצור הקשר חדש בזמן ריצה לכל בקשה.

    בדוגמה הבאה:

    • השיטה ndb_django_middleware יוצרת לקוח Cloud NDB.

    • השיטה middleware יוצרת אובייקט של תוכנת ביניים בהקשר של זמן הריצה של לקוח NDB.

    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. בקובץ settings.py של Django, מעדכנים את ההגדרה MIDDLEWARE כך שיופיע בה רשימה של תוכנת הביניים החדשה שיצרתם במקום google.appengine.ext.ndb.NdbDjangoMiddleware.

מערכת Django תעביר עכשיו כל בקשה דרך אובייקט ה-middleware שציינתם בהגדרה MIDDLEWARE, והאובייקט הזה יאחזר הקשר חדש של זמן ריצה של NDB לכל בקשה.

עדכון הקוד לממשקי NDB API שהוסרו או השתנו

ממשקי NDB APIs שמסתמכים על ממשקי API ושירותים ספציפיים של App Engine עודכנו או הוסרו מספריית Cloud NDB.

אם הקוד שלכם משתמש באחד מממשקי ה-API הבאים של NDB, תצטרכו לעדכן אותו:

מודלים ומאפייני מודלים

השיטות הבאות מ-google.appengine.ext.ndb.Model לא זמינות בספריית Cloud NDB כי הן משתמשות בממשקי API ספציפיים ל-App Engine שכבר לא זמינים.

הסרנו API החלפה
‫Model.get_indexes ו-
Model.get_indexes_async 		ללא
‫Model._deserialize וגם
Model._serialize 		ללא
Model.make_connection ללא

בטבלה הבאה מתוארים המאפיינים הספציפיים של google.appengine.ext.ndb.Model ששונו בספריית Cloud NDB:

מאפיין (property) שינוי
TextProperty אי אפשר להוסיף לאינדקס את google.cloud.ndb.TextProperty. אם תנסו להגדיר את google.cloud.ndb.TextProperty.indexed, תופיע שגיאה NotImplementedError.
StringProperty ‫StringProperty תמיד עובר אינדוקס. אם תנסו להגדיר את google.cloud.ndb.StringProperty.indexed, תופיע NotImplementedError.
כל המאפיינים עם ארגומנטים של name או kind בקונסטרוקטור. ‫name או kind חייבים להיות מסוגי הנתונים str, כי unicode הוחלף ב-str ב-Python 3.

המחלקות וה-methods בטבלה הבאה כבר לא זמינות, כי הן משתמשות במשאבים ספציפיים ל-App Engine שכבר לא זמינים.

הסרנו API החלפה
‫google.appengine.ext.ndb.msgprop.MessageProperty ו-
google.appengine.ext.ndb.msgprop.EnumProperty 		ללא

אם תנסו ליצור את האובייקטים האלה, תופיע הודעת שגיאה NotImplementedError.
google.appengine.ext.ndb.model.Property:
_db_get_value
_db_set_value
_db_set_compressed_meaning
_db_set_uncompressed_meaning
__creation_counter_global 		ללא

השיטות האלה מסתמכות על מאגרי פרוטוקולים במצב Datastore שהשתנו.
Model.make_connection ללא

מקשים

השיטות הבאות מ-google.appengine.ext.ndb.Key לא זמינות בספריית Cloud NDB. השיטות האלה שימשו להעברת מפתחות אל ומממשק DB API, שכבר לא נתמך (DB הוא קודמו של App Engine NDB).

הסרנו API החלפה
‫Key.from_old_key וגם
Key.to_old_key 		ללא

בנוסף, חשוב לשים לב לשינויים הבאים:

App Engine NDB Cloud NDB
הסוגים והמזהים של המחרוזות צריכים להיות קטנים מ-500 בייטים הסוגים והמזהים של המחרוזות צריכים להיות קצרים מ-1,500 בייט.
‫Key.app() מחזירה את מזהה הפרויקט שציינתם כשנוצר המפתח. יכול להיות שהערך שמוחזר על ידי google.cloud.ndb.Key.app() יהיה שונה מהמזהה המקורי שהועבר אל הבונה. הסיבה לכך היא שמזהי אפליקציות עם קידומת כמו s~example הם מזהים מדור קודם מ-App Engine. הם הוחלפו במזהי פרויקט מקבילים, כמו example.

שאילתות

בדומה ל-App Engine NDB, ‏ Cloud NDB מספק מחלקה QueryOptions (google.cloud.ndb.query.QueryOptions) שמאפשרת לכם לעשות שימוש חוזר בקבוצה ספציפית של אפשרויות שאילתה במקום להגדיר אותן מחדש לכל שאילתה. עם זאת, QueryOptions ב-Cloud NDB לא יורש מ-google.appengine.datastore.datastore_rpc.Configuration ולכן לא תומך בשיטות של ...datastore_rpc.Configuration.

בנוסף, google.appengine.datastore.datastore_query.Order הוחלף ב-google.cloud.ndb.query.PropertyOrder. בדומה ל-Order, המחלקה PropertyOrder מאפשרת לציין את סדר המיון בכמה שאילתות. ה-constructor‏ PropertyOrder זהה ל-constructor של Order. רק השם של הכיתה השתנה.

הסרנו API החלפה
מאת 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)

בקוד המקור מופיע תיאור של השיטות האלה.

 ללא
google.appengine.ext.ndb.Order
לדוגמה:
order=Order(-Account.birthday, Account.name) 		google.cloud.ndb.PropertyOrder
לדוגמה:
google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name)

Utils

המודול ndb.utils (google.appengine.ext.ndb.utils) לא זמין יותר. רוב השיטות במודול הזה היו פנימיות ל-App Engine NDB, חלק מהשיטות בוטלו בגלל הבדלים בהטמעה ב-ndb החדש, וחלק מהשיטות הפכו ללא רלוונטיות בגלל תכונות חדשות של Python 3.

לדוגמה, מעצב המיקום במודול utils הישן הצהיר שרק n הארגומנטים הראשונים של פונקציה או שיטה יכולים להיות מיקומיים. עם זאת, ב-Python 3 אפשר לעשות את זה באמצעות ארגומנטים של מילות מפתח בלבד. מה שהיה כתוב בעבר:

@utils.positional(2)
def function1(arg1, arg2, arg3=None, arg4=None)
  pass

אפשר לכתוב את זה כך ב-Python 3:

def function1(arg1, arg2, *, arg3=None, arg4=None)
  pass

מרחבי שמות

מרחבי שמות מאפשרים לאפליקציה עם ריבוי דיירים להשתמש במאגרי נתונים נפרדים לכל דייר, ועדיין להשתמש באותו מסד נתונים במצב Datastore. כלומר, כל דייר מאחסן נתונים במרחב שמות משלו.

במקום להשתמש ב-google.appengine.api.namespacemanager שספציפי ל-App Engine, מציינים מרחב שמות שמוגדר כברירת מחדל כשיוצרים לקוח Cloud NDB, ואז משתמשים במרחב השמות שמוגדר כברירת מחדל על ידי קריאה לשיטות Cloud NDB בהקשר של זמן הריצה של הלקוח. התבנית הזו זהה לתבנית של ממשקי API אחרים Google Cloud שתומכים במרחבי שמות.

הסרנו API החלפה
google.appengine.api.namespace_manager.namespace_manager.set_namespace(str) וגם
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")
כל שאר השיטות של google.appengine.api.namespacemanager ללא

Tasklets

עכשיו אפשר להשתמש ב-Tasklets בהצהרת return Python רגילה כדי להחזיר תוצאה במקום להפעיל חריגה של NDB Return. לדוגמה:

ספריית NDB של App Engine ספריית Cloud NDB 
        @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

שימו לב: עדיין אפשר להחזיר תוצאות ב-Cloud NDB על ידי העלאת חריגה (exception), אבל לא מומלץ לעשות זאת.Return

בנוסף, השיטות ומחלקות המשנה הבאות של Tasklets כבר לא זמינות, בעיקר בגלל שינויים באופן שבו נוצר ומשמש הקשר של NDB בספריית Cloud NDB.

הסרנו API החלפה
מאת google.appengine.api.ext.ndb.tasklets:
add_flow_exception
make_context
make_default_context
set_context 		ללא
מאת google.appengine.api.ext.ndb.tasklets:
QueueFuture
ReducedFuture
SerialQueueFuture 		ללא

חריגים

הספרייה google.cloud.ndb.exceptions module בספריית Cloud NDB מכילה הרבה מהחריגים של ספריית App Engine NDB, אבל לא כל החריגים הישנים זמינים בספרייה החדשה. בטבלה הבאה מפורטים החריגים שכבר לא זמינים:

הסרנו API החלפה
from google.appengine.api.datastore_errors:
BadKeyError
BadPropertyError
CommittedButStillApplying
EntityNotFoundError
InternalError
NeedIndexError
QueryNotFoundError
ReferencePropertyResolveError
Timeout
TransactionFailedError
TransactionNotFoundError 		google.cloud.ndb.exceptions

הפעלת שמירת נתונים במטמון

‫Cloud NDB יכול לשמור נתונים במטמון במאגר נתונים בזיכרון של Redis שמנוהל על ידי Memorystore,‏ Redis או מערכות אחרות. במדריך הזה מוסבר איך להשתמש ב-Memorystore for Redis כדי לשמור נתונים במטמון:

  1. הגדרת חיבור לרשת (VPC) מאפליקציית serverless

  2. הגדרת Memorystore for Redis

  3. מוסיפים את כתובת ה-URL של החיבור ל-Redis לאפליקציה.

  4. יצירת אובייקט RedisCache.

הגדרת חיבור לרשת (VPC) מאפליקציית serverless

האפליקציה יכולה לתקשר עם Memorystore רק דרך מחבר של חיבור לרשת (VPC) מאפליקציית serverless. כדי להגדיר מחבר של חיבור לרשת (VPC) מאפליקציית serverless:

  1. יצירת מחבר של חיבור לרשת (VPC) מאפליקציית serverless

  2. הגדרת האפליקציה לשימוש במחבר

הגדרת Memorystore for Redis

כדי להגדיר את Memorystore for Redis:

  1. יוצרים מכונת Redis ב-Memorystore. כשיוצרים את המופע:

  2. חשוב לשים לב לכתובת ה-IP ולמספר היציאה של מופע Redis שיוצרים. תשתמשו במידע הזה כשמפעילים שמירת נתונים במטמון ב-Cloud NDB.

    חשוב להשתמש בפקודה gcloud beta כדי לפרוס את עדכוני האפליקציה. רק פקודת הבטא יכולה לעדכן את האפליקציה שלכם כדי להשתמש במחבר VPC.

הוספת כתובת ה-URL של חיבור Redis

כדי להתחבר למטמון Redis, מוסיפים את משתנה הסביבה REDIS_CACHE_URL לקובץ app.yaml של האפליקציה. הערך של REDIS_CACHE_URL מופיע באופן הבא:

redis://IP address for your instance:port

לדוגמה, אפשר להוסיף את השורות הבאות לקובץ app.yaml של האפליקציה:

     env_variables:
      REDIS_CACHE_URL: redis://10.0.0.3:6379

יצירה ושימוש באובייקט מטמון Redis

אם הגדרתם את REDIS_CACHE_URL כמשתנה סביבה, אתם יכולים ליצור אובייקט RedisCache בשורה אחת של קוד, ואז להשתמש במטמון על ידי העברתו אל Client.context() כשאתם מגדירים את הקשר של זמן הריצה:

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())

אם לא מגדירים את REDIS_CACHE_URL כמשתנה סביבה, צריך ליצור אובייקט של לקוח Redis ולהעביר אותו לבונה ndb.RedisCache(). לדוגמה:

global_cache = ndb.RedisCache(redis.StrictRedis(host=IP-address, port=redis_port))

שימו לב שלא צריך להצהיר על תלות בספריית הלקוח של Redis, כי ספריית Cloud NDB כבר תלויה בספריית הלקוח של Redis.

בדוגמה ליצירת לקוח Redis אפשר לעיין באפליקציה לדוגמה של Memorystore.

בדיקת העדכונים

כדי להגדיר מסד נתונים לבדיקה ולהריץ את האפליקציה באופן מקומי לפני הפריסה ב-App Engine:

  1. מריצים את האמולטור המקומי של מצב Datastore כדי לאחסן ולאחזר נתונים.

    חשוב לפעול לפי ההוראות להגדרת משתני סביבה כדי שהאפליקציה תתחבר לאמולטור במקום לסביבת הייצור של מצב Datastore.

    אפשר גם לייבא נתונים לאמולטור אם רוצים להתחיל את הבדיקה עם נתונים שכבר נטענו מראש במסד הנתונים.

  2. משתמשים בשרת הפיתוח המקומי כדי להריץ את האפליקציה.

    כדי לוודא שמשתנה הסביבה GOOGLE_CLOUD_PROJECT מוגדר בצורה נכונה במהלך פיתוח מקומי, מפעילים את dev_appserver באמצעות הפרמטר הבא: 

    --application=PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud . אפשר להריץ את הפקודה gcloud config list project כדי למצוא את מזהה הפרויקט, או לעיין בדף הפרויקט במסוף Google Cloud .

פריסת האפליקציה

אחרי שהאפליקציה פועלת בשרת הפיתוח המקומי ללא שגיאות:

  1. בדיקת האפליקציה ב-App Engine.

  2. אם האפליקציה פועלת ללא שגיאות, משתמשים בפיצול תנועה כדי להגדיל בהדרגה את התנועה לאפליקציה המעודכנת. חשוב לעקוב אחרי האפליקציה כדי לזהות בעיות במסד הנתונים לפני שמפנים אליה תנועה נוספת.

המאמרים הבאים