Teorya at kasanayan ng paggamit ng ClickHouse sa totoong mga aplikasyon. Alexander Zaitsev (2018)

Sa kabila ng katotohanan na mayroon na ngayong maraming data sa halos lahat ng dako, ang mga analytical database ay medyo kakaiba pa rin. Ang mga ito ay hindi gaanong kilala at kahit na hindi gaanong epektibong gamitin ang mga ito. Marami ang patuloy na "kumain ng cactus" gamit ang MySQL o PostgreSQL, na idinisenyo para sa iba pang mga sitwasyon, nakikipagpunyagi sa NoSQL, o sobrang bayad para sa mga komersyal na solusyon. Ang ClickHouse ay isang game changer at makabuluhang pinabababa ang hadlang sa pagpasok sa mundo ng analytical DBMS.

Ang ulat ay mula sa BackEnd Conf 2018 at na-publish ito nang may pahintulot ng tagapagsalita.

Sino ako at bakit ko pinag-uusapan ang ClickHouse? Ako ang Direktor ng Pag-unlad sa LifeStreet, na gumagamit ng ClickHouse. Ako din ang founder ng Altinity. Isa itong kasosyo sa Yandex na nagpo-promote ng ClickHouse at tumutulong sa Yandex na gawing mas matagumpay ang ClickHouse. Handa na rin akong magbahagi ng kaalaman tungkol sa ClickHouse.

At hindi rin ako kapatid ni Petya Zaitsev. Madalas akong tinatanong tungkol dito. Hindi, hindi kami magkapatid.

"Alam ng lahat" na ang ClickHouse:

• Napakabilis,
• Napaka maginhawa,
• Ginamit sa Yandex.

Medyo hindi gaanong kilala kung aling mga kumpanya at kung paano ito ginagamit.

Sasabihin ko sa iyo kung bakit, saan at paano ginagamit ang ClickHouse, bukod sa Yandex.

Sasabihin ko sa iyo kung paano nalulutas ang mga partikular na problema gamit ang ClickHouse sa iba't ibang kumpanya, kung anong mga tool ng ClickHouse ang magagamit mo para sa iyong mga gawain, at kung paano ginamit ang mga ito sa iba't ibang kumpanya.

Pumili ako ng tatlong halimbawa na nagpapakita ng ClickHouse mula sa iba't ibang panig. Sa tingin ko ito ay magiging kawili-wili.

Ang unang tanong ay: "Bakit kailangan natin ng ClickHouse?" Tila ang tanong ay medyo halata, ngunit mayroong higit sa isang sagot dito.

• Ang unang sagot ay para sa mga dahilan ng pagganap. Napakabilis ng ClickHouse. Ang Analytics sa ClickHouse ay napakabilis din. Madalas itong magamit kung saan ang ibang bagay ay gumagana nang napakabagal o napakahina.
• Ang pangalawang sagot ay gastos. At una sa lahat, ang halaga ng scaling. Halimbawa, ang Vertica ay isang ganap na mahusay na database. Gumagana ito nang mahusay kung wala kang maraming terabytes ng data. Ngunit kapag pinag-uusapan natin ang tungkol sa daan-daang terabytes o petabytes, ang halaga ng isang lisensya at suporta ay medyo malaking halaga. At ito ay mahal. At ang ClickHouse ay libre.
• Ang pangatlong sagot ay operating cost. Ito ay isang bahagyang naiibang diskarte. Ang RedShift ay isang mahusay na analogue. Sa RedShift makakagawa ka ng desisyon nang napakabilis. Ito ay gagana nang maayos, ngunit sa parehong oras, bawat oras, araw-araw at bawat buwan ay magbabayad ka ng malaki sa Amazon, dahil ito ay isang makabuluhang mahal na serbisyo. Ang Google BigQuery din. Kung may gumamit nito, alam niya na maaari kang magpatakbo ng maraming query doon at biglang makatanggap ng invoice para sa daan-daang dolyar.

Ang ClickHouse ay walang mga problemang ito.

Saan ginagamit ngayon ang ClickHouse? Bilang karagdagan sa Yandex, ang ClickHouse ay ginagamit sa isang grupo ng iba't ibang mga negosyo at kumpanya.

• Una sa lahat, ito ay web application analytics, ibig sabihin, ito ay isang use case na nagmula sa Yandex.
• Maraming kumpanya ng AdTech ang gumagamit ng ClickHouse.
• Maraming mga kumpanya na kailangang pag-aralan ang mga log ng pagpapatakbo mula sa iba't ibang mga mapagkukunan.
• Maraming mga kumpanya ang gumagamit ng ClickHouse upang subaybayan ang mga log ng seguridad. Ina-upload nila ang mga ito sa ClickHouse, gumawa ng mga ulat, at makuha ang mga resulta na kailangan nila.
• Nagsisimula nang gamitin ito ng mga kumpanya sa pagsusuri sa pananalapi, ibig sabihin, unti-unting lumalapit ang malalaking negosyo sa ClickHouse.
• CloudFlare. Kung sinuman ang sumusunod sa ClickHouse, malamang narinig mo na ang pangalan ng kumpanyang ito. Ito ay isa sa mga makabuluhang kontribusyon mula sa komunidad. At mayroon silang napakaseryosong pag-install ng ClickHouse. Halimbawa, gumawa sila ng Kafka Engine para sa ClickHouse.
• Nagsimula nang gamitin ang mga kumpanya ng telekomunikasyon. Maraming mga kumpanya ang gumagamit ng ClickHouse bilang patunay sa konsepto o nasa produksyon na.
• Ang isang kumpanya ay gumagamit ng ClickHouse upang subaybayan ang mga proseso ng produksyon. Sinusubukan nila ang mga microcircuits, isulat ang isang grupo ng mga parameter, mayroong mga 2 na katangian. At pagkatapos ay ina-analyze nila kung maganda o masama ang batch.
• Blockchain analytics. Mayroong isang kumpanyang Ruso na tinatawag na Bloxy.info. Ito ay isang pagsusuri ng Ethereum network. Ginawa rin nila ito sa ClickHouse.

Bukod dito, hindi mahalaga ang laki. Mayroong maraming mga kumpanya na gumagamit ng isang maliit na server. At hinahayaan niya silang lutasin ang kanilang mga problema. At mas maraming kumpanya ang gumagamit ng malalaking kumpol ng maraming server o dose-dosenang mga server.

At kung titingnan mo ang mga talaan, kung gayon:

