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-ში არის ის, რასაც სხვები უწოდებენ მიკროსერვისებს. და აი, მომღიმარი სტიკერი (საკმაოდ ბევრი მოწონება). Როგორ თუ? აბა, მოუსმინეთ შემდგომ!

რა შეიძლება გამოყენებულ იქნას მორების შესანახად? შეუძლებელია არ ვახსენო ჰადუფი. შემდეგ, მაგალითად, Rsyslog (ამ ჟურნალების შენახვა ფაილებში). LSD. ვინ იცის რა არის LSD? არა, ეს LSD არა. შეინახეთ ფაილები, შესაბამისად, ასევე. ისე, ClickHouse უცნაური ვარიანტია.

Clickhouse და კონკურენტები: მოთხოვნები და შესაძლებლობები

რა გვინდა? ჩვენ გვინდა უზრუნველვყოთ, რომ არ გვქონდეს ზედმეტად ფიქრი ოპერაციის შესახებ, რათა ის იმუშაოს ყუთიდან, სასურველია მინიმალური კონფიგურაციით. ჩვენ გვინდა ბევრი დავწეროთ და სწრაფად დავწეროთ. და ჩვენ გვინდა შევინარჩუნოთ იგი ყველა სახის თვის, წლის განმავლობაში, ანუ დიდი ხნის განმავლობაში. ჩვენ შეიძლება გვსურს გავიგოთ პრობლემა, რომლითაც ისინი მოვიდნენ ჩვენთან და თქვეს: „აქ რაღაც არ მუშაობს“ და ეს იყო 3 თვის წინ), და გვსურს შეგვეძლოს დავინახოთ რა მოხდა 3 თვის წინ. მონაცემთა შეკუმშვა - გასაგებია, რატომ იქნება ეს პლუსი - რადგან ამცირებს მის მიერ დაკავებულ ადგილს.

და ჩვენ გვაქვს ასეთი საინტერესო მოთხოვნა: ჩვენ ზოგჯერ ვწერთ ზოგიერთი ბრძანების (მაგალითად, ჟურნალის) გამოსავალს, ის შეიძლება იყოს 4 კილობაიტზე მეტი საკმაოდ მარტივად. და თუ ეს რამ მუშაობს UDP-ზე, მაშინ მას არ სჭირდება დახარჯვა... მას არ ექნება რაიმე "ზედნადები" კავშირისთვის და სერვერების დიდი რაოდენობით ეს იქნება პლუსი.

ვნახოთ რას გვთავაზობს ღია წყარო. პირველ რიგში, ჩვენ გვაქვს Logs Engine - ეს არის ჩვენი ძრავა; პრინციპში ყველაფერი შეუძლია, გრძელი სტრიქონების წერაც კი შეუძლია. ისე, ის არ ახდენს მონაცემების გამჭვირვალედ შეკუმშვას - ჩვენ შეგვიძლია შევკუმშოთ დიდი სვეტები, თუ გვინდა... ჩვენ, რა თქმა უნდა, არ გვინდა (თუ ეს შესაძლებელია). ერთადერთი პრობლემა ის არის, რომ მას შეუძლია გასცეს მხოლოდ ის, რაც მის მეხსიერებაში ჯდება; დანარჩენის წასაკითხად ამ ძრავის ბინლოგი უნდა მიიღოთ და, შესაბამისად, საკმაოდ დიდი დრო სჭირდება.

სხვა რა ვარიანტები არსებობს? მაგალითად, "Hadup". მუშაობის სიმარტივე... ვინ ფიქრობს, რომ Hadup ადვილი დასაყენებელია? რა თქმა უნდა, ჩაწერის პრობლემა არ არის. კითხვისას ზოგჯერ ჩნდება კითხვები. პრინციპში, მე ვიტყოდი, ალბათ არა, განსაკუთრებით ლოგინებისთვის. გრძელვადიანი შენახვა - რა თქმა უნდა, დიახ, მონაცემთა შეკუმშვა - დიახ, გრძელი სტრიქონები - გასაგებია, რომ შეგიძლიათ ჩაწეროთ. მაგრამ ჩაწერა სერვერების დიდი რაოდენობით... თქვენ მაინც უნდა გააკეთოთ რაღაც თავად!

Rsyslog. ფაქტობრივად, სარეზერვო ვარიანტად ვიყენებდით, რომ ბინლოგის გადაყრის გარეშე შეგვეძლო წაკითხვა, მაგრამ გრძელ ხაზებს ვერ წერს, პრინციპში 4 კილობაიტზე მეტს ვერ წერს. თქვენ თავად უნდა გააკეთოთ მონაცემთა შეკუმშვა იმავე გზით. წაკითხვა მოხდება ფაილებიდან.

შემდეგ არის LSD-ის „ბადუშკას“ განვითარება. არსებითად იგივეა, რაც "Rsyslog": ის მხარს უჭერს გრძელ სტრიქონებს, მაგრამ ის ვერ მუშაობს UDP-ის საშუალებით და, ფაქტობრივად, ამის გამო, სამწუხაროდ, იქ საკმაოდ ბევრი რამის გადაწერაა საჭირო. LSD-ს ხელახალი დიზაინი სჭირდება, რათა შეძლოს ჩაწერა ათიათასობით სერვერიდან.

Და აქ! სასაცილო ვარიანტია ElasticSearch. Როგორ ვთქვა? კითხვაში კარგად ეხერხება, ანუ სწრაფად კითხულობს, მაგრამ წერაში არც ისე კარგად. ჯერ ერთი, თუ ის შეკუმშავს მონაცემებს, ძალიან სუსტია. სავარაუდოდ, სრული ძებნა მოითხოვს უფრო დიდ მონაცემთა სტრუქტურებს, ვიდრე ორიგინალური მოცულობა. ძნელია მუშაობა და პრობლემები ხშირად წარმოიქმნება მასთან. და ისევ, ელასტიკაში ჩაწერა - ჩვენ თვითონ უნდა გავაკეთოთ ყველაფერი.

