ClickHouse-ში გადასვლა: 3 წლის შემდეგ

სამი წლის წინ ვიქტორ ტარნავსკი და ალექსეი მილოვიდოვი Yandex-დან სცენაზე მაღალი დატვირთვა ++ განუცხადა, რამდენად კარგია ClickHouse და როგორ არ ანელებს. და შემდეგ ეტაპზე იყო ალექსანდრე ზაიცევი с ანგარიში გადასვლის შესახებ clickhouse სხვა ანალიტიკური DBMS-დან და დასკვნასთან ერთად, რომ clickhouseრა თქმა უნდა, კარგია, მაგრამ არც ისე მოსახერხებელი. როდესაც კომპანია 2016წ სიცოცხლის ქუჩა, სადაც ალექსანდრე მაშინ მუშაობდა, აკონვერტირებდა მრავალპეტაბაიტიან ანალიტიკურ სისტემას clickhouse, ეს იყო მომხიბლავი „ყვითელი აგურის გზა“ სავსე უცნობი საფრთხეებით - clickhouse მაშინ ის ნაღმის ველს ჰგავდა.

Სამი წლის შემდეგ clickhouse ბევრად უკეთესი გახდა - ამ დროის განმავლობაში ალექსანდრემ დააარსა კომპანია Altinity, რომელიც არა მხოლოდ ეხმარება ადამიანებს გადაადგილებაში clickhouse ათობით პროექტი, მაგრამ ასევე აუმჯობესებს თავად პროდუქტს Yandex-ის კოლეგებთან ერთად. ახლა clickhouse ჯერ კიდევ არ არის უდარდელი სეირნობა, მაგრამ აღარ არის ნაღმი.

ალექსანდრე 2003 წლიდან მუშაობს განაწილებულ სისტემებთან, ავითარებს დიდ პროექტებს MySQL, Oracle и ვერტიკას. ბოლოზე HighLoad++ 2019 წელი ალექსანდრე, გამოყენების ერთ-ერთი პიონერი clickhouse, განუცხადა რა არის ეს DBMS ახლა. ჩვენ გავეცნობით ძირითად მახასიათებლებს clickhouse: რით განსხვავდება ის სხვა სისტემებისგან და რა შემთხვევაშია მისი გამოყენება უფრო ეფექტური. მაგალითების გამოყენებით, ჩვენ გადავხედავთ უახლეს და პროექტში გამოცდილი პრაქტიკებს სამშენებლო სისტემებისთვის clickhouse.

რეტროსპექტივა: რაც მოხდა 3 წლის წინ

სამი წლის წინ გადავიტანეთ კომპანია სიცოცხლის ქუჩა on clickhouse სხვა ანალიტიკური მონაცემთა ბაზიდან და რეკლამის ქსელის ანალიტიკის მიგრაცია ასე გამოიყურებოდა:

• ივნისი 2016 წ ღია წყარო გამოჩნდა clickhouse და ჩვენი პროექტი დაიწყო;
• აგვისტო. კონცეფციის მტკიცებულება: დიდი სარეკლამო ქსელი, ინფრასტრუქტურა და 200-300 ტერაბაიტი მონაცემები;
• Ოქტომბერი. პირველი წარმოების მონაცემები;
• დეკემბერი. პროდუქტის სრული დატვირთვა არის 10-50 მილიარდი მოვლენა დღეში.
• 2017 წლის ივნისი. მომხმარებელთა წარმატებული მიგრაცია clickhouse, 2,5 პეტაბაიტი მონაცემები 60 სერვერის კლასტერზე.

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

• ჩვენ ვამზადებთ და ვეხმარებით გადაწყვეტილებების შექმნაზე დაყრდნობით clickhouse რათა მომხმარებლებმა პრობლემები არ შეაღწიონ და გამოსავალი საბოლოოდ იმოქმედოს;
• ჩვენ გთავაზობთ 24/7 მხარდაჭერას clickhouse- დანადგარები;
• ჩვენ ვავითარებთ საკუთარ ეკოსისტემურ პროექტებს;
• ჩვენ აქტიურად ვიღებ საკუთარ თავს clickhouse, პასუხობს მომხმარებლების მოთხოვნებს, რომლებსაც სურთ გარკვეული ფუნქციების ნახვა.

