סקירה כללית על תורים ב-Spanner

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

בחירה בין תורי Spanner לבין סנכרון שינויים בזרמי נתונים

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

תורים של Spanner

מתאים במיוחד ל

  • התראות על אירועים טרנזקציונליים
  • ביצוע עבודה שתוזמנה לעתיד
  • לוגיקה של אישור לכל הודעה

מאפיינים מרכזיים

  • מטענים קטנים של הודעות שהוגדרו על ידי המשתמש
  • מודל משיכה לצריכת הודעות
  • התאמה לעומס (scaling) עם מחשוב של מכונות Spanner

סנכרון שינויים בזרמי נתונים ב-Spanner

מתאים במיוחד ל

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

מאפיינים מרכזיים

  • מערכת שתתעד את כל חלקי הרשומה (עד 10MB)
  • סטרימינג מבוסס-משיכה באמצעות אסימוני מחיצות
  • כולל פעימות לב וסימון נקודות ביקורת

יתרונות מרכזיים

לתורים של Spanner יש כמה יתרונות:

  • משולב: ההודעות משולבות במסד הנתונים. כך לא צריך להקצות, לנהל ולייצא נתונים לתשתית נפרדת של העברת הודעות, מה שמפשט את ארכיטקטורת האפליקציה ומפחית את העלויות הכוללות.
  • טרנזקציוני: אתם יכולים לשלוח ולאשר הודעות באופן אטומי בתוך טרנזקציה של Spanner, לצד פעולות כתיבה אחרות במסד הנתונים. אם העסקה נכשלת, ההודעות שנוספו לתור מוחזרות ולא זמינות למסירה.
  • עמידות: הודעות שלא ניתן למסור מאוחסנות במסד הנתונים. מערכת Spanner מנסה לשלוח את ההודעה שוב ושוב עם השהיה לפני ניסיון חוזר (backoff) עד שההודעה מאושרת או נמחקת באופן מפורש.
  • אפשר להריץ עליהן שאילתות: ההודעות מבוססות על אותם פרימיטיבים כמו טבלאות Spanner ומאוחסנות כשורות. אתם יכולים להריץ שאילתות, להצטרף או לסנן אותם כמו טבלאות רגילות.
  • ניתן להרחבה: המערכת בנויה עם אותה יכולת הרחבה כמו טבלאות Spanner, ועיבוד ההודעות מתרחב יחד עם שאר מסד הנתונים.
  • אמינות: תורים ב-Spanner מקבלים בירושה את כל הפרימיטיבים של זמינות גבוהה ב-Spanner, ולכן שליחת ההודעות והעיבוד שלהן עמידים בכשלים ועמידים בפני כשלים אזוריים או אזוריים.
  • אפשר לתזמן: אפשר לתזמן את מסירת ההודעות לעתיד, וכך לדחות את ביצוע המשימה לסימן זמן ספציפי בעתיד.
  • אטומיות: שליחת הודעות (ממשקי API של INSERT או של מוטציות) ואישור (ממשקי API של DELETE או של מוטציות) מתבצעים באופן אטומי בתוך טרנזקציות, וכך מובטחת עקביות עם מצב מסד הנתונים.
  • ניתן להרחבה: אפשר להאריך את תקופת ההשכרה של ההודעות כדי לתמוך בזמני עיבוד ארוכים במיוחד, על ידי שילוב של מנגנוני מסירה עתידיים והשכרה ידנית.

תרחישים לדוגמה

תורי Spanner שימושיים לניהול משימות מושהות בתוך טרנזקציה. דוגמאות נפוצות:

  • דחיית עבודות שדורשות הרבה משאבי מחשוב: אתר לשיתוף תמונות עשוי לבצע עיבוד תמונה אינטנסיבי כשמעלים תמונה חדשה. העסקה שכותבת את המטא-נתונים של התמונה החדשה יכולה לכתוב בו-זמנית הודעה בתור. בהמשך, מקלט תור אוסף את ההודעה, מבצע את העיבוד ומעדכן את המטא-נתונים באופן טרנזקציונלי.
  • דחיית עדכונים גדולים של עסקאות: באפליקציית יומן, הזמנת קבוצה גדולה לפגישה בעסקה אחת עלולה לגרום להתנגשויות נעילה ולזמני אחזור ארוכים. במקום זאת, הטרנזקציה שיוצרת את פריט היומן יכולה להוסיף רשומה בתור לכל מוזמן, וכך הנמען יכול לשלוח את ההזמנות בנפרד.
  • תזמון משימות לעתיד: חברת תוכנה כשירות (SaaS) שמציעה תקופת ניסיון חינם למשך 30 יום יכולה להקצות את המשאבים של המשתמש ולתזמן הודעה שתועבר אליו בעוד 30 יום. לאחר מכן, עובד מקבל את ההודעה ומבצע את הלוגיקה של סיום תקופת הניסיון.
  • דחיית עבודה למערכות חיצוניות: אחרי שמשתמש נרשם, יכול להיות שאפליקציה תצטרך לשלוח אימייל ברוכים הבאים רק אם ההרשמה למסד הנתונים תצליח. במהלך עסקת ההרשמה אפשר להוסיף רשומה לתור, וכך לאפשר לעובד להפעיל API חיצוני של אימייל בשלב מאוחר יותר.
  • תיאום של צינורות מרובי-שלבים: במערכת לניהול הזמנות, ביצוע הזמנה כולל כמה שלבים שיכולים להיכשל באופן עצמאי. הצגת כל שלב כהודעה בתור מאפשרת למערכת לבצע צ'קפוינט של מצב צינור הנתונים ולהמשיך מהנקודה שבה אירעה השגיאה.

