מדוע האינדקסר של TON לא עומד בקצב גידול העומס
האינדקסר של TON מתחיל לפגר לא בשיא, אלא קודם לכן — כשזרימת האירועים מהרשת מהירה באופן עקבי מהכתיבה המאושרת לאחסון. בתחילה הפער נמדד ביחידות של בלוקים ואינו נראה בתשובות ה-API, ואחר כך הוא גדל בצורה מפולתית: התור נעשה ארוך מהחלון שהווקרים מספיקים לעבור במעבר אחד. ישנן ארבע סיבות אופייניות, וכולן קשורות למבנה מחזור העיבוד, ולא לעוצמת החומרה.
עיבוד חוזר של בלוקים: לאחר ארגון מחדש של ענף, הווקר לעתים קרובות משחזר את כל הטווח, ולא רק את התנועות שנפגעו. כל בלוק שהוחמץ בתור גובה עבודה כפולה, ובהמשך יש להשוות בנפרד את מצבי הביניים באחסון.
התחרות על הצמתים מוסיפה משלה: כשמספר נקודות הגישה מוגבל, חלק מהבקשות נופלות בגלל מכסות, וווקרים שונים קוראים את המצב בנקודות זמן שונות, ובכך עולה ב-API אי-התאמה של יתרות.
סיפור נפרד הוא סכימת המפתחות. מפתח מהסוג «כתובת פלוס תאריך» מפזר את הרשומות על פני מחיצות חמות, הכתיבה באצוות אינה מתגבשת, הכותב נתקע בפעולות דיסק — והפיגור גדל כבר בפלט. מפתח לפי טווח השארד עם צבירת מנה נותן זרימה אחידה והשהיה צפויה בין האירוע ברשת להופעתו באחסון.
בלוקים שהוחמצו מסוכנים לא כשלעצמם, אלא בכך שההדבקה שלהם מתחרה בזרימה השוטפת על אותם צמתים ודיסק. לכן את הפיגור סופרים כמדד נפרד לכל שארד, ולא כממוצע של השירות, ולפיו מקבלים החלטות.
אנחנו מפרטים כיצד זה נסגר: היכן למקם את גבולות חלון העיבוד החוזר, כיצד להפריד בין קריאה לכתיבה בין הצמתים ואיזה פורמט מפתח שומר על כתיבה אחידה.
מה נותנת אינדוקסציה מנוהלת: אפקט מדיד
אינדקסר TON מנוהל שומר על פיגור מראש הרשת בטווח של בלוק מאושר אחד או שניים — במקום דקות של המתנה לאחר כל תנועה. ארגונים מחדש מטופלים באמצעות שחזור הטווח שנפגע של גבהים, ולא באמצעות אינדוקסציה מחדש מלאה של כל ההיסטוריה.
שלמות ההיסטוריה נשענת על יומן של בלוקי מאסטרצ'יין שעובדו: עבור כל גובה ניתן לשחזר את מצב החשבון, האירועים וההעברות שלו. הנכונות נבדקת על ידי השוואת סכומי ביקורת של המצב בגבהים אקראיים — אי-ההתאמות נראות לפני שהמשתמש מבחין בהן.
עמידות לעיבוד חוזר ניתנת על ידי כתיבה אידמפוטנטית: מפתח המורכב מגובה הבלוק ומההאש של התנועה אינו מאפשר שכפול נתונים. ווקר שקרס באמצע הטווח ממשיך מנקודת הביקורת האחרונה ואינו מאבד אף אירוע.
העומס על הצמתים פוחת באמצעות מינוי לבלוקים חדשים במקום סקירה מתמדת, בקשות באצוות ומטמון של חשבונות חמים — מספר הפניות לצומת קטן בסדר גודל. המשאב שהתפנה מופנה לשאילתות עמוקות להיסטוריה: שליפה לפי כתובת או לפי טוקן מגיבה בתוך שברירי שנייה אפילו על טווח גבהים ארוך.
מצבי אינדוקסציה: השוואת גישות ומגבלות
בחירת המצב קובעת לא רק את מהירות הופעת הנתונים ב-API, אלא גם כיצד האינדקסר TON שורד ארגונים מחדש והחמצות. בקלט שני פרמטרים: ההשהיה המותרת בין סיום הבלוק להופעתו בתשובה, ועומק האחסון — כמה היסטוריה יש להעלות לפי דרישה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אינדוקסציה זורמת | חלונות ראווה, ארנקים, יתרות וסטטוסים של תנועות: התשובה נדרשת כמעט מיד לאחר סיום הבלוק | נדרש חוצץ לארגון מחדש וכתיבה אידמפוטנטית לפי מפתח הבלוק; כשל של המפענח עוצר את כל הזרימה, ואי אפשר לחשב מחדש את ההיסטוריה בדיעבד |
| חישובים מחדש באצוות | אנליטיקה, השוואת יתרות, הגירת סכימת אחסון, שחזור לאחר תקלה | הנתונים מופיעים בהשהיה של עשרות דקות; מעבר חוזר על ארכיון הצומת יקר מבחינת עומס על הדיסק ועל האחסון |
| סכימה היברידית | API ציבורי של האינדקסר TON, שבו חשובים גם נתונים טריים וגם שליפה עמוקה | מורכב יותר לתפעול: שני מעגלים, נקודות ביקורת נפרדות ותיאום הגבול בין השכבה החמה לשכבה הקרה |
עומק האחסון הוא ציר נפרד ואין לבלבל בינו לבין המצב. בלוקים טריים נשמרים באחסון מהיר, וההיסטוריה — באחסון דחוס, עם מדיניות מחיקה מוגדרת מראש: כמה בלוקים אחרונים אנחנו מבטיחים לצורך חזרה לאחור, מה עובר לארכיון, ומה מחושב ממנו מחדש לפי דרישה.
היבריד הוא בדרך כלל האפשרות המעשית: הזרימה נותנת השהיה נמוכה, ומעבר באצוות סוגר חורים וממלא פריסות היסטוריות.
בפועל המצב נבחר בהתאם לפרופיל השאילתות, ולא להיפך: תחילה בוחנים אילו שליפות שולטות, ואחר כך קובעים את ההשהיה ואת העומק.
שלבי ההטמעה של האינדקסר TON
סדר העבודה זהה גם עבור אינדקסר TON חדש וגם עבור החלפת סקריפט עצמאי שהפסיק לעמוד בקצב זרימת הבלוקים. תחילה קובעים אילו שאילתות נתונים נדרשות למוצר, ורק לאחר מכן בוחרים את סכימת האחסון: אם מתחילים מהקוד, נאלצים לכתוב מחדש באמצע. להלן הרצף עם נקודות קבלה בכל שלב.
- ביקורת סכימת הנתונים. מפרקים טבלאות, קשרים ושאילתות כבדות, מסמנים חוסר באינדקסים מורכבים וכפילויות. בפלט — מפת מקורות ותוכנית העברה.
- תכנון מודל האחסון. מחליטים מה נשמר בצורה מנורמלת ומה — בהקרנות דה-נורמליזציה עבור שליפות תכופות: היסטוריית כתובת, יתרות, אירועי חוזים.
- הגדרת התורים. את זרימת הבלוקים מחלקים לקליטה, פענוח וכתיבה; התור מנטרל שיאים, ולאחר תקלה העיבוד ממשיך מהמיקום המאושר האחרון.
- בדיקת עקביות. משווים את האינדקס לנתוני הרשת לפי יתרות, מספר תנועות ועיבוד חוזר; מביאים את אי-ההתאמות לאפס על טווח בדיקה.
- הרצת עומס והחלפה. בוחנים את פיגור האינדקסר על נתונים היסטוריים ובזמן אמת, מעבירים את התעבורה בשלבים, עם אפשרות חזרה למעגל הקודם.
- מסירת נהלים. מוסרים תיאור של הסכימה והשאילתות, הוראות להפעלה מחדש ולשחזור, מדדים עם ספים. מכאן והלאה התפעול מתבצע בכוחות הצוות שלכם.
מארז האספקה: סכימות, נהלים, כלים
לאחר ההרצה נשאר לצוות הלקוח לא רק שירות פעיל, אלא גם מארז מסמכים שלפיהם אפשר לתפעל ולפתח אותו בלעדינו. אנחנו מוסרים תיאור של סכימת הנתונים, נהלים וכלי ניטור — כך שהמהנדס התורן יבין את סיבת התקלה, ומפתח חדש יוסיף מתודת API בלי לפענח קוד של אחרים.
- סכימת הנתונים — אילו טבלאות מאחסנות בלוקים, תנועות ואירועים, לפי איזה מפתח מתבצעת החלוקה למחיצות, ואילו אינדקסים מכסים שאילתות תכופות לפי כתובת וטווח זמן.
- מפרט ה-API של האינדקסר TON — רשימת המתודות, פורמטי התשובות, פגינציה מבוססת סמן, מכסות וקודי שגיאה: לפיו כותבים את האינטגרציה בלי שאלות הבהרה.
- הרשאות ותפקידים — גישת שירות לקריאה בלבד, מפתחות נפרדים לאנליטיקה, פעולות ניהול, סדר רוטציה והפרדה של סביבת הבדיקות מהמעגל הייצורי.
- נוהל הפעלה מחדש — באיזה סדר עולים הרכיבים, כיצד השירות מדביק בלוקים שהוחמצו ומאיזו נקודה הוא מחדש את העיבוד, כדי שאירועים לא יוכפלו.
- ניטור התורים — מדדי עומק התורים, הפיגור של האינדקס מהשרשרת ושיעור ההודעות שנזרקו, ספי התראות והצעדים הראשונים של התורן בעת התרעה.
- תמונות מצב ושחזור — כיצד נלקחת תמונת מצב של האחסון, היכן היא נשמרת וכמה זמן נדרש לחזור למצב פעיל.
- ניתוח תקלות אופייניות — חוסר סנכרון, כפילויות אירועים, צומת מפגר: לפי אילו סימנים מזהים אותן ומה עושים צעד אחר צעד.
- העברת ידע — הקלטה של סקירת הארכיטקטורה ותשובות לשאלות הצוות, כדי שהתפעול לא יהיה תלוי באדם אחד.
מקרה בוחן: כיצד גדלה שלמות הנתונים לאחר הפעלה מחדש
מה היה לפני ההפעלה מחדש
את האינדקסר בנו להרצה מהירה: הבלוקים נקראו בזרימה אחת, והכול נכתב לטבלה אחת בלי חלוקה לפי שארדים. בשיא הפיגור מהרשת הגיע לכמה שעות, ובמקרה של חוסר סנכרון התהליך דילג בשקט על טווח בלוקים — את החורים גילו רק מתלונות של שירותים שנבנו על הנתונים האלה.
שלמות ההיסטוריה עמדה על כ-88%: חלק מההעברות הפנימיות ואירועי החוזים לא נכנסו לאינדקס. ב-TON זה קריטי — טווח שהוחמץ קורע את שרשרת המצבים של כתובות תלויות, וכבר אי אפשר להבדיל בין היתרה האמיתית לבין שגיאה מצטברת.
מה שינו ומה התוצאה
את הטעינה כתבו מחדש לעיבוד מקבילי של שארדים עם נקודות ביקורת, ואת האינדוקסציה מחדש הפכו למנוהלת: העומק נקבע כפרמטר — מהשעות האחרונות ועד כל היסטוריית הרשת. השחזור לאחר תקלה הוא כעת אוטומטי, מהנקודה המאושרת האחרונה, בלי ניתוח ידני.
- פיגור מהרשת בשיא — דקות במקום שעות.
- שלמות ההיסטוריה — 100% לפי טווחים שנבדקו, סכומי הביקורת מתכנסים בכל שארד.
- שחזור לאחר תקלה — כ-20 דקות של השלמה אוטומטית במקום שעות של עבודה ידנית.
- עומק האינדוקסציה מחדש — כל ההיסטוריה, ולא חלון של היממה האחרונה.
ההשוואה לא נעשתה בעין: הריצו את האינדקס מול צומת מלא על כמה טווחים, ואין אי-התאמות. לאחר ההפעלה מחדש הצוותים הפסיקו להחזיק ייצוא נתונים משלהם — הנתונים מהאינדקס תואמים לרשת ומוחזרים מיד.
מה לעשות אם האינדקסר כבר פרוס ומפגר
אינדקסר TON בתפעול מפגר משתי סיבות: סכימת החשבונאות השתנתה — נוספו העברות פנימיות, הרכב השדות השתנה — או שהנפחים גדלו, ומחזור עיבוד הבלוק הפסיק להיכנס למרווח. אי אפשר לעצור את השירות: היתרות והיסטוריית הפעולות נדרשות כל העת, והרצה מאפס אורכת שעות.
הטכניקה המעשית — הגירה הדרגתית באמצעות כתיבה כפולה. המעבד כותב גם לסכימה הישנה וגם לחדשה באותה טרנזקציה, ולכן המצבים אינם מתפצלים. שכבת הקריאה עוברת הסבה לא כולה בבת אחת, אלא לפי קבוצות שאילתות: החזרה לאחור מסתכמת בהסרת דגל, ולא בשחזור מגיבוי.
את ההיסטוריה מעבירים ברקע. קובעים את גובה הבלוק שממנו החלה הכתיבה הכפולה — זו נקודת הפיצול. את כל מה שהיה קודם מזרימים במנות לסכימה החדשה באמצעות מעבדים מקבילים עם הגבלת עומס על הצומת, כדי שהזרימה החיה לא תפגר יותר. מדביקים עד לאפס אי-התאמות.
החלפת הסכימה בטוחה יותר מכפי שנדמה: הטבלה החדשה מתקיימת לצד הישנה, ואין קונפליקטים של נעילות. ההשוואה הכרחית — מדגם ביקורת של כתובות ופעולות מורץ דרך שתי הסכימות, התשובות מושוות אוטומטית, ורק לאחר התאמה עוברת הקריאה לחדשה.
אם הפיגור כבר הצטבר, מסירים אותו באמצעות בנייה מחדש של השכבה החמה מתוך ארכיון הבלוקים, בלי לגעת בנתונים המצטברים. לא כדאי להתחיל מאפס: היסטוריית היתרות והעסקאות הולכת לאיבוד, והשחזור אורך יממה. את השכבה הישנה משאירים קריאה, עד שהחדשה תוכיח התאמה בהשוואה.
ספקות טכניים לפני תחילת העבודה
אינדקסר הוא מצב שחייב להתאים לשרשרת בכל תקלה: בלוק שהוחמץ, ניתוק חיבור, ארגון מחדש של הבלוקים האחרונים. להלן תשובות לשאלות הנדסיות שעולות לרוב בשלב ההערכה: שלמות, עיבוד חוזר, הרשאות וגבולות האחריות לאחר המסירה.
כיצד מאושרת שלמות הנתונים עבור כל בלוק?
כל בלוק שעובד נרשם יחד עם ההאש שלו, מספרו, ההאש של ההורה וחותמת הזמן של הכתיבה. ההשוואה מתבצעת מהסימן המאושר האחרון: אם ההאש של ההורה אינו תואם לזה שכבר נשמר, אצוות הבלוקים מוחזרת לנקודה המשותפת ומעובדת מחדש. בדיקת הסיכום — סכום ביקורת של המצב על פני חלון בלוקים, והוא נבדק בנפרד ממחזור הפענוח הראשי.
מה יקרה אם האינדקסר נעצר לכמה שעות?
הפענוח מתבצע לפי סמן, ולא לפי זמן, ולכן לאחר ההפעלה העיבוד ממשיך מהסימן המאושר האחרון. פעולת הכתיבה אידמפוטנטית: עיבוד חוזר של אותו בלוק אינו יוצר כפילויות באחסון. את הפיגור מדביקים במנות עד ליציאה לגובה העדכני, ואחר כך נכנס המצב הרגיל לפעולה.
כיצד בנויות הרשאות הגישה למעגל הפרוס?
ההרשאות ניתנות לפי תפקידים: קריאה דרך ממשק הנתונים, ופעולות שירות של פענוח והגירות — בנפרד. המפתחות ופרטי הזיהוי נמסרים לאחראי מטעמכם, ולא נותרת אצלנו גישה קבועה. שלילת הגישה מצדנו מתועדת בכתב ומאושרת בניסיון התחברות משני הצדדים.
כיצד מתחלקת האחריות לאחר המסירה?
אנחנו מוסרים קונפיגורציות פענוח, סכימת אחסון, מדיניות עיבוד חוזר, הוראות שחזור וסדר פעולות בעת אי-התאמה בין מצבים. המהנדסים שלכם משחזרים את המעגל לפי החומרים האלה בלי עזרתנו.
ליווי האחריות מכסה שגיאות בלוגיקת הפענוח — הן משוחזרות ומטופלות; שינויים בתשתית שלכם וכללי הגישה לצמתים נשארים באחריותכם.
נדון במשימה שלכם ונחזור עם תוכנית
כדי שהערכת הפרויקט תישען על עובדות ולא על הנחות, חשוב לנו מלכתחילה להבין את הגבולות: האם נדרשת היסטוריה מהבלוקים הראשונים או שמספיק חלון של התקופות האחרונות, אילו ישויות חייבות להופיע בתשובה, ואיזו השהיה בין הופעת הבלוק ברשת לבין הופעתו ב-API אתם מחשיבים כמותרת.
שני פרמטרים נוספים — מהיכן מגיעה זרימת הנתונים (צמתים משלכם או מקורות חיצוניים) ואיזה מרווח עומס להקצות כדי שהאינדקסר לא יפגר מראש השרשרת בעת גיאות שיא.
על פי תוצאות השיחה תקבלו:
- סכימת פענוח: מעבר על השארדים, סדר עיבוד המאסטרצ'יין והשרשראות העובדות, ההתנהגות בזמן ארגון מחדש והוצאה חוזרת של בלוקים;
- מודל אחסון עם תיאור של אינדקסים עבור שאילתות ספציפיות — כדי ששליפות לפי כתובת, תנועה והיסטוריה ישמרו על המהירות הנדרשת בנפחים שלכם;
- חוזה API עם דוגמאות תשובות ושדות, כולל פגינציה, מסננים וסימני סופיות;
- תוכנית עבודה לפי שלבים עם נקודות קבלה בכל אחד: זרימה גולמית, אכלוס האחסון, API משלכם, בדיקות עומס;
- הרכב הצוות עם תפקידים — מי אחראי על הפענוח, מי על שכבת השאילתות, מי על הליווי;
- תוכנית מסירה לתפעול: לוחות בקרה לפיגור מראש השרשרת, נוהל אינדוקסציה מחדש לאחר תקלות, סדר עדכון בעת שינוי פורמט הבלוקים;
- רשימת סיכונים והנחות המשפיעים על לוחות הזמנים וההיקף.
תארו את המשימה בצורה חופשית — נפחים, מקורות, דרישות לתשובות. נחזור עם הערכה, תוכנית עבודה ותפקידים בצוות.