და რა თქმა უნდა, ჩვენ ვეხმარებით გადასვლაში clickhouse с MySQL, ვერტიკას, Oracle, გრინპლამი, Redshift და სხვა სისტემები. ჩვენ ჩართული ვიყავით სხვადასხვა ნაბიჯებში და ყველა მათგანი წარმატებული იყო.

რატომ გადავიდეთ clickhouse

არ ანელებს! ეს არის მთავარი მიზეზი. clickhouse - ძალიან სწრაფი მონაცემთა ბაზა სხვადასხვა სცენარისთვის:

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

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

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

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

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

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

ClickHouse-ში გადასვლა

Წასვლა clickhouse რატომღაც, თქვენ მხოლოდ სამი რამ გჭირდებათ:

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

გადაადგილების პრობლემა

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

• გარიგებები;
• შეზღუდვები;
• თანმიმდევრულობა;
• ინდექსები;
• განახლება/წაშლა;
• NULL-ები;
• მილიწამები;
• ავტომატური ტიპის ჩამოსხმები;
• მრავალჯერადი შეერთება;
• თვითნებური ტიხრები;
• კლასტერების მართვის ინსტრუმენტები.

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

და მთავარი ის არის, რომ შიგნით clickhouse ზოგიერთი სტანდარტული პრაქტიკა და მიდგომა არ მუშაობს ან მუშაობს განსხვავებულად, ვიდრე ჩვენ მიჩვეულები ვართ. ყველაფერი რაც ჩნდება clickhouse, შეესაბამება "ClickHouse გზა“, ე.ი. ფუნქციები განსხვავდება სხვა მონაცემთა ბაზებისგან. Მაგალითად:

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

ClickHouse სკრიპტები

1960 წელს უნგრული წარმოშობის ამერიკელი მათემატიკოსი Wigner EP დაწერა სტატია"მათემატიკის არაგონივრული ეფექტურობა საბუნებისმეტყველო მეცნიერებებში” („მათემატიკის გაუგებარი ეფექტურობა საბუნებისმეტყველო მეცნიერებებში“), რომ ჩვენს ირგვლივ სამყარო რატომღაც კარგად არის აღწერილი მათემატიკური კანონებით. მათემატიკა აბსტრაქტული მეცნიერებაა და მათემატიკური ფორმით გამოხატული ფიზიკური კანონები არ არის ტრივიალური და Wigner EP ხაზგასმით აღნიშნა, რომ ეს ძალიან უცნაურია.

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

მაგალითად, ავიღოთ რეალურ დროში მონაცემთა საწყობი, რომელშიც მონაცემები იტვირთება თითქმის განუწყვეტლივ. ჩვენ გვინდა მისგან მოთხოვნები მეორე დაგვიანებით მივიღოთ. გთხოვთ - გამოიყენეთ clickhouse, რადგან ეს არის სცენარი, რომლისთვისაც ის იყო შექმნილი. clickhouse ზუსტად ასე გამოიყენება არა მხოლოდ ინტერნეტში, არამედ მარკეტინგსა და ფინანსურ ანალიტიკაში, AdTecთ, ისევე როგორც ში თაღლითობის გამოვლენან. IN რეალურ დროში მონაცემთა საწყობი გამოიყენება რთული სტრუქტურირებული სქემა, როგორიცაა "ვარსკვლავი" ან "ფიფქია", ბევრი ცხრილი შემოგვიერთდით (ზოგჯერ მრავალჯერადი) და მონაცემები ჩვეულებრივ ინახება და იცვლება ზოგიერთ სისტემაში.

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

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

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

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

დროის სერიები

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

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

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

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

