ClickHouse למשתמשים מתקדמים בשאלות ותשובות

באפריל התכנסו מהנדסי Avito לפגישות מקוונות עם מפתח ClickHouse הראשי אלכסיי מילובידוב וקיריל שבקוב, מפתח גולאנג מ-Integros. דנו כיצד אנו משתמשים במערכת ניהול מסד נתונים ובאילו קשיים אנו נתקלים.

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

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

תוכן

• ClickHouse מתעדכן כל הזמן, אבל הנתונים שלנו לא. מה לעשות בנידון?
• מהן השיטות המומלצות הנוכחיות לגיבוי נתונים מ-ClickHouse?
• האם ניתן יהיה לארגן פיגור מבוקר של העתקים בפירים?
• מה אם מבנה הטבלה השתנה?
• מהן השיטות המומלצות הנוכחיות בשיתוף נתונים מחדש?
• ל-ClickHouse יש כלי עזר למכונת צילום קליקהאוס. אתה יכול לספר לנו עליה?
• היה לך עניין של פיילוט שנקרא מחדש. מה איתה?
• האם ניתן למזג את כל פיסות הנתונים יחד לפני העברתם לדיסקים איטיים?
• כיצד לעבור לגרסאות חדשות של ClickHouse אם אין דרך לבדוק תאימות מראש?
• Kill query אמור להרוג שאילתות, אבל זה לא. למה?
• כיצד לחשב זמן תגובה בעומס קריאה?
• מה אני יכול לצבוט ב-ClickHouse כדי שיהיו נתונים נוספים במטמון?
• כיצד אוכל להגדיר את storage_configuration לאחסון ב-RAM?
• עד איזה מספר ערכים ייחודיים יעילה קרדינליות נמוכה?
• מהן השיטות המומלצות לחיפוש בטקסט מלא בטבלה עם חמישה מיליארד שורות?
• מהי הדרך הטובה ביותר לארגן גישה ל-ClickHouse עבור מספר רב של משתמשים?
• האם ניתן לתת תוצאות של שאילתה אחת לעשרה לקוחות?
• מה לגבי פעולות אסינכרוניות ותצוגות שהתממשו?
• ל- ClickHouse יש הרבה יומנים. איך אני יכול לראות את כל מה שקורה עם השרת ברגע זה?
• איך להשפיע על מיזוגים כדי שהשרת לא יקרוס לתוך OOM?
• כיצד יפותח הדרייבר של Golang עבור ClickHouse?
• המילון החיצוני אינו נטען לאחר אתחול מחדש כאשר הגדרת lazy_load מופעלת. מה לעשות?
• מה לעשות עם העובדה שמערכת טעינה מחדש של מילונים לא טוענת אף אחד מהמילונים הרבים אם לפחות אחד מהם קורס עם שגיאה?
• האם יש דרך להגדיר פרטים בתצורת ClickHouse, אך לא להציג אותם במקרה של שגיאות?
• בונוס: רקעים לזום ממפגשים

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

ClickHouse מתעדכן כל הזמן, אבל הנתונים שלנו לא. מה לעשות בנידון?

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

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

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

מהן השיטות המומלצות הנוכחיות לגיבוי נתונים מ-ClickHouse?

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

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

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

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

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

אם הטבלה עם הנתונים תופסת רק כמה גיגה-בייט, ניתן לבצע גיבוי כך:

1. שמור את הגדרת הטבלה, כלומר מטא נתונים - הצג צור טבלה.
2. בצע dump באמצעות הלקוח של ClickHouse - בחר * משולחן לתייק. כברירת מחדל תקבל קובץ בפורמט TabSeparated. אם אתה רוצה להיות יעיל יותר, אתה יכול לעשות זאת בפורמט Native.

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

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

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

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

לפעמים אתה צריך משהו אפילו יותר מגניב - במקרים שבהם יש לך עשרות ואפילו מאות טרה-בייט בכל שרת ומאות שרתים. יש כאן פתרון שלקחתי מעמיתיי מ-Yandex.Metrica. לא הייתי ממליץ לכולם - קראו ותחליטו בעצמכם אם הוא מתאים או לא.

