HighLoad++, יורי נסרטדינוב (VKontakte): כיצד VK מכניסה נתונים ל-ClickHouse מעשרות אלפי שרתים

HighLoad++ מוסקבה 2018, אולם הקונגרסים. 9 בנובמבר, 15:00

תקצירים ומצגת: http://www.highload.ru/moscow/2018/abstracts/4066

יורי נסרטדינוב (VKontakte): הדו"ח ידבר על חוויית היישום של ClickHouse בחברה שלנו - למה אנחנו צריכים את זה, כמה נתונים אנחנו מאחסנים, איך אנחנו כותבים אותם וכו'.

מאפייני מידע: שימוש ב-Clickhouse כתחליף ל-ELK, Big Query ו-TimescaleDB

יורי נסרדינוב: - שלום לכולם! שמי יורי נסרדינוב, כפי שכבר הוצגתי. אני עובד ב-VKontakte. אני אדבר על איך אנחנו מכניסים נתונים ל-ClickHouse מצי השרתים שלנו (עשרות אלפים).

מהם יומנים ולמה לאסוף אותם?

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

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

למה החלטנו? כנראה שהיו לנו פתרונות לאחסון יומנים. כאן - יש כזה "Backend VK" פומבי. אני ממליץ בחום להירשם אליו.

מה זה יומנים? זהו מנוע שמחזיר מערכים ריקים. מנועים ב-VK הם מה שאחרים מכנים microservices. והנה מדבקה מחייכת (די הרבה לייקים). איך זה? ובכן, תקשיבו יותר!

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

קליקהאוס ומתחרים: דרישות והזדמנויות

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

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

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

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

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

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

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

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

איך נכניס את זה? MergeTree

מי מכם לא שמע או יודע על "ClickHouse"? אני צריך להגיד לך, נכון? מהר מאוד. ההכנסה לשם - 1-2 גיגה-ביט לשנייה, פרצים של עד 10 גיגה-ביט לשנייה יכולה למעשה לעמוד בתצורה הזו - יש שני Xeons 6 ליבות (כלומר, אפילו לא החזקים ביותר), 256 גיגה-בייט של זיכרון RAM, 20 טרה-בייט ב-RAID (אף אחד לא מוגדר, הגדרות ברירת מחדל). אלכסיי מילובידוב, מפתח ClickHouse, כנראה יושב שם בוכה כי לא הגדרנו כלום (הכל עבד לנו ככה). בהתאם לכך, ניתן להשיג מהירות סריקה של, נניח, כ-6 מיליארד שורות בשנייה אם הנתונים דחוסים היטב. אם אתה עושה לייק % על מחרוזת טקסט - 100 מיליון שורות בשנייה, כלומר, זה נראה די מהיר.

איך נכניס את זה? ובכן, אתה יודע ש-VK משתמש ב-PHP. אנו נכניס מכל עובד PHP דרך HTTP לתוך "ClickHouse", לטבלת MergeTree עבור כל רשומה. מי רואה בעיה בתכנית הזו? משום מה, לא כולם הרימו ידיים. תן לי לספר לך.

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

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

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

הנה דמיינו שיש כאלף שרתים עליהם השקנו, יש רק PHP. ובכל שרת יש את הסוכן המקומי שלנו, שקראנו לו "קיטן האוס", ששומר על קשר אחד עם "קליק האוס" ומכניס נתונים כל כמה שניות. מכניס נתונים לא לתוך MergeTree, אלא לטבלת חיץ, המשרתת בדיוק כדי להימנע מהכנסה ישירה לתוך MergeTree מיד.

עבודה עם טבלאות חיץ

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

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

מה זה Kittenhouse ואיך זה עובד?

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

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

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

הוסף nginx

פתרון כזה למודל Thread per connection הוא nginx. התקנו nginx מול Clickhouse, במקביל הגדרנו איזון עבור שני העתקים (מהירות ההכנסה שלנו גדלה פי 2, למרות שזה לא עובדה שזה צריך להיות המקרה) והגבלנו את מספר החיבורים לקליקהאוס, ל- במעלה הזרם, ובהתאם, יותר, מאשר ב-50 חיבורים, נראה שאין טעם להכניס.

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

ואז גילינו את הבעיה המעניינת הזו: אם אתה משתמש בשיטה לא סטנדרטית של הכנסה במצב SQL, זה מאלץ מנתח SQL מבוסס AST מלא, שהוא די איטי. בהתאם לכך, הוספנו הגדרות כדי להבטיח שזה לעולם לא יקרה. עשינו איזון עומסים, בדיקות בריאות, כך שאם אחד מת, אנחנו עדיין משאירים את הנתונים. יש לנו עכשיו די הרבה טבלאות שאנחנו צריכים כדי שיהיו אשכולות Clickhouse שונים. והתחלנו לחשוב גם על שימושים אחרים - למשל, רצינו לכתוב יומנים ממודולי nginx, אבל הם לא יודעים איך לתקשר באמצעות ה-RPC שלנו. ובכן, הייתי רוצה ללמד אותם איך לשלוח לפחות איכשהו - למשל, לקבל אירועים ב-localhost דרך UDP ואז להעביר אותם ל-Clickhouse.

