Aangesien ClickHouse 'n gespesialiseerde stelsel is, is dit belangrik om die eienaardighede van sy argitektuur in ag te neem wanneer dit gebruik word. In hierdie verslag sal Alexey praat oor voorbeelde van tipiese foute by die gebruik van ClickHouse, wat tot ondoeltreffende werk kan lei. Deur praktiese voorbeelde te gebruik, sal ons wys hoe die keuse van een of ander dataverwerkingskema prestasie in ordes van grootte kan verander.
Hi almal! My naam is Alexey, ek skep ClickHouse.
Eerstens, ek haas om jou dadelik tevrede te stel, ek sal jou nie vandag vertel wat ClickHouse is nie. Om eerlik te wees, ek is moeg daarvoor. Ek vertel jou elke keer wat dit is. En seker weet almal reeds.
In plaas daarvan sal ek jou vertel wat die moontlike hark is, dit wil sê hoe ClickHouse misbruik kan word. Trouens, jy moet nie bang wees nie, want ons ontwikkel ClickHouse as 'n stelsel wat eenvoudig, gerieflik is en uit die boks werk. Alles geïnstalleer, geen probleem nie.
Maar tog moet daar in gedagte gehou word dat hierdie stelsel gespesialiseerd is en jy kan maklik op 'n ongewone gebruiksgeval afkom wat hierdie stelsel uit sy gemaksone sal haal.
So, wat is die harke? Basies sal ek praat oor die ooglopende dinge. Alles is duidelik vir almal, almal verstaan alles en kan bly wees dat hulle so slim is, en die wat nie verstaan nie, sal iets nuuts leer.
Die eerste eenvoudigste voorbeeld, wat ongelukkig dikwels voorkom, is 'n groot aantal insetsels met klein bondels, dit wil sê 'n groot aantal klein insetsels.
As ons oorweeg hoe ClickHouse 'n invoeging uitvoer, dan kan u ten minste 'n teragreep data in een versoek stuur. Dit is nie 'n probleem nie.
En kom ons kyk wat die tipiese prestasie sal wees. Ons het byvoorbeeld 'n tabel met Yandex.Metrica-data. Treffers. 105 sommige kolomme. 700 grepe ongecomprimeerd. En ons sal op 'n goeie manier bondels van een miljoen reëls invoeg.
Ons voeg in die MergeTree-tabel in, 'n halfmiljoen rye per sekonde word verkry. Groot. In 'n gerepliseerde tabel - dit sal 'n bietjie minder wees, ongeveer 400 000 rye per sekonde.
En as jy die kworum-insetsel aanskakel, kry jy 'n bietjie minder, maar steeds ordentlike prestasie, 250 000 keer per sekonde. Kworuminvoeging is 'n ongedokumenteerde kenmerk in ClickHouse*.
* vanaf 2020, .
Wat gebeur as jy dit verkeerd doen? Ons voeg een ry in die MergeTree-tabel in en ons kry 59 rye per sekonde. Dit is 10 000 keer stadig. In ReplicatedMergeTree - 6 rye per sekonde. En as die kworum aanskakel, word 2 reëls per sekonde verkry. Na my mening is dit 'n soort van volslae kak. Hoe kan jy so vertraag? Daar staan selfs op my T-hemp dat ClickHouse nie moet vertraag nie. Maar nietemin gebeur dit soms.
Trouens, dit is ons tekortkoming. Ons kon dit net goed laat werk het, maar ons het nie. En ons het nie, want ons draaiboek het dit nie nodig gehad nie. Ons het reeds groepe gehad. Ons het pas bondels by die ingang ontvang, en geen probleme nie. Prop dit in en alles werk goed. Maar natuurlik is allerhande scenario's moontlik. Byvoorbeeld, wanneer jy 'n klomp bedieners het waarop data gegenereer word. En hulle voeg nie data so gereeld in nie, maar hulle kry steeds gereelde invoegings. En jy moet dit op een of ander manier vermy.
Vanuit 'n tegniese oogpunt is die slotsom dat wanneer jy 'n insetsel in ClickHouse doen, die data nie in enige memtable kom nie. Ons het nie eers 'n ware MergeTree-logstruktuur nie, maar net 'n MergeTree, want daar is nie log of memTable nie. Ons skryf net dadelik die data na die lêerstelsel, wat reeds in kolomme ontbind is. En as jy 100 kolomme het, sal meer as 200 lêers na 'n aparte gids geskryf moet word. Dit alles is baie omslagtig.
En die vraag ontstaan: "Hoe om dit reg te doen?" As so 'n situasie, moet jy steeds op een of ander manier data aan ClickHouse skryf.
Metode 1. Dit is die maklikste manier. Gebruik 'n soort verspreide tou. Byvoorbeeld, Kafka. Jy haal net data uit Kafka, ons versamel dit een keer per sekonde. En alles sal reg wees, jy teken op, alles werk goed.
Die nadele is dat Kafka nog 'n omslagtige verspreide stelsel is. Ek verstaan ook as jy reeds Kafka in jou geselskap het. Dit is goed, dit is gerieflik. Maar as dit nie daar is nie, moet jy drie keer dink voordat jy 'n ander verspreide stelsel in jou projek sleep. En daarom is dit die moeite werd om alternatiewe te oorweeg.
Metode 2. Hier is so 'n ouskool alternatief en terselfdertyd baie eenvoudig. Het jy 'n soort bediener wat jou logs genereer. En dit skryf net jou logs na 'n lêer. En een keer per sekonde hernoem ons byvoorbeeld hierdie lêer, maak 'n nuwe een oop. En 'n aparte skrif óf deur cron óf een of ander daemon neem die oudste lêer en skryf dit na ClickHouse. As jy een keer per sekonde logs skryf, sal alles in orde wees.
Maar die nadeel van hierdie metode is dat as jou bediener waarop die logs gegenereer word iewers verdwyn het, dan sal die data ook verdwyn.
Metode 3. Daar is nog 'n interessante manier, wat glad nie tydelike lêers is nie. Byvoorbeeld, jy het 'n soort advertensiedraaier of 'n ander interessante demoon wat data genereer. En jy kan 'n klomp data ophoop reg in die RAM, in die buffer. En wanneer 'n voldoende hoeveelheid tyd verbygaan, sit jy hierdie buffer opsy, skep 'n nuwe een en voeg dit wat reeds opgehoop het in ClickHouse in 'n aparte draad in.
Aan die ander kant verdwyn die data ook met kill -9. As jou bediener afgaan, sal jy hierdie data verloor. En nog 'n probleem is dat as jy nie na die databasis kon skryf nie, dan sal jou data in die RAM ophoop. En óf die RAM raak op, óf jy verloor net data.
Metode 4. Nog 'n interessante manier. Het jy enige bediener proses. En hy kan data op een slag na ClickHouse stuur, maar doen dit in een verbinding. Ek het byvoorbeeld 'n http-versoek gestuur met oordrag-enkodering: gekap met invoegsel. En dit genereer stukke nie te selde nie, jy kan elke reël stuur, alhoewel daar 'n oorhoofse koste sal wees om hierdie data te raam.
In hierdie geval sal die data egter onmiddellik na ClickHouse gestuur word. En ClickHouse self sal hulle buffer.
Maar daar is ook probleme. Nou sal jy data verloor, insluitend wanneer jou proses doodgemaak word en as die ClickHouse-proses doodgemaak word, want dit sal 'n onvolledige insetsel wees. En in ClickHouse is insetsels atoom tot 'n sekere drempel in die grootte van rye. In beginsel is dit 'n interessante manier. Kan ook gebruik word.
Metode 5. Hier is nog 'n interessante manier. Dit is 'n soort van gemeenskap-ontwikkelde bediener vir data bondel. Ek het nog nie self daarna gekyk nie, so ek kan niks waarborg nie. Daar is egter geen waarborge vir ClickHouse self nie. Dit is ook oopbron, maar aan die ander kant kan jy gewoond raak aan een of ander kwaliteitstandaard wat ons probeer voorsien. Maar vir hierdie ding - ek weet nie, gaan na GitHub, kyk na die kode. Miskien het hulle iets goed geskryf.
* vanaf 2020, moet ook by oorweging gevoeg word .
Metode 6. Nog 'n manier is om Buffertabelle te gebruik. Die voordeel van hierdie metode is dat dit baie maklik is om te begin gebruik. Skep 'n buffertabel en plaas dit daarin.
Maar die nadeel is dat die probleem nie heeltemal opgelos is nie. As jy teen 'n tempo van die MergeTree-tipe data met een bondel per sekonde moet groepeer, dan moet jy teen 'n tempo in 'n buffertabel ten minste tot 'n paar duisend per sekonde groepeer. As daar meer as 10 000 per sekonde is, sal dit steeds sleg wees. En as jy in bondels invoeg, dan het jy gesien dat daar honderdduisend reëls per sekonde verkry word. En dit is reeds op redelik swaar data.
En ook buffertabelle het nie 'n log nie. En as daar iets fout is met jou bediener, sal die data verlore gaan.
En as 'n bonus het ons onlangs die geleentheid gehad om data van Kafka in ClickHouse in te samel. Daar is 'n tafelenjin - Kafka. Jy skep bloot. En jy kan gematerialiseerde sienings daaraan hang. In hierdie geval sal hy die data van Kafka uithaal en dit in die tabelle wat jy benodig, invoeg.
En wat veral aan hierdie geleentheid aangenaam is, is dat ons dit nie gemaak het nie. Dit is 'n gemeenskapskenmerk. En as ek sê "gemeenskapskenmerk", sê ek dit sonder enige minagting. Ons het die kode gelees, 'n hersiening gedoen, dit behoort goed te werk.
* vanaf 2020 is daar soortgelyke ondersteuning vir .
Wat anders kan ongerieflik of onverwags wees wanneer data ingevoeg word? As jy 'n invoegwaardes-navraag maak en 'n paar berekende uitdrukkings in waardes skryf. Byvoorbeeld, now() is ook 'n geëvalueerde uitdrukking. En in hierdie geval word ClickHouse gedwing om die tolk van hierdie uitdrukkings vir elke reël te begin, en prestasie sal met ordes van grootte daal. Dit is beter om dit te vermy.
* op die oomblik is die probleem heeltemal opgelos, daar is geen prestasieregressie meer wanneer uitdrukkings in VALUES gebruik word nie.
Nog 'n voorbeeld waar daar probleme kan wees, is wanneer jou data op een bondel aan 'n klomp partisies behoort. By verstek, ClickHouse partisies per maand. En as jy 'n bondel van 'n miljoen rye invoeg, en daar is data vir 'n paar jaar, dan sal jy 'n paar dosyn partisies daar hê. En dit is gelykstaande aan die feit dat daar groepe 'n paar tiene keer kleiner sal wees, want binne word hulle altyd eers in partisies verdeel.
* het onlangs in ClickHouse in eksperimentele modus ondersteuning bygevoeg vir die kompakte formaat van stukke en stukke in RAM met voorskryf-logboek, wat die probleem byna heeltemal oplos.
Oorweeg nou die tweede soort probleem - datatik.
Datatik kan streng wees, en soms string. String - dit is wanneer jy net geneem en verklaar het dat jy alle velde van tipe string het. Dit suig. Jy hoef dit nie te doen nie.
Kom ons vind uit hoe om dit reg te doen in gevalle waar jy wil sê dat ons een of ander veld, 'n tou het, en laat ClickHouse dit op sy eie uitvind, maar ek sal nie 'n stoombad neem nie. Maar dit is steeds die moeite werd om moeite te doen.
Ons het byvoorbeeld 'n IP-adres. In een geval het ons dit as 'n tou gestoor. Byvoorbeeld, 192.168.1.1. Andersins sal dit 'n aantal tipe UInt32* wees. 32 bisse is genoeg vir 'n IPv4-adres.
Eerstens, vreemd genoeg, sal die data omtrent dieselfde saamgepers word. Daar sal 'n verskil wees, seker, maar nie so groot nie. Daar is dus geen spesiale probleme met skyf I/O nie.
Maar daar is 'n ernstige verskil in SVE tyd en navraag uitvoering tyd.
Kom ons tel die aantal unieke IP-adresse as hulle as nommers gestoor word. Dit blyk 137 miljoen reëls per sekonde. As dieselfde as lyne, dan 37 miljoen lyne per sekonde. Ek weet nie hoekom hierdie toeval gebeur het nie. Ek het hierdie versoeke self gedoen. Maar nietemin so 4 keer stadiger.
En as jy die verskil in skyfspasie bereken, dan is daar ook 'n verskil. En die verskil is ongeveer een kwart, want daar is heelwat unieke IP-adresse. En as daar reëls was met 'n klein aantal verskillende waardes, dan sou dit stilweg in die woordeboek saamgepers gewees het in ongeveer dieselfde volume.
En die viervoudige tydsverskil lê nie op die pad nie. Miskien gee jy natuurlik nie om nie, maar as ek so 'n verskil sien, voel ek hartseer.
Kom ons kyk na verskillende gevalle.
1. Een geval wanneer jy min verskillende unieke waardes het. In hierdie geval gebruik ons 'n eenvoudige praktyk wat jy waarskynlik ken en kan gebruik vir enige DBBS. Dit maak alles sin nie net vir ClickHouse nie. Skryf net die numeriese identifiseerders na die databasis. En jy kan omskakel na snare en terug aan die kant van jou aansoek.
Byvoorbeeld, jy het 'n streek. En jy probeer dit as 'n tou stoor. En daar sal geskrywe staan: Moskou en Moskou-streek. En as ek sien dat "Moskou" daar geskryf is, dan is dit nog niks, en as dit MO is, word dit op een of ander manier heeltemal hartseer. Dit is hoeveel grepe.
In plaas daarvan skryf ons eenvoudig die Ulnt32-nommer en 250 neer. Ons het 250 in Yandex, maar joune kan anders wees. Net vir ingeval, sal ek sê dat ClickHouse 'n ingeboude vermoë het om met 'n geobasis te werk. Jy skryf eenvoudig 'n gids met streke neer, insluitend 'n hiërargiese een, dit wil sê daar sal Moskou, Moskou-streek wees en alles wat jy nodig het. En jy kan op versoekvlak omskakel.
Die tweede opsie is omtrent dieselfde, maar met ondersteuning binne ClickHouse. Dit is 'n Enum-datatipe. Jy skryf eenvoudig al die waardes wat jy nodig het in die Enum. Byvoorbeeld, die tipe toestel en skryf daar: lessenaar, selfoon, tablet, TV. Slegs 4 opsies.
Die nadeel is dat jy periodiek moet verander. Slegs een opsie is bygevoeg. Ons maak alter tafel. Trouens, verander tabel in ClickHouse is gratis. Veral gratis vir Enum omdat die data op skyf nie verander nie. Maar nietemin, alter kry 'n slot * op die tafel en moet wag totdat alle keuses voltooi is. En eers nadat hierdie wysiging uitgevoer sal word, dit wil sê, daar is nog 'n paar ongerief.
* In onlangse weergawes van ClickHouse word ALTER heeltemal nie-blokkerend gemaak.
Nog 'n opsie wat baie uniek is vir ClickHouse is die koppeling van eksterne woordeboeke. Jy kan nommers in ClickHouse skryf en jou gidse in enige stelsel hou wat vir jou gerieflik is. Byvoorbeeld, jy kan gebruik: MySQL, Mongo, Postgres. Jy kan selfs jou eie mikrodiens skep, wat hierdie data via http sal stuur. En op die ClickHouse-vlak skryf jy 'n funksie wat hierdie data van getalle na stringe sal omskakel.
Dit is 'n gespesialiseerde maar baie doeltreffende manier om 'n aansluiting op 'n eksterne tafel uit te voer. En daar is twee opsies. In een opsie sal hierdie data volledig in die kas geberg word, volledig in die RAM teenwoordig wees en met sekere tussenposes opgedateer word. En in 'n ander opsie, as hierdie data nie in die RAM pas nie, kan u dit gedeeltelik kas.
Hier is 'n voorbeeld. Daar is Yandex.Direct. En daar is 'n advertensiemaatskappy en baniere. Daar is seker tienmiljoene advertensiemaatskappye. En pas ongeveer in die RAM. En daar is biljoene baniere, hulle pas nie. En ons gebruik 'n kaswoordeboek van MySQL.
Die enigste probleem is dat die kaswoordeboek goed sal werk as die trefkoers naby aan 100% is. As dit kleiner is, sal dit nodig wees om die ontbrekende sleutels in werklikheid te neem wanneer u versoeke vir elke datapak verwerk en data van MySQL af neem. Oor ClickHouse kan ek dit steeds waarborg - ja, dit vertraag nie, ek sal nie oor ander stelsels praat nie.
En as 'n bonus is woordeboeke 'n baie maklike manier om data in ClickHouse terugwerkend op te dateer. Dit wil sê, jy het 'n verslag oor advertensiemaatskappye gehad, die gebruiker het eenvoudig die advertensiemaatskappy verander en in al die ou data, in alle verslae, het hierdie data ook verander. As jy rye direk na die tabel skryf, sal jy dit nie kan opdateer nie.
Nog 'n manier wanneer jy nie weet waar om die identifiseerders vir jou snare te kry nie. jy kan net hash. En die maklikste opsie is om 'n 64-bis hash te neem.
Die enigste probleem is dat as die hash 64-bis is, jy byna seker botsings sal hê. Want as daar 'n biljoen lyne is, dan word die waarskynlikheid reeds tasbaar.
En dit sal nie baie goed wees om die name van advertensiemaatskappye so te hash nie. As die advertensieveldtogte van verskillende maatskappye deurmekaar raak, dan sal daar iets onverstaanbaars wees.
En daar is 'n eenvoudige truuk. Dit is weliswaar ook nie baie geskik vir ernstige data nie, maar as iets nie baie ernstig is nie, voeg eenvoudig nog 'n kliëntidentifiseerder by die woordeboeksleutel. En dan sal jy botsings hê, maar net binne een kliënt. En ons gebruik hierdie metode vir die skakelkaart in Yandex.Metrica. Ons het URL's daar, ons stoor hashes. En ons weet dat daar konflikte is, natuurlik. Maar wanneer 'n bladsy vertoon word, dan is die waarskynlikheid dat dit op een bladsy vir een gebruiker is dat sommige URL's bymekaar bly en dit sal opgemerk word, dan kan dit afgeskeep word.
As 'n bonus, vir baie operasies is slegs hashes genoeg en die snare self kan nêrens gestoor word nie.
Nog 'n voorbeeld as die stringe kort is, soos webwerf-domeine. Hulle kan gestoor word soos dit is. Of, byvoorbeeld, die blaaiertaal ru is 2 grepe. Natuurlik kry ek die grepe jammer, maar moenie bekommerd wees nie, 2 grepe is nie jammer nie. Hou dit asseblief soos dit is, moenie bekommerd wees nie.
Nog 'n geval is wanneer daar inteendeel baie snare is en terselfdertyd baie uniekes daarin is, en selfs die stel is potensieel onbeperk. 'n Tipiese voorbeeld is soekfrases of URL's. Soek frases, insluitend as gevolg van tikfoute. Kom ons kyk hoeveel unieke soekfrases per dag. En dit blyk dat hulle byna die helfte van alle gebeurtenisse is. En in hierdie geval kan u dink dat u die data moet normaliseer, die identifiseerders moet tel, dit in 'n aparte tabel moet plaas. Maar jy hoef dit nie te doen nie. Hou net hierdie lyne soos dit is.
Beter - moenie iets uitvind nie, want as jy dit apart stoor, sal jy 'n aansluiting moet doen. En hierdie join is op sy beste 'n ewekansige toegang tot geheue, as dit nog in die geheue pas. As dit nie pas nie, sal daar in die algemeen probleme wees.
En as die data in plek gestoor word, dan word dit eenvoudig in die regte volgorde van die lêerstelsel gelees en alles is in orde.
As jy URL's of 'n ander komplekse lang string het, moet jy daaraan dink dat jy vooraf 'n bietjie druk kan bereken en dit in 'n aparte kolom kan skryf.
Vir URL's, byvoorbeeld, kan jy die domein afsonderlik stoor. En as jy regtig 'n domein nodig het, gebruik dan net hierdie kolom, en die URL's sal lieg, en jy sal nie eers daaraan raak nie.
Kom ons kyk wat die verskil is. ClickHouse het 'n gespesialiseerde funksie wat die domein bereken. Dit is baie vinnig, ons het dit geoptimaliseer. En om eerlik te wees, dit voldoen nie eens aan die RFC nie, maar dit neem nietemin alles in ag wat ons nodig het.
En in een geval sal ons eenvoudig die URL's kry en die domein bereken. Dit blyk 166 millisekondes. En as jy 'n klaargemaakte domein neem, dan blyk dit net 67 millisekondes, dit wil sê amper drie keer vinniger. En vinniger, nie omdat ons 'n paar berekeninge moet doen nie, maar omdat ons minder data lees.
Om een of ander rede kry een versoek, wat stadiger is, meer spoed in gigagrepe per sekonde. Omdat dit meer gigagrepe lees. Dit is heeltemal oortollige data. Dit lyk asof die versoek vinniger loop, maar dit neem langer om te voltooi.
En as jy kyk na die hoeveelheid data op die skyf, blyk dit dat die URL 126 megagrepe is, en die domein is slegs 5 megagrepe. Dit blyk 25 keer minder. Die navraag is egter steeds net 4 keer vinniger. Maar dit is omdat die data warm is. En as dit koud was, sou dit waarskynlik 25 keer vinniger wees as gevolg van skyf I/O.
Terloops, as jy evalueer hoeveel die domein minder is as die URL, dan blyk dit ongeveer 4 keer te wees, maar om een of ander rede neem die data op die skyf 25 keer minder. Hoekom? As gevolg van kompressie. En die url is saamgepers, en die domein is saamgepers. Maar dikwels bevat die url 'n klomp rommel.
En dit is natuurlik die moeite werd om die regte datatipes te gebruik wat spesifiek ontwerp is vir die regte waardes of wat pas. As jy in IPv4 is, stoor dan UInt32*. As IPv6, dan FixedString(16), want 'n IPv6-adres is 128 bisse, d.w.s. stoor direk in binêre formaat.
Maar wat as jy soms IPv4-adresse en soms IPv6 het? Ja, jy kan albei hou. Een kolom vir IPv4, 'n ander vir IPv6. Natuurlik is daar 'n opsie om IPv4 na IPv6 te karteer. Dit sal ook werk, maar as jy dikwels 'n IPv4-adres in jou versoeke benodig, sal dit lekker wees om dit in 'n aparte kolom te plaas.
* Nou het ClickHouse aparte IPv4, IPv6 datatipes wat data so doeltreffend soos syfers stoor, maar dit so gerieflik soos stringe voorstel.
Dit is ook belangrik om daarop te let dat dit die moeite werd is om die data vooraf te verwerk. Byvoorbeeld, sommige rou logs kom na jou toe. En miskien moet jy dit nie dadelik in ClickHouse plaas nie, alhoewel dit baie aanloklik is om niks te doen nie en alles sal werk. Maar dit is steeds die moeite werd om daardie berekeninge uit te voer wat moontlik is.
Byvoorbeeld, blaaier weergawe. In een of ander naburige departement, waarna ek nie die vinger wil wys nie, word die blaaierweergawe so daar gestoor, dit wil sê as 'n string: 12.3. En dan, om 'n verslag te maak, neem hulle hierdie tou en deel deur 'n skikking, en dan deur die eerste element van die skikking. Natuurlik vertraag alles. Ek het gevra hoekom hulle dit doen. Hulle het vir my gesê dat hulle nie van voortydige optimalisering hou nie. En ek hou nie van voortydige pessimisme nie.
So in hierdie geval sal dit meer korrek wees om in 4 kolomme te verdeel. Moenie hier bang wees nie, want dit is ClickHouse. ClickHouse is 'n kolom databasis. En hoe netjieser kolomme, hoe beter. Daar sal 5 BrowserVersion wees, maak 5 kolomme. Dit is goed.
Oorweeg nou wat om te doen as jy baie lang stringe, baie lang skikkings het. Hulle hoef glad nie in ClickHouse gestoor te word nie. In plaas daarvan kan jy net 'n paar identifiseerder in ClickHouse stoor. En hierdie lang rye stoot hulle in 'n ander stelsel.
Byvoorbeeld, een van ons ontledingsdienste het 'n paar gebeurtenisparameters. En as daar baie parameters by gebeure kom, stoor ons eenvoudig die eerste 512 wat teëkom, want 512 is nie jammer nie.
En as jy nie oor jou datatipes kan besluit nie, dan kan jy ook data na ClickHouse skryf, maar na 'n tydelike tabel van die Log-tipe, wat spesiaal is vir tydelike data. Daarna kan jy ontleed watter soort verspreiding van waardes jy daar het, wat oor die algemeen daar is en die korrekte tipes opmaak.
* Nou het ClickHouse 'n datatipe wat jou toelaat om stringe doeltreffend met minder moeite te stoor.
Oorweeg nou nog 'n interessante geval. Soms werk dinge op 'n vreemde manier vir mense. Ek gaan kyk dit. En dit blyk dadelik dat dit gedoen is deur 'n baie ervare, slim administrateur wat uitgebreide ervaring het met die opstel van MySQL weergawe 3.23.
Hier sien ons 'n duisend tabelle, wat elkeen die res bevat van deling is nie duidelik wat deur 'n duisend nie.
In beginsel respekteer ek ander mense se ervaring, insluitend om te verstaan watter soort lyding hierdie ervaring opgedoen kan word.
En die redes is min of meer duidelik. Dit is ou stereotipes wat moontlik opgehoop het terwyl jy met ander stelsels gewerk het. MyISAM-tabelle het byvoorbeeld nie 'n gegroepeerde primêre sleutel nie. En hierdie manier om data te deel kan 'n desperate poging wees om dieselfde funksionaliteit te kry.
Nog 'n rede is dat dit moeilik is om enige veranderingsbewerkings op groot tafels te doen. Alles sal geblokkeer word. Alhoewel dit in moderne weergawes van MySQL is, is hierdie probleem nie meer so ernstig nie.
Of, byvoorbeeld, microsharding, maar later meer daaroor.
In ClickHouse hoef u dit nie te doen nie, want eerstens is die primêre sleutel gegroepeer, die data word volgens die primêre sleutel gerangskik.
En soms vra mense my: "Hoe verander die prestasie van reeksnavrae in ClickHouse met die grootte van die tabel?". Ek sê dit verander glad nie. Byvoorbeeld, jy het 'n tabel met 'n miljard rye en jy lees 'n reeks van een miljoen rye. Alles is reg. As die tabel 'n biljoen rye het en jy lees een miljoen rye, dan sal dit amper dieselfde wees.
En tweedens, enige stukke soos handafskortings is nie nodig nie. As jy ingaan en kyk na wat op die lêerstelsel is, sal jy sien dat 'n tabel 'n redelik ernstige ding is. En daar binne is iets soos afskortings. Dit wil sê, ClickHouse doen alles vir jou en jy hoef nie te ly nie.
Verander in ClickHouse is gratis as verander voeg/verlaat kolom.
En jy moenie klein tabelle maak nie, want as jy 10 rye of 10 000 rye in jou tabel het, dan maak dit glad nie saak nie. ClickHouse is 'n stelsel wat deurset optimaliseer, nie latensie nie, so dit maak geen sin om 10 reëls te verwerk nie.
Dit is korrek om een groot tafel te gebruik. Raak ontslae van die ou stereotipes, alles sal regkom.
En as 'n bonus, in die nuutste weergawe, het ons die geleentheid om 'n arbitrêre partisiesleutel te maak om allerhande instandhoudingsoperasies op individuele partisies uit te voer.
Byvoorbeeld, jy het baie klein tabelle nodig, byvoorbeeld, wanneer daar 'n behoefte is om 'n paar intermediêre data te verwerk, ontvang jy stukke en jy moet 'n transformasie daarop uitvoer voordat jy na die finale tabel skryf. Vir hierdie geval is daar 'n wonderlike tafelenjin - StripeLog. Dit is soos TinyLog, net beter.
* Nou het ClickHouse meer .
Nog 'n anti-patroon is mikrosharding. Byvoorbeeld, jy moet data versnipper en jy het 5 bedieners, en môre sal daar 6 bedieners wees. En jy dink hoe om hierdie data te herbalanseer. En in plaas daarvan verdeel jy nie in 5 skerwe nie, maar in 1 000 skerwe. En dan karteer jy elkeen van hierdie mikroskerwe na 'n aparte bediener. En jy sal slaag op een bediener, byvoorbeeld, 200 ClickHouse, byvoorbeeld. Afsonderlike instansie op aparte poorte of aparte databasisse.
Maar in ClickHouse is dit nie baie goed nie. Omdat selfs een geval van ClickHouse probeer om alle beskikbare bedienerhulpbronne te gebruik om een versoek te verwerk. Dit wil sê, jy het 'n soort bediener en daar is byvoorbeeld 56 verwerkerkerne. Jy voer 'n navraag wat een sekonde neem en dit sal 56 kerns gebruik. En as jy 200 ClickHouses op een bediener daar geplaas het, dan blyk dit dat 10 000 drade sal begin. Oor die algemeen sal alles baie sleg wees.
Nog 'n rede is dat die verspreiding van werk oor hierdie gevalle ongelyk sal wees. Sommige sal vroeër klaarmaak, ander sal later klaarmaak. As dit alles in een geval gebeur het, sou ClickHouse self uitgevind het hoe om die data korrek tussen die strome te versprei.
En nog 'n rede is dat jy interverwerker kommunikasie oor TCP sal hê. Die data sal geserialiseer, gedeserialiseer moet word, en dit is 'n groot aantal mikroskerwe. Dit sal net nie werk nie.
Nog 'n antipatroon, hoewel dit beswaarlik 'n antipatroon genoem kan word. Dit is 'n groot hoeveelheid vooraf-aggregasie.
Oor die algemeen is preaggregasie goed. Jy het 'n miljard rye gehad, jy het dit saamgevoeg en dit het 1 000 rye geword, en nou word die navraag onmiddellik uitgevoer. Alles is puik. Dis hoe jy dit kan doen. En hiervoor het selfs ClickHouse 'n spesiale AggregatingMergeTree-tabeltipe wat inkrementele samevoeging doen soos data ingevoeg word.
Maar daar is tye wanneer jy dink dat ons data soos hierdie sal versamel en data soos hierdie sal saamvoeg. En in een of ander naburige departement wil ek ook nie sê watter een nie, hulle gebruik SummingMergeTree-tabelle om deur die primêre sleutel op te som, en 20 kolomme word as die primêre sleutel gebruik. Net vir ingeval, ek het die name van sommige kolomme vir sameswering verander, maar dit is omtrent dit.
En sulke probleme ontstaan. Eerstens word die hoeveelheid data wat jy het nie te veel verminder nie. Dit word byvoorbeeld met drie keer verminder. Drie keer sal 'n goeie prys wees om die onbeperkte ontleding te bekostig wat gepaard gaan met die nie-aggregeerde data. As die data saamgevoeg is, kry jy net ellendige statistieke in plaas van analise.
En wat is veral goed? Dat hierdie mense van die volgende departement soms gaan vra om nog een kolom by die primêre sleutel te voeg. Dit wil sê, ons het die data so saamgevoeg, en nou wil ons 'n bietjie meer hê. Maar daar is geen alter primêre sleutel in ClickHouse nie. Daarom moet jy 'n paar skrifte in C ++ skryf. En ek hou nie van skrifte nie, al is dit in C++.
En as jy kyk waarvoor ClickHouse geskep is, dan is nie-geaggregeerde data presies die scenario waarvoor dit gebore is. As jy ClickHouse vir nie-geaggregeerde data gebruik, dan doen jy alles reg. As jy saamvoeg, dan is dit soms vergeefbaar.
Nog 'n interessante geval is versoeke in 'n oneindige lus. Ek gaan soms na die een of ander produksiebediener en kyk na die show processlist daar. En elke keer ontdek ek dat iets verskrikliks aan die gebeur is.
Byvoorbeeld, hier is dit. Dit is dadelik duidelik dat dit moontlik was om alles in een versoek te doen. Skryf net die url in en die lys daar.
Hoekom is baie sulke versoeke in 'n oneindige lus sleg? As die indeks nie gebruik word nie, sal jy baie oorgange oor dieselfde data hê. Maar as 'n indeks byvoorbeeld gebruik word, het jy 'n primêre sleutel op ru en jy skryf url = iets daar. En jy dink dat een url puntsgewys uit die tabel gelees sal word, alles sal reg wees. Maar regtig nee. Omdat ClickHouse alles in bondels doen.
Wanneer hy 'n reeks data moet lees, lees hy 'n bietjie meer, want die indeks in ClickHouse is yl. Hierdie indeks laat jou nie toe om een individuele ry in die tabel te vind nie, net 'n soort reeks. En die data word in blokke saamgepers. Om een reël te lees, moet jy die hele blok neem en dit uitdruk. En as jy 'n klomp navrae uitvoer, sal jy baie kruisings van sulkes hê, en jy sal baie werk oor en oor hê.
En as 'n bonus kan jy sien dat jy in ClickHouse nie bang moet wees om selfs megagrepe en selfs honderde megagrepe na die IN-afdeling oor te dra nie. Ek onthou uit ons praktyk dat as ons byvoorbeeld 'n klomp waardes in die IN-afdeling in MySQL deurgee, ons 100 megagrepe van sommige getalle daar verbygaan, dan vreet MySQL 10 gigagrepe geheue op en niks anders gebeur met dit, alles werk sleg.
En die tweede ding is dat in ClickHouse, as jou navrae 'n indeks gebruik, dit altyd nie stadiger is as 'n volledige skandering nie, dit wil sê as jy amper die hele tabel moet lees, sal dit opeenvolgend gaan en die hele tabel lees. Oor die algemeen sal hy dit uitvind.
Daar is egter 'n paar probleme. Byvoorbeeld, daardie IN met 'n subnavraag gebruik nie die indeks nie. Maar dit is ons probleem en ons moet dit regstel. Hier is niks fundamenteel nie. Kom ons doen dit*.
En nog 'n interessante ding is dat as jy 'n baie lang versoek het en verspreide versoekverwerking aan die gang is, dan sal hierdie baie lang versoek sonder kompressie na elke bediener gestuur word. Byvoorbeeld, 100 megagrepe en 500 bedieners. En dienooreenkomstig sal 50 gigagrepe oor die netwerk oorgedra word. Dit sal oorgedra word en dan sal alles suksesvol uitgevoer word.
* reeds gebruik; alles is reggemaak soos belowe.
En dit is redelik algemeen as die versoeke van die API kom. Byvoorbeeld, jy het 'n soort diens gemaak. En as iemand jou diens nodig het, dan het jy die API oopgemaak en letterlik twee dae later sien jy dat iets onverstaanbaars gebeur. Alles is oorlaai en 'n paar verskriklike versoeke kom in wat nooit moes gewees het nie.
En daar is net een oplossing. As jy die API oopgemaak het, sal jy dit moet sny. Byvoorbeeld, om 'n paar kwotas in te voer. Daar is geen ander redelike opsies nie. Andersins sal hulle dadelik 'n draaiboek skryf en daar sal probleme wees.
En ClickHouse het 'n spesiale kenmerk - dit is die berekening van kwotas. Boonop kan u u kwotasleutel oordra. Dit is byvoorbeeld 'n interne gebruiker-ID. En kwotas sal onafhanklik vir elkeen van hulle bereken word.
Nou nog 'n interessante ding. Dit is handmatige replikasie.
Ek ken baie gevalle waar, ten spyte van ClickHouse wat ingeboude replikasie-ondersteuning het, mense ClickHouse met die hand repliseer.
Wat is die beginsel? Jy het 'n dataverwerkingspyplyn. En dit werk onafhanklik, byvoorbeeld, in verskillende datasentrums. Jy skryf as't ware dieselfde data op dieselfde manier aan ClickHouse. Dit is waar, die praktyk toon dat die data steeds sal verskil as gevolg van 'n paar eienaardighede in jou kode. Ek hoop dit in joune.
En periodiek moet jy steeds handmatig sinkroniseer. Byvoorbeeld, een keer per maand doen admins rsync.
Trouens, dit is baie makliker om die ingeboude replikasie in ClickHouse te gebruik. Maar daar kan 'n paar kontraindikasies wees, want hiervoor moet jy ZooKeeper gebruik. Ek sal niks sleg sê oor ZooKeeper nie, in beginsel werk die stelsel, maar dit gebeur dat mense dit nie gebruik nie as gevolg van java-fobie, want ClickHouse is so 'n goeie stelsel geskryf in C ++ wat jy kan gebruik en alles sal reg wees. En ZooKeeper in java. En op een of ander manier wil jy nie eers kyk nie, maar dan kan jy handmatige replikasie gebruik.
ClickHouse is 'n praktiese stelsel. Dit neem jou behoeftes in ag. As u handmatige replikasie het, kan u 'n verspreide tabel skep wat na u handmatige replikas kyk en 'n failover tussen hulle doen. En daar is selfs 'n spesiale opsie wat jou toelaat om flops te vermy, selfs al is jou lyne stelselmatig uiteenlopend.
Verder kan daar probleme wees as jy primitiewe tafelenjins gebruik. ClickHouse is so 'n konstruktor wat 'n klomp verskillende tafelenjins het. Vir alle ernstige gevalle, soos geskryf in die dokumentasie, gebruik tabelle van die MergeTree-familie. En al die res - dit is so, vir individuele gevalle of vir toetse.
In 'n MergeTree-tabel hoef jy geen datum en tyd te hê nie. Jy kan nog steeds gebruik. As daar geen datum en tyd is nie, skryf dat verstek 2000 is. Dit sal werk en sal nie hulpbronne benodig nie.
En in die nuwe weergawe van die bediener kan jy selfs spesifiseer dat jy persoonlike partisionering het sonder 'n partisiesleutel. Dit sal dieselfde wees.
Aan die ander kant kan primitiewe tafelenjins gebruik word. Vul byvoorbeeld die data een keer in en sien, draai en vee uit. Jy kan Log gebruik.
Of die stoor van klein volumes vir intermediêre verwerking is StripeLog of TinyLog.
Geheue kan gebruik word as daar 'n klein hoeveelheid data is en net iets in die RAM draai.
ClickHouse hou nie baie van gerenormaliseerde data nie.
Hier is 'n tipiese voorbeeld. Dit is 'n groot aantal URL's. Jy sit hulle in die aangrensende tafel. En toe het ons besluit om JOIN met hulle te doen, maar dit sal as 'n reël nie werk nie, want ClickHouse ondersteun net Hash JOIN. As daar nie genoeg RAM is vir baie data om mee te koppel nie, sal JOIN nie werk nie *.
As die data van hoë kardinaliteit is, moenie bekommerd wees nie, stoor dit in 'n gedenormaliseerde vorm, die URL's is direk in die hooftabel in plek.
* en nou het ClickHouse ook 'n samevoeging, en dit werk in toestande waar die intermediêre data nie in die RAM pas nie. Maar dit is ondoeltreffend en die aanbeveling bly geldig.
Nog 'n paar voorbeelde, maar ek twyfel reeds of dit anti-patrone is of nie.
ClickHouse het een bekende nadeel. Hy weet nie hoe om * op te dateer nie. In 'n sekere sin is dit selfs goed. As jy 'n paar belangrike data het, byvoorbeeld rekeningkunde, sal niemand dit kan stuur nie, want daar is geen opdaterings nie.
* Ondersteuning vir opdatering en uitvee in bondelmodus is lank reeds bygevoeg.
Maar daar is 'n paar spesiale maniere wat opdaterings in die agtergrond laat verskyn. Byvoorbeeld, tabelle van die tipe ReplaceMergeTree. Hulle doen opdaterings tydens agtergrondsamesmeltings. Jy kan dit dwing met optimaliseer tabel. Maar moenie dit te gereeld doen nie, want dit sal die partisie heeltemal oorskryf.
Verspreide JOINs in ClickHouse - dit word ook swak hanteer deur die navraagbeplanner.
Sleg, maar soms OK.
Gebruik ClickHouse net om data terug te lees met select*.
Ek sal nie aanbeveel om ClickHouse vir lywige berekeninge te gebruik nie. Maar dit is nie heeltemal waar nie, want ons beweeg reeds weg van hierdie aanbeveling. En ons het onlangs die vermoë bygevoeg om masjienleermodelle toe te pas in ClickHouse - Catboost. En dit bekommer my, want ek dink: “Wat ’n gruwel. Dit is hoeveel siklusse per greep dit blyk! Dit is vir my jammer om kloksiklusse op grepe te begin.
Maar moenie bang wees nie, installeer ClickHouse, alles sal reg wees. As daar iets is, het ons 'n gemeenskap. Terloops, die gemeenskap is jy. En as jy enige probleme het, kan jy ten minste na ons chat gaan, en ek hoop dat jy gehelp sal word.
vrae
Dankie vir die verslag! Waar om te kla oor die ClickHouse-ongeluk?
Jy kan nou persoonlik by my kla.
Ek het onlangs ClickHouse begin gebruik. Het die cli-koppelvlak dadelik laat val.
Wat 'n telling.
'N Bietjie later het ek die bediener met 'n klein keuse laat val.
Jy het talent.
Ek het 'n GitHub-fout oopgemaak, maar dit is geïgnoreer.
Ons sal sien.
Aleksey het my mislei om die verslag by te woon, en belowe om my te vertel hoe jy die data indruk.
Baie eenvoudig.
Dit is wat ek gister besef het. Meer besonderhede.
Daar is geen verskriklike truuks nie. Dit is net blok-vir-blok kompressie. Die verstek is LZ4, jy kan ZSTD* aktiveer. Blokke van 64 kilogrepe tot 1 megagrepe.
* daar is ook ondersteuning vir gespesialiseerde kompressie-kodeks wat in ketting met ander algoritmes gebruik kan word.
Is die blokke net rou data?
Nie juis rou nie. Daar is skikkings. As jy 'n numeriese kolom het, dan word die getalle in 'n ry in 'n skikking gestapel.
Dit is duidelik.
Alexey, 'n voorbeeld wat met uniqExact oor IP's was, dit wil sê die feit dat uniqExact langer neem om deur stringe te tel as volgens getalle, ensovoorts. Wat as ons op die oomblik van proeflees 'n fynfint met ons ore aanbring en gooi? Dit wil sê, dit lyk asof jy gesê het dat dit nie veel op die skyf verskil nie. As ons lyne van die skyf lees, gooi, sal ons dan vinniger aggregate hê of nie? Of wen ons nog marginaal hier? Dit lyk vir my of jy dit getoets het, maar dit om een of ander rede nie in die maatstaf aangedui het nie.
Ek dink dit sal stadiger wees as geen rolverdeling nie. In hierdie geval moet die IP-adres van die string ontleed word. Natuurlik, in ClickHouse is die ontleding van IP-adres ook geoptimaliseer. Ons het baie hard probeer, maar op dieselfde plek het jy die getalle in tienduisendste vorm geskryf. Baie ongemaklik. Aan die ander kant sal die uniqExact-funksie stadiger op stringe werk, nie net omdat dit stringe is nie, maar ook omdat 'n ander spesialisasie van die algoritme gekies word. Snare word net anders hanteer.
En as ons 'n meer primitiewe datatipe neem? Hulle het byvoorbeeld die gebruikers-ID wat ons in het neergeskryf, dit as 'n reël neergeskryf en dit dan gegooi, sal dit meer pret wees of nie?
Ek twyfel. Ek dink dit sal selfs hartseerder wees, want die ontleed van getalle is immers 'n ernstige probleem. Dit lyk vir my of hierdie kollega selfs 'n verslag gehad het oor hoe moeilik dit is om getalle in tienduisendste vorm te ontleed, maar miskien nie.
Alexey, baie dankie vir die verslag! En baie dankie vir ClickHouse! Ek het 'n vraag oor planne. Is daar 'n kenmerk in die planne vir die onvolledige opdatering van woordeboeke?
d.w.s. gedeeltelike herlaai?
Ja ja. Soos die vermoë om 'n MySQL-veld daar te stel, d.w.s. opdateer na sodat slegs hierdie data gelaai word as die woordeboek baie groot is.
Baie interessante kenmerk. En, lyk dit vir my, het een of ander persoon dit in ons chat voorgestel. Miskien was dit selfs jy.
Ek dink nie so nie.
Groot, nou blyk dit dat twee versoeke. En jy kan dit stadig begin doen. Maar ek wil jou dadelik waarsku dat hierdie funksie redelik eenvoudig is om te implementeer. Dit wil sê, in teorie moet jy net die weergawenommer in die tabel skryf en dan skryf: die weergawe is minder as so en so. En dit beteken dat ons dit heel waarskynlik aan entoesiaste sal aanbied. Is jy 'n entoesias?
Ja, maar ongelukkig nie in C++ nie.
Kan jou kollegas in C++ skryf?
Ek sal iemand kry.
Groot*.
* die kenmerk is twee maande na die verslag bygevoeg - dit is ontwikkel deur die skrywer van die vraag en ingedien deur syne .
Dankie!
Hallo! Dankie vir die verslag! U het genoem dat ClickHouse al die hulpbronne wat daarvoor beskikbaar is, baie goed verbruik. En die spreker langs Luxoft het oor sy besluit vir die Russian Post gepraat. Hy het gesê dat hulle baie van ClickHouse gehou het, maar hulle het dit nie in plaas van hul hoofmededinger gebruik nie, juis omdat dit die hele verwerker geëet het. En hulle kon dit nie in hul argitektuur, in hul ZooKeeper met dockers inpas nie. Is dit moontlik om ClickHouse op een of ander manier te beperk sodat dit nie alles verbruik wat vir hom beskikbaar word nie?
Ja, dit is moontlik en baie maklik. As jy minder kerns wil verbruik, skryf dan net set max_threads = 1. En dit is al, dit sal die versoek in een kern uitvoer. Boonop kan u verskillende instellings vir verskillende gebruikers spesifiseer. So geen probleem nie. En sê vir jou kollegas van Luxoft dat dit nie goed is dat hulle nie hierdie instelling in die dokumentasie gevind het nie.
Alexey, hallo! Ek wil graag hierdie vraag vra. Dit is nie die eerste keer dat ek hoor dat baie mense ClickHouse as 'n bewaarplek vir logs begin gebruik nie. By die verslag het jy gesê om dit nie te doen nie, dit wil sê, jy hoef nie lang rye te stoor nie. Wat dink jy daarvan?
Eerstens is stompe gewoonlik nie lang lyne nie. Daar is natuurlik uitsonderings. Byvoorbeeld, sommige diens wat in java geskryf is, gooi 'n uitsondering, dit word aangeteken. En so in 'n eindelose lus, en hardloop uit hardeskyfspasie. Die oplossing is baie eenvoudig. As die lyne baie lank is, sny dit dan. Wat beteken lank? Tiental kilogrepe is sleg *.
* In onlangse weergawes van ClickHouse is "aanpasbare indeksgranulariteit" geaktiveer, wat die probleem van die stoor van lang stringe vir die grootste deel verwyder.
Is 'n kilogreep normaal?
Dit is normaal.
Hallo! Dankie vir die verslag! Ek het reeds hieroor in die chat gevra, maar ek onthou nie of ek 'n antwoord gekry het nie. Is daar enige plan om die WITH-afdeling op 'n CTE-manier uit te brei?
Nog nie. Die WITH-afdeling is ietwat ligsinnig. Dit is soos 'n klein kenmerk vir ons.
Ek verstaan. Dankie!
Dankie vir die verslag! Baie interessant! globale vraag. Word daar beplan om, miskien in die vorm van 'n soort stompe, wysiging van data-skrap te doen?
Nodig. Dit is ons eerste taak in ons tou. Ons dink nou aktief oor hoe om alles reg te doen. En jy moet die sleutelbord* begin druk.
* die knoppies op die sleutelbord gedruk en alles is klaar.
Sal dit op een of ander manier stelselwerkverrigting beïnvloed of nie? Sal die insetsel so vinnig wees soos dit nou is?
Miskien is die verwyderings self, die opdaterings self sal baie swaar wees, maar dit sal op geen manier die prestasie van keuses en die prestasie van insetsels beïnvloed nie.
En nog 'n klein vraag. By die aanbieding het jy oor die primêre sleutel gepraat. Gevolglik het ons partisionering, wat maandeliks by verstek is, nie waar nie? En wanneer ons 'n datumreeks stel wat in 'n maand pas, dan lees ons net hierdie partisie, reg?
Ja.
N vraag. As ons geen primêre sleutel kan kies nie, is dit dan reg om dit presies volgens die "Datum"-veld te doen sodat daar in die agtergrond 'n kleiner herstrukturering van hierdie data is sodat hulle op 'n meer ordelike wyse pas? As jy nie reeksnavrae het nie en jy kan nie eers enige primêre sleutel kies nie, is dit die moeite werd om 'n datum in die primêre sleutel te plaas?
Ja.
Miskien maak dit sin om 'n veld in die primêre sleutel te plaas waardeur die data beter saamgepers sal word as hulle volgens hierdie veld gesorteer word. Byvoorbeeld, gebruikers-ID. Gebruiker gaan byvoorbeeld na dieselfde webwerf. In hierdie geval, plaas die gebruiker-ID en tyd. En dan sal jou data beter saamgepers word. Wat die datum betref, as jy regtig nie het en nooit reeksnavrae oor datums het nie, dan kan jy nie die datum in die primêre sleutel plaas nie.
OK baie dankie!
Bron: will.com