ראשית עליך ליצור מספר שרתים עם מדפי דיסקים גדולים. לאחר מכן, בשרתים אלו, הרם מספר שרתי ClickHouse והגדר אותם כך שיעבדו כעותק נוסף עבור אותם רסיסים. ולאחר מכן השתמש במערכת קבצים או בכלי כלשהו בשרתים אלה המאפשרים לך ליצור צילומי מצב. יש כאן שתי אפשרויות. האפשרות הראשונה היא LVM snapshots, האפשרות השנייה היא ZFS ב-Linux.

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

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

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

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

אם הגיעה פקודה לאשכול שלנו ושברה אותו, אז יש לנו העתק מותנה עם פיגור של שעה, שבו אנחנו יכולים לומר שנשתמש בו כרגע, אבל לא נחיל עליו שינויים בעשר הדקות האחרונות?

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

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

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

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

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

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

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

מה אם מבנה הטבלה השתנה?

כיצד לשחזר גיבוי שנעשה עם הסכימה הישנה? והשאלה השנייה היא על המקרה עם צילומי מצב וכלי מערכת קבצים. האם Btrfs טוב כאן במקום ZFS ב-Linux LVM?

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

כעת השאלה השנייה היא האם ניתן להשתמש ב-Btrfs. מלכתחילה, אם יש לך LVM, אז די בתמונות LVM, ומערכת הקבצים יכולה להיות ext4, זה לא משנה. עם Btrts, הכל תלוי בניסיון שלך בשימוש בו. זו מערכת קבצים בוגרת, אבל עדיין יש כמה חשדות לגבי איך הכל יסתדר בפועל בתרחיש מסוים. לא הייתי ממליץ להשתמש בזה אלא אם כן יש לך Btrfs בייצור.

מהן השיטות המומלצות הנוכחיות בשיתוף נתונים מחדש?

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

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

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

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

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

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

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

אז זו שיטה מספר אחת. ואני מחכה לתשובתך, האם השיטה מתאימה, או שנמשיך הלאה.

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

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

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

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

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

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

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

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

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

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

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

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

יש אשכול ראשי עם אירועי Yandex.Metrica. אירועים הם צפיות בדף, קליקים והמרות. רוב הבקשות מגיעות לאתר ספציפי. אתה פותח את שירות Yandex.Metrica, יש לך אתר אינטרנט - avito.ru, עבור לדוח, ונשלחת בקשה לאתר שלך.

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

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

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

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

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

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

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

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

בתכנית החדשה, כל האתרים מחולקים לשתי קטגוריות - גדולות וקטנות. אני לא יודע איך הסף נבחר, אבל התוצאה הייתה שאתרים גדולים מתועדים על אשכול אחד, שבו יש 120 רסיסים עם שלושה העתקים כל אחד - כלומר 360 שרתים. ושיטת הרסיסים היא כזו שכל בקשה עוברת לכל הרסיסים בבת אחת. אם תפתח כעת דף דיווח כלשהו עבור avito.ru ב-Yandex.Metrica, הבקשה תעבור ל-120 שרתים. יש מעט אתרים גדולים ב-RuNet. והבקשות הן לא אלף לשנייה, אלא אפילו פחות ממאה. כל זה נלעס בשקט על ידי ה-Distributed table, שכל אחד מהם מעבד עם 120 שרתים.

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

ל-ClickHouse יש כלי עזר למכונת צילום קליקהאוס. אתה יכול לספר לנו עליה?

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

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

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

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

היה לך עניין של פיילוט שנקרא מחדש. מה איתה?

עוד בשנת 2017, היה לך עניין של פיילוט שנקרא reharding. יש אפילו אפשרות בקליקהאוס. לפי הבנתי, זה לא המריא. אתה יכול להגיד לי למה זה קרה? נראה שזה מאוד רלוונטי.

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

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

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

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

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

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

כיצד לעבור לגרסאות חדשות של ClickHouse אם אין דרך לבדוק תאימות מראש?

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

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

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

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

יש גרסה 20.3.4. המספר 20 מציין את שנת הייצור - 2020. מבחינת מה שיש בפנים זה לא משנה ולכן לא נשים לב לזה. הבא - 20.3. אנו מגדילים את המספר השני - במקרה זה 3 - בכל פעם שאנו משחררים מהדורה עם פונקציונליות חדשה כלשהי. אם אנחנו רוצים להוסיף תכונה כלשהי ל-ClickHouse, עלינו להגדיל את המספר הזה. כלומר, בגרסה 20.4 ClickHouse יעבוד אפילו טוב יותר. הספרה השלישית היא 20.3.4. הנה 4 הוא מספר מהדורות התיקון שבהם לא הוספנו פיצ'רים חדשים, אלא תיקנו כמה באגים. ו-4 אומר שעשינו את זה ארבע פעמים.

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

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

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

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

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

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

