Kolme vuotta sitten Viktor Tarnavsky ja Aleksei Milovidov Yandexistä lavalla HighLoad++ , mikä ClickHouse on hyvä ja miten se ei hidasta. Ja seuraavassa vaiheessa oli Aleksanteri Zaitsev с muuttamisesta Napsauta taloa toisesta analyyttisestä DBMS:stä ja päätelmänä, että Napsauta taloa, tietysti hyvä, mutta ei kovin kätevä. Kun vuonna 2016 yritys LifeStreet, jossa Alexander työskenteli silloin, käänsi monipetabyyttisen analyysijärjestelmän kielelle Napsauta taloa, se oli kiehtova "keltatiilitie" täynnä tuntemattomia vaaroja - Napsauta taloa silloin se näytti miinakentältä.
Kolme vuotta myöhemmin Napsauta taloa muuttui paljon paremmaksi - tänä aikana Alexander perusti Altinity-yrityksen, joka ei vain auta muuttamaan Napsauta taloa kymmeniä projekteja, mutta myös parantaa itse tuotetta yhdessä Yandexin kollegoiden kanssa. Nyt Napsauta taloa ei vieläkään huoletonta kävelyä, mutta ei enää miinakenttää.
Alexander on ollut mukana hajautettujen järjestelmien parissa vuodesta 2003 lähtien ja kehittänyt suuria projekteja MySQL, Oracle и Vertica. Viimeisellä HighLoad++ 2019 Alexander, yksi käytön pioneereista Napsauta taloa, kertoi mikä tämä DBMS nyt on. Opimme tärkeimmistä ominaisuuksista Napsauta taloa: miten se eroaa muista järjestelmistä ja missä tapauksissa sitä on tehokkaampaa käyttää. Pohditaan esimerkkien avulla tuoreita ja projekteissa hyväksi havaittuja käytäntöjä rakennusjärjestelmien rakentamiseen Napsauta taloa.
Retrospektiivi: mitä tapahtui 3 vuotta sitten
Kolme vuotta sitten siirsimme yrityksen LifeStreet päälle Napsauta taloa toisesta analyyttisestä tietokannasta, ja mainosverkoston analytiikan siirto näytti tältä:
- kesäkuuta 2016 Avoin lähdekoodi ilmestyi Napsauta taloa ja projektimme alkoi;
- Elokuussa. todiste konseptista: suuri mainosverkosto, infrastruktuuri ja 200-300 teratavua dataa;
- Lokakuu. Ensimmäiset tuotantotiedot;
- Joulukuu. Täysi tuotekuorma - 10-50 miljardia tapahtumaa päivässä.
- Kesäkuu 2017. Käyttäjien siirto onnistui Napsauta taloa, 2,5 petatavua dataa 60 palvelimen klusterissa.
Muuttoprosessin aikana ymmärrys siitä lisääntyi Napsauta taloa on hyvä järjestelmä, jonka kanssa on miellyttävä työskennellä, mutta tämä on Yandexin sisäinen projekti. Siksi on vivahteita: Yandex käsittelee ensin omia sisäisiä asiakkaitaan ja vasta sitten yhteisön ja ulkoisten käyttäjien tarpeita, kun taas ClickHouse ei saavuttanut yritystasoa monilla toiminnallisilla alueilla silloin. Joten maaliskuussa 2017 perustimme Altinity to make Napsauta taloa vielä nopeampi ja kätevämpi ei vain Yandexille, vaan myös muille käyttäjille. Ja nyt me:
- Koulutamme ja autamme rakentamaan ratkaisuja perustuen Napsauta taloa jotta asiakkaat eivät joudu vaikeuksiin ja jotta ratkaisu lopulta toimii;
- Tarjoamme 24/7 tukea Napsauta taloa- asennukset;
- Kehitämme omia ekosysteemiprojektejamme;
- Sitoudun aktiivisesti itseeni Napsauta taloa, joka vastaa käyttäjien pyyntöihin, jotka haluavat nähdä tiettyjä ominaisuuksia.
Ja tietysti autamme muutossa Napsauta taloa с MySQL, Vertica, oraakkeli, Vihreäluumu, Redshift ja muut järjestelmät. Olemme olleet mukana monenlaisissa muutoissa ja ne kaikki ovat onnistuneet.
Miksi edes muuttaa Napsauta taloa
Ei hidasta! Tämä on tärkein syy. Napsauta taloa - erittäin nopea tietokanta erilaisille skenaarioille:
Satunnaisia lainauksia ihmisiltä, jotka työskentelevät kanssa Napsauta taloa.
Skaalautuvuus. Jossain muussa tietokannassa voit saavuttaa hyvän suorituskyvyn yhdellä laitteistolla, mutta Napsauta taloa Voit skaalata paitsi pystysuunnassa myös vaakasuunnassa yksinkertaisesti lisäämällä palvelimia. Kaikki ei toimi niin sujuvasti kuin haluaisimme, mutta se toimii. Voit kasvattaa järjestelmää yrityksesi kasvaessa. On tärkeää, että päätös ei nyt rajoita meitä ja kehityspotentiaalia on aina.
Siirrettävyys. Ei ole kiintymystä yhteen asiaan. Esimerkiksi kanssa Amazonin punainen siirto On vaikea liikkua jonnekin. A Napsauta taloa voit laittaa sen kannettavaan tietokoneeseen, palvelimeen, ottaa sen käyttöön pilvessä, mennä osoitteeseen Kubernetes — infrastruktuurin toiminnalle ei ole rajoituksia. Tämä on kätevä kaikille, ja tämä on suuri etu, jota monet muut vastaavat tietokannat eivät voi ylpeillä.
joustavuus. Napsauta taloa ei pysähdy yhteen asiaan, esimerkiksi Yandex.Metricaan, vaan sitä kehitetään ja käytetään yhä useammissa eri projekteissa ja toimialoilla. Sitä voidaan laajentaa lisäämällä uusia ominaisuuksia uusien ongelmien ratkaisemiseksi. Esimerkiksi lokien tallentamisen tietokantaan uskotaan olevan huonoja tapoja, joten he keksivät tämän Elasticsearch. Mutta joustavuuden ansiosta Napsauta taloa, voit myös tallentaa siihen lokit, ja usein se on jopa parempi kuin sisällä Elasticsearch - klo Napsauta taloa se vaatii 10 kertaa vähemmän rautaa.
Vapaa Open Source. Sinun ei tarvitse maksaa mistään. Sinun ei tarvitse neuvotella lupaa asentaa järjestelmä kannettavaan tietokoneeseen tai palvelimeen. Ei ole piilotettuja maksuja. Samaan aikaan mikään muu avoimen lähdekoodin tietokantatekniikka ei voi kilpailla nopeudessa Napsauta taloa. MySQL, MariaDB, Greenplum - ne ovat kaikki paljon hitaampia.
Yhteisö, ajaa ja hauska. Sisään Napsauta taloa erinomainen yhteisö: tapaamiset, chatit ja Aleksei Milovidov, joka lataa meitä kaikkia energiallaan ja optimismillaan.
Muutto ClickHouseen
Mennä Napsauta taloa tarvitset vain kolme asiaa:
- Ymmärrä rajoitukset Napsauta taloa ja mihin se ei sovellu.
- Käytä etuja teknologiaa ja sen suurimpia vahvuuksia.
- Koe. Vaikka tietäisi kuinka se toimii Napsauta taloa, ei aina ole mahdollista ennustaa, milloin se on nopeampi, milloin se on hitaampaa, milloin se on parempi ja milloin se on huonompi. Joten yritä.
Liikkumisongelma
On vain yksi "mutta": jos muutat Napsauta taloa jostain muusta, jokin menee yleensä pieleen. Olemme tottuneet joihinkin käytäntöihin ja asioihin, jotka toimivat suosikkitietokannassamme. Esimerkiksi kuka tahansa, jonka kanssa työskentelee SQL-tietokannat pitävät seuraavia toimintoja pakollisina:
- liiketoimet;
- rajoitukset;
- johdonmukaisuus;
- indeksit;
- PÄIVITYS/POISTA;
- NULLeja;
- millisekuntia;
- automaattiset tyyppivalut;
- useita liitoksia;
- mielivaltaiset osiot;
- klusterinhallintatyökalut.
Rekrytointi on pakollista, mutta kolme vuotta sitten sisään Napsauta taloa ei ollut mitään näistä ominaisuuksista! Nyt alle puolet realisoitumattomista jäännöksistä: tapahtumat, rajoitukset, johdonmukaisuus, millisekunnit ja tyypin valu.
Ja pääasia, että sisään Napsauta taloa jotkut vakiokäytännöt ja lähestymistavat eivät toimi tai eivät toimi niin kuin olemme tottuneet. Kaikki, mikä näkyy Napsauta taloa, vastaa "ClickHouse tapa", eli toiminnot poikkeavat muista tietokantoista. Esimerkiksi:
- Indeksejä ei valita, vaan ne ohitetaan.
- PÄIVITYS/POISTA ei synkroninen, vaan asynkroninen.
- Liitoksia on useita, mutta kyselyn suunnittelijaa ei ole. Tietokantamaailman ihmisille ei yleensä ole kovin selvää, kuinka ne sitten suoritetaan.
ClickHouse-skenaariot
Vuonna 1960 unkarilaistaustainen amerikkalainen matemaatikko WignerEP kirjoitti artikkelinMatematiikan kohtuuton tehokkuus luonnontieteissä”("Matematiikan käsittämätön tehokkuus luonnontieteissä"), että ympärillämme oleva maailma on jostain syystä hyvin kuvattu matemaattisilla laeilla. Matematiikka on abstrakti tiede, ja matemaattisessa muodossa ilmaistut fysiikan lait eivät ole triviaaleja, ja WignerEP korosti, että tämä on hyvin outoa.
Minun näkökulmastani, Napsauta taloa - sama omituisuus. Wignerin uudelleenmuotoiluun voidaan sanoa seuraavaa: hämmästyttävää on käsittämätön tehokkuus Napsauta taloa monenlaisissa analyyttisissa sovelluksissa!
Otetaan esimerkiksi Reaaliaikainen tietovarasto, johon tietoja ladataan lähes jatkuvasti. Haluamme saada häneltä pyyntöjä toisen viiveellä. Ole hyvä ja käytä sitä Napsauta taloakoska se on suunniteltu tätä skenaariota varten. Napsauta taloa näin sitä ei käytetä vain verkossa, vaan myös markkinoinnissa ja talousanalytiikassa, AdTech, samoin kuin sisään Petoksen havaitseminenn. SISÄÄN Reaaliaikainen tietovarasto käytetään monimutkaista rakenteellista skeemaa, kuten "tähti" tai "lumihiutale", useissa taulukoissa LIITY (joskus useita), ja tiedot yleensä tallennetaan ja niitä muutetaan joissakin järjestelmissä.
Otetaan toinen skenaario - Aikasarja: valvontalaitteet, verkot, käyttötilastot, esineiden internet. Täällä kohtaamme melko yksinkertaisia ajoissa tilattuja tapahtumia. Napsauta taloa ei ollut alun perin suunniteltu tähän, mutta on osoittanut itsensä hyvin, joten suuret yritykset käyttävät Napsauta taloa seurantatietojen arkistona. Saa nähdä sopiiko se Napsauta taloa aikasarjoille teimme vertailun lähestymistavan ja tulosten perusteella TuloDB и AikatauluDB - erikoistunut Aikasarja tietokannat. Että Napsauta taloa, jopa ilman optimointia tällaisiin tehtäviin, voittaa myös vieraalla kentällä:
В Aikasarja yleensä käytetään kapeaa taulukkoa - useita pieniä sarakkeita. Valvonnasta voi tulla paljon dataa – miljoonia tietueita sekunnissa – ja ne tulevat yleensä pienissä liitteissä (reaaliaikainen suoratoisto). Siksi tarvitaan erilainen lisäyskomentosarja, ja itse kyselyillä on omat erityispiirteensä.
Kirjaudu Management. Lokien kerääminen tietokantaan on yleensä huonoa, mutta sisään Napsauta taloa tämä voidaan tehdä muutamilla kommenteilla edellä kuvatulla tavalla. Monet yritykset käyttävät Napsauta taloa vain tätä varten. Tässä tapauksessa käytetään tasaista leveää pöytää, johon tallennamme koko lokit (esimerkiksi muodossa JSON) tai leikkaa paloiksi. Tiedot ladataan yleensä suurissa erissä (tiedostoina), ja etsimme jotain kenttää.
Kutakin näistä toiminnoista varten käytetään yleensä erikoistuneita tietokantoja. Napsauta taloa voi tehdä kaiken ja niin hyvin, että se ohittaa heidät suorituskyvyssä. Katsotaanpa nyt tarkemmin Aikasarja käsikirjoitus ja kuinka "keittää" Napsauta taloa tämän skenaarion mukaan.
Aikasarja
Tällä hetkellä tämä on pääskenaario, jolle Napsauta taloa pitää vakioratkaisuna. Aikasarja on joukko aikajärjestettyjä tapahtumia, jotka edustavat muutoksia jossain prosessissa ajan myötä. Se voi olla esimerkiksi syke päivässä tai järjestelmän prosessien määrä. Kaikki, mikä antaa aikaa tietyillä mitoilla, on Aikasarja:
Suurin osa näistä tapahtumista tulee seurannasta. Tämä ei voi olla vain verkkoseurantaa, vaan myös oikeita laitteita: autoja, teollisuusjärjestelmiä, Esineiden internet, teollisuus tai miehittämättömät taksit, joiden tavaratilaan Yandex jo laittaa Napsauta taloa-palvelin.
Esimerkiksi on yrityksiä, jotka keräävät tietoja laivoista. Muutaman sekunnin välein konttialuksen anturit lähettävät satoja erilaisia mittauksia. Insinöörit tutkivat niitä, rakentavat malleja ja yrittävät ymmärtää, kuinka tehokkaasti alusta käytetään, sillä konttilaiva ei saa seistä sekuntiakaan käyttämättömänä. Kaikki seisokit ovat rahan haaskausta, joten on tärkeää ennustaa reitti niin, että pysäköinti on minimaalista.
Nykyään mittaavien erikoistuneiden tietokantojen määrä on lisääntynyt Aikasarja. verkossa DB-Moottorit jotenkin erilaiset tietokannat luokitellaan, ja niitä voidaan tarkastella tyypin mukaan:
Nopeimmin kasvava tyyppi Aikasarjas. Myös graafiset tietokannat kasvavat, mutta Aikasarjaovat kasvaneet nopeammin viime vuosina. Tämän tietokantaperheen tyypillisiä edustajia ovat TuloDB, Prometheus, KDB, AikatauluDB (rakennettu PostgreSQL), ratkaisut alkaen Amazon. Napsauta taloa voidaan käyttää myös täällä, ja sitä käytetään. Annan muutaman julkisen esimerkin.
Yksi edelläkävijöistä on yritys CloudFlare (CDNtarjoaja). He valvovat omaansa CDN kautta Napsauta taloa (DNS-pyynnöt, HTTP-pyynnöt) valtavalla kuormalla - 6 miljoonaa tapahtumaa sekunnissa. Kaikki menee läpi Kafka, menee Napsauta taloa, joka tarjoaa mahdollisuuden nähdä järjestelmän tapahtumien reaaliaikaiset kojelaudat.
Comcast - yksi johtavista tietoliikenteen alalla Yhdysvalloissa: Internet, digitaalinen televisio, puhelin. He loivat samanlaisen ohjausjärjestelmän CDN puitteissa Open Source projekti Apache Traffic Control työskennellä heidän valtavan datansa kanssa. Napsauta taloa käytetään analytiikan taustaohjelmana.
percona sisäänrakennettu Napsauta taloa sinun sisälläsi PMMseurata erilaista MySQL.
Erityisvaatimukset
Aikasarjatietokannoilla on omat erityisvaatimukset.
- Nopea lisäys monilta agenteilta. Meidän on lisättävä tiedot monista virroista hyvin nopeasti. Napsauta taloa Se tekee tämän hyvin, koska kaikki sen lisäkkeet eivät estä. Minkä tahansa lisätä on uusi tiedosto levyllä, ja pienet lisäkkeet voidaan puskuroida tavalla tai toisella. SISÄÄN Napsauta taloa on parempi lisätä tiedot suurissa erissä kuin yksi rivi kerrallaan.
- Joustava piiri. Sisään Aikasarja emme yleensä tunne tietojen rakennetta täysin. Tietylle sovellukselle on mahdollista rakentaa valvontajärjestelmä, mutta silloin sitä on vaikea käyttää toiseen sovellukseen. Tämä vaatii joustavamman järjestelmän. Napsauta taloa, antaa sinun tehdä tämän, vaikka se on vahvasti kirjoitettu pohja.
- Tehokas tallennus ja "unohdettavat" tiedot. Yleensä sisään Aikasarja valtava määrä tietoa, joten ne on tallennettava mahdollisimman tehokkaasti. Esimerkiksi klo TuloDB hyvä pakkaus on sen tärkein ominaisuus. Mutta tallennustilan lisäksi sinun on myös voitava "unohtaa" vanhat tiedot ja tehdä joitain alasnäytteistys — aggregaattien automaattinen laskenta.
- Nopeat kyselyt koostetuista tiedoista. Joskus on mielenkiintoista tarkastella viimeistä 5 minuuttia millisekuntien tarkkuudella, mutta kuukausitiedoissa minuutti- tai sekuntitarkkuutta ei ehkä tarvita - yleiset tilastot riittävät. Tällaista tukea tarvitaan, muuten 3 kuukauden pyyntö toteutuu erittäin pitkään jopa sisällä Napsauta taloa.
- Pyynnöt kuten "viimeinen kohta, tällä hetkellä». Nämä ovat tyypillisiä Aikasarja pyynnöt: katso viimeisintä mittausta tai järjestelmän tilaa tietyllä hetkellä t. Tietokannan kannalta nämä eivät ole kovin miellyttäviä kyselyitä, mutta ne on myös kyettävä suorittamaan.
- "Liimaus" aikasarja. Aikasarja on aikasarja. Jos aikasarjoja on kaksi, ne on usein yhdistettävä ja korreloitava. Tätä ei ole kätevää tehdä kaikissa tietokannoissa, etenkään kohdistamattomissa aikasarjoissa: tässä on joitain aikamerkkejä, on muita. Keskiarvoa voi harkita, mutta yhtäkkiä tulee silti reikä, joten se ei ole selvää.
Katsotaan kuinka nämä vaatimukset täyttyvät Napsauta taloa.
ohjelma
В Napsauta taloa kaava varten Aikasarja voidaan tehdä eri tavoilla tietojen säännöllisyyden asteesta riippuen. Järjestelmä on mahdollista rakentaa tavalliselle datalle, kun tiedämme kaikki mittarit etukäteen. Esimerkiksi teki CloudFlare seurannan kanssa CDN on hyvin optimoitu järjestelmä. Voit rakentaa yleisemmän järjestelmän, joka valvoo koko infrastruktuuria, erilaisia palveluita. Epäsäännöllisten tietojen tapauksessa emme tiedä etukäteen, mitä valvomme - ja tämä on luultavasti yleisin tapaus.
säännölliset tiedot. Sarakkeet. Kaava on yksinkertainen - sarakkeet, joissa on tarvittavat tyypit:
CREATE TABLE cpu (
created_date Date DEFAULT today(),
created_at DateTime DEFAULT now(),
time String,
tags_id UInt32, /* join to dim_tag */
usage_user Float64,
usage_system Float64,
usage_idle Float64,
usage_nice Float64,
usage_iowait Float64,
usage_irq Float64,
usage_softirq Float64,
usage_steal Float64,
usage_guest Float64,
usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);Tämä on tavallinen taulukko, joka tarkkailee jonkinlaista järjestelmän käynnistystä (lähettämä, järjestelmä, tyhjäkäynti, mukava). Yksinkertainen ja kätevä, mutta ei joustava. Jos haluamme joustavamman järjestelmän, voimme käyttää taulukoita.
Epäsäännölliset tiedot. Taulukot:
CREATE TABLE cpu_alc (
created_date Date,
created_at DateTime,
time String,
tags_id UInt32,
metrics Nested(
name LowCardinality(String),
value Float64
)
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);
SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...
Rakenne sisäkkäiset on kaksi taulukkoa: metrics.name и metrics.value. Täällä voit tallentaa tällaiset mielivaltaiset seurantatiedot joukona nimiä ja mittauksia jokaiselle tapahtumalle. Lisäoptimointia varten voidaan tehdä useita tällaisia rakenteita yhden sijasta. Esimerkiksi yksi varten kellua-arvo, toinen - puolesta int-tarkoittaa koska int Haluan varastoida tehokkaammin.
Mutta tällaiseen rakenteeseen on vaikeampi päästä käsiksi. Sinun on käytettävä erityistä rakennetta käyttämällä erikoistoimintoja vetääksesi arvot ensin indeksistä ja sitten taulukosta:
SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...Mutta se toimii silti tarpeeksi nopeasti. Toinen tapa tallentaa epäsäännöllisiä tietoja on rivien mukaan.
Epäsäännölliset tiedot. jouset. Tällä perinteisellä tavalla, ilman taulukoita, nimet ja arvot tallennetaan kerralla. Jos yhdestä laitteesta tulee kerralla 5 000 mittausta, tietokantaan luodaan 5 000 riviä:
CREATE TABLE cpu_rlc (
created_date Date,
created_at DateTime,
time String,
tags_id UInt32,
metric_name LowCardinality(String),
metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);
SELECT
maxIf(metric_value, metric_name = 'usage_user'),
...
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)
Napsauta taloa selviää tästä - siinä on erityiset laajennukset Napsauta taloa SQL. Esimerkiksi maxIf - erikoistoiminto, joka laskee maksimin metriikan mukaan, kun jokin ehto täyttyy. Voit kirjoittaa useita tällaisia lausekkeita yhteen kyselyyn ja laskea välittömästi useiden mittareiden arvon.
Verrataanpa kolmea lähestymistapaa:
Olen lisännyt tähän "Data Size on Disk" jollekin testitietojoukolle. Sarakkeiden tapauksessa meillä on pienin tietokoko: suurin pakkaus, suurin kyselynopeus, mutta maksamme korjaamalla kaikki kerralla.
Taulukon tapauksessa asiat ovat hieman huonommat. Data tiivistyy edelleen hyvin ja on mahdollista tallentaa epäsäännöllinen kuvio. Mutta Napsauta taloa - saraketietokanta, ja kun alamme tallentaa kaiken taulukkoon, se muuttuu merkkijonoksi ja joustavuudesta maksamme tehokkuudella. Jokaista toimintoa varten sinun on luettava koko matriisi muistiin ja löydettävä sitten haluttu elementti - ja jos taulukko kasvaa, nopeus heikkenee.
Yhdessä tätä lähestymistapaa käyttävissä yrityksissä (esim. ), taulukot leikataan 128 elementin paloiksi. Useiden tuhansien mittareiden tietoja, joiden määrä on 200 TB dataa / päivä, ei tallenneta yhteen taulukkoon, vaan 10 tai 30 taulukkoon erityisellä tallennuslogiikalla.
Yksinkertaisin tapa on käyttää merkkijonoja. Mutta data on huonosti pakattu, taulukon koko on suuri, ja vaikka kyselyt perustuvat useisiin mittareihin, ClickHouse ei toimi optimaalisesti.
hybridijärjestelmä
Oletetaan, että olemme valinneet taulukkoskeeman. Mutta jos tiedämme, että useimmat kojelaudoistamme näyttävät vain käyttäjä- ja järjestelmämittareita, voimme lisäksi materialisoida nämä tiedot sarakkeiksi taulukon taulukosta seuraavalla tavalla:
CREATE TABLE cpu_alc (
created_date Date,
created_at DateTime,
time String,
tags_id UInt32,
metrics Nested(
name LowCardinality(String),
value Float64
),
usage_user Float64
MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
usage_system Float64
MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);
Kun liimattu Napsauta taloa laskee ne automaattisesti. Näin voit yhdistää bisnestä iloon: kaava on joustava ja yleinen, mutta otimme esiin yleisimmin käytetyt sarakkeet. Huomautan, että tämä ei vaatinut sisäkkeen vaihtamista ja ETL, joka jatkaa taulukoiden lisäämistä taulukkoon. Teimme juuri ALTER TABLE, lisäsi pari kaiutinta ja sai hybridin ja nopeamman järjestelmän, jonka voit aloittaa käytön heti.
Koodekit ja pakkaus
varten Aikasarja on tärkeää, kuinka hyvin pakkaat tiedot, koska tietojoukko voi olla hyvin suuri. SISÄÄN Napsauta taloa on joukko työkaluja, joilla saavutetaan pakkaussuhde 1:10, 1:20 ja joskus enemmän. Tämä tarkoittaa, että 1 Tt pakkaamatonta tietoa levyllä vie 50-100 Gt. Pienempi koko on hyvä, tiedot voidaan lukea ja käsitellä nopeammin.
Korkean puristustason saavuttamiseksi Napsauta taloa tukee seuraavia koodekkeja:
Esimerkkitaulukko:
CREATE TABLE benchmark.cpu_codecs_lz4 (
created_date Date DEFAULT today(),
created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4),
tags_id UInt32,
usage_user Float64 Codec(Gorilla, LZ4),
usage_system Float64 Codec(Gorilla, LZ4),
usage_idle Float64 Codec(Gorilla, LZ4),
usage_nice Float64 Codec(Gorilla, LZ4),
usage_iowait Float64 Codec(Gorilla, LZ4),
usage_irq Float64 Codec(Gorilla, LZ4),
usage_softirq Float64 Codec(Gorilla, LZ4),
usage_steal Float64 Codec(Gorilla, LZ4),
usage_guest Float64 Codec(Gorilla, LZ4),
usage_guest_nice Float64 Codec(Gorilla, LZ4),
additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);Tässä määrittelemme koodekin DoubleDelta yhdessä tapauksessa, toisessa Gorilla, ja muista lisätä lisää LZ4 puristus. Tämän seurauksena levyllä olevien tietojen koko pienenee huomattavasti:
Tämä näyttää, kuinka paljon tilaa sama data vie, mutta käyttämällä erilaisia koodekkeja ja pakkauksia:
- levyllä olevassa GZIP-tiedostossa;
- ClickHousessa ilman koodekkeja, mutta ZSTD-pakkauksella;
- ClickHousessa LZ4- ja ZSTD-koodekkeilla ja pakkauksella.
Voidaan nähdä, että koodekeilla varustetut taulukot vievät paljon vähemmän tilaa.
Koko on tärkeää
Ei vähemmän tärkeä oikea tietotyyppi:
Kaikissa yllä olevissa esimerkeissä olen käyttänyt Kelluva 64. Mutta jos valitsisimme Kelluva 32niin se olisi vielä parempi. Tämän osoittivat hyvin Perkonan kaverit yllä olevan linkin artikkelissa. On tärkeää käyttää mahdollisimman kompaktia, tehtävään sopivaa tyyppiä: vielä vähemmän levyn koon kuin kyselyn nopeuden kannalta. Napsauta taloa erittäin herkkä sille.
Jos osaat käyttää intxnumx sen sijasta intxnumx, odota sitten suorituskyvyn lähes kaksinkertaistuvan. Tiedot vievät vähemmän muistia, ja kaikki "aritmetiikka" toimii paljon nopeammin. Napsauta taloa sen sisällä on erittäin tiukasti kirjoitettu järjestelmä, se hyödyntää kaikki nykyaikaisten järjestelmien tarjoamat mahdollisuudet.
Aggregointi ja Toteutuneet näkymät
Kokoonpanon ja materialisoituneiden näkymien avulla voit tehdä aggregaatteja eri tilanteisiin:
Sinulla voi esimerkiksi olla ei-koottuja lähdetietoja, ja voit ripustaa niihin erilaisia materialisoituneita näkymiä automaattisella summauksella erityisen moottorin kautta. SummingMergeTree (SMT). SMT on erityinen koontitietorakenne, joka laskee aggregaatit automaattisesti. Raakadata lisätään tietokantaan, se kootaan automaattisesti ja kojetauluja voidaan käyttää heti.
TTL - "unohda" vanhat tiedot
Kuinka "unohda" tiedot, joita ei enää tarvita? Napsauta taloa tietää miten se tehdään. Kun luot taulukoita, voit määrittää TTL lausekkeet: esimerkiksi, että tallennamme minuuttitiedot yhdeltä päivältä, päivittäiset tiedot 30 päivältä emmekä koskaan kosketa viikoittaisia tai kuukausittaisia tietoja:
CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day
CREATE TABLE aggr_by_day
…
TTL time + interval 30 day
CREATE TABLE aggr_by_week
…
/* no TTL */
Moniportainen - jakaa tiedot levyille
Kun tätä ajatusta viedään pidemmälle, tietoja voidaan tallentaa Napsauta taloa eri paikoissa. Oletetaan, että haluamme tallentaa kuumat tiedot viime viikolta erittäin nopeaan paikalliseen SSD, ja laitamme enemmän historiallisia tietoja toiseen paikkaan. SISÄÄN Napsauta taloa nyt se on mahdollista:
Voit määrittää tallennuskäytännön (varastointikäytäntö) Joten Napsauta taloa siirtää tiedot automaattisesti toiseen tallennustilaan, kun tietyt ehdot täyttyvät.
Mutta siinä ei vielä kaikki. Tietyn taulukon tasolla voit määrittää säännöt tarkalleen, milloin tiedot siirretään kylmävarastoon. Esimerkiksi tiedot tallennetaan erittäin nopealle levylle 7 päivää ja kaikki vanhat siirretään hitaalle. Tämä on hyvä, koska sen avulla voit pitää järjestelmän maksimaalisessa suorituskyvyssä ja samalla hallita kustannuksia etkä tuhlaa rahaa kylmään dataan:
CREATE TABLE
...
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume',
date + INTERVAL 180 DAY DELETE
Ainutlaatuiset ominaisuudet Napsauta taloa
Melkein kaikki mukana Napsauta taloa sellaisia "kohokohtia" on, mutta ne tasoitetaan yksinoikeudella - mitä ei ole muissa tietokannoista. Tässä on esimerkiksi joitain ainutlaatuisia ominaisuuksia Napsauta taloa:
- taulukot. Sisään Napsauta taloa erittäin hyvä tuki taulukoille sekä kyky suorittaa monimutkaisia laskelmia niille.
- Tietorakenteiden yhdistäminen. Tämä on yksi "tappajaominaisuuksista" Napsauta taloa. Huolimatta siitä, että Yandexin kaverit sanovat, että emme halua koota tietoja, kaikki on koottu Napsauta taloakoska se on nopeaa ja kätevää.
- Toteutetut näkymät. Yhdessä kokoavien tietorakenteiden kanssa materialisoituneiden näkymien avulla voit tehdä kätevän reaaliaikainen yhdistäminen.
- ClickHouse SQL. Tämä on kielilaajennus SQL joidenkin lisäominaisuuksien kanssa, jotka ovat saatavilla vain Napsauta taloa. Aikaisemmin se oli toisaalta ikään kuin laajennus ja toisaalta haitta. Nyt lähes kaikki puutteet verrattuna SQL 92 poistimme sen, nyt se on vain laajennus.
- Lambda-ilmaisuja. Ovatko ne vielä jossain tietokannassa?
- ML-tuki. Tämä on saatavilla eri tietokannoista, jotkut ovat parempia, jotkut ovat huonompia.
- avoin lähdekoodi. Voimme laajentaa Napsauta taloa yhdessä. Nyt sisällä Napsauta taloa noin 500 kirjoittajaa, ja tämä määrä kasvaa jatkuvasti.
Hankalia kyselyitä
В Napsauta taloa on monia eri tapoja tehdä sama asia. Esimerkiksi on kolme eri tapaa palauttaa taulukon viimeinen arvo prosessori (on myös neljäs, mutta se on vielä eksoottisempi).
Ensimmäinen osoittaa, kuinka kätevää se on tehdä Napsauta taloa kysyy, kun haluat tarkistaa sen monikko alikyselyssä. Tämä on jotain, jota minulla henkilökohtaisesti todella puuttui muista tietokannoista. Jos haluan verrata jotain alikyselyyn, niin muissa tietokannoista voidaan verrata siihen vain skalaaria, ja useille sarakkeille minun on kirjoitettava LIITY. Sisään Napsauta taloa voit käyttää monikkoa:
SELECT *
FROM cpu
WHERE (tags_id, created_at) IN
(SELECT tags_id, max(created_at)
FROM cpu
GROUP BY tags_id)Toinen menetelmä tekee saman, mutta käyttää aggregaattifunktiota argMax:
SELECT
argMax(usage_user), created_at),
argMax(usage_system), created_at),
...
FROM cpu В Napsauta taloa aggregaattifunktioita on useita kymmeniä, ja jos käytät kombinaattoreita, niin kombinatoriikan lakien mukaan saat niitä noin tuhat. ArgMax - yksi funktioista, joka laskee maksimiarvon: kysely palauttaa arvon käyttö_käyttäjä, jossa maksimiarvo saavutetaan luotu_at:
SELECT now() as created_at,
cpu.*
FROM (SELECT DISTINCT tags_id from cpu) base
ASOF LEFT JOIN cpu USING (tags_id, created_at)
ASOF LIITTY — rivien "liimaus" eri aikoina. Tämä on ainutlaatuinen tietokantojen ominaisuus, ja se on käytettävissä vain kdb +. Jos on kaksi aikasarjaa eri aikoina, ASOF LIITTY voit siirtää ja yhdistää ne yhteen pyyntöön. Jokaiselle yhden aikasarjan arvolle löydetään lähin arvo toisesta, ja ne palautetaan samalla rivillä:
Analyyttiset toiminnot
Standardissa SQL-2003 voit kirjoittaa näin:
SELECT origin,
timestamp,
timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
FROM mytable
ORDER BY origin, timestamp;
В Napsauta taloa Et voi tehdä sitä - se ei tue standardia SQL-2003 eikä varmaan koskaan tulekaan. Sen sijaan sisään Napsauta taloa on tapana kirjoittaa näin:
Lupasin lambdat - tässä ne ovat!
Tämä on analogi standardin analyyttiselle kyselylle SQL-2003: se laskee eron kahden välillä aikaleima, kesto, järjestysluku - kaikki, mitä yleensä pidämme analyyttisinä funktioina. SISÄÄN Napsauta taloa laskemme ne taulukoiden kautta: ensin kutistamme tiedot taulukoksi, sen jälkeen teemme taulukossa mitä haluamme ja sitten laajennamme sitä takaisin. Se ei ole kovin kätevää, se vaatii ainakin rakkautta toiminnalliseen ohjelmointiin, mutta se on erittäin joustava.
Erikoistoiminnot
Sitä paitsi sisään Napsauta taloa monia erikoistoimintoja. Kuinka esimerkiksi määrittää, kuinka monta istuntoa tapahtuu samanaikaisesti? Tyypillinen valvontatehtävä on määrittää maksimikuorma yhdellä pyynnöllä. SISÄÄN Napsauta taloa tätä tarkoitusta varten on erityinen toiminto:
Yleensä ClickHousella on erikoistoimintoja moniin tarkoituksiin:
- juoksuEro, juoksuAccumulate, naapuri;
- sumMap(avain, arvo);
- aikaSeriesGroupSum(uid, aikaleima, arvo);
- aikaSeriesGroupRateSum(uid, aikaleima, arvo);
- skewPop, skewSamp, kurtPop, kurtSamp;
- TÄYTTEELLÄ / SIDEMIÄ;
- simpleLinearRegression, stokastinenLinearRegression.
Tämä ei ole täydellinen luettelo ominaisuuksista, niitä on vain 500-600. Vihje: kaikki toiminnot sisään Napsauta taloa on järjestelmätaulukossa (kaikkia ei ole dokumentoitu, mutta kaikki ovat mielenkiintoisia):
select * from system.functions order by nameNapsauta taloa tallentaa paljon tietoa itsestään, mm hirsipöydät, kyselyloki, jäljitysloki, toimintaloki tietolohkoilla (osa_loki), mittausloki ja järjestelmäloki, jotka se yleensä kirjoittaa levylle. Mittariloki on Aikasarja в Napsauta taloa itse asiassa Napsauta taloa: itse tietokannalla voi olla merkitystä Aikasarja tietokantoja, mikä "nielee" itsensä.
Tämä on myös ainutlaatuinen asia - koska teemme hyvää työtä Aikasarjamiksi emme voi pitää kaikkea mitä tarvitsemme? Emme tarvitse Prometheus, pidämme kaiken itsellämme. Yhdistetty grafana ja valvomme itseämme. Kuitenkin, jos Napsauta taloa kaatuu, emme näe miksi, joten he eivät yleensä tee niin.
Suuri klusteri tai monta pientä Napsauta taloa
Mikä on parempi - yksi iso klusteri vai monta pientä ClickHousea? Perinteinen lähestymistapa DWH on suuri klusteri, jossa järjestelmät allokoidaan jokaiselle sovellukselle. Tulimme tietokannan ylläpitäjän luo - anna meille skeema, ja meille annettiin se:
В Napsauta taloa voit tehdä sen toisin. Voiko jokainen sovellus tehdä omanlaisensa Napsauta taloa:
Emme tarvitse enää suurta hirviötä DWH ja hankalat järjestelmänvalvojat. Voimme antaa jokaiselle sovellukselle omanlaisensa Napsauta taloa, ja kehittäjä voi tehdä sen itse, koska Napsauta taloa erittäin helppo asentaa eikä vaadi monimutkaista hallintoa:
Mutta jos meillä on paljon Napsauta taloa, ja sinun on asetettava se usein, niin haluat automatisoida tämän prosessin. Tätä varten voimme käyttää esim Kubernetes и clickhouse-operaattori. SISÄÄN Kubernetes ClickHouse voit laittaa "on click": voin napsauttaa painiketta, suorittaa manifestin ja tietokanta on valmis. Voit heti luoda kaavion, aloittaa mittareiden lataamisen sinne, ja 5 minuutin kuluttua minulla on kojelauta valmiina grafana. Se on niin yksinkertaista!
Tulos?
Niin, Napsauta taloa - Tämä on:
- nopeasti. Kaikki tietävät tämän.
- vain. Hieman kiistanalaista, mutta mielestäni se on vaikea oppia, helppo taistella. Jos ymmärrät miten Napsauta taloa toimii, kaikki on hyvin yksinkertaista.
- Yleisesti. Se sopii erilaisiin skenaarioihin: DWH, aikasarja, lokivarasto. Mutta se ei ole OLTP tietokanta, joten älä yritä tehdä siellä lyhyitä lisäyksiä ja lukemia.
- Mielenkiintoista. Todennäköisesti se, jonka kanssa työskentelee Napsauta taloa, kokenut monia mielenkiintoisia minuutteja hyvässä ja huonossa mielessä. Esimerkiksi uusi julkaisu ilmestyi, kaikki lakkasi toimimasta. Tai kun kamppailit tehtävän kanssa kaksi päivää, mutta Telegram-chatin kysymyksen jälkeen tehtävä ratkesi kahdessa minuutissa. Tai, kuten konferenssissa Lesha Milovidovin raportissa, kuvakaappaus kohteesta Napsauta taloa katkaisi lähetyksen HighLoad++. Tällaisia asioita tapahtuu jatkuvasti ja ne vaikuttavat elämäämme Napsauta taloa valoisaa ja mielenkiintoista!
Esitys on katsottavissa .
Pitkään odotettu korkean kuormituksen järjestelmien kehittäjien tapaaminen klo järjestetään 9. ja 10. marraskuuta Skolkovossa. Lopuksi se on offline-konferenssi (tosin kaikki varotoimenpiteet), koska HighLoad++:n energiaa ei voi pakata verkkoon.
Konferenssia varten etsimme ja näytämme sinulle tapauksia tekniikan maksimaalisista mahdollisuuksista: HighLoad ++ oli, on ja tulee olemaan ainoa paikka, jossa voit oppia kahdessa päivässä kuinka Facebook, Yandex, VKontakte, Google ja Amazon toimivat.
Pidettyämme kokoukset keskeytyksettä vuodesta 2007, tapaamme tänä vuonna 14. kerran. Tänä aikana konferenssi on kasvanut 10-kertaiseksi, viime vuonna alan avaintapahtuma keräsi 3339 osallistujaa, 165 raporttien ja tapaamisen puhujaa ja samaan aikaan soi 16 kappaletta.
Viime vuonna linja-autoja oli 20, teetä ja kahvia 5280 litraa, hedelmäjuomia 1650 litraa ja vesipulloa 10200. Ja vielä 2640 16 kiloa ruokaa, 000 25 lautasta ja 000 100 kuppia. Kierrätyspaperista kerätyillä rahoilla muuten istutimme XNUMX tammen taimia :)Voit ostaa lippuja , saada uutisia konferenssista - ja puhu kaikissa sosiaalisissa verkostoissa: , , и .
Lähde: will.com