Transloĝiĝo al ClickHouse: 3 jarojn poste

Antaŭ tri jaroj Viktor Tarnavsky kaj Alexey Milovidov de Yandex sur la scenejo HighLoad++ rakontis, kiom bona ClickHouse estas, kaj kiel ĝi ne malrapidiĝas. Kaj sur la sekva etapo estis Aleksandro Zaitsev с raporto pri translokiĝo al KlakuDomo de alia analiza DBMS kaj kun la konkludo ke KlakuDomo, kompreneble, bona, sed ne tre oportuna. Kiam en 2016 la kompanio LifeStreet, kie Aleksandro laboris tiam, tradukis la multpetabajtan analizan sistemon en KlakuDomo, ĝi estis fascina "flava brika vojo", plena de nekonataj danĝeroj - KlakuDomo tiam ĝi aspektis kiel minkampo.

Tri jaroj poste KlakuDomo fariĝis multe pli bona - dum ĉi tiu tempo, Aleksandro fondis la kompanion Altinity, kiu ne nur helpas translokiĝi al KlakuDomo dekoj da projektoj, sed ankaŭ plibonigas la produkton mem kune kun kolegoj de Yandex. Nun KlakuDomo ankoraŭ ne senzorga promeno, sed ne plu minkampo.

Aleksandro estis implikita en distribuitaj sistemoj ekde 2003, evoluigante grandajn projektojn sur MySQL, Orakolo и Vertikalo. Fine HighLoad++ 2019 Aleksandro, unu el la pioniroj de la uzo KlakuDomo, diris kio ĉi tiu DBMS estas nun. Ni lernos pri la ĉefaj trajtoj KlakuDomo: kiel ĝi diferencas de aliaj sistemoj kaj en kiuj kazoj estas pli efika uzi ĝin. Uzante ekzemplojn, ni konsideru freŝajn kaj projekt-provitajn praktikojn por konstrui sistemojn bazitajn sur KlakuDomo.

Retrospektivo: kio okazis antaŭ 3 jaroj

Antaŭ tri jaroj ni translokigis la kompanion LifeStreet sur KlakuDomo de malsama analitika datumbazo, kaj la reklam-reto-analitika migrado aspektis jene:

• Junio ​​2016. En Malferma Fonto aperis KlakuDomo kaj komencis nian projekton;
• Aŭgusto. Pruvo De Koncepto: granda reklama reto, infrastrukturo kaj 200-300 terabajtoj da datumoj;
• oktobro. Unuaj produktaddatenoj;
• decembro. Plena ŝarĝo de produktoj - 10-50 miliardoj da eventoj tage.
• Junio ​​2017. Sukcesa migrado de uzantoj al KlakuDomo, 2,5 petabajtoj da datumoj sur aro de 60 serviloj.

Dum la migrado progresis, la kompreno kreskis tion KlakuDomo estas bona sistemo kun kiu estas agrabla labori, sed ĉi tio estas interna projekto de Yandex. Tial estas nuancoj: Yandex unue traktos siajn proprajn internajn klientojn kaj nur tiam la komunumon kaj la bezonojn de eksteraj uzantoj, dum ClickHouse tiam ne atingis la entreprenan nivelon en multaj funkciaj areoj. Do en marto 2017, ni fondis Altinity por fari KlakuDomo eĉ pli rapide kaj pli oportuna ne nur por Yandex, sed ankaŭ por aliaj uzantoj. Kaj nun ni:

• Ni trejnas kaj helpas konstrui solvojn bazitajn sur KlakuDomo por ke klientoj ne plenigu ŝvelaĵojn, kaj por ke la solvo eventuale funkciu;
• Ni provizas 24/7 subtenon KlakuDomo- instalaĵoj;
• Ni evoluigas niajn proprajn ekosistemprojektojn;
• Aktive engaĝiĝu al mi mem KlakuDomo, respondante al petoj de uzantoj, kiuj volas vidi iujn funkciojn.

Kaj kompreneble ni helpas translokiĝi al KlakuDomo с MySQL, Vertikalo, plejsanktejo, Verda pruno, Redŝovo kaj aliaj sistemoj. Ni estis implikitaj en ampleksa vario de translokiĝoj kaj ili ĉiuj sukcesis.

Kial eĉ moviĝi al KlakuDomo

Ne malrapidiĝas! Ĉi tio estas la ĉefa kialo. KlakuDomo - tre rapida datumbazo por malsamaj scenaroj:

Hazardaj citaĵoj de homoj kun kiuj laboras KlakuDomo.

Skalebleco. En iu alia datumbazo, vi povas atingi bonan rendimenton sur unu aparataro, sed KlakuDomo vi povas grimpi ne nur vertikale, sed ankaŭ horizontale per simple aldonado de serviloj. Ne ĉio funkcias tiel glate kiel ni ŝatus, sed ĝi funkcias. Vi povas kreskigi la sistemon dum via komerco kreskas. Gravas, ke ni ne estas limigitaj de la decido nun kaj ĉiam ekzistas la potencialo por disvolviĝo.