ყველაზე სწრაფად მზარდი ტიპია დროის სერიას. გრაფიკული მონაცემთა ბაზებიც იზრდება, მაგრამ დროის სერიაბოლო რამდენიმე წლის განმავლობაში ის უფრო სწრაფად იზრდებოდა. მონაცემთა ბაზების ამ ოჯახის ტიპიური წარმომადგენლები არიან InfluxDB, პრომეთე, KDB, TimescaleDB (აშენებული PostgreSQL), გადაწყვეტილებები Amazon. clickhouse შეიძლება გამოყენებულ იქნას აქაც და გამოიყენება. ნება მომეცით მოგაწოდოთ რამდენიმე საჯარო მაგალითი.

ერთ-ერთი პიონერი კომპანიაა CloudFlare (CDN- პროვაიდერი). ისინი აკონტროლებენ მათ CDN მეშვეობით clickhouse (DNS- მოთხოვნები, HTTP-queries) უზარმაზარი დატვირთვით - 6 მილიონი მოვლენა წამში. ყველაფერი გადის კაფკა, მიდის clickhouse, რომელიც უზრუნველყოფს სისტემაში მოვლენების დაფის რეალურ დროში ნახვის შესაძლებლობას.

Comcast - აშშ-ში ტელეკომუნიკაციების ერთ-ერთი ლიდერი: ინტერნეტი, ციფრული ტელევიზია, ტელეფონი. მათ შექმნეს მსგავსი კონტროლის სისტემა CDN შიგნით ღია პროექტი Apache Traffic Control იმუშაოთ თქვენს უზარმაზარ მონაცემებთან. clickhouse გამოიყენება როგორც ანალიტიკის სარეზერვო საშუალება.

პერკონა ჩაშენებული clickhouse თქვენს შიგნით PMMშესანახად მონიტორინგი სხვადასხვა MySQL.

სპეციფიკური მოთხოვნები

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

• სწრაფი ჩასმა მრავალი აგენტისგან. ჩვენ ძალიან სწრაფად გვიწევს მონაცემების ჩასმა მრავალი ნაკადიდან. clickhouse ის ამას კარგად აკეთებს, რადგან ყველა მისი ჩანართები არ არის დაბლოკილი. ნებისმიერი ჩანართით არის ახალი ფაილი დისკზე და მცირე ჩანართები შეიძლება ამა თუ იმ გზით ბუფერული იყოს. IN clickhouse უმჯობესია მონაცემების ჩასმა დიდ პარტიებში და არა ერთ სტრიქონში ერთდროულად.
• მოქნილი სქემა. In დროის სერიები ჩვენ ჩვეულებრივ არ ვიცით მონაცემთა სტრუქტურა მთლიანად. შესაძლებელია კონკრეტული აპლიკაციისთვის მონიტორინგის სისტემის აშენება, მაგრამ შემდეგ ძნელია მისი გამოყენება სხვა აპლიკაციისთვის. ამას უფრო მოქნილი სქემა სჭირდება. clickhouse, ამის გაკეთების საშუალებას გაძლევთ, მიუხედავად იმისა, რომ ეს არის მკაცრად აკრეფილი ბაზა.
• მონაცემთა ეფექტური შენახვა და დავიწყება. ჩვეულებრივში დროის სერიები დიდი რაოდენობით მონაცემები, ამიტომ უნდა იყოს შენახული რაც შეიძლება ეფექტურად. მაგალითად, ზე InfluxDB კარგი შეკუმშვა მისი მთავარი მახასიათებელია. მაგრამ შენახვის გარდა, თქვენ ასევე უნდა შეძლოთ ძველი მონაცემების „დავიწყება“ და რაიმე სახის გაკეთება შერჩევის შემცირება - აგრეგატების ავტომატური დათვლა.
• სწრაფი მოთხოვნები აგრეგირებულ მონაცემებზე. ზოგჯერ საინტერესოა ბოლო 5 წუთის დათვალიერება მილიწამების სიზუსტით, მაგრამ ყოველთვიური მონაცემების წუთში ან წამში შეიძლება არ იყოს საჭირო - ზოგადი სტატისტიკა საკმარისია. ამ ტიპის მხარდაჭერა აუცილებელია, წინააღმდეგ შემთხვევაში 3 თვის მოთხოვნას ძალიან დიდი დრო დასჭირდება clickhouse.
• მოთხოვნები, როგორიცაა "ბოლო წერტილი, როგორც». ეს ტიპიურია დროის სერიები მოთხოვნები: შეხედეთ სისტემის ბოლო გაზომვას ან მდგომარეობას დროის მომენტში t. ეს არ არის ძალიან სასიამოვნო მოთხოვნები მონაცემთა ბაზისთვის, მაგრამ თქვენ ასევე უნდა შეძლოთ მათი შესრულება.
• დროის სერია "წებება".. დროის სერიები არის დროის სერია. თუ არსებობს ორი დროის სერია, მათ ხშირად სჭირდებათ დაკავშირება და კორელაცია. ეს არ არის მოსახერხებელი ამის გაკეთება ყველა მონაცემთა ბაზაში, განსაკუთრებით არათანმიმდევრული დროის სერიებით: აქ არის გარკვეული დროის წერტილები, არის სხვები. შეგიძლიათ საშუალოდ ჩათვალოთ, მაგრამ უცებ იქ მაინც იქნება ხვრელი, ასე რომ, გაუგებარია.

