ClickHouse-ის რეალურ აპლიკაციებში გამოყენების თეორია და პრაქტიკა. ალექსანდრე ზაიცევი (2018)

იმისდა მიუხედავად, რომ ახლა თითქმის ყველგან არის უამრავი მონაცემი, ანალიტიკური მონაცემთა ბაზები მაინც საკმაოდ ეგზოტიკურია. ისინი ცუდად არიან ცნობილი და კიდევ ნაკლებად შეუძლიათ მათი ეფექტურად გამოყენება. ბევრი აგრძელებს „კაქტუსის ჭამას“ MySQL-ით ან PostgreSQL-ით, რომლებიც შექმნილია სხვა სცენარებისთვის, ებრძვის NoSQL-ს, ან ზედმეტად იხდის კომერციულ გადაწყვეტილებებს. ClickHouse არის თამაშის ჩეინჯერი და მნიშვნელოვნად ამცირებს ანალიტიკური DBMS-ის სამყაროში შესვლის ბარიერს.

ანგარიში არის BackEnd Conf 2018 და გამოქვეყნებულია სპიკერის ნებართვით.

ვინ ვარ მე და რატომ ვსაუბრობ ClickHouse-ზე? მე ვარ განვითარების დირექტორი LifeStreet-ში, რომელიც იყენებს ClickHouse-ს. მე ასევე ვარ Altinity-ის დამფუძნებელი. ეს არის Yandex-ის პარტნიორი, რომელიც ხელს უწყობს ClickHouse-ს და ეხმარება Yandex-ს უფრო წარმატებული გახადოს ClickHouse. ასევე მზად ვარ გავიზიარო ცოდნა ClickHouse-ის შესახებ.

მე ასევე არ ვარ პეტია ზაიცევის ძმა. ამაზე ხშირად მეკითხებიან. არა, ჩვენ ძმები არ ვართ.

"ყველამ იცის", რომ ClickHouse:

• Ძალიან სწრაფად,
• ძალიან მოსახერხებელი,
• გამოიყენება Yandex-ში.

ცოტა ნაკლებად ცნობილია რომელ კომპანიებში და როგორ გამოიყენება.

მე გეტყვით რატომ, სად და როგორ გამოიყენება ClickHouse, გარდა Yandex.

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

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

პირველი კითხვაა: "რატომ გვჭირდება ClickHouse?" როგორც ჩანს, კითხვა საკმაოდ გასაგებია, მაგრამ მასზე ერთზე მეტი პასუხი არსებობს.

• პირველი პასუხი არის შესრულების მიზეზების გამო. ClickHouse ძალიან სწრაფია. ანალიტიკა ClickHouse-ზე ასევე ძალიან სწრაფია. ის ხშირად შეიძლება გამოყენებულ იქნას იქ, სადაც რაღაც სხვა მუშაობს ძალიან ნელა ან ძალიან ცუდად.
• მეორე პასუხი არის ღირებულება. და პირველ რიგში, სკალირების ღირებულება. მაგალითად, Vertica არის აბსოლუტურად შესანიშნავი მონაცემთა ბაზა. ის ძალიან კარგად მუშაობს, თუ არ გაქვთ ბევრი ტერაბაიტი მონაცემები. მაგრამ როდესაც ვსაუბრობთ ასობით ტერაბაიტზე ან პეტაბაიტზე, ლიცენზიისა და მხარდაჭერის ღირებულება საკმაოდ მნიშვნელოვან თანხას შეადგენს. და ძვირია. და ClickHouse უფასოა.
• მესამე პასუხი არის ოპერაციული ღირებულება. ეს ოდნავ განსხვავებული მიდგომაა. RedShift შესანიშნავი ანალოგია. RedShift-ით შეგიძლიათ მიიღოთ გადაწყვეტილება ძალიან სწრაფად. ის კარგად იმუშავებს, მაგრამ ამავდროულად, ყოველ საათში, ყოველდღე და ყოველთვიურად საკმაოდ ბევრს გადაიხდით ამაზონზე, რადგან ეს საგრძნობლად ძვირი სერვისია. Google BigQuery ასევე. თუ ვინმეს გამოუყენებია ის, მაშინ მან იცის, რომ თქვენ შეგიძლიათ რამდენიმე შეკითხვის გაკეთება და მოულოდნელად მიიღოთ ინვოისი ასობით დოლარად.

ClickHouse-ს არ აქვს ეს პრობლემები.

სად გამოიყენება ClickHouse ახლა? Yandex-ის გარდა, ClickHouse გამოიყენება სხვადასხვა ბიზნესსა და კომპანიაში.

