Trasllat a ClickHouse: 3 anys després

Fa tres anys Viktor Tarnavsky i Alexey Milovidov de Yandex a l'escenari HighLoad ++ va dir, quin ClickHouse és bo i com no s'alenteix. I a la següent etapa va ser Alexander Zaitsev с informe sobre traslladar-se a Feu clic a Casa d'un altre SGBD analític i amb la conclusió que Feu clic a Casa, per descomptat, bo, però no gaire convenient. Quan l'any 2016 l'empresa LifeStreet, on Alexander treballava aleshores, va traduir el sistema analític multipetabyte a Feu clic a Casa, era una fascinant "carretera de maons grocs", plena de perills desconeguts - Feu clic a Casa llavors semblava un camp de mines.

Tres anys després Feu clic a Casa va ser molt millor: durant aquest temps, Alexander va fundar l'empresa Altinity, que no només ajuda a traslladar-s'hi Feu clic a Casa desenes de projectes, però també millora el propi producte juntament amb els companys de Yandex. Ara Feu clic a Casa encara no és un passeig despreocupat, però ja no és un camp de mines.

Alexander ha estat involucrat en sistemes distribuïts des de 2003, desenvolupant grans projectes MySQL, Oracle и Vertica. Al final HighLoad ++ 2019 Alexander, un dels pioners de l'ús Feu clic a Casa, va dir què és ara aquest SGBD. Coneixerem les principals característiques Feu clic a Casa: com es diferencia d'altres sistemes i en quins casos és més efectiu utilitzar-lo. Utilitzant exemples, considerem pràctiques noves i provades per projectes per a sistemes de construcció basats en Feu clic a Casa.

Retrospectiva: què va passar fa 3 anys

Fa tres anys vam traslladar l'empresa LifeStreet en Feu clic a Casa d'una base de dades d'anàlisi diferent i la migració de l'anàlisi de la xarxa publicitària va tenir aquest aspecte:

• Juny 2016. En Codi obert aparegut Feu clic a Casa i va començar el nostre projecte;
• Agost Prova de concepte: gran xarxa publicitària, infraestructura i 200-300 terabytes de dades;
• Octubre. Primeres dades de producció;
• desembre. Càrrega completa del producte: entre 10 i 50 mil milions d'esdeveniments al dia.
• Juny 2017. Migració satisfactòria dels usuaris a Feu clic a Casa, 2,5 petabytes de dades en un clúster de 60 servidors.

A mesura que avançava la migració, la comprensió va anar creixent Feu clic a Casa és un bon sistema amb el qual és agradable treballar, però aquest és un projecte intern de Yandex. Per tant, hi ha matisos: Yandex tractarà primer amb els seus propis clients interns i només després amb la comunitat i les necessitats dels usuaris externs, mentre que ClickHouse no va arribar al nivell empresarial en moltes àrees funcionals aleshores. Així, el març de 2017, vam fundar Altinity per fer Feu clic a Casa encara més ràpid i còmode no només per a Yandex, sinó també per a altres usuaris. I ara nosaltres:

• Formem i ajudem a construir solucions basades en Feu clic a Casa perquè els clients no omplin ressalts, i perquè la solució finalment funcioni;
• Oferim assistència les 24 hores del dia Feu clic a Casa- instal·lacions;
• Desenvolupem els nostres propis projectes d'ecosistema;
• Compromesos activament amb mi mateix Feu clic a Casa, responent a les peticions dels usuaris que volen veure determinades funcions.

I, per descomptat, ajudem amb el trasllat a Feu clic a Casa с MySQL, Vertica, Oracle, Greenplum, Redshift i altres sistemes. Hem participat en una gran varietat de trasllats i tots han tingut èxit.

Per què fins i tot passar a Feu clic a Casa

No s'alenteix! Aquest és el motiu principal. Feu clic a Casa - Base de dades molt ràpida per a diferents escenaris:

Cites aleatòries de persones amb qui treballen Feu clic a Casa.

Escalabilitat. En alguna altra base de dades, podeu aconseguir un bon rendiment en una sola peça de maquinari, però Feu clic a Casa podeu escalar no només verticalment, sinó també horitzontalment simplement afegint servidors. No tot funciona tan bé com voldríem, però funciona. Podeu fer créixer el sistema a mesura que el vostre negoci creixi. És important que no estem limitats per la decisió ara i sempre hi ha potencial de desenvolupament.

