ni mfumo huria wa usimamizi wa hifadhidata kwa ajili ya usindikaji wa hoja za uchambuzi mtandaoni (OLAP), iliyoundwa na Yandex. Inatumiwa na Yandex, CloudFlare, VK.com, Badoo na huduma zingine duniani kote kuhifadhi kiasi kikubwa cha data (kuingiza maelfu ya safu kwa sekunde au petabytes ya data iliyohifadhiwa kwenye diski).
Katika kawaida, "kamba" DBMS, mifano ambayo ni MySQL, Postgres, MS SQL Server, data huhifadhiwa kwa mpangilio huu:
Katika kesi hii, maadili yanayohusiana na safu moja yanahifadhiwa kwa upande. Katika safu ya DBMS, maadili kutoka kwa safu wima tofauti huhifadhiwa kando, na data ya safu moja huhifadhiwa pamoja:
Mifano ya safu za DBMS ni Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Kampuni ni msambazaji barua Nilianza kutumia Clickhouse mnamo 2018 kwa kuripoti na nilifurahishwa sana na unyenyekevu wake, uzani, usaidizi wa SQL, na kasi. Kasi ya DBMS hii ilipakana na uchawi.
Unyenyekevu
Clickhouse imewekwa kwenye Ubuntu na amri moja. Ikiwa unajua SQL, unaweza kuanza mara moja kutumia Clickhouse kwa mahitaji yako. Walakini, hii haimaanishi kuwa unaweza "kuonyesha jedwali la kuunda" katika MySQL na kunakili-kubandika SQL kwenye Clickhouse.
Ikilinganishwa na MySQL, kuna tofauti muhimu za aina ya data katika ufafanuzi wa schema ya jedwali katika DBMS hii, kwa hivyo bado unahitaji muda wa kubadilisha ufafanuzi wa schema ya jedwali na ujifunze injini za jedwali ili ustarehe.
Clickhouse inafanya kazi vizuri bila programu yoyote ya ziada, lakini ikiwa unataka kutumia replication utahitaji kusakinisha ZooKeeper. Uchambuzi wa utendaji wa hoja unaonyesha matokeo bora - jedwali za mfumo zina habari yote, na data yote inaweza kupatikana kwa kutumia SQL ya zamani na ya kuchosha.
Uzalishaji
- Bofya dhidi ya Vertica na MySQL ulinganisho kwenye seva ya usanidi: soketi mbili Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 kwenye 8 6TB SATA HDD, ext4.
- kulinganisha kwa Clickhouse na hifadhi ya wingu ya Amazon RedShift.
- Dondoo za blogi :
Hifadhidata ya ClickHouse ina muundo rahisi sana - nodi zote kwenye nguzo zina utendakazi sawa na hutumia ZooKeeper pekee kwa uratibu. Tulijenga kundi dogo la nodi kadhaa na kufanya majaribio, ambapo tuligundua kuwa mfumo una utendakazi wa kuvutia kabisa, ambao unalingana na faida zinazodaiwa katika vigezo vya uchanganuzi vya DBMS. Tuliamua kuangalia kwa karibu dhana nyuma ya ClickHouse. Kizuizi cha kwanza cha utafiti kilikuwa ukosefu wa zana na jamii ndogo ya ClickHouse, kwa hivyo tulijishughulisha na muundo wa DBMS hii ili kuelewa jinsi inavyofanya kazi.
ClickHouse haitumii kupokea data moja kwa moja kutoka kwa Kafka, kwani ni hifadhidata tu, kwa hivyo tuliandika huduma yetu ya adapta katika Go. Ilisoma jumbe zilizosimbwa za Cap'n Proto kutoka Kafka, kuzibadilisha kuwa TSV, na kuziingiza kwenye ClickHouse kwa makundi kupitia kiolesura cha HTTP. Baadaye tuliandika upya huduma hii ili kutumia maktaba ya Go kwa kushirikiana na kiolesura chetu cha ClickHouse ili kuboresha utendakazi. Wakati wa kutathmini utendaji wa pakiti za kupokea, tuligundua jambo muhimu - ikawa kwamba kwa ClickHouse utendaji huu unategemea sana ukubwa wa pakiti, yaani, idadi ya safu zilizoingizwa kwa wakati mmoja. Ili kuelewa kwa nini hii inatokea, tuliangalia jinsi ClickHouse huhifadhi data.
Injini kuu, au tuseme, familia ya injini za meza zinazotumiwa na ClickHouse kwa kuhifadhi data, ni MergeTree. Injini hii kimawazo inafanana na algoriti ya LSM inayotumiwa katika Google BigTable au Apache Cassandra, lakini inaepuka kuunda jedwali la kumbukumbu la kati na huandika data moja kwa moja kwenye diski. Hii huipa upitishaji bora wa uandishi, kwani kila pakiti iliyoingizwa hupangwa tu na kitufe cha msingi cha "kitufe cha msingi", kilichobanwa, na kuandikwa kwa diski kuunda sehemu.
Kutokuwepo kwa meza ya kumbukumbu au dhana yoyote ya "upya" wa data pia ina maana kwamba wanaweza tu kuongezwa, mfumo hauunga mkono kubadilisha au kufuta. Kuanzia leo, njia pekee ya kufuta data ni kuifuta kulingana na mwezi wa kalenda, kwani sehemu hazivuka mipaka ya mwezi. Timu ya ClickHouse inajitahidi sana kufanya kipengele hiki kiweze kubinafsishwa. Kwa upande mwingine, hufanya uandishi na uunganishaji usiwe na ugomvi, kwa hivyo pokea mizani ya upitishaji kwa mstari na idadi ya vichochezi sambamba hadi I/O au cores zijae.
Hata hivyo, hali hii pia inamaanisha kuwa mfumo haufai kwa pakiti ndogo, hivyo huduma za Kafka na viingiza hutumiwa kwa kuakibisha. Zaidi ya hayo, ClickHouse katika usuli inaendelea kuunganisha sehemu, ili vipande vingi vidogo vya habari vitaunganishwa na kurekodiwa mara nyingi zaidi, hivyo basi kuongeza kasi ya kurekodi. Hata hivyo, sehemu nyingi sana ambazo hazihusiani zitasababisha mgandamizo mkali wa viingilio mradi tu muunganisho uendelee. Tumegundua kuwa maelewano bora zaidi kati ya uwekaji data katika wakati halisi na utendakazi wa kumeza ni kukubali idadi ndogo ya ingizo kwa sekunde kwenye jedwali.
Ufunguo wa utendaji wa usomaji wa jedwali ni indexing na eneo la data kwenye diski. Haijalishi jinsi usindikaji ni wa haraka, wakati injini inahitaji kuchambua terabytes ya data kutoka kwa diski na kutumia sehemu yake tu, itachukua muda. ClickHouse ni duka la safu wima, kwa hivyo kila sehemu ina faili kwa kila safu (safu wima) iliyo na maadili yaliyopangwa kwa kila safu. Kwa hivyo, safu wima nzima ambazo hazipo kwenye hoja zinaweza kwanza kurukwa, na kisha seli nyingi zinaweza kuchakatwa sambamba na utekelezaji wa vekta. Ili kuzuia skanning kamili, kila sehemu ina faili ndogo ya faharasa.
Kwa kuzingatia kwamba safu wima zote zimepangwa kwa "ufunguo wa msingi", faili ya faharisi ina lebo tu (safu zilizopigwa) za kila safu ya Nth, ili kuweza kuziweka kwenye kumbukumbu hata kwa jedwali kubwa sana. Kwa mfano, unaweza kuweka mipangilio chaguo-msingi ili "kuweka alama kwenye kila safu mlalo ya 8192", kisha uwekaji faharasa "kidogo" wa jedwali lenye trilioni 1. mistari ambayo inatoshea kwa urahisi kwenye kumbukumbu inaweza kuchukua herufi 122 pekee.
Uendelezaji wa mfumo
Ukuzaji na uboreshaji wa Clickhouse unaweza kupatikana kwa na hakikisha kwamba mchakato wa "kukua" hutokea kwa kasi ya kuvutia.
Umaarufu
Inaonekana kwamba umaarufu wa Clickhouse unakua kwa kasi, hasa katika jumuiya inayozungumza Kirusi. Mkutano wa mwaka jana wa Highload 2018 (Moscow, Novemba 8-9, 2018) ulionyesha kuwa monsters kama vk.com na Badoo hutumia Clickhouse, ambayo huingiza data (kwa mfano, kumbukumbu) kutoka kwa makumi ya maelfu ya seva wakati huo huo. Katika video ya dakika 40 . Hivi karibuni tutachapisha nakala kwenye Habr kwa urahisi wa kufanya kazi na nyenzo.
Maombi
Baada ya kutumia muda kutafiti, nadhani kuna maeneo ambayo ClickHouse inaweza kuwa muhimu au kuweza kubadilisha kabisa suluhisho zingine za kitamaduni na maarufu kama vile MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot na Druid. Yafuatayo ni maelezo ya kutumia ClickHouse kuboresha au kubadilisha kabisa DBMS hapo juu.
Kupanua MySQL na PostgreSQL
Hivi majuzi, tulibadilisha sehemu ya MySQL na ClickHouse kwa jukwaa la jarida . Shida ilikuwa kwamba MySQL kwa sababu ya muundo mbaya iliingia kila barua pepe iliyotumwa na kila kiunga kwenye barua pepe hiyo na heshi ya base64, na kuunda jedwali kubwa la MySQL (email_stats). Baada ya kutuma barua pepe milioni 10 tu kwa wanachama wa huduma, meza hii ilichukua GB 150 ya nafasi ya faili, na MySQL ilianza "kijinga" kwa maswali rahisi. Ili kurekebisha suala la nafasi ya faili, tulifanikiwa kutumia mbano la jedwali la InnoDB, ambalo lilipunguza kwa sababu ya 4. Walakini, bado haina maana kuhifadhi barua pepe zaidi ya milioni 20-30 kwenye MySQL kwa sababu ya kusoma historia, kwani swala lolote rahisi ambalo kwa sababu fulani lazima lifanye matokeo kamili ya skanisho kwa kubadilishana na I/O nzito. juu, ambayo mara kwa mara tulipokea maonyo ya Zabbix.
Clickhouse hutumia kanuni mbili za ukandamizaji ambazo hupunguza kiwango cha data kwa takriban , lakini katika kesi hii, data ilikuwa "compressible".
Kubadilisha ELK
Kulingana na uzoefu wangu mwenyewe, safu ya ELK (ElasticSearch, Logstash na Kibana, katika kesi hii ElasticSearch) inahitaji rasilimali nyingi zaidi kuendesha kuliko inahitajika kuhifadhi kumbukumbu. ElasticSearch ni injini nzuri ikiwa unataka utaftaji mzuri wa kumbukumbu wa maandishi kamili (ambayo sidhani kama unahitaji sana), lakini ninashangaa kwa nini imekuwa injini ya ukataji miti ya kawaida. Utendaji wake wa kumeza, pamoja na Logstash, ulitupa matatizo hata kwa upakiaji mwepesi wa kazi na ulihitaji kuongezwa kwa RAM na nafasi zaidi ya diski. Kama hifadhidata, Clickhouse ni bora kuliko ElasticSearch kwa sababu zifuatazo:
- Msaada wa lahaja ya SQL;
- Kiwango bora cha ukandamizaji wa data iliyohifadhiwa;
- Usaidizi wa utafutaji wa kawaida wa kujieleza wa Regex badala ya utafutaji wa maandishi kamili;
- Ratiba ya hoja iliyoboreshwa na utendakazi bora kwa ujumla.
Hivi sasa, tatizo kubwa linalojitokeza wakati wa kulinganisha ClickHouse na ELK ni ukosefu wa ufumbuzi wa kupakia magogo, pamoja na ukosefu wa nyaraka na mafunzo juu ya mada hii. Wakati huo huo, kila mtumiaji anaweza kuanzisha ELK kwa kutumia mwongozo wa Bahari ya Digital, ambayo ni muhimu sana kwa utekelezaji wa haraka wa teknolojia hizo. Kuna injini ya hifadhidata hapa, lakini hakuna Filebeat ya ClickHouse bado. Ndio ipo na mfumo wa kufanya kazi na magogo , kuna chombo kuingiza data ya faili ya logi kwenye ClickHouse, lakini yote haya huchukua muda zaidi. Walakini, ClickHouse bado ni kiongozi kwa sababu ya unyenyekevu wake, kwa hivyo hata wanaoanza wanaweza kuisakinisha kwa urahisi na kuanza kuitumia kikamilifu kwa dakika 10 tu.
Kwa kupendelea suluhisho za udogo, nilijaribu kutumia FluentBit, zana ya upakiaji ya kumbukumbu ya chini sana, na ClickHouse wakati nikijaribu kuzuia kutumia Kafka. Walakini, kutokubaliana kidogo kunahitaji kushughulikiwa, kama vile kabla ya kufanywa bila safu ya wakala inayobadilisha data kutoka FluentBit hadi ClickHouse.
Kama mbadala wa Kibana, unaweza kutumia ClickHouse kama njia ya nyuma . Ninavyoelewa, hii inaweza kusababisha matatizo ya utendaji wakati wa kutoa idadi kubwa ya pointi za data, hasa kwa matoleo ya zamani ya Grafana. Katika Qwintry, bado hatujajaribu hili, lakini malalamiko kuhusu hili yanaonekana mara kwa mara kwenye kituo cha usaidizi cha ClickHouse katika Telegram.
Uingizwaji wa Google Big Query na Amazon RedShift (suluhisho kwa kampuni kubwa)
Kesi bora ya utumiaji ya BigQuery ni kupakia 1TB ya data ya JSON na kuendesha hoja za uchanganuzi juu yake. Big Query ni bidhaa nzuri ambayo uzani wake ni ngumu kukadiria. Hii ni programu ngumu zaidi kuliko ClickHouse inayoendesha kwenye nguzo ya ndani, lakini kwa mtazamo wa mteja, ina mengi sawa na ClickHouse. BigQuery inaweza "kupandisha bei" kwa haraka mara tu unapoanza kulipia kila SELECT, kwa hivyo ni suluhisho halisi la SaaS pamoja na faida na hasara zake zote.
ClickHouse ndio chaguo bora wakati unauliza maswali mengi ya gharama kubwa. Kadiri ulivyo hoji SELECT kila siku, ndivyo inavyoleta maana zaidi kubadilisha Hoji Kubwa na ClickHouse, kwa sababu uingizwaji kama huo unaweza kuokoa maelfu ya dola inapokuja kwa terabaiti nyingi za data kuchakatwa. Hii haitumiki kwa data iliyohifadhiwa, ambayo ni nafuu kabisa kuchakata katika Hoja Kubwa.
Katika makala ya Alexander Zaitsev, mwanzilishi mwenza wa Altinity inaelezea faida za uhamiaji kama huo wa DBMS.
Ubadilishaji wa TimescaleDB
TimescaleDB ni kiendelezi cha PostgreSQL ambacho kinaboresha kufanya kazi na vipindi kwenye hifadhidata ya kawaida (, ).
Ingawa ClickHouse sio mshindani mkubwa katika niche ya safu ya wakati, lakini kwa suala la muundo wa safu na utekelezaji wa hoja ya vekta, ni haraka sana kuliko TimescaleDB katika hali nyingi za kuchakata maswali ya uchanganuzi. Wakati huo huo, utendaji wa kupokea data ya pakiti ya ClickHouse ni karibu mara 3 zaidi, kwa kuongeza, hutumia nafasi ya diski mara 20, ambayo ni muhimu sana kwa usindikaji wa data kubwa ya kihistoria: .
Tofauti na ClickHouse, njia pekee ya kuhifadhi nafasi ya diski katika TimescaleDB ni kutumia ZFS au mifumo sawa ya faili.
Masasisho yajayo kwa ClickHouse yataanzisha ukandamizaji wa delta, ambayo itaifanya kufaa zaidi kwa usindikaji na kuhifadhi data ya mfululizo wa saa. TimescaleDB inaweza kuwa chaguo bora kuliko ClickHouse wazi katika kesi zifuatazo:
- mitambo ndogo na RAM kidogo sana (<3 GB);
- idadi kubwa ya INSERT ndogo ambazo hutaki kuziba katika vipande vikubwa;
- uthabiti bora, usawa na mahitaji ya ACID;
- Msaada wa PostGIS;
- unganisha na jedwali zilizopo za PostgreSQL, kwani Timescale DB kimsingi ni PostgreSQL.
Ushindani na mifumo ya Hadoop na MapReduce
Hadoop na bidhaa zingine za MapReduce zinaweza kufanya hesabu nyingi changamano, lakini huwa zinafanya kazi kwa utulivu mkubwa. ClickHouse hutatua tatizo hili kwa kuchakata terabaiti za data na kutoa matokeo karibu mara moja. Kwa hivyo, ClickHouse ni bora zaidi kwa kufanya utafiti wa uchambuzi wa haraka, unaoingiliana, ambao unapaswa kuwa wa kupendeza kwa wanasayansi wa data.
Ushindani na Pinot na Druid
Washindani wa karibu zaidi wa ClickHouse ni safu, bidhaa za chanzo huria zinazoweza kusambazwa zaidi Pinot na Druid. Kazi bora ya kulinganisha mifumo hii imechapishwa katika makala Februari 1, 2018
Nakala hii inahitaji kusasishwa - inasema kwamba ClickHouse haiauni shughuli za UPDATE na DELETE, ambayo sio kweli kabisa kuhusiana na matoleo ya hivi karibuni.
Hatuna uzoefu mwingi na DBMS hizi, lakini sipendi ugumu wa miundombinu ya msingi ambayo inahitajika kuendesha Druid na Pinot - ni rundo zima la "sehemu zinazosonga" zilizozungukwa na Java kutoka pande zote.
Druid na Pinot ni miradi ya incubator ya Apache, ambayo imefunikwa kwa kina na Apache kwenye kurasa zao za mradi wa GitHub. Pinot alionekana kwenye incubator mnamo Oktoba 2018, na Druid alizaliwa miezi 8 mapema - mnamo Februari.
Ukosefu wa habari kuhusu jinsi AFS inavyofanya kazi huibua maswali, na labda ya kijinga, kwangu. Ninashangaa ikiwa waandishi wa Pinot waligundua kuwa Wakfu wa Apache una mwelekeo zaidi kwa Druid, na je, mtazamo kama huo kwa mshindani ulisababisha hisia za wivu? Maendeleo ya Druid yatapungua na maendeleo ya Pinot yataharakisha ikiwa wafadhili wanaounga mkono wa zamani watapendezwa na mwisho?
Hasara za ClickHouse
Ukomavu: Ni wazi, hii bado ni teknolojia ya kuchosha, lakini kwa hali yoyote, hakuna kitu kama hiki kinachoonekana kwenye safu zingine za DBMS.
Ingizo ndogo hazifanyi kazi vizuri kwa kasi ya juu: viingilio lazima vigawanywe katika vipande vikubwa kwa sababu utendakazi wa vichocheo vidogo huharibika kulingana na idadi ya safu wima katika kila safu. Hivi ndivyo ClickHouse huhifadhi data kwenye diski - kila safu inawakilisha faili 1 au zaidi, kwa hivyo ili kuingiza safu 1 iliyo na safu wima 100, unahitaji kufungua na kuandika angalau faili 100. Hii ndiyo sababu viingilio vya kuakibisha huhitaji mtu wa kati (isipokuwa mteja mwenyewe hutoa uakifishaji) - kwa kawaida Kafka au aina fulani ya mfumo wa usimamizi wa foleni. Unaweza pia kutumia injini ya jedwali la Buffer ili baadaye kunakili sehemu kubwa za data kwenye jedwali la MergeTree.
Viunga vya jedwali vimepunguzwa na RAM ya seva, lakini angalau zipo! Kwa mfano, Druid na Pinot hawana uhusiano huo wakati wote, kwa kuwa ni vigumu kutekeleza moja kwa moja katika mifumo iliyosambazwa ambayo haiunga mkono kusonga vipande vikubwa vya data kati ya nodes.
Matokeo
Tunapanga kutumia sana ClickHouse huko Qwintry katika miaka ijayo, kwani DBMS hii hutoa usawa bora wa utendakazi, uendeshaji wa chini, scalability na unyenyekevu. Nina hakika itaanza kuenea haraka mara tu jumuiya ya ClickHouse itakapokuja na njia zaidi za kuitumia katika usakinishaji mdogo hadi wa kati.
Baadhi ya matangazo 🙂
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com