yra atvirojo kodo stulpelių duomenų bazių valdymo sistema, skirta internetiniam analitiniam užklausų apdorojimui (OLAP), sukurta Yandex. Jį naudoja Yandex, CloudFlare, VK.com, Badoo ir kitos paslaugos visame pasaulyje, kad saugotų tikrai didelius duomenų kiekius (įterpdami tūkstančius eilučių per sekundę arba diske saugomų petabaitų duomenų).
Įprastoje „eilutės“ DBVS, kurios pavyzdžiai yra MySQL, Postgres, MS SQL Server, duomenys saugomi tokia tvarka:
Tokiu atveju su viena eilute susijusios reikšmės fiziškai saugomos netoliese. Stulpelinėse DBVS vertės iš skirtingų stulpelių saugomos atskirai, o duomenys iš vieno stulpelio saugomi kartu:
Stulpelių DBVS pavyzdžiai yra Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Pašto ekspeditorių įmonė pradėjo naudoti Clickhouse 2018 m. ataskaitoms rengti ir buvo labai sužavėtas jos paprastumu, masteliu, SQL palaikymu ir greičiu. Šios DBVS greitis ribojosi su magija.
palengvinti
„Clickhouse“ yra įdiegtas „Ubuntu“ su viena komanda. Jei žinote SQL, galite iš karto pradėti naudoti Clickhouse savo poreikiams. Tačiau tai nereiškia, kad galite „rodyti sukurti lentelę“ MySQL ir nukopijuoti ir įklijuoti SQL „Clickhouse“.
Palyginti su MySQL, lentelių schemų apibrėžimuose yra svarbių duomenų tipų skirtumų, todėl jums vis tiek reikės šiek tiek laiko pakeisti lentelės schemos apibrėžimus ir išmokti lentelių variklius, kad jaustumėtės patogiai.
„Clickhouse“ puikiai veikia be jokios papildomos programinės įrangos, tačiau jei norite naudoti replikaciją, turėsite įdiegti „ZooKeeper“. Užklausos našumo analizė rodo puikius rezultatus – sistemos lentelėse yra visa informacija, o visus duomenis galima gauti naudojant seną ir nuobodų SQL.
Našumas
- Clickhouse palyginimai su Vertica ir MySQL serverio konfigūracijoje: du lizdai Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD, ext4.
- „Clickhouse“ palyginimas su „Amazon RedShift“ debesies saugykla.
- Tinklaraščio ištraukos :
„ClickHouse“ duomenų bazė yra labai paprasto dizaino – visi klasterio mazgai turi vienodas funkcijas ir koordinavimui naudoja tik „ZooKeeper“. Sukūrėme nedidelį kelių mazgų klasterį ir atlikome testavimą, kurio metu nustatėme, kad sistemos našumas yra gana įspūdingas, o tai atitinka analitiniuose DBVS etalonuose nurodytus pranašumus. Nusprendėme atidžiau pažvelgti į ClickHouse koncepciją. Pirmoji kliūtis tyrimams buvo įrankių trūkumas ir nedidelė ClickHouse bendruomenė, todėl gilinomės į šios DBVS dizainą, kad suprastume, kaip ji veikia.
„ClickHouse“ nepalaiko duomenų gavimo tiesiogiai iš „Kafka“, nes tai tik duomenų bazė, todėl „Go“ sukūrėme savo adapterio paslaugą. Jis perskaitė Cap'n Proto koduotus Kafkos pranešimus, konvertavo juos į TSV ir įterpė juos į ClickHouse paketais per HTTP sąsają. Vėliau šią paslaugą perrašėme, kad naudotume Go biblioteką kartu su ClickHouse sąsaja, kad pagerintume našumą. Vertindami paketų priėmimo efektyvumą, atradome svarbų dalyką – paaiškėjo, kad ClickHouse šis našumas stipriai priklauso nuo paketo dydžio, tai yra vienu metu įterptų eilučių skaičiaus. Norėdami suprasti, kodėl taip nutinka, pažvelgėme į tai, kaip ClickHouse saugo duomenis.
Pagrindinis variklis arba, tiksliau, lentelės variklių šeima, kurią ClickHouse naudoja duomenims saugoti, yra MergeTree. Šis variklis iš esmės panašus į LSM algoritmą, naudojamą „Google BigTable“ arba „Apache Cassandra“, tačiau išvengia tarpinės atminties lentelės kūrimo ir įrašo duomenis tiesiai į diską. Tai užtikrina puikų rašymo pralaidumą, nes kiekvienas įterptas paketas rūšiuojamas tik pagal pirminį raktą, suglaudinamas ir įrašomas į diską, kad būtų sudarytas segmentas.
Atminties lentelės ar bet kokios duomenų „šviežumo“ sąvokos nebuvimas taip pat reiškia, kad juos galima tik pridėti; sistema nepalaiko keitimo ar trynimo. Šiuo metu vienintelis būdas ištrinti duomenis yra ištrinti juos pagal kalendorinį mėnesį, nes segmentai niekada neperžengia mėnesio ribos. „ClickHouse“ komanda aktyviai dirba, kad šią funkciją būtų galima pritaikyti. Kita vertus, dėl to segmentų rašymas ir sujungimas be ginčų, todėl pralaidumo skalės gaunamos tiesiškai atsižvelgiant į lygiagrečių įterpimų skaičių, kol įvyks įvesties / išvesties arba branduolio prisotinimas.
Tačiau tai taip pat reiškia, kad sistema netinka mažiems paketams, todėl buferiui naudojamos Kafka paslaugos ir intarpai. Toliau „ClickHouse“ fone ir toliau nuolat atlieka segmentų sujungimą, todėl daug smulkių informacijos dalių bus sujungta ir įrašoma daugiau kartų, taip padidinant įrašymo intensyvumą. Tačiau per daug nesusijusių dalių sukels agresyvų įdėklų droselį, kol sujungimas tęsis. Mes nustatėme, kad geriausias kompromisas tarp realiojo laiko ir perdavimo našumo yra į lentelę įtraukti ribotą įterpimų skaičių per sekundę.
Lentelės skaitymo našumo raktas yra indeksavimas ir duomenų vieta diske. Kad ir koks greitas būtų apdorojimas, kai varikliui reikia nuskaityti terabaitus duomenų iš disko ir naudoti tik dalį jų, tai užtruks. ClickHouse yra stulpelių parduotuvė, todėl kiekviename segmente yra kiekvieno stulpelio (stulpelio) failas su surūšiuotomis kiekvienos eilutės reikšmėmis. Tokiu būdu pirmiausia galima praleisti ištisus užklausoje trūkstamus stulpelius, o tada kelis langelius galima apdoroti lygiagrečiai su vektoriniu vykdymu. Kad būtų išvengta viso nuskaitymo, kiekviename segmente yra mažas indekso failas.
Atsižvelgiant į tai, kad visi stulpeliai yra surūšiuoti pagal „pirminį raktą“, indekso faile yra tik kiekvienos N-osios eilutės etiketės (užfiksuotos eilutės), kad būtų galima jas išsaugoti atmintyje net ir labai didelėse lentelėse. Pavyzdžiui, galite nustatyti numatytuosius nustatymus į „žymėti kas 8192 eilutę“, tada „menką“ lentelės indeksavimą su 1 trilijonu. eilutės, kurios lengvai telpa į atmintį, užtruks tik 122 070 simbolių.
Sistemos kūrimas
„Clickhouse“ plėtrą ir tobulinimą galima atsekti adresu ir įsitikinkite, kad „augimo“ procesas vyksta įspūdingu tempu.
Populiarumas
Panašu, kad „Clickhouse“ populiarumas auga eksponentiškai, ypač rusakalbių bendruomenėje. Praėjusių metų „High load 2018“ konferencija (Maskva, 8 m. lapkričio 9–2018 d.) parodė, kad tokie monstrai kaip vk.com ir Badoo naudoja Clickhouse, su kuriuo vienu metu įterpia duomenis (pavyzdžiui, žurnalus) iš dešimčių tūkstančių serverių. 40 minučių vaizdo įraše . Netrukus stenogramą paskelbsime Habr svetainėje, kad būtų lengviau dirbti su medžiaga.
Programos
Praleidęs šiek tiek laiko tyrinėdamas, manau, kad yra sričių, kuriose ClickHouse galėtų būti naudingas arba galėtų visiškai pakeisti kitus, labiau tradicinius ir populiarius sprendimus, tokius kaip MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ir Druidas. Toliau aprašoma „ClickHouse“ naudojimo informacija, siekiant modernizuoti arba visiškai pakeisti aukščiau nurodytą DBVS.
MySQL ir PostgreSQL galimybių išplėtimas
Visai neseniai savo naujienlaiškių platformoje iš dalies pakeitėme MySQL į ClickHouse . Problema buvo ta, kad MySQL dėl prasto dizaino registravo kiekvieną išsiųstą laišką ir kiekvieną tame laiške esančią nuorodą su base64 maiša, sukurdamas didžiulę MySQL lentelę (email_stats). Išsiuntus tik 10 milijonų laiškų paslaugos prenumeratoriams, ši lentelė užėmė 150 GB failo vietos, o MySQL pradėjo „kvailas“ pagal paprastas užklausas. Norėdami išspręsti failo vietos problemą, sėkmingai panaudojome InnoDB lentelės glaudinimą, kuris sumažino jį 4 kartus. Tačiau vis tiek nėra prasmės MySQL saugoti daugiau nei 20–30 milijonų el. laiškų vien dėl skaitymo istorijos, nes bet kokia paprasta užklausa, kurią dėl kokių nors priežasčių reikia atlikti pilną nuskaitymą, atsiranda apsikeitimas ir daug /O apkrova, pagal kurią reguliariai gaudavome įspėjimus iš Zabbix.
„Clickhouse“ naudoja du glaudinimo algoritmus, kurie maždaug sumažina duomenų kiekį , tačiau šiuo konkrečiu atveju duomenys buvo ypač „suglaudinami“.
Keičiamas ELK
Remdamasis savo patirtimi, ELK kamino (ElasticSearch, Logstash ir Kibana, šiuo konkrečiu atveju ElasticSearch) paleisti reikia daug daugiau išteklių, nei reikia žurnalams saugoti. „ElasticSearch“ yra puikus variklis, jei jums reikia geros viso teksto žurnalų paieškos (kurios, manau, jums tikrai nereikia), bet man įdomu, kodėl jis tapo de facto standartiniu registravimo varikliu. Jo įsisavinimo našumas kartu su „Logstash“ sukėlė problemų net esant gana mažoms apkrovoms, todėl reikėjo pridėti vis daugiau RAM ir vietos diske. Kaip duomenų bazė „Clickhouse“ yra geresnė nei „ElasticSearch“ dėl šių priežasčių:
- SQL dialekto palaikymas;
- Geriausias saugomų duomenų suspaudimo laipsnis;
- Regex reguliariųjų reiškinių paieškų, o ne viso teksto paieškų, palaikymas;
- Patobulintas užklausų planavimas ir didesnis bendras našumas.
Šiuo metu didžiausia problema, kuri iškyla lyginant ClickHouse su ELK – žurnalų įkėlimo sprendimų trūkumas, taip pat dokumentacijos ir pamokų šia tema trūkumas. Be to, kiekvienas vartotojas gali konfigūruoti ELK naudodamasis Digital Ocean vadovu, kuris yra labai svarbus greitam tokių technologijų diegimui. Yra duomenų bazės variklis, bet dar nėra „Filebeat“, skirto ClickHouse. Taip, ten yra ir darbo su rąstais sistema , yra įrankis įvesti žurnalo failo duomenis į ClickHouse, tačiau visa tai užima daugiau laiko. Tačiau „ClickHouse“ vis dar yra lyderis dėl savo paprastumo, todėl net pradedantieji gali lengvai jį įdiegti ir visiškai funkcionaliai naudoti vos per 10 minučių.
Pirmenybę teikdamas minimalistiniams sprendimams, bandžiau naudoti „FluentBit“ – įrankį, skirtą labai mažai atminties turintiems žurnalams siųsti, kartu su „ClickHouse“, bandydamas vengti „Kafka“. Tačiau reikia pašalinti nedidelius nesuderinamumus, pvz prieš tai galima padaryti be tarpinio serverio sluoksnio, kuris konvertuoja duomenis iš FluentBit į ClickHouse.
Kaip alternatyva, Kibana gali būti naudojama kaip ClickHouse backend . Kiek suprantu, tai gali sukelti našumo problemų, kai pateikiamas didžiulis duomenų taškų skaičius, ypač naudojant senesnes Grafana versijas. Mes dar neišbandėme to Qwintry, tačiau skundai dėl to retkarčiais pasirodo „Telegram“ „ClickHouse“ palaikymo kanale.
„Google Big Query“ ir „Amazon RedShift“ (sprendimas didelėms įmonėms) pakeitimas
Idealus „BigQuery“ naudojimo atvejis – įkelti 1 TB JSON duomenų ir vykdyti juose analitines užklausas. Big Query yra puikus produktas, kurio mastelio negalima pervertinti. Tai daug sudėtingesnė programinė įranga nei ClickHouse, kuri veikia vidiniame klasteryje, tačiau kliento požiūriu ji turi daug bendro su ClickHouse. Pradėjus mokėti už SELECT, „BigQuery“ gali greitai pabrangti, todėl tai tikras SaaS sprendimas su visais privalumais ir trūkumais.
ClickHouse yra geriausias pasirinkimas, kai vykdote daug brangių užklausų. Kuo daugiau SELECT užklausų vykdote kiekvieną dieną, tuo prasmingiau Big Query pakeisti ClickHouse, nes toks pakeitimas gali sutaupyti tūkstančius dolerių, kai reikia apdoroti daug terabaitų duomenų. Tai netaikoma saugomiems duomenims, kuriuos gana pigu apdoroti naudojant „Big Query“.
Altinity įkūrėjo Aleksandro Zaicevo straipsnyje kalba apie tokio DBVS perkėlimo naudą.
TimescaleDB pakeitimas
TimescaleDB yra PostgreSQL plėtinys, optimizuojantis darbą su laiko eilėmis įprastoje duomenų bazėje (, ).
Nors „ClickHouse“ nėra rimtas konkurentas laiko eilučių nišoje, tačiau stulpelinės struktūros ir vektorinės užklausos vykdymo srityje jis yra daug greitesnis už TimescaleDB daugeliu atvejų analitinio užklausų apdorojimo atveju. Tuo pačiu metu paketinių duomenų gavimo iš ClickHouse našumas yra maždaug 3 kartus didesnis, be to, jis naudoja 20 kartų mažiau vietos diske, o tai tikrai svarbu apdorojant didelius istorinių duomenų kiekius: .
Skirtingai nuo ClickHouse, vienintelis būdas sutaupyti vietos diske TimescaleDB yra naudoti ZFS ar panašias failų sistemas.
Būsimuose ClickHouse atnaujinimuose greičiausiai bus įdiegtas delta glaudinimas, todėl jis bus dar tinkamesnis laiko eilučių duomenims apdoroti ir saugoti. „TimescaleDB“ gali būti geresnis pasirinkimas nei „ClickHouse“ šiais atvejais:
- maži įrenginiai su labai mažai RAM (<3 GB);
- daug mažų INSERT, kurių nenorite buferizuoti į didelius fragmentus;
- geresnis nuoseklumas, vienodumas ir RŪGŠTIES reikalavimai;
- PostGIS palaikymas;
- prisijungimas prie esamų PostgreSQL lentelių, nes Timescale DB iš esmės yra PostgreSQL.
Konkurencija su Hadoop ir MapReduce sistemomis
„Hadoop“ ir kiti „MapReduce“ produktai gali atlikti daug sudėtingų skaičiavimų, tačiau jie paprastai veikia su didžiuliu delsimu. „ClickHouse“ išsprendžia šią problemą apdorodama terabaitus duomenų ir beveik akimirksniu pateikdama rezultatus. Taigi „ClickHouse“ daug efektyviau atlieka greitus, interaktyvius analitinius tyrimus, kurie turėtų sudominti duomenų mokslininkus.
Konkurencija su Pinot ir Druid
„ClickHouse“ artimiausi konkurentai yra stulpeliai, tiesiškai keičiami atvirojo kodo produktai „Pinot“ ir „Druid“. Puikus darbas, lyginant šias sistemas, paskelbtas straipsnyje 1 m. vasario 2018 d
Šį straipsnį reikia atnaujinti – jame rašoma, kad ClickHouse nepalaiko UPDATE ir DELETE operacijų, o tai ne visai tiesa naujausioms versijoms.
Neturime daug patirties dirbant su šiomis duomenų bazėmis, bet man nelabai patinka infrastruktūros sudėtingumas, reikalingas Druid ir Pinot paleidimui – tai visa krūva judančių dalių, iš visų pusių apsupta Java.
„Druid“ ir „Pinot“ yra „Apache“ inkubatoriaus projektai, kurių eigą „Apache“ išsamiai aprašo savo „GitHub“ projektų puslapiuose. Pinotas inkubatoriuje pasirodė 2018 metų spalį, o Druidas gimė 8 mėnesiais anksčiau – vasarį.
Informacijos apie tai, kaip veikia AFS, trūkumas man kelia tam tikrų ir galbūt kvailų klausimų. Įdomu, ar Pinot autoriai pastebėjo, kad Apache fondas yra palankesnis Druidui, ir ar toks požiūris į konkurentą sukėlė pavydo jausmą? Ar Druido vystymasis sulėtės, o Pinot – paspartės, jei pirmosios rėmėjai staiga susidomės antruoju?
ClickHouse trūkumai
Nesubrendimas: Akivaizdu, kad tai vis dar nėra nuobodi technologija, tačiau bet kuriuo atveju nieko panašaus nepastebėta kitose stulpelinėse DBVS.
Maži įdėklai netinkamai veikia dideliu greičiu: įdėklus reikia padalyti į didesnius gabalus, nes mažų įdėklų našumas blogėja proporcingai stulpelių skaičiui kiekvienoje eilutėje. Taip ClickHouse saugo duomenis diske – kiekvienas stulpelis reiškia 1 failą ar daugiau, todėl norint įterpti 1 eilutę, kurioje yra 100 stulpelių, reikia atidaryti ir įrašyti mažiausiai 100 failų. Štai kodėl buferio įterpimui reikalingas tarpininkas (nebent pats klientas užtikrina buferį) – dažniausiai Kafka arba kokia nors eilių valdymo sistema. Taip pat galite naudoti buferio lentelės variklį, norėdami vėliau nukopijuoti didelius duomenų gabalus į MergeTree lenteles.
Lentelių prisijungimus riboja serverio RAM, bet bent jau jie yra! Pavyzdžiui, „Druid“ ir „Pinot“ tokių jungčių apskritai neturi, nes juos sunku tiesiogiai įdiegti paskirstytose sistemose, kurios nepalaiko didelių duomenų dalių perkėlimo tarp mazgų.
išvados
Ateinančiais metais planuojame plačiai naudoti „ClickHouse“ programoje „Qwintry“, nes ši DBVS užtikrina puikų našumo, mažų išlaidų, mastelio keitimo ir paprastumo balansą. Esu tikras, kad jis pradės greitai plisti, kai „ClickHouse“ bendruomenė sugalvos daugiau būdų, kaip jį naudoti mažose ir vidutinio dydžio įrenginiuose.
Kai kurie skelbimai 🙂
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com