מעבר לקליקהאוס: 3 שנים מאוחר יותר

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

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

אלכסנדר עובד עם מערכות מבוזרות מאז 2003, ומפתח פרויקטים גדולים בנושא MySQL, אורקל и Vertica. על האחרון + + 2019 אלכסנדר, מחלוצי השימוש קליקהאוס, סיפר מה זה ה-DBMS הזה עכשיו. נלמד על התכונות העיקריות קליקהאוס: במה הוא שונה ממערכות אחרות ובאילו מקרים יעיל יותר להשתמש בו. בעזרת דוגמאות, נבחן פרקטיקות עדכניות ונבדקו בפרויקט לבניית מערכות המבוססות על קליקהאוס.

בדיעבד: מה קרה לפני 3 שנים

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

• יוני 2016. ב קוד פתוח הופיע קליקהאוס והפרויקט שלנו התחיל;
• אוגוסט. הוכחה של רעיון או תאוריה: רשת פרסום גדולה, תשתית ו-200-300 טרה-בייט של נתונים;
• אוֹקְטוֹבֶּר. נתוני ייצור ראשונים;
• דֵצֶמבֶּר. עומס המוצר המלא הוא 10-50 מיליארד אירועים ביום.
• יוני 2017. הגירה מוצלחת של משתמשים ל קליקהאוס, 2,5 פטה-בייט של נתונים על אשכול של 60 שרתים.

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

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

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

למה לעבור ל קליקהאוס

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

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

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

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

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

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

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

עוברים לקליקהאוס

ללכת ל קליקהאוס מסיבה כלשהי, אתה צריך רק שלושה דברים:

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

בעיה בתנועה

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

• עסקאות;
• אילוצים;
• עֲקֵבִיוּת;
• מדדים;
• עדכן/מחק;
• NULLs;
• אלפיות שניות;
• יציקות מסוג אוטומטי;
• חיבורים מרובים;
• מחיצות שרירותיות;
• כלים לניהול אשכולות.

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

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

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

סקריפטים של ClickHouse

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

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

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

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

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

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

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

סדרת זמן

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

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

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

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

הסוג הגדל הכי מהר הוא סדרת זמןס. גם מסדי נתונים של גרפים צומחים, אבל סדרת זמןs גדל מהר יותר במהלך השנים האחרונות. נציגים אופייניים של משפחת מאגרי מידע זו הם InfluxDB, פרומתאוס, KDB, טווח זמנים DB (בנוי על PostgreSQL), פתרונות מ אמזון בעברית. קליקהאוס יכול לשמש גם כאן, והוא משמש. הרשו לי לתת לכם כמה דוגמאות פומביות.

אחת החלוצות היא החברה CloudFlare (CDN-ספק). הם עוקבים אחריהם CDN דרך קליקהאוס (DNS-בקשות, HTTP-שאילתות) עם עומס עצום - 6 מיליון אירועים בשנייה. הכל עובר קפקא, הולך ל קליקהאוס, המספק הזדמנות לראות לוחות מחוונים של אירועים במערכת בזמן אמת.

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

פרקונה נִבנָה בְּ קליקהאוס בתוך שלך PMMלאחסן ניטור של שונים MySQL.

דרישות ספציפיות

לבסיסי נתונים של סדרות זמן יש דרישות ספציפיות משלהם.

