ay isang open source columnar database management system para sa online analytical query processing (OLAP), na nilikha ng Yandex. Ito ay ginagamit ng Yandex, CloudFlare, VK.com, Badoo at iba pang mga serbisyo sa buong mundo upang mag-imbak ng napakaraming data (pagpasok ng libu-libong mga hilera bawat segundo o mga petabytes ng data na nakaimbak sa disk).
Sa isang regular, "string" DBMS, ang mga halimbawa nito ay MySQL, Postgres, MS SQL Server, ang data ay naka-imbak sa sumusunod na pagkakasunud-sunod:
Sa kasong ito, ang mga value na nauugnay sa isang row ay pisikal na nakaimbak sa malapit. Sa mga columnar na DBMS, ang mga halaga mula sa iba't ibang mga column ay iniimbak nang hiwalay, at ang data mula sa isang column ay iniimbak nang magkasama:
Ang mga halimbawa ng columnar DBMS ay Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
kumpanya ng mail forwarder nagsimulang gumamit ng Clickhouse noong 2018 para sa pag-uulat at labis na humanga sa pagiging simple, scalability, suporta at bilis ng SQL nito. Ang bilis ng DBMS na ito ay may hangganan sa mahika.
Ang pagiging simple
Ang Clickhouse ay naka-install sa Ubuntu na may isang solong command. Kung alam mo ang SQL, maaari mong simulan kaagad ang paggamit ng Clickhouse para sa iyong mga pangangailangan. Gayunpaman, hindi ito nangangahulugan na maaari mong gawin ang "ipakita ang paglikha ng talahanayan" sa MySQL at kopyahin-i-paste ang SQL sa Clickhouse.
Kung ikukumpara sa MySQL, may mahahalagang pagkakaiba sa uri ng data sa mga kahulugan ng schema ng talahanayan, kaya kakailanganin mo pa rin ng ilang oras upang baguhin ang mga kahulugan ng schema ng talahanayan at matutunan ang mga makina ng talahanayan upang maging komportable.
Gumagana ang Clickhouse nang walang anumang karagdagang software, ngunit kung gusto mong gumamit ng replikasyon, kakailanganin mong i-install ang ZooKeeper. Ang pagsusuri sa pagganap ng query ay nagpapakita ng mahusay na mga resulta - ang mga talahanayan ng system ay naglalaman ng lahat ng impormasyon, at lahat ng data ay maaaring makuha gamit ang luma at nakakainip na SQL.
Pagiging Produktibo
- paghahambing ng Clickhouse sa Vertica at MySQL sa configuration ng server: dalawang socket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 sa 8 6TB SATA HDD, ext4.
- paghahambing ng Clickhouse sa Amazon RedShift cloud storage.
- Mga sipi sa blog :
Ang ClickHouse database ay may napakasimpleng disenyo - lahat ng node sa cluster ay may parehong functionality at gumagamit lamang ng ZooKeeper para sa koordinasyon. Bumuo kami ng isang maliit na kumpol ng ilang mga node at nagsagawa ng pagsubok, kung saan nalaman namin na ang system ay may lubos na kahanga-hangang pagganap, na tumutugma sa nakasaad na mga pakinabang sa analytical DBMS benchmarks. Nagpasya kaming tingnang mabuti ang konsepto sa likod ng ClickHouse. Ang unang hadlang sa pagsasaliksik ay ang kakulangan ng mga tool at ang maliit na komunidad ng ClickHouse, kaya't sinilip namin ang disenyo ng DBMS na ito upang maunawaan kung paano ito gumagana.
Hindi sinusuportahan ng ClickHouse ang pagtanggap ng data nang direkta mula sa Kafka dahil database lang ito, kaya nagsulat kami ng sarili naming serbisyo ng adapter sa Go. Binasa nito ang mga mensaheng naka-encode ng Cap'n Proto mula sa Kafka, na-convert ang mga ito sa TSV at ipinasok ang mga ito sa ClickHouse sa mga batch sa pamamagitan ng interface ng HTTP. Muli naming isinulat ang serbisyong ito sa ibang pagkakataon upang gamitin ang library ng Go kasabay ng sariling interface ng ClickHouse upang mapabuti ang pagganap. Kapag sinusuri ang pagganap ng pagtanggap ng mga packet, natuklasan namin ang isang mahalagang bagay - lumabas na para sa ClickHouse ang pagganap na ito ay lubos na nakasalalay sa laki ng packet, iyon ay, ang bilang ng mga sabay-sabay na ipinasok na mga hilera. Upang maunawaan kung bakit ito nangyayari, tiningnan namin kung paano nag-iimbak ng data ang ClickHouse.
Ang pangunahing makina, o sa halip na pamilya ng mga table engine, na ginagamit ng ClickHouse upang mag-imbak ng data ay MergeTree. Ang makinang ito ay kapareho ng konsepto sa LSM algorithm na ginamit sa Google BigTable o Apache Cassandra, ngunit iniiwasan ang pagbuo ng isang intermediate memory table at direktang nagsusulat ng data sa disk. Nagbibigay ito ng mahusay na write throughput, dahil ang bawat ipinasok na packet ay pinagsunod-sunod lamang ng primary key, naka-compress, at nakasulat sa disk upang bumuo ng isang segment.
Ang kawalan ng memory table o anumang konsepto ng "pagiging bago" ng data ay nangangahulugan din na maaari lamang silang idagdag; hindi sinusuportahan ng system ang pagbabago o pagtanggal. Sa kasalukuyan, ang tanging paraan upang tanggalin ang data ay tanggalin ito ayon sa buwan ng kalendaryo, dahil ang mga segment ay hindi kailanman tumatawid sa isang buwang hangganan. Ang pangkat ng ClickHouse ay aktibong nagtatrabaho upang gawing nako-customize ang tampok na ito. Sa kabilang banda, ginagawa nitong walang pag-aalinlangan ang pagsulat at pagsasama-sama ng mga segment, kaya tumanggap ng mga antas ng throughput nang linear na may bilang ng mga kasabay na pagsingit hanggang sa mangyari ang I/O o core saturation.
Gayunpaman, nangangahulugan din ito na ang system ay hindi angkop para sa maliliit na packet, kaya ang mga serbisyo at inserter ng Kafka ay ginagamit para sa buffering. Susunod, ang ClickHouse sa background ay patuloy na patuloy na nagsasagawa ng pagsasama-sama ng segment, upang maraming maliliit na piraso ng impormasyon ang pagsasama-samahin at itatala nang mas maraming beses, kaya tumataas ang intensity ng pag-record. Gayunpaman, masyadong maraming hindi konektadong bahagi ang magdudulot ng agresibong pag-throttling ng mga pagsingit hangga't nagpapatuloy ang pagsasanib. Nalaman namin na ang pinakamahusay na kompromiso sa pagitan ng real-time na pag-ingest at pagganap ng pag-ingest ay ang pag-ingest ng limitadong bilang ng mga pagsingit bawat segundo sa talahanayan.
Ang susi sa pagganap ng pagbabasa ng talahanayan ay ang pag-index at ang lokasyon ng data sa disk. Gaano man kabilis ang pagproseso, kapag ang makina ay kailangang mag-scan ng mga terabytes ng data mula sa disk at gumamit lamang ng isang bahagi nito, magtatagal ito. Ang ClickHouse ay isang columnar store, kaya ang bawat segment ay naglalaman ng file para sa bawat column (column) na may mga pinagsunod-sunod na value para sa bawat row. Sa ganitong paraan, maaaring laktawan muna ang mga buong column na nawawala sa query, at pagkatapos ay mapoproseso ang maramihang mga cell kasabay ng vectorized execution. Upang maiwasan ang isang buong pag-scan, ang bawat segment ay may maliit na index file.
Dahil ang lahat ng mga column ay pinagsunod-sunod ayon sa "pangunahing key", ang index file ay naglalaman lamang ng mga label (nakuhang mga row) ng bawat Nth row upang mapanatili ang mga ito sa memorya kahit na para sa napakalaking mga talahanayan. Halimbawa, maaari mong itakda ang mga default na setting sa "markahan ang bawat ika-8192 na hanay", pagkatapos ay "kaunti" ang pag-index ng isang talahanayan na may 1 trilyon. ang mga linyang madaling umaakma sa memorya ay tatagal lamang ng 122 character.
Pag-unlad ng system
Ang pag-unlad at pagpapabuti ng Clickhouse ay maaaring masubaybayan sa at siguraduhin na ang proseso ng "paglaki" ay nangyayari sa isang kahanga-hangang bilis.
Kasikatan
Ang katanyagan ng Clickhouse ay tila lumalaki nang husto, lalo na sa komunidad na nagsasalita ng Ruso. Ipinakita ng kumperensya ng High load 2018 noong nakaraang taon (Moscow, Nobyembre 8-9, 2018) na ang mga halimaw gaya ng vk.com at Badoo ay gumagamit ng Clickhouse, kung saan sila ay naglalagay ng data (halimbawa, mga log) mula sa libu-libong mga server nang sabay-sabay. Sa isang 40 minutong video . Sa lalong madaling panahon ay ipo-post namin ang transcript sa Habr para sa kadalian ng pagtatrabaho sa materyal.
Mga Application
Pagkatapos gumugol ng ilang oras sa pagsasaliksik, sa palagay ko may mga lugar kung saan maaaring maging kapaki-pakinabang ang ClickHouse o maaaring ganap na palitan ang iba, mas tradisyonal at tanyag na mga solusyon tulad ng MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot at Druid. Ang sumusunod ay naglalarawan ng mga detalye ng paggamit ng ClickHouse upang gawing makabago o ganap na palitan ang nasa itaas na DBMS.
Pagpapalawak ng mga kakayahan ng MySQL at PostgreSQL
Kamakailan lamang ay bahagyang pinalitan namin ang MySQL ng ClickHouse para sa aming platform ng newsletter . Ang problema ay ang MySQL, dahil sa hindi magandang disenyo, ay nagla-log sa bawat email na ipinadala at bawat link sa email na iyon na may base64 hash, na lumilikha ng malaking MySQL table (email_stats). Pagkatapos magpadala lamang ng 10 milyong email sa mga subscriber ng serbisyo, ang talahanayang ito ay sumakop ng 150 GB na espasyo ng file, at ang MySQL ay nagsimulang maging "hangal" sa mga simpleng query. Upang ayusin ang isyu sa espasyo ng file, matagumpay naming ginamit ang InnoDB table compression na nabawasan ito ng 4 na salik. Gayunpaman, hindi pa rin makatuwiran na mag-imbak ng higit sa 20-30 milyong mga email sa MySQL para lamang sa pagbabasa ng kasaysayan, dahil ang anumang simpleng query na para sa ilang kadahilanan ay kailangang gumawa ng isang buong pag-scan na nagreresulta sa swap at marami sa I. /O load, ayon sa kung saan kami ay regular na nakatanggap ng mga babala mula sa Zabbix.
Gumagamit ang Clickhouse ng dalawang compression algorithm na nagpapababa ng dami ng data nang humigit-kumulang , ngunit sa partikular na kaso na ito ang data ay partikular na "compressible".
Pinapalitan ang ELK
Batay sa sarili kong karanasan, ang ELK stack (ElasticSearch, Logstash at Kibana, sa partikular na kaso na ito ElasticSearch) ay nangangailangan ng mas maraming mapagkukunan upang tumakbo kaysa sa kinakailangan upang mag-imbak ng mga log. Ang ElasticSearch ay isang mahusay na engine kung kailangan mo ng mahusay na full-text log search (na sa tingin ko ay hindi mo talaga kailangan), ngunit nagtataka ako kung bakit ito ay naging de facto standard logging engine. Ang pagganap nito sa ingest na sinamahan ng Logstash ay nagbigay sa amin ng mga problema kahit na sa ilalim ng medyo magaan na pag-load at hinihiling sa amin na magdagdag ng higit at higit pang RAM at espasyo sa disk. Bilang isang database, ang Clickhouse ay mas mahusay kaysa sa ElasticSearch para sa mga sumusunod na dahilan:
- SQL dialect support;
- Ang pinakamahusay na antas ng compression ng naka-imbak na data;
- Suporta para sa Regex regular expression na paghahanap sa halip ng buong teksto na paghahanap;
- Pinahusay na pag-iiskedyul ng query at mas mataas na pangkalahatang pagganap.
Sa kasalukuyan, ang pinakamalaking problema na lumitaw kapag inihambing ang ClickHouse sa ELK ay ang kakulangan ng mga solusyon para sa pag-upload ng mga log, pati na rin ang kakulangan ng dokumentasyon at mga tutorial sa paksa. Bukod dito, maaaring i-configure ng bawat user ang ELK gamit ang Digital Ocean manual, na napakahalaga para sa mabilis na pagpapatupad ng mga naturang teknolohiya. Mayroong database engine, ngunit wala pang Filebeat para sa ClickHouse. Oo, nariyan at isang sistema para sa pagtatrabaho sa mga log , may gamit upang ipasok ang data ng log file sa ClickHouse, ngunit ang lahat ng ito ay nangangailangan ng mas maraming oras. Gayunpaman, ang ClickHouse ay nangunguna pa rin dahil sa pagiging simple nito, kaya kahit na ang mga baguhan ay madaling mai-install ito at masimulan itong gamitin nang ganap sa loob lamang ng 10 minuto.
Mas pinipili ang mga minimalist na solusyon, sinubukan kong gumamit ng FluentBit, isang tool para sa pagpapadala ng mga log na may napakakaunting memorya, kasama ang ClickHouse, habang sinusubukang iwasan ang paggamit ng Kafka. Gayunpaman, ang mga maliliit na hindi pagkakatugma ay kailangang matugunan, tulad ng bago ito magawa nang walang proxy layer na nagko-convert ng data mula sa FluentBit patungong ClickHouse.
Bilang kahalili, maaaring gamitin ang Kibana bilang backend ng ClickHouse . Mula sa naiintindihan ko, maaari itong magdulot ng mga isyu sa pagganap kapag nag-render ng malaking bilang ng mga punto ng data, lalo na sa mga mas lumang bersyon ng Grafana. Hindi pa namin ito nasubukan sa Qwintry, ngunit ang mga reklamo tungkol dito ay lumalabas paminsan-minsan sa channel ng suporta ng ClickHouse sa Telegram.
Pagpapalit ng Google Big Query at Amazon RedShift (solusyon para sa malalaking kumpanya)
Ang pinakamainam na kaso ng paggamit para sa BigQuery ay ang mag-load ng 1 TB ng JSON data at magpatakbo ng mga analytical na query dito. Ang Big Query ay isang mahusay na produkto na ang scalability ay hindi masasabing labis. Ito ay mas kumplikadong software kaysa sa ClickHouse, na tumatakbo sa isang panloob na kumpol, ngunit mula sa pananaw ng kliyente ay marami itong pagkakatulad sa ClickHouse. Mabilis na magastos ang BigQuery kapag nagsimula kang magbayad sa bawat SELECT, kaya isa itong tunay na solusyon sa SaaS kasama ang lahat ng mga kalamangan at kahinaan nito.
Ang ClickHouse ay ang pinakamahusay na pagpipilian kapag nagpapatakbo ka ng maraming computationally mahal na mga query. Kung mas maraming SELECT query ang pinapatakbo mo araw-araw, mas makatuwirang palitan ang Big Query ng ClickHouse, dahil ang gayong pagpapalit ay makakapagtipid sa iyo ng libu-libong dolyar pagdating sa maraming terabytes ng data na pinoproseso. Hindi ito nalalapat sa nakaimbak na data, na medyo mura para iproseso sa Big Query.
Sa isang artikulo ni Altinity co-founder Alexander Zaitsev ay nagsasalita tungkol sa mga benepisyo ng naturang DBMS migration.
Pagpapalit ng TimescaleDB
Ang TimescaleDB ay isang extension ng PostgreSQL na nag-o-optimize sa pagtatrabaho sa mga timeseries na time series sa isang regular na database (, ).
Bagama't ang ClickHouse ay hindi isang seryosong katunggali sa angkop na lugar ng serye ng oras, ngunit ang istraktura ng columnar at pagpapatupad ng query ng vector, ito ay mas mabilis kaysa sa TimescaleDB sa karamihan ng mga kaso ng analytical na pagproseso ng query. Kasabay nito, ang pagganap ng pagtanggap ng batch data mula sa ClickHouse ay humigit-kumulang 3 beses na mas mataas, at gumagamit din ito ng 20 beses na mas kaunting espasyo sa disk, na talagang mahalaga para sa pagproseso ng malalaking volume ng makasaysayang data: .
Hindi tulad ng ClickHouse, ang tanging paraan upang makatipid ng ilang puwang sa disk sa TimescaleDB ay ang paggamit ng ZFS o mga katulad na file system.
Ang mga paparating na update sa ClickHouse ay malamang na magpapakilala ng delta compression, na gagawing mas angkop para sa pagproseso at pag-iimbak ng data ng time series. Ang TimescaleDB ay maaaring isang mas mahusay na pagpipilian kaysa sa hubad na ClickHouse sa mga sumusunod na kaso:
- maliliit na pag-install na may napakakaunting RAM (<3 GB);
- isang malaking bilang ng maliliit na INSERT na hindi mo gustong i-buffer sa malalaking fragment;
- mas mahusay na pagkakapare-pareho, pagkakapareho at mga kinakailangan sa ACID;
- Suporta sa PostGIS;
- pagsali sa umiiral na mga talahanayan ng PostgreSQL, dahil ang Timescale DB ay mahalagang PostgreSQL.
Kumpetisyon sa Hadoop at MapReduce system
Ang Hadoop at iba pang mga produkto ng MapReduce ay maaaring magsagawa ng maraming kumplikadong kalkulasyon, ngunit malamang na tumakbo ang mga ito nang may malalaking latency. Inaayos ng ClickHouse ang problemang ito sa pamamagitan ng pagproseso ng mga terabyte ng data at paggawa ng mga resulta halos kaagad. Kaya, ang ClickHouse ay mas epektibo sa pagsasagawa ng mabilis, interactive na analytical na pananaliksik, na dapat ay interesado sa data scientist.
Kumpetisyon sa Pinot at Druid
Ang mga pinakamalapit na kakumpitensya ng ClickHouse ay columnar, linearly scalable open source na mga produkto na Pinot at Druid. Ang isang mahusay na trabaho sa paghahambing ng mga sistemang ito ay nai-publish sa artikulo napetsahan noong Pebrero 1, 2018
Ang artikulong ito ay nangangailangan ng pag-update - sinasabi nito na ang ClickHouse ay hindi sumusuporta sa mga pagpapatakbo ng UPDATE at DELETE, na hindi ganap na totoo para sa mga pinakabagong bersyon.
Wala kaming maraming karanasan sa mga database na ito, ngunit hindi ko talaga gusto ang pagiging kumplikado ng imprastraktura na kinakailangan upang patakbuhin ang Druid at Pinot - ito ay isang buong grupo ng mga gumagalaw na bahagi na napapalibutan ng Java sa lahat ng panig.
Ang Druid at Pinot ay mga proyektong incubator ng Apache, ang pag-usad nito ay sinasaklaw nang detalyado ng Apache sa mga pahina ng proyekto ng GitHub nito. Si Pinot ay lumitaw sa incubator noong Oktubre 2018, at si Druid ay ipinanganak 8 buwan na mas maaga - noong Pebrero.
Ang kakulangan ng impormasyon tungkol sa kung paano gumagana ang AFS ay nagpapataas ng ilan, at marahil ay hangal, mga tanong para sa akin. Nagtataka ako kung napansin ng mga may-akda ng Pinot na ang Apache Foundation ay mas pabor kay Druid, at kung ang saloobing ito sa katunggali ay nagdulot ng pakiramdam ng inggit? Bumagal kaya ang pag-unlad ni Druid at bibilis ang pag-unlad ni Pinot kung biglang naging interesado ang mga backers ng una sa huli?
Mga disadvantages ng ClickHouse
Immaturity: Malinaw, hindi pa rin ito nakakabagot na teknolohiya, ngunit sa anumang kaso, walang katulad nito na naobserbahan sa iba pang mga columnar DBMS.
Ang maliliit na pagsingit ay hindi gumaganap nang maayos sa mataas na bilis: ang mga pagsingit ay dapat hatiin sa mas malalaking tipak dahil ang pagganap ng maliliit na pagsingit ay bumababa ayon sa bilang ng mga column sa bawat hilera. Ito ay kung paano ang ClickHouse ay nag-iimbak ng data sa disk - ang bawat column ay kumakatawan sa 1 file o higit pa, kaya para magpasok ng 1 row na naglalaman ng 100 column, kailangan mong magbukas at magsulat ng hindi bababa sa 100 file. Ito ang dahilan kung bakit ang mga pagsingit ng buffering ay nangangailangan ng isang middleman (maliban kung ang kliyente mismo ang nagbibigay ng buffering) - karaniwang Kafka o ilang uri ng sistema ng pamamahala ng pila. Maaari mo ring gamitin ang Buffer table engine upang kopyahin sa ibang pagkakataon ang malalaking tipak ng data sa mga talahanayan ng MergeTree.
Ang mga pagsali sa talahanayan ay limitado ng RAM ng server, ngunit hindi bababa sa naroroon sila! Halimbawa, ang Druid at Pinot ay walang ganoong koneksyon, dahil mahirap silang ipatupad nang direkta sa mga distributed system na hindi sumusuporta sa paglipat ng malalaking tipak ng data sa pagitan ng mga node.
Natuklasan
Plano naming malawakang gamitin ang ClickHouse sa Qwintry sa mga darating na taon, dahil ang DBMS na ito ay nagbibigay ng mahusay na balanse ng pagganap, mababang overhead, scalability at pagiging simple. Sigurado akong magsisimula itong kumalat nang mabilis sa sandaling makabuo ang komunidad ng ClickHouse ng higit pang mga paraan upang magamit ito sa maliliit hanggang sa katamtamang laki ng mga pag-install.
Ilang ad 🙂
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com