აქ ClickHouse იდეალური ვარიანტია, რა თქმა უნდა. ერთადერთი ის არის, რომ ათიათასობით სერვერიდან ჩაწერა პრობლემაა. მაგრამ მაინც არის ერთი პრობლემა, ჩვენ შეგვიძლია ვცადოთ მისი გადაჭრა როგორმე. მოხსენების დანარჩენი ნაწილი კი ამ პრობლემას ეხება. რა სახის შესრულებას შეიძლება ელოდოთ ClickHouse-ისგან?

როგორ ვაპირებთ მის ჩასმას? MergeTree

ვის არ სმენია ან არ იცის "ClickHouse"-ის შესახებ? უნდა გითხრა, არა? Ძალიან სწრაფად. იქ ჩასმა - 1-2 გიგაბიტი წამში, აფეთქებები 10 გიგაბიტამდე წამში, რეალურად გაუძლებს ამ კონფიგურაციას - არის ორი 6 ბირთვიანი ქსონი (ანუ ყველაზე ძლიერიც კი), 256 გიგაბაიტი ოპერატიული მეხსიერება, 20 ტერაბაიტი. RAID-ში (არავინ კონფიგურირებულია, ნაგულისხმევი პარამეტრები). ალექსეი მილოვიდოვი, ClickHouse-ის დეველოპერი, ალბათ იქ ზის და ტირის, რადგან ჩვენ არაფერი დავაკონფიგურირეთ (ყველაფერი ასე მუშაობდა ჩვენთან). შესაბამისად, სკანირების სიჩქარე, ვთქვათ, დაახლოებით 6 მილიარდი ხაზი წამში შეიძლება მიღებულ იქნას, თუ მონაცემები კარგად არის შეკუმშული. თუ მოგწონთ % ტექსტის სტრიქონზე - 100 მილიონი სტრიქონი წამში, ანუ ის საკმაოდ სწრაფი ჩანს.

როგორ ვაპირებთ მის ჩასმას? კარგად, თქვენ იცით, რომ VK იყენებს PHP-ს. ჩვენ ჩავსვამთ თითოეული PHP მუშაკიდან HTTP-ის საშუალებით „ClickHouse“-ში, MergeTree ცხრილში თითოეული ჩანაწერისთვის. ვინ ხედავს პრობლემას ამ სქემაში? რატომღაც ყველამ არ ასწია ხელი. ნება მომეცით გითხრათ.

ჯერ ერთი, ბევრი სერვერია - შესაბამისად, იქნება ბევრი კავშირი (ცუდი). მაშინ უმჯობესია მონაცემების ჩასმა MergeTree-ში არა უმეტეს წამში ერთხელ. და ვინ იცის რატომ? Კარგი კარგი. ამაზე ცოტა მეტს გეტყვით. კიდევ ერთი საინტერესო კითხვა არის ის, რომ ჩვენ არ ვაკეთებთ ანალიტიკას, არ გვჭირდება მონაცემების გამდიდრება, არ გვჭირდება შუალედური სერვერები, გვინდა პირდაპირ „ClickHouse“-ში ჩავსვათ (სასურველია - რაც უფრო პირდაპირ, მით უკეთესი).

შესაბამისად, როგორ ხდება ჩასმა MergeTree-ში? რატომ არის უკეთესი მასში ჩასმა არა უმეტეს წამში ერთხელ ან ნაკლებად ხშირად? ფაქტია, რომ "ClickHouse" არის სვეტოვანი მონაცემთა ბაზა და ახარისხებს მონაცემებს პირველადი გასაღების ზრდადი თანმიმდევრობით, ხოლო ჩასმისას იქმნება ფაილების რაოდენობა, მინიმუმ იმ სვეტების რაოდენობის ტოლი, რომლებშიც დალაგებულია მონაცემები. პირველადი გასაღების აღმავალი თანმიმდევრობით (შეიქმნება ცალკე დირექტორია, ფაილების ნაკრები დისკზე თითოეული ჩასართისთვის). შემდეგ მოდის შემდეგი ჩასმა და ფონზე ისინი გაერთიანებულია უფრო დიდ "ტიხრებში". ვინაიდან მონაცემები დალაგებულია, შესაძლებელია ორი დახარისხებული ფაილის „შერწყმა“ მეხსიერების დიდი მოხმარების გარეშე.

მაგრამ, როგორც თქვენ ალბათ მიხვდებით, თუ თქვენ დაწერთ 10 ფაილს თითოეული ჩანართისთვის, მაშინ ClickHouse (ან თქვენი სერვერი) სწრაფად დასრულდება, ამიტომ რეკომენდებულია დიდი პარტიების ჩასმა. შესაბამისად, პირველი სქემა წარმოებაში არასოდეს გაგვიშვებია. ჩვენ მაშინვე გავუშვით ერთი, რომელიც აქ No2 აქვს:

აქ წარმოიდგინეთ, რომ დაახლოებით ათასი სერვერია, რომელზედაც ჩვენ გავუშვით, არის მხოლოდ PHP. და თითოეულ სერვერზე არის ჩვენი ადგილობრივი აგენტი, რომელსაც ჩვენ ვუწოდეთ "Kittenhouse", რომელიც ინარჩუნებს ერთ კავშირს "ClickHouse"-თან და ათავსებს მონაცემებს ყოველ რამდენიმე წამში. ათავსებს მონაცემებს არა MergeTree-ში, არამედ ბუფერულ ცხრილში, რომელიც ემსახურება ზუსტად MergeTree-ში უშუალოდ ჩასმის თავიდან აცილებას.