porteblo. Ne estas alligiteco al unu afero. Ekzemple, kun Amazon RedShift malfacile moviĝi ien. A KlakuDomo vi povas instali ĝin sur via tekkomputilo, servilo, disfaldi ĝin al la nubo, iri al Kubernetoj - ne estas limigoj pri funkciado de la infrastrukturo. Ĉi tio estas oportuna por ĉiuj, kaj ĉi tio estas granda avantaĝo, pri kiu multaj aliaj similaj datumbazoj ne povas fanfaroni.

Fleksebleco. KlakuDomo ne ĉesas ĉe unu afero, ekzemple, Yandex.Metrica, sed estas disvolvita kaj uzata en pli kaj pli diversaj projektoj kaj industrioj. Ĝi povas esti vastigita aldonante novajn funkciojn por solvi novajn problemojn. Ekzemple, oni kredas, ke stoki protokolojn en datumbazo estas malbona maniero, do por tio ili elpensis Elasta esploro. Sed danke al la fleksebleco KlakuDomo, vi ankaŭ povas konservi ŝtipojn en ĝi, kaj ofte ĉi tio estas eĉ pli bona ol en Elasta esploro - en KlakuDomo ĝi postulas 10 fojojn malpli da fero.

Senpaga Malferma Fonto. Vi ne devas pagi por io ajn. Ne necesas negoci permeson por meti la sistemon sur vian tekkomputilon aŭ servilon. Ne estas kaŝitaj kotizoj. Samtempe, neniu alia Open Source datumbaza teknologio povas konkuri rapide kun KlakuDomo. MySQL, MariaDB, Greenplum - ili ĉiuj estas multe pli malrapidaj.

Komunumo, stirado kaj amuza. Ĉe KlakuDomo bonega komunumo: renkontiĝoj, babiloj kaj Alexey Milovidov, kiu ŝarĝas nin ĉiujn per sia energio kaj optimismo.

Moviĝante al ClickHouse

Por ŝanĝi al KlakuDomo kun io, vi bezonas nur tri aferojn:

• Komprenu limojn KlakuDomo kaj por kio ĝi ne taŭgas.
• Uzu la avantaĝojn teknologio kaj ĝiaj plej grandaj fortoj.
• Eksperimento. Eĉ sciante kiel ĝi funkcias KlakuDomo, ne ĉiam eblas antaŭdiri kiam ĝi estos pli rapida, kiam ĝi estos pli malrapida, kiam ĝi estos pli bona, kaj kiam ĝi estos pli malbona. Do provu.

La problemo de moviĝado

Estas nur unu "sed": se vi moviĝas al KlakuDomo de io alia, tiam kutime io misfunkcias. Ni kutimas iujn praktikojn kaj aferojn, kiuj funkcias en nia plej ŝatata datumbazo. Ekzemple, iu ajn kun kiu laboras SQL-datumbazoj konsideras la sekvan aron de funkcioj deviga:

• transakcioj;
• limoj;
• kohereco;
• indeksoj;
• Ĝisdatigi/Forigi;
• NULLoj;
• milisekundoj;
• aŭtomataj tipkonvertiĝoj;
• multoblaj kunigoj;
• arbitraj vandoj;
• iloj pri administrado de clusteroj.

Rekrutado estas deviga, sed antaŭ tri jaroj en KlakuDomo estis neniu el ĉi tiuj trajtoj! Nun malpli ol duono de la nerealigitaj restas: transakcioj, limoj, Konsistenco, milisekundoj kaj tipa casting.

Kaj la ĉefa afero estas, ke en KlakuDomo iuj normaj praktikoj kaj aliroj ne funkcias aŭ ne funkcias kiel ni kutimas. Ĉio, kio aperas en KlakuDomo, respondas al "klaku domo vojo", t.e. funkcioj estas diferencaj de aliaj DBoj. Ekzemple:

• Indeksoj ne estas elektitaj, sed preterlasitaj.
• Ĝisdatigi/Forigi ne sinkrona, sed nesinkrona.
• Estas pluraj kuniĝoj, sed ne ekzistas konsultplanilo. Kiel ili tiam estas ekzekutitaj estas ĝenerale ne tre klara por homoj de la datumbaza mondo.

ClickHouse Scenaroj

En 1960, usona matematikisto de hungara deveno WignerEP skribis artikolonLa neracia efikeco de matematiko en la natursciencoj”(“La nekomprenebla efikeco de matematiko en la natursciencoj”) ke la mondo ĉirkaŭ ni estas ial bone priskribita de matematikaj leĝoj. Matematiko estas abstrakta scienco, kaj fizikaj leĝoj esprimitaj en matematika formo ne estas bagatelaj, kaj WignerEP emfazis, ke tio estas tre stranga.

El mia vidpunkto, KlakuDomo - la sama strangaĵo. Por reformuli Wigner, ni povas diri ĉi tion: mirinda estas la neimagebla efikeco KlakuDomo en ampleksa vario de analizaj aplikoj!

Ekzemple, ni prenu Realtempa Datuma Stokejo, en kiu datumoj estas ŝarĝitaj preskaŭ senĉese. Ni volas ricevi petojn de li kun dua prokrasto. Bonvolu uzi KlakuDomoĉar ĝi estis desegnita por ĉi tiu scenaro. KlakuDomo jen kiel ĝi estas uzata ne nur en la reto, sed ankaŭ en merkatado kaj financa analizo, AdTech, same kiel en Detekto de fraŭdon. EN Realtempa Datuma Stokejo kompleksa strukturita skemo kiel "stelo" aŭ "neĝfloko" estas uzata, multaj tabeloj kun JOIN (foje multoblaj), kaj la datumoj estas kutime konservitaj kaj ŝanĝitaj en iuj sistemoj.

Ni prenu alian scenaron - Tempo-Serio: monitoraj aparatoj, retoj, uzadostatistikoj, interreto de aferoj. Ĉi tie ni renkontiĝas kun sufiĉe simplaj eventoj ordigitaj ĝustatempe. KlakuDomo ne estis origine evoluigita por tio, sed montris sin bone, do grandaj kompanioj uzas KlakuDomo kiel deponejo por monitorado de informoj. Por vidi ĉu ĝi taŭgas KlakuDomo por tempo-serio, ni faris komparnormon bazitan sur la aliro kaj rezultoj InfluxDB и TimecaleDB — specialigita tempo-serio datumbazoj. Ĝi rezultis, tio KlakuDomo, eĉ sen optimumigo por tiaj taskoj, gajnas sur eksterlanda kampo:

В tempo-serio kutime oni uzas mallarĝan tabelon - pluraj malgrandaj kolumnoj. Multaj datumoj povas veni de monitorado - milionoj da registroj sekundo - kaj ili kutime venas en malgrandaj enmetoj (Reala tempo fluanta). Sekve, ni bezonas malsaman enmeti skripton, kaj la demandojn mem - kun kelkaj specifaĵoj propraj.

Log Management. Kolekti protokolojn en la datumbazo estas kutime malbona, sed en KlakuDomo ĉi tio povas esti farita per kelkaj komentoj kiel priskribite supre. Multaj kompanioj uzas KlakuDomo nur por ĉi tio. En ĉi tiu kazo, plata larĝa tablo estas uzata, kie ni stokas la tutajn ŝtipojn (ekzemple, en la formo JSON), aŭ tranĉita en pecojn. Datumoj kutime estas ŝarĝitaj en grandaj aroj (dosieroj), kaj ni serĉas iun kampon.

Por ĉiu el tiuj funkcioj, specialigitaj datumbazoj estas kutime uzitaj. KlakuDomo oni povas fari ĉion kaj tiel bone, ke ĝi preterpasas ilin en agado. Ni nun rigardu pli detale tempo-serio skripto, kaj kiel "kuiri" KlakuDomo sub ĉi tiu scenaro.

Tempo-Serio

Ĉi tiu estas nuntempe la ĉefa scenaro por kiu KlakuDomo konsideris la norman solvon. Tempo-serio estas aro de eventoj ordigitaj en tempo, reprezentante ŝanĝojn en iu procezo dum tempo. Ekzemple, ĉi tio povus esti la korfrekvenco tage aŭ la nombro da procezoj en la sistemo. Ĉio, kio donas tempon kun iuj dimensioj, estas tempo-serio:

Plej multaj el ĉi tiuj eventoj venas de monitorado. Ĉi tio povas esti ne nur interreta monitorado, sed ankaŭ realaj aparatoj: aŭtoj, industriaj sistemoj, IoT, industrioj aŭ senpilotaj taksioj, en kies kofron jam metas Yandex KlakuDomo-servilo.

Ekzemple, estas kompanioj kiuj kolektas datumojn de ŝipoj. Ĉiujn malmultajn sekundojn, sensiloj de kontenera ŝipo sendas centojn da malsamaj mezuradoj. Inĝenieroj studas ilin, konstruas modelojn kaj provas kompreni kiom efike la ŝipo estas uzata, ĉar kontenera ŝipo ne devus stari senmova eĉ unu sekundo. Ajna malfunkcio estas mono malŝparo, do gravas antaŭdiri la itineron por ke parkado estu minimuma.

Nun estas kresko de fakaj datumbazoj kiuj mezuras tempo-serio. Sur la retejo DB-Motoroj iel malsamaj datumbazoj estas vicigitaj, kaj ili povas esti viditaj laŭ tipo:

La plej rapida kreskanta tipo estas temposerios. Grafikaj datumbazoj ankaŭ kreskas, sed temposerios kreskis pli rapide dum la lastaj jaroj. Tipaj reprezentantoj de ĉi tiu familio de datumbazoj estas InfluxDB, Prometeo, KDB, TimecaleDB (konstruita sur PostgreSQL), solvoj el amazono. KlakuDomo povas esti uzata ĉi tie ankaŭ, kaj estas uzata. Mi donu al vi kelkajn publikajn ekzemplojn.

Unu el la pioniroj estas la kompanio CloudFlare (CDNprovizanto). Ili monitoras sian CDN tra KlakuDomo (DNS-petoj, HTTP-petoj) kun grandega ŝarĝo - 6 milionoj da eventoj sekundo. Ĉio trairas Kafka, iras al KlakuDomo, kiu provizas la kapablon vidi realtempajn panelojn de eventoj en la sistemo.

Comcast - unu el la gvidantoj en telekomunikado en Usono: Interreto, cifereca televido, telefonio. Ili kreis similan regsistemon CDN kadre Malferma Fonto la projekto Apache Trafika Kontrolo labori kun siaj grandegaj datumoj. KlakuDomo uzata kiel backend por analizo.

percona enkonstruita KlakuDomo ene de via PMMkonservi monitoradon de diversaj MySQL.

Specifaj Postuloj

Temp-seriaj datumbazoj havas siajn proprajn specifajn postulojn.

• Rapida enmeto de multaj agentoj. Ni devas enmeti datumojn de multaj fluoj tre rapide. KlakuDomo faras ĝin bone, ĉar ĝi havas ĉiujn neblokantajn enigaĵojn. Ajna enigi estas nova dosiero sur disko, kaj malgrandaj enmetoj povas esti bufrigitaj unumaniere aŭ alie. EN KlakuDomo estas pli bone enmeti datumojn en grandaj aroj, prefere ol unu linion samtempe.
• Fleksebla skemo. la tempo-serio ni kutime ne tute konas la strukturon de la datumoj. Eblas konstrui monitoran sistemon por specifa aplikaĵo, sed tiam estas malfacile uzi ĝin por alia aplikaĵo. Ĉi tio postulas pli flekseblan skemon. KlakuDomo, permesas al vi fari tion, kvankam ĝi estas forte tajpita bazo.
• Efika stokado kaj "forgesado" de datumoj. Kutime en tempo-serio grandega kvanto da datumoj, do ili devas esti konservitaj kiel eble plej efike. Ekzemple, ĉe InfluxDB bona kunpremo estas ĝia ĉefa trajto. Sed krom stokado, vi ankaŭ devas povi "forgesi" malnovajn datumojn kaj fari kelkajn subspecimenigo — aŭtomata kalkulado de agregaĵoj.
• Rapidaj demandoj pri kunigitaj datumoj. Kelkfoje estas interese rigardi la lastajn 5 minutojn kun precizeco de milisekundoj, sed pri monataj datumoj eble ne necesas minuto aŭ dua granulareco - ĝeneralaj statistikoj sufiĉas. Subteno de ĉi tiu speco estas necesa, alie peto por 3 monatoj estos efektivigita por tre longa tempo eĉ en KlakuDomo.
• Petoj kiel "lasta punkto, ekde». Ĉi tiuj estas tipaj por tempo-serio petoj: rigardu la lastan mezuron aŭ la staton de la sistemo en momento t. Por la datumbazo, ĉi tiuj ne estas tre agrablaj demandoj, sed ili ankaŭ devas povi ekzekuti.
• "Gluado" temposerio. Tempo-serio estas temposerio. Se estas du temposerio, tiam ili ofte devas esti konektitaj kaj korelaciitaj. Ne estas oportune fari tion en ĉiuj datumbazoj, precipe kun nevicigitaj temposerio: jen kelkaj tempomarkoj, estas aliaj. Vi povas konsideri la mezumon, sed subite ankoraŭ estos truo, do ĝi ne estas klara.

Ni vidu kiel ĉi tiuj postuloj estas plenumitaj KlakuDomo.

Skemo

В KlakuDomo skemo por tempo-serio povas esti farita laŭ malsamaj manieroj, depende de la grado da datuma reguleco. Eblas konstrui sistemon sur regulaj datumoj kiam ni scias ĉiujn metrikojn anticipe. Ekzemple, faris CloudFlare kun monitorado CDN estas bone optimumigita sistemo. Vi povas konstrui pli ĝeneralan sistemon, kiu kontrolas la tutan infrastrukturon, malsamajn servojn. En la kazo de neregulaj datumoj, ni ne scias anticipe, kion ni kontrolas - kaj ĉi tio verŝajne estas la plej ofta kazo.

regulaj datumoj. Kolumnoj. La skemo estas simpla - kolumnoj kun la necesaj tipoj:

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);

