Strings optimisation in ClickHouse. Yandex report

Analüütiline andmebaas ClickHouse töötleb erinevaid stringe, tarbides ressursse. Süsteemi töö kiirus on pidevalt paranenud tänu uutele optimeerimistele. ClickHouse arendaja Nikolai Kočetov räägib andmetüübist string, sealhulgas uuest tüübist LowCardinality, ja selgitab, kuidas kiirendada tööd stringidega.

— Alustame sellest, kuidas stringe salvestada.



Meil on stringi andmetüübid. String sobib vaikimisi väga hästi ja seda tuleks kasutada peaaegu alati. Sellel on väike overhead — 9 baiti ühe stringi kohta. Kui soovime, et stringide suurus oleks fikseeritud ja eelnevalt teada, on parem kasutada FixedString. Sellesse saab määrata vajaliku bitti arvu, see sobib IP-aadresside või hash-funktsioonide jaoks.

Loomulikult võib mõnikord miski pidurdada. Oletame, et teete päringu tabelisse. ClickHouse loeb üsna suurt andmemassi, ütleme kiirusel 100 GB/s, samas stringe töödeldakse vähe. Meil on kaks tabelit, mis sisaldavad peaaegu samu andmeid. Teisest tabelist loeb ClickHouse andmeid suurema kiirusel, kuid stringide arvu loetakse kolm korda vähem sekundis.

Kui vaatame kokku surutud andmete suurust, selgub, et see on peaaegu sama. Tegelikult on tabelites salvestatud samad andmed — esimesed miljard numbrit — lihtsalt esimeses veerus on nad salvestatud UInt64 kujul, teises aga String. Sel põhjusel loetakse teises päringus andmed ketas pikemalt ja neid dekompressitakse.

Siin on teine näide. Oletame, et on eelnevalt teadaolev hulk stringe, mis on piiratud konstantsusega 1000 või 10 000 ning praktiliselt kunagi ei muutu. Selle juhtumi jaoks sobib meile andmetüüp Enum, ClickHouse'is on neid kaks — Enum8 ja Enum16. Enum'st hoidmise tõttu töötleme päringuid kiiresti.

ClickHouse'is on kiirus täiustused GROUP BY, IN, DISTINCT ja optimeerimised teatud funktsioonide jaoks, näiteks fikseeritud stringiga võrdlemiseks. Loomulikult ei muundata stringi numbreid, vaid vastupidi, fikseeritud string muudetakse Enum väärtuseks. Pärast seda võrreldakse kõike kiiresti.

Kuid on ka miinuseid. Isegi kui me teame stringide täpset hulka, peab see mõnikord täiendama. Kui uus string tuleb, peame tegema ALTER.

ALTER Enumi ClickHouse on optimaalne. Me ei kirjutame andmeid ketasse, kuid ALTER võib aeglustuda, kuna Enum struktuurid on salvestatud tabeli endasse. Seetõttu peame ootama lugemis запросы tabelist, näiteks.