ბუფერულ ცხრილებთან მუშაობა

რა არის ეს? ბუფერული ცხრილები არის მეხსიერების ნაწილი, რომელიც გახეხილია (ანუ მასში ხშირად შეიძლება ჩასვა). ისინი შედგება რამდენიმე ნაწილისგან და თითოეული ცალი მუშაობს როგორც დამოუკიდებელი ბუფერი და ისინი დამოუკიდებლად ირეცხება (თუ ბუფერში ბევრი ცალი გაქვთ, მაშინ იქნება ბევრი ჩასმა წამში). ამ ცხრილებიდან წაკითხვა შესაძლებელია - შემდეგ კითხულობთ ბუფერისა და მშობლის ცხრილის შიგთავსის გაერთიანებას, მაგრამ ამ მომენტში ჩაწერა დაბლოკილია, ამიტომ ჯობია არ წაიკითხოთ იქიდან. და ბუფერული ცხრილები აჩვენებს ძალიან კარგ QPS-ს, ანუ 3 ათასამდე QPS-მდე საერთოდ არ შეგექმნებათ პრობლემა ჩასმისას. გასაგებია, რომ თუ სერვერი კარგავს ენერგიას, მაშინ მონაცემები შეიძლება დაიკარგოს, რადგან ის მხოლოდ მეხსიერებაში იყო შენახული.

ამავდროულად, სქემა ბუფერთან ერთად ართულებს ALTER-ს, რადგან თქვენ ჯერ უნდა ჩამოაგდოთ ძველი ბუფერული ცხრილი ძველი სქემით (მონაცემები არსად გაქრება, რადგან ცხრილის წაშლამდე გაქრება). შემდეგ თქვენ „ცვლით“ საჭირო ცხრილს და კვლავ შექმნით ბუფერულ ცხრილს. შესაბამისად, სანამ არ არის ბუფერული ცხრილი, თქვენი მონაცემები არსად არ შემოვა, მაგრამ შეგიძლიათ დისკზე გქონდეთ მინიმუმ ადგილობრივად.

რა არის Kittenhouse და როგორ მუშაობს?

რა არის KittenHouse? ეს არის მარიონეტული. გამოიცანით რა ენაზე? ყველაზე მეტი აჟიოტაჟის თემები შევაგროვე ჩემს მოხსენებაში - "Clickhouse", წადი, იქნებ სხვა რამე გამახსენდეს. დიახ, ეს წერია Go-ში, რადგან მე ნამდვილად არ ვიცი როგორ დავწერო C-ზე, არ მინდა.

შესაბამისად, ის ინარჩუნებს კავშირს თითოეულ სერვერთან და შეუძლია ჩაწეროს მეხსიერებაში. მაგალითად, თუ Clickhouse-ში ჩავწერთ შეცდომის ჟურნალებს, მაშინ თუ Clickhouse-ს არ აქვს დრო მონაცემების ჩასართავად (ბოლოს და ბოლოს, თუ ძალიან ბევრია დაწერილი), მაშინ მეხსიერებას არ გავდიდებთ - უბრალოდ, დანარჩენს ვყრით. იმის გამო, რომ თუ ჩვენ დავწერთ რამდენიმე გიგაბიტს წამში შეცდომებს, მაშინ, ალბათ, შეგვიძლია გადავაგდოთ რამდენიმე. Kittenhouse-ს შეუძლია ამის გაკეთება. გარდა ამისა, მას შეუძლია შეასრულოს საიმედო მიწოდება, ანუ ჩაწეროს დისკზე ადგილობრივ აპარატზე და ყოველ ჯერზე (იქ, ყოველ რამდენიმე წამში ერთხელ) ცდილობს ამ ფაილიდან მონაცემების მიწოდებას. და თავიდან ჩვენ გამოვიყენეთ რეგულარული ღირებულებების ფორმატი - არა ორობითი ფორმატი, ტექსტის ფორმატი (როგორც ჩვეულებრივ SQL-ში).

მაგრამ შემდეგ ეს მოხდა. გამოვიყენეთ სანდო მიწოდება, დავწერეთ ლოგები, მერე გადავწყვიტეთ (პირობითი სატესტო კლასტერი იყო)... რამდენიმე საათი იყო გამოტანილი და უკან წამოსული და ათასობით სერვერიდან დაიწყო ჩასმა - აღმოჩნდა, რომ Clickhouse-ს ჯერ კიდევ ჰქონდა "ძაფი კავშირზე" - შესაბამისად, ათას კავშირში აქტიური ჩასმა იწვევს სერვერზე საშუალო დატვირთვას დაახლოებით ერთი და ნახევარი ათასი. გასაკვირია, რომ სერვერმა მიიღო მოთხოვნები, მაგრამ მონაცემები მაინც ჩასმული იყო გარკვეული დროის შემდეგ; მაგრამ სერვერს ძალიან გაუჭირდა მისი მომსახურება...

დაამატეთ nginx

ასეთი გადაწყვეტა Thread თითო კავშირის მოდელისთვის არის nginx. ჩვენ დავაინსტალირეთ nginx Clickhouse-ის წინ, ამავდროულად დავაყენეთ ბალანსი ორი რეპლიკისთვის (ჩვენი ჩასმის სიჩქარე გაიზარდა 2-ჯერ, თუმცა ფაქტი არ არის, რომ ასე უნდა იყოს) და შევზღუდეთ კავშირების რაოდენობა Clickhouse-თან მხოლოდ ზემოთ და, შესაბამისად, მეტი, ვიდრე 50 კავშირში, როგორც ჩანს, ჩასმას აზრი არ აქვს.

შემდეგ მივხვდით, რომ ამ სქემას ზოგადად აქვს უარყოფითი მხარეები, რადგან აქ მხოლოდ ერთი nginx გვაქვს. შესაბამისად, თუ ეს nginx დაიშლება, მიუხედავად რეპლიკების არსებობისა, ჩვენ ვკარგავთ მონაცემებს ან, ყოველ შემთხვევაში, არსად არ ვწერთ. სწორედ ამიტომ, ჩვენ გავაკეთეთ საკუთარი დატვირთვის დაბალანსება. ჩვენ ასევე მივხვდით, რომ "კლიკჰაუსი" ჯერ კიდევ შესაფერისია მორებისთვის და "დემონმა" ასევე დაიწყო თავისი მორების დაწერა "კლიკჰაუსში" - ძალიან მოსახერხებელია, მართალი გითხრათ. ჩვენ კვლავ ვიყენებთ მას სხვა "დემონებისთვის".

შემდეგ აღმოვაჩინეთ ეს საინტერესო პრობლემა: თუ იყენებთ SQL რეჟიმში ჩასმის არასტანდარტულ მეთოდს, ეს აიძულებს სრულფასოვან AST-ზე დაფუძნებულ SQL პარსერს, რომელიც საკმაოდ ნელია. შესაბამისად, ჩვენ დავამატეთ პარამეტრები, რათა ეს არასოდეს მოხდეს. ჩავატარეთ დატვირთვის დაბალანსება, ჯანმრთელობის შემოწმებები, რომ თუ ვინმე მოკვდება, ჩვენ მაინც დავტოვებთ მონაცემებს. ახლა ჩვენ გვაქვს საკმაოდ ბევრი ცხრილი, რომელიც უნდა გვქონდეს სხვადასხვა Clickhouse კლასტერები. ჩვენ ასევე დავიწყეთ ფიქრი სხვა გამოყენებაზე - მაგალითად, გვინდოდა ჩაგვეწერა ჟურნალები nginx მოდულებიდან, მაგრამ მათ არ იციან როგორ დაუკავშირდნენ ჩვენი RPC-ს გამოყენებით. ისე, მინდა ვასწავლო მათ როგორმე მაინც გაგზავნონ - მაგალითად, მიიღონ მოვლენები ლოკალჰოსტზე UDP-ის საშუალებით და შემდეგ გადააგზავნონ Clickhouse-ში.

გადაწყვეტიდან ერთი ნაბიჯია

საბოლოო სქემა ასე დაიწყო (ამ სქემის მეოთხე ვერსია): თითოეულ სერვერზე Clickhouse-ის წინ არის nginx (იგივე სერვერზე) და ის უბრალოდ აგზავნის ლოკალჰოსტის მოთხოვნებს 50 კავშირების რაოდენობის შეზღუდვით. ნაჭრები. და ეს სქემა უკვე საკმაოდ მუშაობდა, ყველაფერი საკმაოდ კარგი იყო მასთან.

დაახლოებით ერთი თვე ასე ვიცხოვრეთ. ყველას გაუხარდა, დაამატეს ცხრილები, დაამატეს, დაამატეს... ზოგადად, ისე გამოვიდა, რომ ბუფერული ცხრილების დამატება არც თუ ისე ოპტიმალური იყო (მოდი ასე ვთქვათ). ჩვენ გავაკეთეთ 16 ცალი თითოეულ მაგიდაზე და ფლეშ ინტერვალით რამდენიმე წამი; ჩვენ გვქონდა 20 ცხრილი და თითო ცხრილი იღებდა 8 ჩანართს წამში - და ამ დროს დაიწყო "Clickhouse"... ჩანაწერებმა შენელება დაიწყო. არამარტო არ გაიარეს... ნაგულისხმევად, nginx-ს ჰქონდა ისეთი საინტერესო რამ, რომ თუ კავშირები სრულდებოდა ზემოთ, მაშინ ის უბრალოდ უბრუნებდა "502"-ს ყველა ახალ მოთხოვნას.

და აი, ჩვენ გვაქვს (მე უბრალოდ გადავხედე ჟურნალებს თავად Clickhouse-ში) მოთხოვნის დაახლოებით ნახევარი პროცენტი ვერ მოხერხდა. შესაბამისად, დისკის უტილიზაცია იყო მაღალი, იყო ბევრი შერწყმა. აბა, რა გავაკეთე? ბუნებრივია, არ შევწუხდი იმის გარკვევაში, თუ რატომ დასრულდა ზუსტად კავშირი და ზემოქმედება.

nginx-ის შეცვლა საპირისპირო პროქსით

მე გადავწყვიტე, რომ ეს ჩვენ თვითონ უნდა მოვახერხოთ, არ გვჭირდება nginx-ისთვის მიტოვება - nginx-მა არ იცის რა ცხრილებია Clickhouse-ში და nginx შევცვალე საპირისპირო პროქსით, რომელიც მეც დავწერე.

Რას აკეთებს? ის მუშაობს fasthttp ბიბლიოთეკის "goshnoy" საფუძველზე, ანუ სწრაფად, თითქმის ისევე სწრაფად, როგორც nginx. უკაცრავად, იგორ, თუ აქ ხართ (შენიშვნა: იგორ სისოევი რუსი პროგრამისტია, რომელმაც შექმნა nginx ვებ სერვერი). მას შეუძლია გაიგოს, რა სახის მოთხოვნებია ეს - INSERT ან SELECT - შესაბამისად, მას აქვს სხვადასხვა კავშირის აუზი სხვადასხვა ტიპის მოთხოვნებისთვის.

შესაბამისად, იმ შემთხვევაშიც კი, თუ დრო არ გვექნება ჩასმის მოთხოვნების დასასრულებლად, „არჩევანი“ გაივლის და პირიქით. და ის აჯგუფებს მონაცემებს ბუფერულ ცხრილებში - პატარა ბუფერით: თუ იყო რაიმე შეცდომა, სინტაქსის შეცდომები და ა. ჰქონდა პატარა "ბაჩი" და ყველა სინტაქსური შეცდომა მხოლოდ ამ პატარა ნაწილს შეეხო; და აქ ისინი უკვე იმოქმედებენ დიდ ბუფერზე. პატარა არის 1 მეგაბაიტი, ანუ არც ისე პატარა.

სინქრონიზაციის ჩასმა და nginx-ის არსებითად ჩანაცვლება, არსებითად იგივეს აკეთებს, რასაც ადრე აკეთებდა nginx - ამისათვის არ გჭირდებათ ადგილობრივი "Kittenhouse"-ის შეცვლა. და რადგან ის იყენებს fasthttp-ს, ის ძალიან სწრაფია - შეგიძლიათ გააკეთოთ 100 ათასზე მეტი მოთხოვნა წამში ერთჯერადი ჩანართებისთვის საპირისპირო პროქსის საშუალებით. თეორიულად, თქვენ შეგიძლიათ ჩასვათ თითო ხაზი კნუტის სახლის საპირისპირო პროქსიში, მაგრამ რა თქმა უნდა, ჩვენ ამას არ ვაკეთებთ.

სქემა ასე დაიწყო: "Kittenhouse", საპირისპირო პროქსი აჯგუფებს ბევრ მოთხოვნას ცხრილებში და, თავის მხრივ, ბუფერული ცხრილები ჩასვით მათ მთავარში.

მკვლელი დროებითი გამოსავალია, კნუტი მუდმივი

საინტერესო პრობლემაა... ვინმეს თუ გამოგიყენებიათ fasthttp? ვინ გამოიყენა fasthttp POST მოთხოვნებთან ერთად? ალბათ, ეს ნამდვილად არ უნდა გაკეთებულიყო, რადგან ის სტანდარტულად აფერხებს მოთხოვნის სხეულს და ჩვენი ბუფერის ზომა დაყენებული იყო 16 მეგაბაიტზე. ჩასმა რაღაც მომენტში შეწყვიტა და 16 მეგაბაიტიანი ნაწილაკები ათიათასობით სერვერიდან მოვიდა და ისინი ყველა ბუფერული იყო მეხსიერებაში, სანამ გაიგზავნებოდნენ Clickhouse-ში. შესაბამისად, მეხსიერება ამოიწურა, მოვიდა Out-Of-Memory Killer და მოკლა საპირისპირო პროქსი (ან „Clickhouse“, რომელსაც თეორიულად შეეძლო „შეჭამა“ მეტი, ვიდრე საპირისპირო პროქსი). ციკლი განმეორდა. არც ისე სასიამოვნო პრობლემაა. თუმცა ჩვენ ამას წავაწყდით მხოლოდ რამდენიმე თვის მუშაობის შემდეგ.

Რა გავაკეთე? ისევ და ისევ, მე ნამდვილად არ მომწონს იმის გაგება, თუ რა მოხდა. ვფიქრობ, საკმაოდ აშკარაა, რომ მეხსიერებაში ბუფერული არ უნდა იყოს. სწრაფი http ვერ დავაყენე, თუმცა ვცადე. მაგრამ მე ვიპოვე გზა, რომ ასე გამეკეთებინა, რომ არაფრის დაყენება არ დამჭირვებოდა და HTTP-ში ჩემი მეთოდი მოვიფიქრე - მას KITTEN დავარქვი. ისე, ლოგიკურია - "VK", "Kitten"... კიდევ რა?..

თუ სერვერზე მოთხოვნა მოდის Kitten მეთოდით, მაშინ სერვერმა უნდა უპასუხოს "meow" - ლოგიკურად. თუ ამაზე პასუხობს, მაშინ ითვლება, რომ მას ესმის ეს პროტოკოლი და მე ჩავჭრი კავშირს (fasthttp-ს აქვს ასეთი მეთოდი) და კავშირი გადადის "raw" რეჟიმში. რატომ მჭირდება? მე მინდა გავაკონტროლო, თუ როგორ ხდება კითხვა TCP კავშირებიდან. TCP-ს აქვს შესანიშნავი თვისება: თუ არავინ კითხულობს მეორე მხრიდან, მაშინ ჩაწერა იწყებს ლოდინს და მეხსიერება განსაკუთრებით არ იხარჯება ამაზე.

ასე რომ, მე ერთდროულად ვკითხულობდი დაახლოებით 50 კლიენტს (ორმოცდაათიდან, რადგან ორმოცდაათი აუცილებლად საკმარისი უნდა იყოს, თუნდაც ეს მაჩვენებელი სხვა DC-დან მოდის)... ამ მიდგომით მოხმარება შემცირდა მინიმუმ 20-ჯერ, მაგრამ მე, მართალი გითხრათ. , ზუსტად ვერ გავზომე რა დრო, რადგან უკვე უაზროა (უკვე შეცდომის დონეს მიაღწია). პროტოკოლი ორობითია, ანუ შეიცავს ცხრილის სახელს და მონაცემებს; არ არსებობს http სათაურები, ამიტომ მე არ გამოვიყენე ვებ სოკეტი (არ მჭირდება ბრაუზერებთან კომუნიკაცია - მე გავაკეთე პროტოკოლი, რომელიც შეესაბამება ჩვენს საჭიროებებს). და ყველაფერი კარგად იყო მასთან.

ბუფერული მაგიდა სევდიანია

ახლახან შევხვდით ბუფერული ცხრილების კიდევ ერთ საინტერესო მახასიათებელს. და ეს პრობლემა უკვე ბევრად უფრო მტკივნეულია, ვიდრე სხვები. წარმოვიდგინოთ ეს სიტუაცია: თქვენ უკვე აქტიურად იყენებთ Clickhouse-ს, გაქვთ ათობით Clickhouse სერვერი და გაქვთ გარკვეული მოთხოვნები, რომელთა წაკითხვას ძალიან დიდი დრო სჭირდება (ვთქვათ, 60 წამზე მეტი); და შენ მოდი და აკეთებ Alter-ს ამ მომენტში... ამასობაში, "სელექტები", რომლებიც "Alter"-მდე დაიწყო, არ იქნება ამ ცხრილში, "Alter" არ დაიწყება - ალბათ ზოგიერთი ფუნქცია, თუ როგორ მუშაობს "Clickhouse"-ში. ეს ადგილი. იქნებ ეს გამოსწორდეს? ანუ შეუძლებელია?

ზოგადად, გასაგებია, რომ სინამდვილეში ეს არც ისე დიდი პრობლემაა, მაგრამ ბუფერული ცხრილებით ეს უფრო მტკივნეული ხდება. იმიტომ, რომ, თუ, ვთქვათ, თქვენი „Alter“-ის დრო ამოიწურა (და შეიძლება სხვა ჰოსტზე გასულიყო - არა თქვენზე, არამედ რეპლიკაზე, მაგალითად), მაშინ... თქვენ წაშალეთ ბუფერული ცხრილი, თქვენი „Alter“ ( ან სხვა ჰოსტს) ამოიწურა. შემდეგ მოხდა "Alter" შეცდომა) - თქვენ ჯერ კიდევ უნდა დარწმუნდეთ, რომ მონაცემები კვლავ ჩაიწერება: თქვენ ქმნით ბუფერულ ცხრილებს უკან (იგივე სქემის მიხედვით, როგორც მშობელი ცხრილი), შემდეგ "Alter" გადის, ბოლოს და ბოლოს მთავრდება და ბუფერი ცხრილი იწყებს სქემით განსხვავდება მშობლისგან. იმისდა მიხედვით, თუ რა იყო "Alter", ჩანართი შეიძლება აღარ მოხვდეს ამ ბუფერულ ცხრილში - ეს ძალიან სამწუხაროა.

ასევე არის ასეთი ნიშანი (შეიძლება ვინმემ შეამჩნია) - მას Query_thread_log ჰქვია Clickhouse-ის ახალ ვერსიებში. სტანდარტულად, ზოგიერთ ვერსიაში იყო ერთი. აქ ჩვენ დავაგროვეთ 840 მილიონი ჩანაწერი რამდენიმე თვეში (100 გიგაბაიტი). ეს იმით არის განპირობებული, რომ იქ „ჩანართები“ ეწერა (შეიძლება ახლა, სხვათა შორის, არ იწერება). როგორც გითხარით, ჩვენი "ჩანართები" მცირეა - ჩვენ გვქონდა ბევრი "ჩანართები" ბუფერულ ცხრილებში. გასაგებია, რომ ეს გამორთულია - მე უბრალოდ გეტყვით იმას, რაც ვნახე ჩვენს სერვერზე. რატომ? ეს არის კიდევ ერთი არგუმენტი ბუფერული ცხრილების გამოყენების წინააღმდეგ! სპოტი ძალიან სევდიანია.

ვინ იცოდა, რომ ამ ბიჭს სპოტი ერქვა? VK-ის თანამშრომლებმა ხელები ასწიეს. ᲙᲐᲠᲒᲘ.

"KitttenHouse"-ის გეგმების შესახებ

გეგმები ჩვეულებრივ არ არის გაზიარებული, არა? მოულოდნელად თქვენ არ შეასრულებთ მათ და არც ისე კარგად გამოიყურებით სხვა ადამიანების თვალში. მაგრამ რისკზე წავალ! ჩვენ გვინდა გავაკეთოთ შემდეგი: ბუფერული ცხრილები, მეჩვენება, ჯერ კიდევ ყავარჯენია და ჩვენ თვითონ გვჭირდება ბუფერული ჩასმა. მაგრამ ჩვენ ჯერ კიდევ არ გვინდა მისი ბუფერირება დისკზე, ამიტომ ჩასმას მეხსიერებაში ბუფერული გავატარებთ.

შესაბამისად, როდესაც „ჩასმა“ კეთდება, ის აღარ იქნება სინქრონული - ის უკვე იმუშავებს როგორც ბუფერული ცხრილი, ჩასვამს მთავარ ცხრილში (კარგად, ერთ დღეს) და ცალკე არხით აცნობებს, რომელმა ჩანართებმა გაიარა და რომელი. არ ქონა.

რატომ არ შემიძლია სინქრონული ჩანართის დატოვება? ბევრად უფრო მოსახერხებელია. ფაქტია, რომ 10 ათასი ჰოსტიდან რომ ჩასვა, მაშინ ყველაფერი კარგადაა - თითოეული ჰოსტისგან ცოტას მიიღებ, წამში ერთხელ ჩასვა, ყველაფერი კარგადაა. მაგრამ მე ვისურვებდი, რომ ეს სქემა იმუშაოს, მაგალითად, ორი აპარატიდან, ასე რომ თქვენ შეგიძლიათ ჩამოტვირთოთ მაღალი სიჩქარით - შესაძლოა არ მიიღოთ მაქსიმუმი Clickhouse-დან, მაგრამ დაწეროთ მინიმუმ 100 მეგაბაიტი წამში ერთი აპარატიდან საპირისპირო პროქსის საშუალებით - ეს სქემა უნდა გაფართოვდეს როგორც დიდ, ისე მცირე რაოდენობებზე, ასე რომ, ჩვენ არ შეგვიძლია დაველოდოთ წამს თითოეულ ჩასმაზე, ამიტომ ის უნდა იყოს ასინქრონული. და ანალოგიურად, ასინქრონული დადასტურებები უნდა მოვიდეს ჩასმის დასრულების შემდეგ. გავიგეთ, გავიდა თუ არა.

