סקירה כללית של ספריית הלקוח NDB של App Engine

ספריית הלקוח NDB של Google Datastore מאפשרת לאפליקציות Python ב-App Engine להתחבר ל-Datastore. ספריית הלקוח של NDB מבוססת על ספריית DB Datastore הישנה יותר, ומוסיפה את התכונות הבאות של מאגר הנתונים:

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

בדף הזה מובאים מבוא וסקירה כללית על ספריית הלקוח NDB של App Engine. מידע על מעבר ל-Cloud NDB, שתומך ב-Python 3, מופיע במאמר מעבר ל-Cloud NDB.

הגדרת ישויות, מפתחות ומאפיינים

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

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

הצגת הקשר בין ישות הבסיס לישויות הצאצא בקבוצת ישויות

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

בתרשים הבא של קשרים בין ישויות ובדוגמת הקוד מוצג איך לכל Guestbook יכולים להיות כמה Greetings, שלכל אחד מהם יש מאפיינים של content ושל date.

הצגת קשרי ישויות כפי שנוצרו על ידי דוגמת הקוד שצורפה

שימוש במודלים לאחסון נתונים

מודל הוא מחלקה שמתארת סוג של ישות, כולל הסוגים וההגדרות של המאפיינים שלה. היא דומה בערך לטבלה ב-SQL. אפשר ליצור ישות על ידי הפעלת בנאי המחלקה של המודל, ואז לאחסן אותה על ידי הפעלת השיטה put().

שאילתות ואינדקסים

אפליקציה יכולה לשלוח שאילתה כדי למצוא ישויות שתואמות למסננים מסוימים.

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

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

הוא מגדיר את האינדקסים המורכבים שלו בקובץ תצורה, index.yaml. שרת פיתוח להצגה באינטרנט (development web server) מוסיף באופן אוטומטי הצעות לקובץ הזה כשהוא נתקל בשאילתות שעדיין לא הוגדרו להן אינדקסים.

אפשר לשנות את ההגדרות של האינדקסים באופן ידני על ידי עריכת הקובץ לפני העלאת האפליקציה. אפשר לעדכן את האינדקסים בנפרד מהעלאת האפליקציה על ידי הרצת הפקודה gcloud app deploy index.yaml.

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

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

הסבר על פעולות כתיבה ב-NDB: ביצוע, ניקוי המטמון והחלה

‫NDB כותב נתונים בשלבים:

  • בשלב האישור, שירות Datastore הבסיסי מתעד את השינויים.
  • ‫NDB מבטל את התוקף של המטמון של הישות או הישויות שהושפעו. לכן, קריאות עתידיות יקראו ממאגר הנתונים הבסיסי (ויאחסנו במטמון) במקום לקרוא ערכים לא עדכניים מהמטמון.
  • לבסוף, יכול להיות שרק כמה שניות אחר כך, Datastore הבסיסי מחיל את השינוי. השינוי יהיה גלוי לשאילתות גלובליות, ובסופו של דבר לקריאות עקביות.

הפונקציה NDB שכותבת את הנתונים (לדוגמה, put()) מוחזרת אחרי ביטול התוקף של המטמון. השלב Apply מתרחש באופן אסינכרוני.

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

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

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

עסקאות ושמירת נתונים במטמון

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

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

שימוש ב-Django עם NDB

כדי להשתמש ב-NDB עם מסגרת האינטרנט Django, מוסיפים את google.appengine.ext.ndb.django_middleware.NdbDjangoMiddleware לרשומה MIDDLEWARE_CLASSES בקובץ settings.py של Django. מומלץ להוסיף אותו לפני כל מחלקות middleware אחרות, כי יכול להיות שחלק מה-middleware האחר יבצע קריאות למאגר הנתונים, והקריאות האלה לא יטופלו בצורה תקינה אם ה-middleware הזה יופעל לפני ה-middleware הזה. מידע נוסף על תוכנת ביניים של Django

המאמר הבא

למידע נוסף על: