שימוש ב-Clickhouse כתחליף ל-ELK, Big Query ו-TimescaleDB

בית קליק היא מערכת ניהול מסד נתונים עמודים בקוד פתוח לעיבוד שאילתות אנליטיות מקוונות (OLAP) שנוצרה על ידי Yandex. הוא משמש את Yandex, CloudFlare, VK.com, Badoo ושירותים אחרים ברחבי העולם כדי לאחסן כמויות גדולות באמת של נתונים (הכנסת אלפי שורות בשנייה או פטה-בייט של נתונים המאוחסנים בדיסק).

ב-DBMS רגיל, "מחרוזת", שדוגמאות לכך הן MySQL, Postgres, MS SQL Server, הנתונים מאוחסנים בסדר הזה:

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

דוגמאות ל-DBMSs עמודים הם Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.

החברה היא משלחת דואר Qwintry התחלתי להשתמש ב-Clickhouse ב-2018 לדיווח והתרשמתי מאוד מהפשטות, המדרגיות, התמיכה ב-SQL ומהמהירות שלו. המהירות של ה-DBMS הזה גבלה בקסם.

פשטות

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

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

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

פרודוקטיביות

• Benchmark השוואות Clickhouse לעומת Vertica ו-MySQL בשרת תצורה: שני שקעים Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 על 8 6TB SATA HDD, ext4.
• Benchmark השוואה של Clickhouse עם אחסון ענן של Amazon RedShift.
• קטעי בלוג Cloudflare על ביצועי Clickhouse:

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

ClickHouse לא תומך בקבלת נתונים ישירות מקפקא, מכיוון שהוא רק מסד נתונים, אז כתבנו שירות מתאמים משלנו ב-Go. הוא קרא הודעות מקודדות Cap'n Proto מקפקא, המיר אותן ל-TSV והכניס אותן ל-ClickHouse בקבוצות דרך ממשק HTTP. מאוחר יותר שכתבנו שירות זה כדי להשתמש בספריית Go בשילוב עם ממשק ClickHouse משלנו כדי לשפר את הביצועים. בעת הערכת הביצועים של קבלת מנות, גילינו דבר חשוב - התברר שעבור ClickHouse הביצועים הללו תלויים מאוד בגודל החבילה, כלומר במספר השורות המוכנסות בו זמנית. כדי להבין מדוע זה קורה, למדנו כיצד ClickHouse מאחסנת נתונים.

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

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

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

בהתחשב בכך שכל העמודות ממוינות לפי "המפתח הראשי", קובץ האינדקס מכיל רק את התוויות (שורות שנתפסו) של כל שורה Nth, על מנת להיות מסוגל לשמור אותן בזיכרון גם עבור טבלאות גדולות מאוד. לדוגמה, אתה יכול להגדיר את הגדרות ברירת המחדל "לסמן כל שורה 8192", ולאחר מכן אינדקס "דל" של טבלה עם 1 טריליון. שורות שמתאימות בקלות לזיכרון ייקח רק 122 תווים.

פיתוח מערכת

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

פופולריות

נראה שהפופולריות של קליקהאוס צומחת באופן אקספוננציאלי, במיוחד בקהילה דוברת הרוסית. כנס High load 2018 בשנה שעברה (מוסקבה, 8-9 בנובמבר 2018) הראה שמפלצות כמו vk.com ו-Badoo משתמשות ב-Clickhouse, שמכניסה נתונים (לדוגמה, יומנים) מעשרות אלפי שרתים בו זמנית. בסרטון של 40 דקות יורי נסרדינוב מצוות VKontakte מדבר על איך זה נעשה. בקרוב נפרסם את התמליל בהבר לנוחות העבודה עם החומר.

יישומים

לאחר שהשקעתי זמן במחקר, אני חושב שיש תחומים שבהם ClickHouse יכול להיות שימושי או מסוגל להחליף לחלוטין פתרונות מסורתיים ופופולריים אחרים כמו MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ו דרואיד. להלן הפרטים על השימוש ב-ClickHouse כדי לשדרג או להחליף לחלוטין את ה-DBMS הנ"ל.

הרחבת MySQL ו-PostgreSQL

לאחרונה, החלפנו חלקית את MySQL ב-ClickHouse עבור פלטפורמת הניוזלטר ניוזלטר מאוטיק. הבעיה הייתה ש-MySQL עקב עיצוב לא מתוכנן רשם כל מייל שנשלח וכל קישור במייל הזה עם hash של base64, ויצר טבלת MySQL ענקית (email_stats). לאחר שליחת 10 מיליון מיילים בלבד למנויי השירות, הטבלה הזו תפסה 150 ג'יגה-בייט של שטח קבצים, ו-MySQL התחילה להיות "טיפשה" בשאילתות פשוטות. כדי לתקן את בעיית שטח הקבצים, השתמשנו בהצלחה בדחיסת טבלת InnoDB, שהפחיתה אותה בפקטור של 4. עם זאת, עדיין לא הגיוני לאחסן יותר מ-20-30 מיליון מיילים ב-MySQL רק למען קריאת ההיסטוריה, שכן כל שאילתה פשוטה שמסיבה כלשהי חייבת לבצע סריקה מלאה גורמת להחלפה ו-I/O כבדה. תקורה, שעליה קיבלנו בקביעות אזהרות של Zabbix.

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