ყველაზე მნიშვნელოვანი ის არის, რომ ამ სქემაში ზუსტად ვიცით მოხდა თუ არა ჩასმა. წარმოიდგინეთ ეს სიტუაცია: თქვენ გაქვთ ბუფერული ცხრილი, ჩაწერეთ მასში რაღაც, შემდეგ კი, ვთქვათ, ცხრილი გადავიდა მხოლოდ წაკითხვის რეჟიმში და სცადეთ ბუფერის გასუფთავება. სად წავა მონაცემები? ისინი დარჩებიან ბუფერში. მაგრამ ამაში დარწმუნებული ვერ ვიქნებით - რა მოხდება, თუ რაიმე სხვა შეცდომაა, რის გამოც მონაცემები ბუფერში არ დარჩება... (მიმართავს ალექსეი მილოვიდოვს, Yandex, ClickHouse დეველოპერს) თუ დარჩება? ყოველთვის? ალექსეი გვარწმუნებს, რომ ყველაფერი კარგად იქნება. ჩვენ არ გვაქვს მიზეზი, რომ არ დავუჯეროთ მას. მაგრამ ერთი და იგივე: თუ ჩვენ არ გამოვიყენებთ ბუფერულ ცხრილებს, მაშინ მათთან არანაირი პრობლემა არ იქნება. ორჯერ მეტი ცხრილის შექმნაც მოუხერხებელია, თუმცა პრინციპში დიდი პრობლემები არ არის. ეს არის გეგმა.

მოდით ვისაუბროთ კითხვაზე

ახლა მოდით ვისაუბროთ კითხვაზე. ჩვენ ასევე დავწერეთ ჩვენი საკუთარი ინსტრუმენტი აქ. როგორც ჩანს, აბა, რატომ წერთ აქ საკუთარ ინსტრუმენტს?... და ვინ გამოიყენა ტაბიქსი? რატომღაც ცოტამ აწია ხელი... და ტაბიქსის შესრულებით ვინ არის კმაყოფილი? ჩვენ არ ვართ კმაყოფილი ამით და არც ისე მოსახერხებელია მონაცემების სანახავად. ეს კარგია ანალიტიკისთვის, მაგრამ მხოლოდ სანახავად აშკარად არ არის ოპტიმიზირებული. ასე რომ, მე დავწერე ჩემი საკუთარი ინტერფეისი.

ეს ძალიან მარტივია - მას შეუძლია მხოლოდ მონაცემების წაკითხვა. არ იცის გრაფიკის ჩვენება, არც არაფერი იცის. მაგრამ მას შეუძლია აჩვენოს ის, რაც გვჭირდება: მაგალითად, რამდენი მწკრივია ცხრილში, რამდენ ადგილს იკავებს ის (სვეტებად დაშლის გარეშე), ანუ ძალიან ძირითადი ინტერფეისი არის ის, რაც ჩვენ გვჭირდება.

და ის ძალიან ჰგავს Sequel Pro-ს, მაგრამ დამზადებულია მხოლოდ Twitter-ის Bootstrap-ზე და მეორე ვერსიაზე. თქვენ ჰკითხავთ: "იური, რატომ მეორე ვერსიაზე?" Რომელი წელი? 2018? ზოგადად, მე ეს გავაკეთე საკმაოდ დიდი ხნის წინ "Muscle"-სთვის (MySQL) და უბრალოდ შევცვალე რამდენიმე ხაზი იქ კითხვებში და მან დაიწყო მუშაობა "Clickhouse"-სთვის, რისთვისაც განსაკუთრებული მადლობა! იმის გამო, რომ პარსერი ძალიან ჰგავს "კუნთოვანს" და მოთხოვნები ძალიან ჰგავს - ძალიან მოსახერხებელია, განსაკუთრებით თავიდან.

კარგად, მას შეუძლია ცხრილების გაფილტვრა, ცხრილის სტრუქტურისა და შიგთავსის ჩვენება, საშუალებას გაძლევთ დაალაგოთ, გაფილტროთ სვეტების მიხედვით, აჩვენებს შეკითხვას, რომელმაც შედეგი გამოიღო, დაზარალებული რიგები (შედეგად რამდენი), ანუ ძირითადი რამ მონაცემების სანახავად. საკმაოდ სწრაფად.

არის რედაქტორიც. გულწრფელად ვცადე ტაბიქსისგან მთელი რედაქტორის მოპარვა, მაგრამ ვერ მოვახერხე. მაგრამ რატომღაც მუშაობს. პრინციპში სულ ესაა.

"კლიკჰაუსი" შესაფერისია ბუხრებისთვის

მინდა გითხრათ, რომ Clickhouse, მიუხედავად ყველა აღწერილი პრობლემისა, ძალიან კარგად შეეფერება ჟურნალებს. რაც მთავარია, ის აგვარებს ჩვენს პრობლემას - ის ძალიან სწრაფია და საშუალებას გაძლევთ გაფილტროთ ჟურნალები სვეტების მიხედვით. პრინციპში, ბუფერულმა ცხრილებმა კარგად ვერ შეასრულეს, მაგრამ, როგორც წესი, არავინ იცის რატომ... იქნებ ახლა უკეთ იცოდეთ სად შეგექმნებათ პრობლემები.

TCP? ზოგადად, VK– ში ჩვეულებრივია გამოიყენოთ UDP. და როცა TCP გამოვიყენე... რა თქმა უნდა, არავინ მითხრა: „იური, რას ლაპარაკობ! თქვენ არ შეგიძლიათ, გჭირდებათ UDP. ” აღმოჩნდა, რომ TCP არც ისე საშინელია. ერთადერთი ის არის, რომ თუ თქვენ გაქვთ ათიათასობით აქტიური ნაერთი, რომელსაც წერთ, ცოტა ფრთხილად უნდა მოამზადოთ; მაგრამ ეს შესაძლებელია და საკმაოდ მარტივია.

