— është një sistem menaxhimi bazash të dhënash me kolona për përpunimin online të kërkesave analitike (OLAP) me kod të hapur, i krijuar nga Yandex. Përdoret nga Yandex, CloudFlare, VK.com, Badoo dhe shërbime të tjera në mbarë botën për ruajtjen e vëllimeve të mëdha të të dhënave (inserimi i mijëra rreshtave në sekondë ose petabayt të dhënash të ruajtura në disk).
Në një DBMS të zakonshëm, të quajtur 'të rreshtave', shembuj të të cilëve janë MySQL, Postgres, MS SQL Server, të dhënat ruhen në këtë rend:
Në këtë rast, vlerat që i përkasin një rreshti ruhen fizikisht pranë njëra-tjetrës. Në DBMS-të me kolona, vlerat nga kolona të ndryshme ruhen veçmas, ndërsa të dhënat e një kolone – bashkë:
Shembuj të DBMS-ve me kolona janë Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Kompania – mailforwarder filloi të përdorë Clickhouse në vitin 2018 për përgatitjen e raporteve dhe u impresionua shumë nga thjeshtësia, shkallëzueshmëria, mbështetja SQL dhe shpejtësia e saj. Shpejtësia e punës së këtij DBMS ishte në prag të magjisë.
Thjeshtësia
Clickhouse instalohet në Ubuntu me një komandë të vetme. Nëse e njihni SQL-in, mund të filloni menjëherë ta përdorni Clickhouse për nevojat tuaja. Megjithatë, kjo nuk do të thotë se mund të kryeni "show create table" në MySQL dhe të kopjoni-pastoni SQL-in në Clickhouse.
Në krahasim me MySQL, në këtë DBMS ekzistojnë dallime të rëndësishme në llojet e të dhënave në definicionet e skemave të tabelave, kështu që për të punuar rehat ju nevojitet pak kohë për të ndryshuar definicionet e skemave të tabelave dhe për të studiuar motorët e tabelave.
Clickhouse funksionon shkëlqyer pa ndonjë softuer të shtesë, por nëse dëshironi të përdorni replikimin, do t'ju nevojitet të instaloni ZooKeeper. Analiza e performancës së pyetjeve tregon rezultate të shkëlqyera — tabelat sistemike përmbajnë të gjitha informacionet, dhe të gjitha të dhënat mund të merren përmes SQL-it të vjetër dhe të mërzitshëm.
Performanca
- krahasimi i Clickhouse me Vertica dhe MySQL në serverin me konfigurim: dy socket-e Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 me 8 6TB SATA HDD, ext4.
- krahasimi i Clickhouse me magazinën e të dhënave në cloud Amazon RedShift.
- Përmbledhje nga blogu :
Baza e të dhënave ClickHouse ka një dizajn shumë të thjeshtë — të gjithë nyjat në klaster kanë funksionalitete të njëjta dhe përdorin vetëm ZooKeeper për koordinim. Ne ndërtuam një klaster të vogël prej disa nyjash dhe kryem testime, gjatë të cilave zbuluam se sistemi ka një performancë mjaft mbresëlënëse, e cila përputhet me avantazhet e deklaruara në benchmarket e DB-ve analitike. Vendosëm të shqyrtonim më në detaje konceptin në thelb të ClickHouse. Pengesa e parë për hulumtimin ishte mungesa e mjeteve dhe pakësia e komunitetit ClickHouse, prandaj u thelluam në dizajnin e kësaj DB-je për të kuptuar si funksionon.
ClickHouse nuk mbështet marrjen e të dhënave drejtpërdrejt nga Kafka, pasi kjo është vetëm një bazë të dhënash, prandaj ne shkruam një shërbim adaptues të ndërtuar me gjuhën Go. Ai lexonte mesazhet e koduara Cap’n Proto nga Kafka, i shndërronte ato në TSV dhe i insertonte në ClickHouse në grupe përmes HTTP-it. Më vonë, ne e riparametruam këtë shërbim për të përdorur biblioteken Go së bashku me ndërfaqen tonë të ClickHouse për të rritur performancën. Gjatë vlerësimit të performancës së marrjes së grupeve, zbuluam një gjë të rëndësishme – doli se për ClickHouse, kjo performancë varet shumë nga madhësia e grupit, dmth, numri i rreshtave që insertohen në një kohë. Për të kuptuar pse ndodh kjo, ne studiuam se si ClickHouse ruan të dhënat.
Motori kryesorë, më saktësisht, familja e motorëve për tabela që përdoret nga ClickHouse për ruajtjen e të dhënave është MergeTree. Ky motor është konceptualisht i ngjashëm me algoritmin LSM, i cili aplikohet në Google BigTable ose Apache Cassandra, megjithatë shmang ndërtimin e një tabele ndërmjetëse në memorie dhe shkruan të dhënat drejtpërdrejt në disk. Kjo i jep atij një kapacitet të shkëlqyer të shkrimit, pasi çdo paketë e futur renditet vetëm sipas “çelësit primar” primary key, kompresohet dhe shkruhet në disk për të formuar një segment.
Mungesa e një tabele të memories ose ndonjë koncepti të 'risisë' së të dhënave gjithashtu do të thotë se ato mund të shtohen vetëm; modifikimi ose fshirja nuk mbështetet nga sistemi. Aktualisht, mënyra e vetme për të fshirë të dhënat është t'i fshini ato sipas muajve kalendarikë, pasi segmentet kurrë nuk kalojnë kufirin e muajit. Ekipi i ClickHouse po punon aktivisht për ta bërë këtë funksionalitet të personalizueshëm. Nga ana tjetër, kjo e bën regjistrimin dhe bashkimin e segmenteve pa konflikte, kështu që kapaciteti i pranimit rritet në mënyrë lineare me numrin e inserteve paralele deri në të njëjtën kohë kur ndodh saturimi i I/O ose bërthamave.
Megjithatë, kjo situatë gjithashtu do të thotë se sistemi nuk është i përshtatshëm për paketa të vogla, prandaj përdoren shërbime Kafka dhe inserter për buferizimin. Më pas, ClickHouse vazhdon të kryejë vazhdimisht bashkimin e segmenteve në sfond, kështu që shumë pjesë të vogla informacioni do të kombinohen dhe do të shkruhen më shumë herë, duke rritur kështu intensitetin e shkruarjes. Në këtë proces, një numër i tepruar pjesësh të pazakontë do të shkaktojë një trotllem të agresiv të inserteve derisa bashkimi të vazhdojë. Ne zbuluam se kompromisi më i mirë midis pranimit të të dhënave në kohë reale dhe performancës është marrja në një tabelë e një numri të kufizuar insertesh në sekondë.
Çelësi për performancën e leximit të tabelave është indeksimi dhe vendosja e dhënave në disk. Pavarësisht sa e shpejtë është përpunimi, kur motorit i nevojitet të skanojë terabajt të dhënash nga disku dhe të përdorë vetëm një pjesë të tyre, do të marrë kohë. ClickHouse është një magazinë kolonash, prandaj çdo segment përmban një skedë për çdo kolone me vlera të renditura për çdo rresht. Kështu, kolona të tëra, që nuk janë të pranishme në kërkesë, mund të kalohen fillimisht, dhe pastaj disa qeliza mund të përpunohen paralelisht me ekzekutimin e vektorizuar. Për të shmangur skanimin e plotë, çdo segment ka një skedë të vogël indeksi.
Duke pasur parasysh se të gjitha kolonet janë të renditura sipas 'çelësit të parë', skeda e indeksit përmban vetëm etiketat (rreshtat e kapur) të çdo rreshti N-të, për të pasur mundësi t'i ruajë ato në memorie edhe për tabela shumë të mëdha. Për shembull, mund të vendosen cilësimet e paracaktuara 'të etiketohen çdo 8192 rresht', atëherë 'indeksimi i skajshëm' i një tabele me 1 trilion rreshtash, e cila lehtë përshtatet në memorie, do të marrë vetëm 122,070 karaktere.
Zhvillimi i sistemit
Zhvillimi dhe përmirësimi i Clickhouse mund të ndiqen në dhe të siguroheni se procesi i "rritjes" po ndodh me ritme të habitshme.
Popullariteti
Duket se popullariteti i Clickhouse po rritet eksponencialisht, veçanërisht në komunitetin anglishtfolës. Konferenca e vitit të kaluar High Load 2018 (Moskë, 8-9 nëntor 2018) tregoi se monstru të tillë si vk.com dhe Badoo, përdorin Clickhouse për të futur të dhëna (p.sh., loge) nga dhjetëra mijëra serverë në të njëjtën kohë. Në videon 40-minutëshe . Shpejt do të publikojmë transkriptin në Habr për lehtësimin e punës me materialin.
Fushat e aplikimit
Pas disa kohësh hulumtimi, mendoj se ka fusha ku ClickHouse mund të jetë e dobishme ose të jetë në gjendje të zëvendësojë plotësisht zgjidhje të tjera, më tradicionale dhe të njohura, si MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot dhe Druid. Më poshtë janë përshkrime të detajuara të përdorimit të ClickHouse për modernizimin ose zëvendësimin e plotë të sistemeve të menaxhimit të të dhënave të përmendura.
Zgjerimi i mundësive të MySQL dhe PostgreSQL
Para pak ditë më parë, ne zëvendësuam pjesërisht MySQL me ClickHouse për platformën e buletinëve informativë. . Problemi ishte se MySQL, për shkak të një dizajni të paplanifikuar, regjistronte çdo email të dërguar dhe çdo lidhje në këtë email me një hash base64, duke krijuar një tabelë të madhe MySQL (email_stats). Pas dërgimit të vetëm 10 milion email-e për abonentët e shërbimit, kjo tabelë zinte 150 GB hapësirë dyshe dhe MySQL fillonte të 'ngadalësohej' në kërkesat e thjeshta. Për të zgjidhur problemin e hapësirës së skedarëve, ne përdorëm me sukses kompresimin e tabelës InnoDB, e cila e zvogëloi atë me 4 herë. Megjithatë, nuk ka sens të ruhet më shumë se 20-30 milion email-e në MySQL thjesht për të lexuar historinë, pasi çdo kërkesë e thjeshtë që për një arsye ndonjëherë duhet të përfitojë një skanim të plotë sjell në swap dhe ngarkesë të madhe në I/O, për të cilën ne rregullisht merrnim paralajmërime nga Zabbix.
ClickHouse përdor dy algoritme kompresimi, të cilët reduktojnë volumet e të dhënave rreth , por në këtë rast të veçantë të dhënat ishin veçanërisht 'të kompresueshme'.
Zëvendësimi i ELK
Duke përvojës sime, staku ELK (ElasticSearch, Logstash dhe Kibana, në këtë rast konkret ElasticSearch) kërkon shumë më tepër burime për të funksionuar se sa është e nevojshme për ruajtjen e logëve. ElasticSearch është një motor i shkëlqyer, nëse ju nevojitet një kërkim i mirë me tekst të plotë në logë (dhe nuk mendoj se realisht ju duhet), por më intereson, pse de-fakto ka ndodhur që ai të bëhet standardi për mbajtjen e eksperiencave. Performanca e pranimit të tij bashkë me Logstash na ka krijuar probleme edhe me ngarkesa mjaft të vogla dhe ka kërkuar gjithnjë e më shumë memorie RAM dhe hapësirë disku. Si një DB, Clickhouse është më i mirë se ElasticSearch për arsye të mëposhtme:
- Mbështetje për dialektin SQL;
- Shkalla më e mirë e kompresionit të të dhënave të ruajtura;
- Mbështetje për kërkimin me shprehje të rregullta Regex përveç kërkimit të tekstit të plotë;
- Planifikim të përmirësuar të pyetjeve dhe performancë më të lartë në përgjithësi.
Aktualisht, problemi më i madh që lind kur krahasohet ClickHouse me ELK është mungesa e zgjidhjeve për eksportimin e logeve, si dhe mungesa e dokumentacionit dhe materialeve mësimore mbi këtë temë. Megjithatë, çdo përdorues mund ta konfigurojë ELK duke përdorur udhëzimin e Digital Ocean, gjë që është shumë e rëndësishme për një implementim të shpejtë të teknologjive të tilla. Ka një motor databazash këtu, por ende nuk ka Filebeat për ClickHouse. Po, aty ka dhe një sistem për punë me loge , ekziston një mjet për futjen në ClickHouse të të dhënave nga skedarët e logeve, por gjithçka kërkon më shumë kohë. Megjithatë, ClickHouse vazhdon të mbetet në krye për shkak të thjeshtësisë së tij, kështu që edhe fillestarët e instalojnë lehtësisht dhe fillojnë përdorimin e plotë funksional brenda vetëm 10 minutash.
Duke preferuar zgjidhje minimalistike, përpiqesha të përdorja FluentBit, një mjet për eksportimin e logeve me shumë pak kujtesë, së bashku me ClickHouse, duke u munduar të shmang përfshirjen e Kafka-s. Megjithatë, është e nevojshme të eliminohen disa moskompatibilitete të vogla, siç janë , прежде чем это можно будет сделать без proxy-слоя, который преобразует данные из FluentBit в ClickHouse.
В качестве альтернативы Kibana можно в роли бэкенда ClickHouse использовать . Насколько я понял, при этом могут возникать проблемы с производительностью при рендеринге огромного количества пунктов данных, особенно с более старыми версиями Grafana. В Qwintry мы пока что это не пробовали, но жалобы на такое время от времени появляются на канале поддержки ClickHouse в Telegram.
Замена Google Big Query и Amazon RedShift (решение для крупных компаний)
Идеальный вариант использования BigQuery – это загрузить 1 ТБ данных JSON и выполните по ним аналитические запросы. Big Query — это отличный продукт, масштабируемость которого трудно переоценить. Это гораздо более сложное ПО, чем ClickHouse, работающее на внутреннем кластере, но с точки зрения клиента оно имеет много общего с ClickHouse. BigQuery может быстро «подорожать», как только вы станете платить за каждый SELECT, так что это настоящее решение SaaS со всеми его плюсами и минусами.
ClickHouse është zgjidhja më e mirë nëse po kryeni shumë kërkesa të shtrenjta në mënyrë llogarithmike. Sa më shumë kërkesa SELECT që kryeni çdo ditë, aq më shumë ka kuptim të zëvendësoni Big Query me ClickHouse, sepse një zëvendësim i tillë do t'ju ndihmojë të kurseni mijëra dollarë kur flasim për shumë terabajtë të dhënash në përpunim. Kjo nuk i referohet të dhënave të ruajtura, përpunimi i të cilave në Big Query është relativisht i lirë.
Në artikullin e bashkëndërtuesit të kompanisë Altinity, Aleksandër Zajtsev përshkruhen përfitimet e një migre të tillë të DBMS.
Zëvendësimi i TimescaleDB
TimescaleDB është një zgjerim i PostgreSQL që optimizon punën me seritë e kohës (timeseries) në një bazë të dhënash normale, ).
Megjithëse ClickHouse nuk është një konkurent i rëndësishëm në nişën e serive temporale, struktura kolone dhe ekzekutimi vektorial i kërkesave e bëjnë atë shumë më të shpejtë se TimescaleDB në shumicën e rasteve të përpunimit të kërkesave analitike. Performanca e pranimit të të dhënave në grupe nga ClickHouse është rreth 3 herë më e lartë, dhe për më tepër, ai përdor 20 herë më pak hapësirë disk, gjë që është me të vërtetë e rëndësishme për përpunimin e volumit të madh të të dhënave historike:.
Në ndryshim nga ClickHouse, mënyra e vetme për të kursyer ndonjë hapësirë disk në TimescaleDB është përdorimi i ZFS ose sistemeve të ngjashme të skedarëve.
Përditësimet e ardhshme të ClickHouse, me siguri do të prezantojnë kompresimin delta, i cili do ta bëjë atë edhe më të përshtatshëm për përpunimin dhe ruajtjen e të dhënave të serive temporale. TimescaleDB mund të bëhet zgjedhja më e mirë se "ClickHouse i papërpunuar" në rastet e mëposhtme:
- instalime të vogla me sasi shumë të vogël të memorjes së brendshme (<3 GB);
- një numër të madh INSERT-esh të vogla që nuk dëshironi t'i bufferizoni në fragmente të mëdha;
- koherencë më e mirë, një formë dhe kërkesa ACI;
- mbështetje për PostGIS;
- Integrimi me tabelat ekzistuese PostgreSQL, pasi në thelb Timescale DB është PostgreSQL.
Konkurrenca me sistemet Hadoop dhe MapReduce
Hadoop dhe produkte të tjera MapReduce mund të kryejnë shumë llogaritje komplekse, por zakonisht funksionojnë me vonesa të mëdha. ClickHouse zgjidh këtë problem duke trajtuar terabajt të dhënash dhe duke e nxjerrë rezultatin pothuajse menjëherë. Kështu, ClickHouse është shumë më efektiv për kryerjen e studimeve analitike të shpejta dhe interaktive, që duhet të tërheqë specialistët në fushën e përpunimit të të dhënave.
Konkurrenca me Pinot dhe Druid
Konkurrentët më të afërt të ClickHouse janë produktet open source columnar dhe linear-scaling Pinot dhe Druid. Një krahasim i shkëlqyer i këtyre sistemeve është publikuar në artikullin më 1 shkurt 2018.
Ky artikull kërkon përditësim – përmendet se ClickHouse nuk mbështet operacionet UPDATE dhe DELETE, që nuk është plotësisht e saktë për versionet e fundit.
Nuk kemi përvojë të mjaftueshme me këto DBMS, por nuk më pëlqen aspak kompleksiteti i infrastrukturës që kërkohet për të nisur Druid dhe Pinot — është një grumbull "pjesësh lëvizëse", të rrethuara nga Java nga të gjitha anët.
Druid dhe Pinot janë projekte inkubator në Apache, dhe zhvillimi i tyre është ndjekur në detaje nga Apache në faqet e projekteve të tyre në GitHub. Pinot u shfaq në inkubator në tetor 2018, ndërsa Druid u lind 8 muaj më herët – në shkurt.
Mungesa e informacionit mbi mënyrën se si funksionon AFS, më ngre disa, ndoshta, pyetje të çuditshme. Është interesante, a kanë vënë re autorët e Pinot se Fondacioni Apache është më i prirur ndaj Druid, dhe a ka shkaktuar një ndjenjë zili për konkurrencën? A do të ngadalësohet zhvillimi i Druid dhe do të përshpejtohet zhvillimi i Pinot, nëse sponsorët që mbështesin të parin, papritur interesohen për të dytin?
Disavantazhet e ClickHouse
Pjekuria: është e qartë se kjo është ende një teknologji e papjekur, por në çdo rast, nuk ka asgjë të ngjashme në DBMS të tjera me kolona.
Injektet e vogla funksionojnë keq me shpejtësi të lartë: injektet duhet të ndahen në pjesë të mëdha, sepse performanca e injekteve të vogla zvogëlohet proporcionalisht me numrin e kolonave në çdo rresht. Kështu ruhet të dhënat në ClickHouse në disk — çdo kolonë përfaqëson 1 skedarin ose më shumë, prandaj, për të injektuar 1 rresht që përmban 100 kolona, është e nevojshme të hapen dhe shkruhen të paktën 100 skedarë. Prandaj, nevojitet një ndërmjetës për buferimin e injekteve (nëse klienti vetë nuk siguron buferimin) — zakonisht është Kafka ose ndonjë sistem menaxhimi të radhëve. Gjithashtu mund të përdoret motori Buffer table për të kopjuar më vonë fragmente të mëdha të të dhënave në tabelat MergeTree.
Këputjet e tabelave janë të kufizuara nga memoria operativë e serverit, megjithatë, të paktën, ato ekzistojnë atje! Për shembull, Druid dhe Pinot nuk kanë fare këto këputje, duke qenë se është e vështirë t'i implementosh drejtpërdrejt në sistemet e shpërndara që nuk mbështesin transferimin e copave të mëdha të të dhënave midis nyjave.
Përfundimet
Në vitet në vijim, ne planifikojmë të përdorim gjerësisht ClickHouse në Qwintry, pasi kjo bazë e të dhënash ofron një balancim të shkëlqyer midis performancës, kostove të ulta, shkallëzueshmërisë dhe thjeshtësisë. Jam pothuajse i sigurt se ajo do të fillojë të përhapet shpejt, sapo komuniteti ClickHouse të gjejë më shumë mënyra për ta përdorur në instalime të vogla dhe të mesme.
Pak reklamë 🙂
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish më i lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — nga $99! Lexoni rreth
Burimi: habr.com
