🥇Verhuizen naar ClickHouse: 3 jaar later

Drie jaar geleden stonden Viktor Tarnavsky en Alexey Milovidov van Yandex op het podium HighLoad ++ vertelde, hoe goed ClickHouse is en hoe het niet vertraagt. En in de volgende fase was dat zo Alexander Zaitsev с verslag doen van over verhuizen naar Klik op Huis van een ander analytisch DBMS en met de conclusie dat Klik op HuisNatuurlijk goed, maar niet erg handig. Toen in 2016 het bedrijf LifeStreet, waar Alexander toen werkte, was een analytisch systeem van meerdere petabytes aan het ombouwen Klik op Huiswas het een fascinerende “gele stenen weg” vol onbekende gevaren - Klik op Huis Toen leek het op een mijnenveld.

Drie jaar later Klik op Huis werd veel beter - gedurende deze tijd richtte Alexander het bedrijf Altinity op, dat niet alleen mensen helpt om naartoe te verhuizen Klik op Huis tientallen projecten, maar verbetert ook samen met collega's van Yandex het product zelf. Nu Klik op Huis nog steeds geen zorgeloze wandeling, maar geen mijnenveld meer.

Alexander werkt sinds 2003 met gedistribueerde systemen en ontwikkelt grote projecten MySQL, Orakel и Verticaal. Op de laatste HighLoad ++ 2019 Alexander, een van de pioniers van het gebruik Klik op Huis, vertelde wat dit DBMS nu is. We zullen de belangrijkste kenmerken leren kennen Klik op Huis: hoe het verschilt van andere systemen en in welke gevallen het effectiever is om het te gebruiken. Aan de hand van voorbeelden zullen we kijken naar recente en projectgeteste praktijken voor het bouwen van systemen op basis van Klik op Huis.

Terugblik: wat er 3 jaar geleden is gebeurd

Drie jaar geleden hebben we het bedrijf overgedragen LifeStreet op Klik op Huis vanuit een andere analytische database, en de migratie van advertentienetwerkanalyses zag er als volgt uit:

Juni 2016. In Open source verschenen Klik op Huis en ons project begon;
Augustus. Bewijs van concept: groot advertentienetwerk, infrastructuur en 200-300 terabytes aan data;
Oktober. Eerste productiegegevens;
December. De volledige productlading bedraagt 10-50 miljard evenementen per dag.
Juni 2017. Succesvolle migratie van gebruikers naar Klik op Huis2,5 petabytes aan gegevens op een cluster van 60 servers.

Tijdens het migratieproces groeide het inzicht daarin Klik op Huis is een goed systeem waar prettig mee gewerkt wordt, maar dit is een intern project van Yandex. Daarom zijn er nuances: Yandex zal eerst omgaan met zijn eigen interne klanten en pas daarna met de gemeenschap en de behoeften van externe gebruikers, en ClickHouse bereikte toen op veel functionele gebieden niet het bedrijfsniveau. Daarom hebben wij Altinity in maart 2017 opgericht om Klik op Huis nog sneller en handiger, niet alleen voor Yandex, maar ook voor andere gebruikers. En nu wij:

Wij trainen en helpen oplossingen te bouwen op basis van Klik op Huis zodat klanten niet in de problemen komen en de oplossing uiteindelijk werkt;
Wij bieden 24/7 ondersteuning Klik op Huis- installaties;
We ontwikkelen onze eigen ecosysteemprojecten;
Wij zetten ons actief in voor onszelf Klik op Huis, reagerend op verzoeken van gebruikers die bepaalde functies willen zien.

En natuurlijk helpen wij met verhuizen naar Klik op Huis с MySQL, Verticaal, Oracle, Groene pruim, Redshift en andere systemen. We zijn bij verschillende acties betrokken geweest en ze zijn allemaal succesvol geweest.

Waarom verhuizen naar Klik op Huis

Vertraagt niet! Dit is de belangrijkste reden. Klik op Huis - zeer snelle database voor verschillende scenario's:

Willekeurige quotes van mensen die al heel lang met mensen werken Klik op Huis.

Schaalbaarheid. Op een andere database kunt u goede prestaties behalen op één stuk hardware, maar Klik op Huis je kunt niet alleen verticaal, maar ook horizontaal schalen, simpelweg door servers toe te voegen. Niet alles werkt zo soepel als we zouden willen, maar het werkt wel. U kunt het systeem uitbreiden naarmate uw bedrijf groeit. Het is belangrijk dat we nu niet beperkt worden door de oplossing en dat er altijd ontwikkelingspotentieel is.

