Stringide optimeerimine ClickHouse'is. Yandexi ettekandja

Analüütiline andmebaas ClickHouse töötleb mitmesuguseid stringe, tarbides ressursse. Süsteemi töö kiirendamiseks lisatakse pidevalt uusi optimeerimisi. ClickHouse arendaja Nikolai Kočetov räägib stringi andmetüübist, sealhulgas uuest tüübist LowCardinality, ja selgitab, kuidas stringide töötlemist kiirendada.

— Esiteks laskem mõista, kuidas stringe salvestada.



Meil on stringi andmetüübid. String on vaikimisi hästi sobiv, seda tasub kasutada peaaegu alati. Sellel on väike Overhead — 9 baiti ühe stringi kohta. Kui soovime, et stringide suurus oleks fikseeritud ja eelnevalt teada, tasub kasutada FixedStringi. Sellesse saab määrata soovitud byte'ide arvu, see on mugav näiteks IP-aadresside või hash-funktsioonide jaoks.

Muidugi aeg-ajalt midagi peatud. Oletame, et teete päringut tabelisse. ClickHouse loeb üsna suurt hulka andmeid, ütleme kiirusel 100 GB/s, samas töötleb see vähe stringe. Meil on kaks tabelit, mis hoiavad peaaegu sama andmestikku. Teisest tabelist loeb ClickHouse andmeid suurema kiirusena, kuid stringe loetakse kolmandiku võrra vähem sekundis.

Kui vaatame tihendatud andmete suurust, siis selgub, et see on peaaegu sama. Tegelikult on tabelites kirjas samad andmed — esimene miljard numbrit — ainult et esimeses veerus on need kirjutatud vormis UInt64, samas kui teises veerus on need Stringina. Seetõttu loetakse teise päringu andmed kettalt kauem ja need dekomprimeeritakse.

Siin on veel üks näide. Oletame, et meil on ette teada kindel rida stringe, mis on piiratud konstantsiga 1000 või 10 000 ja peaaegu kunagi ei muutu. Selleks sobib meile andmetüüp Enum, ClickHouse'is on neid kaks — Enum8 ja Enum16. Enum'i salvestamine kiirendab päringute töötlemist.

ClickHouse'is on kiirus täiendavatele GROUP BY, IN, DISTINCT-le ja optimeerimine teatud funktsioonide jaoks, näiteks konstantse stringiga võrreldes. Loomulikult ei muundata numbreid stringiks, vaid vastupidi, konstantne string muudetakse Enum'i väärtuseks. Pärast seda võrdlemine toimub kiiresti.

Aga on ka miinuseid. Isegi kui me teame täpselt rida stringe, peab see mõnikord täiendama. Kui uus string saabus — peame tegema ALTER.

ALTER Enum ClickHouse'is on optimaalselt rakendatud. Me ei kirjuta andmeid kettale ümber, kuid ALTER võib veidi venida, kuna Enum'i struktuurid salvestatakse tabeli enda skeemi. Seetõttu peame ootama lugemisotsuseid tabelist, näiteks.