• Yandex: 500+ server, nag-iimbak sila ng 25 bilyong record sa isang araw doon.
• LifeStreet: 60 server, humigit-kumulang 75 bilyong talaan bawat araw. Mayroong mas kaunting mga server at mas maraming tala kaysa sa Yandex.
• CloudFlare: 36 na server, nag-iimbak sila ng 200 bilyong talaan bawat araw. Mayroon silang mas kaunting mga server at nag-iimbak ng higit pang data.
• Bloomberg: 102 server, humigit-kumulang isang trilyong talaan bawat araw. Tagahawak ng rekord.

Sa heograpiya, marami rin ito. Ipinapakita ng mapa na ito ang heatmap kung saan ginagamit ang ClickHouse sa mundo. Dito malinaw na namumukod-tangi ang Russia, China, at America. Mayroong ilang mga bansa sa Europa. At 4 na kumpol ay maaaring makilala.

Ito ay isang paghahambing na pagsusuri, hindi na kailangang maghanap ng mga ganap na numero. Isa itong pagsusuri ng mga bisitang nagbabasa ng mga materyal sa wikang Ingles sa website ng Altinity, dahil walang mga nagsasalita ng Ruso doon. At ang Russia, Ukraine, Belarus, ibig sabihin, ang bahagi ng komunidad na nagsasalita ng Ruso, ay ang pinakamaraming gumagamit. Pagkatapos ay ang USA at Canada. Ang Tsina ay nahuhuli nang husto. Halos walang China doon anim na buwan na ang nakalipas; ngayon ay nalampasan na ng China ang Europa at patuloy na lumalaki. Hindi rin nahuhuli ang Old Europe, at ang nangunguna sa paggamit ng ClickHouse ay, kakaiba, France.

Bakit ko sinasabi ang lahat ng ito? Upang ipakita na ang ClickHouse ay nagiging isang karaniwang solusyon para sa malaking pagsusuri ng data at ginagamit na sa maraming lugar. Kung gagamitin mo ito, ikaw ay nasa tamang kalakaran. Kung hindi mo pa ito ginagamit, hindi mo kailangang matakot na maiiwan kang mag-isa at walang tutulong sa iyo, dahil marami na ang gumagawa nito.

Ito ay mga halimbawa ng tunay na paggamit ng ClickHouse sa ilang kumpanya.

• Ang unang halimbawa ay isang network ng advertising: paglipat mula sa Vertica patungo sa ClickHouse. At may alam akong ilang kumpanya na lumipat mula sa Vertica o nasa proseso ng paglipat.
• Ang pangalawang halimbawa ay ang transactional storage sa ClickHouse. Ito ay isang halimbawa na binuo sa mga antipattern. Lahat ng hindi kailangang gawin sa ClickHouse ayon sa payo ng mga developer ay ginagawa dito. At sa parehong oras ito ay tapos na kaya epektibo na ito ay gumagana. At ito ay gumagana nang mas mahusay kaysa sa isang tipikal na transactional na solusyon.
• Ang ikatlong halimbawa ay ipinamahagi na computing sa ClickHouse. May tanong tungkol sa kung paano maisasama ang ClickHouse sa Hadoop ecosystem. Magpapakita ako ng isang halimbawa kung paano ginawa ng isang kumpanya ang isang bagay na katulad ng mapa bawasan ang lalagyan sa ClickHouse, pagsubaybay sa lokalisasyon ng data, atbp., upang makalkula ang isang napaka-di-trivial na gawain.

• Ang LifeStreet ay isang kumpanya ng Ad Tech na mayroong lahat ng teknolohiyang nauugnay sa isang network ng advertising.
• Siya ay nakikibahagi sa ad optimization at programmatic bidding.
• Maraming data: humigit-kumulang 10 bilyong kaganapan bawat araw. Bukod dito, maaaring hatiin ang mga kaganapan sa ilang mga sub-kaganapan.
• Maraming kliyente ang data na ito, at hindi lang mga tao ang mga ito, marami pa ang iba't ibang algorithm na nakikibahagi sa programmatic na pag-bid.

Ang kumpanya ay dumating sa isang mahaba at matinik na landas. At napag-usapan ko ito sa HighLoad. Una, lumipat ang LifeStreet mula sa MySQL (na may maikling paghinto sa Oracle) patungo sa Vertica. At makakahanap ka ng kwento tungkol dito.

At lahat ay napakahusay, ngunit mabilis na naging malinaw na ang data ay lumalaki at ang Vertica ay mahal. Samakatuwid, ang iba't ibang mga alternatibo ay hinanap. Ang ilan sa mga ito ay nakalista dito. At sa katunayan, gumawa kami ng patunay ng konsepto o kung minsan ay pagsubok sa pagganap ng halos lahat ng mga database na magagamit sa merkado mula 13 hanggang 16 at tinatayang angkop sa functionality. At napag-usapan ko rin ang ilan sa kanila sa HighLoad.

Ang gawain ay lumipat muna mula sa Vertica, dahil lumalaki ang data. At sila ay lumago nang husto sa loob ng ilang taon. Pagkatapos ay pumunta sila sa istante, ngunit pa rin. At hinuhulaan ang paglago na ito, mga kinakailangan sa negosyo para sa dami ng data kung saan kailangang gawin ang ilang uri ng analytics, malinaw na sa lalong madaling panahon magkakaroon ng pag-uusap tungkol sa mga petabytes. At napakamahal na magbayad para sa mga petabytes, kaya naghanap kami ng alternatibo kung saan pupunta.

Saan pupunta? At sa loob ng mahabang panahon ay ganap na hindi malinaw kung saan pupunta, dahil sa isang banda mayroong mga komersyal na database, tila gumagana nang maayos. Ang ilan ay gumagana halos kasinghusay ng Vertica, ang ilan ay mas masahol pa. Ngunit lahat sila ay mahal, walang mas mura o mas mahusay na mahahanap.

Sa kabilang banda, may mga open source na solusyon, kung saan hindi masyadong marami, ibig sabihin, para sa analytics, mabibilang sila sa isang banda. At sila ay libre o mura, ngunit sila ay gumagana nang mabagal. At madalas silang kulang sa kinakailangan at kapaki-pakinabang na pag-andar.

At walang pagsamahin ang magagandang bagay na nasa mga komersyal na database at lahat ng mga libreng bagay na nasa open source.

Walang nangyari hanggang sa biglang hinila ni Yandex ang ClickHouse mula sa isang sumbrero tulad ng kuneho ng isang salamangkero. At ito ay isang hindi inaasahang desisyon; ang mga tao ay nagtatanong pa rin ng tanong: "Bakit?", ngunit gayunpaman.

At kaagad sa tag-araw ng 2016, sinimulan naming tingnan kung ano ang ClickHouse. At ito ay naging mas mabilis kung minsan kaysa sa Vertica. Sinubukan namin ang iba't ibang mga sitwasyon sa iba't ibang kahilingan. At kung ang query ay gumamit lamang ng isang talahanayan, ibig sabihin, nang walang anumang pagsali, ang ClickHouse ay dalawang beses na mas mabilis kaysa sa Vertica.

