Tatlong taon na ang nakalilipas sina Viktor Tarnavsky at Alexey Milovidov mula sa Yandex sa entablado HighLoad++ , kung gaano kahusay ang ClickHouse, at kung paano ito hindi bumabagal. At sa susunod na yugto ay nagkaroon Alexander Zaitsev Ρ tungkol sa paglipat sa clickhouse mula sa isa pang analytical DBMS at may konklusyon na clickhouse, siyempre, mabuti, ngunit hindi masyadong maginhawa. Kapag sa 2016 ang kumpanya LifeStreet, kung saan nagtrabaho noon si Alexander, ay nagko-convert ng multi-petabyte analytical system sa clickhouse, ito ay isang kamangha-manghang "yellow brick road" na puno ng hindi kilalang mga panganib - clickhouse noon ay parang minahan.
Makalipas ang tatlong taon clickhouse naging mas mahusay - sa panahong ito itinatag ni Alexander ang kumpanyang Altinity, na hindi lamang tumutulong sa mga tao na lumipat sa clickhouse dose-dosenang mga proyekto, ngunit pinapabuti din ang produkto mismo kasama ng mga kasamahan mula sa Yandex. Ngayon clickhouse hindi pa rin isang walang malasakit na paglalakad, ngunit hindi na isang minefield.
Si Alexander ay nagtatrabaho sa mga distributed system mula noong 2003, sa pagbuo ng malalaking proyekto MySQL, Oracle ΠΈ Vertica. Sa huli HighLoad++ 2019 Alexander, isa sa mga pioneer ng paggamit clickhouse, sinabi kung ano ang DBMS na ito ngayon. Malalaman natin ang tungkol sa mga pangunahing tampok clickhouse: kung paano ito naiiba sa ibang mga sistema at sa anong mga kaso ito ay mas epektibong gamitin ito. Gamit ang mga halimbawa, titingnan natin ang mga kamakailang kasanayan at nasubok sa proyekto para sa pagbuo ng mga sistema batay sa clickhouse.
Retrospective: anong nangyari 3 years ago
Tatlong taon na ang nakararaan lumipat kami ng kumpanya LifeStreet sa clickhouse mula sa isa pang analytical database, at ganito ang hitsura ng ad network analytics migration:
- Hunyo 2016. Sa Bukas na mapagkukunan lumitaw clickhouse at nagsimula ang aming proyekto;
- Agosto Patunay ng konsepto: malaking network ng advertising, imprastraktura at 200-300 terabytes ng data;
- Oktubre. Unang data ng produksyon;
- Disyembre. Ang buong pag-load ng produkto ay 10-50 bilyong kaganapan bawat araw.
- Hunyo 2017. Ang matagumpay na paglipat ng mga user sa clickhouse, 2,5 petabytes ng data sa isang kumpol ng 60 server.
Sa panahon ng proseso ng paglipat, nagkaroon ng lumalagong pag-unawa na clickhouse ay isang mahusay na sistema na kaaya-ayang magtrabaho, ngunit ito ay isang panloob na proyekto ng Yandex. Samakatuwid, mayroong mga nuances: Ang Yandex ay unang haharap sa sarili nitong mga panloob na customer at pagkatapos lamang sa komunidad at sa mga pangangailangan ng mga panlabas na gumagamit, at ang ClickHouse ay hindi naabot ang antas ng enterprise sa maraming mga functional na lugar. Iyon ang dahilan kung bakit itinatag namin ang Altinity noong Marso 2017 para gumawa clickhouse kahit na mas mabilis at mas maginhawa hindi lamang para sa Yandex, kundi pati na rin para sa iba pang mga gumagamit. At ngayon kami:
- Nagsasanay at tumutulong kami sa pagbuo ng mga solusyon batay sa clickhouse upang ang mga customer ay hindi magkaroon ng problema, at upang ang solusyon sa huli ay gumana;
- Nagbibigay kami ng 24/7 na suporta clickhouse- mga pag-install;
- Bumubuo tayo ng sarili nating mga proyekto sa ecosystem;
- Kami ay aktibong nangangako sa aming sarili clickhouse, tumutugon sa mga kahilingan mula sa mga user na gustong makakita ng ilang partikular na feature.
At siyempre, tumulong kami sa paglipat sa clickhouse Ρ MySQL, Vertica, Orakulo, Greenplum, Redshift at iba pang mga sistema. Kami ay nasangkot sa iba't ibang mga galaw, at lahat sila ay naging matagumpay.
Bakit lumipat sa clickhouse
Hindi bumabagal! Ito ang pangunahing dahilan. clickhouse - napakabilis na database para sa iba't ibang mga sitwasyon:
Random na mga panipi mula sa mga taong matagal nang nakikipagtulungan sa mga tao clickhouse.
Scalability. Sa ilang iba pang database makakamit mo ang mahusay na pagganap sa isang piraso ng hardware, ngunit clickhouse maaari mong sukatin hindi lamang patayo, ngunit pahalang din, sa pamamagitan lamang ng pagdaragdag ng mga server. Ang lahat ay hindi gumagana nang maayos gaya ng gusto namin, ngunit ito ay gumagana. Maaari mong palawakin ang sistema habang lumalago ang iyong negosyo. Mahalaga na hindi tayo limitado sa solusyon ngayon at laging may potensyal para sa pag-unlad.
Portability. Walang attachment sa isang bagay. Halimbawa, may Amazon RedShift Ang hirap lumipat ng kung saan. A clickhouse maaari mong i-install ito sa iyong laptop, server, i-deploy ito sa cloud, pumunta sa Kubernetes β walang mga paghihigpit sa pagpapatakbo ng imprastraktura. Ito ay maginhawa para sa lahat, at ito ay isang malaking kalamangan na hindi maaaring ipagmalaki ng maraming iba pang katulad na mga database.
Kakayahang umangkop. clickhouse ay hindi tumitigil sa isang bagay, halimbawa, Yandex.Metrica, ngunit bubuo at ginagamit sa parami nang parami ng iba't ibang mga proyekto at industriya. Maaari itong palawakin sa pamamagitan ng pagdaragdag ng mga bagong kakayahan upang malutas ang mga bagong problema. Halimbawa, ito ay pinaniniwalaan na ang pag-iimbak ng mga log sa isang database ay masamang asal, kaya naisip nila Elasticsearch. Ngunit salamat sa kakayahang umangkop clickhouse, maaari ka ring mag-imbak ng mga log sa loob nito, at kadalasan ay mas mahusay pa ito kaysa sa in Elasticsearch - sa clickhouse nangangailangan ito ng 10 beses na mas kaunting bakal.
Libre Open Source. Wala kang kailangang bayaran. Hindi na kailangang makipag-ayos ng pahintulot na i-install ang system sa iyong laptop o server. Walang nakatagong bayad. Kasabay nito, walang ibang teknolohiya ng database ng Open Source ang maaaring makipagkumpitensya sa bilis clickhouse. MySQL, MariaDB, Greenplum - lahat sila ay mas mabagal.
Komunidad, pagmamaneho at magsaya. Sa clickhouse mahusay na komunidad: mga meetup, chat at Alexey Milovidov, na sinisingil sa ating lahat ang kanyang lakas at optimismo.
Lumipat sa ClickHouse
Upang pumunta sa clickhouse sa ilang kadahilanan, kailangan mo lamang ng tatlong bagay:
- Unawain ang mga limitasyon clickhouse at kung ano ang hindi angkop.
- Samantalahin teknolohiya at ang pinakadakilang lakas nito.
- Eksperimento. Kahit na ang pag-unawa kung paano ito gumagana clickhouse, hindi laging posible na mahulaan kung kailan ito magiging mas mabilis, kung kailan ito magiging mas mabagal, kung kailan ito magiging mas mahusay, at kung kailan ito magiging mas masahol pa. Kaya subukan ito.
Problema sa paglipat
Mayroon lamang isang "ngunit": kung lilipat ka sa clickhouse mula sa ibang bagay, kung gayon kadalasan ay may mali. Nakasanayan na namin ang ilang mga kasanayan at bagay na gumagana sa aming paboritong database. Halimbawa, sinumang nagtatrabaho sa SQItinuturing ng mga L-database na mandatory ang sumusunod na hanay ng mga function:
- mga transaksyon;
- mga hadlang;
- hindi pagbabago;
- index;
- I-UPDATE/DELETE;
- NULLs;
- millisecond;
- awtomatikong uri ng mga cast;
- maramihang pagsali;
- di-makatwirang mga partisyon;
- mga tool sa pamamahala ng kumpol.
Ang recruitment ay sapilitan, ngunit tatlong taon na ang nakakaraan sa clickhouse Wala sa mga function na ito ang available! Ngayon wala pang kalahati ng hindi naipatupad ang nananatili: mga transaksyon, mga hadlang, Consistency, millisecond at type casting.
At ang pangunahing bagay ay na sa clickhouse ilang karaniwang kasanayan at diskarte ay hindi gumagana o gumagana nang iba kaysa sa nakasanayan natin. Lahat ng lumalabas sa clickhouse, tumutugma sa "ClickHouse paraan", ibig sabihin. ang mga function ay naiiba sa ibang mga database. Halimbawa:
- Hindi pinipili ang mga index, ngunit nilaktawan.
- I-UPDATE/DELETE hindi kasabay, ngunit asynchronous.
- Mayroong maraming pagsali, ngunit walang query planner. Kung paano ginaganap ang mga ito sa pangkalahatan ay hindi masyadong malinaw sa mga tao mula sa mundo ng database.
ClickHouse Scripts
Noong 1960, isang Amerikanong matematiko na nagmula sa Hungarian Wigner EP nagsulat ng isang artikulo"Ang hindi makatwirang bisa ng matematika sa mga natural na aghamβ (βThe Incomprehensible Effectiveness of Mathematics in the Natural Sciencesβ) na ang mundo sa paligid natin ay sa ilang kadahilanan ay mahusay na inilarawan ng mga batas sa matematika. Ang matematika ay isang abstract na agham, at ang mga pisikal na batas na ipinahayag sa anyong matematika ay hindi mahalaga, at Wigner EP idiniin na ito ay lubhang kakaiba.
Sa aking palagay, clickhouse - ang parehong kakaiba. Upang muling sabihin ang Wigner, masasabi natin ito: ang hindi maisip na kahusayan ay kahanga-hanga clickhouse sa iba't ibang uri ng analytical application!
Halimbawa, kunin natin Real-Time na Data Warehouse, kung saan halos tuloy-tuloy na nilo-load ang data. Gusto naming makatanggap ng mga kahilingan mula dito nang may pangalawang pagkaantala. Mangyaring - gamitin ito clickhouse, dahil ito ang senaryo kung saan ito idinisenyo. clickhouse ito ay eksakto kung paano ito ginagamit hindi lamang sa web, kundi pati na rin sa marketing at financial analytics, AdTech, pati na rin sa Pagtuklas ng pandarayan. SA Real-time na Data Warehouse isang kumplikadong structured scheme tulad ng "star" o "snowflake" ang ginagamit, maraming table na may SUMALI (minsan marami), at ang data ay karaniwang iniimbak at binago sa ilang system.
Kumuha tayo ng isa pang senaryo - Serye ng Oras: pagsubaybay sa mga device, network, istatistika ng paggamit, Internet of Things. Dito nakatagpo kami ng medyo simpleng mga kaganapan na naayos sa oras. clickhouse ay hindi orihinal na binuo para dito, ngunit ipinakita ang sarili na gumagana nang maayos, kaya naman ginagamit ng malalaking kumpanya clickhouse bilang isang imbakan para sa pagsubaybay ng impormasyon. Upang tuklasin kung ito ay angkop clickhouse para sa time-series, gumawa kami ng benchmark batay sa diskarte at mga resulta InfluxDB ΠΈ TimescaleDB - dalubhasa serye ng oras mga database. Na clickhouse, kahit na walang pag-optimize para sa mga naturang gawain, ay nanalo sa isang dayuhang larangan:
Π serye ng oras Karaniwan ang isang makitid na talahanayan ay ginagamit - ilang maliliit na hanay. Maraming data ang maaaring magmula sa pagsubaybayβmilyong-milyong talaan bawat segundoβat kadalasang dumarating ang mga ito sa maliliit na pagsabog (real-time streaming). Samakatuwid, kailangan ng ibang insertion script, at ang mga query mismo ay may sariling mga detalye.
Log Management. Ang pagkolekta ng mga log sa isang database ay karaniwang masama, ngunit clickhouse ito ay maaaring gawin sa ilang mga komento tulad ng inilarawan sa itaas. Maraming kumpanya ang gumagamit clickhouse eksakto para sa layuning ito. Sa kasong ito, gumagamit kami ng flat wide table kung saan iniimbak namin ang buong log (halimbawa, sa form JSON), o gupitin sa mga piraso. Karaniwang nilo-load ang data sa malalaking batch (mga file), at naghahanap kami ayon sa ilang field.
Para sa bawat isa sa mga function na ito, ang mga dalubhasang database ay karaniwang ginagamit. clickhouse magagawa ng isa ang lahat ng ito at napakahusay na nahihigitan nito ang mga ito. Tingnan natin ngayon nang mas malapitan serye ng oras senaryo, at kung paano "magluto" ng tama clickhouse para sa ganitong senaryo.
Serye ng Oras
Sa kasalukuyan ito ang pangunahing senaryo kung saan clickhouse isinasaalang-alang ang karaniwang solusyon. Serye ng oras ay isang hanay ng mga kaganapan na inayos ayon sa oras, na kumakatawan sa mga pagbabago sa ilang proseso sa paglipas ng panahon. Halimbawa, ito ay maaaring ang tibok ng puso bawat araw o ang bilang ng mga proseso sa system. Ang lahat ng nagbibigay ng oras ay may ilang dimensyon serye ng oras:
Karamihan sa mga ganitong uri ng kaganapan ay nagmumula sa pagsubaybay. Ito ay maaaring hindi lamang pagsubaybay sa web, kundi pati na rin sa mga totoong device: mga kotse, mga sistemang pang-industriya, IoT, pabrika o unmanned taxi, sa trunk kung saan inilalagay na ng Yandex clickhouse-server.
Halimbawa, may mga kumpanyang nangongolekta ng data mula sa mga barko. Bawat ilang segundo, nagpapadala ang mga sensor sa container ship ng daan-daang iba't ibang sukat. Pinag-aaralan sila ng mga inhinyero, bumuo ng mga modelo at sinisikap na maunawaan kung gaano kahusay ang paggamit ng barko, dahil ang isang container ship ay hindi dapat idle kahit isang segundo. Ang anumang downtime ay isang pagkawala ng pera, kaya mahalagang hulaan ang ruta upang ang mga paghinto ay minimal.
Sa ngayon, dumarami ang mga dalubhasang database na sumusukat serye ng oras. Sa site DB-Engine Ang iba't ibang mga database ay niraranggo sa anumang paraan, at maaari mong tingnan ang mga ito ayon sa uri:
Ang pinakamabilis na lumalagong uri ay serye ng orass. Ang mga database ng graph ay lumalaki din, ngunit serye ng orass ay lumalago nang mas mabilis sa nakalipas na ilang taon. Ang mga karaniwang kinatawan ng pamilyang ito ng mga database ay InfluxDB, Promiteyus, KDB, TimescaleDB (itinayo sa PostgreSQL), mga solusyon mula sa Birago. clickhouse magagamit din dito, at ginagamit. Hayaan akong magbigay sa iyo ng ilang pampublikong halimbawa.
Isa sa mga pioneer ay ang kumpanya CloudFlare (CDN-tagapagbigay). Sinusubaybayan nila ang kanilang CDN sa pamamagitan ng clickhouse (DNS-mga kahilingan, HTTP-queries) na may malaking load - 6 na milyong kaganapan kada segundo. Lahat ay dumadaan Kafka, pumupunta sa clickhouse, na nagbibigay ng pagkakataong makita ang mga dashboard ng mga kaganapan sa system sa real time.
Comcast - isa sa mga nangunguna sa telekomunikasyon sa USA: Internet, digital television, telephony. Lumikha sila ng isang katulad na sistema ng kontrol CDN sa loob ng Open Source proyekto Kontrol sa Trapiko ng Apache upang gumana sa iyong malaking data. clickhouse ginamit bilang backend para sa analytics.
percona nakapaloob sa clickhouse sa loob ng iyong PMMupang mag-imbak ng pagsubaybay sa iba't ibang MySQL.
Partikular na kinakailangan
Ang mga database ng time-series ay may sariling mga partikular na pangangailangan.
- Mabilis na pagpasok mula sa maraming ahente. Kailangan nating magpasok ng data mula sa maraming stream nang napakabilis. clickhouse Mahusay itong ginagawa dahil ang lahat ng mga pagsingit nito ay hindi nakaharang. Anuman isingit ay isang bagong file sa disk, at ang maliliit na pagsingit ay maaaring i-buffer sa isang paraan o iba pa. SA clickhouse Mas mainam na magpasok ng data sa malalaking batch kaysa sa isang linya sa isang pagkakataon.
- Flexible na pamamaraan. Sa serye ng oras karaniwang hindi namin alam ang istraktura ng data nang buo. Posible na bumuo ng isang sistema ng pagsubaybay para sa isang partikular na aplikasyon, ngunit pagkatapos ay mahirap gamitin ito para sa isa pang aplikasyon. Nangangailangan ito ng mas nababaluktot na pamamaraan. clickhouse, ay nagbibigay-daan sa iyong gawin ito, kahit na ito ay isang malakas na na-type na base.
- Mahusay na imbakan at pagkalimot ng data. Karaniwan sa serye ng oras isang malaking halaga ng data, kaya dapat itong maimbak nang mahusay hangga't maaari. Halimbawa, sa InfluxDB mahusay na compression ang pangunahing tampok nito. Ngunit bukod sa pag-iimbak, kailangan mo ring "makalimutan" ang lumang data at gumawa ng ilang uri ng pagbagsak β awtomatikong pagbibilang ng mga pinagsama-samang.
- Mabilis na mga query sa pinagsama-samang data. Minsan nakakatuwang tingnan ang huling 5 minuto na may katumpakan na millisecond, ngunit sa buwanang data minuto o segundong granularity ay maaaring hindi kailanganin - sapat na ang mga pangkalahatang istatistika. Ang ganitong uri ng suporta ay kinakailangan, kung hindi, ang isang kahilingan sa loob ng 3 buwan ay aabutin ng napakatagal na panahon upang makumpleto kahit na clickhouse.
- Mga kahilingan tulad ng "huling punto, mula noongΒ». Ang mga ito ay tipikal para sa serye ng oras mga query: tingnan ang huling sukat o estado ng system sa isang sandali sa oras t. Ang mga ito ay hindi masyadong kaaya-aya na mga query para sa isang database, ngunit kailangan mo ring magawa ang mga ito.
- "Gluing" time series. Serye ng oras ay isang serye ng oras. Kung mayroong dalawang serye ng oras, madalas silang kailangang konektado at magkaugnay. Hindi maginhawang gawin ito sa lahat ng mga database, lalo na sa hindi nakahanay na serye ng oras: narito ang ilang mga punto ng oras, mayroong iba pa. Maaari mong isaalang-alang ang average, ngunit biglang magkakaroon pa rin ng isang butas doon, kaya hindi malinaw.
Tingnan natin kung paano natutugunan ang mga kinakailangang ito clickhouse.
Ang pamamaraan
Π clickhouse scheme para sa serye ng oras maaaring gawin sa iba't ibang paraan, depende sa antas ng regularidad ng data. Posibleng bumuo ng system sa regular na data kapag alam namin ang lahat ng sukatan nang maaga. Halimbawa, ginawa ko ito CloudFlare may pagmamanman CDN ay isang mahusay na na-optimize na sistema. Maaari kang bumuo ng isang mas pangkalahatang sistema na sinusubaybayan ang buong imprastraktura at iba't ibang mga serbisyo. Sa kaso ng hindi regular na data, hindi namin alam nang maaga kung ano ang aming sinusubaybayan - at ito marahil ang pinakakaraniwang kaso.
Regular na data. Mga hanay. Ang scheme ay simple - mga haligi na may mga kinakailangang uri:
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);Ito ay isang regular na talahanayan na sinusubaybayan ang ilang uri ng aktibidad sa paglo-load ng system (gumagamit, sistema, idle, maganda). Simple at maginhawa, ngunit hindi nababaluktot. Kung gusto natin ng mas nababaluktot na pamamaraan, maaari tayong gumamit ng mga array.
Hindi regular na data. Mga array:
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 ...
Kaayusan Pugad ay dalawang array: metrics.name ΠΈ sukatan.halaga. Dito maaari kang mag-imbak ng naturang di-makatwirang data ng pagsubaybay bilang isang hanay ng mga pangalan at isang hanay ng mga sukat para sa bawat kaganapan. Para sa karagdagang pag-optimize, sa halip na isang ganoong istraktura, maaari kang gumawa ng ilan. Halimbawa, isa para sa lumutang-halaga, isa pa - para sa int-ibig sabihin kasi int Gusto kong mag-imbak nang mas mahusay.
Ngunit ang gayong istraktura ay mas mahirap ma-access. Kakailanganin mong gumamit ng isang espesyal na konstruksyon, gamit ang mga espesyal na pag-andar upang ilabas ang mga halaga ng unang index at pagkatapos ay ang array:
SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...Ngunit gumagana pa rin ito nang mabilis. Ang isa pang paraan upang mag-imbak ng hindi regular na data ay ayon sa hilera.
Hindi regular na data. Mga string. Sa tradisyunal na pamamaraang ito, nang walang mga array, ang mga pangalan at halaga ay naka-imbak nang sabay-sabay. Kung 5 mga sukat ang nanggaling sa isang device nang sabay-sabay, 000 row ang nabuo sa database:
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 nakayanan ito - mayroon itong mga espesyal na extension clickhouse SQL. Halimbawa maxIf β isang espesyal na function na kinakalkula ang maximum sa pamamagitan ng isang sukatan kapag natugunan ang ilang kundisyon. Maaari kang magsulat ng ilang ganoong expression sa isang kahilingan at agad na kalkulahin ang halaga para sa ilang sukatan.
Paghambingin natin ang tatlong paraan:
Dito ko idinagdag ang "Disk Data Size" para sa ilang test data set. Sa kaso ng mga column, mayroon kaming pinakamaliit na laki ng data: maximum compression, maximum na bilis ng query, ngunit nagbabayad kami sa pamamagitan ng pag-record ng lahat nang sabay-sabay.
Sa kaso ng mga arrays, ang lahat ay medyo mas masahol pa. Ang data ay mahusay pa ring naka-compress at maaaring mag-imbak ng hindi regular na pattern. Pero clickhouse - isang columnar database, at kapag sinimulan naming iimbak ang lahat sa isang array, ito ay nagiging isang hilera, at nagbabayad kami para sa flexibility nang may kahusayan. Para sa anumang operasyon, kailangan mong basahin ang buong array sa memorya, pagkatapos ay hanapin ang nais na elemento sa loob nito - at kung ang array ay lumalaki, ang bilis ay bumababa.
Sa isa sa mga kumpanyang gumagamit ng diskarteng ito (halimbawa, ), ang mga array ay pinutol sa mga piraso ng 128 elemento. Ang data mula sa ilang libong sukatan na may volume na 200 TB ng data/araw ay hindi iniimbak sa isang array, ngunit sa 10 o 30 array na may espesyal na lohika ng storage.
Ang pinakasimpleng diskarte ay ang mga string. Ngunit ang data ay mahinang na-compress, ang laki ng talahanayan ay malaki, at kahit na ang mga query ay batay sa ilang mga sukatan, ang ClickHouse ay hindi gumagana nang mahusay.
Hybrid scheme
Ipagpalagay natin na pumili tayo ng array circuit. Ngunit kung alam namin na karamihan sa aming mga dashboard ay nagpapakita lamang ng mga sukatan ng user at system, maaari din naming isakatuparan ang mga sukatang ito sa mga column mula sa isang array sa antas ng talahanayan sa ganitong paraan:
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);
Kapag pinapasok clickhouse ay awtomatikong mabibilang ang mga ito. Sa ganitong paraan maaari mong pagsamahin ang negosyo nang may kasiyahan: ang scheme ay nababaluktot at pangkalahatan, ngunit hinugot namin ang pinakamadalas na ginagamit na mga column. Tandaan na hindi ito nangangailangan ng pagbabago sa insert at ETLna patuloy na naglalagay ng mga arrays sa talahanayan. Ginawa lang namin Baguhin ang talahanayan, nagdagdag ng ilang speaker at nakakuha kami ng hybrid at mas mabilis na scheme na maaari mong simulan kaagad ang paggamit.
Mga codec at compression
Para sa serye ng oras Mahalaga kung gaano ka kahusay mag-pack ng data dahil ang dami ng impormasyon ay maaaring napakalaki. SA clickhouse Mayroong isang hanay ng mga tool upang makamit ang epekto ng compression na 1:10, 1:20, at kung minsan ay higit pa. Nangangahulugan ito na ang 1 TB ng hindi naka-pack na data sa disk ay tumatagal ng 50-100 GB. Ang mas maliit na sukat ay mabuti, ang data ay maaaring basahin at maproseso nang mas mabilis.
Upang makamit ang isang mataas na antas ng compression, clickhouse sumusuporta sa mga sumusunod na codec:
Halimbawang talahanayan:
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);Dito namin tinukoy ang codec DoubleDelta sa isang kaso, sa pangalawa - Gorilya, at tiyak na magdadagdag pa kami LZ4 compression. Bilang resulta, ang laki ng data sa disk ay lubhang nabawasan:
Ipinapakita nito kung gaano karaming espasyo ang ginagamit ng parehong data, ngunit gumagamit ng iba't ibang mga codec at compression:
- sa isang GZIP file sa disk;
- sa ClickHouse na walang mga codec, ngunit may ZSTD compression;
- sa ClickHouse na may mga codec at compression na LZ4 at ZSTD.
Makikita na ang mga talahanayan na may mga codec ay kumukuha ng mas kaunting espasyo.
Mga bagay na laki
Hindi gaanong mahalaga tamang uri ng data:
Sa lahat ng mga halimbawa sa itaas na ginamit ko Lutang64. Pero kung papipiliin tayo Lutang32, kung gayon iyon ay magiging mas mabuti. Ito ay mahusay na ipinakita ng mga lalaki mula sa Perkona sa artikulong naka-link sa itaas. Mahalagang gamitin ang pinaka-compact na uri na angkop para sa gawain: kahit na mas mababa para sa laki ng disk kaysa sa bilis ng query. clickhouse napaka sensitive dito.
Kung magagamit mo intxnumx sa halip ng intxnumx, pagkatapos ay asahan ang halos dalawang beses na pagtaas sa pagganap. Ang data ay tumatagal ng mas kaunting memorya, at lahat ng "aritmetika" ay gumagana nang mas mabilis. clickhouse sa loob ito ay isang napakahigpit na na-type na sistema; ito ay gumagawa ng maximum na paggamit ng lahat ng mga posibilidad na ibinibigay ng mga modernong sistema.
Pagsasama-sama at Mga Materyal na Panonood
Nagbibigay-daan sa iyo ang pagsasama-sama at mga materyal na view na lumikha ng mga pinagsama-sama para sa iba't ibang okasyon:
Halimbawa, maaaring mayroon kang hindi pinagsama-samang source data, at maaari kang mag-attach ng iba't ibang materialized na view sa mga ito gamit ang awtomatikong pagsusuma sa pamamagitan ng isang espesyal na makina. SummingMergeTree (SMT). SMT ay isang espesyal na istraktura ng pinagsama-samang data na awtomatikong kinakalkula ang mga pinagsama-samang. Ang raw data ay ipinasok sa database, ito ay awtomatikong pinagsama-sama, at ang mga dashboard ay maaaring gamitin kaagad dito.
TTL - "kalimutan" ang lumang data
Paano "kalimutan" ang data na hindi na kailangan? clickhouse alam kung paano gawin ito. Kapag lumilikha ng mga talahanayan, maaari mong tukuyin TTL mga expression: halimbawa, na nag-iimbak kami ng minutong data para sa isang araw, araw-araw na data sa loob ng 30 araw, at hindi kailanman hawakan ang lingguhan o buwanang data:
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 */
Multi-tier - hatiin ang data sa mga disk
Kung isasaalang-alang ang ideyang ito, maaaring maimbak ang data clickhouse sa iba't ibang lugar. Ipagpalagay na gusto naming mag-imbak ng mainit na data para sa huling linggo sa isang napakabilis na lokal SSD, at naglalagay kami ng higit pang makasaysayang data sa ibang lugar. SA clickhouse ito ay posible na ngayon:
Maaari kang mag-configure ng patakaran sa storage (patakaran sa imbakan) Kaya clickhouse ay awtomatikong maglilipat ng data kapag naabot ang ilang partikular na kundisyon sa ibang storage.
Ngunit hindi lang iyon. Sa antas ng isang partikular na talahanayan, maaari mong tukuyin ang mga panuntunan para sa eksakto kung kailan napupunta ang data sa cold storage. Halimbawa, ang data ay naka-imbak sa isang napakabilis na disk sa loob ng 7 araw, at lahat ng mas luma ay inililipat sa isang mabagal. Maganda ito dahil pinapayagan ka nitong panatilihin ang system sa maximum na performance, habang kinokontrol ang mga gastos at hindi nag-aaksaya ng pera sa malamig na data:
CREATE TABLE
...
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume',
date + INTERVAL 180 DAY DELETE
Mga natatanging tampok clickhouse
Sa halos lahat ng bagay clickhouse May mga ganoong "highlight", ngunit na-offset sila ng pagiging eksklusibo - isang bagay na wala sa ibang mga database. Halimbawa, narito ang ilan sa mga natatanging tampok clickhouse:
- Mga Arrays. Sa clickhouse napakahusay na suporta para sa mga array, pati na rin ang kakayahang magsagawa ng mga kumplikadong kalkulasyon sa mga ito.
- Pinagsasama-sama ang Mga Istraktura ng Data. Ito ay isa sa mga "killer features" clickhouse. Sa kabila ng katotohanan na ang mga lalaki mula sa Yandex ay nagsasabi na hindi namin nais na pagsama-samahin ang data, lahat ay pinagsama-sama sa clickhouse, dahil ito ay mabilis at maginhawa.
- Materialized Views. Kasama ang pinagsama-samang mga istruktura ng data, binibigyang-daan ka ng mga materialized na view na gawing komportable real-time pagsasama-sama.
- ClickHouse SQL. Ito ay isang extension ng wika SQL na may ilang karagdagang at eksklusibong feature na available lang sa clickhouse. Dati, ito ay tulad ng isang pagpapalawak sa isang banda, at isang kawalan sa kabilang banda. Ngayon halos lahat ng mga disadvantages kumpara sa SQL 92 tinanggal namin, ngayon extension na lang.
- Lambdaβ mga ekspresyon. Nasa anumang database pa ba sila?
- ML-suporta. Ito ay magagamit sa iba't ibang mga database, ang ilan ay mas mahusay, ang ilan ay mas masahol pa.
- Bukas na mapagkukunan. Maaari naming palawakin clickhouse magkasama. Ngayon sa clickhouse humigit-kumulang 500 na nag-aambag, at ang bilang na ito ay patuloy na lumalaki.
Mga nakakalito na tanong
Π clickhouse maraming iba't ibang paraan upang gawin ang parehong bagay. Halimbawa, maaari mong ibalik ang huling halaga mula sa isang talahanayan sa tatlong magkakaibang paraan para sa CPU (may pang-apat din, pero mas exotic pa).
Ang una ay nagpapakita kung gaano ito maginhawang gawin sa clickhouse mga tanong kung kailan mo gustong suriin iyon tuple nakapaloob sa subquery. Ito ay isang bagay na personal kong napalampas sa ibang mga database. Kung nais kong ihambing ang isang bagay sa isang subquery, kung gayon sa iba pang mga database ay isang scalar lamang ang maihahambing dito, ngunit para sa ilang mga haligi kailangan kong magsulat SUMALI. Sa clickhouse maaari mong gamitin ang tuple:
SELECT *
FROM cpu
WHERE (tags_id, created_at) IN
(SELECT tags_id, max(created_at)
FROM cpu
GROUP BY tags_id)Ang pangalawang pamamaraan ay gumagawa ng parehong bagay ngunit gumagamit ng isang pinagsama-samang function argMax:
SELECT
argMax(usage_user), created_at),
argMax(usage_system), created_at),
...
FROM cpu Π clickhouse mayroong ilang dosenang pinagsama-samang pag-andar, at kung gumagamit ka ng mga combinator, ayon sa mga batas ng combinatorics makakakuha ka ng halos isang libo sa kanila. ArgMax - isa sa mga function na kinakalkula ang maximum na halaga: ang kahilingan ay nagbabalik ng halaga usage_user, kung saan naabot ang maximum na halaga nilikha_sa:
SELECT now() as created_at,
cpu.*
FROM (SELECT DISTINCT tags_id from cpu) base
ASOF LEFT JOIN cpu USING (tags_id, created_at)
ASOF SUMALI β "pagdikit" ng mga hilera na may iba't ibang oras. Ito ay isang natatanging tampok para sa mga database na magagamit lamang sa kdb+. Kung mayroong dalawang time series na may magkaibang oras, ASOF SUMALI nagbibigay-daan sa iyong ilipat at pagsamahin ang mga ito sa isang kahilingan. Para sa bawat value sa isang time series, makikita ang pinakamalapit na value sa isa pa, at ibinabalik ang mga ito sa parehong linya:
Analytic Function
Sa pamantayan SQL-2003 maaari kang sumulat ng ganito:
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 Hindi mo magagawa iyon - hindi nito sinusuportahan ang pamantayan SQL-2003 at malamang na hinding hindi ito gagawin. Sa halip, sa clickhouse Nakaugalian na magsulat ng ganito:
Nangako ako sa mga lambdas - narito sila!
Ito ay isang analogue ng analytical na query sa pamantayan SQL-2003: binibilang niya ang pagkakaiba ng dalawa timestamp, tagal, ordinal number - lahat ng bagay na karaniwan naming itinuturing na analytical function. SA clickhouse Binibilang namin ang mga ito sa pamamagitan ng mga array: una naming i-collapse ang data sa isang array, pagkatapos ay gagawin namin ang lahat ng gusto namin sa array, at pagkatapos ay palawakin namin ito pabalik. Ito ay hindi masyadong maginhawa, ito ay nangangailangan ng isang pag-ibig ng functional programming sa isang minimum, ngunit ito ay napaka-kakayahang umangkop.
Mga espesyal na pag-andar
Bukod, sa clickhouse maraming mga espesyal na pag-andar. Halimbawa, paano matukoy kung gaano karaming mga sesyon ang nagaganap nang sabay-sabay? Ang isang karaniwang gawain sa pagsubaybay ay upang matukoy ang maximum na pagkarga sa isang kahilingan. SA clickhouse Mayroong isang espesyal na function para sa layuning ito:
Sa pangkalahatan, ang ClickHouse ay may mga espesyal na function para sa maraming layunin:
- runningDifference, runningAccumulate, neighbor;
- sumMap(key, value);
- timeSeriesGroupSum(uid, timestamp, value);
- timeSeriesGroupRateSum(uid, timestamp, value);
- skewPop, skewSamp, kurtPop, kurtSamp;
- MAY PUNO / MAY TALATA;
- simpleLinearRegression, stochasticLinearRegression.
Hindi ito kumpletong listahan ng mga function, mayroong 500-600 sa kabuuan. Hint: lahat ng function sa clickhouse ay nasa talahanayan ng system (hindi lahat ay dokumentado, ngunit lahat ay kawili-wili):
select * from system.functions order by nameclickhouse nag-iimbak ito ng maraming impormasyon tungkol sa sarili nito, kabilang ang log table, query_log, trace log, log ng mga operasyon na may mga bloke ng data (part_log), metrics log, at system log, na karaniwan nitong isinusulat sa disk. Ang mga sukatan ng log ay serye ng oras Π² clickhouse sa totoo lang clickhouse: Ang database mismo ay maaaring gumanap ng isang papel serye ng oras mga database, kaya "nilamon" ang sarili nito.
Ito rin ay isang natatanging bagay - dahil ginagawa namin ang isang mahusay na trabaho para sa serye ng oras, bakit hindi natin maiimbak ang lahat ng kailangan natin sa ating sarili? Hindi namin kailangan Promiteyus, itinatago namin ang lahat sa aming sarili. Nakakonekta grafana at sinusubaybayan natin ang ating sarili. Gayunpaman, kung clickhouse falls, hindi natin makikita kung bakit, kaya kadalasan hindi nila ginagawa iyon.
Malaking kumpol o maraming maliliit clickhouse
Ano ang mas mabuti - isang malaking kumpol o maraming maliliit na ClickHouse? Tradisyunal na diskarte sa DWH ay isang malaking kumpol kung saan ang mga circuit ay inilalaan para sa bawat aplikasyon. Dumating kami sa administrator ng database - bigyan kami ng isang diagram, at binigyan nila kami ng isa:
Π clickhouse maaari mong gawin ito nang iba. Maaari mong gawing sarili mo ang bawat aplikasyon clickhouse:
Hindi na natin kailangan ang malaking halimaw DWH at mahirap na mga admin. Maaari naming bigyan ang bawat aplikasyon ng sarili nitong clickhouse, at magagawa ito mismo ng developer, dahil clickhouse napakadaling i-install at hindi nangangailangan ng kumplikadong pangangasiwa:
Pero kung marami tayo clickhouse, at kailangan mo itong i-install nang madalas, pagkatapos ay gusto mong i-automate ang prosesong ito. Para dito maaari naming, halimbawa, gamitin Kubernetes ΠΈ clickhouse-operator. SA Kubernetes ClickHouse maaari mong ilagay ito "on-click": Maaari akong mag-click ng isang pindutan, patakbuhin ang manifest at ang database ay handa na. Makakagawa agad ako ng diagram, magsimulang mag-upload ng mga sukatan doon, at sa loob ng 5 minuto ay handa na ako ng dashboard grafana. Napakasimple nito!
Ang resulta?
Kaya, clickhouse - ito ay:
- Mabilis. Alam ng lahat ito.
- Simple lang. Medyo kontrobersyal, pero naniniwala ako na mahirap sa pagsasanay, madali sa labanan. Kung naiintindihan mo kung paano clickhouse ito ay gumagana, pagkatapos ang lahat ay napaka-simple.
- Pang-unibersidad. Ito ay angkop para sa iba't ibang mga sitwasyon: DWH, Serye ng Oras, Imbakan ng Log. Pero hindi OLTP database, kaya huwag subukang gumawa ng mga maikling pagsingit at pagbabasa doon.
- Nang kawili-wili. Malamang yung katrabaho clickhouse, nakaranas ng maraming kawili-wiling sandali sa mabuti at masamang kahulugan. Halimbawa, may lumabas na bagong release, tumigil ang lahat. O kapag nahirapan ka sa isang gawain sa loob ng dalawang araw, ngunit pagkatapos magtanong sa Telegram chat, nalutas ang gawain sa loob ng dalawang minuto. O tulad ng sa kumperensya sa ulat ni Lesha Milovidov, isang screenshot mula sa clickhouse sinira ang broadcast HighLoad++. Ang ganitong uri ng bagay ay nangyayari sa lahat ng oras at nagpapahirap sa ating buhay. clickhouse maliwanag at kawili-wili!
Maaari mong panoorin ang pagtatanghal .
Ang pinakahihintay na pagpupulong ng mga developer ng mga high-load system sa magaganap sa Nobyembre 9 at 10 sa Skolkovo. Sa wakas, ito ay magiging offline na kumperensya (kahit na may lahat ng pag-iingat sa lugar), dahil ang enerhiya ng HighLoad++ ay hindi maaaring i-package online.
Para sa kumperensya, hahanapin at ipapakita namin sa iyo ang mga kaso tungkol sa pinakamataas na kakayahan ng teknolohiya: Ang HighLoad++ noon, ay at magiging tanging lugar kung saan maaari mong malaman sa loob ng dalawang araw kung paano gumagana ang Facebook, Yandex, VKontakte, Google at Amazon.
Sa pagkakaroon ng pagdaraos ng aming mga pagpupulong nang walang pagkaantala mula noong 2007, sa taong ito ay magkikita kami sa ika-14 na pagkakataon. Sa panahong ito, ang kumperensya ay lumago nang 10 beses; noong nakaraang taon, ang pangunahing kaganapan sa industriya ay nagsama-sama ng 3339 kalahok, 165 tagapagsalita, mga ulat at pagkikita-kita, at 16 na mga track ay tumatakbo nang sabay-sabay.
Noong nakaraang taon ay mayroong 20 bus, 5280 liters ng tsaa at kape, 1650 liters ng fruit drinks at 10200 na bote ng tubig. At isa pang 2640 kilo ng pagkain, 16 plato at 000 tasa. Oo nga pala, sa nalikom na pera mula sa recycled paper, nagtanim kami ng 25 oak seedlings :)Maaari kang bumili ng mga tiket , makakuha ng balita tungkol sa kumperensya - , at makipag-usap sa lahat ng mga social network: , , ΠΈ .
Pinagmulan: www.habr.com