Haqiqiy ilovalarda ClickHouse-dan foydalanish nazariyasi va amaliyoti. Aleksandr Zaitsev (2018)

Hozir deyarli hamma joyda juda ko'p ma'lumotlar mavjud bo'lishiga qaramay, analitik ma'lumotlar bazalari hali ham juda ekzotik. Ular kam ma'lum va undan samarali foydalanishga qodir. Ko'pchilik boshqa stsenariylar uchun mo'ljallangan MySQL yoki PostgreSQL bilan "kaktus yeyishda" davom etadi, NoSQL bilan azoblanadi yoki tijorat yechimlari uchun ortiqcha to'laydi. ClickHouse o'yin qoidalarini o'zgartiradi va analitik DBMS dunyosiga kirish chegarasini sezilarli darajada pasaytiradi.

BackEnd Conf 2018 hisoboti va u ma'ruzachining ruxsati bilan nashr etiladi.

Men kimman va nima uchun ClickHouse haqida gapiryapman? Men ClickHouse-dan foydalanadigan LifeStreet-ning rivojlanish bo'yicha direktoriman. Bundan tashqari, men Altinity asoschisiman. Bu ClickHouse-ni targ'ib qiluvchi va Yandex-ga ClickHouse-ni yanada muvaffaqiyatli qilishga yordam beradigan Yandex hamkoridir. Shuningdek, ClickHouse haqidagi bilimlarni almashishga tayyor.

Va men Petya Zaitsevning ukasi emasman. Mendan bu haqda tez-tez so'rashadi. Yo'q, biz aka-uka emasmiz.

ClickHouse-ni "hamma biladi":

• Juda tez,
• Juda qulay
• Yandex-da qo'llaniladi.

Qaysi kompaniyalarda va qanday foydalanilganligi biroz kamroq ma'lum.

Men sizga nima uchun, qaerda va qanday qilib ClickHouse ishlatilishini aytaman, Yandexdan tashqari.

Men sizga turli kompaniyalarda ClickHouse yordamida aniq vazifalar qanday hal qilinishini, vazifalaringiz uchun qanday ClickHouse vositalaridan foydalanishingiz mumkinligini va ular turli kompaniyalarda qanday ishlatilganligini aytib beraman.

Men ClickHouse-ni turli burchaklardan ko'rsatadigan uchta misolni oldim. Menimcha qiziqarli bo'ladi.

Birinchi savol: "Nima uchun bizga ClickHouse kerak?". Bu juda aniq savol bo'lib tuyuladi, lekin unga bir nechta javob bor.

• Birinchi javob ishlash uchun. ClickHouse juda tez. ClickHouse-dagi tahlillar ham juda tez. Ko'pincha boshqa narsa juda sekin yoki juda yomon bo'lgan joyda ishlatilishi mumkin.
• Ikkinchi javob - bu narx. Va birinchi navbatda, masshtablash narxi. Masalan, Vertica - bu mutlaqo ajoyib ma'lumotlar bazasi. Agar sizda ko'p terabayt ma'lumotlar bo'lmasa, u juda yaxshi ishlaydi. Ammo yuzlab terabaytlar yoki petabaytlar haqida gap ketganda, litsenziya va qo'llab-quvvatlash narxi juda katta miqdorda ketadi. Va bu qimmat. ClickHouse esa bepul.
• Uchinchi javob - operatsion xarajatlar. Bu biroz boshqacha yondashuv. RedShift - bu ajoyib analog. RedShift-da siz juda tez qaror qabul qilishingiz mumkin. Bu yaxshi ishlaydi, lekin shu bilan birga, har soatda, har kuni va har oyda siz Amazonga juda qimmat to'laysiz, chunki bu juda qimmat xizmat. Google BigQuery ham. Agar kimdir undan foydalangan bo'lsa, u erda siz birdaniga bir nechta so'rovlarni bajarishingiz va yuzlab dollarlar uchun hisob olishingiz mumkinligini biladi.

ClickHouse-da bunday muammolar yo'q.

ClickHouse hozir qayerda ishlatiladi? Yandex-ga qo'shimcha ravishda ClickHouse turli xil biznes va kompaniyalarda qo'llaniladi.

• Birinchidan, bu veb-ilovalar tahlili, ya'ni bu Yandex-dan kelgan foydalanish holati.
• Ko'pgina AdTech kompaniyalari ClickHouse-dan foydalanadi.
• Turli manbalardan tranzaksiya jurnallarini tahlil qilish kerak bo'lgan ko'plab kompaniyalar.
• Bir nechta kompaniyalar xavfsizlik jurnallarini kuzatish uchun ClickHouse-dan foydalanadilar. Ular ularni ClickHouse-ga yuklaydi, hisobotlar tuzadi va kerakli natijalarni oladi.
• Kompaniyalar moliyaviy tahlilda foydalanishni boshlaydilar, ya'ni asta-sekin yirik korxonalar ham ClickHouse-ga yaqinlashmoqda.
• bulutli chaqnash. Agar kimdir ClickHouse-ga ergashsa, ular bu kompaniya nomini eshitgan bo'lishi mumkin. Bu jamiyatning muhim hissalaridan biridir. Va ular juda jiddiy ClickHouse o'rnatilishiga ega. Masalan, ular ClickHouse uchun Kafka dvigatelini yaratdilar.
• Telekommunikatsiya kompaniyalari foydalanishni boshladilar. Bir nechta kompaniyalar ClickHouse-dan kontseptsiyani isbotlash yoki allaqachon ishlab chiqarishda foydalanishadi.
• Bitta kompaniya ishlab chiqarish jarayonlarini kuzatish uchun ClickHouse-dan foydalanadi. Ular mikrosxemalarni sinovdan o'tkazadilar, bir qator parametrlarni yozadilar, 2 ga yaqin xususiyatlar mavjud. Va keyin ular o'yin yaxshi yoki yomon ekanligini tahlil qilishadi.
• Blokcheyn tahlili. Bloxy.info kabi rus kompaniyasi mavjud. Bu ethereum tarmog'ining tahlili. Ular buni ClickHouse-da ham qilishdi.

Va o'lcham muhim emas. Bitta kichik serverdan foydalanadigan ko'plab kompaniyalar mavjud. Va u o'z muammolarini hal qilishga imkon beradi. Va bundan ham ko'proq kompaniyalar ko'plab serverlar yoki o'nlab serverlarning katta klasterlaridan foydalanadilar.

Va agar siz yozuvlarga qarasangiz, unda:

• Yandex: 500+ serverlar, ular kuniga 25 milliard yozuvni saqlaydi.
• LifeStreet: 60 ta server, kuniga taxminan 75 milliard yozuv. Yandex-ga qaraganda kamroq serverlar, ko'proq yozuvlar mavjud.
• CloudFlare: 36 ta server, ular kuniga 200 milliard yozuvni saqlaydi. Ularda kamroq serverlar mavjud va ko'proq ma'lumotlarni saqlaydi.
• Bloomberg: 102 server, kuniga taxminan bir trillion yozuv. Rekord egasi.