• הכנסה מהירה מסוכנים רבים. עלינו להכניס נתונים מזרמים רבים במהירות רבה. קליקהאוס הוא עושה זאת היטב מכיוון שכל התוספות שלו לא חוסמות. כל להכניס הוא קובץ חדש בדיסק, וניתן לאחסן תוספות קטנות בצורה כזו או אחרת. IN קליקהאוס עדיף להכניס נתונים באצוות גדולות ולא שורה אחת בכל פעם.
• תכנית גמישה. בתוך סדרת זמן אנחנו בדרך כלל לא יודעים את מבנה הנתונים לחלוטין. אפשר לבנות מערכת ניטור לאפליקציה ספציפית, אבל אז קשה להשתמש בה לאפליקציה אחרת. זה דורש תוכנית גמישה יותר. קליקהאוס, מאפשר לך לעשות זאת, למרות שזה בסיס מוקלד חזק.
• אחסון יעיל ושכחת נתונים. בדרך כלל ב סדרת זמן כמות עצומה של נתונים, ולכן יש לאחסן אותם בצורה יעילה ככל האפשר. לדוגמה, ב InfluxDB דחיסה טובה היא התכונה העיקרית שלו. אבל מלבד אחסון, אתה גם צריך להיות מסוגל "לשכוח" נתונים ישנים ולעשות סוג כלשהו דגימת הפחתה - ספירה אוטומטית של אגרגטים.
• שאילתות מהירות על נתונים מצטברים. לפעמים מעניין להסתכל על 5 הדקות האחרונות בדיוק של אלפיות שניות, אבל בנתונים חודשיים ייתכן שלא יהיה צורך בפירוט דקה או שניה - די בסטטיסטיקה כללית. תמיכה מהסוג הזה הכרחית, אחרת בקשה ל-3 חודשים ייקח הרבה מאוד זמן להשלים גם ב קליקהאוס.
• בקשות כמו "נקודה אחרונה, נכון ליום». אלה אופייניים ל סדרת זמן שאילתות: הסתכל על המדידה או המצב האחרון של המערכת ברגע בזמן t. אלו שאילתות לא מאוד נעימות עבור מסד נתונים, אבל אתה גם צריך להיות מסוגל לבצע אותן.
• סדרת זמן "הדבקה".. סדרת זמן היא סדרת זמן. אם יש שתי סדרות זמן, לעתים קרובות יש צורך בחיבור ובקורלציה ביניהן. לא נוח לעשות זאת בכל מסדי הנתונים, במיוחד עם סדרות זמן לא מיושרות: הנה כמה נקודות זמן, יש אחרות. אתה יכול לשקול ממוצע, אבל פתאום עדיין יהיה שם חור, אז זה לא ברור.

בוא נראה כיצד הדרישות הללו מתקיימות קליקהאוס.

ערכתי

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

נתונים רגילים. עמודות. הסכימה פשוטה - עמודות עם הסוגים הנדרשים:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

נתונים לא סדירים. מערכים:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

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

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

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

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

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

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

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

הבה נשווה שלוש גישות:

פרטים

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

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

באחת החברות המשתמשות בגישה זו (למשל, סופר), מערכים נחתכים לחתיכות של 128 אלמנטים. נתונים מכמה אלפי מדדים בנפח של 200 TB של נתונים ליום מאוחסנים לא במערך אחד, אלא ב-10 או 30 מערכים עם היגיון אחסון מיוחד.

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

תכנית היברידית

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

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

קודקים ודחיסה

עבור סדרת זמן זה משנה כמה טוב אתה אורז את הנתונים כי כמות המידע יכולה להיות גדולה מאוד. IN קליקהאוס יש סט כלים להשגת אפקט דחיסה של 1:10, 1:20 ולפעמים יותר. המשמעות היא ש-1 TB של נתונים לא ארוזים בדיסק תופסים 50-100 GB. גודל קטן יותר הוא טוב, ניתן לקרוא נתונים ולעבד אותם מהר יותר.

כדי להשיג רמה גבוהה של דחיסה, קליקהאוס תומך בקודקים הבאים:

טבלה לדוגמה:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

כאן אנו מגדירים את ה-codec DoubleDelta במקרה אחד, במקרה השני - גורילה, ובהחלט נוסיף עוד LZ4 דְחִיסָה. כתוצאה מכך, גודל הנתונים בדיסק מצטמצם מאוד:

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

• בקובץ GZIP בדיסק;
• ב-ClickHouse ללא קודקים, אבל עם דחיסת ZSTD;
• ב-ClickHouse עם קודקים ודחיסה LZ4 ו-ZSTD.

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

גודל חשוב

לא פחות חשוב Выбрать סוג הנתונים הנכון:

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

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

צבירה ו תצוגות ממומשות

צבירה ותצוגות ממומשות מאפשרות לך ליצור אגרגטים לאירועים שונים:

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

TTL - "לשכח" נתונים ישנים

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

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

רב שכבתי - לחלק נתונים על פני דיסקים

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

אתה יכול להגדיר מדיניות אחסון (מדיניות אחסון) כך קליקהאוס יעביר נתונים אוטומטית עם הגעה לתנאים מסוימים לאחסון אחר.

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

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

הזדמנויות ייחודיות קליקהאוס

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