Draagbaarheid. Er is geen gehechtheid aan één ding. Met bijvoorbeeld Amazon roodverschuiving Het is moeilijk om ergens naartoe te verhuizen. A Klik op Huis u kunt het op uw laptop of server installeren, in de cloud implementeren, ga naar Kubernetes — er zijn geen beperkingen op de exploitatie van de infrastructuur. Dit is voor iedereen handig, en dit is een groot voordeel waar veel andere vergelijkbare databases niet op kunnen bogen.

flexibiliteit. Klik op Huis stopt niet bij één ding, bijvoorbeeld Yandex.Metrica, maar ontwikkelt en wordt gebruikt in steeds meer verschillende projecten en industrieën. Het kan worden uitgebreid door nieuwe mogelijkheden toe te voegen om nieuwe problemen op te lossen. Er wordt bijvoorbeeld aangenomen dat het opslaan van logs in een database een slechte manier is, zo bedachten ze Elasticsearch. Maar dankzij flexibiliteit Klik op Huis, je kunt er ook logs in opslaan, en vaak is dit zelfs beter dan in Elasticsearch - in Klik op Huis hiervoor is 10 keer minder ijzer nodig.

Gratis Open Source. Je hoeft nergens voor te betalen. U hoeft niet te onderhandelen over toestemming om het systeem op uw laptop of server te installeren. Geen verborgen kosten. Tegelijkertijd kan geen enkele andere Open Source databasetechnologie qua snelheid concurreren Klik op Huis. MySQL, MariaDB, Greenplum - ze zijn allemaal veel langzamer.

Gemeenschap, rijden en leuke. in Klik op Huis uitstekende community: meetups, chats en Alexey Milovidov, die ons allemaal beschuldigt van zijn energie en optimisme.

Verhuizing naar ClickHouse

Gaan naar Klik op Huis om de een of andere reden heb je maar drie dingen nodig:

Begrijp de beperkingen Klik op Huis en waarvoor het niet geschikt is.
Profiteer ervan technologie en zijn grootste troeven.
Experiment. Zelfs begrijpen hoe het werkt Klik op Huis, is het niet altijd mogelijk om te voorspellen wanneer het sneller zal zijn, wanneer het langzamer zal zijn, wanneer het beter zal zijn en wanneer het slechter zal zijn. Dus probeer het.

Verplaatsingsprobleem

Er is maar één ‘maar’: als je verhuist naar Klik op Huis van iets anders, dan gaat er meestal iets mis. We zijn gewend aan een aantal praktijken en dingen die werken in onze favoriete database. Iedereen die ermee werkt, bijvoorbeeld SQL-databases beschouwen de volgende reeks functies als verplicht:

transacties;
beperkingen;
consistentie;
indices;
UPDATEN/VERWIJDEREN;
NULL's;
milliseconden;
automatische typecasts;
meerdere joins;
willekeurige partities;
tools voor clusterbeheer.

Rekrutering is verplicht, maar drie jaar geleden in Klik op Huis Geen van deze functies was beschikbaar! Nu blijft minder dan de helft over van wat niet is geïmplementeerd: transacties, beperkingen, consistentie, milliseconden en typecasting.

En het belangrijkste is dat in Klik op Huis sommige standaardpraktijken en benaderingen werken niet of anders dan we gewend zijn. Alles wat erin verschijnt Klik op Huis, komt overeen met "ClickHouse-manier", d.w.z. functies verschillen van andere databases. Bijvoorbeeld:

Indexen worden niet geselecteerd, maar overgeslagen.
UPDATEN/VERWIJDEREN niet synchroon, maar asynchroon.
Er zijn meerdere joins, maar er is geen queryplanner. Hoe ze vervolgens worden uitgevoerd, is voor mensen uit de databasewereld doorgaans niet zo duidelijk.

ClickHouse-scripts

In 1960, een Amerikaanse wiskundige van Hongaarse afkomst Wigner EP schreef een artikel"De onredelijke effectiviteit van wiskunde in de natuurwetenschappen” (“The Incomprehensible Effectiveness of Mathematics in the Natural Sciences”) dat de wereld om ons heen om de een of andere reden goed wordt beschreven door wiskundige wetten. Wiskunde is een abstracte wetenschap, en natuurkundige wetten, uitgedrukt in wiskundige vorm, zijn niet triviaal Wigner EP benadrukt dat dit zeer vreemd is.

Vanuit mijn oogpunt, Klik op Huis - dezelfde vreemdheid. Om Wigner opnieuw te formuleren kunnen we het volgende zeggen: de onvoorstelbare efficiëntie is verbazingwekkend Klik op Huis in een breed scala aan analytische toepassingen!