portabilitat. No hi ha cap afecció a una cosa. Per exemple, amb Amazon Redshift difícil de moure a algun lloc. A Feu clic a Casa podeu posar-lo al vostre ordinador portàtil, servidor, desplegar-lo al núvol, anar a Kubernetes - No hi ha restriccions en el funcionament de la infraestructura. Això és convenient per a tothom, i aquest és un gran avantatge del qual moltes altres bases de dades similars no poden presumir.

Flexibilitat. Feu clic a Casa no es limita a una cosa, per exemple, Yandex.Metrica, sinó que s'està desenvolupant i utilitzant en projectes i indústries cada cop més diferents. Es pot ampliar afegint noves funcions per resoldre nous problemes. Per exemple, es creu que emmagatzemar els registres en una base de dades és una mala educació, de manera que per això es van plantejar Elasticsearch. Però gràcies a la flexibilitat Feu clic a Casa, també hi podeu emmagatzemar els registres, i sovint és fins i tot millor que a Elasticsearch - dins Feu clic a Casa requereix 10 vegades menys ferro.

Gratuït Open Source. No has de pagar per res. No cal negociar permís per posar el sistema al vostre ordinador portàtil o servidor. No hi ha comissions amagades. Al mateix temps, cap altra tecnologia de bases de dades de codi obert pot competir amb la velocitat Feu clic a Casa. MySQL, MariaDB, Greenplum - tots són molt més lents.

Comunitat, conducció i diversió. Tenir Feu clic a Casa gran comunitat: trobades, xats i Alexey Milovidov, que ens carrega a tots amb la seva energia i optimisme.

Passant a ClickHouse

Per canviar a Feu clic a Casa amb alguna cosa, només necessites tres coses:

• Entendre les limitacions Feu clic a Casa i per a què no és apte.
• Utilitza els beneficis tecnologia i els seus punts forts.
• Experimenta. Fins i tot sabent com funciona Feu clic a Casa, no sempre és possible predir quan serà més ràpid, quan serà més lent, quan serà millor i quan serà pitjor. Així que prova.

El problema de moure's

Només hi ha un "però": si et mous Feu clic a Casa amb una altra cosa, alguna cosa normalment va malament. Estem acostumats a algunes pràctiques i coses que funcionen a la nostra base de dades preferida. Per exemple, qualsevol persona amb qui treballa SQL-bases de dades, considera obligatori el següent conjunt de funcions:

• transaccions;
• restriccions;
• consistència;
• índexs;
• ACTUALITZAR/ELIMINAR;
• NULLS;
• mil·lisegons;
• conversions de tipus automàtiques;
• unions múltiples;
• particions arbitràries;
• eines de gestió de clústers.

La contractació és obligatòria, però fa tres anys Feu clic a Casa no hi havia cap d'aquestes característiques! Ara queda menys de la meitat del no realitzat: transaccions, restriccions, coherència, mil·lisegons i càsting de tipus.

I el més important és que en Feu clic a Casa algunes pràctiques i enfocaments estàndard no funcionen o no funcionen de la manera que estem acostumats. Tot el que apareix en Feu clic a Casa, correspon a "feu clic a casa", és a dir les funcions són diferents de les altres DB. Per exemple:

• Els índexs no estan seleccionats, però s'ometen.
• ACTUALITZAR/ELIMINAR no sincrònic, sinó asíncron.
• Hi ha diverses unions, però no hi ha cap planificador de consultes. Com s'executen aleshores, generalment no està molt clar per a la gent del món de la base de dades.

Escenaris de ClickHouse