Ĉi tio estas regula tabelo, kiu kontrolas ian sisteman lanĉan agadon (surhavi, sistemo, sencela, bela). Simpla kaj oportuna, sed ne fleksebla. Se ni volas pli flekseblan skemon, tiam ni povas uzi tabelojn.

Neregulaj datumoj. Tabeloj:

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 ...

strukturo Nestita estas du tabeloj: metriko.nomo и metriko.valoro. Ĉi tie vi povas konservi tiajn arbitrajn monitorajn datumojn kiel tabelon da nomoj kaj tabelon da mezuradoj por ĉiu evento. Por plia optimumigo, pluraj tiaj strukturoj povas esti faritaj anstataŭ unu. Ekzemple, unu por kaleŝego-valoro, alia - por int-signifo, ĉar int Mi volas konservi pli efike.

Sed tia strukturo estas pli malfacile alirebla. Vi devos uzi specialan konstruon, uzante specialajn funkciojn por eltiri la valorojn de unue la indekso kaj poste la tabelo:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Sed ĝi ankoraŭ funkcias sufiĉe rapide. Alia maniero stoki neregulajn datumojn estas per vicoj.

Neregulaj datumoj. Kordoj. En ĉi tiu tradicia maniero, sen tabeloj, nomoj kaj valoroj estas stokitaj samtempe. Se 5 mezuradoj venas de unu aparato samtempe, 000 vicoj estas generitaj en la datumbazo:

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', ...)

KlakuDomo traktas ĉi tion - ĝi havas specialajn etendaĵojn KlakuDomo SQL. Ekzemple maxSe - speciala funkcio kiu kalkulas la maksimumon per la metriko kiam iu kondiĉo estas plenumita. Vi povas skribi plurajn tiajn esprimojn en unu demando kaj tuj kalkuli la valoron por pluraj metrikoj.

Ni komparu tri alirojn:

detaloj

Ĉi tie mi aldonis "Datumgrandecon sur Disko" por iu testa datumaro. En la kazo de kolumnoj, ni havas la plej malgrandan datumgrandecon: maksimuma kunpremo, maksimuma konsulta rapido, sed ni pagas devante ĉion ripari samtempe.

En la kazo de tabeloj, aferoj estas iom pli malbonaj. La datumoj ankoraŭ bone kunpremas kaj eblas konservi neregulan ŝablonon. Sed KlakuDomo - kolumna datumbazo, kaj kiam ni komencas stoki ĉion en tabelo, ĝi iĝas korda datumbazo, kaj ni pagas por fleksebleco kun efikeco. Por ajna operacio, vi devos legi la tutan tabelon en memoron, tiam trovi la deziratan elementon en ĝi - kaj se la tabelo kreskas, tiam la rapideco degradas.

En unu el la kompanioj, kiuj uzas ĉi tiun aliron (ekzemple, uber), tabeloj estas tranĉitaj en pecojn de 128 elementoj. La datumoj de pluraj miloj da metrikoj kun volumo de 200 TB da datumoj / tago ne estas stokitaj en unu tabelo, sed en 10 aŭ 30 tabeloj kun speciala stoka logiko.

La plej simpla aliro estas kun ŝnuroj. Sed la datumoj estas malbone kunpremitaj, la grandeco de la tabelo estas granda, kaj eĉ kiam demandoj baziĝas sur pluraj metrikoj, ClickHouse ne funkcias optimume.

hibrida skemo

Ni supozu, ke ni elektis tabelskemon. Sed se ni scias, ke la plej multaj el niaj paneloj montras nur uzantajn kaj sistemajn metrikojn, ni povas aldone realigi ĉi tiujn metrikojn en kolumnojn de tabelo ĉe la tabelnivelo tiamaniere:

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);

Kiam algluita KlakuDomo aŭtomate kalkulos ilin. Tiel vi povas kombini komercon kun plezuro: la skemo estas fleksebla kaj ĝenerala, sed ni eltiris la plej ofte uzatajn kolumnojn. Notu, ke tio ne postulis ŝanĝi la enigaĵon kaj ETL, kiu daŭre enigas tabelojn en la tabelon. Ni ĵus faris Ŝanĝi TABELON, aldonis kelkajn parolantojn kaj ricevis hibridan kaj pli rapidan skemon, kiun vi povas tuj ekuzi.

Kodekoj kaj kunpremado

Por tempo-serio gravas kiom bone vi pakas la datumojn, ĉar la aro de informoj povas esti tre granda. EN KlakuDomo ekzistas aro da iloj por atingi la efikon de kunpremado 1:10, 1:20, kaj foje pli. Ĉi tio signifas, ke 1 TB da nekunpremitaj datumoj sur disko okupas 50-100 GB. Pli malgranda grandeco estas bona, datumoj povas esti legitaj kaj prilaboritaj pli rapide.

Por atingi altan nivelon de kunpremo, KlakuDomo subtenas la sekvajn kodekojn:

Tabelo ekzemplo:

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);

