on avoimen lähdekoodin saraketietokannan hallintajärjestelmä online-analyyttiseen kyselynkäsittelyyn (OLAP), jonka on luonut Yandex. Yandex, CloudFlare, VK.com, Badoo ja muut palvelut ympäri maailmaa käyttävät sitä todella suurten tietomäärien tallentamiseen (tuhansien rivien lisääminen sekunnissa tai petabyyttiä levylle tallennettua dataa).
Normaalissa "merkkijono" DBMS:ssä, joista esimerkkejä ovat MySQL, Postgres, MS SQL Server, tiedot tallennetaan tässä järjestyksessä:
Tässä tapauksessa yhteen riviin liittyvät arvot tallennetaan fyysisesti vierekkäin. Sarakepohjaisessa DBMS:ssä arvot eri sarakkeista tallennetaan erikseen ja yhden sarakkeen tiedot tallennetaan yhdessä:
Esimerkkejä sarakepohjaisista tietokantajärjestelmistä ovat Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Yritys toimii postin välittäjänä Aloitin Clickhousen käytön raportointiin vuonna 2018, ja olin erittäin vaikuttunut sen yksinkertaisuudesta, skaalautumisesta, SQL-tuesta ja nopeudesta. Tämän DBMS:n nopeus rajoitti taikuutta.
helppous
Clickhouse asennetaan Ubuntuun yhdellä komennolla. Jos osaat SQL:n, voit heti alkaa käyttää Clickhousea tarpeisiisi. Tämä ei kuitenkaan tarkoita, että voit "näyttää luontitaulukon" MySQL:ssä ja kopioida ja liittää SQL:n Clickhousessa.
Verrattuna MySQL:ään tämän DBMS:n taulukkoskeeman määritelmissä on merkittäviä tietotyyppieroja, joten tarvitset vielä jonkin aikaa muuttaaksesi taulukkoskeeman määritelmiä ja oppiaksesi taulukkomoottorit tuntemaan olosi mukavaksi.
Clickhouse toimii hyvin ilman lisäohjelmistoja, mutta jos haluat käyttää replikointia, sinun on asennettava ZooKeeper. Kyselyn suorituskyvyn analyysi osoittaa erinomaisia tuloksia - järjestelmätaulukot sisältävät kaiken tiedon ja kaikki tiedot voidaan saada vanhalla ja tylsällä SQL:llä.
Suorituskyky
- Clickhouse versus Vertica ja MySQL vertailu konfigurointipalvelimella: kaksi liitäntää Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 8 6 Tt:n SATA HDD:llä, ext4.
- Clickhousen vertailu Amazon RedShift -pilvitallennustilaan.
- Blogin otteita :
ClickHouse-tietokanta on rakenteeltaan hyvin yksinkertainen - klusterin kaikissa solmuissa on samat toiminnot ja ne käyttävät vain ZooKeeperiä koordinointiin. Rakensimme pienen useista solmuista koostuvan klusterin ja suoritimme testauksen, jonka aikana havaitsimme, että järjestelmän suorituskyky on varsin vaikuttava, mikä vastaa väitettyjä etuja analyyttisissä DBMS-benchmarkissa. Päätimme tarkastella tarkemmin ClickHousen taustalla olevaa konseptia. Ensimmäinen este tutkimukselle oli työkalujen puute ja ClickHousen pieni yhteisö, joten syvennyimme tämän DBMS:n suunnitteluun ymmärtääksemme, miten se toimii.
ClickHouse ei tue tiedon vastaanottamista suoraan Kafkasta, koska se on vain tietokanta, joten kirjoitimme oman sovitinpalvelumme Go-sovellukseen. Se luki Cap'n Proto -koodatut Kafkan viestit, muunsi ne TSV:ksi ja lisäsi ne ClickHouseen erissä HTTP-rajapinnan kautta. Myöhemmin kirjoitimme tämän palvelun käyttämään Go-kirjastoa yhdessä oman ClickHouse-käyttöliittymämme kanssa suorituskyvyn parantamiseksi. Arvioidessamme pakettien vastaanottamisen suorituskykyä havaitsimme tärkeän asian - kävi ilmi, että ClickHouselle tämä suorituskyky riippuu voimakkaasti paketin koosta, eli samanaikaisesti lisättyjen rivien määrästä. Ymmärtääksemme miksi näin tapahtuu, tutkimme, kuinka ClickHouse tallentaa tietoja.
Pääkone, tai pikemminkin ClickHousen tietojen tallentamiseen käyttämä taulukkomoottoriperhe, on MergeTree. Tämä moottori on käsitteellisesti samanlainen kuin Google BigTablessa tai Apache Cassandrassa käytetty LSM-algoritmi, mutta välttää välimuistitaulukon rakentamisen ja kirjoittaa tiedot suoraan levylle. Tämä antaa sille erinomaisen kirjoitusnopeuden, koska jokainen lisätty paketti lajitellaan vain "ensisijaisen avaimen" perusavaimen mukaan, pakataan ja kirjoitetaan levylle segmentin muodostamiseksi.
Muistitaulukon tai tietojen "tuoreuden" puuttuminen tarkoittaa myös sitä, että niitä voidaan vain lisätä, järjestelmä ei tue muuttamista tai poistamista. Nykyään ainoa tapa poistaa tiedot on poistaa ne kalenterikuukausittain, koska segmentit eivät koskaan ylitä kuukauden rajaa. ClickHouse-tiimi työskentelee aktiivisesti tehdäkseen tästä ominaisuudesta mukautettavan. Toisaalta se tekee kirjoittamisesta ja segmenttien yhdistämisestä kilpailuvapaata, joten vastaanota läpimenoasteikkoja lineaarisesti rinnakkaisten lisäysten lukumäärän mukaan, kunnes I/O tai ytimet kyllästyvät.
Tämä seikka tarkoittaa kuitenkin myös sitä, että järjestelmä ei sovellu pienille paketeille, joten puskurointiin käytetään Kafka-palveluita ja inserteriä. Lisäksi taustalla oleva ClickHouse jatkaa jatkuvasti segmenttien yhdistämistä, jotta monet pienet tiedot yhdistetään ja tallennetaan useammin, mikä lisää tallennuksen intensiteettiä. Liian monet toisiinsa liittymättömät osat aiheuttavat kuitenkin lisäosien aggressiivista kuristusta niin kauan kuin yhdistäminen jatkuu. Olemme havainneet, että paras kompromissi reaaliaikaisen tiedonkeruun ja tiedonkeruun suorituskyvyn välillä on hyväksyä rajoitettu määrä lisäyksiä sekunnissa taulukkoon.
Taulukon lukusuorituskyvyn avain on levyllä olevien tietojen indeksointi ja sijainti. Ei ole väliä kuinka nopea käsittely on, kun moottorin on skannata teratavuja tietoa levyltä ja käyttää vain murto-osaa siitä, se vie aikaa. ClickHouse on sarakevarasto, joten jokainen segmentti sisältää tiedoston jokaiselle sarakkeelle (sarakkeelle), jossa on lajitellut arvot kullekin riville. Siten kokonaiset sarakkeet, joita ei ole kyselyssä, voidaan ensin ohittaa ja sitten voidaan käsitellä useita soluja rinnakkain vektorisoidun suorituksen kanssa. Täyden tarkistuksen välttämiseksi jokaisessa segmentissä on pieni hakemistotiedosto.
Koska kaikki sarakkeet lajitellaan "ensisijaisen avaimen" mukaan, hakemistotiedosto sisältää vain jokaisen N:nnen rivin otsikot (siepatut rivit), jotta ne voidaan säilyttää muistissa jopa erittäin suuria taulukoita varten. Voit esimerkiksi asettaa oletusasetuksiksi "merkitse joka 8192. rivi" ja sitten "niukka" taulukon indeksointi 1 biljoonalla. helposti muistiin mahtuvat rivit vaativat vain 122 070 merkkiä.
Järjestelmän kehittäminen
Clickhousen kehitystä ja parantamista voidaan seurata ja varmista, että ”kasvamisprosessi” tapahtuu vaikuttavalla tahdilla.
Suosio
Näyttää siltä, että Clickhousen suosio kasvaa eksponentiaalisesti, etenkin venäjänkielisessä yhteisössä. Viime vuoden High load 2018 -konferenssi (Moskova, 8.-9) osoitti, että hirviöt, kuten vk.com ja Badoo, käyttävät Clickhousea, joka lisää tietoja (esimerkiksi lokeja) kymmeniltä tuhansilta palvelimilta samanaikaisesti. 2018 minuutin videossa . Pian julkaisemme tekstin Habrissa materiaalin käsittelyn helpottamiseksi.
sovellukset
Kun olen viettänyt aikaa tutkimiseen, uskon, että on alueita, joilla ClickHouse voi olla hyödyllinen tai voi täysin korvata muita perinteisempiä ja suosittuja ratkaisuja, kuten MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ja Druidi. Seuraavassa on tietoja ClickHousen käytöstä yllä olevan DBMS:n päivittämiseen tai korvaamiseen kokonaan.
MySQL:n ja PostgreSQL:n laajentaminen
Viimeksi korvasimme MySQL:n osittain ClickHousella uutiskirjealustalla . Ongelmana oli, että MySQL huonosti suunnitellun suunnittelun vuoksi kirjasi jokaisen lähetetyn sähköpostin ja jokaisen sähköpostin linkin base64-tiivisteellä, mikä loi valtavan MySQL-taulukon (email_stats). Lähetettyään vain 10 miljoonaa sähköpostiviestiä palvelun tilaajille, tämä taulukko vei 150 Gt tiedostotilaa, ja MySQL alkoi olla "tyhmä" yksinkertaisissa kyselyissä. Tiedostotilaongelman korjaamiseksi käytimme onnistuneesti InnoDB-taulukon pakkausta, mikä pienensi sen kertoimella 4. Siltikään ei ole järkevää tallentaa yli 20-30 miljoonaa sähköpostia MySQL:ään vain lukuhistorian vuoksi, koska mikä tahansa yksinkertainen kysely, joka jostain syystä joutuu suorittamaan täyden tarkistuksen, johtaa swapiin ja raskaaseen I/O:hen. yleiskustannukset, josta saimme säännöllisesti Zabbix-varoituksia.
Clickhouse käyttää kahta pakkausalgoritmia, jotka vähentävät tiedon määrää noin , mutta tässä nimenomaisessa tapauksessa tiedot olivat erityisen "pakkattavissa".
ELK:n vaihto
Oman kokemukseni perusteella ELK-pino (ElasticSearch, Logstash ja Kibana, tässä tapauksessa ElasticSearch) vaatii paljon enemmän resursseja toimiakseen kuin lokien tallentamiseen. ElasticSearch on loistava moottori, jos haluat hyvän täystekstin lokihaun (jota en usko sinun tarvitsevan), mutta ihmettelen, miksi siitä on tullut de facto standardi lokihakukone. Sen vastaanottokyky yhdistettynä Logstashiin aiheutti meille ongelmia jopa melko kevyillä työkuormilla ja vaati yhä enemmän RAM-muistin ja levytilan lisäämistä. Tietokantana Clickhouse on parempi kuin ElasticSearch seuraavista syistä:
- SQL-murteen tuki;
- Tallennettujen tietojen paras pakkausaste;
- Tuki Regex-haulle koko tekstihaun sijaan;
- Parannettu kyselyn ajoitus ja parempi yleinen suorituskyky.
Tällä hetkellä suurin ongelma, joka syntyy verrattaessa ClickHousea ELK:hen, on ratkaisujen puute lokien lataamiseen sekä dokumentaation ja opetusohjelmien puute tästä aiheesta. Samanaikaisesti jokainen käyttäjä voi määrittää ELK:n Digital Ocean -oppaan avulla, mikä on erittäin tärkeää tällaisten teknologioiden nopean käyttöönoton kannalta. Täällä on tietokantamoottori, mutta Filebeat for ClickHouse -sovellusta ei vielä ole. Kyllä on ja järjestelmä tukkien kanssa työskentelemiseen , on työkalu syöttääksesi lokitiedoston tiedot ClickHouseen, mutta kaikki tämä vie enemmän aikaa. ClickHouse on kuitenkin edelleen edelläkävijä yksinkertaisuutensa ansiosta, joten aloittelijatkin voivat helposti asentaa sen ja aloittaa täysin toimivan käytön vain 10 minuutissa.
Minimalistisia ratkaisuja suosiessani yritin käyttää ClickHousen kanssa FluentBitiä, erittäin vähän muistia sisältävää lokin lataustyökalua, samalla kun yritin välttää Kafkan käyttöä. Pienet yhteensopimattomuudet on kuitenkin korjattava, kuten ennen kuin se voidaan tehdä ilman välityspalvelintasoa, joka muuntaa tiedot FluentBitistä ClickHouse-muotoon.
Vaihtoehtona Kibanalle voit käyttää ClickHousea taustaohjelmana . Ymmärtääkseni tämä voi aiheuttaa suorituskykyongelmia, kun renderöidään valtava määrä datapisteitä, etenkin Grafanan vanhemmissa versioissa. Qwintryssä emme ole vielä kokeilleet tätä, mutta tästä tulee valituksia Telegramin ClickHouse-tukikanavalla aika ajoin.
Google Big Queryn ja Amazon RedShiftin korvaaminen (ratkaisu suurille yrityksille)
BigQueryn ihanteellinen käyttötapa on ladata 1 Tt JSON-dataa ja suorittaa analyyttisiä kyselyjä. Big Query on loistava tuote, jonka skaalautuvuutta on vaikea yliarvioida. Tämä on paljon monimutkaisempi ohjelmisto kuin sisäisessä klusterissa toimiva ClickHouse, mutta asiakkaan näkökulmasta sillä on paljon yhteistä ClickHousen kanssa. BigQuery voi nopeasti "hinnoitella", kun alat maksaa jokaisesta SELECT:stä, joten se on todellinen SaaS-ratkaisu kaikkine etuineen ja haittoineen.
ClickHouse on paras valinta, kun suoritat paljon laskennallisesti kalliita kyselyjä. Mitä enemmän SELECT-kyselyitä suoritat joka päivä, sitä tärkeämpää on korvata Big Query ClickHousella, koska tällainen korvaaminen säästää tuhansia dollareita, kun käsitellään useita teratavuja dataa. Tämä ei koske tallennettuja tietoja, jotka ovat melko halpoja käsitellä Big Queryssä.
Altinityn perustajan Alexander Zaitsevin artikkelissa kuvailee tällaisen DBMS-siirtämisen edut.
TimescaleDB vaihto
TimescaleDB on PostgreSQL-laajennus, joka optimoi työskentelyn aikasarjojen kanssa tavallisessa tietokannassa (, ).
Vaikka ClickHouse ei ole vakava kilpailija aikasarjan kapealla, mutta sarakerakenteen ja vektorikyselyn suorittamisen suhteen se on paljon nopeampi kuin TimescaleDB useimmissa tapauksissa analyyttisten kyselyjen käsittelyssä. Samaan aikaan ClickHouse-pakettitietojen vastaanottamisen suorituskyky on noin 3 kertaa suurempi, lisäksi se käyttää 20 kertaa vähemmän levytilaa, mikä on todella tärkeää suurten historiatietomäärien käsittelyssä: .
Toisin kuin ClickHousessa, ainoa tapa säästää levytilaa TimescaleDB:ssä on käyttää ZFS:ää tai vastaavia tiedostojärjestelmiä.
ClickHousen tulevat päivitykset tuovat todennäköisesti käyttöön delta-pakkauksen, mikä tekee siitä entistä sopivamman aikasarjatietojen käsittelyyn ja tallentamiseen. TimescaleDB voi olla parempi valinta kuin paljas ClickHouse seuraavissa tapauksissa:
- pienet asennukset erittäin pienellä RAM-muistilla (<3 Gt);
- suuri määrä pieniä INSERTejä, joita et halua puskuroida suuriksi fragmenteiksi;
- parempi johdonmukaisuus, yhtenäisyys ja happovaatimukset;
- PostGIS-tuki;
- yhdistää olemassa oleviin PostgreSQL-taulukoihin, koska Timescale DB on pohjimmiltaan PostgreSQL.
Kilpailu Hadoop- ja MapReduce-järjestelmien kanssa
Hadoop ja muut MapReduce-tuotteet voivat suorittaa monia monimutkaisia laskelmia, mutta niillä on taipumus suorittaa valtava viive. ClickHouse korjaa tämän ongelman käsittelemällä teratavuja tietoa ja tuottamalla tuloksia lähes välittömästi. Siten ClickHouse on paljon tehokkaampi nopean, interaktiivisen analyyttisen tutkimuksen suorittamiseen, jonka pitäisi kiinnostaa datatieteilijöitä.
Kilpailu Pinotin ja Druidin kanssa
ClickHousen lähimmät kilpailijat ovat pylväsmäiset, lineaarisesti skaalautuvat avoimen lähdekoodin tuotteet Pinot ja Druid. Artikkelissa on julkaistu erinomaista työtä näiden järjestelmien vertailussa 1. helmikuuta 2018
Tämä artikkeli on päivitettävä - siinä sanotaan, että ClickHouse ei tue UPDATE- ja DELETE-toimintoja, mikä ei ole täysin totta uusimpien versioiden suhteen.
Meillä ei ole paljon kokemusta näistä DBMS-järjestelmistä, mutta en pidä Druidin ja Pinotin suorittamiseen vaadittavan taustalla olevan infrastruktuurin monimutkaisuudesta - se on koko joukko "liikkuvia osia", joita Java ympäröi joka puolelta.
Druid ja Pinot ovat Apache-hautomoprojekteja, joita Apache käsittelee yksityiskohtaisesti GitHub-projektisivuillaan. Pinot ilmestyi hautomoon lokakuussa 2018, ja Druid syntyi 8 kuukautta aikaisemmin - helmikuussa.
Tietojen puute AFS:n toiminnasta herättää minulle joitain ja ehkä tyhmiä kysymyksiä. Ihmettelen, huomasivatko Pinotin kirjoittajat, että Apache Foundation suhtautuu enemmän druideihin, ja aiheuttiko tällainen asenne kilpailijaa kohtaan kateutta? Hidastuuko Druidin kehitys ja kiihtyykö Pinotin kehitys, jos ensimmäistä tukevat sponsorit alkavat yhtäkkiä kiinnostua jälkimmäisestä?
ClickHousen haitat
Epäkypsyys: On selvää, että tämä on edelleen tylsä tekniikka, mutta joka tapauksessa mitään tällaista ei nähdä muissa sarakepohjaisissa DBMS-järjestelmissä.
Pienet lisäykset eivät toimi hyvin suurella nopeudella: lisäkkeet on jaettava suuriin osiin, koska pienten lisäosien suorituskyky heikkenee suhteessa kunkin rivin sarakkeiden määrään. Näin ClickHouse tallentaa tiedot levylle - jokainen sarake tarkoittaa yhtä tiedostoa tai enemmän, joten 1 saraketta sisältävän rivin lisäämiseksi sinun on avattava ja kirjoitettava vähintään 1 tiedostoa. Tästä syystä puskurointiin tarvitaan välittäjä (ellei asiakas itse tee puskurointia) - yleensä Kafkan tai jonkinlaisen jonojärjestelmän. Voit myös käyttää puskuritaulukkomoottoria kopioidaksesi myöhemmin suuria tietopaloja MergeTree-taulukoihin.
Palvelimen RAM rajoittaa pöytäliittymiä, mutta ainakin ne ovat siellä! Esimerkiksi Druidilla ja Pinotilla ei ole tällaisia yhteyksiä ollenkaan, koska niitä on vaikea toteuttaa suoraan hajautetuissa järjestelmissä, jotka eivät tue suurten tietopalojen siirtämistä solmujen välillä.
Tulokset
Tulevina vuosina aiomme hyödyntää laajasti ClickHousen Qwintryssä, koska tämä DBMS tarjoaa erinomaisen suorituskyvyn, alhaiset yleiskustannukset, skaalautuvuuden ja yksinkertaisuuden tasapainon. Olen melko varma, että se leviää nopeasti, kun ClickHouse-yhteisö keksii lisää tapoja käyttää sitä pienissä ja keskisuurissa asennuksissa.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com