• უპირველეს ყოვლისა, ეს არის ვებ აპლიკაციის ანალიტიკა, ანუ ეს არის გამოყენების შემთხვევა, რომელიც მოვიდა Yandex-დან.
• ბევრი AdTech კომპანია იყენებს ClickHouse-ს.
• მრავალი კომპანია, რომლებსაც სჭირდებათ საოპერაციო ჟურნალის ანალიზი სხვადასხვა წყაროდან.
• რამდენიმე კომპანია იყენებს ClickHouse-ს უსაფრთხოების ჟურნალების მონიტორინგისთვის. ისინი ატვირთავენ ClickHouse-ში, აკეთებენ მოხსენებებს და იღებენ საჭირო შედეგებს.
• კომპანიები იწყებენ მის გამოყენებას ფინანსურ ანალიზში, ანუ თანდათან მსხვილი ბიზნესებიც უახლოვდებიან ClickHouse-ს.
• CloudFlare. თუ ვინმე მიყვება ClickHouse-ს, ალბათ გსმენიათ ამ კომპანიის სახელი. ეს არის საზოგადოების ერთ-ერთი მნიშვნელოვანი წვლილი. და მათ აქვთ ძალიან სერიოზული ClickHouse ინსტალაცია. მაგალითად, მათ დაამზადეს Kafka Engine ClickHouse-ისთვის.
• სატელეკომუნიკაციო კომპანიებმა დაიწყეს გამოყენება. რამდენიმე კომპანია იყენებს ClickHouse-ს, როგორც კონცეფციის მტკიცებულებას ან უკვე წარმოებაში.
• ერთი კომპანია იყენებს ClickHouse-ს წარმოების პროცესების მონიტორინგისთვის. ისინი ამოწმებენ მიკროსქემებს, ჩამოწერენ რამდენიმე პარამეტრს, დაახლოებით 2 მახასიათებელია. შემდეგ კი აანალიზებენ პარტია კარგია თუ ცუდი.
• ბლოკჩეინის ანალიტიკა. არის რუსული კომპანია Bloxy.info. ეს არის Ethereum ქსელის ანალიზი. მათ ასევე გააკეთეს ეს ClickHouse-ზე.

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

და თუ გადახედავთ ჩანაწერებს, მაშინ:

• Yandex: 500+ სერვერი, ისინი დღეში 25 მილიარდ ჩანაწერს ინახავენ.
• LifeStreet: 60 სერვერი, დაახლოებით 75 მილიარდი ჩანაწერი დღეში. უფრო ნაკლები სერვერი და მეტი ჩანაწერია, ვიდრე Yandex-ში.
• CloudFlare: 36 სერვერი, ისინი ინახავენ 200 მილიარდ ჩანაწერს დღეში. მათ კიდევ უფრო ნაკლები სერვერები აქვთ და კიდევ უფრო მეტ მონაცემს ინახავენ.
• Bloomberg: 102 სერვერი, დაახლოებით ტრილიონი ჩანაწერი დღეში. რეკორდსმენი.

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

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

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

ეს არის ClickHouse-ის რეალური გამოყენების მაგალითები რამდენიმე კომპანიაში.

• პირველი მაგალითი არის სარეკლამო ქსელი: მიგრაცია Vertica-დან ClickHouse-ში. და მე ვიცი რამდენიმე კომპანია, რომლებიც გადავიდნენ ვერტიკიდან ან არიან გადართვის პროცესში.
• მეორე მაგალითი არის ტრანზაქციის შენახვა ClickHouse-ზე. ეს არის ანტიპატერნებზე აგებული მაგალითი. ყველაფერი, რისი გაკეთებაც არ არის საჭირო ClickHouse-ში დეველოპერების რჩევით, აქ კეთდება. და ამავე დროს ის კეთდება ისე ეფექტურად, რომ მუშაობს. და ის ბევრად უკეთ მუშაობს, ვიდრე ტიპიური ტრანზაქციის გადაწყვეტა.
• მესამე მაგალითი არის განაწილებული გამოთვლები ClickHouse-ზე. გაჩნდა კითხვა იმის შესახებ, თუ როგორ შეიძლება ClickHouse ინტეგრირება Hadoop-ის ეკოსისტემაში. მე ვაჩვენებ მაგალითს, თუ როგორ გააკეთა კომპანიამ მსგავსი რამ რუქის შემცირების კონტეინერზე ClickHouse-ზე, მონაცემთა ლოკალიზაციის მონიტორინგი და ა.შ., რათა გამოთვალოს ძალიან არატრივიალური დავალება.