Laten we bijvoorbeeld nemen Realtime datawarehouse, waarin gegevens vrijwel continu worden geladen. Wij willen verzoeken van haar met een tweede vertraging ontvangen. Alsjeblieft, gebruik het Klik op Huis, omdat dit het scenario is waarvoor het is ontworpen. Klik op Huis dit is precies hoe het niet alleen op internet wordt gebruikt, maar ook in marketing en financiële analyses, AdTech, evenals in Fraude detectieN. IN Realtime datawarehouse er wordt een complex gestructureerd schema zoals “ster” of “sneeuwvlok” gebruikt, veel tabellen met AANMELDEN (soms meerdere), en de gegevens worden meestal in sommige systemen opgeslagen en gewijzigd.

Laten we een ander scenario nemen: Tijdreeksen: monitoring van apparaten, netwerken, gebruiksstatistieken, Internet of Things. Hier komen we vrij eenvoudige gebeurtenissen tegen, geordend in de tijd. Klik op Huis is hier oorspronkelijk niet voor ontwikkeld, maar heeft bewezen goed te werken, vandaar dat grote bedrijven er gebruik van maken Klik op Huis als opslagplaats voor monitoringinformatie. Om te onderzoeken of het geschikt is Klik op Huis voor tijdreeksen hebben we een benchmark gemaakt op basis van de aanpak en resultaten InstroomDB и Tijdschaal DB - gespecialiseerd tijdreeksen databases. Het bleekDat Klik op Huis, zelfs zonder optimalisatie voor dergelijke taken, wint op een buitenlands gebied:

В tijdreeksen Meestal wordt een smalle tafel gebruikt - meerdere kleine kolommen. Er kunnen veel gegevens uit monitoring komen (miljoenen records per seconde) en deze komen meestal in kleine uitbarstingen (real-time streamen). Daarom is een ander invoegscript nodig en hebben de query's zelf hun eigen specifieke kenmerken.

Log management. Het verzamelen van loggegevens in een database is meestal slecht, maar Klik op Huis dit kan gedaan worden met enkele opmerkingen zoals hierboven beschreven. Veel bedrijven gebruiken Klik op Huis precies voor dit doel. In dit geval gebruiken we een platte brede tafel waar we de hele boomstammen in bewaren (bijvoorbeeld in de vorm JSON), of in stukjes gesneden. Gegevens worden meestal in grote batches (bestanden) geladen en we zoeken op een bepaald veld.

Voor elk van deze functies worden doorgaans gespecialiseerde databases gebruikt. Klik op Huis men kan het allemaal en zo goed dat het beter presteert dan zij. Laten we het nu eens nader bekijken tijdreeksen scenario, en hoe je correct kunt ‘koken’ Klik op Huis voor dit scenario.

Tijdreeksen

Momenteel is dit het hoofdscenario waarvoor Klik op Huis beschouwd als de standaardoplossing. Tijdreeksen is een reeks gebeurtenissen, geordend in de tijd, die veranderingen in een bepaald proces in de loop van de tijd vertegenwoordigen. Dit kan bijvoorbeeld de hartslag per dag zijn of het aantal processen in het systeem. Alles wat de tijd aangeeft, heeft bepaalde dimensies tijdreeksen:

De meeste van dit soort gebeurtenissen komen voort uit monitoring. Dit kan niet alleen het monitoren van het internet zijn, maar ook echte apparaten: auto's, industriële systemen, IoT, fabrieken of onbemande taxi's, in de kofferbak waarvan Yandex al zet Klik op Huis-server.

Er zijn bijvoorbeeld bedrijven die data verzamelen van schepen. Elke paar seconden versturen sensoren op het containerschip honderden verschillende metingen. Ingenieurs bestuderen ze, bouwen modellen en proberen te begrijpen hoe efficiënt het schip wordt gebruikt, want een containerschip mag geen seconde stil liggen. Elke stilstand is geldverlies, dus het is belangrijk om de route te voorspellen, zodat de stilstand minimaal is.

Tegenwoordig is er een groei van gespecialiseerde databases die meten tijdreeksen. Online DB-motoren De verschillende databases zijn op de een of andere manier gerangschikt en u kunt ze op type bekijken:

Het snelst groeiende type is tijdreeksenS. Graph-databases groeien ook, maar tijdreeksens zijn de afgelopen jaren sneller gegroeid. Typische vertegenwoordigers van deze familie van databases zijn InstroomDB, Prometheus, KDB, Tijdschaal DB (gebouwd op PostgreSQL), oplossingen van Amazone. Klik op Huis kan hier ook worden gebruikt, en wordt gebruikt. Ik zal u een paar openbare voorbeelden geven.

