תורים ב-Spanner מספקים העברת הודעות טרנזקציונליות כדי לעזור לכם לנהל עבודה אסינכרונית. התכונה הזו משלבת את היכולת הזו עם יכולת ההתאמה לעומס (scaling) והאמינות של Spanner, ומאפשרת לכם ליצור אפליקציות מבוססות-אירועים. התורים של Spanner משתמשים במודל משיכה לצריכת הודעות, וחושפים ממשק SQL למקלטים כדי לבקש ולקבל הודעות.
בחירה בין תורים לבין סנכרון שינויים בזרמי נתונים ב-Spanner
ההשוואה הבאה מספקת הנחיות לבחירת המנגנון המתאים להפצת נתונים ולעיבוד אסינכרוני.
תורים ב-Spannerלמי זה מתאים
מאפיינים מרכזיים
|
סנכרון שינויים בזרמי נתונים ב-Spannerלמי זה מתאים
מאפיינים מרכזיים
|
יתרונות עיקריים
לתורים ב-Spanner יש כמה יתרונות:
- משולב: ההודעות משולבות במסד הנתונים. כך לא צריך להקצות, לנהל ולייצא נתונים לתשתית נפרדת של העברת הודעות, מה שמפשט את ארכיטקטורת האפליקציה ומפחית את העלויות הכוללות.
- טרנזקציות: אתם יכולים לשלוח הודעות ולאשר אותן באופן אטומי בטרנזקציה של Spanner, לצד כתיבות אחרות במסד הנתונים. אם הטרנזקציה נכשלת, ההודעות שהתווספו לתור מוחזרות למצב הקודם ולא זמינות למסירה.
- עמידות: הודעות שלא ניתן לשלוח נשמרות במסד הנתונים. Spanner מנסה כל הזמן לשלוח את ההודעה עם השהיה, עד שהיא מאושרת או נמחקת באופן מפורש.
- ניתן לשלוח שאילתות: ההודעות מבוססות על אותם פרימיטיבים כמו טבלאות Spanner ומאוחסנות כשורות. אפשר לשלוח אליהן שאילתות, לצרף אותן או לסנן אותן כמו טבלאות רגילות.
- ניתן להתאמה לעומס: עיבוד ההודעות נבנה עם אותה יכולת התאמה לעומס כמו טבלאות Spanner, והוא משתנה בהתאם לשאר מסד הנתונים.
- אמינות: התורים של Spanner מקבלים בירושה את כל הפרימיטיבים של הזמינות הגבוהה של Spanner, כך ששליחת ההודעות והעיבוד שלהן עמידים בפני תקלות באזורים או במחוזות.
- ניתן לתזמון: אפשר לתזמן הודעות לשליחה בעתיד, וכך לדחות את ביצוע המשימה לחותמת זמן ספציפית בעתיד.
- אטומיות: שליחת הודעות (
INSERTאו ממשקי API של מוטציות) ואישור (DELETEאו ממשקי API של מוטציות) מתבצעים באופן אטומי בתוך טרנזקציות, כדי להבטיח עקביות עם מצב מסד הנתונים. - ניתן להרחבה: אפשר להאריך את משך ההשכרה של הודעות כדי לתמוך בזמני עיבוד ארוכים במיוחד, על ידי שילוב של מנגנוני מסירה עתידית והשכרה ידנית.
תרחישים לדוגמה
תורים ב-Spanner שימושיים לתזמור משימות מושהות בתוך טרנזקציה. דוגמאות נפוצות:
- דחיית עבודה שדורשת משאבי מחשוב רבים: יכול להיות שאתר לשיתוף תמונות יצטרך לבצע עיבוד תמונה אינטנסיבי כשמעלים תמונה חדשה. הטרנזקציה שכותבת את המטא-נתונים של התמונה החדשה יכולה לכתוב בו-זמנית הודעה בתור. מקבל תור אוסף את ההודעה מאוחר יותר, מבצע את העיבוד ומעדכן את המטא-נתונים באופן טרנזקציונלי.
- דחיית עדכונים טרנזקציונליים גדולים: באפליקציית יומן, הזמנת קבוצה גדולה לפגישה בטרנזקציה אחת יכולה לגרום להתנגשויות נעילה ולזמני אחזור ארוכים. במקום זאת, הטרנזקציה שיוצרת את הפריט ביומן יכולה להוסיף פריט לתור לכל מוזמן, וכך לאפשר למקבל לשלוח את ההזמנות בנפרד.
- תזמון משימות לעתיד: חברת תוכנה כשירות (SaaS) שמציעה תקופת ניסיון בחינם למשך 30 יום יכולה להקצות את המשאבים של המשתמש, ובמקביל להוסיף לתור הודעה שמתוזמנת להישלח בעוד 30 יום. לאחר מכן, ה-worker מקבל את ההודעה ומפעיל את הלוגיקה של תפוגת תקופת הניסיון.
- דחיית עבודה למערכות חיצוניות: אחרי שמשתמש נרשם, יכול להיות שהאפליקציה תצטרך לשלוח אימייל פתיחה רק אם הרישום למסד הנתונים הצליח. טרנזקציית הרישום יכולה להוסיף רשומה לתור, וכך לאפשר ל-worker להפעיל API חיצוני של אימייל בשלב מאוחר יותר.
- תזמור צינורות עיבוד נתונים בכמה שלבים: במערכת לניהול הזמנות, מילוי הזמנה כולל כמה שלבים שיכולים להיכשל בנפרד. כשכל שלב מיוצג כהודעה בתור, המערכת יכולה ליצור נקודת ביקורת של מצב צינור עיבוד הנתונים ולהמשיך מנקודת הכשל.
תהליך עבודה
תהליך עבודה אופייני לתורים ב-Spanner כולל את השלבים הבאים:
- יצירת תור: מגדירים תור באמצעות DDL, בדומה לטבלה. הוא חייב לכלול עמודת
Payload(payloadב-PostgreSQL) ומפתח ראשי. - שליחת הודעות: הוספת הודעות לתור באמצעות DML רגיל (
INSERT) או ממשקי API של מוטציות, באופן טרנזקציונלי עם פעולות אחרות במסד הנתונים. - קבלת הודעות: משתמשים ב-API של
ExecuteStreamingSQLכדי לקרוא לפונקציה עם ערך טבלה (TVF) בשםRECEIVE_QUEUE_NAME(). הפונקציה הזו מעבירה הודעות ללקוח כשאילתה שפועלת לאורך זמן. - עיבוד הודעות: צריכת ההודעות שהתקבלו מה-TVF באמצעות לוגיקת האפליקציה.
- אישור הודעות: הסרת הודעות מהתור באמצעות DML (
DELETE) או ממשקי API למוטציות (כמוack). בדרך כלל הפעולה הזו מתבצעת אחרי שהעיבוד הושלם, בתוך טרנזקציה. - ניהול חכירות: ניהול חכירות של הודעות כדי לוודא שהתורים של Spanner לא מעבירים מחדש הודעות כשנגמר הזמן הקצוב לתפוגה של החכירה.
השיטה הנפוצה ביותר היא להשתמש ב-TVF של
RENEWLEASE_QUEUE_NAME().
בנוסף, חשוב לזכור את ההתנהגויות העיקריות הבאות של תורים ב-Spanner:
- מסירה לפחות פעם אחת: בדומה לרוב מערכות התורים מבוססות-הענן, Spanner מבטיח מסירה לפחות פעם אחת. כדי לצמצם את מספר ההעברות החוזרות, אפשר להאריך את משך ההשכרה.
- אישור פעם אחת לכל היותר: מכיוון שאישור ההודעה מתבצע באמצעות טרנזקציה, סמנטיקת ACID של Spanner מבטיחה שההודעה תאושר פעם אחת בלבד. כדי להטמיע בצורה נכונה אישור לכל היותר פעם אחת, צריך לפעול לפי השיטות שמופיעות בדף עיבוד בדיוק פעם אחת ואישור לכל היותר פעם אחת.
מגבלות
לתורים ב-Spanner יש את המגבלות הבאות:
- מקסימום מקבלים: יש מגבלה של 1,000 שאילתות קבלה פעילות עם אותם ארגומנטים לכל תור
- מגבלת המכסה של פונקציות TVF לקבלה בו-זמנית: יש מגבלת מכסה של 2,000 פונקציות TVF לקבלה בו-זמנית לכל פרויקט בכל אזור. כדי להגדיל את המכסה, ממלאים את הטופס בקשה להגדלת המכסה בפרויקט Cloud Spanner.
- פיצול ידני: ה-API של
AddSplitsלא נתמך בתורים. חלוקת עומסי העבודה מתבצעת רק על סמך חלוקה לפי עומס. מומלץ להוסיף את התור לטבלה, כדי שהמשתמשים יוכלו להוסיף נקודות פיצול לטבלה. - תאימות לחלוקה למחיצות במיקומים שונים: תורים שמחולקים למחיצות במיקומים שונים לא תואמים למיקום אחסון הנתונים אחרי ביצוע פעולת
DROP PARTITION. - מגבלות על מספר התורים: המכסות של מכונות עם צומת אחד או יותר מוגבלות ל-100 תורים. המגבלה מצטמצמת באופן יחסי למכונות פרטניות (לדוגמה, מכונות עם 200 יחידות עיבוד מוגבלות ל-20 תורים).
- מתן שמות לעמודות ב-PostgreSQL: ב-Spanner מוצגות העמודות
deliver_timeו-DeliverTimeלזמן המסירה של ההודעה. מומלץ להשתמש בעמודהdeliver_timeכדי להתאים למוסכמות השמות הרגילות של PostgreSQL, וגם כי העמודהDeliverTimeתוסתר מסכימת המידע בגרסה עתידית. - סכימה עם שם: אי אפשר ליצור תורים בסכימות עם שם.