צעד אחד מהפתרון

הסכימה הסופית החלה להיראות כך (הגרסה הרביעית של הסכמה הזו): בכל שרת מול Clickhouse יש nginx (באותו שרת) והוא פשוט מעביר בקשות ל-localhost עם הגבלה על מספר החיבורים של 50 חתיכות. והתוכנית הזו כבר די עבדה, הכל היה די טוב איתה.

חיינו ככה כחודש. כולם היו מרוצים, הוסיפו טבלאות, הוסיפו, הוסיפו... בכלל, התברר שהדרך בה הוספנו טבלאות חיץ לא הייתה אופטימלית במיוחד (בואו נגיד את זה כך). עשינו 16 חלקים בכל טבלה ומרווח הבזק של כמה שניות; היו לנו 20 טבלאות וכל טבלה קיבלה 8 הוספות לשנייה - ובשלב זה התחיל "קליקהאוס"... הרשומות החלו להאט. הם אפילו לא עברו... ל-Nginx כברירת מחדל היה דבר כל כך מעניין שאם החיבורים הסתיימו במעלה הזרם, אז זה פשוט החזיר "502" לכל הבקשות החדשות.

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

החלפת nginx בפרוקסי הפוך

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

מה הוא עושה? זה עובד על בסיס ספריית fasthttp "goshnoy", כלומר, מהר, כמעט מהר כמו nginx. סליחה, איגור, אם אתה נוכח כאן (הערה: איגור סיסוייב הוא מתכנת רוסי שיצר את שרת האינטרנט nginx). הוא יכול להבין באיזה סוג של שאילתות מדובר - INSERT או SELECT - בהתאם, הוא מחזיק בריכות חיבור שונות לסוגים שונים של שאילתות.

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

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

הסכימה החלה להיראות כך: "Kittenhouse", ה-Proxy ההפוך מקבץ בקשות רבות לטבלאות, ובתמורה, טבלאות המאגר מכניסות אותן לטבלאות הראשיות.

רוצח הוא פתרון זמני, חתלתול הוא קבוע

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

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

אם בקשה מגיעה לשרת בשיטת Kitten, אז השרת צריך להגיב "מיאו" - בהיגיון. אם הוא מגיב לזה, אז נחשב שהוא מבין את הפרוטוקול הזה, ואז אני מיירט את החיבור (ל-fasthttp יש שיטה כזו), והחיבור עובר למצב "גולמי". למה אני צריך את זה? אני רוצה לשלוט כיצד קריאה מחיבורי TCP מתרחשת. ל-TCP יש תכונה נפלאה: אם אף אחד לא קורא מהצד השני, הכתיבה מתחילה לחכות, והזיכרון לא מושקע במיוחד על זה.

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

טבלת החיץ עצובה

לאחרונה נתקלנו בתכונה מעניינת נוספת של טבלאות חיץ. והבעיה הזו כבר הרבה יותר כואבת מהאחרות. בואו נדמיין את המצב הזה: אתה כבר משתמש באופן פעיל ב-Clickhouse, יש לך עשרות שרתי Clickhouse, ויש לך כמה בקשות שלוקח הרבה מאוד זמן לקריאה (נניח, יותר מ-60 שניות); ואתה בא ועושה אלטר ברגע זה... בינתיים, "בחר" שהתחיל לפני "Alter" לא ייכלל בטבלה זו, "Alter" לא יתחיל - כנראה כמה תכונות של איך "Clickhouse" עובד ב המקום הזה. אולי אפשר לתקן את זה? או שזה בלתי אפשרי?

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

יש גם שלט כזה (אולי מישהו שם לב לזה) - זה נקרא query_thread_log בגרסאות חדשות של Clickhouse. כברירת מחדל, בגרסה כלשהי הייתה אחת. כאן צברנו 840 מיליון שיאים בכמה חודשים (100 גיגה-בייט). זה נובע מכך שנכתבו שם "תוספות" (אולי עכשיו, אגב, הן לא כתובות). כפי שאמרתי לך, ה"תוספות" שלנו קטנות - היו לנו הרבה "תוספות" לטבלאות המאגר. ברור שזה מושבת - אני רק אומר לך מה ראיתי בשרת שלנו. למה? זהו טיעון נוסף נגד שימוש בטבלאות חיץ! ספוטי עצוב מאוד.

מי ידע ששמו של הבחור הזה הוא ספוטי? עובדי VK הרימו ידיים. בסדר.

על התוכניות של "KittenHouse"

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

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

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

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

בואו נדבר על קריאה

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

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

וזה נראה מאוד דומה ל-Sequel Pro, אבל נעשה רק על Bootstrap של טוויטר, והגרסה השנייה. אתה שואל: "יורי, למה בגרסה השנייה?" איזו שנה? 2018? באופן כללי, עשיתי את זה די מזמן עבור "Muscle" (MySQL) ורק שיניתי כמה שורות בשאילתות שם, וזה התחיל לעבוד עבור "Clickhouse", ועל כך תודה מיוחדת! מכיוון שהמנתח דומה מאוד ל"שריר", והשאילתות דומות מאוד - מאוד נוח, במיוחד בהתחלה.

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

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