ვნახოთ, როგორ სრულდება ეს მოთხოვნები clickhouse.

სქემა

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

რეგულარული მონაცემები. Სვეტები. სქემა მარტივია - სვეტები საჭირო ტიპებით:

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

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

არარეგულარული მონაცემები. მასივები:

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

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

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

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

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

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

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

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


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

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

მოდით შევადაროთ სამი მიდგომა:

დეტალები

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

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

ერთ-ერთ კომპანიაში, რომელიც იყენებს ამ მიდგომას (მაგალითად, Uber), მასივები იჭრება 128 ელემენტის ნაჭრებად. რამდენიმე ათასი მეტრიკის მონაცემები 200 ტბ მონაცემთა/დღეში მოცულობით ინახება არა ერთ მასივში, არამედ 10 ან 30 მასივში სპეციალური შენახვის ლოგიკით.

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

ჰიბრიდული სქემა

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

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

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

კოდეკები და შეკუმშვა

იყიდება დროის სერიები მნიშვნელოვანია რამდენად კარგად შეფუთავთ მონაცემებს, რადგან ინფორმაციის რაოდენობა შეიძლება იყოს ძალიან დიდი. IN clickhouse არსებობს ინსტრუმენტების ნაკრები 1:10, 1:20 და ზოგჯერ მეტი შეკუმშვის ეფექტის მისაღწევად. ეს ნიშნავს, რომ დისკზე 1 ტბაიტი დაუფასოებელი მონაცემი იკავებს 50-100 გბ-ს. მცირე ზომის კარგია, მონაცემების წაკითხვა და დამუშავება უფრო სწრაფად შეიძლება.

შეკუმშვის მაღალი დონის მისაღწევად, clickhouse მხარს უჭერს შემდეგ კოდეკებს:

მაგალითი ცხრილი:

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

აქ ჩვენ განვსაზღვრავთ კოდეკს DoubleDelta ერთ შემთხვევაში, მეორეში - Gorilla, და ჩვენ აუცილებლად დავამატებთ LZ4 შეკუმშვა. შედეგად, დისკზე მონაცემების ზომა მნიშვნელოვნად მცირდება:

ეს გვიჩვენებს, თუ რამდენ ადგილს იკავებს იგივე მონაცემები, მაგრამ სხვადასხვა კოდეკებისა და შეკუმშვის გამოყენებით:

• GZIP ფაილში დისკზე;
• ClickHouse-ში კოდეკების გარეშე, მაგრამ ZSTD შეკუმშვით;
• ClickHouse-ში კოდეკებით და შეკუმშვით LZ4 და ZSTD.

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

ზომა საკითხები

არანაკლებ მნიშვნელოვანია выбрать სწორი მონაცემთა ტიპი:

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

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

აგრეგაცია და მატერიალიზებული ხედები

აგრეგაცია და მატერიალიზებული ხედები საშუალებას გაძლევთ შექმნათ აგრეგატები სხვადასხვა შემთხვევებისთვის:

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

TTL - „დაივიწყე“ ძველი მონაცემები

როგორ „დავივიწყოთ“ მონაცემები, რომლებიც აღარ არის საჭირო? clickhouse იცის როგორ გააკეთოს ეს. ცხრილების შექმნისას შეგიძლიათ მიუთითოთ TTL გამონათქვამები: მაგალითად, რომ ჩვენ ვინახავთ წუთ მონაცემებს ერთი დღის განმავლობაში, დღიურ მონაცემებს 30 დღის განმავლობაში და არასდროს ვეხებით ყოველკვირეულ ან ყოველთვიურ მონაცემებს:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

მრავალსართულიანი - მონაცემების გაყოფა დისკებზე

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

შეგიძლიათ დააკონფიგურიროთ შენახვის პოლიტიკა (შენახვის პოლიტიკა) Ისე clickhouse ავტომატურად გადასცემს მონაცემებს სხვა საცავში გარკვეული პირობების მიღწევის შემდეგ.

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

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

უნიკალური თვისებები clickhouse

თითქმის ყველაფერში clickhouse არის ასეთი „მაჩვენებლები“, მაგრამ ისინი კომპენსირდება ექსკლუზიურობით - რაც არ არის სხვა მონაცემთა ბაზებში. მაგალითად, აქ არის რამდენიმე უნიკალური თვისება clickhouse:

• კოლექტორები. In clickhouse მასივების ძალიან კარგი მხარდაჭერა, ასევე მათზე რთული გამოთვლების შესრულების შესაძლებლობა.
• მონაცემთა სტრუქტურების აგრეგაცია. ეს არის ერთ-ერთი "მკვლელი თვისება" clickhouse. იმისდა მიუხედავად, რომ Yandex-ის ბიჭები ამბობენ, რომ ჩვენ არ გვინდა მონაცემების გაერთიანება, ყველაფერი აგრეგირებულია clickhouse, რადგან ის სწრაფი და მოსახერხებელია.
• მატერიალიზებული ხედები. მონაცემთა აგრეგაციასთან ერთად, მატერიალიზებული ხედები საშუალებას გაძლევთ გახადოთ მოსახერხებელი რეალურ დროში აგრეგაცია.
• ClickHouse SQL. ეს არის ენის გაფართოება SQL რამდენიმე დამატებითი და ექსკლუზიური ფუნქციით, რომლებიც მხოლოდ ხელმისაწვდომია clickhouse. ადრე, ეს ერთი მხრივ გაფართოებას ჰგავდა და მეორეს მხრივ მინუსს. ახლა თითქმის ყველა მინუსი შედარებით SQL 92 ჩვენ წავშალეთ იგი, ახლა ეს მხოლოდ გაფართოებაა.
• ლამბდა- გამონათქვამები. ისინი კიდევ არიან რაიმე მონაცემთა ბაზაში?
• ML- მხარდაჭერა. ეს ხელმისაწვდომია სხვადასხვა მონაცემთა ბაზაში, ზოგი უკეთესია, ზოგი უარესი.
• საჯარო წყარო. შეგვიძლია გავაფართოვოთ clickhouse ერთად. ახლა შიგნით clickhouse დაახლოებით 500 კონტრიბუტორი და ეს რიცხვი მუდმივად იზრდება.

სახიფათო კითხვები

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

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

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

მეორე მეთოდი აკეთებს იგივეს, მაგრამ იყენებს აგრეგატის ფუნქციას argMax:

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