תהליך עבודה

תהליך עבודה טיפוסי לתורים ב-Spanner כולל את השלבים הבאים:

  • יצירת תור: מגדירים תור באמצעות DDL, בדומה לטבלה. הוא צריך לכלול עמודה Payload (payload ב-PostgreSQL) ומפתח ראשי.
  • שליחת הודעות: הוספת הודעות לתור באמצעות DML רגיל (INSERT) או ממשקי API של שינוי, באופן טרנזקציונלי עם פעולות אחרות במסד הנתונים.
  • קבלת הודעות: משתמשים ב-ExecuteStreamingSQL API כדי לקרוא לפונקציה להחזרת ערכי טבלה (TVF) בשם RECEIVE_QUEUE_NAME(). הפונקציה הזו מעבירה הודעות ללקוח כשאילתה פועלת לטווח ארוך.
  • עיבוד הודעות: צריכת ההודעות שהתקבלו מ-TVF באמצעות הלוגיקה של האפליקציה.
  • אישור קבלה של הודעות: הסרת הודעות מהתור באמצעות DML ‏(DELETE) או ממשקי API של מוטציה (כמו ack). הפעולה הזו מתבצעת בדרך כלל אחרי שהעיבוד מסתיים, במסגרת טרנזקציה.
  • ניהול חכירות: ניהול חכירות של הודעות כדי להבטיח שתורים של Spanner לא ימסרו מחדש הודעות אם חלף הזמן הקצוב לחכירה. השיטה הכי נפוצה היא שימוש ב-RENEWLEASE_QUEUE_NAME() TVF.

בנוסף, חשוב לזכור את ההתנהגויות העיקריות הבאות של תורי Spanner:

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

מגבלות

יש מגבלות על תורים ב-Spanner:

  • מספר מקסימלי של נמענים: יש מגבלה של 1,000 שאילתות פעילות לקבלת הודעות עם אותם ארגומנטים לכל תור
  • מכסת TVF מקסימלית לקבלה בו-זמנית: קיימת מכסה של 2,000 TVF מקסימליים לקבלה בו-זמנית לכל פרויקט בכל אזור. כדי להגדיל את מכסת המגבלות, ממלאים את הטופס בקשה להגדלת המכסה של פרויקט Cloud Spanner.
  • פיצול ידני: אין תמיכה ב-API‏ AddSplits לתורים. חלוקת עומסי העבודה מתבססת באופן מלא על פיצול לפי עומס. מומלץ לשלב את התור בטבלה כדי שהמשתמשים יוכלו להוסיף נקודות פיצול לטבלה.
  • תאימות לחלוקה גיאוגרפית: תורים עם חלוקה גיאוגרפית לא עומדים בדרישות של שמירת נתונים במדינה מסוימת אחרי ביצוע פעולת DROP PARTITION.
  • מגבלות על מספר התורים: המכסות של המכונות הן 100 תורים למכונות עם צומת אחד או יותר. המגבלה מצטמצמת באופן יחסי במקרים של מכונות עם רמת פירוט גבוהה (לדוגמה, מכונות עם 200 יחידות עיבוד מוגבלות ל-20 תורים).
  • הסרה ויצירה מחדש של תור: אין תמיכה מלאה בהסרה וביצירה מחדש של תור באותו שם. יכול להיות שיעבור זמן עד שערך ה-RECEIVETVF של התור יתאפס, ורק אז אפשר יהיה לקבל הודעות עם אותו שם.
  • שמות העמודות ב-PostgreSQL: ב-Spanner מוצגות גם העמודות deliver_time וגם DeliverTime של זמן המסירה של הודעה. מומלץ להשתמש בעמודה deliver_time כדי להתאים למוסכמות מתן השמות הסטנדרטיות של PostgreSQL, וגם כי העמודה DeliverTime תוסתר מסכימת המידע בגרסה עתידית.
  • סכימה עם שם: אי אפשר ליצור תורים בסכימות עם שם.

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