Hindi ako masyadong tamad at tumingin sa higit pang mga pagsubok sa Yandex noong isang araw. Pareho rin doon: Ang ClickHouse ay dalawang beses na mas mabilis kaysa sa Vertica, kaya madalas nilang pag-usapan ito.

Ngunit kung ang mga query ay naglalaman ng mga pagsali, kung gayon ang lahat ay hindi masyadong malinaw. At ang ClickHouse ay maaaring dalawang beses na mas mabagal kaysa sa Vertica. At kung itatama mo at muling isulat ang kahilingan nang kaunti, kung gayon ang mga ito ay humigit-kumulang pantay. Hindi masama. At ito ay libre.

At pagkatapos matanggap ang mga resulta ng pagsubok, at tingnan ito mula sa iba't ibang mga anggulo, pumunta ang LifeStreet sa ClickHouse.

Ito ang ika-16 na taon, ipinaalala ko sa iyo. Parang biro ng mga daga na umiyak at nag-inject ng sarili, pero patuloy na kinakain ang cactus. At ito ay tinalakay nang detalyado, mayroong isang video tungkol dito, atbp.

Samakatuwid, hindi ko ito pag-uusapan nang detalyado, sasabihin ko lamang ang tungkol sa mga resulta at ilang mga kagiliw-giliw na bagay na hindi ko napag-usapan noon.

Ang mga resulta ay:

• Ang matagumpay na paglipat at ang sistema ay nasa produksyon nang higit sa isang taon.
• Ang pagiging produktibo at kakayahang umangkop ay tumaas. Mula sa 10 bilyong talaan na kayang-kaya nating iimbak bawat araw sa maikling panahon lamang, ang LifeStreet ay nag-iimbak na ngayon ng 75 bilyong talaan bawat araw at magagawa ito sa loob ng 3 buwan o higit pa. Kung magbibilang ka sa tuktok, ito ay nakaimbak ng hanggang sa isang milyong mga kaganapan sa bawat segundo. Mahigit sa isang milyong SQL query sa isang araw ang ipinapadala sa system na ito, karamihan ay mula sa iba't ibang mga robot.
• Sa kabila ng katotohanan na ang ClickHouse ay nagsimulang gumamit ng higit pang mga server kaysa sa Vertica, ang mga pagtitipid ay ginawa din sa hardware, dahil ang Vertica ay gumamit ng medyo mahal na mga disk ng SAS. Gumamit ang ClickHouse ng SATA. At bakit? Dahil sa Vertica insert ay kasabay. At ang pag-synchronize ay nangangailangan na ang mga disk ay hindi masyadong bumagal, at ang network ay hindi masyadong bumagal, ibig sabihin, isang medyo mahal na operasyon. At sa ClickHouse insert ay asynchronous. Bukod dito, maaari mong palaging isulat ang lahat nang lokal, walang mga karagdagang gastos para dito, kaya ang data ay maaaring maipasok sa ClickHouse nang mas mabilis kaysa sa Vertika, kahit na hindi sa pinakamabilis na mga disk. At ang pagbabasa ay halos pareho. Ang pagbabasa sa SATA, kung sila ay nasa RAID, kung gayon ang lahat ay sapat na mabilis.
• Walang limitasyon sa pamamagitan ng lisensya, ibig sabihin, 3 petabytes ng data sa 60 server (20 server ang isang replika) at 6 trilyong tala sa mga katotohanan at pinagsama-samang. Hindi kayang bayaran ni Vertica ang ganito.

Ngayon napupunta ako sa mga praktikal na bagay sa halimbawang ito.

• Ang una ay isang epektibong pamamaraan. Marami ang nakasalalay sa scheme.
• Ang pangalawa ay ang pagbuo ng mahusay na SQL.

Ang isang karaniwang query sa OLAP ay piliin. Ang ilang column ay napupunta sa pangkat ayon, ang ilang column ay napupunta sa pinagsama-samang mga function. Mayroong kung saan, na maaaring isipin bilang isang slice ng isang kubo. Ang buong pangkat ni ay maaaring isipin bilang isang projection. At iyon ang dahilan kung bakit ito ay tinatawag na multivariate data analysis.

At madalas na ito ay na-modelo sa anyo ng isang diagram ng bituin, kapag mayroong isang sentral na katotohanan at mga katangian ng katotohanang ito sa mga gilid, kasama ang mga sinag.

At mula sa punto ng view ng pisikal na disenyo, kung paano ito umaangkop sa talahanayan, kadalasan ay gumagawa sila ng isang normal na representasyon. Maaari kang mag-denormalize, ngunit ito ay mahal sa disk at hindi masyadong mahusay sa mga query. Samakatuwid, kadalasan ay gumagawa sila ng normalized na view, ibig sabihin, isang fact table at marami, maraming dimensyon na talahanayan.

Ngunit hindi ito gumagana nang maayos sa ClickHouse. Mayroong dalawang dahilan:

• Ang una ay dahil ang ClickHouse ay walang napakahusay na pagsali, ibig sabihin, may mga pagsali, ngunit sila ay masama. Sa ngayon ay masama sila.
• Ang pangalawa ay ang mga talahanayan ay hindi na-update. Kadalasan sa mga palatandaang ito na nasa paligid ng diagram ng bituin, may kailangang baguhin. Halimbawa, pangalan ng kliyente, pangalan ng kumpanya, atbp. At hindi ito gumagana.

At mayroong isang paraan sa ClickHouse. kahit dalawa:

• Ang una ay ang paggamit ng mga diksyunaryo. Ang mga Panlabas na Diksyunaryo ay kung ano ang tumutulong sa 99% na malutas ang problema sa star scheme, may mga update at iba pa.
• Ang pangalawa ay ang paggamit ng mga arrays. Nakakatulong din ang mga array na maalis ang mga pagsali at mga problema sa normalisasyon.

• Hindi na kailangang sumali.
• Naa-update. Mula noong Marso 2018, lumitaw ang isang hindi dokumentadong pagkakataon (hindi mo ito mahahanap sa dokumentasyon) upang bahagyang i-update ang mga diksyunaryo, ibig sabihin, ang mga entry na iyon na nagbago. Sa pagsasagawa, ito ay tulad ng isang mesa.
• Palaging nasa memorya, kaya ang pagsali sa isang diksyunaryo ay gumagana nang mas mabilis kaysa sa kung ito ay isang talahanayan na nasa disk at hindi ito isang katotohanan na ito ay nasa cache, malamang na wala.

• Hindi mo rin kailangan sumali.
• Ito ay isang compact 1 sa maraming representasyon.
• At sa aking opinyon, ang mga array ay ginawa para sa mga geeks. Ito ang mga function ng lambda at iba pa.

Ito ay hindi para sa kapakanan ng mga salita. Ito ay isang napakalakas na functionality na nagbibigay-daan sa iyong gawin ang maraming bagay nang napakasimple at elegante.

Mga karaniwang halimbawa na tumutulong sa paglutas ng mga array. Ang mga halimbawang ito ay simple at medyo malinaw:

• Maghanap sa pamamagitan ng mga tag. Kung mayroon kang mga hashtag doon at nais na makahanap ng ilang mga post sa pamamagitan ng hashtag.
• Maghanap ayon sa mga pares ng key-value. Mayroon ding ilang mga katangian na may kahulugan.
• Pag-iimbak ng mga listahan ng mga susi na kailangan mong isalin sa ibang bagay.

Ang lahat ng mga problemang ito ay maaaring malutas nang walang mga array. Maaaring ilagay ang mga tag sa ilang linya at piliin gamit ang isang regular na expression, o sa isang hiwalay na talahanayan, ngunit pagkatapos ay kailangan mong gumawa ng mga pagsali.

Ngunit sa ClickHouse wala kang kailangang gawin, ilarawan lamang ang isang string array para sa mga hashtag o lumikha ng isang nested na istraktura para sa mga key-value system.

Ang isang nested na istraktura ay maaaring hindi ang pinakamahusay na pangalan. Ito ay dalawang array na may isang karaniwang bahagi sa pangalan at ilang mga kaugnay na katangian.

At napakadaling maghanap sa pamamagitan ng tag. May function has, na nagsusuri na ang array ay naglalaman ng isang elemento. Lahat, nakita namin ang lahat ng mga entry na nauugnay sa aming kumperensya.

Ang paghahanap sa pamamagitan ng subid ay medyo mas kumplikado. Kailangan muna nating hanapin ang index ng susi, at pagkatapos ay kunin ang elemento na may ganitong index at suriin kung ang halagang ito ang kailangan natin. Ngunit gayunpaman napaka-simple at compact.

Ang regular na expression na gusto mong isulat, kung iimbak mo ang lahat sa isang linya, ito ay, una sa lahat, malamya. At, pangalawa, nagtrabaho ito nang mas mahaba kaysa sa dalawang array.

Isa pang halimbawa. Mayroon kang array kung saan nag-iimbak ka ng mga ID. At maaari mong isalin ang mga ito sa mga pangalan. Function arrayMap. Isa itong tipikal na function ng lambda. Nagpapasa ka ng mga lambda expression doon. At inilabas niya ang halaga ng pangalan para sa bawat ID mula sa diksyunaryo.

Maaari kang magsagawa ng paghahanap sa parehong paraan. Ang isang function ng predicate ay ipinasa, na nagsusuri kung ano ang tumutugma sa mga elemento.

Ang mga bagay na ito ay lubos na pinasimple ang circuit at malulutas ang isang grupo ng mga problema.

Ngunit ang susunod na problema na nakatagpo namin at nais kong banggitin ay mahusay na mga query.

• Walang tagaplano ng query ang ClickHouse. Talagang hindi.
• Ngunit gayunpaman, ang mga kumplikadong query ay kailangan pa ring planuhin. Sa anong mga kaso?
• Kung ang kahilingan ay may ilang mga pagsali, na ibalot mo sa mga subselect. At mahalaga ang pagkakasunud-sunod ng mga ito.
• At pangalawa, kung ang kahilingan ay ipinamahagi. Dahil sa isang distributed na query, tanging ang pinakaloob na subselect ang ipapatupad sa isang distributed na paraan, at lahat ng iba pa ay ipapadala sa isang server kung saan ka nakakonekta at nag-execute doon. Samakatuwid, kung namahagi ka ng mga query na may maraming pagsali, kailangan mong pumili ng isang order.

At kahit na sa mas simpleng mga kaso, kung minsan kailangan mo ring gawin ang gawain ng scheduler at muling isulat ang mga query nang kaunti.

Narito ang isang halimbawa. Sa kaliwang bahagi ay isang query na nagpapakita ng nangungunang 5 bansa. At ito ay tumatakbo sa loob ng 2,5 segundo, sa palagay ko. At sa kanang bahagi ay ang parehong kahilingan, ngunit bahagyang muling isinulat. Sa halip na magpangkat ayon sa string, sinimulan namin ang pagpapangkat ayon sa key (int). At ito ay mas mabilis. At pagkatapos ay ikinonekta namin ang isang diksyunaryo sa resulta. Sa halip na 2,5 segundo, ang kahilingan ay tumatagal ng 1,5 segundo. Mabuti ito.

Isang katulad na halimbawa sa muling pagsusulat ng mga filter. Narito ang isang kahilingan para sa Russia. Tumatakbo ito ng 5 segundo. Kung muling isusulat natin ito sa paraang muli nating ihahambing hindi isang string, ngunit mga numero na may ilang hanay ng mga key na iyon na nauugnay sa Russia, kung gayon ito ay magiging mas mabilis.

Maraming ganyang pakulo. At binibigyang-daan ka nila na makabuluhang pabilisin ang mga query na sa tingin mo ay tumatakbo nang mabilis, o, sa kabaligtaran, ay tumatakbo nang mabagal. Maaari silang gawin nang mas mabilis.

• Pinakamataas na trabaho sa distributed mode.
• Pag-uuri ayon sa kaunting uri, tulad ng ginawa ko sa pamamagitan ng ints.
• Kung mayroong anumang mga pagsali o mga diksyunaryo, kung gayon mas mahusay na gawin ang mga ito nang huli, kapag mayroon ka nang data na hindi bababa sa bahagyang naka-grupo, pagkatapos ay ang operasyon ng pagsali o pagtawag sa diksyunaryo ay tatawagin nang mas kaunting beses at ito ay magiging mas mabilis.
• Pagpapalit ng mga filter.

May iba pang technique, hindi lang yung mga pinakita ko. At lahat ng mga ito kung minsan ay nagbibigay-daan sa iyo upang makabuluhang mapabilis ang pagpapatupad ng mga query.

Lumipat tayo sa susunod na halimbawa. Kumpanya X mula sa USA. Ano ang ginagawa niya?

May isang gawain:

• Offline na pag-link ng mga transaksyon sa advertising.
• Simulation ng iba't ibang mga umiiral na modelo.

Ano ang senaryo?

Ang isang ordinaryong bisita ay bumibisita sa site, halimbawa, 20 beses sa isang buwan mula sa iba't ibang mga ad, o kung minsan ay dumarating lamang siya nang walang anumang mga ad, dahil naaalala niya ang site na ito. Tinitingnan ang ilang mga produkto, inilalagay ang mga ito sa basket, inilabas ang mga ito sa basket. At sa huli, may bibilhin siya.

Mga makatwirang tanong: "Sino ang dapat magbayad para sa advertising, kung kinakailangan?" at "Anong advertising, kung mayroon man, ang nakaimpluwensya sa kanya?" Ibig sabihin, bakit siya bumili at paano masigurado na ang mga taong katulad ng taong ito ay bibili rin?

Upang malutas ang problemang ito, kailangan mong ikonekta ang mga kaganapan na nagaganap sa website sa tamang paraan, iyon ay, kahit papaano ay bumuo ng isang koneksyon sa pagitan nila. Pagkatapos ay inilipat sila para sa pagsusuri sa DWH. At batay sa pagsusuring ito, bumuo ng mga modelo kung sino ang ipapakita kung anong advertising.

Ang isang transaksyon sa advertising ay isang hanay ng mga nauugnay na kaganapan ng user na nagsisimula sa isang ad na ipinapakita, pagkatapos ay may nangyari, pagkatapos ay maaaring isang pagbili, at pagkatapos ay maaaring may mga pagbili sa loob ng isang pagbili. Halimbawa, kung ito ay isang mobile application o isang mobile na laro, kung gayon kadalasan ay libre ang pag-install ng application, ngunit kung may gagawin pa doon, maaaring mangailangan ito ng pera. At kung mas maraming gumagastos ang isang tao sa app, mas mahalaga ito. Ngunit para dito kailangan mong ikonekta ang lahat.

Mayroong maraming mga umiiral na mga modelo.

Ang pinakasikat ay:

• Huling Pakikipag-ugnayan, kung saan ang pakikipag-ugnayan ay alinman sa isang pag-click o isang impression.
• Unang Pakikipag-ugnayan, ibig sabihin, ang unang bagay na nagdala sa isang tao sa site.
• Linear na kumbinasyon - pantay na bahagi para sa lahat.
• Attenuation.
• At iba pa.

At paano gumana ang lahat sa simula? May Runtime at Cassandra. Ginamit si Cassandra bilang imbakan ng transaksyon, ibig sabihin, lahat ng kaugnay na transaksyon ay nakaimbak dito. At kapag naganap ang ilang kaganapan sa Runtime, halimbawa, ang pagpapakita ng isang pahina o iba pa, isang kahilingan ang ginawa kay Cassandra kung may ganoong tao o wala. Pagkatapos ay natanggap ang mga transaksyon na nauugnay dito. At ang pagbubuklod ay ginawa.

At kung ikaw ay mapalad na ang kahilingan ay naglalaman ng isang transaksyon id, kung gayon ito ay madali. Ngunit kadalasan ay wala kang swerte. Samakatuwid, kinakailangang hanapin ang huling transaksyon o ang transaksyon sa huling pag-click, atbp.

At lahat ng ito ay gumana nang mahusay hanggang sa ang pag-link ay sa huling pag-click. Dahil mayroong, sabihin nating, 10 milyong pag-click bawat araw, 300 milyon bawat buwan, kung magtatakda ka ng isang window para sa isang buwan. At dahil sa Cassandra lahat ng ito ay kailangang nasa memorya upang gumana nang mabilis, dahil ang Runtime ay kinakailangan upang mabilis na tumugon, humigit-kumulang 10-15 server ang kinakailangan.

At kapag gusto nilang i-link ang isang transaksyon sa display, agad itong naging hindi napakasaya. At bakit? Makikita na 30 beses na higit pang mga kaganapan ang kailangang itabi. At, nang naaayon, kailangan mo ng 30 beses na higit pang mga server. At lumalabas na ito ay isang uri ng astronomical figure. Ang pagpapanatiling hanggang sa 500 server upang magawa ang pag-link, sa kabila ng katotohanan na may makabuluhang mas kaunting mga server sa Runtime, ay isang uri ng maling figure. At nagsimula silang mag-isip kung ano ang gagawin.

At pumunta kami sa ClickHouse. Paano ito gagawin sa ClickHouse? Sa unang sulyap, tila ito ay isang hanay ng mga antipattern.

• Ang transaksyon ay lumalaki, kami ay nag-a-attach ng higit at higit pang mga kaganapan dito, ibig sabihin, ito ay nababago, at ang ClickHouse ay hindi gumagana nang maayos sa mga nababagong bagay.
• Kapag may bisitang dumating sa atin, kailangan nating kunin ang kanyang mga transaksyon sa pamamagitan ng susi, sa pamamagitan ng kanyang visit id. Isa rin itong puntong query; hindi iyon ginagawa ng ClickHouse. Karaniwan ang ClickHouse ay may malalaking…pag-scan, ngunit dito kailangan nating kumuha ng ilang mga tala. Isa ring antipattern.
• Bilang karagdagan, ang transaksyon ay nasa json, ngunit hindi nila nais na muling isulat ito, kaya gusto nilang iimbak ang json nang hindi nakabalangkas, at kung kinakailangan, kumuha ng isang bagay mula dito. At ito rin ay isang antipattern.

Iyon ay, isang hanay ng mga antipattern.

Ngunit gayunpaman, nagawa naming lumikha ng isang sistema na gumagana nang mahusay.

Ano ang ginawa? Lumitaw ang ClickHouse, kung saan ang mga log, na hinati sa mga talaan, ay itinapon. Lumitaw ang isang nauugnay na serbisyo na nakatanggap ng mga log mula sa ClickHouse. Pagkatapos nito, para sa bawat entry sa pamamagitan ng pagbisita id, nakatanggap ako ng mga transaksyon na maaaring hindi pa naproseso at kasama ang mga snapshot, ibig sabihin, ang mga transaksyon ay konektado na, katulad ng resulta ng nakaraang trabaho. Nakagawa na ako ng lohika sa kanila, pinili ang tamang transaksyon, at nagkonekta ng mga bagong kaganapan. Ni-log ito muli. Ang log ay bumalik sa ClickHouse, ibig sabihin, ito ay isang patuloy na paikot na sistema. And besides, I went to DWH to analyze it there.

Hindi ito gumana nang maayos sa form na ito. At para gawing mas madali para sa ClickHouse, kapag may kahilingan para sa isang visit id, pinagsama nila ang mga kahilingang ito sa mga bloke ng 1-000 visit id at hinila ang lahat ng transaksyon para sa 2-000 na tao. At pagkatapos ay gumana ang lahat.

Kung titingnan mo ang loob ng ClickHouse, mayroon lamang 3 pangunahing talahanayan na nagsisilbi sa lahat ng ito.

Ang unang talahanayan kung saan ina-upload ang mga log, at ang mga log ay ina-upload nang halos walang pagproseso.

Pangalawang mesa. Sa pamamagitan ng materyal na pananaw, ang mga kaganapan na hindi pa naiugnay, ibig sabihin, walang kaugnayan, ay nakuha mula sa mga tala na ito. At sa pamamagitan ng materyal na pagtingin, ang mga transaksyon ay nakuha sa mga log na ito upang bumuo ng isang snapshot. Iyon ay, ang isang snapshot ay nilikha na may isang espesyal na materyalized na view, lalo na ang huling naipon na estado ng transaksyon.

Narito ang teksto ay nakasulat sa SQL. Gusto kong magkomento sa ilang mahahalagang bagay dito.

Ang unang mahalagang bagay ay ang kakayahan sa ClickHouse na kunin ang mga column at field mula sa json. Iyon ay, ang ClickHouse ay may ilang mga pamamaraan para sa pagtatrabaho sa json. Napaka-primitive nila.

Binibigyang-daan ka ng visitParamExtractInt na mag-extract ng mga attribute mula sa json, ibig sabihin, na-trigger ang unang hit. At sa ganitong paraan maaari mong ilabas ang transaction id o visit id. Sa pagkakataong ito.

Pangalawa, isang nakakalito na materyalized na larangan ang ginagamit dito. Ano ang ibig sabihin nito? Nangangahulugan ito na hindi mo maaaring ipasok ito sa talahanayan, i.e. hindi ito ipinasok, ito ay kinakalkula at nakaimbak kapag ipinasok. Kapag nagpasok ka, ginagawa ng ClickHouse ang trabaho para sa iyo. At kung ano ang kakailanganin mo mamaya ay nakuha mula sa json.

Sa kasong ito, ang materialized na view ay para sa mga hilaw na string. At ang unang talahanayan na may halos hilaw na log ay ginagamit. At ano ang ginagawa nito? Una, binabago nito ang pag-uuri, ibig sabihin, ang pag-uuri ay ginagawa na ngayon sa pamamagitan ng visit id, dahil kailangan nating mabilis na i-pull out ang kanyang transaksyon partikular para sa isang partikular na tao.

Ang pangalawang mahalagang bagay ay index_granularity. Kung nakita mo ang MergeTree, kadalasan ang default na halaga ay 8 index_granularity. Ano ito? Ito ang index sparsity parameter. Sa ClickHouse, ang index ay kalat-kalat; hindi nito ini-index ang bawat record. Ginagawa ito tuwing 192. At ito ay mabuti kapag kailangan mong kalkulahin ang maraming data, ngunit ito ay masama kapag kailangan mong kalkulahin nang kaunti, dahil mayroong maraming overhead. At kung babawasan natin ang index granularity, babawasan natin ang overhead. Hindi mo ito maaaring bawasan sa isa, dahil maaaring walang sapat na memorya. Ang index ay palaging nakaimbak sa memorya.

At ang snapshot ay gumagamit ng ilang iba pang kawili-wiling mga function ng ClickHouse.

Una ay AggregatingMergeTree. At ang AggregatingMergeTree ay nag-iimbak ng argMax, ibig sabihin, ito ang estado ng transaksyon na naaayon sa huling timestamp. Palaging nabuo ang mga bagong transaksyon para sa bisitang ito. At sa pinakahuling estado ng transaksyong ito, nagdagdag kami ng kaganapan at nagkaroon kami ng bagong estado. Muli itong tumama sa ClickHouse. At sa pamamagitan ng argMax sa materialized view na ito palagi nating makukuha ang kasalukuyang estado.

• Ang pagbubuklod ay "undethered" mula sa Runtime.
• Hanggang 3 bilyong transaksyon bawat buwan ang iniimbak at pinoproseso. Ito ay isang pagkakasunud-sunod ng magnitude na mas malaki kaysa sa Cassandra, ibig sabihin, sa isang karaniwang transactional system.
• Cluster ng 2x5 ClickHouse server. 5 server at bawat server ay may replica. Mas mababa pa ito kaysa sa Cassandra para magawa ang attribution na nakabatay sa pag-click, ngunit dito mayroon kaming batay sa impression. Iyon ay, sa halip na dagdagan ang bilang ng mga server ng 30 beses, sila ay nabawasan.

At ang huling halimbawa ay ang kumpanya sa pananalapi Y, na sinuri ang mga ugnayan ng mga pagbabago sa mga presyo ng stock.

At ang gawain ay ito:

• Mayroong humigit-kumulang 5 shares.
• Alam ang mga quote bawat 100 millisecond.
• Ang data ay naipon sa loob ng 10 taon. Tila, para sa ilang mga kumpanya ito ay higit pa, para sa ilang mga ito ay mas mababa.
• Mayroong humigit-kumulang 100 bilyong row sa kabuuan.

At kinakailangan upang kalkulahin ang ugnayan ng mga pagbabago.

Narito ang dalawang stock at ang kanilang mga quote. Kung ang isa ay tumaas at ang isa ay tumaas, ito ay isang positibong ugnayan, ibig sabihin, ang isa ay tumaas at ang isa ay tumaas. Kung ang isa ay tumaas, tulad ng sa dulo ng graph, at ang isa ay bumaba, kung gayon ito ay isang negatibong ugnayan, ibig sabihin, kapag ang isa ay tumaas, ang isa ay bumaba.

Sa pamamagitan ng pagsusuri sa mga pagbabagong ito sa isa't isa, maaaring gumawa ng mga hula sa merkado sa pananalapi.

Ngunit mahirap ang gawain. Ano ang ginagawa para dito? Mayroon kaming 100 bilyong talaan na naglalaman ng: oras, stock at presyo. Kailangan muna nating kalkulahin ang 100 bilyong beses sa runningDifference mula sa algorithm ng presyo. Ang RunningDifference ay isang function sa ClickHouse na sunud-sunod na kinakalkula ang pagkakaiba sa pagitan ng dalawang linya.

At pagkatapos nito kailangan nating kalkulahin ang ugnayan, at ang ugnayan ay dapat kalkulahin para sa bawat pares. Para sa 5 na pagbabahagi, ang mga pares ay 000 milyon. At ito ay marami, ibig sabihin, 12,5 beses na kailangan mong kalkulahin ang function ng ugnayan na ito.

At kung sakaling may nakakalimutan, si ͞x at ͞y ay checkmate. sample na inaasahan. Iyon ay, kailangan mong hindi lamang kalkulahin ang mga ugat at kabuuan, kundi pati na rin ang iba pang mga kabuuan sa loob ng mga kabuuan na ito. Napakaraming kalkulasyon ang kailangang gawin nang 12,5 milyong beses, at kailangan din nilang pagsama-samahin ayon sa oras. At marami rin kaming oras. At kailangan mong gawin ito sa loob ng 60 segundo. biro lang.