• מערכים. בתוך קליקהאוס תמיכה טובה מאוד עבור מערכים, כמו גם היכולת לבצע חישובים מורכבים עליהם.
• צבירת מבני נתונים. זו אחת ה"תכונות הרוצחות" קליקהאוס. למרות העובדה שהחבר'ה מיאנדקס אומרים שאנחנו לא רוצים לצבור נתונים, הכל מצטבר ב קליקהאוס, כי זה מהיר ונוח.
• צפיות ממומשות. יחד עם מבני נתונים מצטברים, תצוגות ממומשות מאפשרות לך לעשות נוחות זמן אמת צבירה.
• ClickHouse SQL. זוהי הרחבה לשפה SQL עם כמה תכונות נוספות ובלעדיות הזמינות רק ב קליקהאוס. בעבר זה היה כמו הרחבה מצד אחד, וחיסרון מצד שני. עכשיו כמעט כל החסרונות לעומת SQL 92 הסרנו את זה, עכשיו זה רק הרחבה.
• למבדה-ביטויים. האם הם עדיין בבסיס נתונים כלשהו?
• ML-תמיכה. זה זמין במסדי נתונים שונים, חלקם טובים יותר, חלקם גרועים יותר.
• קוד פתוח. אנחנו יכולים להרחיב קליקהאוס יַחַד. עכשיו ב קליקהאוס כ-500 תורמים, ומספר זה גדל ללא הרף.

שאילתות מסובכות

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

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

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

השיטה השנייה עושה את אותו הדבר אבל משתמשת בפונקציה צבירה argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

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

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

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

פונקציות אנליטיות

בתקן SQL-2003 אתה יכול לכתוב כך:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

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

הבטחתי למבדות - הנה הן כאן!

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

מאפיינים מיוחדים

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

באופן כללי, ל- ClickHouse יש פונקציות מיוחדות למטרות רבות:

• runningDifference, runningAccumulate, שכן;
• sumMap(מפתח, ערך);
• timeSeriesGroupSum(uid, חותמת זמן, ערך);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• עם מילוי / עם קשרים;
• simpleLinearRegression, stochasticLinearRegression.

זו לא רשימה מלאה של פונקציות, יש 500-600 בסך הכל. רמז: כל הפונקציות ב קליקהאוס נמצא בטבלת המערכת (לא כולם מתועדים, אבל כולם מעניינים):

select * from system.functions order by name

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

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

אשכול גדול או הרבה קטנים קליקהאוס

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

В קליקהאוס אתה יכול לעשות את זה אחרת. אתה יכול להפוך כל יישום לשלך קליקהאוס:

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

אבל אם יש לנו הרבה קליקהאוס, ואתה צריך להתקין אותו לעתים קרובות, אז אתה רוצה להפוך את התהליך הזה לאוטומטי. לשם כך נוכל, למשל, להשתמש קוברנט и בית קליק-מַפעִיל. IN Kubernetes ClickHouse אתה יכול לשים את זה "בלחיצה": אני יכול ללחוץ על כפתור, להפעיל את המניפסט ומסד הנתונים מוכן. אני יכול מיד ליצור דיאגרמה, להתחיל להעלות שם מדדים, ותוך 5 דקות יש לי לוח מחוונים מוכן גרפנה. זה כל כך פשוט!

התוצאה?

לפיכך, קליקהאוס - זה:

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

ניתן לצפות במצגת כאן.

המפגש המיוחל של מפתחי מערכות עומס גבוה ב HighLoad ++ יתקיים ב-9 וב-10 בנובמבר בסקולקובו. לבסוף, זה יהיה ועידה לא מקוונת (אם כי עם כל אמצעי הזהירות במקום), מכיוון שלא ניתן לארוז את האנרגיה של HighLoad++ באופן מקוון.

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

לאחר שקיימנו את המפגשים שלנו ללא הפרעה מאז 2007, השנה ניפגש בפעם ה-14. במהלך תקופה זו, הכנס גדל פי 10; בשנה שעברה, האירוע המרכזי בתעשייה ריכז 3339 משתתפים, 165 דוברים, דוחות ומפגשים, ו-16 מסלולים פעלו בו זמנית.
בשנה שעברה היו 20 אוטובוסים, 5280 ליטר תה וקפה, 1650 ליטר משקאות פירות ו-10200 בקבוקי מים. ועוד 2640 קילוגרמים של אוכל, 16 צלחות ו-000 כוסות. אגב, בכסף שנאסף מנייר ממוחזר שתלנו 25 שתילי אלון :)

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

מקור: www.habr.com