יצירת סאבגרף The Graph: תכנון, פריסה ואופטימיזציה

מדוע פיתוח subgraph מאט עם גידול הנתונים

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

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

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

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

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

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

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

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

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

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

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

גישות לפיתוח subgraph: השוואת אפשרויות

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

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

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

כיצד אנו מובילים את ההטמעה: שלבי העבודה ההנדסית

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

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

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

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

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

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

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

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

מסמכי המסירה: סכימות, תקנונים, תיעוד

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

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

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

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

בנקודת הפתיחה — subgraph עובד ב-The Graph: חוזה ראשי ומפעל (factory) כמקורות אירועים. השאילתות הוגשו, אך לוחות האנליטיקה פיגרו אחרי הרשת ב-6 עד 9 שעות, וכל ארגון מחדש של השרשרת הפעיל אינדוקס מחדש מלא.

היכן היה צוואר הבקבוק

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

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

מה שינינו ומה קבענו במדידות

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

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

מה עושים אם כבר פרסתם כלי איסוף נתונים משלכם?

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

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

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

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

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

טריות הנתונים, גישות ומגבלות: ספקות נפוצים

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

כיצד מופרדת הגישה לנתונים?

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

מה יקרה עם גידול במספר השאילתות?

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

כיצד מעדכנים את הסכימה בלי השבתה?

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

נדון במשימה: מה נדייק וכיצד נחזור עם תוכנית

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

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

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