Kinailangan naming gawin ito kahit papaano, dahil gumana ang lahat, napakabagal bago dumating ang ClickHouse.

Sinubukan nilang kalkulahin ito sa Hadoop, sa Spark, sa Greenplum. At lahat ng ito ay napakabagal o mahal. Iyon ay, posible na kahit papaano ay kalkulahin ito, ngunit pagkatapos ito ay mahal.

At pagkatapos ay dumating ang ClickHouse at naging mas mahusay ang lahat.

Ipaalala ko sa iyo na mayroon kaming problema sa lokalidad ng data, kaya hindi ma-localize ang mga ugnayan. Hindi kami maaaring magdagdag ng ilang data sa isang server, ang ilan sa isa pa at kalkulahin; dapat ay mayroon kaming lahat ng data sa lahat ng dako.

Anong ginawa nila? Sa una, ang data ay naisalokal. Ang bawat server ay nag-iimbak ng data ng pagpepresyo para sa isang partikular na hanay ng mga pagbabahagi. At hindi sila nagsasalubong. Samakatuwid, posibleng kalkulahin ang logReturn nang kahanay at nakapag-iisa; lahat ng ito ay nangyayari nang magkatulad at ipinamamahagi.

Pagkatapos ay nagpasya kaming bawasan ang data na ito nang hindi nawawala ang pagpapahayag. Bawasan ang paggamit ng mga array, ibig sabihin, para sa bawat yugto ng panahon, gumawa ng hanay ng mga pagbabahagi at hanay ng mga presyo. Kaya ito ay tumatagal ng mas kaunting espasyo ng data. At medyo mas maginhawa silang magtrabaho kasama. Ito ay halos magkatulad na mga operasyon, ibig sabihin, kami ay bahagyang nagbibilang nang magkatulad at pagkatapos ay sumulat sa server.

Ito ay maaaring kopyahin. Ang titik na "r" ay nangangahulugan na kinopya namin ang data na ito. Iyon ay, mayroon kaming parehong data sa lahat ng tatlong mga server - ito ang mga array.

At pagkatapos, gamit ang isang espesyal na script, maaari kang gumawa ng mga pakete mula sa hanay na ito ng 12,5 milyong mga ugnayan na kailangang kalkulahin. Ibig sabihin, 2 gawain na may 500 pares ng mga ugnayan. At ang gawaing ito ay dapat kalkulahin sa isang partikular na server ng ClickHouse. Nasa kanya ang lahat ng data dahil pare-pareho ang data at maaari niyang kalkulahin ito nang sunud-sunod.

Narito muli ang hitsura nito. Una, mayroon kaming lahat ng data sa sumusunod na istraktura: oras, pagbabahagi, presyo. Pagkatapos ay kinakalkula namin ang logReturn, ibig sabihin, ang data ng parehong istraktura, sa halip na presyo ay mayroon kaming logReturn. Pagkatapos ay muling ginawa ang mga ito, ibig sabihin, nakakuha kami ng oras at groupArray sa pamamagitan ng mga promosyon at listahan ng presyo. Kinulit. At pagkatapos noon, nakabuo sila ng isang bungkos ng mga gawain at ipinakain sila sa ClickHouse upang mabilang ang mga ito. At ito ay gumagana.

Sa patunay ng konsepto, ang gawain ay isang subtask, ibig sabihin, mas kaunting data ang kinuha nila. At sa tatlong server lamang.

Ang unang dalawang yugtong ito: ang pagkalkula ng Log_return at pag-wrap nito sa mga arrays ay tumagal nang humigit-kumulang isang oras bawat isa.

At ang pagkalkula ng ugnayan ay tumatagal ng mga 50 oras. Ngunit ang 50 oras ay hindi sapat, dahil dati ito ay nagtrabaho para sa kanila nang ilang linggo. Ito ay isang mahusay na tagumpay. At kung bibilangin mo, ang lahat ay binibilang ng 70 beses bawat segundo sa cluster na ito.

Ngunit ang pinakamahalagang bagay ay ang sistemang ito ay halos walang mga bottleneck, ibig sabihin, halos linearly ang sukat nito. At sinuri nila ito. Matagumpay itong na-scale.

• Ang tamang pamamaraan ay kalahati ng tagumpay. At ang tamang pamamaraan ay gamitin ang lahat ng kinakailangang teknolohiya ng ClickHouse.
• Ang Summing/AggregatingMergeTrees ay mga teknolohiyang nagbibigay-daan sa iyong pagsama-samahin o bilangin ang isang snapshot ng estado bilang isang espesyal na kaso. At ito ay lubos na nagpapasimple sa maraming bagay.
• Binibigyang-daan ka ng Materialized Views na malampasan ang limitasyon ng one-index. Marahil ay hindi ko ito nasabi nang malinaw, ngunit nang na-load namin ang mga log, ang mga hilaw na log ay nasa isang talahanayan na may isang index, at sa katangian ang mga log ay nasa talahanayan, ibig sabihin, ang parehong data, na-filter lamang, ngunit ang index ay ganap sa iba. Mukhang pareho ang data, ngunit magkaibang pag-uuri. At binibigyang-daan ka ng Materialized Views, kung kailangan mo ito, na lampasan ang limitasyon ng ClickHouse na ito.
• Bawasan ang index granularity para sa mga query sa punto.
• At mamahagi ng data nang matalino, subukang i-localize ang data sa loob ng server hangga't maaari. At subukang tiyakin na ang mga kahilingan ay gumagamit din ng lokalisasyon hangga't maaari hangga't maaari.

At upang ibuod ang maikling talumpati na ito, masasabi nating mahigpit na ngayon na sinakop ng ClickHouse ang teritoryo ng parehong mga komersyal na database at mga open source na database, ibig sabihin, partikular para sa analytics. Tamang-tama siya sa landscape na ito. At higit pa, ito ay unti-unting nagsisimulang lumipat sa iba, dahil kapag naroon ang ClickHouse, hindi mo na kailangan ang InfiniDB. Maaaring hindi na kailanganin ang vertical kung nagbibigay sila ng normal na suporta sa SQL. Gamitin ito!

-Salamat sa ulat! Napaka-interesante! Mayroon bang anumang paghahambing sa Apache Phoenix?

-Hindi, wala akong narinig na naghahambing. Sinusubukan namin at ng Yandex na subaybayan ang lahat ng paghahambing ng ClickHouse na may iba't ibang mga database. Dahil kung biglang may lumabas na mas mabilis kaysa sa ClickHouse, kung gayon si Lesha Milovidov ay hindi makatulog sa gabi at nagsisimula itong mabilis na mapabilis. Wala akong narinig na ganoong paghahambing.

