Yandex-ek sortutako kode irekiko zutabe datu-baseak kudeatzeko sistema bat da, lineako kontsulta analitikoak prozesatzeko (OLAP). Yandex, CloudFlare, VK.com, Badoo eta mundu osoko beste zerbitzu batzuek erabiltzen dute datu kopuru benetan handiak gordetzeko (segundoko milaka errenkada edo diskoan gordetako datu petabyte sartuz).
"kate" DBMS normal batean, horien adibideak MySQL, Postgres, MS SQL Server dira, datuak ordena honetan gordetzen dira:
Kasu honetan, errenkada bati lotutako balioak fisikoki elkarren ondoan gordetzen dira. DBMS zutabeetan, zutabe ezberdinetako balioak bereizita gordetzen dira eta zutabe bateko datuak elkarrekin gordetzen dira:
Zutabe-DBMSen adibideak dira Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Enpresa posta bidaltzailea da 2018an hasi zen Clickhouse erabiltzen txostenak egiteko eta oso harrituta geratu zen bere sinpletasunarekin, eskalagarritasunarekin, SQL laguntzarekin eta abiadurarekin. DBMS honen abiadura magiarekin muga egiten zuen.
arintzeko
Clickhouse Ubuntun instalatuta dago komando bakar batekin. SQL ezagutzen baduzu, berehala has zaitezke Clickhouse erabiltzen zure beharretarako. Hala ere, horrek ez du esan nahi "sortu taula" MySQL-n eta SQL kopiatu-itsatsi dezakezuenik Clickhouse-n.
MySQL-rekin alderatuta, datu-moten desberdintasun garrantzitsuak daude DBMS honetako taula-eskemaren definizioetan, beraz, oraindik denbora pixka bat behar duzu taula-eskema-definizioak aldatzeko eta taula-motorrak ikasteko eroso egoteko.
Clickhouse-k ondo funtzionatzen du software gehigarririk gabe, baina erreplikazioa erabili nahi baduzu ZooKeeper instalatu beharko duzu. Kontsulten errendimenduaren analisiak emaitza bikainak erakusten ditu - sistema-taulek informazio guztia dute eta datu guztiak SQL zahar eta aspergarria erabiliz lor daitezke.
produktibitatea
- Clickhouse versus Vertica eta MySQL konparaketak konfigurazio zerbitzarian: bi socket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 8 TB SATA HDD-n, ext6.
- Clickhouse-ren alderaketa Amazon RedShift hodeiko biltegiratzearekin.
- Blogaren zatiak :
ClickHouse datu-baseak diseinu oso sinplea du: klusterreko nodo guztiek funtzionalitate bera dute eta ZooKeeper bakarrik erabiltzen dute koordinaziorako. Hainbat nodoz osatutako multzo txiki bat eraiki genuen eta probak egin genituen, eta horietan sistemak nahiko errendimendu ikusgarria duela ikusi genuen, eta hori DBMS analitikoen erreferentziazko abantailekin bat dator. ClickHouseren atzean dagoen kontzeptua gertutik aztertzea erabaki genuen. Ikerketarako lehen oztopoa tresnen falta eta ClickHouse komunitate txikia izan ziren, beraz, DBMS honen diseinuan sakondu genuen nola funtzionatzen duen ulertzeko.
ClickHouse-k ez du onartzen Kafka-tik zuzenean datuak jasotzea, datu-base bat besterik ez baita, beraz, gure egokitzaile-zerbitzua idatzi dugu Go-n. Cap'n Proto-k Kafka-ren kodetutako mezuak irakurri zituen, TSV bihurtu zituen eta ClickHousen txertatu zituen loteka HTTP interfazearen bidez. Geroago zerbitzu hau berridatzi dugu Go liburutegia gure ClickHouse interfazearekin batera erabiltzeko, errendimendua hobetzeko. Paketeak jasotzearen errendimendua ebaluatzean, gauza garrantzitsu bat aurkitu dugu: ClickHouserentzat errendimendu hau paketearen tamainaren araberakoa da, hau da, aldi berean txertatutako errenkada kopuruaren araberakoa dela. Hori zergatik gertatzen den ulertzeko, ClickHouse-k datuak nola gordetzen dituen aztertu dugu.
Motor nagusia, edo hobeto esanda, ClickHousek datuak gordetzeko erabiltzen duen taula-motor familia bat, MergeTree da. Motor hau Google BigTable edo Apache Cassandra-n erabiltzen den LSM algoritmoaren antzekoa da kontzeptualki, baina tarteko memoria-taula bat eraikitzea saihesten du eta datuak zuzenean diskoan idazten ditu. Honek idazketa-erritmo bikaina ematen du, txertatutako pakete bakoitza "gako nagusi" gako nagusiaren arabera bakarrik ordenatzen baita, konprimituta eta diskoan idazten baita segmentu bat osatzeko.
Memoria-taularik edo datuen "freskotasun" kontzepturik ez egoteak esan nahi du soilik gehitu daitezkeela, sistemak ez du onartzen aldatzea edo ezabatzea. Gaurtik aurrera, datuak ezabatzeko modu bakarra hilabete naturalaren arabera ezabatzea da, segmentuek ez baitute hilabete bateko muga gainditzen. ClickHouse taldea aktiboki lanean ari da funtzio hau pertsonalizagarria izan dadin. Bestalde, idazketa eta batuketa segmentuak liskarrik gabeko bihurtzen ditu, beraz, jaso karga-eskalak linealki txertatze paraleloen kopuruarekin, I/O edo nukleoak saturatu arte.
Hala ere, horrek esan nahi du sistema ez dela pakete txikietarako egokia, beraz Kafka zerbitzuak eta txertatzaileak buffererako erabiltzen dira. Ondoren, ClickHouse-k atzeko planoan segmentu bategitea egiten jarraitzen du etengabe, eta, beraz, informazio txiki asko aldiz gehiago konbinatu eta grabatuko dira, horrela grabazioaren intentsitatea handituz. Hala ere, konektatu gabeko zati gehiegik txertaketak moteldu erasokorrak eragingo ditu, bateratzeak jarraitzen duen bitartean. Ikusi dugu denbora errealeko ingesta eta ingesta-errendimenduaren arteko konpromisorik onena taulan segundoko txertaketa kopuru mugatu bat sartzea dela.
Taulen irakurketaren errendimenduaren gakoa diskoan datuak indexatzea eta kokapena da. Ez du axola zein azkarra den prozesatzea, motorrak diskotik datuen terabyte eskaneatu eta zati bat bakarrik erabili behar duenean, denbora beharko du. ClickHouse zutabe denda bat da, beraz, segmentu bakoitzak zutabe bakoitzeko fitxategi bat dauka (zutabea), errenkada bakoitzeko balio ordenatuak dituena. Horrela, kontsultan ez dauden zutabe osoak saltatu daitezke lehenik, eta, ondoren, gelaxka anitz prozesatu daitezke exekuzio bektorialarekin paraleloan. Eskaneatu osoa saihesteko, segmentu bakoitzak indize fitxategi txiki bat du.
Zutabe guztiak "gako nagusiaren arabera" ordenatuta daudela kontuan hartuta, indize-fitxategiak Ngarren errenkada bakoitzaren etiketak (harrapatutako errenkadak) baino ez ditu, taula oso handietan ere memorian gorde ahal izateko. Esate baterako, ezarpen lehenetsiak "8192. errenkada bakoitza markatzeko" ezar ditzakezu, eta gero bilioi bat duen taula baten "eskasa" indexatzeko. Memorian erraz sartzen diren lerroek 1 karaktere baino ez dituzte hartuko.
Sistemaren garapena
Clickhouse-ren garapena eta hobekuntza jarraipena egin daiteke eta ziurtatu “hazteko” prozesua erritmo ikusgarrian gertatzen ari dela.
ospea
Clickhouse-ren ospea esponentzialki hazten ari dela dirudi, batez ere errusiera hiztunen komunitatean. Iazko High load 2018 konferentziak (Mosku, 8ko azaroaren 9tik 2018ra) erakutsi zuen vk.com eta Badoo bezalako munstroek Clickhouse erabiltzen dutela, eta horrekin aldi berean dozenaka mila zerbitzaritako datuak (adibidez, erregistroak) sartzen dituzte. 40 minutuko bideo batean . Laster transkripzioa Habr-en argitaratuko dugu, materiala lantzeko erraztasunerako.
aplikazioetan
Denbora pixka bat ikertzen eman ondoren, uste dut badaudela ClickHouse erabilgarria izan daitekeen edo guztiz ordezkatzeko gai diren beste irtenbide tradizional eta ezagunagoak, hala nola MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot eta Druida. Honako hauek dira goiko DBMSa berritzeko edo guztiz ordezkatzeko ClickHouse erabiltzearen xehetasunak.
MySQL eta PostgreSQL-en gaitasunak zabaltzea
Duela gutxi MySQL partzialki ordezkatu dugu ClickHouse-rekin gure buletin plataformarako . Arazoa zen MySQL-k gaizki asmatutako diseinuaren ondorioz bidalitako mezu elektroniko guztiak eta mezu elektroniko horretako esteka guztiak base64 hash batekin erregistratzen zituela, MySQL taula erraldoi bat sortuz (email_stats). Zerbitzuaren harpidedunei 10 milioi mezu elektroniko besterik ez bidali ondoren, taula honek 150 GB fitxategi-espazioa hartzen zuen, eta MySQL "ergelkeria" egiten hasi zen kontsulta sinpleetan. Fitxategi-espazioaren arazoa konpontzeko, InnoDB taula-konpresioa behar bezala erabili dugu eta horrek 4 faktore murriztu du. Hala ere, oraindik ez du zentzurik MySQL-n 20-30 milioi mezu elektroniko baino gehiago gordetzeak historia irakurtzeko soilik, arrazoiren bategatik eskaneatu osoa egin behar duen edozein kontsulta soil truke eta asko eragiten baitu. /O karga, horren arabera, aldizka Zabbixen abisuak jasotzen genituen.
Clickhouse-k bi konpresio algoritmo erabiltzen ditu datuen bolumena gutxi gorabehera gutxi gorabehera , baina kasu zehatz honetan datuak bereziki "konprimigarriak" ziren.
ELK Ordezkoa
Nire esperientzian oinarrituta, ELK pilak (ElasticSearch, Logstash eta Kibana, kasu zehatz honetan ElasticSearch) erregistroak gordetzeko behar baino askoz baliabide gehiago behar ditu exekutatzeko. ElasticSearch motor bikaina da testu osoko erregistro bilaketa ona nahi baduzu (eta ez dut uste benetan behar duzunik), baina galdetzen ari naiz zergatik bihurtu den de facto erregistro-motor estandarra. Haren ingesta-errendimenduak, Logstash-ekin konbinatuta, arazoak eman zizkigun nahiko lan-karga arinetan ere eta gero eta RAM eta disko espazio gehiago gehitzea eskatzen zuen. Datu-base gisa, Clickhouse ElasticSearch baino hobea da arrazoi hauengatik:
- SQL dialektoaren euskarria;
- Biltegiratutako datuen konpresio-maila onena;
- Testu osoko bilaketaren ordez Regex bilaketarako laguntza;
- Kontsulten programazio hobetua eta errendimendu orokorra hobea.
Gaur egun, ClickHouse ELKrekin alderatzean sortzen den arazo handiena erregistroak igotzeko irtenbiderik eza da, baita gai honi buruzko dokumentazio eta tutorial falta ere. Aldi berean, erabiltzaile bakoitzak ELK konfigura dezake Digital Ocean eskuliburua erabiliz, eta hori oso garrantzitsua da horrelako teknologiak azkar ezartzeko. Hemen datu-basearen motorra dago, baina ez dago oraindik ClickHouserako Filebeat. Bai hor dago eta erregistroekin lan egiteko sistema , tresna bat dago erregistro-fitxategiaren datuak ClickHouse-n sartzeko, baina honek guztiak denbora gehiago behar du. Hala ere, ClickHouse-k bere sinpletasunagatik jarraitzen du oraindik, beraz, hasiberriek ere erraz instalatu dezakete eta 10 minututan guztiz funtzionala erabiltzen hasteko.
Irtenbide minimalistak nahiago, FluentBit erabiltzen saiatu nintzen, memoria oso baxuko erregistroak kargatzeko tresna, ClickHouse-rekin Kafka erabiltzen saihesten saiatzen nintzen bitartean. Hala ere, bateraezintasun txikiak zuzendu behar dira, esaterako hori egin aurretik FluentBit-etik datuak ClickHouse-ra bihurtzen dituen proxy geruzarik gabe.
Kibanaren alternatiba gisa, ClickHouse backend gisa erabil dezakezu . Ulertzen dudanez, horrek errendimendu-arazoak sor ditzake datu-puntu asko errendatzean, batez ere Grafana-ren bertsio zaharragoekin. Qwintryn, oraindik ez dugu probatu, baina honen inguruko kexak agertzen dira noizean behin Telegrameko ClickHouse laguntza kanalean.
Google Big Query eta Amazon RedShift (enpresa handientzako irtenbidea) ordezkatzea
BigQuery-ren erabilera-kasu ezin hobea da 1 TB JSON datu kargatzea eta bertan kontsulta analitikoak egitea. Big Query produktu bikaina da, eta bere eskalagarritasuna gehiegi esan daiteke. ClickHouse baino askoz software konplexuagoa da hau, barne-kluster batean exekutatzen dena, baina bezeroaren ikuspuntutik ClickHouse-rekin komunean asko ditu. BigQuery-k azkar "prezioak igo" ditzake SELECT bakoitza ordaintzen hasten zarenean, beraz, benetako SaaS irtenbide bat da, bere abantailak eta txarrak dituena.
ClickHouse aukerarik onena da konputazio-kontsulta garesti asko exekutatzen dituzunean. Zenbat eta SELECT kontsulta gehiago exekutatu egunero, orduan eta garrantzi handiagoa izango du Big Query ClickHouse-rekin ordezkatzeak, ordezkapen horrek milaka dolar aurreztuko baititu datu-terabyte asko prozesatzen direnean. Hau ez da gordetako datuei aplikatzen, eta hori nahiko merkea da Big Query-n prozesatzea.
Alexander Zaitsev Altinity-ren sortzailekidearen artikulu batean DBMS migrazio horren onurak deskribatzen ditu.
TimescaleDB ordezkatzea
TimescaleDB PostgreSQL luzapena da, datu-base arrunt batean denbora serieko denbora serieekin lan egitea optimizatzen duena (, ).
ClickHouse denbora serieen nitxoan lehiakide serioa ez den arren, zutabe-egitura eta kontsulta bektorialaren exekuzioa baizik, TimescaleDB baino askoz azkarragoa da kontsulta analitikoen prozesamendu kasu gehienetan. Aldi berean, ClickHouse-tik loteen datuak jasotzearen errendimendua 3 aldiz handiagoa da gutxi gorabehera, eta diskoko 20 aldiz espazio gutxiago erabiltzen du, hori benetan garrantzitsua da datu historikoen bolumen handiak prozesatzeko: .
ClickHouse-n ez bezala, TimescaleDB-n diskoko espazioa aurrezteko modu bakarra ZFS edo antzeko fitxategi-sistemak erabiltzea da.
ClickHouse-ren datozen eguneratzeek delta konpresioa sartuko dute, eta horrek are egokiagoa izango du denbora serieko datuak prozesatzeko eta gordetzeko. TimescaleDB ClickHouse hutsa baino aukera hobea izan daiteke kasu hauetan:
- RAM oso gutxi duten instalazio txikiak (<3 GB);
- zati handitan gorde nahi ez dituzun txertatze txiki kopuru handi bat;
- koherentzia, uniformetasun eta ACID eskakizun hobeak;
- PostGIS laguntza;
- batu lehendik dauden PostgreSQL taulekin, Timescale DB funtsean PostgreSQL delako.
Hadoop eta MapReduce sistemekin lehia
Hadoop-ek eta MapReduce-ko beste produktu batzuek kalkulu konplexu asko egin ditzakete, baina latentzia handian exekutatu ohi dira. ClickHouse-k arazo hau konpontzen du terabyte datuak prozesatu eta emaitzak ia berehala emanez. Horrela, ClickHouse askoz eraginkorragoa da ikerketa analitiko azkarra eta interaktiboa egiteko, datu-zientzialarientzat interesgarria izan beharko lukeena.
Pinot eta Druid-ekin lehiaketa
ClickHouseren lehiakide hurbilenak Pinot eta Druid kode irekiko produktu zutabeak eta linealki eskalagarriak dira. Sistema hauek alderatuz lan bikaina argitaratu da artikuluan 1ko otsailaren 2018a
Artikulu honek eguneratu behar du - ClickHouse-k ez duela EGUNERATZEA eta EZABATZEA eragiketak onartzen dio, eta hori ez da guztiz egia azken bertsioetarako.
Ez dugu esperientzia handirik datu-base hauekin, baina ez zait asko gustatzen Druid eta Pinot exekutatzeko beharrezkoa den azpiegituraren konplexutasuna - alde guztietatik Javaz inguratutako pieza mugikor mordoa da.
Druid eta Pinot Apache inkubagailu proiektuak dira, eta Apache-k zehatz-mehatz azaltzen ditu GitHub proiektuaren orrietan. Pinot 2018ko urrian agertu zen inkubagailuan, eta Druid 8 hilabete lehenago jaio zen - otsailean.
AFSren funtzionamenduari buruzko informazio faltak galdera batzuk, eta agian ergelak, sortzen dizkit. Galdetzen diot Pinot-en egileek ohartu ote diren Apache Fundazioa Druidekiko jarrera gehiago dagoela, eta lehiakideekiko jarrera horrek inbidia sentimendurik eragin ote zuen? Druid-en garapena moteldu eta Pinot-en garapena bizkortuko al da lehenengoa babesten duten babesleak bat-batean bigarrenean interesatzen badira?
ClickHouseren desabantailak
Heldutasunik gabea: jakina, hau oraindik ez da teknologia aspergarria, baina, nolanahi ere, ez da horrelakorik ikusten beste zutabe-DBMSetan.
Txertaketa txikiek ez dute ondo funtzionatzen abiadura handian: txertaketak zati handitan banatu behar dira, txertaketa txikien errendimendua hondatzen baita ilara bakoitzeko zutabe kopuruaren proportzioan. Hau da ClickHouse-k datuak diskoan gordetzen ditu - zutabe bakoitzak fitxategi bat edo gehiago esan nahi du, beraz, 1 zutabe dituen errenkada 1 txertatzeko, gutxienez 100 fitxategi ireki eta idatzi behar dituzu. Horregatik txertatzeko buffering-ak bitartekari bat behar du (bezeroak berak buffering-a ematen ez badu behintzat), normalean Kafka edo ilara-sistemaren bat. Buffer taula-motorra ere erabil dezakezu gero datu zati handiak MergeTree tauletan kopiatzeko.
Taulen batuketak zerbitzariaren RAMak mugatuta daude, baina behintzat hor daude! Esaterako, Druid eta Pinotek ez dute halako konexiorik batere, zaila baita zuzenean ezartzea nodoen artean datu-puska handiak mugitzea onartzen ez duten sistema banatuetan.
Findings
Datozen urteetan, Qwintry-n ClickHouse asko erabiltzeko asmoa dugu, DBMS honek errendimenduaren, gainkostu txikiaren, eskalagarritasunaren eta sinpletasunaren oreka bikaina eskaintzen baitu. Ziur nago azkar zabalduko dela ClickHouse komunitateak instalazio txiki eta ertainetan erabiltzeko modu gehiago aurkezten dituenean.
Iragarki batzuk 🙂
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com