В clickhouse არსებობს რამდენიმე ათეული აგრეგატული ფუნქცია და თუ იყენებთ კომბინატორებს, მაშინ კომბინატორიკის კანონების მიხედვით მიიღებთ დაახლოებით ათას მათგანს. ArgMax - ერთ-ერთი ფუნქცია, რომელიც ითვლის მაქსიმალურ მნიშვნელობას: მოთხოვნა აბრუნებს მნიშვნელობას გამოყენება_მომხმარებელი, სადაც მიღწეულია მაქსიმალური მნიშვნელობა შექმნილი_ზე:

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

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

ანალიტიკური ფუნქციები

სტანდარტში SQL-2003 შეგიძლიათ დაწეროთ ასე:

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

В clickhouse თქვენ არ შეგიძლიათ ამის გაკეთება - ის არ უჭერს მხარს სტანდარტს SQL-2003 და ალბათ არასოდეს გააკეთებს. სამაგიეროდ, შიგნით clickhouse ჩვეულებრივად დაწერა ასე:

ლამბდას დავპირდი - აი ისინი!

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

Სპეციალური თვისებები

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

ზოგადად, ClickHouse-ს აქვს სპეციალური ფუნქციები მრავალი მიზნისთვის:

• runDifference, runAcumulate, მეზობელი;
• sumMap(გასაღები, მნიშვნელობა);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• შიგთავსით / ბაფთით;
• მარტივი ხაზოვანი რეგრესია, სტოქასტური ხაზოვანი რეგრესია.

ეს არ არის ფუნქციების სრული სია, სულ არის 500-600. მინიშნება: ყველა ფუნქციაა clickhouse არის სისტემის ცხრილში (ყველა არ არის დოკუმენტირებული, მაგრამ ყველა საინტერესოა):

select * from system.functions order by name

clickhouse ის ინახავს უამრავ ინფორმაციას თავის შესახებ, მათ შორის ჟურნალის ცხრილები, query_log, კვალის ჟურნალი, ოპერაციების ჟურნალი მონაცემთა ბლოკებით (part_log), მეტრიკის ჟურნალი და სისტემის ჟურნალი, რომელსაც ის ჩვეულებრივ წერს დისკზე. ჟურნალის მეტრიკა არის დროის სერიები в clickhouse სინამდვილეში clickhouse: თავად მონაცემთა ბაზას შეუძლია როლი შეასრულოს დროის სერიები მონაცემთა ბაზები, რითაც „შთანთქავს“ საკუთარ თავს.

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

დიდი მტევანი ან ბევრი პატარა clickhouse

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

В clickhouse შეგიძლიათ გააკეთოთ სხვაგვარად. თქვენ შეგიძლიათ გააკეთოთ თითოეული აპლიკაცია საკუთარი clickhouse:

ჩვენ აღარ გვჭირდება დიდი ამაზრზენი DWH და შეუპოვარი ადმინები. ჩვენ შეგვიძლია თითოეულ აპლიკაციას მივცეთ საკუთარი clickhouse, და დეველოპერს შეუძლია ამის გაკეთება თავად, რადგან clickhouse ძალიან მარტივი ინსტალაცია და არ საჭიროებს რთულ ადმინისტრირებას:

მაგრამ თუ ბევრი გვაქვს clickhouseდა თქვენ უნდა დააინსტალიროთ ის ხშირად, შემდეგ გსურთ ამ პროცესის ავტომატიზაცია. ამისთვის შეგვიძლია, მაგალითად, გამოვიყენოთ კუბერნეტები и clickhouse-ოპერატორი. IN Kubernetes ClickHouse შეგიძლიათ დააწკაპუნოთ „დაწკაპუნებაზე“: შემიძლია დავაჭირო ღილაკს, გავუშვა მანიფესტი და მონაცემთა ბაზა მზად არის. შემიძლია დაუყოვნებლივ შევქმნა დიაგრამა, დავიწყო მეტრიკის ატვირთვა და 5 წუთში მზად მაქვს დაფა გრაფანა. ეს ასე მარტივია!