Ĉi tie ni difinas la kodekon DoubleDelta en unu kazo, en la dua Gorilo, kaj ni certe aldonos pli LZ4 kunpremado. Kiel rezulto, la grandeco de la datumoj sur disko estas multe reduktita:

Ĉi tio montras kiom da spaco okupas la samaj datumoj, sed uzante malsamajn kodekojn kaj kunpremojn:

• en GZIP-dosiero sur disko;
• en ClickHouse sen kodekoj, sed kun ZSTD-kunpremado;
• en ClickHouse kun kodekoj kaj kunpremado LZ4 kaj ZSTD.

Oni povas vidi, ke tabeloj kun kodekoj okupas multe malpli da spaco.

Grandeco gravas

Ne malpli grava elekti ĝusta datumtipo:

En ĉiuj supraj ekzemploj mi uzis Flosilo64. Sed se ni elektas Flosilo32tiam tio estus eĉ pli bona. Ĉi tio estis bone pruvita de la uloj de Perkona en la artikolo ĉe la supra ligilo. Gravas uzi la plej kompaktan tipon, kiu konvenas al la tasko: eĉ malpli por grandeco sur disko ol por demandorapideco. KlakuDomo tre sentema al ĝi.

Se vi povas uzi int32 anstataŭ int64, tiam atendu preskaŭ duoblan pliiĝon en rendimento. La datumoj okupas malpli da memoro, kaj la tuta "aritmetiko" funkcias multe pli rapide. KlakuDomo ene de ĝi estas tre strikte tajpita sistemo, ĝi eluzas ĉiujn eblecojn, kiujn provizas modernaj sistemoj.

Agregado kaj Materiigitaj Vidoj

Agregado kaj realigitaj vidoj permesas vin fari agregaĵojn por malsamaj okazoj:

Ekzemple, vi eble havas ne-agregajn fontajn datumojn, kaj vi povas pendigi diversajn realigitajn vidojn sur ili kun aŭtomata sumado per speciala motoro. SummingMergeTree (SMT). SMT estas speciala agregacia datumstrukturo kiu nombras agregaĵojn aŭtomate. Krudaj datumoj estas enmetitaj en la datumbazon, ĝi estas aŭtomate kunigita, kaj paneloj povas esti uzataj tuj.

TTL - "forgesu" malnovajn datumojn

Kiel "forgesi" datumojn, kiuj ne plu bezonas? KlakuDomo scias kiel fari ĝin. Kreante tabelojn, vi povas specifi TTL esprimoj: ekzemple, ke ni konservas etajn datumojn por unu tago, ĉiutagajn datumojn dum 30 tagoj, kaj neniam tuŝas semajnajn aŭ monatajn datumojn:

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 */

Plurnivela - dispartigo de datumoj tra diskoj

Disvolvante ĉi tiun ideon, datumoj povas esti konservitaj KlakuDomo en malsamaj lokoj. Supozu, ke ni volas stoki varmajn datumojn por la lasta semajno en tre rapida loka SSD, kaj ni aldonas pli da historiaj datumoj al alia loko. EN KlakuDomo nun eblas:

Vi povas agordi la retenpolitikon (konservada politiko) Do KlakuDomo aŭtomate transdonos datumojn al alia stokado kiam certaj kondiĉoj estas plenumitaj.

Sed tio ne estas ĉio. Je la nivelo de aparta tablo, vi povas difini regulojn por ĝuste kiam datumoj estas transdonitaj al malvarma stokado. Ekzemple, 7 tagoj da datumoj kuŝas sur tre rapida disko, kaj ĉio, kio estas pli malnova, estas translokigita al malrapida. Ĉi tio estas bona ĉar ĝi permesas al la sistemo konservi maksimuman rendimenton, dum ili kontrolas kostojn kaj ne elspezas monon por malvarmaj datumoj:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Unika trajtoj KlakuDomo

Preskaŭ ĉio en KlakuDomo ekzistas tiaj "altaĵoj", sed ili estas ebenigitaj per la ekskluzivo - kio ne estas en aliaj datumbazoj. Ekzemple, jen kelkaj el la unikaj trajtoj KlakuDomo:

• Aroj. la KlakuDomo tre bona subteno por tabeloj, same kiel la kapablo fari kompleksajn kalkulojn sur ili.
• Agregado de Datumaj Strukturoj. Ĉi tio estas unu el la "mortigaj trajtoj" KlakuDomo. Malgraŭ tio, ke la uloj de Yandex diras, ke ni ne volas kunigi datumojn, ĉio estas kunigita en KlakuDomoĉar ĝi estas rapida kaj oportuna.
• Materiigitaj Vidoj. Kune kun agregaciaj datumstrukturoj, realigitaj vidoj permesas vin fari oportunan Reala tempo agregacio.
• ClickHouse SQL. Ĉi tio estas lingva etendaĵo SQL kun kelkaj kromaj kaj ekskluzivaj funkcioj kiuj estas nur haveblaj en KlakuDomo. Antaŭe ĝi estis, kvazaŭ, etendo unuflanke, kaj malavantaĝo aliflanke. Nun preskaŭ ĉiuj mankoj kompare al SQL 92 ni forigis ĝin, nun ĝi estas nur etendaĵo.
• Lambda-esprimoj. Ĉu ili ankoraŭ estas en iu datumbazo?
• ML-subteno. Ĉi tio estas en malsamaj datumbazoj, iuj estas pli bonaj, iuj estas pli malbonaj.
• malferma fonto. Ni povas vastigi KlakuDomo kune. Nun en KlakuDomo ĉirkaŭ 500 kontribuantoj, kaj ĉi tiu nombro konstante kreskas.