• LifeStreet არის Ad Tech კომპანია, რომელსაც აქვს ყველა ტექნოლოგია, რომელიც დაკავშირებულია სარეკლამო ქსელთან.
• ის ეწევა რეკლამის ოპტიმიზაციას და პროგრამულ ტენდერს.
• ბევრი მონაცემი: დაახლოებით 10 მილიარდი მოვლენა დღეში. უფრო მეტიც, იქ მოვლენები შეიძლება დაიყოს რამდენიმე ქვემოვლენად.
• ამ მონაცემების ბევრი კლიენტია და ეს არ არის მხოლოდ ხალხი, სხვა მრავალი ალგორითმებია, რომლებიც მონაწილეობენ პროგრამულ ტენდერში.

კომპანიამ გრძელი და ეკლიანი გზა გაიარა. და მე ვისაუბრე ამაზე HighLoad-ზე. პირველი, LifeStreet გადავიდა MySQL-დან (მოკლე გაჩერებით Oracle-ში) Vertica-ში. და თქვენ შეგიძლიათ იპოვოთ ამბავი ამის შესახებ.

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

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

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

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

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

არაფერი მომხდარა მანამ, სანამ Yandex-მა მოულოდნელად არ ამოიღო ClickHouse ქუდიდან, როგორც ჯადოქარი კურდღელი. და ეს იყო მოულოდნელი გადაწყვეტილება; ხალხი კვლავ სვამს კითხვას: "რატომ?", მაგრამ მაინც.

და მაშინვე 2016 წლის ზაფხულში დავიწყეთ იმის გარკვევა, თუ რა არის ClickHouse. და აღმოჩნდა, რომ ის ზოგჯერ შეიძლება იყოს უფრო სწრაფი ვიდრე ვერტიკა. ჩვენ გამოვცადეთ სხვადასხვა სცენარი სხვადასხვა მოთხოვნაზე. და თუ მოთხოვნამ გამოიყენა მხოლოდ ერთი ცხრილი, ანუ შეერთების გარეშე, მაშინ ClickHouse იყო ორჯერ უფრო სწრაფი ვიდრე Vertica.

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

მაგრამ თუ მოთხოვნები შეიცავს შეერთებებს, მაშინ ყველაფერი არც თუ ისე ნათელია. და ClickHouse შეიძლება იყოს ორჯერ უფრო ნელი ვიდრე Vertica. და თუ ცოტათი შეასწორებთ და გადაწერთ მოთხოვნას, მაშინ ისინი დაახლოებით ტოლი იქნება. Ცუდი არაა. და ეს უფასოა.

ტესტის შედეგების მიღებისა და სხვადასხვა კუთხით დათვალიერების შემდეგ LifeStreet წავიდა ClickHouse-ში.

მე-16 წელია, შეგახსენებთ. ეს ხუმრობას ჰგავდა თაგვებზე, რომლებიც ტიროდნენ და გაუკეთეს ინექცია, მაგრამ განაგრძეს კაქტუსის ჭამა. და ეს იყო დეტალურად განხილული, არის ვიდეო ამის შესახებ და ა.შ.

ამიტომ, ამაზე დეტალურად არ ვისაუბრებ, მხოლოდ შედეგებზე და რამდენიმე საინტერესოზე ვისაუბრებ, რაზეც მაშინ არ ვსაუბრობდი.

შედეგები ასეთია:

• წარმატებული მიგრაცია და სისტემა უკვე წელიწადზე მეტია წარმოებაშია.
• გაიზარდა პროდუქტიულობა და მოქნილობა. 10 მილიარდი ჩანაწერიდან, რომელთა შენახვა შეგვიძლია დღეში მხოლოდ მოკლე დროში, LifeStreet ახლა ინახავს 75 მილიარდ ჩანაწერს დღეში და შეუძლია ამის გაკეთება 3 თვის ან მეტი ხნის განმავლობაში. თუ პიკზე ითვლით, მაშინ ის ინახება მილიონამდე მოვლენა წამში. დღეში მილიონზე მეტი SQL მოთხოვნა იგზავნება ამ სისტემაში, ძირითადად სხვადასხვა რობოტებიდან.
• იმისდა მიუხედავად, რომ ClickHouse-მა დაიწყო მეტი სერვერის გამოყენება, ვიდრე Vertica, დანაზოგი განხორციელდა აპარატურაზეც, რადგან Vertica იყენებდა საკმაოდ ძვირადღირებულ SAS დისკებს. ClickHouse-მა გამოიყენა SATA. Და რატომ? რადგან ვერტიკაში ჩანართი სინქრონულია. და სინქრონიზაცია მოითხოვს, რომ დისკები ძალიან არ შენელდეს და ასევე, რომ ქსელი არ შენელდეს ძალიან, ანუ საკმაოდ ძვირი ოპერაცია. და ClickHouse-ში ჩასმა არის ასინქრონული. უფრო მეტიც, თქვენ ყოველთვის შეგიძლიათ დაწეროთ ყველაფერი ადგილობრივად, ამისთვის დამატებითი ხარჯები არ არის, ამიტომ მონაცემების ჩასმა შესაძლებელია ClickHouse-ში ბევრად უფრო სწრაფად, ვიდრე Vertika-ში, თუნდაც არა უსწრაფეს დისკებზე. და კითხვა დაახლოებით იგივეა. SATA-ზე კითხვა, თუ ისინი RAID-ში არიან, მაშინ ეს ყველაფერი საკმარისად სწრაფია.
• შეუზღუდავი ლიცენზიით, ანუ 3 პეტაბაიტი მონაცემები 60 სერვერზე (20 სერვერი არის ერთი რეპლიკა) და 6 ტრილიონი ჩანაწერი ფაქტებსა და აგრეგატებში. ვერტიკა მსგავს რამეს ვერ ახერხებდა.

ახლა მე გადავდივარ ამ მაგალითში პრაქტიკულ საკითხებზე.

• პირველი ეფექტური სქემაა. ბევრი რამ არის დამოკიდებული სქემაზე.
• მეორე არის ეფექტური SQL-ის გენერირება.

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

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

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

მაგრამ ეს კარგად არ მუშაობს ClickHouse-ში. არსებობს ორი მიზეზი:

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

და ამისგან გამოსავალი არის ClickHouse-ში. თუნდაც ორი:

• პირველი არის ლექსიკონების გამოყენება. გარე ლექსიკონები არის ის, რაც 99%-ს ეხმარება პრობლემის გადაჭრაში ვარსკვლავის სქემით, განახლებებით და ა.შ.
• მეორე არის მასივების გამოყენება. მასივები ასევე ხელს უწყობს შეერთებისა და ნორმალიზაციის პრობლემების მოშორებას.

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

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

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

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

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

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

მაგრამ ClickHouse-ში არაფრის გაკეთება არ გჭირდებათ, უბრალოდ აღწერეთ სიმებიანი მასივი ჰეშთეგებისთვის ან შექმენით ჩადგმული სტრუქტურა გასაღები-მნიშვნელობის სისტემებისთვის.

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

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

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

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

Სხვა მაგალითი. თქვენ გაქვთ მასივი, რომელშიც ინახავთ ID-ებს. და თქვენ შეგიძლიათ თარგმნოთ ისინი სახელებად. ფუნქცია arrayMap. ეს არის ტიპიური ლამბდა ფუნქცია. იქ ლამბდა გამონათქვამებს გადასცემ. და იგი ამოიღებს თითოეული ID-ის სახელს ლექსიკონიდან.

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

ეს ყველაფერი მნიშვნელოვნად ამარტივებს წრეს და წყვეტს უამრავ პრობლემას.

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

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

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

აი მაგალითი. მარცხენა მხარეს არის მოთხოვნა, რომელიც აჩვენებს ტოპ 5 ქვეყანას. და 2,5 წამში გადის მგონი. და მარჯვენა მხარეს არის იგივე მოთხოვნა, მაგრამ ოდნავ გადაწერილი. სტრიქონების მიხედვით დაჯგუფების ნაცვლად, ჩვენ დავიწყეთ დაჯგუფება გასაღების მიხედვით (int). და უფრო სწრაფია. შემდეგ კი შედეგს მივაერთეთ ლექსიკონი. 2,5 წამის ნაცვლად, მოთხოვნას 1,5 წამი სჭირდება. Კარგია.

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

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

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

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

მოდით გადავიდეთ შემდეგ მაგალითზე. კომპანია X ამერიკიდან. Რას აკეთებს?

იყო დავალება:

• სარეკლამო ტრანზაქციების ოფლაინ ბმული.
• სხვადასხვა შეკვრის მოდელების სიმულაცია.

რა სცენარია?

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

გონივრული კითხვები: "ვინ უნდა გადაიხადოს რეკლამა, საჭიროების შემთხვევაში?" და "რომელმა რეკლამამ მოახდინა გავლენა მასზე?" ანუ რატომ იყიდა და როგორ უნდა დარწმუნდეს, რომ ამ ადამიანის მსგავსი ადამიანებიც იყიდიან?

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

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

