How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. מהירות היא עניין של , פלטפורמת תצפית שהצוותים של המפתחים סומכים עליה כדי לזהות אירועים לפני שהם מתדרדרים לבעיות.Coralogix משתמשת בצינור אנליטי סטרימינג בזמן אמת, ומספקת יכולות מעקב, ויזואליזציה ומזהירות ללא צורך באינדקס. קוראולוגיה אחד ההבדלים העיקריים של Coralogix הוא מנוע שאילתות מפוזר עבור שאילתות מהירות על נתונים המפותחים מהארכיונים של הלקוח באחסון מרחוק. הוא תוכנן במקור כמנוע שאילתות ללא סטטוס מעל אחסון האובייקט הבסיסי, אך קריאת מטא-נתונים של Parquet במהלך ביצוע השאילתה הציגה תוקף לא מקובל.כדי להתגבר על זה, הם פיתחו אחסון מטא-נתונים (שנקרא פשוט "מטאסטור") כדי לאפשר חיפוש מהיר יותר ועיבוד של מטא-נתונים של Parquet הדרושים לביצוע שאילתות גדולות. חניה יישום המטאסטור המקורי, שנבנה על גבי PostgreSQL, לא היה מהיר מספיק עבור הצרכים שלהם. אז, הצוות ניסה יישום חדש – הפעם, עם ScyllaDB במקום PostgreSQL. ספוילר: זה עבד. הם השיגו רווחים מרשימים ביצועים – קיצוץ זמן עיבוד שאילתות מ -30 שניות ל -86 מילישניות. והנדסיהם דן האריס (הנדס תוכנה ראשי) וסבסטיאן ורקרוייס (הנדס תוכנה בכיר) לקחו את הבמה ב ScyllaDB Summit כדי להסביר איך הם עשו את זה. הצטרפו אלינו ב-ScyllaDB Summit 24 כדי לשמוע יותר דוחות ממקור ראשון של האופן שבו צוותים מתמודדים עם האתגרים הקשים ביותר שלהם.דיסני, Discord, Expedia, Supercell, Paramount ועוד כולם על סדר היום. ScyllaDB Summit 2024 הוא עכשיו חבילה! Update: מטאסטורה מוטיבציה ודרישות לפני שנכנס לפרטים של יישום המטאסטור, בואו נלך צעד אחורה ולראות את הסיבה לבניית מטאסטור במקום הראשון. "התחלנו לתכנן את הפלטפורמה הזו כמנוע שאילתות ללא סטטוס מעל אחסון האובייקט הבסיסי - אבל הבנו במהירות כי העלות של קריאת מטא-נתונים של Parquet במהלך ביצוע שאילתות היא אחוז גדול מהזמן שאילתות", הסביר דן האריס. הם הציגו פתרון שיכול: שמור את המטא-נתונים של Parquet בפורמט מפוזר לצורך גמישות ועוצמה גבוהה השתמש מסנני bloom לזיהוי יעיל של קבצים כדי לסרוק עבור כל שאלה שימוש בלוגים של עסקאות כדי להוסיף, לעדכן ולחליף נתונים קיימים באחסון האובייקט הבסיסי הדרישות העיקריות כוללות עיכוב נמוך, גמישות במונחים של יכולת קריאה / כתיבה, וגמישות של אחסון הבסיסי. יוצר 2,000 קבצים Parquet לשעה (50,000 ליום), בסך הכל 15 TB ליום, וכתוצאה מכך 20 GB של מטא-נתונים Parquet בלבד . לקוח יחיד רק ליום אחד לקוח יחיד רק ליום אחד יישום ראשוני של PostgreSQL "התחלנו את היישום הראשוני ב-Postgres, והבנו באותו זמן כי מנוע שאינו מופץ לא יהיה מספיק לטווח הארוך", אמר דן.ההיישום המקורי מאחסן מידע מפתח כגון "בלוקים", המייצג קבוצה אחת בשורה וקובץ פרקט אחד. Block url: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Row group: 0, 1, 2 … Min timestamp Max timestamp Number of rows Total size … כדי לאופטימיזציה של קריאה, הם השתמשו מסנני פרח עבור חיתוך נתונים יעיל. דן ציין: "בסופו של דבר, אנחנו רוצים לתמוך במשהו כמו חיפוש טקסט מלא. באופן בסיסי, כאשר אנו מעבירים קבצים אלה למערכת שלנו, אנו יכולים לבנות מסנני פרח עבור כל התוויות השונות שאנו מוצאים בקובץ. אז, בהתבסס על שאלת מסוימת, אנו יכולים להשתמש מסננים פרח כדי לחתוך את הנתונים שאנחנו צריכים לסרוק." בנוסף, הם שמרו את מטא-נתוני העמודה עבור כל קובץ Parquet, לדוגמה: Block URL Row Group Column Name Column metadata (blob) דן הסביר: "הקבצים שאנחנו כותבים הם די רחבים, לפעמים עד 20,000 עמודות, אז על ידי קריאת רק את המטא-נתונים שאנחנו צריכים, אנחנו יכולים באמת להפחית את כמות IO הנדרשת על כל שאלה נתונה." יישום ScyllaDB לאחר מכן, בואו נסתכל על יישום ScyllaDB כפי שתואר על ידי עמית צוותו של דן, סבסטיאן Vercruysse. Blocks מודל נתונים היישום החדש נדרש לבדוק מחדש את מודל הבלוק, הנה דוגמה של כתובת URL של בלוק: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet החלק האומץ הוא הקופסא ברמה העליונה של הלקוח; בתוך הקופסה, פריטים מחולקים לפי שעה. אבל כמה לקוחות יש הרבה יותר קבצים Parquet מאשר לקוחות אחרים, והם רצו לשמור על דברים מאוזנים ((Block url, row group))? זה מזהה באופן ייחודי בלוק מסוים, אבל זה יהיה קשה לרשום את כל הבלוקים עבור יום מסוים כי סימן הזמן אינו במפתח ((Table url, time))? זה עובד כי אם יש לך 24 שעות לשאול, אתה יכול לשאול די בקלות ((Table url, hour), block url, row group)?זה מה שהם בחרו.באמצעות הוספת את הבלוק url ו- row group כקובצי קבוצה, הם יכולים בקלות להשיג בלוק מסוים בתוך שעה, אשר גם מפשט את התהליך של עדכון או מחיקה של בלוקים וקבוצות שורות. Bloom Filter Chunking ו- Data Modeling האתגר הבא: כיצד לבדוק אם ביטים מסוימים מוגדרים, בהתחשב בכך ש-ScyllaDB לא מציעה פונקציות מחוץ לקופסה עבור זה. הקבוצה החליטה לקרוא את מסנני הפרח ולעבד אותם ביישום. עם זאת, זכור כי הם מתמודדים עם עד 50,000 בלוקים ליום לכל לקוח, כל בלוק מכיל 262 KB עבור חלק מסנני הפרח. זה בסך הכל 12 GB – יותר מדי כדי למשוך בחזרה ביישום עבור שאלה אחת. אבל הם לא היו צריכים לקרוא את המסנני הפרח כולו בכל פעם; הם זקוקים רק לחלקים ממנו, בהתאם לטוקינים המעורבים במהלך ביצוע השאלה. עבור מודל נתונים, אחת האפשרויות הייתה להשתמש כמו המפתח העיקרי. זה ייצר 8192 חתיכות של 32 בייטים לכל מסנן פרח, וכתוצאה מכך חלוקת שווה עם כ 262 KB לכל מקטע. עם כל מסנן פרח באותו מקטע, זה יהיה קל להכניס ולמחוק נתונים עם שאלת מקטע יחיד. אבל יש תפיסה שמשפיעה על יעילות קריאה: אתה צריך לדעת את ה-ID של הבלוק לפני שאתה יכול לקרוא את מסנן פרח. בנוסף, הגישה תכלול גישה למספר משמעותי של מקטעים; 50K בלוקים פירושו מקטעים 50K. וכפי שסבסטיאן ציין, "גם עם משהו מהיר כמו ScyllaDB, זה עדיין קשה להשיג תהליך תת-שני עבור מקטעים 50K." ((block_url, row_group), אינדקס צ'אק) אפשרות נוספת (האחת שבה הם בחרו בסופו של דבר): שים לב כי זהו אותו מפתח מחלקה כמו Blocks אחד, עם אינדקס נוסף למפתח מחלקה המייצג את nth טוקן הנדרש על ידי מנוע השאילתה. ((Table url, hour, chunk index), בלוק url, קבוצת שורות) יתר על כן, גישה זו כבר לא דורשת את מזהה הבלוק לפני קריאת מסנן הפרח - המאפשר קריאה מהירה יותר. כמובן, תמיד יש מחלוקות. כאן, בשל גישה מסנן הפרח חסום, הם צריכים לחלק מסנן הפרח יחיד ל 8192 מחלוקות ייחודיות. זה בסופו של דבר משפיע על מהירות האכילה לעומת הגישה הקודמת של מחלוקת המאפשרת לאכול את כל חתיכות מסנן הפרח בבת אחת. מודל נתונים פוגע לא מפתיע, המעבר מ- SQL ל- NoSQL כרוך בכמות הוגנת של עבודות מחדש של מודל נתונים, כולל כמה ניסיונות ושגיאות. לדוגמה, סבסטיאן שיתף, "יום אחד, גיליתי שסבלנו מ-min ו-max timestamps - ואני תוהה איך אני הולך לתקן את זה. חשבתי שאולי אני יכול לשנות את השמות של העמדות ולאחר מכן איכשהו לעשות את זה לעבוד שוב. אבל, כאן אתה לא יכול לשנות את השם של העמודה אם היא חלק מפתח קבוצה. בסופו של דבר, הם החליטו לחתוך את השולחן ולהתחיל מחדש נגד כתיבת קוד הגירה. רווחי ביצועים למרות עבודת המודל של הנתונים הנדרשת, ההעברה השתלמה היטב. כרגע כל כבל יכול להתמודד עם 4-5 TB. הם מעבדים כעת סביב 10K כותבים לשנייה עם P99 עיכוב עקבי מתחת למיליש שנייה. רשימת הבלוק יוצרת כ -2000 קבצי פרקט בשעה; עם מסנני הפרח שלהם, הם מעובדים בתוך פחות מ -20 מילישניות. עבור קבצים 50K, זה פחות מ 500 מילישניות. אבל, עבור קבצים 50K Parquet, 500 מילישניות הוא בסדר עבור הצרכים שלהם. בעבודת מטא-נתונים בעמודה, P50 טובה למדי, אך יש לו אורך זנב גבוה. סבסטיאן הסביר: "הבעיה היא שאם יש לנו קבצים של 50K Parquet, המפעילים שלנו מקבלים את כל אלה במקביל. הגדרת ScyllaDB ראוי לציין, Coralogix עבר מהגילוי הראשון של ScyllaDB כדי להיכנס לייצור עם טרה-בייט של נתונים בתוך רק 2 חודשים (זה היה SQL ל- NoSQL הגירה הדורשת עבודה מודל נתונים, לא הרבה יותר פשוט Cassandra או DynamoDB הגירה). התוכנית נכתבה ב-Rust on top of the והם מצאו , , ו מאחר שמציעה ללקוחותיהם חלופה בעלות נמוכה לתצפית היא חשובה עבור Coralogix, צוות Coralogix היה מרוצה מהביצועים המחירים החיוביים של תשתית ScyllaDB שלהם: קבוצת 3 כוכבים עם: ScyllaDB Rust נהג ScyllaDB Operator עבור Kubernetes מעקב ScyllaDB מנהל ScyllaDB 8 VCPU 32 GB זיכרון גרביטון / Graviton Volumes EBS (gp3) with 500 MBps bandwidth and 12k IOPS השימוש ב-ARM מפחית את העלויות, וההחלטה להשתמש ב-EBS (gp3) באה בסופו של דבר על זמינות, גמישות וביצועים במחיר. שיעורים שלמדו השיעורים החשובים שלמדנו כאן... ההבדל הגדול ביותר בעבודה עם ScyllaDB לעומת עבודה עם Postgres הוא שאתה צריך לחשוב די בזהירות על חלוקת וגודל חלוקת. Keep an eye on partition sizes: אתה גם צריך לחשוב בקפידה על דפוסי קריאה / כתיבה. האם עומס העבודה שלך הוא קריא כבד? האם זה כולל שילוב טוב של קריאה וכתבה? או, הוא בעיקר כתיבה כבדה? עומסי העבודה של Coralogix הם די כתיבה כבדה כי הם כל הזמן לצרוך נתונים, אבל הם צריכים להעדיף קריאה כי אורך קריאה הוא קריטי ביותר לעסק שלהם. Think about read/write patterns: הצוות מודה שהם נזהרו לא להשתמש EBS: "לא הקשבנו, אבל כנראה שאנחנו צריכים.אם אתה שוקל להשתמש ScyllaDB, זה כנראה יהיה רעיון טוב להסתכל על דוגמאות שיש SSDים מקומיים במקום לנסות להשתמש Volumes EBS." Avoid EBS: תוכניות עתידיות: WebAssembly UDFs עם Rust בעתיד, הם רוצים למצוא את האמצע בין כתיבת חתיכות גדולות מספיק וקריאה של נתונים מיותרים, הם מחלקים את החתיכות ל ~8,000 שורות ומאמינים שהם יכולים לחלק אותן עוד יותר ל 1,000 שורות, אשר יכול להאיץ את הפריטים שלהם. המטרה הסופית שלהם היא להוריד עוד יותר עבודה ל- ScyllaDB על ידי ניצול עם קוד Rust הקיים שלהם, שילוב UDFs ימנע את הצורך לשלוח את הנתונים בחזרה לאפליקציה, ומספק גמישות להתאמת התאמות ושיפורים פוטנציאליים. פונקציות מוגדרות על ידי המשתמש (UDFs) עם WebAssembly סבסטיאן אומר, "יש לנו כבר הכל כתוב ב- Rust. זה יהיה ממש נחמד אם נוכל להתחיל להשתמש ב- UDFs כך שלא נצטרך לשלוח שום דבר בחזרה לאפליקציה. צפו בשיחה הטכנית המלאה אתה יכול לצפות בשיחה הטכנולוגית המלאה ולגלוש דרך המדף בספריה הטכנולוגית שלנו. אודות Cynthia Dunlop סינתה היא מנהל בכיר של אסטרטגיה תוכן ב ScyllaDB. היא כותבת על פיתוח תוכנה והנדסת איכות במשך 20+ שנים.