Delikataj Demandoj

В KlakuDomo estas multaj malsamaj manieroj fari la saman aferon. Ekzemple, estas tri malsamaj manieroj por redoni la lastan valoron de tabelo por CPU (estas ankaŭ kvara, sed ĝi estas eĉ pli ekzotika).

La unua montras kiom oportune estas fari enen KlakuDomo demandojn kiam vi volas kontroli tion opo enhavita en la subdemando. Ĉi tio estas io, kion mi persone vere maltrafis en aliaj datumbazoj. Se mi volas kompari ion kun subdemando, tiam en aliaj datumbazoj nur skalaro povas esti komparita kun ĝi, sed por pluraj kolumnoj mi devas skribi JOIN. la KlakuDomo vi povas uzi opon:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

La dua metodo faras la samon sed uzas entuta funkcion argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В KlakuDomo ekzistas kelkaj dekoj da entutaj funkcioj, kaj se oni uzas kombinantojn, tiam laŭ la leĝoj de kombinatoriko oni ricevas ĉirkaŭ milon da ili. ArgMax - unu el la funkcioj, kiu kalkulas la maksimuman valoron: la demando liveras la valoron uzado_uzanto, ĉe kiu la maksimuma valoro estas atingita kreita_je:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF JOIN - "glui" vicojn kun malsamaj tempoj. Ĉi tio estas unika trajto por datumbazoj kaj disponeblas nur en kdb+. Se estas du temposerio kun malsamaj tempoj, ASOF JOIN permesas ilin movi kaj glui en unu peto. Por ĉiu valoro en unu temposerio, la plej proksima valoro en alia estas trovita, kaj ili estas resenditaj sur la sama linio:

Analizaj Funkcioj

En la normo SQL-2003 vi povas skribi tiel:

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;

В KlakuDomo tio ne eblas - ĝi ne subtenas la normon SQL-2003 kaj verŝajne neniam faros ĝin. Anstataŭe, en KlakuDomo estas kutime skribi tiel:

Mi promesis lambdojn — jen ili!

Ĉi tio estas analogo de la analiza demando en la normo SQL-2003: li kalkulas la diferencon inter la du timestamp, daŭro, orda - ĉio, kion ni kutime konsideras analizajn funkciojn. EN KlakuDomo Ni kalkulas ilin per tabeloj: unue ni kolapsas la datumojn en tabelon, post tio ni faras ĉion, kion ni volas sur la tabelo, kaj poste ni vastigas ĝin reen. Ĝi ne estas tre oportuna, ĝi postulas amon al funkcia programado minimume, sed ĝi estas tre fleksebla.

Specialaj Trajtoj

Cetere, en KlakuDomo multaj specialaj trajtoj. Ekzemple, kiel determini kiom da sesioj funkcias samtempe? Tipa tasko por monitorado estas determini la maksimuman ŝarĝon en ununura peto. EN KlakuDomo ekzistas speciala funkcio por ĉi tiu celo:

Ĝenerale, ClickHouse havas specialajn funkciojn por multaj celoj:

• kuradoDiferenco, kuradoAkumuli, najbaro;
• sumMap(ŝlosilo, valoro);
• timeSeriesGroupSum(uid, tempostampo, valoro);
• timeSeriesGroupRateSum(uid, tempostampo, valoro);
• skewPop, skewSamp, kurtPop, kurtSamp;
• KUN PLENIGO / KUN LIGILOJ;
• simpleLinearRegression, stokastaLinearRegression.

Ĉi tio ne estas kompleta listo de funkcioj, ekzistas nur 500-600 el ili. Sugesto: ĉiuj funkcioj en KlakuDomo estas en la sistema tabelo (ne ĉiuj estas dokumentitaj, sed ĉiuj estas interesaj):

select * from system.functions order by name

KlakuDomo konservas multajn informojn pri si mem, inkluzive protokolaj tabeloj, query_log, spurprotokolo, operacioprotokolo kun datumblokoj (part_log), la metrika protokolo, kaj la sistemprotokolo, kiun ĝi kutime skribas al disko. La metrika protokolo estas tempo-serio в KlakuDomo fakte KlakuDomo: la datumbazo mem povas ludi rolon tempo-serio datumbazoj, tiel "vorante" sin.

