ir atvērtā koda kolonnu datu bāzes pārvaldības sistēma tiešsaistes analītisko vaicājumu apstrādei (OLAP), ko izveidojis Yandex. To izmanto Yandex, CloudFlare, VK.com, Badoo un citi servisi visā pasaulē, lai uzglabātu patiešām lielu datu apjomu (tūkstošiem rindu sekundē vai diskā saglabāto datu petabaitu ievietošana).
Parastā “virknes” DBVS, kuras piemēri ir MySQL, Postgres, MS SQL Server, dati tiek glabāti šādā secībā:
Šajā gadījumā ar vienu rindu saistītās vērtības tiek fiziski saglabātas blakus. Kolonnu DBVS vērtības no dažādām kolonnām tiek glabātas atsevišķi, un vienas kolonnas dati tiek glabāti kopā:
Kolonnu DBVS piemēri ir Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Pasta ekspeditoru uzņēmums 2018. gadā sāka izmantot Clickhouse pārskatu sniegšanai un bija ļoti pārsteigts ar tā vienkāršību, mērogojamību, SQL atbalstu un ātrumu. Šīs DBVS ātrums robežojās ar maģiju.
Vienkāršība
Clickhouse instalē Ubuntu ar vienu komandu. Ja zināt SQL, varat nekavējoties sākt izmantot Clickhouse savām vajadzībām. Tomēr tas nenozīmē, ka pakalpojumā MySQL varat veikt “parādīt tabulu izveidei” un nokopēt un ielīmēt SQL pakalpojumā Clickhouse.
Salīdzinot ar MySQL, tabulu shēmu definīcijās ir būtiskas datu tipu atšķirības, tāpēc jums joprojām būs nepieciešams zināms laiks, lai mainītu tabulas shēmas definīcijas un apgūtu tabulu dzinējus, lai justos ērti.
Clickhouse darbojas lieliski bez papildu programmatūras, taču, ja vēlaties izmantot replikāciju, jums būs jāinstalē ZooKeeper. Vaicājumu veiktspējas analīze uzrāda izcilus rezultātus – sistēmas tabulās ir visa informācija, un visus datus var izgūt, izmantojot veco un garlaicīgo SQL.
Производительность
- Clickhouse salīdzinājumi ar Vertica un MySQL servera konfigurācijā: divas ligzdas Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 uz 8 6 TB SATA HDD, ext4.
- Clickhouse salīdzinājums ar Amazon RedShift mākoņkrātuvi.
- Emuāra fragmenti :
ClickHouse datubāzei ir ļoti vienkāršs dizains – visiem klastera mezgliem ir vienāda funkcionalitāte un koordinācijai tiek izmantots tikai ZooKeeper. Mēs izveidojām nelielu vairāku mezglu kopu un veicām testēšanu, kuras laikā atklājām, ka sistēmai ir diezgan iespaidīgs sniegums, kas atbilst apgalvotajām priekšrocībām analītiskajos DBVS etalonos. Mēs nolēmām tuvāk apskatīt ClickHouse koncepciju. Pirmais šķērslis pētniecībai bija rīku trūkums un nelielā ClickHouse kopiena, tāpēc mēs iedziļinājāmies šīs DBVS dizainā, lai saprastu, kā tā darbojas.
ClickHouse neatbalsta datu saņemšanu tieši no Kafka, jo tā ir tikai datu bāze, tāpēc mēs izveidojām paši savu adaptera pakalpojumu Go. Tas nolasīja Cap'n Proto kodētos ziņojumus no Kafka, pārveidoja tos par TSV un ievietoja tos ClickHouse partijās, izmantojot HTTP saskarni. Vēlāk mēs pārrakstījām šo pakalpojumu, lai izmantotu Go bibliotēku kopā ar ClickHouse interfeisu, lai uzlabotu veiktspēju. Izvērtējot pakešu saņemšanas veiktspēju, atklājām būtisku lietu - izrādījās, ka ClickHouse šī veiktspēja stipri ir atkarīga no paketes izmēra, tas ir, vienlaicīgi ievietoto rindu skaita. Lai saprastu, kāpēc tas notiek, mēs apskatījām, kā ClickHouse uzglabā datus.
Galvenais dzinējs vai drīzāk tabulu dzinēju saime, ko ClickHouse izmanto datu glabāšanai, ir MergeTree. Šis dzinējs ir konceptuāli līdzīgs LSM algoritmam, ko izmanto Google BigTable vai Apache Cassandra, taču izvairās veidot starpposma atmiņas tabulu un ieraksta datus tieši diskā. Tas nodrošina izcilu rakstīšanas caurlaidspēju, jo katra ievietotā pakete tiek kārtota tikai pēc primārās atslēgas, saspiesta un ierakstīta diskā, veidojot segmentu.
Atmiņas tabulas vai datu “svaiguma” jēdziena trūkums arī nozīmē, ka tos var tikai pievienot; sistēma neatbalsta mainīšanu vai dzēšanu. Pašlaik vienīgais veids, kā dzēst datus, ir dzēst tos pēc kalendārā mēneša, jo segmenti nekad nepārsniedz mēneša robežu. ClickHouse komanda aktīvi strādā, lai padarītu šo funkciju pielāgojamu. No otras puses, tas padara segmentu rakstīšanu un sapludināšanu bez strīdiem, tāpēc saņemiet caurlaidspējas skalas lineāri ar vienlaicīgu ievietojumu skaitu, līdz notiek I/O vai kodola piesātinājums.
Taču šis apstāklis nozīmē arī to, ka sistēma nav piemērota mazām paketēm, tāpēc buferēšanai tiek izmantoti Kafka servisi un ievietotāji. Turklāt ClickHouse fonā turpina nepārtraukti apvienot segmentus, lai daudzas mazas informācijas daļas tiktu apvienotas un ierakstītas vairāk reižu, tādējādi palielinot ierakstīšanas intensitāti. Tomēr pārāk daudz nesaistītu detaļu izraisīs agresīvu ieliktņu droseli, kamēr saplūšana turpināsies. Mēs esam noskaidrojuši, ka labākais kompromiss starp reāllaika datu ievadi un ievades veiktspēju ir tabulā pieņemt ierobežotu skaitu ievietošanas gadījumu sekundē.
Tabulas lasīšanas veiktspējas atslēga ir datu indeksēšana un atrašanās vieta diskā. Neatkarīgi no tā, cik ātra ir apstrāde, kad dzinējam ir jāskenē terabaiti datu no diska un jāizmanto tikai daļa no tiem, tas prasīs laiku. ClickHouse ir kolonnu veikals, tāpēc katrā segmentā ir fails katrai kolonnai (kolonnai) ar sakārtotām vērtībām katrai rindai. Tādējādi visas kolonnas, kas nav vaicājumā, vispirms var izlaist un pēc tam var apstrādāt vairākas šūnas paralēli vektorizētai izpildei. Lai izvairītos no pilnīgas skenēšanas, katram segmentam ir neliels indeksa fails.
Ņemot vērā, ka visas kolonnas ir sakārtotas pēc "primārās atslēgas", indeksa failā ir tikai katras N rindas etiķetes (tvertās rindas), lai tās varētu saglabāt atmiņā pat ļoti lielām tabulām. Piemēram, varat iestatīt noklusējuma iestatījumus uz "atzīmēt katru 8192. rindu", pēc tam "niecīgo" tabulas indeksāciju ar 1 triljonu. rindas, kas viegli iekļaujas atmiņā, aizņemtu tikai 122 070 rakstzīmes.
Sistēmas izstrāde
Clickhouse attīstībai un uzlabošanai var izsekot un pārliecinieties, ka “pieaugšanas” process notiek iespaidīgā tempā.
Popularitāte
Šķiet, ka Clickhouse popularitāte pieaug eksponenciāli, īpaši krievvalodīgo kopienā. Pagājušā gada High load 2018 konference (Maskava, 8. gada 9.–2018. novembris) parādīja, ka tādi monstri kā vk.com un Badoo izmanto Clickhouse, ar kuru vienlaikus ievieto datus (piemēram, žurnālus) no desmitiem tūkstošu serveru. 40 minūšu video . Drīzumā mēs publicēsim stenogrammu vietnē Habr, lai atvieglotu darbu ar materiālu.
Pieteikumi
Pēc kāda laika izpētei, manuprāt, ir jomas, kurās ClickHouse varētu būt noderīga vai pilnībā aizstāt citus, tradicionālākus un populārākus risinājumus, piemēram, MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot un Druīds. Tālāk ir aprakstīta informācija par ClickHouse izmantošanu, lai modernizētu vai pilnībā aizstātu iepriekš minēto DBVS.
MySQL un PostgreSQL paplašināšana
Pavisam nesen mēs biļetenu platformai daļēji aizstājām MySQL ar ClickHouse . Problēma bija tā, ka MySQL slikta dizaina dēļ reģistrēja katru nosūtīto e-pastu un katru saiti šajā e-pastā ar base64 jaucējkodu, izveidojot milzīgu MySQL tabulu (email_stats). Pēc tikai 10 miljonu e-pasta ziņojumu nosūtīšanas pakalpojumu abonentiem šī tabula aizņēma 150 GB faila vietas, un MySQL sāka būt “stulba” vienkāršos vaicājumos. Lai novērstu faila vietas problēmu, mēs veiksmīgi izmantojām InnoDB tabulas saspiešanu, kas to samazināja par 4 reizēm. Tomēr joprojām nav jēgas MySQL glabāt vairāk nekā 20–30 miljonus e-pasta ziņojumu tikai lasīšanas vēstures labad, jo jebkurš vienkāršs vaicājums, kuram kaut kādu iemeslu dēļ ir jāveic pilna skenēšana, rada mijmaiņas un daudz /O slodze, saskaņā ar kuru regulāri saņēmām Zabbix brīdinājumus.
Clickhouse izmanto divus saspiešanas algoritmus, kas aptuveni samazina datu apjomu , taču šajā konkrētajā gadījumā dati bija īpaši "saspiežami".
ELK nomaiņa
Pamatojoties uz manu pieredzi, ELK kaudze (ElasticSearch, Logstash un Kibana, šajā konkrētajā gadījumā ElasticSearch) prasa daudz vairāk resursu, nekā nepieciešams žurnālu glabāšanai. ElasticSearch ir lieliska programma, ja vēlaties labu pilna teksta žurnālu meklēšanu (kas, manuprāt, jums nav īsti vajadzīga), taču man rodas jautājums, kāpēc tā ir kļuvusi par de facto standarta reģistrēšanas dzinēju. Tās pārsūtīšanas veiktspēja kopā ar Logstash radīja problēmas pat pie diezgan nelielas darba slodzes, un bija nepieciešams pievienot arvien vairāk RAM un diska vietas. Kā datu bāze Clickhouse ir labāka par ElasticSearch šādu iemeslu dēļ:
- SQL dialektu atbalsts;
- Labākā saglabāto datu saspiešanas pakāpe;
- Atbalsts Regex regulāro izteiksmju meklēšanai pilna teksta meklēšanas vietā;
- Uzlabota vaicājumu plānošana un augstāka vispārējā veiktspēja.
Šobrīd lielākā problēma, kas rodas, salīdzinot ClickHouse ar ELK, ir risinājumu trūkums žurnālu augšupielādei, kā arī dokumentācijas un pamācību trūkums par šo tēmu. Turklāt katrs lietotājs var konfigurēt ELK, izmantojot Digital Ocean rokasgrāmatu, kas ir ļoti svarīgi šādu tehnoloģiju ātrai ieviešanai. Ir datu bāzes dzinējs, bet vēl nav Filebeat for ClickHouse. Jā, tas ir tur un sistēma darbam ar baļķiem , ir rīks lai ievadītu žurnālfaila datus ClickHouse, taču tas viss aizņem vairāk laika. Tomēr ClickHouse joprojām ir līderis savas vienkāršības dēļ, tāpēc pat iesācēji to var viegli uzstādīt un sākt lietot pilnībā funkcionāli tikai 10 minūšu laikā.
Dodot priekšroku minimālisma risinājumiem, es mēģināju izmantot FluentBit, ļoti maz atmiņas žurnālu augšupielādes rīku, ar ClickHouse, vienlaikus cenšoties izvairīties no Kafka lietošanas. Tomēr ir jānovērš nelielas nesaderības, piemēram, Pirms to var izdarīt bez starpniekservera slāņa, kas pārvērš datus no FluentBit uz ClickHouse.
Kā alternatīvu Kibana var izmantot kā ClickHouse aizmugursistēmu . Cik es saprotu, tas var izraisīt veiktspējas problēmas, renderējot milzīgu skaitu datu punktu, īpaši ar vecākām Grafana versijām. Mēs to vēl neesam izmēģinājuši vietnē Qwintry, bet sūdzības par to laiku pa laikam parādās Telegram ClickHouse atbalsta kanālā.
Google Big Query un Amazon RedShift nomaiņa (risinājums lieliem uzņēmumiem)
Ideāls BigQuery izmantošanas gadījums ir ielādēt 1 TB JSON datu un tajā izpildīt analītiskos vaicājumus. Big Query ir lielisks produkts, kura mērogojamību ir grūti pārvērtēt. Šī ir daudz sarežģītāka programmatūra nekā ClickHouse, kas darbojas iekšējā klasterī, taču no klienta viedokļa tai ir daudz kopīga ar ClickHouse. BigQuery var ātri paaugstināt cenu, tiklīdz sākat maksāt par katru SELECT, tāpēc tas ir īsts SaaS risinājums ar visiem tā plusiem un mīnusiem.
ClickHouse ir labākā izvēle, ja veicat daudz skaitļošanas ziņā dārgu vaicājumu. Jo vairāk SELECT vaicājumu izpildāt katru dienu, jo lietderīgāk ir aizstāt Big Query ar ClickHouse, jo šāda aizstāšana var ietaupīt tūkstošiem dolāru, ja runa ir par daudzu terabaitu datu apstrādi. Tas neattiecas uz saglabātajiem datiem, kuru apstrāde programmā Big Query ir diezgan lēta.
Altinity līdzdibinātāja Aleksandra Zaiceva rakstā apraksta šādas DBVS migrācijas priekšrocības.
TimescaleDB nomaiņa
TimescaleDB ir PostgreSQL paplašinājums, kas optimizē darbu ar laikrindu laikrindām parastā datu bāzē (, ).
Lai gan ClickHouse nav nopietns konkurents laikrindu nišā, taču kolonnu struktūras un vektora vaicājumu izpilde, vairumā analītisko vaicājumu apstrādes gadījumu ir daudz ātrāka par TimescaleDB. Tajā pašā laikā pakešu datu saņemšanas veiktspēja no ClickHouse ir aptuveni 3 reizes lielāka, un tā arī izmanto 20 reizes mazāk vietas diskā, kas ir patiešām svarīgi liela apjoma vēsturisko datu apstrādei: .
Atšķirībā no ClickHouse, vienīgais veids, kā ietaupīt vietu diskā TimescaleDB, ir izmantot ZFS vai līdzīgas failu sistēmas.
Gaidāmie ClickHouse atjauninājumi, iespējams, ieviesīs delta saspiešanu, kas padarīs to vēl piemērotāku laikrindu datu apstrādei un glabāšanai. TimescaleDB var būt labāka izvēle nekā tukša ClickHouse šādos gadījumos:
- mazas instalācijas ar ļoti mazu operatīvo atmiņu (<3 GB);
- liels skaits mazu INSERT, kurus nevēlaties buferizēt lielos fragmentos;
- labāka konsistence, viendabīgums un SKĀBES prasības;
- PostGIS atbalsts;
- savienošana ar esošajām PostgreSQL tabulām, jo Timescale DB būtībā ir PostgreSQL.
Konkurence ar Hadoop un MapReduce sistēmām
Hadoop un citi MapReduce produkti var veikt daudz sarežģītu aprēķinu, taču tie mēdz darboties ar milzīgu latentumu. ClickHouse novērš šo problēmu, apstrādājot terabaitus datu un gandrīz uzreiz iegūstot rezultātus. Tādējādi ClickHouse ir daudz efektīvāks, veicot ātrus, interaktīvus analītiskos pētījumus, kam vajadzētu interesēt datu zinātniekus.
Sacensības ar Pinot un Druid
ClickHouse tuvākie konkurenti ir kolonnveida, lineāri mērogojami atvērtā pirmkoda produkti Pinot un Druid. Rakstā ir publicēts lielisks šo sistēmu salīdzināšanas darbs 1. gada 2018. februāris
Šis raksts ir jāatjaunina - tajā teikts, ka ClickHouse neatbalsta UPDATE un DELETE darbības, kas nav pilnībā taisnība jaunākajām versijām.
Mums nav lielas pieredzes ar šīm DBVS, taču man nepatīk pamatā esošās infrastruktūras sarežģītība, kas nepieciešama Druid un Pinot darbināšanai - tā ir vesela virkne "kustīgu daļu", ko no visām pusēm ieskauj Java.
Druid un Pinot ir Apache inkubatoru projekti, par kuru gaitu Apache ir detalizēti atspoguļots savās GitHub projektu lapās. Pinots inkubatorā parādījās 2018. gada oktobrī, un Druīds piedzima 8 mēnešus agrāk - februārī.
Informācijas trūkums par to, kā darbojas AFS, man rada dažus un, iespējams, muļķīgus jautājumus. Interesanti, vai Pinot autori pamanīja, ka Apache fonds ir labvēlīgāks pret Druīdu, un vai šāda attieksme pret konkurentu radīja skaudības sajūtu? Vai Druīda attīstība palēnināsies un Pinot attīstība paātrināsies, ja pirmā atbalstītāji pēkšņi sāks interesēties par otro?
ClickHouse trūkumi
Nenobriedums: Acīmredzot šī joprojām nav garlaicīga tehnoloģija, taču jebkurā gadījumā nekas tāds nav novērots citās kolonnu DBVS.
Mazie ieliktņi nedarbojas labi lielā ātrumā: ieliktņi ir jāsadala lielākos gabalos, jo mazo ieliktņu veiktspēja pasliktinās proporcionāli kolonnu skaitam katrā rindā. Tādā veidā ClickHouse saglabā datus diskā – katra kolonna apzīmē 1 vai vairāk failu, tāpēc, lai ievietotu 1 rindu, kurā ir 100 kolonnas, ir jāatver un jāieraksta vismaz 100 faili. Tāpēc buferizācijas ieliktņiem ir nepieciešams starpnieks (ja vien klients pats nenodrošina buferizāciju) - parasti Kafka vai kāda veida rindu pārvaldības sistēma. Varat arī izmantot bufera tabulas programmu, lai vēlāk kopētu lielus datu gabalus MergeTree tabulās.
Tabulu savienojumus ierobežo servera RAM, bet vismaz tie ir tur! Piemēram, Druid un Pinot šādu savienojumu vispār nav, jo tos ir grūti ieviest tieši sadalītās sistēmās, kas neatbalsta lielu datu gabalu pārvietošanu starp mezgliem.
Atzinumi
Nākamajos gados mēs plānojam plaši izmantot ClickHouse programmā Qwintry, jo šī DBVS nodrošina izcilu veiktspējas līdzsvaru, zemas pieskaitāmās izmaksas, mērogojamību un vienkāršību. Esmu diezgan pārliecināts, ka tas sāks ātri izplatīties, tiklīdz ClickHouse kopiena nāks klajā ar vairākiem veidiem, kā to izmantot mazās un vidēja izmēra instalācijās.
Dažas reklāmas 🙂
Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, , unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).
Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai šeit Nīderlandē! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB — no 99 USD! Lasīt par
Avots: www.habr.com