შედეგი?

აქედან გამომდინარე, clickhouse - ეს არის:

• სწრაფად. ეს ყველამ იცის.
• უბრალოდ. ცოტა საკამათოა, მაგრამ მე მჯერა, რომ ვარჯიშში რთულია, ბრძოლაში ადვილი. თუ გესმით როგორ clickhouse მუშაობს, მაშინ ყველაფერი ძალიან მარტივია.
• უნივერსალურად. ეს შესაფერისია სხვადასხვა სცენარისთვის: DWH, დროის სერიები, ჟურნალის შენახვა. მაგრამ ეს ასე არ არის OLTP მონაცემთა ბაზა, ასე რომ ნუ ცდილობთ იქ მოკლე ჩანართების და წაკითხვის გაკეთებას.
• საინტერესოა. ალბათ ის, ვინც მუშაობს clickhouse, განიცადა ბევრი საინტერესო მომენტი კარგი და ცუდი გაგებით. მაგალითად, გამოვიდა ახალი გამოშვება, ყველაფერი შეჩერდა. ან როცა ორი დღის განმავლობაში უჭირდათ დავალება, მაგრამ Telegram-ის ჩატში კითხვის დასმის შემდეგ, ამოცანა ორ წუთში მოგვარდა. ან როგორც ლეშა მილოვიდოვის მოხსენებაში კონფერენციაზე, სკრინშოტი clickhouse დაარღვია გადაცემა მაღალი დატვირთვა ++. ასეთი რამ ყოველთვის ხდება და ართულებს ჩვენს ცხოვრებას. clickhouse ნათელი და საინტერესო!

შეგიძლიათ ნახოთ პრეზენტაცია აქ.

მაღალი დატვირთვის სისტემების დეველოპერების დიდი ხნის ნანატრი შეხვედრა ზე მაღალი დატვირთვა ++ 9 და 10 ნოემბერს სკოლკოვოში გაიმართება. დაბოლოს, ეს იქნება ოფლაინ კონფერენცია (თუმცა ყველა სიფრთხილით), ვინაიდან HighLoad++-ის ენერგიის შეფუთვა შეუძლებელია ონლაინ.

კონფერენციისთვის ჩვენ ვპოულობთ და გაჩვენებთ შემთხვევებს ტექნოლოგიის მაქსიმალური შესაძლებლობების შესახებ: HighLoad++ იყო, არის და იქნება ერთადერთი ადგილი, სადაც ორ დღეში შეძლებთ გაიგოთ, თუ როგორ მუშაობს Facebook, Yandex, VKontakte, Google და Amazon.

2007 წლიდან ჩვენი შეხვედრები შეუფერხებლად ჩატარდა, წელს მე-14-ედ შევხვდებით. ამ დროის განმავლობაში, კონფერენცია 10-ჯერ გაიზარდა; გასულ წელს, საკვანძო ინდუსტრიის ღონისძიებამ შეკრიბა 3339 მონაწილე, 165 მომხსენებელი, მოხსენებები და შეხვედრები, ხოლო 16 ტრეკი ერთდროულად გადიოდა.
გასულ წელს იყო 20 ავტობუსი, 5280 ლიტრი ჩაი და ყავა, 1650 ლიტრი ხილის სასმელი და 10200 ბოთლი წყალი. და კიდევ 2640 კილოგრამი საკვები, 16 თეფში და 000 ჭიქა. სხვათა შორის, გადამუშავებული ქაღალდიდან შემოსული თანხით 25 მუხის ნერგი დავრგეთ :)

შეგიძლიათ შეიძინოთ ბილეთები აქ, მიიღეთ სიახლეები კონფერენციის შესახებ - აქდა ისაუბრეთ ყველა სოციალურ ქსელში: დეპეშა, Facebook, Vkontakte и Twitter.

წყარო: www.habr.com