Ĉi tio ankaŭ estas unika afero - ĉar ni faras bonan laboron por tempo-seriokial ni ne povas konservi en ni ĉion, kion ni bezonas? Ni ne bezonas Prometeo, ni konservas ĉion en ni mem. Konektis grafana kaj ni kontrolas nin mem. Tamen, se KlakuDomo falas, ni ne vidos — kial — tial ili kutime ne faras tion.

Granda areto aŭ multaj malgrandaj KlakuDomo

Kio estas pli bona - unu granda areto aŭ multaj malgrandaj Klakdomoj? La tradicia aliro al DWH estas granda areto en kiu kabaloj estas asignitaj por ĉiu aplikiĝo. Ni venis al la datumbaza administranto - donu al ni skemon, kaj ni ricevis ĝin:

В KlakuDomo vi povas fari ĝin alimaniere. Ĉu ĉiu aplikaĵo povas fari sian propran? KlakuDomo:

Ni ne plu bezonas grandan monstron DWH kaj nekunlaborantaj administrantoj. Ni povas doni al ĉiu aplikaĵo sian propran KlakuDomo, kaj la programisto povas fari ĝin mem, ĉar KlakuDomo tre facile instalebla kaj ne postulas kompleksan administradon:

Sed se ni havas multon KlakuDomo, kaj vi devas agordi ĝin ofte, tiam vi volas aŭtomatigi ĉi tiun procezon. Por tio ni povas, ekzemple, uzi Kubernetoj и klakdomo-funkciigisto. EN Kubernetes ClickHouse vi povas meti "sur klako": mi povas klaki butonon, ruli la manifeston kaj la datumbazo estas preta. Vi povas tuj krei skemon, komenci ŝarĝi metrikojn tie, kaj post 5 minutoj mi havas panelon preta grafana. Ĝi estas tiel simpla!

Kio en la fino?

Kaj tiel, KlakuDomo - Ĉi tio:

• Rapida. Ĉiuj scias ĉi tion.
• Simple. Iom diskutebla, sed mi pensas, ke estas malfacile lernebla, facile batali. Se vi komprenas kiel KlakuDomo funkcias, ĉio estas tre simpla.
• Universale. Ĝi taŭgas por malsamaj scenaroj: DWH, Time Series, Log Storage. Sed ne estas OLTP datumbazo, do ne provu fari mallongajn enmetojn kaj legadojn tie.
• Estas interesa. Verŝajne tiu, kiu laboras kun KlakuDomo, spertis multajn interesajn minutojn en bona kaj malbona senco. Ekzemple, nova eldono aperis, ĉio ĉesis funkcii. Aŭ kiam vi luktis kun tasko dum du tagoj, sed post demando en la Telegram-babilejo, la tasko estis solvita en du minutoj. Aŭ, kiel ĉe la konferenco ĉe la raporto de Lesha Milovidov, ekrankopio de KlakuDomo rompis la elsendon HighLoad++. Ĉi tiuj specoj de aferoj okazas la tutan tempon kaj faras nian vivon kun KlakuDomo brila kaj interesa!

La prezento videblas tie.

La longe atendita renkontiĝo de programistoj de altŝarĝaj sistemoj ĉe HighLoad++ okazos la 9-an kaj 10-an de novembro en Skolkovo. Fine, ĝi estos eksterreta konferenco (kvankam kun ĉiuj antaŭzorgoj), ĉar la energio de HighLoad++ ne povas esti pakita interrete.

Por la konferenco, ni trovas kaj montras al vi kazojn pri la maksimumaj kapabloj de teknologio: HighLoad++ estis, estas kaj estos la sola loko, kie vi povas lerni en du tagoj, kiel funkcias Facebook, Yandex, VKontakte, Google kaj Amazon.

Okazinte niajn kunvenojn seninterrompe ekde 2007, ĉi-jare ni kunvenos la 14-an fojon. Dum ĉi tiu tempo, la konferenco kreskis 10 fojojn, pasintjare la ŝlosila evento de la industrio kolektis 3339 partoprenantojn, 165 prelegantojn de raportoj kaj renkontiĝoj, kaj 16 aŭtoveturejoj ludis samtempe.
Pasintjare estis 20 busoj por vi, 5280 litroj da teo kaj kafo, 1650 litroj da fruktotrinkaĵoj kaj 10200 boteloj da akvo. Kaj pliaj 2640 kilogramoj da manĝaĵo, 16 teleroj kaj 000 tasoj. Cetere, per la mono akirita el reciklita papero, ni plantis 25 kverkplantidojn 🙂

Biletoj aĉeteblas tie, ricevu novaĵojn pri la konferenco — tie, kaj parolu en ĉiuj sociaj retoj: Telegramo, Facebook, Vkontakte и Twitter.

fonto: www.habr.com