Eén van de pioniers is het bedrijf CloudFlare (CDN-aanbieder). Zij monitoren hun CDN door Klik op Huis (DNS-verzoeken, HTTP-queries) met een enorme belasting - 6 miljoen gebeurtenissen per seconde. Alles gaat door Kafka, gaat naar Klik op Huis, dat de mogelijkheid biedt om dashboards van gebeurtenissen in het systeem in realtime te bekijken.

Comcast - een van de leiders op het gebied van telecommunicatie in de VS: internet, digitale televisie, telefonie. Ze creëerden een soortgelijk controlesysteem CDN binnen het raamwerk Open Source project Apache-verkeersbeheer om met uw enorme gegevens te werken. Klik op Huis gebruikt als backend voor analyses.

Percona ingebouwd Klik op Huis binnen jouw PMMom monitoring van verschillende op te slaan MySQL.

Specifieke vereisten

Tijdreeksdatabases hebben hun eigen specifieke vereisten.

Snelle invoeging door veel agenten. We moeten gegevens uit veel stromen zeer snel invoegen. Klik op Huis Het doet dit goed omdat alle inzetstukken niet-blokkerend zijn. Elk invoegen is een nieuw bestand op schijf en kleine inserts kunnen op de een of andere manier worden gebufferd. IN Klik op Huis Het is beter om gegevens in grote batches in te voegen in plaats van regel voor regel.
Flexibel schema. In tijdreeksen we kennen de datastructuur meestal niet volledig. Het is mogelijk om voor een specifieke toepassing een monitoringsysteem te bouwen, maar dan is het lastig om het voor een andere toepassing te gebruiken. Dit vereist een flexibeler regeling. Klik op Huis, kunt u dit doen, ook al is het een sterk getypeerde basis.
Efficiënte opslag en vergeten van gegevens. Meestal binnen tijdreeksen een enorme hoeveelheid gegevens, dus deze moeten zo efficiënt mogelijk worden opgeslagen. Bijvoorbeeld bij InstroomDB goede compressie is het belangrijkste kenmerk. Maar naast opslag moet je ook oude gegevens kunnen ‘vergeten’ en iets dergelijks kunnen doen downsamplen — automatisch tellen van aggregaten.
Snelle zoekopdrachten op geaggregeerde gegevens. Soms is het interessant om naar de laatste 5 minuten te kijken met een nauwkeurigheid van milliseconden, maar bij maandelijkse gegevens is granulariteit van minuten of seconden misschien niet nodig - algemene statistieken zijn voldoende. Dit soort steun is nodig, anders duurt het zelfs binnen 3 maanden erg lang voordat de aanvraag is afgerond Klik op Huis.
Verzoeken als "laatste punt, vanaf». Deze zijn typisch voor tijdreeksen queries: bekijk de laatste meting of staat van het systeem op een bepaald moment t. Voor een database zijn dit geen prettige queries, maar je moet ze wel ook kunnen uitvoeren.
Tijdreeksen voor het "lijmen".. Tijdreeksen is een tijdreeks. Als er twee tijdreeksen zijn, moeten deze vaak met elkaar worden verbonden en gecorreleerd. Het is niet handig om dit voor alle databases te doen, vooral niet bij niet-uitgelijnde tijdreeksen: hier zijn enkele tijdstippen, er zijn andere. Je kunt uitgaan van gemiddeld, maar daar zit ineens toch nog een gat, dus het is niet duidelijk.

Laten we eens kijken hoe aan deze vereisten wordt voldaan Klik op Huis.

Het schema

В Klik op Huis schema voor tijdreeksen kan op verschillende manieren gebeuren, afhankelijk van de mate van regelmaat van de gegevens. Het is mogelijk om een systeem te bouwen op basis van reguliere gegevens als we alle statistieken van tevoren kennen. Dit heb ik bijvoorbeeld gedaan CloudFlare met monitoring CDN is een goed geoptimaliseerd systeem. Je kunt een algemener systeem bouwen dat de gehele infrastructuur en diverse diensten monitort. In het geval van onregelmatige gegevens weten we van tevoren niet wat we monitoren – en dit is waarschijnlijk het meest voorkomende geval.

Reguliere gegevens. Kolommen. Het schema is eenvoudig: kolommen met de vereiste typen:

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

Dit is een gewone tabel die een soort systeemlaadactiviteit controleert (gebruiker, system, stationair, mooi). Eenvoudig en handig, maar niet flexibel. Als we een flexibeler schema willen, kunnen we arrays gebruiken.

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