Geografik jihatdan bu ham juda ko'p. Bu xaritada ClickHouse dunyoda qayerda foydalanilayotganining issiqlik xaritasi ko‘rsatilgan. Bu erda Rossiya, Xitoy, Amerika yaqqol ajralib turadi. Yevropa davlatlari kam. Va 4 ta klaster mavjud.

Bu qiyosiy tahlil, mutlaq raqamlarni izlashning hojati yo'q. Bu Altinity veb-saytida ingliz tilidagi materiallarni o'qigan tashrif buyuruvchilarning tahlili, chunki u erda rus tilida so'zlashuvchilar yo'q. Va Rossiya, Ukraina, Belarusiya, ya'ni jamiyatning rusiyzabon qismi, bu eng ko'p foydalanuvchilar. Keyin AQSh va Kanada keladi. Xitoy juda ko'p ortda qoldi. Olti oy oldin u erda Xitoy deyarli yo'q edi, endi Xitoy allaqachon Evropani ortda qoldirdi va o'sishda davom etmoqda. Qadimgi Evropa ham orqada emas va ClickHouse-dan foydalanish bo'yicha etakchi, g'alati, Frantsiya.

Bularning barchasini nega aytyapman? ClickHouse katta ma'lumotlarni tahlil qilish uchun standart yechimga aylanib borayotganini va ko'p joylarda allaqachon qo'llanilganligini ko'rsatish uchun. Agar siz undan foydalansangiz, siz to'g'ri tendentsiyadasiz. Agar siz hali foydalanmayotgan bo'lsangiz, unda siz yolg'iz qolasiz va hech kim sizga yordam bermaydi, deb qo'rqishingiz mumkin emas, chunki ko'pchilik allaqachon buni qilmoqda.

Bular bir nechta kompaniyalarda haqiqiy ClickHouse-dan foydalanishga misollardir.

• Birinchi misol - reklama tarmog'i: Vertica-dan ClickHouse-ga o'tish. Va men Vertica'dan o'tgan yoki o'tish jarayonida bo'lgan bir nechta kompaniyalarni bilaman.
• Ikkinchi misol - ClickHouse-da tranzaksiya saqlash. Bu antipatternlarga asoslangan namunadir. Ishlab chiquvchilarning maslahati bilan ClickHouse-da bajarilmasligi kerak bo'lgan hamma narsa bu erda amalga oshiriladi. Va u shunchalik samarali amalga oshirildiki, u ishlaydi. Va u odatdagi tranzaksiya yechimidan ancha yaxshi ishlaydi.
• Uchinchi misol ClickHouse-da taqsimlangan hisoblashdir. ClickHouse-ni Hadoop ekotizimiga qanday integratsiyalash mumkinligi haqida savol tug'ildi. Men kompaniyaning juda ahamiyatsiz bo'lmagan vazifani hisoblash uchun ClickHouse-da xaritani kamaytirish konteyneriga o'xshash ishni qanday qilgani, ma'lumotlarning lokalizatsiyasini kuzatib borishi va hokazolarni misol qilib ko'rsataman.

• LifeStreet - bu reklama tarmog'i bilan birga keladigan barcha texnologiyalarga ega bo'lgan Ad Tech kompaniyasi.
• U reklamani optimallashtirish, dasturiy takliflar bilan shug'ullanadi.
• Ko'p ma'lumotlar: kuniga taxminan 10 milliard voqea. Shu bilan birga, u yerdagi voqealarni bir nechta kichik hodisalarga bo'lish mumkin.
• Ushbu ma'lumotlarning ko'plab mijozlari bor va bu nafaqat odamlar, balki yana ko'plari - bu dasturiy savdolar bilan shug'ullanadigan turli xil algoritmlar.