El 1960, un matemàtic nord-americà d'origen hongarès WignerEP va escriure un articleL'eficàcia no raonable de les matemàtiques a les ciències naturals”(“L'efectivitat incomprensible de les matemàtiques a les ciències naturals”) que el món que ens envolta està per alguna raó ben descrit per les lleis matemàtiques. Les matemàtiques són una ciència abstracta i les lleis físiques expressades en forma matemàtica no són trivials i WignerEP va subratllar que això és molt estrany.

Des del meu punt de vista, Feu clic a Casa - la mateixa raresa. Per reformular Wigner, podem dir això: sorprenent és l'eficàcia inconcebible Feu clic a Casa en una gran varietat d'aplicacions analítiques!

Per exemple, prenguem Magatzem de dades en temps real, on les dades es carreguen gairebé contínuament. Volem rebre les seves peticions amb un segon retard. Si us plau, utilitza Feu clic a Casaperquè va ser dissenyat per a aquest escenari. Feu clic a Casa així és com s'utilitza no només a la web, sinó també en màrqueting i anàlisi financera, AdTech, així com en Detecció de fraun. EN Magatzem de dades en temps real s'utilitza un esquema estructurat complex com ara "estrella" o "floc de neu", amb moltes taules JOIN (de vegades múltiples), i les dades s'emmagatzemen i es canvien normalment en alguns sistemes.

Prenem un altre escenari - Sèries temporals: dispositius de monitorització, xarxes, estadístiques d'ús, internet de les coses. Aquí ens trobem amb esdeveniments força senzills ordenats en el temps. Feu clic a Casa no es va desenvolupar originalment per a això, però s'ha mostrat bé, de manera que les grans empreses l'utilitzen Feu clic a Casa com a dipòsit per al seguiment de la informació. A veure si encaixa Feu clic a Casa per a les sèries temporals, vam fer un punt de referència basat en l'enfocament i els resultats InfluxDB и Escala de temps DB - especialitzat sèries temporals bases de dades. Va resultarQue Feu clic a Casa, fins i tot sense optimització per a aquestes tasques, també guanya en un camp estranger:

В sèries temporals normalment s'utilitza una taula estreta: diverses columnes petites. Moltes dades poden provenir de la supervisió (milions de registres per segon) i solen venir en petites insercions (en temps real streaming). Per tant, necessitem un script d'inserció diferent i les consultes en si, amb algunes especificitats pròpies.

Gestió de registres. Recollir registres a la base de dades sol ser dolent, però en Feu clic a Casa això es pot fer amb alguns comentaris tal com es descriu anteriorment. Moltes empreses utilitzen Feu clic a Casa només per això. En aquest cas, s'utilitza una taula ampla i plana, on emmagatzemem els registres sencers (per exemple, en el formulari JSON), o tallat a trossos. Les dades es carreguen normalment en grans lots (fitxers) i estem buscant algun camp.

Per a cadascuna d'aquestes funcions s'acostumen a utilitzar bases de dades especialitzades. Feu clic a Casa un pot fer-ho tot i tan bé que els supera en l'actuació. Mirem-ho ara més de prop sèries temporals guió i com "cuinar" Feu clic a Casa sota aquest escenari.

Sèries temporals

Aquest és actualment l'escenari principal per al qual Feu clic a Casa considerada la solució estàndard. Sèries temporals és un conjunt d'esdeveniments ordenats en el temps que representen els canvis en algun procés al llarg del temps. Per exemple, pot ser la freqüència cardíaca per dia o el nombre de processos del sistema. Tot el que fa que el temps tingui algunes dimensions sèries temporals:

La majoria d'aquests esdeveniments provenen del seguiment. Això pot ser no només monitorització web, sinó també dispositius reals: cotxes, sistemes industrials, IO, indústries o taxis no tripulats, en el maleter dels quals ja està posant Yandex Feu clic a Casa-servidor.

Per exemple, hi ha empreses que recullen dades dels vaixells. Cada pocs segons, els sensors d'un vaixell portacontenidors envien centenars de mesures diferents. Els enginyers les estudien, construeixen models i intenten entendre amb quina eficàcia s'utilitza el vaixell, perquè un vaixell portacontenidors no s'ha de quedar inactiu ni un segon. Qualsevol temps d'inactivitat és una pèrdua de diners, per la qual cosa és important predir el recorregut perquè l'aparcament sigui mínim.

Ara hi ha un creixement de bases de dades especialitzades que mesuren sèries temporals. En el lloc Motors DB d'alguna manera es classifiquen diferents bases de dades i es poden veure per tipus:

El tipus de creixement més ràpid sèries temporalss. Les bases de dades de gràfics també creixen, però sèries temporalss han anat creixent més ràpidament en els últims anys. Els representants típics d'aquesta família de bases de dades són InfluxDB, Prometeu, KDB, Escala de temps DB (construït sobre PostgreSQL), solucions de Amazon. Feu clic a Casa aquí també es pot utilitzar, i s'utilitza. Permeteu-me que us posi uns quants exemples públics.

Un dels pioners és l'empresa CloudFlare (CDNproveïdor). Supervisen els seus CDN a través d' Feu clic a Casa (DNS- sol·licituds, HTTP-sol·licituds) amb una càrrega enorme: 6 milions d'esdeveniments per segon. Tot passa Kafka, va a Feu clic a Casa, que ofereix la possibilitat de veure taulers de control d'esdeveniments en temps real al sistema.

Comcast - un dels líders en telecomunicacions als Estats Units: Internet, televisió digital, telefonia. Van crear un sistema de control similar CDN dins del marc Open Source projecte Control de trànsit Apache per treballar amb les seves enormes dades. Feu clic a Casa utilitzat com a backend per a l'anàlisi.

Percona incorporat Feu clic a Casa dins teu PMMper seguir fent un seguiment diferent MySQL.

Requisits específics

Les bases de dades de sèries temporals tenen els seus propis requisits específics.

• Ràpida inserció de molts agents. Hem d'inserir dades de molts fluxos molt ràpidament. Feu clic a Casa ho fa bé, perquè té totes les insercions que no bloquegen. Cap inserir és un fitxer nou al disc, i les petites insercions es poden emmagatzemar d'una manera o altra. EN Feu clic a Casa és millor inserir dades en lots grans, en lloc d'una línia a la vegada.
• Circuit flexible. En sèries temporals normalment no coneixem completament l'estructura de les dades. És possible construir un sistema de monitorització per a una aplicació específica, però després és difícil utilitzar-lo per a una altra aplicació. Això requereix un esquema més flexible. Feu clic a Casa, us permet fer-ho, tot i que és una base fortament mecanografiada.
• Emmagatzematge eficient i "oblit" de dades. Normalment a sèries temporals una gran quantitat de dades, de manera que s'han d'emmagatzemar de la manera més eficient possible. Per exemple, a InfluxDB una bona compressió és la seva característica principal. Però, a més de l'emmagatzematge, també cal poder "oblidar" dades antigues i fer-ne algunes baixes mostreigs — Recompte automàtic d'àrids.
• Consultes ràpides sobre dades agregades. De vegades és interessant mirar els últims 5 minuts amb una precisió de mil·lisegons, però en les dades mensuals, pot ser que no calgui la granularitat del minut o del segon; les estadístiques generals són suficients. El suport d'aquest tipus és necessari, en cas contrari, una sol·licitud de 3 mesos s'executarà durant molt de temps fins i tot en Feu clic a Casa.
• Sol·licituds com "últim punt, a partir de». Aquests són típics per sèries temporals peticions: mirar l'última mesura o l'estat del sistema en un moment determinat t. Per a la base de dades, aquestes consultes no són gaire agradables, però també s'han de poder executar.
• sèries temporals per "enganxar".. Sèries temporals és una sèrie temporal. Si hi ha dues sèries temporals, sovint s'han de connectar i correlacionar. No és convenient fer-ho en totes les bases de dades, especialment amb sèries temporals no alineades: aquí hi ha algunes marques de temps, n'hi ha d'altres. Podeu considerar la mitjana, però de sobte encara hi haurà un forat, així que no està clar.

Vegem com es compleixen aquests requisits Feu clic a Casa.

L'esquema

В Feu clic a Casa esquema per sèries temporals es pot fer de diferents maneres, en funció del grau de regularitat de les dades. És possible construir un sistema amb dades habituals quan coneixem totes les mètriques per endavant. Per exemple, va fer CloudFlare amb seguiment CDN és un sistema ben optimitzat. Podeu construir un sistema més general que controli tota la infraestructura, diferents serveis. En el cas de dades irregulars, no sabem per endavant què estem monitoritzant -i probablement aquest és el cas més habitual.

dades habituals. Columnes. L'esquema és senzill: columnes amb els tipus necessaris:

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

Aquesta és una taula normal que supervisa algun tipus d'activitat d'arrencada del sistema (user, eOS®, ralentí, agradable). Senzill i còmode, però no flexible. Si volem un esquema més flexible, podem utilitzar matrius.

Dades irregulars. Arrays:

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

Estructura Anidat són dues matrius: mètriques.nom и mètriques.valor. Aquí podeu emmagatzemar dades de control arbitràries com una matriu de noms i una matriu de mesures per a cada esdeveniment. Per a una optimització addicional, es poden fer diverses estructures d'aquest tipus en lloc d'una. Per exemple, un per flotador-valor, un altre - per int-és a dir, perquè int Vull emmagatzemar de manera més eficient.

Però aquesta estructura és més difícil d'accedir. Haureu d'utilitzar una construcció especial, utilitzant funcions especials per treure primer els valors de l'índex i després de la matriu:

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

Però encara funciona prou ràpid. Una altra manera d'emmagatzemar dades irregulars és mitjançant files.

Dades irregulars. Cordes. D'aquesta manera tradicional, sense matrius, els noms i els valors s'emmagatzemen alhora. Si 5 mesures provenen d'un dispositiu alhora, es generen 000 files a la base de dades:

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

Feu clic a Casa fa front a això: té extensions especials Feu clic a Casa SQL. Per exemple maxIf - una funció especial que calcula el màxim per la mètrica quan es compleix alguna condició. Podeu escriure diverses d'aquestes expressions en una consulta i calcular immediatament el valor de diverses mètriques.

Comparem tres enfocaments:

Детали

Aquí he afegit "Mida de les dades al disc" per a alguns conjunts de dades de prova. En el cas de les columnes, tenim la mida de dades més petita: màxima compressió, màxima velocitat de consulta, però paguem per haver de solucionar-ho tot alhora.

En el cas de les matrius, les coses són una mica pitjors. Les dades encara es comprimeixen bé i és possible emmagatzemar un patró irregular. Però Feu clic a Casa - una base de dades de columnes, i quan comencem a emmagatzemar-ho tot en una matriu, es converteix en una base de dades de cadenes i paguem la flexibilitat amb eficiència. Per a qualsevol operació, haureu de llegir tota la matriu a la memòria, després trobar-hi l'element desitjat, i si la matriu creix, la velocitat es degrada.

En una de les empreses que utilitza aquest enfocament (per exemple, Uber), les matrius es tallen en trossos de 128 elements. Les dades de diversos milers de mètriques amb un volum de 200 TB de dades/dia no s'emmagatzemen en una matriu, sinó en 10 o 30 matrius amb una lògica d'emmagatzematge especial.

L'enfocament més senzill és amb cordes. Però les dades estan mal comprimides, la mida de la taula és gran i, fins i tot quan les consultes es basen en diverses mètriques, ClickHouse no funciona de manera òptima.

esquema híbrid

Suposem que hem escollit un esquema de matriu. Però si sabem que la majoria dels nostres taulers només mostren mètriques d'usuari i sistema, també podem materialitzar aquestes mètriques en columnes d'una matriu a nivell de taula d'aquesta manera:

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

Quan s'enganxa Feu clic a Casa els comptarà automàticament. D'aquesta manera podeu combinar el negoci amb el plaer: l'esquema és flexible i general, però vam treure les columnes més utilitzades. Tinc en compte que això no va requerir canviar la inserció i ETL, que continua inserint matrius a la taula. Acabem de fer ALTER TABLE, va afegir un parell d'altaveus i va obtenir un esquema híbrid i més ràpid que podeu començar a utilitzar de seguida.

Còdecs i compressió

Per sèries temporals és important com empaqueteu les dades, perquè la matriu d'informació pot ser molt gran. EN Feu clic a Casa hi ha un conjunt d'eines per aconseguir l'efecte de la compressió 1:10, 1:20 i, de vegades, més. Això vol dir que 1 TB de dades no comprimides al disc ocupa entre 50 i 100 GB. Una mida més petita és bona, les dades es poden llegir i processar més ràpidament.

Per aconseguir un alt nivell de compressió, Feu clic a Casa admet els còdecs següents:

Exemple de taula:

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

Aquí definim el còdec DobleDelta en un cas, en el segon Goril, i assegureu-vos d'afegir-ne més LZ4 compressió. Com a resultat, la mida de les dades al disc es redueix molt:

Això mostra quant espai ocupa les mateixes dades, però utilitzant còdecs i compressions diferents:

• en un fitxer GZIP al disc;
• a ClickHouse sense còdecs, però amb compressió ZSTD;
• a ClickHouse amb còdecs LZ4 i ZSTD i compressió.

Es pot veure que les taules amb còdecs ocupen molt menys espai.

La mida és important

No menys important выбрать tipus de dades correctes:

En tots els exemples anteriors que he utilitzat Flotador64. Però si triem Flotador32llavors seria encara millor. Això ho van demostrar bé els nois de Perkona a l'article de l'enllaç anterior. És important utilitzar el tipus més compacte que s'adapti a la tasca: encara menys per a la mida del disc que per a la velocitat de consulta. Feu clic a Casa molt sensible a això.

Si pots utilitzar int32 en comptes de int64, llavors espereu un augment gairebé el doble del rendiment. Les dades ocupen menys memòria i tota l'"aritmètica" funciona molt més ràpid. Feu clic a Casa al seu interior hi ha un sistema molt estricte de mecanografia, aprofita totes les possibilitats que ofereixen els sistemes moderns.

Agregació i Vistes materialitzades

L'agregació i les vistes materialitzades us permeten fer agregats per a diferents ocasions:

Per exemple, podeu tenir dades d'origen no agregades i podeu penjar-hi diverses vistes materialitzades amb una suma automàtica mitjançant un motor especial SummingMergeTree (SMT). SMT és una estructura de dades d'agregació especial que compta els agregats automàticament. Les dades en brut s'insereixen a la base de dades, s'agreguen automàticament i els taulers es poden utilitzar immediatament.

TTL - "Oblidar" dades antigues

Com "oblidar" les dades que ja no són necessàries? Feu clic a Casa sap com fer-ho. Quan creeu taules, podeu especificar TTL expressions: per exemple, que emmagatzemem dades de minuts durant un dia, dades diàries durant 30 dies i mai toquem dades setmanals o mensuals:

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

diversos nivells - particionament de dades entre discs

Desenvolupant aquesta idea, es poden emmagatzemar dades Feu clic a Casa en diferents llocs. Suposem que volem emmagatzemar les dades actuals de la darrera setmana en un local molt ràpid SSD, i afegim més dades històriques a un altre lloc. EN Feu clic a Casa ara és possible:

Podeu configurar la política de retenció (política d'emmagatzematge) Tan Feu clic a Casa transferirà automàticament les dades a un altre emmagatzematge quan es compleixin determinades condicions.

Però això no és tot. Al nivell d'una taula concreta, podeu definir regles per a quan exactament es transfereixen les dades a l'emmagatzematge en fred. Per exemple, 7 dies de dades es troben en un disc molt ràpid i tot el que és més antic es transfereix a un altre lent. Això és bo perquè permet que el sistema mantingui el màxim rendiment, alhora que controla els costos i no gasta diners en dades fredes:

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

Característiques úniques Feu clic a Casa

Gairebé tot dins Feu clic a Casa hi ha aquests "punts destacats", però estan anivellats per l'exclusiu, el que no es troba a altres bases de dades. Per exemple, aquí teniu algunes de les característiques úniques Feu clic a Casa:

• Matrius. En Feu clic a Casa molt bon suport per a matrius, així com la capacitat de realitzar càlculs complexos sobre ells.
• Agregació d'estructures de dades. Aquesta és una de les "característiques assassines" Feu clic a Casa. Malgrat que els nois de Yandex diuen que no volem agregar dades, tot està agregat en Feu clic a Casaperquè és ràpid i còmode.
• Vistes materialitzades. Juntament amb l'agregació d'estructures de dades, les vistes materialitzades us permeten fer-ho més còmode en temps real agregació.
• ClickHouse SQL. És una extensió lingüística SQL amb algunes funcions addicionals i exclusives que només estan disponibles a Feu clic a Casa. Anteriorment, era com una extensió d'una banda i un desavantatge per l'altra. Ara gairebé totes les deficiències en comparació amb SQL 92 l'hem eliminat, ara només és una extensió.
• Lambda-expressions. Encara estan en alguna base de dades?
• ML-suport. Això es troba en diferents bases de dades, algunes són millors, altres pitjors.
• codi obert. Ens podem ampliar Feu clic a Casa junts. Ara dins Feu clic a Casa uns 500 col·laboradors, i aquest nombre està en constant creixement.

Consultes complicades

В Feu clic a Casa hi ha moltes maneres diferents de fer el mateix. Per exemple, hi ha tres maneres diferents de retornar l'últim valor d'una taula CPU (també n'hi ha un quart, però encara és més exòtic).

El primer mostra com de còmode és fer-ho Feu clic a Casa consultes quan ho vulguis comprovar tupla continguda a la subconsulta. Això és una cosa que personalment em faltava en altres bases de dades. Si vull comparar alguna cosa amb una subconsulta, en altres bases de dades només es pot comparar amb un escalar i, per a diverses columnes, he d'escriure JOIN. En Feu clic a Casa podeu utilitzar la tupla:

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

La segona manera fa el mateix però utilitza una funció agregada argMax:

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

В Feu clic a Casa hi ha diverses dotzenes de funcions agregades, i si feu servir combinadors, segons les lleis de la combinatòria, obteniu un miler d'elles. ArgMax - una de les funcions que compta el valor màxim: la consulta retorna el valor usuari_ús, en què s'assoleix el valor màxim creat_a:

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

ASOF UNIR-SE - "enganxar" files amb diferents temps. Aquesta és una característica única per a bases de dades i només està disponible a kdb+. Si hi ha dues sèries temporals amb temps diferents, ASOF UNIR-SE permet desplaçar-los i enganxar-los en una sol·licitud. Per a cada valor d'una sèrie temporal, es troba el valor més proper en una altra i es retornen a la mateixa línia:

Funcions analítiques

En l'estàndard SQL-2003 pots escriure així:

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;

В Feu clic a Casa això no és possible, no és compatible amb l'estàndard SQL-2003 i probablement mai ho farà. En canvi, a Feu clic a Casa és costum escriure així:

Vaig prometre lambdes: aquí les teniu!

Aquest és un anàleg d'una consulta analítica a l'estàndard SQL-2003: compta la diferència entre dos marca de temps, durada, ordinal: tot allò que normalment considerem funcions analítiques. EN Feu clic a Casa els comptem a través de matrius: primer col·lapsem les dades en una matriu, després fem el que vulguem a la matriu i després les tornem a expandir. No és molt convenient, requereix amor per la programació funcional com a mínim, però és molt flexible.

Característiques especials

A més, en Feu clic a Casa moltes característiques especialitzades. Per exemple, com es pot determinar quantes sessions s'estan executant al mateix temps? Una tasca típica de monitorització és determinar la càrrega màxima en una sol·licitud única. EN Feu clic a Casa hi ha una funció especial per a aquest propòsit:

En general, ClickHouse té funcions especials per a molts propòsits:

• runningDifference, runningAcumular, veí;
• sumMap(clau, valor);
• timeSeriesGroupSum(uid, marca de temps, valor);
• timeSeriesGroupRateSum(uid, marca de temps, valor);
• skewPop, skewSamp, kurtPop, kurtSamp;
• AMB ROLL / AMB CORBATES;
• SimpleLinearRegression, estocàsticLinearRegression.

Aquesta no és una llista completa de funcions, només n'hi ha entre 500 i 600. Pista: totes les funcions a Feu clic a Casa està a la taula del sistema (no tots estan documentats, però tots són interessants):

select * from system.functions order by name

Feu clic a Casa emmagatzema molta informació sobre si mateix, inclòs taules de registre, query_log, registre de traça, registre d'operacions amb blocs de dades (part_log), el registre de mètriques i el registre del sistema, que normalment escriu al disc. El registre de mètriques és sèries temporals в Feu clic a Casa de fet Feu clic a Casa: la pròpia base de dades pot jugar un paper sèries temporals bases de dades, "devorant-se" a si mateix.

Això també és una cosa única, ja que estem fent una bona feina sèries temporalsper què no podem emmagatzemar tot el que necessitem en nosaltres mateixos? No necessitem Prometeu, ho guardem tot en nosaltres mateixos. Connectat Grafana i ens vigilem a nosaltres mateixos. Tanmateix, si Feu clic a Casa cau, no veurem -per què- per això no solen fer això.

Cúmul gran o molts petits Feu clic a Casa

Què és millor: un clúster gran o molts ClickHouses petits? L'enfocament tradicional de DWH és un gran clúster en el qual s'assignen esquemes per a cada aplicació. Vam arribar a l'administrador de la base de dades: doneu-nos un esquema i ens el van donar:

В Feu clic a Casa pots fer-ho de manera diferent. Cada aplicació pot fer la seva? Feu clic a Casa:

Ja no necessitem un gran monstre DWH i administradors poc cooperatius. Podem donar la seva a cada aplicació Feu clic a Casa, i el desenvolupador pot fer-ho ell mateix, ja que Feu clic a Casa molt fàcil d'instal·lar i no requereix una administració complexa:

Però si tenim molt Feu clic a Casa, i l'heu de configurar sovint, llavors voleu automatitzar aquest procés. Per a això podem, per exemple, utilitzar Kubernetes и casa de clics-operador. EN Kubernetes ClickHouse podeu posar "al clic": puc fer clic a un botó, executar el manifest i la base de dades està a punt. Podeu crear immediatament un esquema, començar a carregar mètriques allà i, al cap de 5 minuts, tinc un tauler preparat Grafana. És tan senzill!

El resultat?

Per tant, Feu clic a Casa - això:

• Ràpid. Això ho sap tothom.
• Simplement. Una mica discutible, però crec que és difícil d'aprendre, fàcil de lluitar. Si entens com Feu clic a Casa funciona, tot és molt senzill.
• Universalment. És adequat per a diferents escenaris: DWH, sèrie temporal, emmagatzematge de registres. Però no ho és OLTP base de dades, així que no intenteu fer-hi insercions i lectures curtes.
• Curiosament. Probablement amb qui treballa Feu clic a Casa, va viure molts minuts interessants en el sentit bo i dolent. Per exemple, va sortir una nova versió, tot va deixar de funcionar. O quan vau lluitar amb una tasca durant dos dies, però després d'una pregunta al xat de Telegram, la tasca es va resoldre en dos minuts. O, com a la conferència a l'informe de Lesha Milovidov, una captura de pantalla de Feu clic a Casa va trencar l'emissió HighLoad ++. Aquest tipus de coses passen tot el temps i ens fan la vida Feu clic a Casa brillant i interessant!

La presentació es pot veure aquí.

La tan esperada reunió de desenvolupadors de sistemes d'alta càrrega a HighLoad ++ tindrà lloc els dies 9 i 10 de novembre a Skolkovo. Finalment, serà una conferència fora de línia (encara que amb totes les precaucions), ja que l'energia de HighLoad++ no es pot empaquetar en línia.

Per a la conferència, trobem i us mostrem casos sobre les màximes possibilitats de la tecnologia: HighLoad ++ va ser, és i serà l'únic lloc on podreu conèixer en dos dies com funcionen Facebook, Yandex, VKontakte, Google i Amazon.

Havent fet les nostres reunions sense interrupció des del 2007, enguany ens reunirem per 14a vegada. Durant aquest temps, la conferència ha crescut 10 vegades, l'any passat l'esdeveniment clau de la indústria va reunir 3339 participants, 165 ponents d'informes i trobades, i 16 temes sonaven al mateix temps.
L'any passat hi havia 20 autobusos per a tu, 5280 litres de te i cafè, 1650 litres de begudes de fruita i 10200 ampolles d'aigua. I altres 2640 quilos de menjar, 16 plats i 000 tasses. Per cert, amb els diners recaptats amb paper reciclat, hem plantat 25 plàntules de roure 🙂

Les entrades es poden comprar aquí, rebre notícies sobre la conferència — aquí, i parlar a totes les xarxes socials: telegram, Facebook, Vkontakte и Twitter.

Font: www.habr.com