Lielākajai daļai uzņēmumu ar kaut cik ilgu darbības vēsturi ir uzkrāti gadiem ilgi darījumu dati, kas praktiski nav izmantojami vaicājumiem — tie ir ieslodzīti OLTP datubāzē, kas aizrijas ar analītiskiem vaicājumiem, vai vēl sliktāk, guļ aukstās rezerves kopijās, ko neviens negrib atjaunot. Padarīt šo vēsturi par kaut ko, ko datu komanda tiešām var izmantot, vispirms ir dizaina jautājums un tikai pēc tam — migrācijas jautājums.
Kāpēc tieši ClickHouse
Kolonnu veida glabāšana un agresīva saspiešana padara ClickHouse par lielisku risinājumu tieši šāda veida slodzei: lieli apjomi vēsturisku, gandrīz tikai pievienojamu (append-only) datu, kurus vaicā ar agregācijām, nevis atsevišķu rindu meklējumiem. Vaicājumi, kas rindu orientētā OLTP datubāzē pie miljardiem rindu ilgtu minūtēm, kolonnu dzinējam pārveidotiem datiem parasti izpildās dažu sekunžu laikā — ar nosacījumu, ka shēma tiešām ir veidota atbilstoši tam, kā dati tiek vaicāti, nevis vienkārši kopēta no avota shēmas.
Pieeja, kas tiešām darbojas
- Sāc ar to, kas tiešām tiek vaicāts. Noliktavā ievietot pilnīgi visu bez izšķiršanas ir lēnāk jāveido un grūtāk jāvalidē nekā noliktavot to, par ko biznesam tiešām jāspēj uzdot jautājumus. Pirms shēmas izstrādes parunājies ar cilvēkiem, kas šos vaicājumus veiks.
- Projektē pēc vaicājumu modeļiem, nevis pēc avota shēmas. OLTP shēma tika normalizēta darījumu integritātes, nevis analītiskā ātruma labad. ClickHouse noliktava parasti tiek apzināti denormalizēta, un kārtošanas atslēgas (ClickHouse
ORDER BY) izvēle ietekmē vaicājumu veiktspēju tikpat lielā mērā, cik jebkura indeksa izvēle tradicionālā datubāzē. - Sadali partīcijās pēc laika datiem, kuriem ir dabiska laika dimensija — tas nodrošina ātru izpildi vaicājumiem, kas skar tikai nesenus datus, un padara dzīves cikla pārvaldību (veco partīciju arhivēšanu vai dzēšanu) par vienkāršu darbību, nevis par visas tabulas operāciju.
- Ielādē datus (backfill) pa daļām un padari to atsākamu. Desmit gadu vēsturi nevar pārvietot vienā transakcijā. Sadali to partijās, fiksē progresu ar kontrolpunktiem un validē katru partiju pret avotu, pirms ķeries pie nākamās — ne tikai pēc rindu skaita, bet ar saskaņotām summām un izlases veida rindu līmeņa salīdzinājumiem.
- Izlem, cik svaigiem jābūt datiem noliktavā turpmāk. Pakešu (batch) ETL pēc grafika ir vienkāršāk izveidot un uzturēt; change-data-capture straumēšana ir sarežģītāka, taču notur noliktavu tuvu reālajam laikam. Izvēlies, pamatojoties uz to, ko tiešām prasa analītika, nevis pēc noklusējuma.
Vienā no nesenajiem projektiem šī pieeja pārvērta vairāk nekā desmit gadu loģistikas uzņēmuma vēsturiskos ierakstus — iepriekš izkaisītus pa vairākām sistēmām tā, ka jebkas vairāk par pamata meklēšanu bija nepraktisks — vienotā noliktavā, kurā analītiķi varēja vaicāt tieši, ar atbildes laikiem, kas pietiekami ātri interaktīviem informācijas paneļiem, nevis nakts pakešu atskaitēm.
Kļūdas, kas parādās vēlāk, nevis uzreiz
- Tiešā normalizētās shēmas kopēšana — dati ielādēsies bez problēmām, taču veiktspēja kritīsies, tiklīdz kāds pār tiem palaidīs reālu agregāciju.
- GROUP BY atslēgu kardinalitātes ignorēšana, izvēloties kārtošanas atslēgu — šī neatbilstība ir viens no biežākajiem iemesliem, kāpēc ClickHouse noliktava tehniski strādā, bet ir vilinoši lēna.
- Nav dzīves cikla plāna. Desmit gadu datiem nepieciešama politika par to, kas notiek ar vecākajām partīcijām — TTL noteikumi, līmeņota (tiered) glabāšana vai apzināts lēmums glabāt visu mūžīgi — pieņemta jau iepriekš, nevis kā ārkārtas situācija brīdī, kad glabāšanas izmaksas parādās kāda redzeslokā.
Galvenās atziņas
- Projektē noliktavas shēmu atbilstoši tam, kā tā tiks vaicāta, nevis atbilstoši avota OLTP shēmai.
- Sadali partīcijās pēc laika un apzināti izvēlies kārtošanas atslēgu — tas ir lielākais atsevišķais veiktspējas ietekmes faktors.
- Ielādē datus (backfill) atsākamās partijās ar reālu saskaņošanu, nevis tikai rindu skaita pārbaudi.
- Izlem par datu dzīves cikla politiku, pirms glabāšanas izmaksas šo lēmumu uzspiež vēlāk.