დავპირდი, რომ დავდებ "Kittenhouse"-ს და "Lighthouse-ს" HighLoad Siberia-ზე, თუ ყველა გამოიწერს ჩვენს საჯარო "VK backend-ს"... და იცით, ყველა არ გამოიწერებოდა... რა თქმა უნდა, არ მოვითხოვ, რომ ჩვენი გამოწერა. საჯარო. ჯერ კიდევ ძალიან ბევრი ხართ, შეიძლება ვინმემ განაწყენდეს კიდეც, მაგრამ მაინც გთხოვთ გამოიწეროთ (და აქ კატის თვალები უნდა გავაკეთო). ესე იგი სხვათა შორის, ლინკი. Ძალიან დიდი მადლობა! Github ჩვენია აქ. Clickhouse-ით თქვენი თმა რბილი და აბრეშუმისებრი გახდება.

მოდერატორი: - მეგობრებო, ახლა კითხვები. მას შემდეგ, რაც ჩვენ წარმოგიდგენთ მადლობის სერთიფიკატს და თქვენს მოხსენებას VHS-ზე.

იური ნასრეტდინოვი (შემდგომში YN): – როგორ მოახერხეთ ჩემი მოხსენების ჩაწერა VHS-ზე, თუ ის ახლახან დასრულდა?

მოდერატორი: – თქვენ ასევე ვერ განსაზღვრავთ, როგორ იმუშავებს თუ არა „კლიკჰაუსი“! მეგობრებო, 5 წუთი კითხვებისთვის!

კითხვები

აუდიტორიის შეკითხვა (შემდგომში Q): - Საღამო მშვიდობისა. დიდი მადლობა მოხსენებისთვის. ორი კითხვა მაქვს. დავიწყებ რაღაც არასერიოზულობით: გავლენას ახდენს თუ არა დიაგრამებში (3, 4, 7...) სახელწოდებაში „კნუტის სახლი“ ასოების t რიცხვი კატების კმაყოფილებაზე?

YN: - რა რაოდენობა?

ზ: - წერილი ტ. სამი t-ია, სადღაც სამი t-ია.

YN: - არ გამოვასწორე? კარგად, რა თქმა უნდა, ასეა! ეს სხვადასხვა პროდუქტებია - უბრალოდ მთელი ამ ხნის განმავლობაში მოგატყუებდი. კარგი, ვხუმრობ - არა უშავს. აჰ, სწორედ აქ! არა, იგივეა, შეცდომა დავუშვი.

ზ: - Გმადლობთ. მეორე კითხვა სერიოზულია. რამდენადაც მე მესმის, Clickhouse-ში ბუფერული ცხრილები ცხოვრობს ექსკლუზიურად მეხსიერებაში, არ არის ბუფერული დისკზე და, შესაბამისად, არ არის მუდმივი.

YN: - დიახ.

ზ: – და ამავდროულად, თქვენი კლიენტი ბუფერებს დისკზე, რაც გულისხმობს იმავე ჟურნალების მიწოდების გარკვეულ გარანტიას. მაგრამ ეს არავითარ შემთხვევაში არ არის გარანტირებული Clickhouse-ში. ახსენი გარანტია როგორ ხორციელდება, რის გამო?.. აი ეს მექანიზმი უფრო დეტალურად

YN: – დიახ, თეორიულად აქ წინააღმდეგობები არ არის, რადგან როდესაც Clickhouse დაეცემა, თქვენ შეგიძლიათ რეალურად ამოიცნოთ იგი მილიონობით სხვადასხვა გზით. თუ Clickhouse ავარიულია (თუ ის არასწორად მთავრდება), შეგიძლიათ, უხეშად რომ ვთქვათ, გადაახვიოთ თქვენი ჩაწერილი ჟურნალის ცოტა ნაწილი და დაიწყოთ იმ მომენტიდან, როდესაც ყველაფერი კარგად იყო. დავუშვათ, თქვენ გადაახვიეთ ერთი წუთით, ანუ ითვლება, რომ თქვენ ყველაფერი წუთში გაასუფთავეთ.

ზ: – ანუ „კუნთჰაუსს“ უფრო დიდხანს უჭირავს ფანჯარა და დაცემის შემთხვევაში შეუძლია მისი ამოცნობა და გადახვევა?

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: – მაქვს განცდა, რომ რედისი, დიდი ალბათობით, ვერ შეძლებს ისეთი მოცულობის ჩასმას ერთ ჰოსტზეც კი (რამდენიმე სერვერის გაგებით), რომელიც ამოიღებს Clickhouse-ს. მე არ შემიძლია ამის დამადასტურებელი მტკიცებულებებით (მე არ მაქვს შეფასებული), მაგრამ მეჩვენება, რომ Redis არ არის საუკეთესო გამოსავალი აქ. პრინციპში, ეს სისტემა შეიძლება ჩაითვალოს, როგორც იმპროვიზირებული შეტყობინებების რიგი, მაგრამ რომელიც მორგებულია მხოლოდ "Clickhouse"-ზე.

მოდერატორი: – იური, დიდი მადლობა. მე ვთავაზობ აქ დავასრულოთ კითხვა-პასუხი და ვთქვა, რომელ კითხვას მივცემთ წიგნს.

YN: – პირველს, ვინც შეკითხვა დამისვა, მინდა წიგნი ვაჩუქო.

მოდერატორი: - მშვენიერია! დიდი! ზღაპრული! Დიდი მადლობა!

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე 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 ტელევიზორი $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