אלכסיי מילובידוב: אני אגיד לך מהי סביבת הבדיקה של החברים שלנו מ-Yandex.Metrica. לאשכול אחד היו 600 שרתים, באחר היו 360, ויש שלישי וכמה אשכולות. סביבת הבדיקה של אחד מהם היא פשוט שני רסיסים עם שני העתקים כל אחד. למה שני רסיסים? כדי שאתה לא לבד. וצריך להיות גם העתקים. רק סכום מינימלי מסוים שאתה יכול להרשות לעצמך.

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

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

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

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

Kill query אמור להרוג שאילתות, אבל זה לא. למה?

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

אני מוצא את הבקשה הזו וכותב לה להרוג. ואני רואה ששום דבר לא קורה. השרת שלי נמצא במדף, קליקהאוס נותנת לי כמה פקודות, מראה שהשרת חי והכל נהדר. אבל יש לי השפלה בכל בקשות המשתמש, השפלה מתחילה ברשומות ב-ClickHouse, ושאילתת ההרוג שלי לא עובדת. למה? חשבתי ש-kill query אמור להרוג שאילתות, אבל זה לא קורה.

עכשיו תהיה תשובה די מוזרה. הנקודה היא ש-kill query לא הורג שאילתות.

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

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

כיצד לחשב זמן תגובה בעומס קריאה?

יש טבלה המאחסנת אגרגטים של פריטים - מונים שונים. מספר השורות הוא כמאה מיליון. האם ניתן לסמוך על זמן תגובה צפוי אם אתה מוזג 1K RPS עבור 1K פריטים?

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

בקשות קריאה שונות מאוד. בבחירה 1, ClickHouse יכולה לבצע כעשרות אלפי בקשות בשנייה, כך שאפילו בקשות למפתח אחד כבר ידרשו משאבים מסוימים. ושאילתות נקודות כאלה יהיו קשות יותר מאשר בכמה מסדי נתונים של ערכי מפתח, מכיוון שלכל קריאה יש צורך לקרוא בלוק נתונים לפי אינדקס. האינדקס שלנו מתייחס לא לכל רשומה, אלא לכל טווח. כלומר, תצטרכו לקרוא את כל הטווח - זה 8192 שורות כברירת מחדל. ואתה תצטרך לפרק את בלוק הנתונים הדחוס מ-64 KB ל-1 MB. בדרך כלל, שאילתות ממוקדות כאלה לוקחות כמה אלפיות שניות להשלמת. אבל זו האפשרות הפשוטה ביותר.

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

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

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

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

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

כשאין לך הרבה נתונים, אין הרבה טעם להשתמש ב-ClickHouse. יש מאגרי מידע רגילים והם עושים זאת היטב.

מה אני יכול לצבוט ב-ClickHouse כדי שיהיו נתונים נוספים במטמון?

בואו נדמיין מצב - לשרתים יש 256 ג'יגה זיכרון RAM, בשגרה היומיומית ClickHouse לוקח בערך 60-80 ג'יגה, בשיא - עד 130. מה אפשר להפעיל ולצבוט כך שיותר נתונים יהיו במטמון ובהתאם, יש פחות נסיעות לדיסק?

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

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

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

כיצד אוכל להגדיר את storage_configuration לאחסון ב-RAM?

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

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

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

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

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

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

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

עד איזה מספר ערכים ייחודיים יעילה קרדינליות נמוכה?

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

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

מהן השיטות המומלצות לחיפוש בטקסט מלא בטבלה עם חמישה מיליארד שורות?

יש תשובות שונות. הראשון הוא לומר ש-ClickHouse אינו מנוע חיפוש בטקסט מלא. יש מערכות מיוחדות לכך, למשל, Elasticsearch и ספינקס. עם זאת, אני רואה יותר ויותר אנשים אומרים שהם עוברים מ- Elasticsearch ל- ClickHouse.

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

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

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

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

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