Tekkib küsimus, kas on võimalik paremini teha? Tõenäoliselt jah. Enum'i struktuuri võiks säilitada mitte tabeli skeemis, vaid ZooKeeper'is. Siiski võivad tekkida sünkroonimisprobleemid. Näiteks, kui üks replika sai andmed, siis teine ei saanud, ja kui tal on vana Enum, siis midagi puruneb. (ClickHouse'is oleme peaaegu lõpetanud mitteblokeerivad ALTER-päringud. Kui me need täielikult lõpetame, ei ole enam vaja oodata lugemispäringuid.)

Kui te ei soovi ALTER Enum'iga tegelda, võite kasutada ClickHouse'i väliseid sõnastikke. Kordan, et see on key-value andmestruktuur ClickHouse'is, mille kaudu saab andmeid väliseidest allikatest, näiteks MySQL tabelitest.

ClickHouse'i sõnastikus hoiame me palju erinevaid ridu, ja tabelis on nende identifikaatorid numbrite kujul. Kui me peame saama rea, kutsume välja funktsiooni dictGet ja töötame sellega. Pärast seda ei tohiks me teha ALTERi. Kui soovime Enumisse midagi lisada, sisestame selle samasse MySQL tabelisse.

Kuid siin tekivad teised probleemid. Esiteks, ebamugav süntaks. Kui soovime saada rida, peame kutsuma välja dictGet. Teiseks, teatud optimeerimiste puudumine. Muudatust konstandistringiga sõnastike jaoks ei saa teha sama kiiresti.

Samuti võivad tekkida probleemid värskendamisega. Oletame, et küsisime rida vahemälu sõnastikus, aga see ei jõudnud vahemällu. Siis peame ootama, kuni andmed välisest allikast laaditakse.

Mõlema meetodi üldine puudus on see, et hoiame kõik võtmed ühes kohas ja sünkroniseerime need. Miks mitte hoida sõnastikke kohalikult? Pole sünkroniseerimist — pole probleeme. Sõnastikku saab hoida kohalikult plaadi tükkide kaupa. Seega teeme Inserti, kirjutame sõnastiku. Kui töötame andmetega mälu sees, saame sõnastiku kirja panna kas andmeplokki, veerutükkidesse või mõnda vahemälu, et arvutusi kiirendada.

Sõnaraamatute kodeerimine

Nii jõudsime ClickHouse'is uue andmetüübi – LowCardinality – loomiseni. See on andmete salvestamise formaat: kuidas need kirjutatakse kettale ja kuidas neid loetakse, kuidas need on mälus esindatud ja nende töötlemise skeem.

Slaidil on kaks veergu. Paremal on read salvestatud tavalisel viisil, tüübis String. Näha on, et need on mingid mobiiltelefonide mudelid. Vasakul on täpselt sama veerg, ainult tüübiga LowCardinality. See koosneb sõnastikust, kus on palju erinevaid reasse (parema veeru read), ja positsioonide loendist (rea numbrid).

Nende kahe struktuuriga saab taastada algse veeru. Samuti on olemas vastupidine indeks – rippmenüü, mis aitab leida rea positsiooni sõnastikus. Seda vajatakse mõnede päringute kiirendamiseks. Näiteks, kui soovime võrrelda, otsida rida meie veerus või neid omavahel ühendada.

LowCardinality on parameetriline andmetüüp. See võib olla kas number, midagi, mis salvestatakse numbrina, rida või nende Nullable variant.

LowCardinality'i eelis on see, et see võib salvestuda teatud funktsioonide jaoks. Slidil on näide päringust. Esimeses reas lõin LowCardinality tüüpi veeru String'ist, nimetasime selle S-ks. Siis küsisin selle nime — ClickHouse ütles, et see on LowCardinality String'ist. Kõik on korras.

Kolmas rida on peaaegu sama, lihtsalt kutsusime välja length funktsiooni. ClickHouse'is tagastab length funktsioon andmetüübi UInt64. Kuid nüüd saime LowCardinality UInt64. Mis selle tähendus on?

Sõnastikus olid mobiiltelefonide nimed, rakendasime length funktsiooni. Nüüd on meil sarnane sõnaraamat, mis koosneb ainult numbritest — need on stringide pikkused. Positsioonide veerg ei ole muutunud. Lõppkokkuvõttes töötasime vähemate andmetega, säästsime päringu ajas.

Võivad olla ka teised optimeerimised, näiteks lihtsa vahemälu lisamine. Funktsiooni väärtuse arvutamisel saab selle mäletada ja koostada sama, mitte arvutada uuesti.

Samuti saab GROUP BY optimeerida, kuna meie sõnastiku veerg on juba osaliselt koondatud — häshtfunktsioonide väärtusi saab kiiremini arvutada ja umbkaudu leida bucket, kuhu järgmine rida paigutada. Samuti on võimalik spetsialiseerida mõningaid agregaatfunktsioone, näiteks uniq, sest sellesse saab saata ainult sõnastiku, jättes positsioonid puutumatuks — nii töötab kõik kiiremini. Need kaks optimeerimist on me juba ClickHouse'i lisanud.

Ent mis saab siis, kui loome veeru meie andmetüübiga ja sisestame sellesse palju halbu erinevaid ridu? Kas meie mälu ei ületata? Ei, ClickHouse'is on selleks kaks spetsiaalset seadet. Esimene on low_cardinality_max_dictionary_size. See on maksimaalne sõnastiku suurus, mis saab kettale salvestada. Sisestamine toimub järgmiselt: kui me andmeid sisestame, tuleb meile ridade voog, millest me kujundame suure ühis sõnastiku. Kui sõnastik muutub suuremaks kui seadistuse väärtus, salvestame praeguse sõnastiku kettale, samal ajal kui ülejäänud read — jäävad kuhugi „kõrvale“, indeksite kõrvale. Lõpptulemusena ei arvuta me kunagi suurt sõnastikku uuesti ja ei saa mälu probleemidega kokku.

Teine seadistus kannab nime low_cardinality_use_single_dictionary_for_part. Kujutage ette, et eelmisel skeemil, kui me andmeid sisestasime, meie sõnastik ületas piiri ja me salvestasime selle kettale. Küsimus on, miks mitte luua nüüd veel üks täiesti sama sõnastik?

Kui see jälle üle voolab, salvestame selle uuesti kettale ja hakkame kolmandat looma. See seadistus lülitab selle võimaluse vaikeolekus välja.

Tegelikult võivad palju sõnastikke olla kasulikud, kui me tahame sisestada mingit rida, kuid juhuslikult sisestame "prügi". Ütleme, et kõigepealt sisestasime halvad read ja siis head. Siis jaguneb sõnastik paljudeks väikesteks sõnastikeks. Osad neist sisaldavad "prügi", kuid viimased sisaldavad häid ridu. Ja kui me lugedes, ütleme, ainult viimast granulaati, töötab kõik ka kiiresti.

Enne kui räägime LowCardinality eeliste kohta, ütlen kohe, et tõenäoliselt ei suuda me andmeid ketast vähendada (kuigi see võib juhtuda), sest ClickHouse tihendab andmeid. Vaikimisi on olemas variant — LZ4. Samuti saab kasutada ZSTD tihendust. Kuid mõlemad algoritmid rakendavad juba sõnaraamiga tihendust, seega meie väline sõnaraamat ClickHouse'is ei aita eriti.

Kuna ma ei soovi olla põhjendamatu, võtsin mõned andmed metrikast — String, LowCardinality(String) ja Enum — ning salvestasin need erinevatesse andmetüüpidesse. Saime kolm veergu, kus on üks miljard rida. Esimeses veerus, CodePage, on kokku 62 väärtust. Ja on näha, et LowCardinality(String) tihendas neid paremini. String on veidi halvem, kuid see on tõenäoliselt tingitud sellest, et read on lühikesed, me hoiame nende pikkusi ja need võtavad palju ruumi, halvemini tihendatud.

Kui võtta PhoneModel, siis neid on 48 tuhat — juba rohkem, ja erinevused String ja LowCardinality(String) vahel on peaaegu olematud. URL-ide puhul säästsime samuti vaid 2 GB — arvan, et sellele ei tohiks toetuda.

Töökiirus hindamine

Viide slaidilt

Nüüd hindame töökiirust. Selle hindamiseks kasutasin New Yorgi taksireiside andmestikku. saadaval GitHubis. Seal on veidi üle miljardi sõidu. Seal on näidatud asukoht, sõidu algus- ja lõppaeg, makseviis, reisijate arv ja isegi takso tüüp — roheline, kollane ja Uber.

Esimene päring, mille ma tegin, oli üsna lihtne — küsisin, kust sagedamini taksot tellitakse. Selleks tuleb võtta asukoht, kust takso telliti, kasutada GROUP BY-d ja lugeda funktsiooni count. ClickHouse annab midagi.

Küsimuse töötlemise kiirusest mõõtmiseks lõin kolm tabelit ühesuguste andmetega, kuid kasutasin meie algasukoha jaoks kolme erinevat andmetüüpi — String, LowCardinality ja Enum. LowCardinality ja Enum osutusid viiekordselt kiiremaks kui String. Enum on kiirem, sest töötab numbritega. LowCardinality on samuti efektiivne, kuna on rakendatud GROUP BY optimeerimist.

Teeme päringu veel keerulisemaks — küsime, kus asub kõige populaarsem park New Yorgis. Jällegi mõõdame seda selle järgi, kus sagedamini taksosid tellitakse, kuid filtreerime välja ainult need asukohad, kus on sõna „park“. Lisame ka funktsiooni like.

Vaadates aega, näeme, et Enum on äkitselt hakanud aeglustuma. Tegelikult töötab see isegi aeglasemalt kui tavaline String andmetüüp. See juhtub, kuna funktsioon like ei ole Enum-i jaoks üldse optimeeritud. Peame meie enum stringid tavalistesse stringidesse konverteerima — see tähendab, et teeme rohkem tööd. LowCardinality(String) ei ole ka vaikimisi optimeeritud, kuid seal toimub like sõnastiku peal, seega kiireneb päring võrreldes Stringiga.

Enumiga töötamisel on veelgi globaalne probleem. Kui me tahame seda optimeerida, peame seda tegema igas koodikohas. Oletame, et oleme kirjutanud uue funktsiooni — peame kindlasti leidma optimeerimise Enum-i jaoks. LowCardinality on aga kõik vaikimisi optimeeritud.

Vaadakem viimast päringut, mis on kunstlikum. Arvutame lihtsalt meie asukoha hash-funktsiooni. Hash-funktsioon — üsna aeglane päring, seda arvutatakse pikka aega, seega kõik aeglustub umbes kolm korda.

LowCardinality töötab endiselt kiiremini, kuigi siin ei ole filtreerimist. See juhtub, kuna meie funktsioonid töötavad ainult sõnastiku peal. Hash-funktsioonil on üks argument — see saab töödelda vähem andmeid ja samuti võib tagastada LowCardinality.

Meie globaalne plaan on saavutada töökiirus, mis ei oleks madalam kui String igas olukorras, ja säilitada kiirus. Ja võib-olla asendame kunagi Stringi LowCardinality'ga, te uuendate ClickHouse'i ja teil hakkab kõik natuke kiiremini toimima.

Allikas: habr.com