është një sistem i menaxhimit të bazës së të dhënave kolone me burim të hapur për përpunimin e pyetjeve analitike në internet (OLAP), krijuar nga Yandex. Përdoret nga Yandex, CloudFlare, VK.com, Badoo dhe shërbime të tjera në mbarë botën për të ruajtur sasi vërtet të mëdha të dhënash (duke futur mijëra rreshta në sekondë ose petabajt të të dhënave të ruajtura në disk).
Në një DBMS të rregullt, "string", shembuj të të cilit janë MySQL, Postgres, MS SQL Server, të dhënat ruhen në rendin e mëposhtëm:
Në këtë rast, vlerat e lidhura me një rresht ruhen fizikisht afër. Në DBMS kolone, vlerat nga kolona të ndryshme ruhen veçmas, dhe të dhënat nga një kolonë ruhen së bashku:
Shembuj të DBMS-ve kolone 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 e dërguesit të postës filloi të përdorte Clickhouse në 2018 për raportim dhe ishte shumë i impresionuar me thjeshtësinë, shkallëzueshmërinë, mbështetjen dhe shpejtësinë e SQL. Shpejtësia e kësaj DBMS kufizohej me magjinë.
Lehtësi
Clickhouse është instaluar në Ubuntu me një komandë të vetme. Nëse e dini SQL, mund të filloni menjëherë të përdorni Clickhouse për nevojat tuaja. Megjithatë, kjo nuk do të thotë që ju mund të bëni "tregoni krijimin e tabelës" në MySQL dhe kopjoni-ngjisni SQL në Clickhouse.
Krahasuar me MySQL, ka dallime të rëndësishme të llojeve të të dhënave në përkufizimet e skemës së tabelës, kështu që do t'ju duhet ende pak kohë për të ndryshuar përkufizimet e skemës së tabelës dhe për të mësuar motorët e tabelave për t'u rehatuar.
Clickhouse funksionon shkëlqyeshëm pa ndonjë softuer shtesë, por nëse dëshironi të përdorni replikimin, do t'ju duhet të instaloni ZooKeeper. Analiza e performancës së pyetjeve tregon rezultate të shkëlqyera - tabelat e sistemit përmbajnë të gjithë informacionin dhe të gjitha të dhënat mund të merren duke përdorur SQL të vjetër dhe të mërzitshëm.
prodhimtari
- Krahasimet e Clickhouse me Vertica dhe MySQL në konfigurimin e serverit: dy priza Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 në 8 6TB SATA HDD, ext4.
- Krahasimi i Clickhouse me ruajtjen e cloud të Amazon RedShift.
- Fragmente nga blogu :
Baza e të dhënave ClickHouse ka një dizajn shumë të thjeshtë - të gjitha nyjet në grup kanë të njëjtin funksionalitet dhe përdorin vetëm ZooKeeper për koordinim. Ne ndërtuam një grup të vogël me disa nyje dhe kryem testime, gjatë të cilave zbuluam se sistemi ka performancë mjaft mbresëlënëse, e cila korrespondon me avantazhet e deklaruara në standardet analitike të DBMS. Ne vendosëm të hedhim një vështrim më të afërt në konceptin që qëndron pas ClickHouse. Pengesa e parë për kërkimin ishte mungesa e mjeteve dhe komuniteti i vogël ClickHouse, kështu që ne u futëm në hartimin e kësaj DBMS për të kuptuar se si funksionon.
ClickHouse nuk mbështet marrjen e të dhënave direkt nga Kafka pasi është thjesht një bazë të dhënash, kështu që ne kemi shkruar shërbimin tonë të përshtatësit në Go. Ai lexoi mesazhet e koduara Cap'n Proto nga Kafka, i konvertoi në TSV dhe i futi në ClickHouse në grupe përmes ndërfaqes HTTP. Më vonë e rishkruam këtë shërbim për të përdorur bibliotekën Go në lidhje me ndërfaqen e vetë ClickHouse për të përmirësuar performancën. Kur vlerësuam performancën e marrjes së paketave, zbuluam një gjë të rëndësishme - doli që për ClickHouse kjo performancë varet fuqishëm nga madhësia e paketës, domethënë nga numri i rreshtave të futur njëkohësisht. Për të kuptuar pse ndodh kjo, ne shikuam se si ClickHouse ruan të dhënat.
Motori kryesor, ose më mirë familja e motorëve të tabelave, i përdorur nga ClickHouse për të ruajtur të dhënat është MergeTree. Ky motor është konceptualisht i ngjashëm me algoritmin LSM të përdorur në Google BigTable ose Apache Cassandra, por shmang ndërtimin e një tabele të ndërmjetme memorie dhe shkruan të dhënat direkt në disk. Kjo i jep asaj një xhiro të shkëlqyeshme të shkrimit, pasi çdo paketë e futur renditet vetëm nga çelësi primar, kompresohet dhe shkruhet në disk për të formuar një segment.
Mungesa e një tabele memorie ose ndonjë koncepti të "freskisë" të të dhënave do të thotë gjithashtu se ato mund të shtohen vetëm; sistemi nuk mbështet ndryshimin ose fshirjen. Aktualisht, mënyra e vetme për të fshirë të dhënat është fshirja e tyre sipas muajit kalendarik, pasi segmentet nuk kalojnë kurrë kufirin e një muaji. Ekipi i ClickHouse po punon në mënyrë aktive për ta bërë këtë veçori të personalizueshme. Nga ana tjetër, ai bën që segmentet e shkrimit dhe bashkimit të jenë pa grindje, kështu që merrni shkallët e xhiros në mënyrë lineare me numrin e inserteve të njëkohshme derisa të ndodhë ngopja e I/O ose bërthamës.
Megjithatë, kjo do të thotë gjithashtu se sistemi nuk është i përshtatshëm për paketa të vogla, kështu që shërbimet dhe futësit Kafka përdoren për buferim. Më pas, ClickHouse në sfond vazhdon të kryejë vazhdimisht bashkimin e segmenteve, në mënyrë që shumë pjesë të vogla informacioni të kombinohen dhe regjistrohen më shumë herë, duke rritur kështu intensitetin e regjistrimit. Megjithatë, shumë pjesë të palidhura do të shkaktojnë mbytje agresive të futjeve për sa kohë që bashkimi vazhdon. Kemi zbuluar se kompromisi më i mirë midis gëlltitjes në kohë reale dhe performancës së gëlltitjes është futja e një numri të kufizuar futjesh për sekondë në tabelë.
Çelësi për performancën e leximit të tabelës është indeksimi dhe vendndodhja e të dhënave në disk. Pavarësisht se sa i shpejtë është përpunimi, kur motori duhet të skanojë terabajt të dhëna nga disku dhe të përdorë vetëm një pjesë të tyre, do të duhet kohë. ClickHouse është një dyqan kolone, kështu që çdo segment përmban një skedar për secilën kolonë (kolona) me vlera të renditura për çdo rresht. Në këtë mënyrë, kolonat e tëra që mungojnë nga pyetja mund të anashkalohen fillimisht, dhe më pas qelizat e shumta mund të përpunohen paralelisht me ekzekutimin e vektorizuar. Për të shmangur një skanim të plotë, çdo segment ka një skedar të vogël indeksi.
Duke qenë se të gjitha kolonat janë të renditura sipas "çelësit primar", skedari i indeksit përmban vetëm etiketat (rreshtat e kapur) të çdo rreshti të nëntë për t'i mbajtur ato në kujtesë edhe për tabela shumë të mëdha. Për shembull, mund të vendosni cilësimet e paracaktuara për të "shënuar çdo rresht të 8192-të", më pas indeksimin "i pakët" të një tabele me 1 trilion. linjat që futen lehtësisht në memorie do të marrin vetëm 122 karaktere.
Zhvillimi i sistemit
Zhvillimi dhe përmirësimi i Clickhouse mund të gjurmohen në dhe sigurohuni që procesi i "rritjes" të ndodhë me një ritëm mbresëlënës.
Popullaritet
Popullariteti i Clickhouse duket se po rritet në mënyrë eksponenciale, veçanërisht në komunitetin rusisht-folës. Konferenca e vitit të kaluar me ngarkesë të lartë 2018 (Moskë, 8-9 nëntor 2018) tregoi se monstra të tillë si vk.com dhe Badoo përdorin Clickhouse, me të cilin futin të dhëna (për shembull, regjistrat) nga dhjetëra mijëra serverë njëkohësisht. Në një video 40 minutëshe . Së shpejti do të postojmë transkriptin në Habr për lehtësinë e punës me materialin.
aplikimet
Pasi kalova ca kohë duke hulumtuar, mendoj se ka fusha ku ClickHouse mund të jetë i dobishëm ose mund 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ë përshkruan detajet e përdorimit të ClickHouse për të modernizuar ose zëvendësuar plotësisht DBMS-në e mësipërme.
Zgjerimi i aftësive të MySQL dhe PostgreSQL
Kohët e fundit ne zëvendësuam pjesërisht MySQL me ClickHouse për platformën tonë të buletinit . Problemi ishte se MySQL, për shkak të një dizajni të dobët, po regjistronte çdo email të dërguar dhe çdo lidhje në atë email me një hash base64, duke krijuar një tabelë të madhe MySQL (email_stats). Pasi dërgoi vetëm 10 milionë email për abonentët e shërbimit, kjo tabelë zinte 150 GB hapësirë skedari dhe MySQL filloi të ishte "budallaqe" në pyetje të thjeshta. Për të rregulluar problemin e hapësirës së skedarit, ne përdorëm me sukses kompresimin e tabelës InnoDB, i cili e zvogëloi atë me një faktor prej 4. Megjithatë, ende nuk ka kuptim të ruash më shumë se 20-30 milionë emaile në MySQL vetëm për hir të leximit të historisë, pasi çdo pyetje e thjeshtë që për ndonjë arsye duhet të bëjë një skanim të plotë rezulton në shkëmbim dhe shumë /O ngarkesës, sipas së cilës rregullisht kemi marrë paralajmërime nga Zabbix.
Clickhouse përdor dy algoritme kompresimi që reduktojnë vëllimin e të dhënave përafërsisht , por në këtë rast të veçantë të dhënat ishin veçanërisht të "ngjeshshme".
Zëvendësimi i ELK
Bazuar në përvojën time, grupi ELK (ElasticSearch, Logstash dhe Kibana, në këtë rast të veçantë ElasticSearch) kërkon shumë më tepër burime për të ekzekutuar sesa është e nevojshme për të ruajtur regjistrat. ElasticSearch është një motor i shkëlqyeshëm nëse keni nevojë për një kërkim të mirë të regjistrave me tekst të plotë (që nuk mendoj se ju nevojitet vërtet), por pyes veten pse është bërë motori standard de facto i prerjeve. Performanca e marrjes së tij e kombinuar me Logstash na dha probleme edhe nën ngarkesa mjaft të lehta dhe na kërkoi të shtonim gjithnjë e më shumë RAM dhe hapësirë në disk. Si bazë të dhënash, Clickhouse është më i mirë se ElasticSearch për arsyet e mëposhtme:
- mbështetje për dialekt SQL;
- Shkalla më e mirë e kompresimit të të dhënave të ruajtura;
- Mbështetje për kërkimet me shprehje të rregullta Regex në vend të kërkimeve me tekst të plotë;
- Planifikimi i përmirësuar i pyetjeve dhe performanca e përgjithshme më e lartë.
Aktualisht, problemi më i madh që lind kur krahasojmë ClickHouse me ELK është mungesa e zgjidhjeve për ngarkimin e regjistrave, si dhe mungesa e dokumentacionit dhe udhëzimeve për këtë temë. Për më tepër, çdo përdorues mund të konfigurojë ELK duke përdorur manualin Digital Ocean, i cili është shumë i rëndësishëm për zbatimin e shpejtë të teknologjive të tilla. Ekziston një motor i bazës së të dhënave, por ende nuk ka Filebeat për ClickHouse. Po, është aty dhe një sistem për të punuar me shkrimet , ka një mjet për të futur të dhënat e skedarit log në ClickHouse, por e gjithë kjo kërkon më shumë kohë. Megjithatë, ClickHouse është ende lider për shkak të thjeshtësisë së tij, kështu që edhe fillestarët mund ta instalojnë lehtësisht dhe të fillojnë ta përdorin atë plotësisht funksionalisht në vetëm 10 minuta.
Duke preferuar zgjidhjet minimaliste, u përpoqa të përdor FluentBit, një mjet për dërgimin e regjistrave me shumë pak memorie, së bashku me ClickHouse, ndërsa përpiqesha të shmangja përdorimin e Kafkës. Megjithatë, duhet të adresohen papajtueshmëritë e vogla, si p.sh përpara se kjo të mund të bëhet pa shtresën proxy që konverton të dhënat nga FluentBit në ClickHouse.
Si një alternativë, Kibana mund të përdoret si një backend ClickHouse . Nga sa kuptoj unë, kjo mund të shkaktojë probleme të performancës kur jepet një numër i madh pikash të dhënash, veçanërisht me versionet më të vjetra të Grafana. Ne nuk e kemi provuar ende këtë në Qwintry, por ankesat për këtë shfaqen herë pas here në kanalin mbështetës të ClickHouse në Telegram.
Zëvendësimi i Google Big Query dhe Amazon RedShift (zgjidhje për kompanitë e mëdha)
Rasti ideal i përdorimit për BigQuery është të ngarkoni 1 TB të dhëna JSON dhe të ekzekutoni pyetje analitike në të. Big Query është një produkt i shkëlqyer, shkallëzueshmëria e të cilit nuk mund të mbivlerësohet. Ky është softuer shumë më kompleks se ClickHouse, i cili funksionon në një grup të brendshëm, por nga këndvështrimi i klientit ai ka shumë të përbashkëta me ClickHouse. BigQuery mund të kushtojë shpejt sapo të filloni të paguani për SELECT, kështu që është një zgjidhje e vërtetë SaaS me të gjitha të mirat dhe të këqijat e saj.
ClickHouse është zgjidhja më e mirë kur kryeni shumë pyetje të shtrenjta llogaritëse. Sa më shumë pyetje SELECT të kryeni çdo ditë, aq më shumë ka kuptim të zëvendësoni Big Query me ClickHouse, sepse një zëvendësim i tillë mund t'ju kursejë mijëra dollarë kur bëhet fjalë për shumë terabajt të dhëna që përpunohen. Kjo nuk vlen për të dhënat e ruajtura, të cilat janë mjaft të lira për t'u përpunuar në Big Query.
Në një artikull nga bashkëthemeluesi i Altinity Alexander Zaitsev flet për përfitimet e një migrimi të tillë DBMS.
Zëvendësimi i TimescaleDB
TimescaleDB është një shtesë PostgreSQL që optimizon punën me seritë kohore të serive në një bazë të dhënash të rregullt (, ).
Edhe pse ClickHouse nuk është një konkurrent serioz në kamare të serive kohore, por struktura kolone dhe ekzekutimi i pyetjeve vektoriale, është shumë më i shpejtë se TimescaleDB në shumicën e rasteve të përpunimit analitik të pyetjeve. Në të njëjtën kohë, performanca e marrjes së të dhënave të grupit nga ClickHouse është afërsisht 3 herë më e lartë, dhe gjithashtu përdor 20 herë më pak hapësirë në disk, gjë që është vërtet e rëndësishme për përpunimin e vëllimeve të mëdha të të dhënave historike: .
Ndryshe nga ClickHouse, mënyra e vetme për të kursyer pak hapësirë në disk në TimescaleDB është të përdorni ZFS ose sisteme skedarësh të ngjashëm.
Përditësimet e ardhshme të ClickHouse ka të ngjarë të prezantojnë kompresimin delta, gjë që do ta bëjë atë edhe më të përshtatshëm për përpunimin dhe ruajtjen e të dhënave të serive kohore. TimescaleDB mund të jetë një zgjedhje më e mirë se ClickHouse e zhveshur në rastet e mëposhtme:
- instalime të vogla me shumë pak RAM (<3 GB);
- një numër i madh INSERT-sh të vegjël që nuk dëshironi t'i mbuloni në fragmente të mëdha;
- konsistencë më të mirë, uniformitet dhe kërkesa për ACID;
- Mbështetje PostGIS;
- duke u bashkuar me tabelat ekzistuese PostgreSQL, pasi Timescale DB është në thelb PostgreSQL.
Konkurrenca me sistemet Hadoop dhe MapReduce
Hadoop dhe produktet e tjera të MapReduce mund të kryejnë shumë llogaritje komplekse, por ato priren të funksionojnë me vonesa të mëdha. ClickHouse e rregullon këtë problem duke përpunuar terabajt të dhëna dhe duke prodhuar rezultate pothuajse menjëherë. Kështu, ClickHouse është shumë më efektiv në kryerjen e kërkimeve analitike të shpejta, interaktive, të cilat duhet të jenë me interes për shkencëtarët e të dhënave.
Konkurrenca me Pinot dhe Druid
Konkurrentët më të afërt të ClickHouse janë produktet me kod të hapur në formë kolone, të shkallëzuara në mënyrë lineare, Pinot dhe Druid. Një punë e shkëlqyer që krahason këto sisteme është botuar në artikull datë 1 shkurt 2018
Ky artikull ka nevojë për përditësim - thotë se ClickHouse nuk mbështet operacionet UPDATE dhe DELETE, gjë që nuk është plotësisht e vërtetë për versionet më të fundit.
Ne nuk kemi shumë përvojë me këto baza të dhënash, por nuk më pëlqen shumë kompleksiteti i infrastrukturës që kërkohet për të ekzekutuar Druid dhe Pinot - është një grup i tërë pjesësh lëvizëse të rrethuara nga Java nga të gjitha anët.
Druid dhe Pinot janë projekte të inkubatorit Apache, përparimi i të cilave mbulohet në detaje nga Apache në faqet e tij të projektit GitHub. Pinot u shfaq në inkubator në tetor 2018, dhe Druid lindi 8 muaj më parë - në shkurt.
Mungesa e informacionit se si funksionon AFS-ja ngre disa pyetje, dhe ndoshta budallaqe, për mua. Pyes veten nëse autorët Pinot vunë re që Fondacioni Apache është më i favorshëm ndaj Druidit dhe nëse ky qëndrim ndaj konkurrentit shkaktoi një ndjenjë zilie? A do të ngadalësohet zhvillimi i Druidit dhe zhvillimi i Pinot-it do të përshpejtohet nëse mbështetësit e të parit interesohen papritur për të dytin?
Disavantazhet e ClickHouse
Papjekuria: Natyrisht, kjo nuk është ende një teknologji e mërzitshme, por në çdo rast, asgjë e tillë nuk vërehet në DBMS-të e tjera kolone.
Futjet e vogla nuk funksionojnë mirë me shpejtësi të lartë: futjet duhet të ndahen në copa më të mëdha sepse performanca e futjeve të vogla degradon në proporcion me numrin e kolonave në çdo rresht. Kjo është mënyra se si ClickHouse ruan të dhënat në disk - çdo kolonë përfaqëson 1 skedar ose më shumë, kështu që për të futur 1 rresht që përmban 100 kolona, duhet të hapni dhe shkruani të paktën 100 skedarë. Kjo është arsyeja pse futjet e bufferimit kërkojnë një ndërmjetës (përveç nëse vetë klienti ofron buffering) - zakonisht Kafka ose një lloj sistemi i menaxhimit të radhëve. Ju gjithashtu mund të përdorni motorin e tabelës Buffer për të kopjuar më vonë pjesë të mëdha të të dhënave në tabelat MergeTree.
Lidhjet e tabelave janë të kufizuara nga RAM-i i serverit, por të paktën ato janë atje! Për shembull, Druid dhe Pinot nuk kanë fare lidhje të tilla, pasi ato janë të vështira për t'u zbatuar drejtpërdrejt në sistemet e shpërndara që nuk mbështesin lëvizjen e pjesëve të mëdha të të dhënave midis nyjeve.
Gjetjet
Ne planifikojmë të përdorim gjerësisht ClickHouse në Qwintry në vitet e ardhshme, pasi kjo DBMS ofron një ekuilibër të shkëlqyer të performancës, shpenzime të ulëta, shkallëzueshmëri dhe thjeshtësi. Jam shumë i sigurt se do të fillojë të përhapet shpejt sapo komuniteti ClickHouse të gjejë më shumë mënyra për ta përdorur atë në instalime të vogla dhe të mesme.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më 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 dollarë! Lexoni rreth
Burimi: www.habr.com