Structuur Genesteld zijn twee arrays: metrische gegevens.naam и statistieken.waarde. Hier kunt u willekeurige monitoringgegevens opslaan als een reeks namen en een reeks metingen voor elke gebeurtenis. Voor verdere optimalisatie kunt u in plaats van één dergelijke structuur er meerdere maken. Eén voor bijvoorbeeld drijven-waarde, een andere - voor int-betekenis omdat int Ik wil efficiënter opslaan.

Maar zo'n structuur is moeilijker toegankelijk. Je zult een speciale constructie moeten gebruiken, waarbij je speciale functies gebruikt om de waarden van eerst de index en vervolgens de array eruit te halen:

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

Maar het werkt nog steeds vrij snel. Een andere manier om onregelmatige gegevens op te slaan is per rij.

Onregelmatige gegevens. Snaren. Bij deze traditionele methode worden zonder arrays namen en waarden tegelijkertijd opgeslagen. Als er 5 metingen tegelijk uit één apparaat komen, worden er 000 rijen in de database gegenereerd:

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

Klik op Huis gaat hiermee om - het heeft speciale extensies Klik op Huis SQL. Bijvoorbeeld maxAls — een speciale functie die het maximum berekent met behulp van een metriek wanneer aan een bepaalde voorwaarde is voldaan. U kunt meerdere van dergelijke expressies in één verzoek schrijven en onmiddellijk de waarde voor verschillende metrieken berekenen.

Laten we drie benaderingen vergelijken:

Details

Hier heb ik "Schijfgegevensgrootte" toegevoegd voor een aantal testgegevenssets. In het geval van kolommen hebben we de kleinste datagrootte: maximale compressie, maximale querysnelheid, maar we betalen door alles in één keer vast te leggen.

In het geval van arrays is alles een beetje erger. De gegevens zijn nog steeds goed gecomprimeerd en er kan een onregelmatig patroon worden opgeslagen. Maar Klik op Huis - een kolomvormige database, en wanneer we alles in een array beginnen op te slaan, verandert het in een rij, en betalen we voor flexibiliteit met efficiëntie. Voor elke bewerking moet je de hele array in het geheugen lezen en er vervolgens het gewenste element in vinden - en als de array groeit, neemt de snelheid af.

In een van de bedrijven die deze aanpak gebruikt (bijvoorbeeld Uber), worden arrays in stukken van 128 elementen gesneden. Gegevens van enkele duizenden statistieken met een volume van 200 TB aan gegevens/dag worden niet in één array opgeslagen, maar in 10 of 30 arrays met speciale opslaglogica.

De eenvoudigste aanpak is met strings. Maar de gegevens zijn slecht gecomprimeerd, de tabelgrootte is groot en zelfs als zoekopdrachten op verschillende statistieken zijn gebaseerd, werkt ClickHouse niet optimaal.

Hybride schema

Laten we aannemen dat we een arraycircuit hebben gekozen. Maar als we weten dat de meeste van onze dashboards alleen gebruikers- en systeemstatistieken tonen, kunnen we deze statistieken bovendien op deze manier materialiseren in kolommen vanuit een array op tabelniveau:

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

Bij het inbrengen Klik op Huis telt ze automatisch. Zo kun je zaken met plezier combineren: de regeling is flexibel en algemeen, maar we hebben de meest gebruikte kolommen eruit gehaald. Merk op dat hiervoor geen vervanging van het inzetstuk en ETLdie doorgaan met het invoegen van arrays in de tabel. Dat hebben we gewoon gedaan ALTER TABLE, een paar luidsprekers toegevoegd en we hebben een hybride en sneller schema dat je meteen kunt gebruiken.

Codecs en compressie

Voor tijdreeksen Het maakt uit hoe goed u de gegevens verpakt, omdat de hoeveelheid informatie erg groot kan zijn. IN Klik op Huis Er is een reeks hulpmiddelen om een compressie-effect van 1:10, 1:20 en soms meer te bereiken. Dit betekent dat 1 TB aan uitgepakte gegevens op de schijf 50-100 GB in beslag neemt. Een kleiner formaat is goed, gegevens kunnen sneller worden gelezen en verwerkt.

Om een hoog compressieniveau te bereiken, Klik op Huis ondersteunt de volgende codecs:

Voorbeeld tabel:

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

Hier definiëren we de codec Dubbele Delta in het ene geval, in het tweede - gorilla, en we zullen er zeker meer aan toevoegen LZ4 compressie. Als gevolg hiervan wordt de grootte van de gegevens op schijf aanzienlijk verminderd:

Dit laat zien hoeveel ruimte dezelfde gegevens in beslag nemen, maar met verschillende codecs en compressies:

in een GZIP-bestand op schijf;
in ClickHouse zonder codecs, maar met ZSTD-compressie;
in ClickHouse met codecs en compressie LZ4 en ZSTD.

Het is duidelijk dat tabellen met codecs veel minder ruimte in beslag nemen.

Grootte is belangrijk

Niet minder belangrijk kiezen juiste gegevenstype:

In alle bovenstaande voorbeelden heb ik gebruikt Zweven64. Maar als we ervoor kiezen Zweven32, dan zou dat nog beter zijn. Dit werd goed gedemonstreerd door de jongens van Perkona in het hierboven gelinkte artikel. Het is belangrijk om het meest compacte type te gebruiken dat geschikt is voor de taak: nog minder voor de schijfgrootte dan voor de querysnelheid. Klik op Huis hier erg gevoelig voor.

Als je kunt gebruiken int32 in plaats van int64, verwacht dan een bijna tweevoudige prestatieverbetering. De gegevens nemen minder geheugen in beslag en alle ‘rekenkundige handelingen’ werken veel sneller. Klik op Huis intern is het een zeer streng getypeerd systeem; het maakt maximaal gebruik van alle mogelijkheden die moderne systemen bieden.

Aggregatie en Gematerialiseerde opvattingen

Met aggregatie en gematerialiseerde weergaven kunt u aggregaten maken voor verschillende gelegenheden:

U beschikt bijvoorbeeld mogelijk over niet-geaggregeerde brongegevens en u kunt er verschillende gerealiseerde weergaven aan koppelen met automatische optelling via een speciale engine SummingMergeTree (SMT). SMT is een speciale aggregerende gegevensstructuur die aggregaties automatisch berekent. Ruwe gegevens worden in de database ingevoegd, automatisch geaggregeerd en dashboards kunnen er onmiddellijk op worden gebruikt.

TTL - “vergeet” oude gegevens

Hoe kunt u gegevens ‘vergeten’ die niet langer nodig zijn? Klik op Huis weet hoe dit te doen. Bij het maken van tabellen kunt u dit opgeven TTL uitdrukkingen: bijvoorbeeld dat we minuutgegevens voor één dag opslaan, dagelijkse gegevens voor 30 dagen, en nooit wekelijkse of maandelijkse gegevens aanraken:

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

Meerdere niveaus - Verdeel gegevens over schijven

Als we dit idee verder uitwerken, kunnen gegevens worden opgeslagen in Klik op Huis op verschillende plaatsen. Stel dat we actuele gegevens van de afgelopen week op een zeer snelle lokale server willen opslaan SSD, en we plaatsen meer historische gegevens op een andere plaats. IN Klik op Huis dit is nu mogelijk:

U kunt een opslagbeleid configureren (opslagbeleid) Dus Klik op Huis zal bij het bereiken van bepaalde voorwaarden automatisch gegevens overbrengen naar een andere opslag.

Maar dat is niet alles. Op het niveau van een specifieke tabel kunt u regels definiëren voor het exacte tijdstip waarop de gegevens in de koude opslag terechtkomen. Gegevens worden bijvoorbeeld 7 dagen op een zeer snelle schijf opgeslagen en al het oudere wordt overgebracht naar een langzame schijf. Dit is goed omdat het ervoor zorgt dat het systeem maximale prestaties kan blijven leveren, terwijl de kosten onder controle worden gehouden en er geen geld wordt verspild aan koude gegevens:

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

Unieke kansen Klik op Huis

In bijna alles Klik op Huis Er zijn zulke ‘hoogtepunten’, maar deze worden gecompenseerd door exclusiviteit – iets dat niet in andere databases staat. Hier zijn bijvoorbeeld enkele van de unieke kenmerken Klik op Huis:

Arrays. In Klik op Huis zeer goede ondersteuning voor arrays, evenals de mogelijkheid om er complexe berekeningen op uit te voeren.
Gegevensstructuren aggregeren. Dit is een van de "killer features" Klik op Huis. Ondanks het feit dat de jongens van Yandex zeggen dat we geen gegevens willen aggregeren, wordt alles samengevoegd Klik op Huis, omdat het snel en gemakkelijk is.
Gematerialiseerde weergaven. Samen met het aggregeren van datastructuren kunt u met gematerialiseerde weergaven handig maken real-time aggregatie.
ClickHouseSQL. Dit is een taalextensie SQL met enkele extra en exclusieve functies die alleen beschikbaar zijn in Klik op Huis. Voorheen was het enerzijds een uitbreiding en anderzijds een nadeel. Nu bijna alle nadelen vergeleken met SQL92 we hebben het verwijderd, nu is het slechts een extensie.
Lambda–uitdrukkingen. Staan ze nog in een database?
ML-steun. Dit is beschikbaar in verschillende databases, sommige zijn beter, sommige zijn slechter.
од. Wij kunnen uitbreiden Klik op Huis samen. Nu in Klik op Huis ongeveer 500 bijdragers, en dit aantal groeit voortdurend.