לאחרונה, ClickHouse הוסיפה פונקציות מתקדמות עוד יותר לחיפוש בטקסט מלא. זהו, ראשית, חיפוש אחר חבורה של מחרוזות משנה בו-זמנית במעבר אחד, כולל אפשרויות שהן תלויות-רישיות, לא-רישיות, עם תמיכה ב-UTF-8 או רק ב-ASCII. בחר את היעיל ביותר שאתה צריך.

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

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

מהי הדרך הטובה ביותר לארגן גישה ל-ClickHouse עבור מספר רב של משתמשים?

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

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

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

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

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

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

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

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

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

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

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

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

האם ניתן לתת תוצאות של שאילתה אחת לעשרה לקוחות?

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

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

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

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

ישנו פתרון חלופי שמוקם כרכב צד ליד ClickHouse - Proxy של ClickHouse.

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

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

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

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

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

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

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

זה הכרחי בשביל הוודאות. אם אתה מקבל "Ok" במהלך ההכנסה, הנתונים שלך הוכנסו. אם אתה מקבל שגיאה מ-ClickHouse, זה אומר שהם לא הוכנסו ואתה צריך לחזור על ההוספה. אבל אם החיבור נשבר במהלך ההכנסה, אז אתה לא יודע אם הנתונים הוכנסו או לא. האפשרות היחידה היא לחזור על ההחדרה שוב. אם הנתונים הוכנסו בפועל והכנסתם אותם מחדש, יש מניעת כפילויות בלוק. זה נחוץ כדי למנוע כפילויות.

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

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

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

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

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

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

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

ל- ClickHouse יש הרבה יומנים. איך אני יכול לראות את כל מה שקורה לשרת במבט אחד?

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

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

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

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

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

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

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

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

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

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

איך להשפיע על מיזוגים כדי שהשרת לא יקרוס לתוך OOM?

יש לי טבלה, יש רק מחיצה אחת בטבלה, היא ReplaceingMergeTree. אני כותב לתוכו נתונים כבר ארבע שנים. הייתי צריך לעשות בו שינוי ולמחוק כמה נתונים.

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

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

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

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

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

מה כרגע מגן עליי מנפילה לתוך OOM אם זה באמת צורך 100 GB של זיכרון RAM? מה לעשות אם פתאום ה-RAM במיזוג אוזל?

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

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

כיצד יפותח הדרייבר של Golang עבור ClickHouse?

נהג הגולנג, שנכתב על ידי קיריל שבקוב, נתמך כעת רשמית על ידי צוות ClickHouse. הוא במאגר ClickHouse, עכשיו הוא גדול ואמיתי.

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

יש לי שתי שאלות. כעת מנהל התקן Golang של Kirill הוא כמעט דרך ברירת המחדל לתקשר מ-Golang עם ClickHouse. אלא אם כן מישהו עדיין מתקשר דרך ממשק http כי הוא אוהב את זה ככה. כיצד יתקדם הפיתוח של דרייבר זה? האם זה יסונכרן עם כל שינוי שבירה במאגר עצמו? ומהו הפרוצדורה לבחינת נושא?

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

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

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

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

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

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

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

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

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

המילון החיצוני אינו נטען לאחר אתחול מחדש כאשר הגדרת lazy_load מופעלת. מה לעשות?

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

אולי יש לנו גרסה ישנה של ClickHouse, כך שהמילון לא נטען אוטומטית. האם זה יכול להיות המקרה?

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

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

התשובה לשאלה האחרונה היא או שהגרסה ישנה או שצריך לנפות באגים.

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

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

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

האם יש דרך להגדיר פרטים בתצורת ClickHouse, אך לא להציג אותם במקרה של שגיאות?

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

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

הפתרון האמיתי כאן הוא לציין את האישורים הללו ב-odbc.ini, וב-ClickHouse עצמו לציין רק את שם מקור הנתונים של ODBC. זה לא יקרה עבור מקורות מילון אחרים - לא עבור המילון עם MySQL, ולא עבור האחרים, אתה לא אמור לראות את הסיסמה כאשר אתה מקבל הודעת שגיאה. עבור ODBC, אני גם אחפש - אם הוא קיים, אתה רק צריך להסיר אותו.

בונוס: רקעים לזום ממפגשים

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

מקור: www.habr.com