Küsimus on, kas seda saab paremaks teha? Tõenäoliselt jah. Enum struktuuri võib salvestada mitte tabeli skeemi, vaid ZooKeeperisse. Kuid võivad tekkida sünkroniseerimisega seotud probleemid. Näiteks võib üks replik saada andmed, teine mitte, ja kui sellel on vana Enum, siis midagi läheb katki. (ClickHouse'is oleme peaaegu lõpetanud blokeerimata ALTER päringud. Kui saame need täielikult valmis, ei pea ootama lugemis запросы.)

ALTER Enumiga vaevlemise vältimiseks saab kasutada ClickHouse'i väliseid sõnastikke. Tuletan meelde, et see on key-value andmestruktuur ClickHouse'is, mille abil saab andmeid välisest allikast, näiteks MySQL tabelitest.

ClickHouse'i sõnastikus hoiame mitmeid erinevaid stringe, ja tabelis on nende identifikaatorid numbrite kujul. Kui peame saama stringi, kutsume välja dictGet funktsiooni ja töötame sellega. Seejärel ei pea me tegema ALTER't. Kui midagi on Enumisse lisada, siis sisestame selle samasse MySQL tabelisse.

Kuid siin kerkivad esile teised probleemid. Esiteks, ebamugav süntaks. Kui soovime saada stringi, peame kutsuma dictGet'i. Teiseks, teatud optimeerimiste puudumine. Konstantse stringiga võrdlemine sõnastikes ei ole nii kiire.

Samuti võivad esineda probleemid värskendamisega. Oletame, et küsisime stringi vahekäesõnastikust, kuid see ei jõudnud vahekäesse. 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 neid. Nii et miks mitte hoida sõnastikke kohalikult? Pole sünkroniseerimist — pole probleeme. Sõnastikku saab hoida lokaalselt ketta tükis. See tähendab, et tegime Insert, salvestasime sõnastiku. Kui töötame andmetega mälus, võime salvestada sõnastiku kas andmeplokki, veeru tüki või mõnda muu vahemälu, et arvutusi kiirendada.

Stringide sõnastikukood

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

Slaidil on kaks veergu. Paremal pool hoitakse read standardses vormingus, String tüüpi. Selgelt on näha, et need on teatud mobiiltelefonide mudelid. Vasakul on täpselt sama veerg, kuid LowCardinality tüübis. See koosneb sõnastikust, kus on palju erinevaid stringe (paremal pool olevate veergude stringid) ja positsioonide nimekirjast (rea numbrid).

Nende kahe struktuuri abil on võimalik taastada algne veerg. Samuti on olemas tagurpidi indeks — hash-tabel, mis aitab leida rea positsiooni sõnastikus. See on vajalik teatud päringute kiirendamiseks. Näiteks, kui tahame 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, string või nende Nullable variant.

LowCardinality eripära on see, et see võib mõnedes funktsioonides salvestuda. Slaidil on näha päringu näide. Esimeses reas lõin LowCardinality String tüübiga veeru ja nimetasime selle S-ks. Seejärel küsisin selle nime — ClickHouse ütles, et see on LowCardinality String. Kõik on õige.

Kolmas rida on peaaegu sama, aga oleme kutsunud välja length funktsiooni. ClickHouse'is tagastab length funktsioon andmetüübi UInt64. Kuid meil on saanud LowCardinality UInt64. Mis on selle mõte?

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

Võivad olla ka teised optimeerimised, näiteks lihtsa vahemälu lisamine. Funktsiooni väärtuse arvutamisel on võimalik see meelde jätta ja luua sarnane, mitte arvutada uuesti.

Samuti võib olla tehtud GROUP BY optimeerimine, sest meie sõnastiku veerg on juba osaliselt agreggeeritud — häshefunktsiooni väärtuste arvutamine ja sobiva bucket'i leidmine järgmise rea jaoks on kiirem. Samuti saab spetsialiseerida mõningaid agregaatfunktsioone, näiteks uniq, kuna sellesse saab saata ainult sõnastiku, samas kui positsioonid jäävad puutumatuks — siis töötab kõik kiiremini. Esimesed kaks optimeerimist oleme juba ClickHouse'i lisanud.

Entä, jos luomme sarakkeen omalle datatyypillemme ja syötämme siihen paljon erilaisia huonoja merkkijonoja? Eikö meidän muistimme lopu? Ei, ClickHouse:ssa on tähän kaksi erityistä asetusta. Ensimmäinen on low_cardinality_max_dictionary_size. Tämä on sanakirjan maksimikoko, joka voidaan tallentaa levylle. Tietojen syöttäminen tapahtuu näin: kun syötämme tietoja, saamme virran merkkijonoja, joista muodostamme suuren yhteisen sanakirjan. Jos sanakirja kasvaa suuremmaksi kuin asetuksen arvo, tallennamme nykyisen sanakirjan levylle ja muut merkkijonot johonkin 'sivulle', indeksien viereen. Täten emme koskaan laske suurta sanakirjaa uudelleen emmekä kohtaa muistiongelmia.

Toinen asetus on nimeltään low_cardinality_use_single_dictionary_for_part. Kuvittele, että edellisessä schema:ssa, kun syötimme tietoja, sanakirjamme täyttyi ja tallensimme sen levylle. Herää kysymys, miksi emme nyt voisi luoda vielä yhtä samanlaista sanakirjaa?

Kun se täyttyy, tallennamme sen taas levylle ja aloitamme kolmannen sanakirjan muodostamisen. Tämä asetus estää juuri tämän mahdollisuuden oletusarvoisesti.

Itse asiassa monet sanakirjat voivat olla hyödyllisiä, jos haluamme syöttää tietyn määrän merkkijonoja, mutta vahingossa syötimme 'roskaa'. Sanotaan, että ensin syötimme huonoja merkkijonoja ja sitten hyviä. Tällöin sanakirja jakautuu moneen pieneen sanakirjaan. Osa niistä sisältää 'roskaa', mutta viimeiset sisältävät hyviä merkkijonoja. Ja jos luemme vain viimeistä fragmenttia, kaikki toimii nopeasti.

Ennen kuin puhumme LowCardinality:n eduista, sanon heti, että tuskin saamme aikaan vähennystä tiedoissa levyllä (vaikka se voi tapahtua), koska ClickHouse pakkaa tiedot. On oletusvaihtoehto — LZ4. Voimme myös pakata ZSTD:n avulla. Mutta molemmat algoritmit toteuttavat jo sanakirjapakkausta, joten ulkoinen sanakirjamme ClickHouse:ssa ei ole kovin hyödyllinen.

Kuna ei taha olla sõnaline, tõin mõned andmed metrikast — String, LowCardinality(String) ja Enum — ning salvestasin need erinevatesse andmetüüpidesse. Saime kolm veergu, kus on kirjas miljard rida. Esimeses veerus, CodePage, on kokku 62 väärtust. On näha, et LowCardinality(String) komprimeeris need paremini. Stringi tulemus on veidi kehvem, kuid see on tõenäoliselt tingitud lühikestest ridadest; me salvestame nende pikkusi ja need võtavad palju ruumi, seega komprimeeruvad halvasti.

Kui võtta PhoneModel, on neid 48 tuhat — juba rohkem, ja erinevused Stringi ja LowCardinality(String) vahel on peaaegu olematud. URL-i puhul säästsime ka vaid 2 GB — arvan, et sellele ei tasu loota.

Töökiirus

Link slaidilt

Nüüd hindame töökiirus. Selle hindamiseks kasutasin taksireiside andmestikku New Yorgis. See saadaval on GitHubis. Andmestikus on veidi üle miljardi reisi. Seal on kajastatud asukoht, sõiduki algus- ja lõppaeg, makseviis, reisijate arv ja isegi taksotüüp — roheline, kollane ja Uber.

Tegin esimese päringu üsna lihtsaks — küsisin, kust tellitakse kõige rohkem taksosid. Selleks oli vaja võtta asukoht, kust taksot telliti, teha selle põhjal GROUP BY ja lugeda count-funktsiooni. Siin on ClickHouse midagi välja andnud.

Küsimise töötlemise kiirusest mõõtmiseks lõin kolm tabelit, kus on samad andmed, kuid kasutasin meie algasukoha jaoks kolme erinevat andmetüüpi — String, LowCardinality ja Enum. LowCardinality ja Enum osutusid viis korda kiiremateks kui String. Enum on kiire, kuna töötab numbritega. LowCardinality on kiire, kuna realizatsioon on optimeeritud GROUP BY jaoks.

Komplektime päringut veelgi keerulisemaks — küsime, kus asub New Yorgi kõige populaarsem park. Taaskord mõõdame seda selle põhjal, kust taksosid kõige sagedamini tellitakse, kuid filtrime ainult need asukohad, kus on sõna "park". Samuti lisame funktsiooni like.

Vaadates aega — näeme, et Enum hakkas ootamatult aeglustuma. Tõsi, see töötab isegi aeglasemalt kui tavaline andmetüüp String. See juhtub seetõttu, et funktsioon like ei ole Enum'i jaoks üldse optimeeritud. Peame muundama meie Enum'i stringid tavalisteks stringideks — teeme rohkem tööd. LowCardinality(String) ei ole ka vaikimisi optimeeritud, kuid seal töötab like sõnaraamatute kallal, seetõttu kiireneb päring võrreldes Stringiga.

Enumiga töötamisel on üks suurem probleem. Kui me soovime seda optimeerida, peame seda tegema igas koodikohtas. Oletame, et oleme kirjutanud uue funktsiooni — peame kindlasti välja mõtlema Enum'i optimeerimise. Madala kardinaalsusega on kõik vaikimisi optimeeritud.

Vaatame viimast päringut, mis on rohkem kunstlik. Me lihtsalt arvutame meie asukoha hash-funktsiooni. Hash-funktsioon on üsna aeglane päring, see võtab kaua aega, seega kõik aeglustub kolm korda.

Madala kardinaalsusega töötab endiselt kiiremini, kuigi siin ei ole filtreerimist. See juhtub seetõttu, et meie funktsioonid töötavad ainult sõnastiku üle. Hash-funktsiooni arvutamise funktsioonil on üks argument — see saab töödelda vähem andmeid ja võib samuti tagastada madala kardinaalsuse.

Meie globaalne plaan on saavutada kiirus, mis pole madalam kui String igas olukorras, ja säilitada kiirus. Ja võib-olla asendame mingi päev String'i madala kardinaalsusega, värskendate ClickHouse'i ja kõik töötab natuke kiiremini.

Allikas: habr.com