არსებობს მრავალი სავალდებულო მოდელი.

ყველაზე პოპულარულია:

• ბოლო ინტერაქცია, სადაც ურთიერთქმედება არის ან დაწკაპუნება ან შთაბეჭდილება.
• პირველი ინტერაქცია, ანუ პირველი, რამაც ადამიანი მიიყვანა საიტზე.
• ხაზოვანი კომბინაცია - თანაბარი წილი ყველასთვის.
• შესუსტება.
• Და ასე შემდეგ.

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

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

და ეს ყველაფერი ძალიან კარგად მუშაობდა, სანამ კავშირი არ იყო ბოლო დაწკაპუნებამდე. იმიტომ, რომ არის, ვთქვათ, 10 მილიონი დაწკაპუნება დღეში, 300 მილიონი თვეში, თუ ფანჯარას დააყენებთ ერთი თვის განმავლობაში. და რადგან კასანდრაში ეს ყველაფერი უნდა იყოს მეხსიერებაში, რათა სწრაფად იმუშაოს, რადგან Runtime საჭიროა სწრაფად რეაგირებისთვის, საჭირო იყო დაახლოებით 10-15 სერვერი.

და როდესაც მათ მოინდომეს ტრანზაქციის დაკავშირება ჩვენებასთან, მაშინვე აღმოჩნდა არც ისე სახალისო. Და რატომ? ჩანს, რომ 30-ჯერ მეტი მოვლენის შენახვაა საჭირო. და, შესაბამისად, გჭირდებათ 30-ჯერ მეტი სერვერი. და გამოდის, რომ ეს არის ერთგვარი ასტრონომიული ფიგურა. 500-მდე სერვერის შენახვა ლინკების გასაკეთებლად, მიუხედავად იმისა, რომ Runtime-ში გაცილებით ნაკლები სერვერია, ერთგვარი არასწორი მაჩვენებელია. და დაიწყეს ფიქრი რა გაეკეთებინათ.

და ჩვენ მივედით ClickHouse-ში. როგორ გავაკეთოთ ეს ClickHouse-ზე? ერთი შეხედვით ჩანს, რომ ეს არის ანტიპატერნების ნაკრები.

• ტრანზაქცია იზრდება, ჩვენ მას უფრო და უფრო მეტ მოვლენას ვამაგრებთ, ანუ ის ცვალებადია და ClickHouse არც ისე კარგად მუშაობს ცვალებადი ობიექტებთან.
• როდესაც ვიზიტორი ჩვენთან მოდის, ჩვენ უნდა მოვიძიოთ მისი ტრანზაქციები გასაღებით, მისი ვიზიტის ID-ით. ეს ასევე წერტილის მოთხოვნაა; ClickHouse ამას არ აკეთებს. ჩვეულებრივ ClickHouse-ს აქვს დიდი… სკანირება, მაგრამ აქ ჩვენ უნდა მივიღოთ რამდენიმე ჩანაწერი. ასევე ანტიპატერნა.
• გარდა ამისა, ტრანზაქცია იყო json-ში, მაგრამ მათ არ სურდათ მისი გადაწერა, ამიტომ მათ სურდათ json-ის შენახვა უსტრუქტუროდ და საჭიროების შემთხვევაში, რაღაცის ამოღება. და ეს ასევე ანტიპატერნაა.

ანუ ანტიპატერნების ნაკრები.

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

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

ეს არ მუშაობდა ძალიან კარგად ამ ფორმით. და ClickHouse-ის გასაადვილებლად, როდესაც იყო მოთხოვნა ვიზიტის id-ზე, მათ დაჯგუფეს ეს მოთხოვნები 1-000 ვიზიტების ID ბლოკებად და ამოიღეს ყველა ტრანზაქცია 2-000 ადამიანისთვის. და შემდეგ ეს ყველაფერი მუშაობდა.

თუ დააკვირდებით ClickHouse-ს, არის მხოლოდ 3 ძირითადი ცხრილი, რომელიც ამ ყველაფერს ემსახურება.

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

მეორე მაგიდა. მატერიალიზებული ხედვით, ამ ჟურნალებიდან ამოღებულია მოვლენები, რომლებიც ჯერ არ არის მიკუთვნებული, ანუ ერთმანეთთან დაკავშირებული. და მატერიალიზებული ხედის მეშვეობით, ტრანზაქციები ამოიღეს ამ ჟურნალებიდან, რათა აეშენებინათ სნეპშოტი. ანუ შეიქმნა სნეპშოტი სპეციალური მატერიალიზებული ხედით, კერძოდ, ტრანზაქციის ბოლო დაგროვილი მდგომარეობა.