• (Alexey Milovidov) Ang Apache Phoenix ay isang SQL engine batay sa Hbase. Pangunahing idinisenyo ang Hbase para sa senaryo ng trabaho na uri ng key-value. Doon, ang bawat linya ay maaaring magkaroon ng arbitrary na bilang ng mga column na may mga arbitrary na pangalan. Ito ay masasabi tungkol sa mga sistema tulad ng Hbase at Cassandra. At ito ay tiyak na mabibigat na analytical na mga query na hindi gagana nang normal para sa kanila. O maaari mong isipin na gumagana ang mga ito kung hindi ka pa nagkaroon ng anumang karanasan sa ClickHouse.

• salamat

  • Magandang hapon Medyo interesado na ako sa paksang ito, dahil mayroon akong isang analytical subsystem. Ngunit kapag tinitingnan ko ang ClickHouse, naramdaman ko na ang ClickHouse ay napakahusay na angkop para sa pagsusuri ng kaganapan, nababago. At kung kailangan kong pag-aralan ang maraming data ng negosyo na may isang bungkos ng malalaking talahanayan, kung gayon ang ClickHouse, sa pagkakaintindi ko, ay hindi masyadong angkop para sa akin? Lalo na kung magbabago sila. Tama ba ito o may mga halimbawa na maaaring pabulaanan ito?

  • Ito ay tama. At ito ay totoo tungkol sa karamihan sa mga dalubhasang analytical database. Iniayon ang mga ito sa katotohanang mayroong isa o ilang malalaking mesa na nababago, at maraming maliliit na dahan-dahang nagbabago. Iyon ay, ang ClickHouse ay hindi tulad ng Oracle, kung saan maaari mong ilagay ang lahat at bumuo ng ilang napaka-kumplikadong mga query. Upang epektibong magamit ang ClickHouse, kailangan mong buuin ang scheme sa paraang gumagana nang maayos sa ClickHouse. Iyon ay, iwasan ang labis na normalisasyon, gumamit ng mga diksyunaryo, subukang gumawa ng mas kaunting mahabang koneksyon. At kung ang pamamaraan ay binuo sa ganitong paraan, kung gayon ang mga katulad na problema sa negosyo ay maaaring malutas sa ClickHouse nang mas mahusay kaysa sa isang tradisyunal na relational database.

Salamat sa ulat! May tanong ako tungkol sa pinakabagong financial case. Nagkaroon sila ng analytics. Ito ay kinakailangan upang ihambing kung paano sila umakyat at bumaba. At naiintindihan ko na ginawa mo ang system na partikular para sa analytics na ito? Kung bukas, sabihin nating, kailangan nila ng ibang ulat sa data na ito, kailangan ba nilang buuin muli ang diagram at i-load ang data? Iyon ay, gumawa ng ilang uri ng preprocessing upang matanggap ang kahilingan?

Siyempre, ito ay gumagamit ng ClickHouse para sa isang partikular na gawain. Maaari itong malutas nang mas tradisyonal sa loob ng Hadoop. Para sa Hadoop ito ay isang perpektong gawain. Ngunit sa Hadoop ito ay napakabagal. At ang aking layunin ay upang ipakita na ang ClickHouse ay maaaring malutas ang mga problema na karaniwang nalutas sa pamamagitan ng ganap na iba't ibang paraan, ngunit sa parehong oras gawin ito nang mas mahusay. Ito ay iniangkop para sa isang partikular na gawain. Malinaw na kung mayroong isang problema na medyo magkatulad, maaari itong malutas sa katulad na paraan.

Malinaw na. Sinabi mo na tumagal ng 50 oras upang maproseso. Nagsisimula ba ito sa umpisa pa lang, kapag na-load mo ang data o natanggap ang mga resulta?

Oo Oo.

OK maraming salamat.

Ito ay nasa isang 3 server cluster.

Pagbati! Salamat sa ulat! Lahat ay napaka-interesante. Hindi ako nagtatanong ng kaunti tungkol sa pag-andar, ngunit tungkol sa paggamit ng ClickHouse mula sa punto ng view ng katatagan. Ibig sabihin, mayroon ka bang mga problema at kailangan mo bang ibalik ang mga ito? Paano kumikilos ang ClickHouse? At nangyari na ba na nag-crash din ang replica mo? Halimbawa, nakatagpo kami ng problema sa ClickHouse noong lumampas pa rin ito sa limitasyon nito at nahulog.

Siyempre, walang perpektong sistema. At ang ClickHouse ay mayroon ding mga problema. Ngunit narinig mo ba ang tungkol sa Yandex.Metrica na hindi gumagana nang mahabang panahon? Hindi siguro. Ito ay gumagana nang mapagkakatiwalaan mula noong mga 2012-2013 sa ClickHouse. Masasabi ko rin ang tungkol sa aking karanasan. Hindi pa tayo nagkaroon ng kumpletong kabiguan. Maaaring mangyari ang ilang bahagyang bagay, ngunit hindi sila naging sapat na kritikal upang seryosong makaapekto sa negosyo. Hindi pa ito nangyari dati. Ang ClickHouse ay lubos na maaasahan at hindi nag-crash nang random. Hindi mo kailangang mag-alala tungkol dito. Ito ay hindi isang hilaw na bagay. Ito ay napatunayan ng maraming kumpanya.

Kamusta! Sinabi mo na kailangan mong agad na pag-isipang mabuti ang schema ng data. Paano kung nangyari ito? Ang aking data ay bumubuhos at lumalabas. Lumipas ang anim na buwan, at naiintindihan ko na hindi ako mabubuhay nang ganito, kailangan kong i-upload muli ang data at gumawa ng isang bagay dito.

Ito ay depende, siyempre, sa iyong system. Mayroong ilang mga paraan upang gawin ito nang halos walang tigil. Halimbawa, maaari kang lumikha ng isang Materialized View kung saan maaari kang lumikha ng ibang istraktura ng data kung maaari itong natatanging imapa. Iyon ay, kung pinapayagan nito ang pagmamapa gamit ang ClickHouse, ibig sabihin, pag-extract ng ilang bagay, pagpapalit ng pangunahing key, pagbabago ng partitioning, pagkatapos ay maaari kang gumawa ng Materialized View. Doon ay muling isusulat ang iyong lumang data, ang mga bago ay awtomatikong isusulat. At pagkatapos ay lumipat lamang sa paggamit ng Materialized View, pagkatapos ay ilipat ang record at patayin ang lumang talahanayan. Ito ay karaniwang walang tigil na paraan.

Salamat sa inyo.

Pinagmulan: www.habr.com