Lastige vragen

В Klik op Huis er zijn veel verschillende manieren om hetzelfde te doen. U kunt bijvoorbeeld op drie verschillende manieren de laatste waarde uit een tabel retourneren CPU (er is ook een vierde, maar die is nog exotischer).

De eerste laat zien hoe handig het is om in te doen Klik op Huis vragen wanneer u dat wilt controleren tuple in de subquery. Dit is iets dat ik persoonlijk erg heb gemist in andere databases. Als ik iets wil vergelijken met een subquery, dan kan in andere databases alleen een scalaire waarde ermee worden vergeleken, maar voor meerdere kolommen moet ik schrijven AANMELDEN. In Klik op Huis je kunt tuple gebruiken:

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

De tweede methode doet hetzelfde, maar gebruikt een aggregatiefunctie argMax:

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

В Klik op Huis er zijn enkele tientallen aggregatiefuncties, en als je combinatoren gebruikt, dan krijg je er volgens de wetten van de combinatoriek ongeveer duizend van. ArgMax - een van de functies die de maximale waarde berekent: het verzoek retourneert de waarde gebruik_gebruiker, waarbij de maximale waarde wordt bereikt gemaakt bij:

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

ASOF DOE MEE — Rijen met verschillende tijden “lijmen”. Dit is een unieke functie voor databases die alleen beschikbaar is in kdb +. Als er twee tijdreeksen zijn met verschillende tijden, ASOF DOE MEE Hiermee kunt u ze in één verzoek verplaatsen en samenvoegen. Voor elke waarde in de ene tijdreeks wordt de dichtstbijzijnde waarde in de andere gevonden, en deze worden op dezelfde regel geretourneerd:

Analytische functies

In de standaard SQL-2003 je kunt zo schrijven:

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;

В Klik op Huis Dat kun je niet doen; het ondersteunt de standaard niet SQL-2003 en zal het waarschijnlijk nooit doen. In plaats daarvan, binnen Klik op Huis Het is gebruikelijk om als volgt te schrijven:

Ik heb lambda's beloofd - hier zijn ze!

Dit is analoog aan de analytische vraag in de standaard SQL-2003: hij telt het verschil tussen de twee tijdstempel, duur, rangtelwoord - alles wat we gewoonlijk als analytische functies beschouwen. IN Klik op Huis We tellen ze via arrays: eerst vouwen we de gegevens samen in een array, daarna doen we alles wat we willen op de array, en dan breiden we deze weer uit. Het is niet erg handig, het vereist op zijn minst liefde voor functioneel programmeren, maar het is erg flexibel.

Speciale kenmerken

Bovendien, binnen Klik op Huis veel gespecialiseerde functies. Hoe bepaal je bijvoorbeeld hoeveel sessies er tegelijkertijd plaatsvinden? Een typische monitoringtaak is het bepalen van de maximale belasting met één verzoek. IN Klik op Huis Hiervoor bestaat een speciale functie:

Over het algemeen heeft ClickHouse speciale functies voor vele doeleinden:

hardlopenVerschil, hardlopenAccumuleren, buurman;
sumMap(sleutel, waarde);
timeSeriesGroupSum(uid, tijdstempel, waarde);
timeSeriesGroupRateSum(uid, tijdstempel, waarde);
skewPop, skewSamp, kurtPop, kurtSamp;
MET VULLING / MET BANDEN;
simpleLinearRegressie, stochastischeLineaireRegressie.

Dit is geen volledige lijst met functies, er zijn er in totaal 500-600. Tip: alle functies in Klik op Huis staat in de systeemtabel (niet alle zijn gedocumenteerd, maar ze zijn allemaal interessant):

select * from system.functions order by name

Klik op Huis het slaat veel informatie over zichzelf op, inclusief log tabellen, query_log, traceerlogboek, logboek van bewerkingen met datablokken (deel_log), metrische gegevenslogboek en systeemlogboek, dat gewoonlijk naar schijf wordt geschreven. Logboekstatistieken zijn tijdreeksen в Klik op Huis Eigenlijk Klik op Huis: De database zelf kan een rol spelen tijdreeksen databases, waardoor ze zichzelf ‘verslinden’.