აქ ტექსტი იწერება SQL-ში. მასში რამდენიმე მნიშვნელოვან საკითხზე მინდა კომენტარი გავაკეთო.

პირველი მნიშვნელოვანი რამ არის ClickHouse-ში json-დან სვეტების და ველების ამოღების შესაძლებლობა. ანუ, ClickHouse-ს აქვს json-თან მუშაობის რამდენიმე მეთოდი. ისინი ძალიან, ძალიან პრიმიტიულები არიან.

visitParamExtractInt საშუალებას გაძლევთ ამოიღოთ ატრიბუტები json-დან, ანუ პირველი დარტყმა ამოქმედდება. და ამ გზით შეგიძლიათ ამოიღოთ ტრანზაქციის ID ან ეწვიოთ ID. Ამჯერად.

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

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

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

და სნეპშოტი იყენებს სხვა საინტერესო ClickHouse ფუნქციებს.

პირველი არის AggregatingMergeTree. და AggregatingMergeTree ინახავს argMax-ს, ანუ ეს არის ტრანზაქციის მდგომარეობა, რომელიც შეესაბამება ბოლო დროის ნიშანს. ახალი ტრანზაქციები ყოველთვის გენერირდება ამ ვიზიტორისთვის. და ამ ტრანზაქციის ბოლო მდგომარეობაში, ჩვენ დავამატეთ ღონისძიება და გვქონდა ახალი მდგომარეობა. ის კვლავ მოხვდა ClickHouse-ზე. და argMax-ის მეშვეობით ამ მატერიალიზებულ ხედში ჩვენ ყოველთვის შეგვიძლია მივიღოთ არსებული მდგომარეობა.

• Binding არის "untethered" საწყისი Runtime.
• თვეში 3 მილიარდამდე ტრანზაქცია ინახება და მუშავდება. ეს არის უფრო დიდი ბრძანება, ვიდრე კასანდრაში, ანუ ტიპიურ ტრანზაქციულ სისტემაში.
• 2x5 ClickHouse სერვერების კლასტერი. 5 სერვერი და თითოეულ სერვერს აქვს ასლი. ეს კიდევ უფრო ნაკლებია, ვიდრე კასანდრაში იყო დაწკაპუნების საფუძველზე ატრიბუციის გასაკეთებლად, მაგრამ აქ ჩვენ გვაქვს შთაბეჭდილებაზე დაფუძნებული. ანუ სერვერების 30-ჯერ გაზრდის ნაცვლად ისინი შემცირდა.

და ბოლო მაგალითია ფინანსური კომპანია Y, რომელმაც გააანალიზა აქციების ფასების ცვლილებების კორელაციები.

და დავალება ასეთი იყო:

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

და საჭირო იყო ცვლილებების კორელაციის გამოთვლა.

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

ამ ორმხრივი ცვლილებების ანალიზით შესაძლებელია ფინანსურ ბაზარზე პროგნოზების გაკეთება.

მაგრამ ამოცანა რთულია. რა კეთდება ამისთვის? ჩვენ გვაქვს 100 მილიარდი ჩანაწერი, რომელიც შეიცავს: დროს, მარაგს და ფასს. ჩვენ ჯერ უნდა გამოვთვალოთ 100 მილიარდჯერ გაშვებული განსხვავება ფასის ალგორითმისგან. RunningDifference არის ფუნქცია ClickHouse-ში, რომელიც თანმიმდევრულად ითვლის განსხვავებას ორ ხაზს შორის.

და ამის შემდეგ ჩვენ უნდა გამოვთვალოთ კორელაცია და კორელაცია უნდა გამოვთვალოთ თითოეული წყვილისთვის. 5 აქციაზე წყვილი 000 მილიონია. და ეს ბევრია, ანუ 12,5-ჯერ გჭირდებათ ამ კორელაციის ფუნქციის გამოთვლა.

და თუ ვინმეს დაავიწყდა, ͞x და ͞y არის მატე. ნიმუშის მოლოდინი. ანუ, თქვენ უნდა გამოთვალოთ არა მხოლოდ ფესვები და ჯამები, არამედ სხვა ჯამებიც ამ ჯამებში. ბევრი და ბევრი გამოთვლაა საჭირო 12,5 მილიონჯერ და ასევე საჭიროა მათი დაჯგუფება საათების მიხედვით. და ასევე გვაქვს ბევრი საათი. და თქვენ უნდა გააკეთოთ ეს 60 წამში. ეს ხუმრობაა.

