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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם יש כשל במהלך שלב האישור, המערכת מנסה שוב באופן אוטומטי, אבל אם הכשלים נמשכים, האפליקציה מקבלת חריגה. אם שלב ה-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. מומלץ להוסיף אותו לפני כל מחלקות התוכנה האחרות, כי יכול להיות שתוכנות אחרות יבצעו קריאות למאגר הנתונים, והקריאות האלה לא יטופלו בצורה תקינה אם התוכנה הזו תופעל לפני התוכנה הזו. מידע נוסף על תוכנת ביניים של Django

המאמר הבא

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