Dat is ook iets unieks, want we doen er goed werk voor tijdreeksenWaarom kunnen we niet alles wat we nodig hebben in onszelf opslaan? We hebben niet nodig Prometheus, wij houden alles voor onszelf. Verbonden grafana en we houden onszelf in de gaten. Echter, als Klik op Huis valt, we zullen niet zien waarom, dus dat doen ze meestal niet.

Grote cluster of veel kleine Klik op Huis

Wat is beter: één groot cluster of veel kleine ClickHouses? Traditionele aanpak van DWH is een groot cluster waarin voor elke toepassing circuits zijn toegewezen. We kwamen bij de databasebeheerder - geef ons een diagram, en zij gaven ons er een:

В Klik op Huis je kunt het anders doen. U kunt elke toepassing uw eigen maken Klik op Huis:

We hebben het grote monster niet meer nodig DWH en hardnekkige beheerders. Wij kunnen elke toepassing zijn eigen toepassing geven Klik op Huis, en sindsdien kan de ontwikkelaar het zelf doen Klik op Huis zeer eenvoudig te installeren en vereist geen complex beheer:

Maar als we veel hebben Klik op Huis, en je moet het vaak installeren, dan wil je dit proces automatiseren. Hiervoor kunnen we bijvoorbeeld gebruik maken van Kubernetes и klikhuis-operator. IN Kubernetes ClickHouse je kunt het “on-click” zetten: ik kan op een knop klikken, het manifest uitvoeren en de database is klaar. Ik kan meteen een diagram maken, daar statistieken uploaden en binnen 5 minuten heb ik een dashboard klaar grafana. Het is zo makkelijk!

Het resultaat?

aldus Klik op Huis - Dit:

snel. Iedereen weet dit.
gewoon. Een beetje controversieel, maar ik geloof dat het moeilijk is tijdens de training, gemakkelijk in de strijd. Als je begrijpt hoe Klik op Huis het werkt, dan is alles heel eenvoudig.
Universeel. Het is geschikt voor verschillende scenario's: DWH, tijdreeksen, logopslag. Maar het is niet OLTP database, dus probeer daar geen korte invoegingen en leesbewerkingen uit te voeren.
Belangwekkend. Waarschijnlijk degene die meewerkt Klik op Huis, veel interessante momenten meegemaakt in goede en slechte zin. Er kwam bijvoorbeeld een nieuwe release uit, alles werkte niet meer. Of wanneer je twee dagen met een taak worstelde, maar na het stellen van een vraag in de Telegram-chat, de taak binnen twee minuten was opgelost. Of zoals op de conferentie bij het verslag van Lesha Milovidov, een screenshot van Klik op Huis brak de uitzending HighLoad ++. Dit soort dingen gebeuren voortdurend en maken ons leven moeilijk. Klik op Huis helder en interessant!

U kunt de presentatie bekijken hier.

De langverwachte bijeenkomst van ontwikkelaars van systemen met hoge belasting op HighLoad ++ vindt plaats op 9 en 10 november in Skolkovo. Ten slotte zal dit een offline conferentie zijn (zij het met alle voorzorgsmaatregelen), aangezien de energie van HighLoad++ niet online kan worden verpakt.

Voor de conferentie zoeken en laten we u cases zien over de maximale mogelijkheden van technologie: HighLoad++ was, is en zal de enige plek zijn waar je in twee dagen kunt leren hoe Facebook, Yandex, VKontakte, Google en Amazon werken.

Nadat we onze vergaderingen sinds 2007 zonder onderbreking hebben gehouden, komen we dit jaar voor de 14e keer samen. Gedurende deze tijd is de conferentie tien keer zo groot geworden; vorig jaar bracht het belangrijkste branche-evenement 10 deelnemers, 3339 sprekers, rapporten en meetups samen, en er liepen 165 tracks tegelijkertijd.
Vorig jaar waren er 20 bussen, 5280 liter thee en koffie, 1650 liter vruchtendranken en 10200 flessen water. En nog eens 2640 kilogram voedsel, 16 borden en 000 kopjes. Met het ingezamelde geld van gerecycled papier hebben we trouwens 25 eikenzaailingen geplant :)

Je kunt kaartjes kopen hier, ontvang nieuws over de conferentie - hier, en praat op alle sociale netwerken: Telegram, Facebook, Vkontakte и Twitter.

Bron: www.habr.com

Verhuizen naar ClickHouse: 3 jaar later