"קליקהאוס" מתאים למאורות

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

TCP? באופן כללי, ב-VK נהוג להשתמש ב-UDP. וכשהשתמשתי ב-TCP... כמובן, אף אחד לא אמר לי: “יורי, על מה אתה מדבר! אתה לא יכול, אתה צריך UDP." התברר ש-TCP לא כל כך מפחיד. הדבר היחיד הוא שאם יש לך עשרות אלפי תרכובות פעילות שאתה כותב, אתה צריך להכין את זה קצת יותר בזהירות; אבל זה אפשרי, ודי קל.

הבטחתי לפרסם את "קייטנהאוס" ו"מגדלור" ב-HighLoad Siberia אם כולם יירשמו ל-"VK backend" הציבורי שלנו... ואתה יודע, לא כולם נרשמו... כמובן, אני לא אדרוש ממך להירשם למנוי שלנו פּוּמְבֵּי. עדיין יש יותר מדי מכם, אולי מישהו אפילו נעלב, אבל בכל זאת, בבקשה הירשמו (וכאן אני חייב לעשות עיניים כמו של חתול). זה קישור אליו דרך אגב. תודה רבה לך! Github הוא שלנו כאן. עם Clickhouse השיער שלך יהיה רך ומשיי.

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

יורי נסרדינוב (להלן י"נ): - איך הצלחת להקליט את הדיווח שלי ב-VHS אם זה רק הסתיים?

עופרת: - גם אתה לא יכול לקבוע באופן מלא איך "קליקהאוס" יעבוד או לא! חברים, 5 דקות לשאלות!

שאלות

שאלה מהקהל (להלן ש'): - אחר הצהריים טובים. תודה רבה על הדיווח. יש לי שתי שאלות. אתחיל במשהו קל דעת: האם מספר האותיות t בשם "בית חתולים" בתרשימים (3, 4, 7...) משפיע על שביעות הרצון של החתולים?

YN: - כמות של מה?

З: – אות ט. יש שלושה ת', איפשהו בסביבות שלוש ת'.

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

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

YN: - כן.

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

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

З: – כלומר, "קייטנהאוס" מחזיק את החלון זמן רב יותר ובמקרה של נפילה יכול לזהות אותו ולגלגל אותו לאחור?

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

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

YN: - במה אנו משתמשים ב-TCP?

З: - בעיקרון כן.

YN: לא.

З: – עם fasthttp היו לך בעיות, עם החיבור היו לך בעיות. אם רק היית משתמש ב-UDP היית חוסך לעצמך קצת זמן. ובכן, יהיו בעיות עם הודעות ארוכות או משהו אחר...

YN: - עם מה?

З: – עם הודעות ארוכות, מכיוון שזה אולי לא מתאים ל-MTU, משהו אחר... ובכן, יכול להיות שיש בעיות משלהם. השאלה היא: למה לא UDP?

YN: – אני מאמין שהכותבים שפיתחו TCP/IP הרבה יותר חכמים ממני ויודעים יותר טוב ממני איך לעשות סדרת מנות (כדי שילכו), במקביל להתאים את חלון השליחה, לא להעמיס על הרשת, לתת משוב על מה לא נקרא, לא סופר בצד השני... כל הבעיות האלה, לדעתי, יהיו קיימות ב-UDP, רק שאצטרך לכתוב אפילו יותר קוד ממה שכבר כתבתי כדי ליישם את אותו הדבר בעצמי וסביר להניח בצורה גרועה. אני אפילו לא ממש אוהב לכתוב ב-C, שלא לדבר על שם...

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

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

З: - אני לא אבזבז זמן. צריך לדון בזה יותר. תודה.

עופרת: – למי יש שאלות – ידיים לשמיים!

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

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

З: "אבל בסופו של דבר זה יצא ככה בכל מקרה."

YN: – לא, אין מארחים! כל זה עובד על מארחי Clickhouse.

З: - ובכן, ו-"Kittenhouse", שזה הפוך - איפה הוא גר?

YN: - במארח Clickhouse, הוא לא כותב דבר לדיסק.

З: בוא נניח.

עופרת: - האם אתה מרוצה? אפשר לתת לך משכורת?

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

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

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

YN: - בבקשה הצע באילו תורים ניתן להשתמש?

З: – כל, גם ללא ערובה שהם תקינים. סוג של Redis, RMQ...

YN: – יש לי הרגשה שסביר להניח ש-Redis לא תוכל למשוך נפח כזה של הכנסה אפילו על מארח אחד (במובן של מספר שרתים) ששולף את Clickhouse. אני לא יכול לגבות את זה בשום ראיה (לא בדקתי את זה), אבל נראה לי שרדיס הוא לא הפתרון הטוב ביותר כאן. באופן עקרוני, מערכת זו יכולה להיחשב כתור הודעות מאולתר, אך היא מותאמת רק עבור "Clickhouse"

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

YN: – אני רוצה לתת ספר לאדם הראשון ששאל שאלה.

עופרת: - נפלא! גדול! מהמם! תודה רבה!

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, 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