Kompaniya uzoq va mashaqqatli yo'lni bosib o'tdi. Va men bu haqda HighLoad-da gaplashdim. Birinchidan, LifeStreet MySQL-dan (Oracle-da qisqa to'xtash bilan) Vertica-ga o'tdi. Va bu haqda hikoya topishingiz mumkin.

Va hamma narsa juda yaxshi edi, lekin tezda ma'lumotlar o'sib borayotgani va Vertica qimmat ekanligi ma'lum bo'ldi. Shuning uchun turli xil variantlar izlandi. Ulardan ba'zilari bu erda keltirilgan. Va aslida, biz 13-yildan 16-yilgacha bozorda mavjud bo'lgan va funksionallik nuqtai nazaridan taxminan mos bo'lgan deyarli barcha ma'lumotlar bazalarining kontseptsiyasini yoki ba'zan ishlashini sinovdan o'tkazdik. Va men ularning ba'zilari haqida HighLoad-da gaplashdim.

Vazifa birinchi navbatda Vertica'dan ko'chish edi, chunki ma'lumotlar o'sdi. Va ular yillar davomida o'sib bordi. Keyin ular javonga ketishdi, lekin shunga qaramay. Va bu o'sishni bashorat qilish, qandaydir tahlil qilish kerak bo'lgan ma'lumotlar miqdori uchun biznes talablari, yaqin orada petabaytlar muhokama qilinishi aniq edi. Petabaytlar uchun to'lov allaqachon juda qimmat, shuning uchun biz qaerga borishni muqobil qidirdik.

Qayerga borish kerak? Va uzoq vaqt davomida qaerga borish kerakligi aniq emas edi, chunki bir tomondan tijorat ma'lumotlar bazalari mavjud, ular yaxshi ishlayotganga o'xshaydi. Ba'zilar Vertica kabi deyarli yaxshi ishlaydi, ba'zilari esa yomonroq. Ammo ularning barchasi qimmat, undan arzonroq va yaxshiroq narsani topib bo'lmaydi.

Boshqa tomondan, ochiq manbali echimlar mavjud, ular juda ko'p emas, ya'ni analitika uchun ularni barmoqlar bilan hisoblash mumkin. Va ular bepul yoki arzon, lekin sekin. Va ular ko'pincha kerakli va foydali funksiyalardan mahrum.

Tijoriy ma'lumotlar bazalaridagi yaxshi narsalarni va ochiq manbadagi barcha bepul narsalarni birlashtira oladigan hech narsa yo'q edi.

Kutilmaganda, Yandex ClickHouse-ni shlyapadan sehrgar, quyon kabi tortib olmaguncha hech narsa yo'q edi. Va bu kutilmagan qaror edi, ular hali ham savol berishadi: "Nima uchun?", Lekin shunga qaramay.

Va darhol 2016 yilning yozida biz ClickHouse nima ekanligini ko'rib chiqa boshladik. Va ma'lum bo'lishicha, ba'zida u Vertica'dan tezroq bo'lishi mumkin. Biz turli so'rovlar bo'yicha turli stsenariylarni sinab ko'rdik. Va agar so'rovda faqat bitta jadvaldan foydalanilgan bo'lsa, ya'ni hech qanday birlashmalarsiz (qo'shilish), u holda ClickHouse Vertica'dan ikki baravar tez edi.

Men juda dangasa emas edim va boshqa kuni Yandex testlariga qaradim. U erda ham xuddi shunday: ClickHouse Verticadan ikki baravar tezroq, shuning uchun ular bu haqda tez-tez gapirishadi.

Ammo so'rovlarda qo'shilishlar mavjud bo'lsa, unda hamma narsa unchalik aniq emas. ClickHouse esa Vertica’dan ikki baravar sekin bo‘lishi mumkin. Va agar siz so'rovni biroz tuzatsangiz va uni qayta yozsangiz, ular taxminan teng bo'ladi. Yomon emas. Va bepul.

Va test natijalarini olib, unga turli burchaklardan qarab, LifeStreet ClickHouse-ga bordi.

Bu 16 yil, eslataman. Bu sichqonlar haqidagi hazilga o'xshardi, ular yig'lab, o'zlarini sanchishadi, lekin kaktusni eyishni davom ettirdilar. Va bu batafsil tasvirlangan, bu haqda video bor va hokazo.

Shuning uchun men bu haqda batafsil gapirmayman, men faqat natijalar va o'sha paytda gapirmagan bir nechta qiziqarli narsalar haqida gapiraman.

Natijalar:

• Muvaffaqiyatli migratsiya va bir yildan ortiq tizim allaqachon ishlab chiqarishda ishlamoqda.
• Hosildorlik va moslashuvchanlik oshdi. Biz kuniga va keyin qisqa vaqtga saqlashimiz mumkin bo'lgan 10 milliard yozuvdan LifeStreet endi kuniga 75 milliard yozuvni saqlaydi va buni 3 oy yoki undan ko'proq vaqt davomida bajarishi mumkin. Agar siz eng yuqori nuqtada hisoblasangiz, bu soniyada bir million hodisaga etadi. Ushbu tizimga kuniga bir milliondan ortiq SQL so'rovlari keladi, asosan turli robotlardan.
• Vertica'dan ko'ra ClickHouse uchun ko'proq serverlar ishlatilganiga qaramay, ular apparatda ham tejaydi, chunki Vertica'da ancha qimmat SAS disklari ishlatilgan. ClickHouse SATA-dan foydalangan. Nega? Chunki Vertica-da qo'shimcha sinxronlashtiriladi. Sinxronizatsiya esa disklarning juda ko'p sekinlashmasligini, shuningdek, tarmoqning juda ko'p sekinlashmasligini, ya'ni ancha qimmat operatsiyani talab qiladi. Va ClickHouse-da qo'shimcha asinxrondir. Bundan tashqari, siz har doim hamma narsani mahalliy sifatida yozishingiz mumkin, buning uchun qo'shimcha xarajatlar yo'q, shuning uchun ma'lumotlarni ClickHouse-ga Vertika-ga qaraganda tezroq, hatto sekinroq disklarda ham kiritish mumkin. Va o'qish taxminan bir xil. SATA-da o'qish, agar ular RAID-da bo'lsa, bularning barchasi etarlicha tez.
• Litsenziya bilan cheklanmagan, ya'ni 3 ta serverdagi 60 petabayt ma'lumotlar (20 server - bitta nusxa) va faktlar va yig'ilishlarda 6 trillion yozuv. Vertica'da bunday narsaga erishib bo'lmaydi.

Endi men ushbu misolda amaliy narsalarga murojaat qilaman.

• Birinchisi, samarali sxema. Ko'p narsa sxemaga bog'liq.
• Ikkinchisi samarali SQL avlodidir.

Oddiy OLAP so'rovi tanlovdir. Ba'zi ustunlar guruhlash bo'yicha, ba'zi ustunlar yig'ish funktsiyalariga o'tadi. Kub bo'lagi sifatida ifodalanishi mumkin bo'lgan joy mavjud. Butun guruhni proyeksiya sifatida ko'rish mumkin. Va shuning uchun u ko'p o'lchovli ma'lumotlarni tahlil qilish deb ataladi.

Va ko'pincha bu yulduz sxemasi shaklida modellashtiriladi, bu faktning markaziy haqiqati va xususiyatlari tomonlar bo'ylab, nurlar bo'ylab mavjud bo'lganda.

Va jismoniy dizayn nuqtai nazaridan, u stolga qanday mos keladi, ular odatda normallashtirilgan vakillikni bajaradilar. Siz normalizatsiya qilishingiz mumkin, lekin u diskda qimmat va so'rovlarda unchalik samarali emas. Shuning uchun ular odatda normallashtirilgan tasvirni, ya'ni faktlar jadvalini va ko'plab o'lchovli jadvallarni yaratadilar.

Lekin bu ClickHouse-da yaxshi ishlamaydi. Buning ikkita sababi bor:

• Birinchisi, ClickHouse-da unchalik yaxshi birikmalarga ega emasligi, ya'ni qo'shilishlar mavjud, ammo ular yomon. Yomon bo'lsada.
• Ikkinchisi - jadvallar yangilanmagan. Odatda yulduz sxemasi atrofida joylashgan bu plitalarda biror narsani o'zgartirish kerak. Masalan, mijoz nomi, kompaniya nomi va boshqalar. Va u ishlamayapti.

ClickHouse-da bundan chiqish yo'li bor. hatto ikkitasi:

• Birinchisi, lug'atlardan foydalanish. Tashqi lug'atlar 99% yulduz sxemasi, yangilanishlar va boshqalar bilan muammoni hal qilishga yordam beradi.
• Ikkinchisi - massivlardan foydalanish. Massivlar, shuningdek, normalizatsiya bilan bog'liq muammolar va birlashmalardan xalos bo'lishga yordam beradi.

• Qo'shilish shart emas.
• Yangilanishi mumkin. 2018 yil mart oyidan boshlab lug'atlarni, ya'ni o'zgargan yozuvlarni qisman yangilash uchun hujjatsiz imkoniyat paydo bo'ldi (buni hujjatlarda topa olmaysiz). Amalda, bu stolga o'xshaydi.
• Har doim xotirada, shuning uchun lug'at bilan qo'shilish diskdagi jadvalga qaraganda tezroq ishlaydi va u keshda ekanligi hali aniq emas, balki yo'q.

• Sizga qo'shilish ham kerak emas.
• Bu 1 dan ko'pgacha bo'lgan ixcham ko'rinishdir.
• Va mening fikrimcha, massivlar geeks uchun yaratilgan. Bu lambda funktsiyalari va boshqalar.

Bu qizil so'zlar uchun emas. Bu juda oddiy va oqlangan tarzda ko'p narsalarni qilish imkonini beruvchi juda kuchli funksionallik.

Massivlarni echishga yordam beradigan odatiy misollar. Bu misollar juda oddiy va tushunarli:

• Teglar bo'yicha qidirish. Agar sizda hashtaglaringiz bo'lsa va hashtag bo'yicha ba'zi xabarlarni topmoqchi bo'lsangiz.
• Kalit-qiymat juftliklari bo'yicha qidirish. Bundan tashqari, qiymatga ega bo'lgan ba'zi atributlar mavjud.
• Boshqa biror narsaga tarjima qilishingiz kerak bo'lgan kalitlar ro'yxatini saqlash.

Bu vazifalarning barchasini massivlarsiz hal qilish mumkin. Teglar bir qatorga qo'yilishi va muntazam ifoda yoki alohida jadval bilan tanlanishi mumkin, ammo keyin siz birlashmalarni bajarishingiz kerak.

Va ClickHouse-da siz hech narsa qilishingiz shart emas, faqat hashtaglar uchun qatorlar qatorini tavsiflash yoki kalit-qiymat tizimlari uchun ichki tuzilmani yaratish kifoya.

Ichki tuzilma eng yaxshi nom bo'lmasligi mumkin. Bu nomda umumiy qismga va ba'zi bir-biriga bog'liq xususiyatlarga ega bo'lgan ikkita massivdir.

Va teg bo'yicha qidirish juda oson. Funktsiyaga ega bo'ling has, bu massivda element mavjudligini tekshiradi. Hamma, konferentsiyamizga tegishli barcha yozuvlarni topdi.

Subid bo'yicha qidirish biroz murakkabroq. Biz birinchi navbatda kalitning indeksini topishimiz kerak, so'ngra ushbu indeks bilan elementni olib, bu qiymat bizga kerak bo'lganligini tekshirishimiz kerak. Biroq, bu juda oddiy va ixcham.

Agar hammasini bir qatorda saqlasangiz, yozmoqchi bo'lgan muntazam ibora, birinchi navbatda, noqulay bo'lar edi. Ikkinchidan, u ikkita massivdan ancha uzoqroq ishladi.

Yana bir misol. Sizda IDni saqlaydigan massiv bor. Va siz ularni nomlarga tarjima qilishingiz mumkin. Funktsiya arrayMap. Bu odatiy lambda funktsiyasi. Siz u erda lambda ifodalarini o'tkazasiz. Va u lug'atdan har bir identifikator uchun ismning qiymatini chiqaradi.

Qidiruv xuddi shu tarzda amalga oshirilishi mumkin. Elementlar nimaga mos kelishini tekshiradigan predikat funksiyasi uzatiladi.

Bu narsalar sxemani sezilarli darajada soddalashtiradi va bir qator muammolarni hal qiladi.

Ammo biz duch kelayotgan va men aytib o'tmoqchi bo'lgan keyingi muammo - bu samarali so'rovlar.

• ClickHouse-da so'rovlarni rejalashtiruvchi yo'q. Mutlaqo yo'q.
• Shunga qaramay, murakkab so'rovlar hali ham rejalashtirilishi kerak. Qaysi hollarda?
• Agar so'rovda bir nechta qo'shilish mavjud bo'lsa, siz ularni pastki tanlovlarga o'tkazasiz. Va ularni bajarish tartibi muhim.
• Va ikkinchisi - agar so'rov tarqatilsa. Chunki taqsimlangan so'rovda faqat eng ichki pastki tanlov taqsimlangan holda bajariladi va qolgan hamma narsa siz ulangan va u erda bajarilgan bitta serverga uzatiladi. Shuning uchun, agar siz ko'p qo'shilish (qo'shilish) bilan so'rovlarni tarqatgan bo'lsangiz, unda siz tartibni tanlashingiz kerak.

Va hatto oddiyroq holatlarda ham, ba'zida rejalashtiruvchining ishini bajarish va so'rovlarni biroz qayta yozish kerak bo'ladi.

Mana bir misol. Chap tomonda eng yaxshi 5 mamlakatni ko'rsatadigan so'rov mavjud. Va mening fikrimcha, bu 2,5 soniyani oladi. Va o'ng tomonda, xuddi shu so'rov, lekin biroz qayta yozilgan. Satr bo'yicha guruhlash o'rniga biz kalit (int) bo'yicha guruhlashni boshladik. Va tezroq. Va keyin biz natijaga lug'atni bog'ladik. 2,5 soniya o'rniga so'rov 1,5 soniyani oladi. Bu yaxshi.

Filtrlarni qayta yozishga o'xshash misol. Mana, Rossiya uchun so'rov. 5 soniya davomida ishlaydi. Agar biz uni satrni emas, balki Rossiyaga tegishli bo'lgan kalitlarning ba'zi to'plami bilan raqamlarni taqqoslaydigan tarzda qayta yozsak, u tezroq bo'ladi.

Bunday hiyla-nayranglar juda ko'p. Va ular siz allaqachon tez ishlayotgan yoki aksincha, sekin ishlaydigan so'rovlarni sezilarli darajada tezlashtirishga imkon beradi. Ularni yanada tezroq qilish mumkin.

• Tarqalgan rejimda maksimal ish.
• Ints bo'yicha qilganim kabi minimal turlar bo'yicha saralash.
• Agar qo'shilish (qo'shilish), lug'atlar mavjud bo'lsa, ularni oxirgi chora sifatida qilish yaxshiroqdir, agar sizda ma'lumotlar hech bo'lmaganda qisman guruhlangan bo'lsa, qo'shilish operatsiyasi yoki lug'at chaqiruvi kamroq chaqiriladi va tezroq bo'ladi. .
• Filtrlarni almashtirish.

Men ko'rsatganlar emas, boshqa texnikalar ham bor. Va ularning barchasi ba'zan so'rovlarning bajarilishini sezilarli darajada tezlashtirishi mumkin.

Keling, keyingi misolga o'tamiz. AQShdan X kompaniyasi. U nima ish qiladi?

Vazifa bor edi:

• Reklama operatsiyalarining oflayn ulanishi.
• Turli xil bog'lash modellarini modellashtirish.

Ssenariy qanday?

Oddiy mehmon saytga, masalan oyiga 20 marta turli reklamalardan keladi yoki shunga o'xshash ba'zida hech qanday reklamasiz keladi, chunki u bu saytni eslab qoladi. Ba'zi mahsulotlarga qaraydi, ularni savatga qo'yadi, savatdan chiqaradi. Va, oxir-oqibat, nimadir sotib oladi.

Mantiqiy savollar: "Agar kerak bo'lsa, reklama uchun kim to'lashi kerak?" va "Agar mavjud bo'lsa, unga qanday reklama ta'sir qildi?". Ya'ni, u nima uchun sotib oldi va qanday qilib bu odamga o'xshash odamlarni ham sotib olishga undaydi?

Ushbu muammoni hal qilish uchun siz veb-saytda sodir bo'lgan voqealarni to'g'ri tarzda bog'lashingiz kerak, ya'ni ular o'rtasida qandaydir aloqa o'rnatishingiz kerak. Keyin ular DWHga tahlil qilish uchun yuboriladi. Va bu tahlil asosida kim va qanday reklamalarni ko'rsatish modellarini yarating.

Reklama tranzaktsiyasi - bu reklamani ko'rsatishdan boshlanadigan, keyin nimadir sodir bo'ladigan, keyin xarid, keyin esa xarid doirasida xaridlar bo'lishi mumkin bo'lgan tegishli foydalanuvchi voqealari to'plami. Masalan, agar bu mobil ilova yoki mobil o'yin bo'lsa, odatda dasturni o'rnatish bepul amalga oshiriladi va agar u erda biror narsa qilingan bo'lsa, buning uchun pul talab qilinishi mumkin. Va bir kishi dasturda qancha ko'p pul sarflasa, shunchalik qimmatlidir. Lekin buning uchun siz hamma narsani ulashingiz kerak.

Ko'p bog'lovchi modellar mavjud.

Eng mashhurlari:

• Oxirgi shovqin, bunda oʻzaro taʼsir klik yoki taassurotdir.
• Birinchi shovqin, ya'ni odamni saytga olib kelgan birinchi narsa.
• Chiziqli kombinatsiya - barchasi teng.
• Zaiflash.
• Va hokazo.

Va bularning barchasi birinchi navbatda qanday ishladi? Runtime va Cassandra bor edi. Kassandra tranzaktsiyalarni saqlash sifatida ishlatilgan, ya'ni barcha tegishli tranzaktsiyalar unda saqlangan. Va Runtime-da biron bir voqea sodir bo'lganda, masalan, biron bir sahifa yoki boshqa narsani ko'rsatsa, Kassandraga so'rov yuborilgan - bunday odam bormi yoki yo'qmi. Keyin u bilan bog'liq bitimlar olingan. Va aloqa o'rnatildi.

Agar so‘rovda tranzaksiya identifikatori borligi omadli bo‘lsa, bu oson. Ammo odatda omad yo'q. Shuning uchun, oxirgi operatsiyani yoki oxirgi marta bosish bilan operatsiyani va hokazolarni topish kerak edi.

Va oxirgi marta bosish bilan bog'lanish uchun hammasi juda yaxshi ishladi. Chunki, aytaylik, kuniga 10 million marta bosish, oyiga 300 million, agar biz bir oyga oyna o'rnatsak. Va Kassandrada tez ishlashi uchun hammasi xotirada bo'lishi kerak, chunki Runtime tezda javob berishi kerak, bu taxminan 10-15 serverni talab qildi.

Va ular tranzaktsiyani displeyga bog'lamoqchi bo'lganlarida, bu darhol unchalik qiziqarli emas edi. Nega? Ko'rinib turibdiki, 30 barobar ko'proq hodisalarni saqlash kerak. Va shunga ko'ra, sizga 30 barobar ko'proq server kerak bo'ladi. Va bu qandaydir astronomik raqam ekanligi ma'lum bo'ldi. Runtime-da serverlar sezilarli darajada kam bo'lishiga qaramay, ulanishni amalga oshirish uchun 500 tagacha serverni saqlash uchun bu qandaydir noto'g'ri raqam. Va ular nima qilishni o'ylay boshladilar.

Va biz ClickHouse-ga bordik. Va buni ClickHouse-da qanday qilish kerak? Bir qarashda, bu anti-naqshlar to'plami kabi ko'rinadi.

• Tranzaksiya o'sib boradi, biz unga tobora ko'proq voqealarni bog'laymiz, ya'ni u o'zgaruvchan va ClickHouse o'zgaruvchan ob'ektlar bilan unchalik yaxshi ishlamaydi.
• Bizga mehmon kelganda, biz uning tranzaktsiyalarini kalit bo'yicha, tashrif identifikatori bo'yicha olib tashlashimiz kerak. Bu ham nuqta so'rovidir, ular buni ClickHouse'da qilmaydi. Odatda ClickHouse-da katta ... skanerlar mavjud, ammo bu erda biz ba'zi yozuvlarni olishimiz kerak. Shuningdek, antipattern.
• Bundan tashqari, tranzaktsiya json-da edi, lekin ular uni qayta yozishni xohlamadilar, shuning uchun ular json-ni tuzilmagan tarzda saqlashni va agar kerak bo'lsa, undan biror narsani tortib olishni xohlashdi. Va bu ham antipattern.

Ya'ni, antipatternlar to'plami.

Ammo shunga qaramay, juda yaxshi ishlaydigan tizim paydo bo'ldi.

Nima qilindi? ClickHouse paydo bo'ldi, unga jurnallar tashlangan, yozuvlarga bo'lingan. ClickHouse-dan jurnallarni qabul qiluvchi atributli xizmat paydo bo'ldi. Shundan so'ng, har bir kirish uchun tashrif identifikatori bo'yicha men hali qayta ishlanmagan bo'lishi mumkin bo'lgan tranzaktsiyalarni va qo'shimcha oniy tasvirlarni, ya'ni allaqachon ulangan tranzaktsiyalarni, ya'ni oldingi ish natijasini oldim. Men ulardan mantiqiy xulosa chiqardim, to'g'ri tranzaksiyani tanladim, yangi voqealarni bog'ladim. Qayta tizimga kirdi. Jurnal ClickHouse-ga qaytdi, ya'ni bu doimiy tsiklik tizimdir. Va bundan tashqari, men u erda tahlil qilish uchun DWHga bordim.

Aynan shu shaklda u juda yaxshi ishlamadi. ClickHouse-ni osonlashtirish uchun tashrif identifikatori bo'yicha so'rov bo'lganda, ular bu so'rovlarni 1-000 tashrif identifikatorlari bloklariga guruhlashdi va 2-000 kishi uchun barcha tranzaksiyalarni olib tashlashdi. Va keyin hammasi ishladi.

Agar siz ClickHouse-ga qarasangiz, bularning barchasiga xizmat qiluvchi faqat 3 ta asosiy jadval mavjud.

Jurnallar yuklanadigan birinchi jadval va jurnallar deyarli qayta ishlanmasdan yuklanadi.

Ikkinchi stol. Moddiylashtirilgan ko'rinish orqali, bu jurnallardan hali tegishli bo'lmagan, ya'ni aloqador bo'lmagan voqealar tishlab olindi. Va amalga oshirilgan ko'rinish orqali, oniy tasvirni yaratish uchun tranzaktsiyalar ushbu jurnallardan chiqarildi. Ya'ni, maxsus materiallashtirilgan ko'rinish oniy tasvirni, ya'ni bitimning oxirgi to'plangan holatini qurdi.

Mana SQL da yozilgan matn. Undagi bir nechta muhim narsalarga izoh bermoqchiman.

Birinchi muhim narsa - ClickHouse-da json-dan ustunlar va maydonlarni tortib olish qobiliyati. Ya'ni, ClickHouse json bilan ishlashning ba'zi usullariga ega. Ular juda ibtidoiy.

visitParamExtractInt sizga json-dan atributlarni chiqarish imkonini beradi, ya'ni birinchi hit ishlaydi. Shu tarzda siz tranzaksiya identifikatorini chiqarib olishingiz yoki identifikatorga tashrif buyurishingiz mumkin. Bu safar.

Ikkinchidan, bu erda murakkab materiallashtirilgan maydon qo'llaniladi. Bu nima degani? Bu shuni anglatadiki, siz uni jadvalga kirita olmaysiz, ya'ni kiritilmaydi, u kiritilganda hisoblab chiqiladi va saqlanadi. Joylashtirishda ClickHouse siz uchun ishlaydi. Va keyinroq sizga kerak bo'lgan narsa allaqachon jsondan chiqarilgan.

Bunday holda, materiallashtirilgan ko'rinish xom qatorlar uchundir. Va amalda xom loglar bilan birinchi jadval faqat ishlatiladi. Va u nima qiladi? Birinchidan, u saralashni o'zgartiradi, ya'ni saralash endi tashrif identifikatori bo'yicha o'tadi, chunki biz uning tranzaksiyasini ma'lum bir shaxs uchun tezda tortib olishimiz kerak.

Ikkinchi muhim narsa - index_granularity. Agar siz MergeTree-ni ko'rgan bo'lsangiz, u odatda index_granularity bo'yicha 8 bo'ladi. Bu nima? Bu indeksning siyraklik parametri. ClickHouse-da indeks siyrak, u hech qachon har bir yozuvni indekslamaydi. Buni har 192 marta amalga oshiradi. Va bu juda ko'p ma'lumotlarni hisoblash kerak bo'lganda yaxshi, lekin oz bo'lsa yomon, chunki katta yuk bor. Va agar biz indeksning granularligini kamaytirsak, unda biz qo'shimcha xarajatlarni kamaytiramiz. Uni bittaga qisqartirib bo'lmaydi, chunki xotira yetarli bo'lmasligi mumkin. Indeks har doim xotirada saqlanadi.

Snapshot shuningdek, boshqa qiziqarli ClickHouse xususiyatlaridan foydalanadi.

Birinchidan, bu AggregatingMergeTree. Va AggregatingMergeTree argMax-ni saqlaydi, ya'ni bu oxirgi vaqt tamg'asiga mos keladigan tranzaksiya holati. Bitimlar har doim ma'lum bir tashrif buyuruvchi uchun yaratiladi. Va ushbu tranzaksiyaning eng oxirgi holatida biz voqea qo'shdik va bizda yangi holat mavjud. Bu yana ClickHouse-ga tegdi. Ushbu moddiylashtirilgan ko'rinishda argMax orqali biz har doim joriy holatni olishimiz mumkin.

• Bog'lanish Runtime dan "ajratilgan".
• Oyiga 3 milliardgacha tranzaktsiyalar saqlanadi va qayta ishlanadi. Bu Kassandrada, ya'ni odatiy tranzaksiya tizimida bo'lganidan ko'ra kattaroq tartibdir.
• 2x5 ClickHouse serverlari klasteri. 5 ta server va har bir serverda replika mavjud. Bu chertishga asoslangan atributni amalga oshirish uchun Kassandradagidan ham kamroq va bu erda biz taassurotga asoslanganmiz. Ya'ni, serverlar sonini 30 barobarga oshirish o'rniga, ularni qisqartirishga muvaffaq bo'lishdi.

Va oxirgi misol Y moliyaviy kompaniyasi bo'lib, u aksiyalar bahosidagi o'zgarishlarning korrelyatsiyasini tahlil qildi.

Va vazifa shunday edi:

• Taxminan 5 ta aktsiya mavjud.
• Kotirovkalar har 100 millisekundda ma'lum.
• Ma'lumotlar 10 yil davomida to'plangan. Ko'rinishidan, ba'zi kompaniyalar uchun ko'proq, kimdir uchun kamroq.
• Jami 100 milliardga yaqin qatorlar mavjud.

Va o'zgarishlarning korrelyatsiyasini hisoblash kerak edi.

Mana ikkita aktsiya va ularning kotirovkalari. Agar biri yuqoriga ko'tarilsa, ikkinchisi esa yuqoriga ko'tarilsa, unda bu ijobiy korrelyatsiya, ya'ni biri ko'tariladi, ikkinchisi esa ko'tariladi. Agar grafik oxiridagidek biri yuqoriga ko'tarilsa, ikkinchisi pastga tushsa, bu salbiy korrelyatsiya, ya'ni biri ko'tarilsa, ikkinchisi tushadi.

Ushbu o'zaro o'zgarishlarni tahlil qilib, moliya bozorida bashorat qilish mumkin.

Ammo vazifa qiyin. Buning uchun qanday ishlar qilinmoqda? Bizda 100 milliard yozuv bor: vaqt, aktsiya va narx. Biz narx algoritmidan birinchi 100 milliard marta ishlaydigan farqni hisoblashimiz kerak. RunningDifference - bu ClickHouse-dagi funksiya bo'lib, u ikkita satr orasidagi farqni ketma-ket hisoblab chiqadi.

Va bundan keyin siz korrelyatsiyani hisoblashingiz kerak va korrelyatsiya har bir juftlik uchun hisoblanishi kerak. 5 ta aktsiya uchun juftliklar 000 mln. Va bu juda ko'p, ya'ni 12,5 marta aynan shunday korrelyatsiya funktsiyasini hisoblash kerak.

Va agar kimdir unutgan bo'lsa, u holda ͞x va ͞y mat hisoblanadi. namuna olishni kutish. Ya'ni, nafaqat ildiz va yig'indilarni, balki bu summalar ichida yana bir so'mni ham hisoblash kerak. Bir qator hisob-kitoblarni 12,5 million marta bajarish va hatto soatlar bo'yicha guruhlash kerak. Bizda ham ko'p soatlar bor. Va buni 60 soniya ichida qilishingiz kerak. Bu hazil.

Hech bo'lmaganda qandaydir tarzda vaqt topish kerak edi, chunki bularning barchasi ClickHouse kelishidan oldin juda va juda sekin ishladi.

Ular buni Hadoop-da, Spark-da, Greenplum-da hisoblashga harakat qilishdi. Va bularning barchasi juda sekin yoki qimmat edi. Ya'ni, qandaydir tarzda hisoblash mumkin edi, lekin keyin qimmatga tushdi.

Va keyin ClickHouse paydo bo'ldi va ishlar ancha yaxshilandi.

Sizga shuni eslatib o'tamanki, bizda ma'lumotlarning joylashuvi bilan bog'liq muammo bor, chunki korrelyatsiyalarni mahalliylashtirish mumkin emas. Biz ma'lumotlarning bir qismini bitta serverga, ba'zilarini boshqasiga joylashtira olmaymiz va hisoblay olmaymiz, biz hamma joyda hamma ma'lumotlarga ega bo'lishimiz kerak.

Ular nima qilishdi? Dastlab, ma'lumotlar mahalliylashtiriladi. Har bir server ma'lum bir aktsiyalar to'plamining narxi haqidagi ma'lumotlarni saqlaydi. Va ular bir-biriga mos kelmaydi. Shuning uchun logReturnni parallel va mustaqil ravishda hisoblash mumkin, bularning barchasi hozirgacha parallel va taqsimlangan holda sodir bo'ladi.

Keyin biz ekspressivlikni yo'qotmasdan, bu ma'lumotlarni kamaytirishga qaror qildik. Massivlardan foydalanishni kamaytiring, ya'ni har bir vaqt davri uchun bir qator aktsiyalarni va narxlar qatorini yarating. Shunday qilib, u kamroq ma'lumot maydonini egallaydi. Va ular bilan ishlash biroz osonroq. Bu deyarli parallel operatsiyalar, ya'ni biz qisman parallel ravishda o'qiymiz va keyin serverga yozamiz.

Shundan so'ng uni takrorlash mumkin. "R" harfi biz ushbu ma'lumotlarni takrorlaganimizni anglatadi. Ya'ni, biz uchta serverda bir xil ma'lumotlarga egamiz - bu massivlar.

Va keyin hisoblanishi kerak bo'lgan 12,5 million korrelyatsiya to'plamidan maxsus skript yordamida siz paketlarni yaratishingiz mumkin. Ya'ni, 2 juft korrelyatsiyaga ega bo'lgan 500 ta vazifa. Va bu vazifa ma'lum bir ClickHouse serverida hisoblanishi kerak. U barcha ma'lumotlarga ega, chunki ma'lumotlar bir xil va u ularni ketma-ket hisoblashi mumkin.

Yana bir bor aytaman, bu shunday ko'rinadi. Birinchidan, biz ushbu tuzilmadagi barcha ma'lumotlarga egamiz: vaqt, aktsiyalar, narx. Keyin biz logReturn ni, ya'ni bir xil tuzilmaning ma'lumotlarini hisobladik, lekin narx o'rniga bizda allaqachon logReturn mavjud. Keyin ular qayta ishlangan, ya'ni biz aktsiyalar va narxlar uchun vaqt va groupArray ga ega bo'ldik. Replikatsiya qilingan. Va shundan so'ng biz bir nechta vazifalarni yaratdik va ularni hisoblash uchun ClickHouse-ga berdik. Va u ishlaydi.

Kontseptsiyani isbotlash bo'yicha, vazifa kichik vazifa edi, ya'ni kamroq ma'lumot olindi. Va faqat uchta server.

Birinchi ikki bosqich: Log_return ni hisoblash va massivlarga o'rash taxminan bir soat davom etdi.

Va korrelyatsiyani hisoblash taxminan 50 soatni tashkil qiladi. Lekin 50 soat yetarli emas, chunki ular haftalab ishlashardi. Bu katta muvaffaqiyat edi. Va agar hisoblasangiz, bu klasterda hamma narsa soniyada 70 marta hisoblangan.

Lekin eng muhimi shundaki, bu tizim amalda to'siqsiz, ya'ni deyarli chiziqli ravishda o'lchaydi. Va ular buni tekshirishdi. Uni muvaffaqiyatli kengaytirdi.

• To'g'ri sxema - bu urushning yarmi. Va to'g'ri sxema - barcha kerakli ClickHouse texnologiyalaridan foydalanish.
• Summing/AggregatingMergeTrees - bu shtat snapshotini alohida holat sifatida jamlash yoki ko'rib chiqish imkonini beruvchi texnologiyalar. Va bu juda ko'p narsalarni soddalashtiradi.
• Materiallashtirilgan ko'rinishlar bir indeks chegarasini chetlab o'tishga imkon beradi. Ehtimol, men buni juda aniq aytmadim, lekin biz jurnallarni yuklaganimizda, xom jurnallar bitta indeks bilan jadvalda va atribut jurnallari jadvalda edi, ya'ni bir xil ma'lumotlar, faqat filtrlangan, lekin indeks to'liq edi. boshqalar. Bu bir xil ma'lumotlarga o'xshaydi, lekin turli xil saralash. Va Materialized Views, agar kerak bo'lsa, bunday ClickHouse cheklovini chetlab o'tishga imkon beradi.
• Nuqta so'rovlari uchun indeksning granularligini kamaytiring.
• Va ma'lumotlarni oqilona taqsimlang, iloji boricha server ichidagi ma'lumotlarni mahalliylashtirishga harakat qiling. Va iloji boricha so'rovlar mahalliylashtirishdan foydalanishiga ishonch hosil qilishga harakat qiling.

Va bu qisqa nutqni sarhisob qilsak, shuni aytishimiz mumkinki, ClickHouse endi tijorat ma'lumotlar bazalari va ochiq manba ma'lumotlar bazalari, ya'ni, ayniqsa, tahliliy ma'lumotlar bazalari hududini mustahkam egalladi. U bu manzaraga juda mos tushadi. Bundan tashqari, u asta-sekin boshqalarni siqib chiqara boshlaydi, chunki sizda ClickHouse mavjud bo'lganda, sizga InfiniDB kerak emas. Agar ular oddiy SQL-ni qo'llab-quvvatlasa, Vertika tez orada kerak bo'lmasligi mumkin. Rohatlaning!

-Hisobot uchun rahmat! Juda qiziq! Apache Feniks bilan taqqoslashlar bo'lganmi?

Yo'q, men hech kimni taqqoslaganini eshitmadim. Biz va Yandex turli ma'lumotlar bazalari bilan barcha ClickHouse taqqoslashlarini kuzatib borishga harakat qilamiz. Chunki to'satdan nimadir ClickHouse'dan tezroq bo'lib chiqsa, u holda Lesha Milovidov kechasi uxlay olmaydi va tezda tezlasha boshlaydi. Men bunday taqqoslash haqida eshitmaganman.

• (Aleksey Milovidov) Apache Phoenix - bu Hbase tomonidan boshqariladigan SQL dvigateli. Hbase asosan kalit-qiymatli ish stsenariysi uchun. U erda har bir satrda o'zboshimchalik nomlari bilan ixtiyoriy sonli ustunlar bo'lishi mumkin. Buni Hbase, Cassandra kabi tizimlar haqida aytish mumkin. Va aynan og'ir analitik so'rovlar ular uchun normal ishlamaydi. Yoki ClickHouse bilan hech qanday tajribaga ega bo'lmagan bo'lsangiz, ular yaxshi ishlaydi deb o'ylashingiz mumkin.

• Rahmat

  • Hayrli kun! Men bu mavzuga allaqachon qiziqaman, chunki menda analitik quyi tizim bor. Ammo ClickHouse-ga qaraganimda, ClickHouse voqealarni tahlil qilish uchun juda mos ekanligini his qilaman, o'zgaruvchan. Va agar men ko'plab biznes ma'lumotlarini bir nechta katta jadvallar bilan tahlil qilishim kerak bo'lsa, men tushunganimdek, ClickHouse men uchun unchalik mos emasmi? Ayniqsa, agar ular o'zgarsa. Bu to'g'rimi yoki buni rad etadigan misollar bormi?

  • Bu to'g'ri. Va bu ko'pchilik ixtisoslashgan analitik ma'lumotlar bazalariga tegishli. Ular o'zgaruvchan bir yoki bir nechta katta jadvallar mavjudligi va sekin o'zgarib turadigan ko'plab kichik jadvallar uchun mo'ljallangan. Ya'ni, ClickHouse Oracle-ga o'xshamaydi, bu erda siz hamma narsani qo'yishingiz va juda murakkab so'rovlarni yaratishingiz mumkin. ClickHouse-dan samarali foydalanish uchun siz ClickHouse-da yaxshi ishlaydigan tarzda sxema yaratishingiz kerak. Ya'ni, ortiqcha normallashtirishdan qoching, lug'atlardan foydalaning, kamroq uzun havolalar qilishga harakat qiling. Va agar sxema shu tarzda qurilgan bo'lsa, unda shunga o'xshash biznes vazifalari ClickHouse-da an'anaviy relyatsion ma'lumotlar bazasiga qaraganda ancha samaraliroq hal qilinishi mumkin.

Hisobot uchun rahmat! Menda oxirgi moliyaviy ish haqida savolim bor. Ularda analitik bor edi. Ularning yuqoriga va pastga tushishini solishtirish kerak edi. Va siz tizimni ushbu tahlil uchun maxsus qurganingizni tushunaman? Agar ertaga, masalan, ularga ushbu ma'lumotlar bo'yicha boshqa hisobot kerak bo'lsa, ular sxemani qayta qurishlari va ma'lumotlarni yuklashlari kerakmi? Ya'ni, so'rovni olish uchun qandaydir oldindan ishlov berish kerakmi?

Albatta, bu juda aniq vazifa uchun ClickHouse-dan foydalanish. Buni an'anaviy tarzda Hadoop ichida hal qilish mumkin edi. Hadoop uchun bu ideal vazifa. Ammo Hadoop-da bu juda sekin. Va mening maqsadim ClickHouse odatda butunlay boshqa vositalar bilan hal qilinadigan vazifalarni hal qila olishini ko'rsatishdir, lekin ayni paytda uni ancha samarali bajaradi. Bu ma'lum bir vazifa uchun mo'ljallangan. Ma'lumki, agar shunga o'xshash narsa bilan muammo bo'lsa, uni shunga o'xshash tarzda hal qilish mumkin.

Tushunarli. Siz 50 soat ishlov berilganini aytdingiz. Bu eng boshidanmi, qachon ma'lumotlarni yukladingiz yoki natijalarni oldingizmi?

Ha ha.

OK sizga katta rahmat.

Bu 3 ta server klasterida.

Salom! Hisobot uchun rahmat! Hammasi juda qiziq. Men funksionallik haqida bir oz so'ramayman, lekin barqarorlik nuqtai nazaridan ClickHouse-dan foydalanish haqida. Ya'ni, sizda bormi, qayta tiklashingiz kerakmi? Bu holatda ClickHouse qanday harakat qiladi? Va shunday bo'ldiki, sizda ham replika bormi? Misol uchun, biz ClickHouse bilan bog'liq muammoga duch keldik, qachonki u o'z chegarasidan chiqib, tushib qolsa.

Albatta, ideal tizimlar mavjud emas. ClickHouse-ning ham o'z muammolari bor. Ammo Yandex.Metrica uzoq vaqt davomida ishlamayotgani haqida eshitganmisiz? Balki yo'q. 2012-2013 yillarda ClickHouse-da ishonchli ishlamoqda. O'z tajribam haqida ham shunday deyishim mumkin. Biz hech qachon to'liq muvaffaqiyatsizlikka uchramaganmiz. Ba'zi qisman narsalar sodir bo'lishi mumkin, ammo ular biznesga jiddiy ta'sir ko'rsatadigan darajada muhim emas edi. Bu hech qachon sodir bo'lmagan. ClickHouse juda ishonchli va tasodifiy qulab tushmaydi. Bu haqda tashvishlanishingiz shart emas. Bu xom narsa emas. Bu ko'plab kompaniyalar tomonidan tasdiqlangan.

Salom! Siz darhol ma'lumotlar sxemasini o'ylab ko'rishingiz kerakligini aytdingiz. Agar shunday bo'lgan bo'lsa-chi? Mening ma'lumotlarim to'kilmoqda va to'kilmoqda. Olti oy o'tdi va men bunday yashashning iloji yo'qligini tushunaman, men ma'lumotlarni qayta yuklashim va ular bilan biror narsa qilishim kerak.

Bu, albatta, tizimingizga bog'liq. Buni deyarli to'xtamasdan qilishning bir necha yo'li mavjud. Misol uchun, agar uni yagona xaritalash mumkin bo'lsa, boshqa ma'lumotlar strukturasini yaratish uchun Materiallashtirilgan ko'rinish yaratishingiz mumkin. Ya'ni, agar u ClickHouse yordamida xaritalash imkonini bersa, ya'ni ba'zi narsalarni ajratib oling, asosiy kalitni o'zgartiring, bo'linishni o'zgartiring, keyin siz Materialized View qilishingiz mumkin. U erda eski ma'lumotlaringizni qayta yozing, yangilari avtomatik ravishda yoziladi. Va keyin shunchaki Materialized View-dan foydalanishga o'ting, keyin yozuvni almashtiring va eski jadvalni o'ldiring. Bu odatda to'xtovsiz usul.

Rahmat.

Manba: www.habr.com