ჩვენ უნდა გაგვეკეთებინა ეს როგორმე, რადგან ეს ყველაფერი ძალიან, ძალიან ნელა მუშაობდა ClickHouse-ის მოსვლამდე.

ისინი ცდილობდნენ ამის გამოთვლას Hadoop-ზე, Spark-ზე, Greenplum-ზე. და ეს ყველაფერი ძალიან ნელი ან ძვირი იყო. ანუ შეიძლებოდა როგორმე გამოთვლა, მაგრამ მაშინ ძვირი ღირდა.

შემდეგ კი ClickHouse მოვიდა და ყველაფერი ბევრად უკეთესი გახდა.

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

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

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

ამის შემდეგ შეიძლება განმეორდეს. ასო "r" ნიშნავს, რომ ჩვენ გავიმეორეთ ეს მონაცემები. ანუ სამივე სერვერზე გვაქვს ერთი და იგივე მონაცემები - ეს არის მასივები.

შემდეგ კი, სპეციალური სკრიპტის გამოყენებით, შეგიძლიათ გააკეთოთ პაკეტები 12,5 მილიონი კორელაციის ამ ნაკრებიდან, რომლებიც უნდა გამოითვალოთ. ანუ 2 დავალება 500 წყვილი კორელაციით. და ეს ამოცანა უნდა იყოს გათვლილი კონკრეტულ ClickHouse სერვერზე. მას აქვს ყველა მონაცემი, რადგან მონაცემები ერთი და იგივეა და შეუძლია მისი თანმიმდევრობით გამოთვლა.

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

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

ამ პირველ ორ ეტაპს: Log_return-ის გამოთვლას და მასივებში შეფუთვას თითოეულს დაახლოებით ერთი საათი დასჭირდა.

და კორელაციის გამოთვლას დაახლოებით 50 საათი სჭირდება. მაგრამ 50 საათი არ არის საკმარისი, რადგან ადრე ეს მათთვის კვირების განმავლობაში მუშაობდა. ეს იყო დიდი წარმატება. და თუ ითვლით, მაშინ ამ კლასტერზე ყველაფერი წამში 70-ჯერ იყო დათვლილი.

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

• სწორი სქემა წარმატების ნახევარია. და სწორი სქემა არის ყველა საჭირო ClickHouse ტექნოლოგიების გამოყენება.
• Summing/AggregatingMergeTrees არის ტექნოლოგიები, რომლებიც საშუალებას გაძლევთ შეაგროვოთ ან გამოთვალოთ სახელმწიფოს სნეპშოტი, როგორც სპეციალური შემთხვევა. და ეს მნიშვნელოვნად ამარტივებს ბევრ რამეს.
• მატერიალიზებული ხედები საშუალებას გაძლევთ გადალახოთ ერთი ინდექსის შეზღუდვა. შეიძლება მე არ ვთქვი ეს ძალიან მკაფიოდ, მაგრამ როდესაც ჩავტვირთეთ ჟურნალები, ნედლეული ჟურნალები იყო ცხრილში ერთი ინდექსით და ატრიბუტით ჟურნალები იყო ცხრილში, ანუ იგივე მონაცემები, მხოლოდ გაფილტრული, მაგრამ ინდექსი იყო. მთლიანად სხვებისთვის. როგორც ჩანს, იგივე მონაცემებია, მაგრამ განსხვავებული დახარისხება. და Materialized Views გაძლევთ საშუალებას, თუ ეს გჭირდებათ, გვერდის ავლით ამ ClickHouse შეზღუდვას.
• შეამცირეთ ინდექსის სიზუსტე წერტილოვანი მოთხოვნებისთვის.
• და ჭკვიანურად გაანაწილეთ მონაცემები, შეეცადეთ შეძლებისდაგვარად მოაწყოთ მონაცემები სერვერის შიგნით. და შეეცადეთ უზრუნველყოთ, რომ მოთხოვნები ასევე გამოიყენონ ლოკალიზაცია, სადაც ეს შესაძლებელია.

და რომ შევაჯამოთ ეს მოკლე სიტყვა, შეგვიძლია ვთქვათ, რომ ClickHouse-მა ახლა მტკიცედ დაიპყრო როგორც კომერციული, ისე ღია კოდის მონაცემთა ბაზების ტერიტორია, ანუ სპეციალურად ანალიტიკისთვის. ის მშვენივრად ჯდება ამ ლანდშაფტში. უფრო მეტიც, ის ნელ-ნელა იწყებს სხვების გადაადგილებას, რადგან როდესაც ClickHouse არის იქ, თქვენ არ გჭირდებათ InfiniDB. ვერტიკალური შეიძლება მალე არ იყოს საჭირო, თუ ისინი უზრუნველყოფენ ნორმალურ SQL მხარდაჭერას. Გამოიყენე!