החלפת ELK

בהתבסס על הניסיון שלי, מחסנית ה-ELK (ElasticSearch, Logstash ו-Kibana, במקרה הספציפי הזה ElasticSearch) דורשת הרבה יותר משאבים להפעלה ממה שנדרש לאחסון יומנים. ElasticSearch הוא מנוע נהדר אם אתה רוצה חיפוש טוב ביומן טקסט מלא (שאני לא חושב שאתה באמת צריך), אבל אני תוהה מדוע הוא הפך למנוע הרישום הסטנדרטי דה פקטו. ביצועי הבליעה שלו, בשילוב עם Logstash, העניקו לנו בעיות גם בעומסי עבודה קלים למדי והצריכו תוספת של עוד ועוד זיכרון RAM ושטח דיסק. כמסד נתונים, Clickhouse עדיף על ElasticSearch מהסיבות הבאות:

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

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

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

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

החלפת Google Big Query ו-Amazon RedShift (פתרון לחברות גדולות)

מקרה השימוש האידיאלי עבור BigQuery הוא לטעון 1TB של נתוני JSON ולהריץ עליהם שאילתות אנליטיות. Big Query הוא מוצר נהדר שקשה להעריך יתר על המידה את יכולת ההרחבה שלו. זו תוכנה הרבה יותר מורכבת מ-ClickHouse שפועלת על אשכול פנימי, אבל מבחינת הלקוח, יש לה הרבה מן המשותף עם ClickHouse. BigQuery יכולה "לתמחר" במהירות ברגע שתתחיל לשלם עבור כל SELECT, כך שזהו פתרון SaaS אמיתי עם כל היתרונות והחסרונות שלו.

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

במאמר של אלכסנדר זייצב, מייסד שותף של Altinity "מעבר לקליקהאוס" מתאר את היתרונות של הגירת DBMS כזו.

החלפת TimescaleDB

TimescaleDB היא תוסף PostgreSQL המייעל את העבודה עם סדרות זמן במסד נתונים רגיל (https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

אמנם ClickHouse היא לא מתחרה רצינית בנישת סדרות הזמן, אבל מבחינת מבנה עמודות וביצוע שאילתות וקטוריות, היא הרבה יותר מהירה מ-TimescaleDB ברוב המקרים של עיבוד שאילתות אנליטיות. יחד עם זאת, הביצועים של קבלת נתוני מנות ClickHouse גבוהים בערך פי 3, בנוסף, הוא מנצל פי 20 פחות שטח דיסק, וזה באמת חשוב לעיבוד כמויות גדולות של נתונים היסטוריים: 
https://www.altinity.com/blog/ClickHouse-for-time-series.

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

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

• התקנות קטנות עם מעט מאוד זיכרון RAM (<3 GB);
• מספר רב של INSERTs קטנים שאינך רוצה לאחסן לשברים גדולים;
• דרישות עקביות, אחידות ו-ACID טובה יותר;
• תמיכה ב-PostGIS;
• התמזג עם טבלאות PostgreSQL קיימות, מכיוון ש-Timescale DB הוא בעצם PostgreSQL.

תחרות עם מערכות Hadoop ו-MapReduce

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

תחרות עם פינו ודרואיד

המתחרים הקרובים ביותר של ClickHouse הם מוצרי הקוד הפתוח העמודים הניתנים להרחבה ליניארית Pinot ו-Druid. עבודה מצוינת בהשוואת מערכות אלו מתפרסמת במאמר רומנה לבנטובה 1 בפברואר 2018

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

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

Druid ופינו הם פרויקטי חממת אפאצ'י, אשר מכוסים בפירוט על ידי Apache בדפי פרויקט GitHub שלהם. פינו הופיע בחממה באוקטובר 2018, ודרואיד נולד 8 חודשים קודם לכן - בפברואר.

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

החסרונות של קליקהאוס

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

תוספות קטנות לא מתפקדות היטב במהירות גבוהה: יש לפצל את ההוספות לנתחים גדולים מכיוון שהביצועים של תוספות קטנות יורדות ביחס למספר העמודות בכל שורה. כך קליקהאוס מאחסנת נתונים בדיסק - כל עמודה פירושה קובץ 1 או יותר, כך שכדי להכניס שורה אחת המכילה 1 עמודות, צריך לפתוח ולכתוב לפחות 100 קבצים. זו הסיבה ש-Insert buffering דורש מתווך (אלא אם הלקוח עצמו מספק חציצה) - בדרך כלל קפקא או איזושהי מערכת תורים. אתה יכול גם להשתמש במנוע הטבלאות Buffer כדי להעתיק מאוחר יותר נתחים גדולים של נתונים לטבלאות MergeTree.

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

ממצאים

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

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com