-გმადლობთ ანგარიშისთვის! Ძალიან საინტერესო! ყოფილა რაიმე შედარება Apache Phoenix-თან?

-არა, არ მსმენია ვინმეს შედარება. ჩვენ და Yandex ვცდილობთ თვალყური ადევნოთ ClickHouse-ის ყველა შედარებას სხვადასხვა მონაცემთა ბაზებთან. იმის გამო, რომ თუ მოულოდნელად რაღაც უფრო სწრაფი აღმოჩნდა, ვიდრე ClickHouse, მაშინ ლეშა მილოვიდოვი ღამით ვერ იძინებს და იწყებს სწრაფად აჩქარებას. ასეთი შედარება არ მსმენია.

• (ალექსეი მილოვიდოვი) Apache Phoenix არის SQL ძრავა, რომელიც დაფუძნებულია Hbase-ზე. Hbase ძირითადად შექმნილია გასაღების ღირებულების ტიპის სამუშაო სცენარისთვის. იქ თითოეულ ხაზს შეიძლება ჰქონდეს სვეტების თვითნებური რაოდენობა თვითნებური სახელებით. ეს შეიძლება ითქვას ისეთ სისტემებზე, როგორიცაა Hbase და Cassandra. და ეს არის ზუსტად მძიმე ანალიტიკური მოთხოვნები, რომლებიც ნორმალურად არ იმუშავებს მათთვის. ან შეიძლება ფიქრობთ, რომ ისინი კარგად მუშაობენ, თუ არ გქონიათ რაიმე გამოცდილება ClickHouse-თან.

• მადლობა

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

  • Ეს სწორია. და ეს ეხება ყველაზე სპეციალიზებულ ანალიტიკურ მონაცემთა ბაზებს. ისინი მორგებულია იმ ფაქტზე, რომ არსებობს ერთი ან რამდენიმე დიდი ცხრილი, რომელიც ცვალებადია და ბევრი პატარა, რომელიც ნელ-ნელა იცვლება. ანუ, ClickHouse არ ჰგავს Oracle-ს, სადაც შეგიძლიათ განათავსოთ ყველაფერი და შექმნათ ძალიან რთული მოთხოვნები. იმისათვის, რომ გამოიყენოთ ClickHouse ეფექტურად, თქვენ უნდა ააწყოთ სქემა ისე, რომ კარგად იმოქმედოს ClickHouse-ში. ანუ მოერიდეთ ზედმეტ ნორმალიზებას, გამოიყენეთ ლექსიკონები, შეეცადეთ ნაკლები გრძელი კავშირი დაამყაროთ. და თუ სქემა აგებულია ამ გზით, მაშინ მსგავსი ბიზნეს პრობლემები შეიძლება გადაწყდეს ClickHouse-ზე ბევრად უფრო ეფექტურად, ვიდრე ტრადიციულ რელაციურ მონაცემთა ბაზაზე.

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

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

Ნათელია. თქვენ თქვით, რომ დამუშავებას 50 საათი დასჭირდა. ეს თავიდანვე იწყება, როცა ჩატვირთე მონაცემები თუ მიიღე შედეგები?

დიახ, დიახ.

Კარგი, დიდი მადლობა.

ეს არის 3 სერვერის კლასტერზე.

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

რა თქმა უნდა, იდეალური სისტემები არ არსებობს. და ClickHouse-საც აქვს თავისი პრობლემები. მაგრამ გსმენიათ იმის შესახებ, რომ Yandex.Metrica დიდი ხანია არ მუშაობს? Ალბათ არა. იგი საიმედოდ მუშაობს დაახლოებით 2012-2013 წლიდან ClickHouse-ზე. იგივე შემიძლია ვთქვა ჩემს გამოცდილებაზე. ჩვენ არასდროს გვქონია სრული წარუმატებლობა. ზოგიერთი ნაწილობრივი რამ შეიძლებოდა მომხდარიყო, მაგრამ ისინი არასოდეს იყვნენ საკმარისად კრიტიკული, რომ სერიოზულად იმოქმედონ ბიზნესზე. ეს აქამდე არასდროს მომხდარა. ClickHouse საკმაოდ საიმედოა და არ იშლება შემთხვევით. თქვენ არ უნდა ინერვიულოთ ამაზე. ეს არ არის ნედლი რამ. ეს ბევრმა კომპანიამ დაადასტურა.

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

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

დიდი მადლობა.

წყარო: www.habr.com