Yn april sammele Avito-yngenieurs foar online gearkomsten mei de wichtichste ClickHouse-ûntwikkelder Alexey Milovidov en Kirill Shvakov, in Golang-ûntwikkelder fan Integros. Wy hawwe besprutsen hoe't wy in databankbehearsysteem brûke en hokker swierrichheden wy tsjinkomme.
Op grûn fan 'e gearkomste hawwe wy in artikel gearstald mei antwurden fan saakkundigen op ús en fragen fan it publyk oer backups, data resharding, eksterne wurdboeken, de Golang-bestjoerder en it bywurkjen fan ClickHouse-ferzjes. It kin nuttich wêze foar ûntwikkelders dy't al aktyf wurkje mei de Yandex DBMS en binne ynteressearre yn syn hjoeddeistige en takomst. Standert binne de antwurden fan Alexey Milovidov, útsein as oars skreaun.
Wês foarsichtich, der is in protte tekst ûnder de besuniging. Wy hoopje dat de ynhâld mei fragen jo sil helpe te navigearjen.
Ynhâld
As jo de tekst net lêze wolle, kinne jo de opname fan de gearkomsten besjen . Tiidkoades binne yn 'e earste opmerking ûnder de fideo.
ClickHouse wurdt konstant bywurke, mar ús gegevens binne net. Wat der oan te dwaan?
ClickHouse wurdt konstant bywurke, en ús gegevens, dy't waarden optimalisearre úteinlik ferwurke, wurdt net bywurke en is yn in reservekopy.
Litte wy sizze dat wy wat probleem hiene en de gegevens wiene ferlern. Wy besletten om te herstellen, en it die bliken dat de âlde partysjes, dy't wurde opslein op de reservekopy tsjinners, binne hiel oars as de op it stuit brûkte ferzje fan ClickHouse. Wat te dwaan yn sa'n situaasje, en is it mooglik?
In situaasje wêryn jo gegevens weromsette fan in reservekopy yn in âld formaat, mar it makket gjin ferbining mei de nije ferzje, is ûnmooglik. Wy soargje derfoar dat it gegevensformaat yn ClickHouse altyd efterút kompatibel bliuwt. Dit is folle wichtiger as efterútkompatibiliteit yn funksjonaliteit as it gedrach fan guon selden brûkte funksje is feroare. De nije ferzje fan ClickHouse moat altyd de gegevens kinne lêze dy't op skiif opslein binne. Dit is de wet.
Wat binne de hjoeddeistige bêste praktiken foar it bewarjen fan gegevens fan ClickHouse?
Hoe meitsje reservekopyen, rekken hâldend mei it optimalisearjen fan definitive operaasjes, in enoarme database fan terabytes, en gegevens dy't, bygelyks, foar de lêste trije dagen binne bywurke, en dan barre der gjin prosedueres mei?
Wy kinne ús eigen oplossing meitsje en op 'e bash skriuwe: dizze reservekopyen op sa en sa sammelje. Miskien is it net nedich om wat te krûpen, en de fyts is lang lyn útfûn?
Litte wy begjinne mei de bêste praktiken. Myn kollega's advisearje altyd, yn antwurd op fragen oer backups, om har te herinnerjen oer de Yandex.Cloud-tsjinst, wêr't dit probleem al is oplost. Dus brûk it as mooglik.
D'r is gjin folsleine oplossing foar backups, hûndert prosint ynboud yn ClickHouse. D'r binne wat blanks dy't brûkt wurde kinne. Om in folsleine oplossing te krijen, moatte jo in bytsje mei de hân tintsje, of wrappers meitsje yn 'e foarm fan skripts.
Ik sil begjinne mei de ienfâldichste oplossingen en einigje mei de meast ferfine, ôfhinklik fan it folume fan gegevens en de grutte fan it kluster. Hoe grutter it kluster, hoe komplekser de oplossing wurdt.
As de tabel mei gegevens mar in pear gigabytes beslacht, kin backup sa dien wurde:
- Bewarje tabeldefinysje i.e. metadata - sjen litte meitsje tabel.
- Meitsje in dump mei de ClickHouse-kliïnt - útkieze * fan tafel opslaan. Standert krije jo in bestân yn TabSeparated opmaak. As jo effisjinter wolle wêze, kinne jo it dwaan yn Native-formaat.
As de hoemannichte gegevens grutter is, dan sil de reservekopy mear tiid en in protte romte nimme. Dit wurdt in logyske reservekopy neamd; it is net bûn oan it ClickHouse-gegevensformaat. As it is, dan kinne jo as lêste ynstânsje in reservekopy nimme en it uploade nei MySQL foar herstel.
Foar mear avansearre gefallen hat ClickHouse in ynboude mooglikheid om in momintopname te meitsjen fan partysjes yn it lokale bestânsysteem. Dizze funksje is beskikber as fersyk feroarje tabel freeze partition. Of gewoan feroarje tafel freeze - dit is in momintopname fan 'e hiele tafel.
De snapshot sil konsekwint makke wurde foar ien tabel op ien shard, dat is, it is ûnmooglik om op dizze manier in konsekwint momintopname fan it hiele kluster te meitsjen. Mar foar de measte taken is d'r net sa'n need, en it is genôch om in fersyk op elke shard út te fieren en in konsekwint momintopname te krijen. It is makke yn 'e foarm fan hurdlinks en nimt dêrom gjin ekstra romte yn. Dêrnei kopiearje jo dizze momintopname nei de reservekopytsjinner of nei de opslach dy't jo brûke foar backups.
It werstellen fan sa'n reservekopy is frij maklik. Meitsje earst tabellen mei besteande tabeldefinysjes. Kopiearje dan de bewarre snapshots fan 'e partysjes nei Directory-Detached foar dizze tabellen en útfiere de query attach partition. Dizze oplossing is hiel geskikt foar de meast serieuze voluminten fan gegevens.
Soms hawwe jo wat koeler nedich - yn gefallen wêr't jo tsientallen of sels hûnderten terabytes hawwe op elke server en hûnderten servers. D'r is hjir in oplossing dy't ik ophelle fan myn kollega's fan Yandex.Metrica. Ik soe it net elkenien oanbefelje - lês it en beslute sels as it geskikt is of net.
Earst moatte jo ferskate servers meitsje mei grutte skiifplanken. Folgjende, op dizze servers, ferheegje ferskate ClickHouse-tsjinners en konfigurearje se sadat se wurkje as in oare replika foar deselde shards. En brûk dan in bestânsysteem as wat ark op dizze servers wêrmei jo snapshots kinne meitsje. D'r binne hjir twa opsjes. De earste opsje is LVM-snapshots, de twadde opsje is ZFS op Linux.
Dêrnei moatte jo elke dei in momintopname meitsje, it sil lizze en wat romte ynnimme. Fansels, as de gegevens feroarje, sil de hoemannichte romte oer de tiid tanimme. Dizze momintopname kin op elk momint úthelle wurde en de gegevens weromsette, sa'n nuvere oplossing. Plus, wy moatte ek dizze replika's yn 'e konfiguraasje beheine, sadat se net besykje lieders te wurden.
Sil it mooglik wêze om in kontrolearre efterstân fan replika's yn 'e skachten te organisearjen?
Dit jier binne jo fan plan om shafts te meitsjen yn ClickHouse. Sil it mooglik wêze om in kontroleare efterstân fan replika's yn har te organisearjen? Wy wolle it brûke om ússels te beskermjen tsjin negative senario's mei feroarings en oare feroaringen.
Is it mooglik om te dwaan wat soarte fan roll werom foar alters? Bygelyks, yn in besteande skacht, nim en sis dat oant dit momint jo de feroarings tapasse, en fan dit momint stopje jo de wizigingen ta te passen?
As in kommando nei ús kluster kaam en it bruts, dan hawwe wy in betingsten replika mei in oere fertraging, wêr't wy kinne sizze dat wy it op it stuit brûke, mar wy sille gjin wizigingen tapasse foar de lêste tsien minuten?
Earst, oer de kontrolearre efterstân fan replika's. D'r wie sa'n fersyk fan brûkers, en wy makken in probleem op Github mei it fersyk: "As immen dit nedich hat, like it, set in hert." Nimmen levere, en it probleem waard sletten. Jo kinne dizze kâns lykwols al krije troch ClickHouse yn te stellen. Wier, allinich begjinnend fan ferzje 20.3.
ClickHouse fiert konstant gegevens gearfoegjen op 'e eftergrûn. As in fúzje foltôge is, wurdt in bepaalde set fan stikken gegevens ferfongen troch in grutter stik. Tagelyk bliuwe stikken gegevens dy't der earder wiene, noch in skoft op 'e skiif.
Earst bliuwe se opslein salang't d'r selekteare fragen binne dy't se brûke, om net-blokkearjende operaasje te leverjen. Selekteare fragen wurde maklik lêzen út âlde brokken.
As twadde is der ek in tiiddrompel - âlde stikken gegevens lizze acht minuten op 'e skiif. Dizze acht minuten kinne wurde oanpast en sels feroare yn ien dei. Dit kostet skiifromte: ôfhinklik fan de gegevensstream, docht bliken dat de lêste dei de gegevens net allinich ferdûbelje, se kinne fiif kear mear wurde. Mar as d'r in serieus probleem is, kinne jo de ClickHouse-tsjinner stopje en alles sortearje.
No komt de fraach op hoe't dit beskermet tsjin feroarings. It is it wurdich hjir in djipper te sjen, om't yn âldere ferzjes fan ClickHouse it alter sa wurke dat it gewoan stikken direkt feroare. D'r is in stikje gegevens mei guon bestannen, en wy dogge bgl. feroarje drop kolom. Dan wurdt dizze kolom fysyk fuortsmiten fan alle brokken.
Mar begjinnend mei ferzje 20.3 is it altermeganisme folslein feroare, en no binne stikken gegevens altyd ûnferoarlik. Se feroarje hielendal net - feroarings wurkje no krekt op deselde manier as fúzjes. Yn stee fan it ferfangen fan in stik op it plak, meitsje wy in nij. Yn it nije stik wurde bestannen dy't net feroare binne hurdlinks, en as wy in kolom wiskje, sil it gewoan ûntbrekke yn 'e nije brok. It âlde stik sil nei acht minuten standert wiske wurde, en hjir kinne jo de hjirboppe neamde ynstellingen oanpasse.
Itselde jildt foar alters lykas mutaasjes. As jo dogge feroarje wiskje of feroarje update, it feroaret it stik net, mar makket in nij. En dan wisket de âlde.
Wat as de tabelstruktuer is feroare?
Hoe kinne jo in reservekopy weromsette dy't makke is mei it âlde skema? En de twadde fraach giet oer it gefal mei snapshots en ark foar bestânsysteem. Is Btrfs hjir goed ynstee fan ZFS op Linux LVM?
Ast it dochst attach partition partysjes mei in oare struktuer, dan sil ClickHouse jo fertelle dat dit net mooglik is. Dit is de oplossing. De earste is om in tydlike tabel fan it MergeTree-type te meitsjen mei de âlde struktuer, taheakje gegevens dêr mei taheakje, en meitsje in alter query. Dan kinne jo dizze gegevens kopiearje of oerdrage en opnij taheakje, of in fersyk brûke feroarje tabel move partition.
No is de twadde fraach oft Btrfs brûkt wurde kinne. Om te begjinnen, as jo LVM hawwe, dan binne LVM-snapshots genôch, en it bestânsysteem kin ext4 wêze, it makket net út. Mei Btrts hinget alles ôf fan jo ûnderfining by it brûken dêrfan. Dit is in folwoeksen bestânsysteem, mar d'r binne noch wat fertochten oer hoe't alles yn 'e praktyk sil wurkje yn in bepaald senario. Ik soe net riede in gebrûk dit útsein as jo hawwe Btrfs yn produksje.
Wat binne de hjoeddeistige bêste praktiken yn it resharding fan gegevens?
It probleem fan resharding is kompleks en mannichfâldich. D'r binne hjir ferskate mooglike antwurden. Jo kinne fan 'e iene kant gean en dit sizze - ClickHouse hat gjin ynboude resharding-funksje. Mar ik bin bang dat dit antwurd net by elkenien past. Dêrom kinne jo fan 'e oare kant gean en sizze dat ClickHouse in protte manieren hat om gegevens opnij te meitsjen.
As it kluster gjin romte hat of it kin de lading net oan, foegje jo nije tsjinners ta. Mar dizze servers binne standert leech, d'r binne gjin gegevens oer har, d'r is gjin lading. Jo moatte de gegevens opnij regelje, sadat se lykwichtich ferspraat wurde oer it nije, gruttere kluster.
De earste manier wêrop dit kin dien wurde is om in diel fan 'e partysjes te kopiearjen nei nije servers mei in fersyk feroarje tabel heljen partition. Bygelyks, jo hiene partysjes per moanne, en jo nimme de earste moanne fan 2017 en kopiearje it nei in nije server, kopiearje dan de tredde moanne nei in oare nije server. En jo dogge dit oant it min of mear gelyk wurdt.
Oerdracht kin wurde útfierd allinnich foar dy partysjes dy't net feroarje tidens opname. Foar frisse partysjes sil opname moatte wurde útskeakele, om't har oerdracht net atoom is. Oars sille jo einigje mei duplikaten as gatten yn 'e gegevens. Dizze metoade is lykwols praktysk en wurket frij effektyf. Ready-makke komprimearre partysjes wurde oer it netwurk oerbrocht, dat is, de gegevens wurde net komprimearre of opnij kodearre.
Dizze metoade hat ien neidiel, en it hinget ôf fan de sharding skema, oft jo tasein oan dizze sharding skema, hokker sharding kaai do hiest. Yn jo foarbyld foar it gefal mei metriken is de sharding-kaai de hash fan it paad. As jo selektearje in Distributed tabel, it giet nei alle shards yn it kluster yn ien kear en nimt gegevens út dêr.
Dit betsjut dat it jo eins net útmakket hokker gegevens op hokker shard terjochte binne. It wichtichste is dat gegevens lâns ien paad op ien shard komme, mar hokker is net wichtich. Yn dit gefal is it oerdragen fan ready-made partysjes perfekt, om't jo mei selekteare fragen ek folsleine gegevens krije - of foar it werheljen of nei, it skema makket net echt út.
Mar d'r binne gefallen dy't komplekser binne. As jo op 'e applikaasje logika nivo jo fertrouwe op in spesjale sharding skema, dat dizze klant leit op sa'n en sa'n shard, en it fersyk kin stjoerd wurde direkt dêr, en net nei de Distributed tafel. Of jo brûke in frij resinte ferzje fan ClickHouse en hawwe de ynstelling ynskeakele optimisearje oerslaan net brûkte shards. Yn dit gefal, tidens de seleksjefraach, sil de útdrukking yn 'e wêr't seksje wurde analysearre en sil wurde berekkene hokker shards moatte wurde brûkt neffens it shardingskema. Dit wurket op betingst dat de gegevens presys binne ferdield neffens dit shardingskema. As jo se mei de hân opnij regele hawwe, kin de korrespondinsje feroarje.
Dat dit is metoade nûmer ien. En ik wachtsje op jo antwurd, oft de metoade geskikt is, of litte wy fierder gean.
Vladimir Kolobaev, lead systeembehearder by Avito: Alexey, de metoade dy't jo neamden wurket net heul goed as jo de lading moatte fersprieden, ynklusyf lêzen. Wy kinne in partysje nimme dy't moanliks is en kin de foarige moanne nei in oare knooppunt nimme, mar as der in fersyk komt foar dizze gegevens, sille wy it allinich laden. Mar wy wolle it hiele kluster wol laden, want oars wurdt de hiele lêslading noch in skoft ferwurke troch twa skuorren.
Alexey Milovidov: It antwurd hjir is nuver - ja, it is min, mar it kin wurkje. Ik sil útlizze krekt hoe. It is de muoite wurdich om te sjen nei it loadsenario dat efter jo gegevens komt. As dit is tafersjoch op gegevens, dan kinne wy hast wis sizze dat de grutte mearderheid fan oanfragen binne foar farske gegevens.
Jo hawwe nije servers ynstalleare, âlde partysjes migrearre, mar ek feroare hoe't farske gegevens wurde opnommen. En frisse gegevens sille ferspraat wurde oer it kluster. Dus, nei mar fiif minuten sille fersiken foar de lêste fiif minuten it kluster lykwichtich laden; nei in dei sille fersiken foar XNUMX oeren it kluster lykwichtich laden. En oanfragen foar de foarige moanne sille spitigernôch allinich nei in diel fan 'e klusterservers gean.
Mar faaks sille jo gjin spesifyk oanfragen hawwe foar febrewaris 2019. Meast wierskynlik, as oanfragen yn 2019 gean, dan sille se foar it heule 2019 wêze - foar in grutte perioade, en net foar wat lyts berik. En sokke oanfragen sille ek it kluster lykwichtich laden kinne. Mar yn 't algemien is jo opmerking absolút korrekt dat dit in ad hoc-oplossing is dy't de gegevens net folslein gelyk ferspriedt.
Ik haw noch in pear punten om de fraach te beantwurdzjen. Ien fan har giet oer hoe't jo yn earste ynstânsje in shardingskema ûntwerpe kinne, sadat opnij sharding minder pine feroarsaakje soe. Dit is net altyd mooglik.
Jo hawwe bygelyks tafersjochgegevens. Tafersjochgegevens groeie om trije redenen. De earste is it sammeljen fan histoaryske gegevens. De twadde is ferkearsgroei. En de tredde is in tanimming fan it oantal dingen dy't ûnder tafersjoch binne. D'r binne nije mikrotsjinsten en metriken dy't moatte wurde bewarre.
It is mooglik dat fan dizze de grutste ferheging is ferbûn mei de tredde reden - de tanimming fan it gebrûk fan tafersjoch. En yn dit gefal is it wurdich te sjen nei de aard fan 'e lading, wat binne de wichtichste seleksjefragen. Basis seleksjefragen sille nei alle gedachten wurde basearre op guon subset fan metriken.
Bygelyks, CPU-gebrûk op guon servers troch guon tsjinst. It docht bliken dat d'r in bepaalde subset fan kaaien is wêrmei jo dizze gegevens krije. En it fersyk sels foar dizze gegevens is nei alle gedachten frij simpel en wurdt foltôge yn tsientallen millisekonden. Wurdt brûkt foar tafersjochtsjinsten en dashboards. Ik hoopje dat ik dit goed begryp.
Vladimir Kolobaev: It feit is dat wy heul faak in berop dwaan op histoaryske gegevens, om't wy de hjoeddeistige situaasje fergelykje mei de histoaryske yn realtime. En it is wichtich foar ús in ha flugge tagong ta in grutte hoemannichte gegevens, en ClickHouse docht in poerbêste baan mei dizze.
Jo hawwe absolút gelyk, wy belibje de measte lêsoanfragen yn 'e lêste dei, lykas elk tafersjochsysteem. Mar tagelyk is de lading op histoaryske gegevens ek frij grut. It is yn prinsipe fan in warskôgingssysteem dat elke tritich sekonden rûn en seit tsjin ClickHouse: "Jou my de gegevens foar de lêste seis wiken. Bou my no in soarte fan bewegend gemiddelde fan har, en lit ús de hjoeddeistige wearde fergelykje mei de histoaryske.
Ik soe graach sizze dat wy foar sokke heul resinte oanfragen in oare lytse tabel hawwe wêryn wy mar twa dagen oan gegevens opslaan, en de wichtichste oanfragen fleane deryn. Wy stjoere allinnich grutte histoaryske queries nei de grutte sharded tafel.
Alexey Milovidov: Spitigernôch blykt it min fan tapassing te wêzen foar jo senario, mar ik sil jo in beskriuwing fertelle fan twa minne en komplekse shardingskema's dy't net hoege te brûken, mar dy't brûkt wurde yn 'e tsjinst fan myn freonen.
D'r is in haadkluster mei Yandex.Metrica-eveneminten. Eveneminten binne sidewerjeften, klikken en konversaasjes. De measte oanfragen geane nei in spesifike webside. Jo iepenje de Yandex.Metrica-tsjinst, jo hawwe in webside - avito.ru, gean nei it rapport, en in fersyk wurdt makke foar jo webside.
Mar d'r binne oare oanfragen - analytysk en wrâldwide - dy't wurde makke troch ynterne analysten. Krekt foar it gefal, ik merk op dat ynterne analysten allinich oanfragen meitsje foar Yandex-tsjinsten. Mar nettsjinsteande, sels Yandex tsjinsten besette in grut part fan alle gegevens. Dit binne oanfragen net foar spesifike tellers, mar foar breder filterjen.
Hoe kinne jo gegevens op sa'n manier organisearje dat alles effisjint wurket foar ien teller, en ek globale queries? In oare swierrichheid is dat it oantal oanfragen yn ClickHouse foar it Metrics-kluster ferskate tûzen per sekonde is. Tagelyk, ien ClickHouse tsjinner kin net omgean net-triviale fersiken, Bygelyks, ferskate tûzen per sekonde.
De klustergrutte is seishûndert-wat servers. As jo gewoan lûke in Distributed tafel oer dit kluster en stjoere ferskate tûzen fersiken dêr, it sil wurden noch slimmer as in stjoeren se nei ien tsjinner. Oan 'e oare kant, de opsje dat de gegevens wurde ferspraat gelyk, en wy geane en fersykje fan alle tsjinners, wurdt fuortendaliks ôfwiisd.
D'r is in opsje dy't diametraal tsjinoersteld is. Stel jo foar as wy de gegevens oer siden sjitte, en in fersyk foar ien side giet nei ien shard. No kin it kluster tsientûzen fersiken per sekonde behannelje, mar op ien shard sil elk fersyk te stadich wurkje. It sil net langer skaalfergrutsje yn termen fan trochslach. Benammen as dit de side is avito.ru. Ik sil it geheim net iepenbierje as ik sis dat Avito ien fan 'e meast besochte siden yn RuNet is. En it ferwurkjen op ien skerp soe dwylsinnigens wêze.
Dêrom is it shardingskema op in slimmer manier ûntwurpen. It hiele kluster is ferdield yn in oantal klusters, dy't wy lagen neame. Elk kluster befettet fan in tsiental oant ferskate tsientallen shards. Der binne yn totaal njoggenentritich fan sokke klusters.
Hoe wurdt dit allegear skaal? It oantal klusters feroaret net - sa't it in pear jier lyn njoggenentritich wie, bliuwt dat sa. Mar binnen elk fan har ferheegje wy it oantal shards stadichoan as wy gegevens sammelje. En it shardingskema as gehiel is sa: dizze klusters binne ferdield yn websiden, en om te begripen hokker webside op hokker kluster is, wurdt in aparte metabase yn MySQL brûkt. Ien side - op ien kluster. En binnen it komt sharding neffens besikers-ID's foar.
By it opnimmen dielen wy se troch de rest fan 'e ferdieling fan' e besikers-ID. Mar by it tafoegjen fan in nije shard feroaret it shardingskema; wy geane troch te splitsen, mar mei in rest fan 'e divyzje troch in oar nûmer. Dit betsjut dat ien besiker al leit op ferskate tsjinners, en do kinst net fertrouwe op dit. Dit wurdt allinich dien om te soargjen dat de gegevens better wurde komprimearre. En by it meitsjen fan oanfragen geane wy nei de Distributed tabel, dy't sjocht nei it kluster en tagong ta tsientallen tsjinners. Dit is sa'n dom skema.
Mar myn ferhaal sil ûnfolslein wêze as ik net sis dat wy dit skema ferlitten hawwe. Yn it nije skema hawwe wy alles feroare en alle gegevens kopieare mei clickhouse-copier.
Yn it nije skema binne alle siden ferdield yn twa kategoryen - grut en lyts. Ik wit net hoe't de drompel is keazen, mar it resultaat wie dat grutte siden wurde opnommen op ien kluster, wêr't d'r 120-shards binne mei trije replika's elk - dat is 360 tsjinners. En it shardingskema is sa dat elk fersyk tagelyk nei alle shards giet. As jo no elke rapportside foar avito.ru iepenje yn Yandex.Metrica, sil it fersyk nei 120 tsjinners gean. D'r binne in pear grutte siden yn RuNet. En de oanfragen binne net tûzen per sekonde, mar noch minder as hûndert. Dit alles wurdt rêstich opknapt troch de Distributed tabel, dy't elk fan har ferwurket mei 120 servers.
En it twadde kluster is foar lytse siden. Hjir is in sharding skema basearre op de site ID, en elk fersyk giet nei krekt ien shard.
ClickHouse hat in clickhouse-kopiearprogramma. Kinne jo ús oer har fertelle?
Ik sil daliks sizze dat dizze oplossing omslachtiger en wat minder produktyf is. It foardiel is dat it de gegevens folslein smyt neffens it patroan dat jo oantsjutte. Mar it neidiel fan it nut is dat it hielendal net opnij wurdt. It kopiearret gegevens fan ien klusterskema nei in oar klusterskema.
Dit betsjut dat jo twa klusters moatte hawwe om it te wurkjen. Se kinne lizze op deselde tsjinners, mar dochs, de gegevens sille net wurde ferpleatst incrementally, mar wurde kopiearre.
Der wiene bygelyks fjouwer servers, no binne dat acht. Jo meitsje in nije ferspraat tabel op alle tsjinners, nije lokale tabellen en starte clickhouse-copier, oanjout dêryn it wurk skema dat it moat lêze út dêr, akseptearje it nije sharding skema en oerdrage de gegevens dêr. En op âlde servers sille jo ien en in heal kear mear romte nedich wêze as no, om't de âlde gegevens der op bliuwe moatte, en de helte fan deselde âlde gegevens komt boppe-op. As jo fan tefoaren tocht dat de gegevens moatte wurde resharded en der is romte, dan is dizze metoade geskikt.
Hoe wurket clickhouse-copier binnen? It brekt al it wurk yn in set fan taken foar it ferwurkjen fan ien partysje fan ien tabel op ien shard. Al dizze taken kinne wurde útfierd parallel, en clickhouse-copier kin wurde útfierd op ferskate masines yn meardere eksimplaren, mar wat it docht foar ien partition is neat mear as in ynfoegje selektearje. De gegevens wurde lêzen, dekomprimearre, opnij partitionearre, dan wer komprimearre, earne skreaun en opnij sorteare. Dit is in dreger beslút.
Jo hiene in pilot ding neamd resharding. Wat mei har?
Werom yn 2017 hiene jo in pilot ding neamd resharding. D'r is sels in opsje yn ClickHouse. Sa't ik it begryp gie it net ôf. Kinne jo my fertelle wêrom dit barde? It liket tige relevant te wêzen.
It hiele probleem is dat as it nedich is om gegevens opnij te meitsjen, heul komplekse syngronisaasje is nedich om dit atomysk te dwaan. Doe't wy begûnen te sjen nei hoe't dizze syngronisaasje wurket, waard dúdlik dat der fûnemintele problemen wiene. En dy fûnemintele problemen binne net allinne teoretysk, mar fuortendaliks begûn te sjen litte harsels yn 'e praktyk yn' e foarm fan eat dat kin wurde ferklearre hiel gewoan - neat wurket.
Is it mooglik om alle stikken gegevens byinoar te fusearjen foardat jo it ferpleatse nei trage skiven?
Fraach oer TTL mei de ferhuzing nei trage skiif opsje yn 'e kontekst fan fúzjes. Is d'r in manier, oars as fia cron, om alle dielen yn ien te fusearjen foardat se nei trage skiven ferpleatse?
It antwurd op 'e fraach is it mooglik om ien of oare manier automatysk alle stikken yn ien te lijmen foardat se se oerdrage - nee. Ik tink net dat dit nedich is. Jo moatte net alle dielen yn ien gearfoegje, mar gewoan rekkenje op it feit dat se automatysk wurde oerbrocht nei trage skiven.
Wy hawwe twa kritearia foar oerdracht regels. De earste is sa't it is fol. As de hjoeddeiske opslach tier hat minder as in bepaald persintaazje frije romte, wy selektearje ien brok en ferpleatse it nei trager opslach. Of leaver, net stadiger, mar de folgjende - as jo konfigurearje.
It twadde kritearium is grutte. It giet om it ferpleatsen fan grutte stikken. Jo kinne de drompel oanpasse neffens de frije romte op 'e snelle skiif, en de gegevens wurde automatysk oerdroegen.
Hoe migrearje nei nije ferzjes fan ClickHouse as d'r gjin manier is om kompatibiliteit fan tefoaren te kontrolearjen?
Dit ûnderwerp wurdt geregeld besprutsen rekken hâldend mei ferskate ferzjes, en noch altyd. Hoe feilich is it om te upgrade fan ferzje 19.11 nei 19.16 en bygelyks fan 19.16 nei 20.3. Wat is de bêste manier om nei nije ferzjes te migrearjen sûnder de kompatibiliteit yn 'e sânbak fan tefoaren te kontrolearjen?
D'r binne ferskate "gouden" regels hjir. Earste - . It is grut, mar d'r binne aparte paragrafen oer werom ynkompatibele feroarings. Behannelje dizze punten net as in reade flagge. Dit binne meastentiids lytse ynkompatibiliteiten dy't wat rânefunksjonaliteit befetsje dy't jo wierskynlik net brûke.
Twads, as d'r gjin manier is om kompatibiliteit te kontrolearjen yn 'e sânbak, en jo wolle fuortendaliks yn' e produksje bywurkje, is de oanbefelling dat jo dit net hoege te dwaan. Meitsje earst in sânbak en test. As d'r gjin testomjouwing is, dan hawwe jo wierskynlik gjin heul grut bedriuw, wat betsjut dat jo guon fan 'e gegevens nei jo laptop kinne kopiearje en derfoar soargje dat alles goed wurket. Jo kinne sels ferskate replika's lokaal ophelje op jo masine. Of jo kinne earne yn 'e buert in nije ferzje ophelje en guon fan' e gegevens dêr uploade - dat is, meitsje in ymprovisearre testomjouwing.
In oare regel is net te aktualisearjen foar in wike nei de frijlitting fan 'e ferzje fanwege it fangen fan bugs yn produksje en folgjende rappe fixes. Litte wy de nûmering fan ClickHouse-ferzjes útfine om net betize te wurden.
D'r is ferzje 20.3.4. It nûmer 20 jout it jier fan fabrikaazje oan - 2020. Fanút it eachpunt fan wat der binnen is, makket dit neat út, dus wy sille der gjin omtinken oan jaan. Folgjende - 20.3. Wy ferheegje it twadde nûmer - yn dit gefal 3 - elke kear as wy in release frijlitte mei wat nije funksjonaliteit. As wy wat funksje wolle tafoegje oan ClickHouse, moatte wy dit oantal ferheegje. Dat is, yn ferzje 20.4 sil ClickHouse noch better wurkje. It tredde sifer is 20.3.4. Hjir 4 is it oantal patch-releases wêryn wy gjin nije funksjes hawwe tafoege, mar wat bugs repareare. En 4 betsjut dat wy it fjouwer kear dien hawwe.
Tink net dat dit wat ferskrikliks is. Normaal kin de brûker de lêste ferzje ynstallearje en it sil wurkje sûnder problemen mei uptime per jier. Mar stel jo foar dat yn guon funksje foar it ferwurkjen fan bitmaps, dy't waard tafoege troch ús Sineeske kameraden, de tsjinner crasht by it trochjaan fan ferkearde arguminten. Wy hawwe in ferantwurdlikens om dit te reparearjen. Wy sille in nije patchferzje frijlitte en ClickHouse sil stabiler wurde.
As jo ClickHouse yn produksje hawwe, en in nije ferzje fan ClickHouse komt út mei ekstra funksjes - bygelyks 20.4.1 is de earste, haast dan net om it op 'e earste dei yn produksje te setten. Wêrom is it sels nedich? As jo ClickHouse net al brûke, dan kinne jo it ynstallearje, en nei alle gedachten sil alles goed wêze. Mar as ClickHouse al stabyl wurket, hâld dan patches en updates yn 'e gaten om te sjen hokker problemen wy reparearje.
Kirill Shvakov: Ik soe graach tafoegje in bytsje oer test omjouwings. Elkenien is tige bang foar testomjouwings en om ien of oare reden leauwe se dat as jo in heul grut ClickHouse-kluster hawwe, dan moat de testomjouwing net minder of op syn minst tsien kear lytser wêze. It is hielendal net sa.
Ik kin jo fertelle út myn eigen foarbyld. Ik haw in projekt, en der is ClickHouse. Us testomjouwing is krekt foar him - dit is in lytse firtuele masine yn Hetzner foar tweintich euro, dêr't absolút alles ynset wurdt. Om dit te dwaan, hawwe wy folsleine automatisearring yn Ansible, en dêrom makket it yn prinsipe gjin ferskil wêr't te gean - nei hardware-tsjinners of gewoan ynsette yn firtuele masines.
Wat kin dien wurde? It soe moai wêze om in foarbyld te jaan yn 'e ClickHouse-dokumintaasje oer hoe't jo in lyts kluster yn jo eigen hûs kinne ynsette - yn Docker, yn LXC, miskien in Ansible-spielboek meitsje, om't ferskate minsken ferskate ynset hawwe. Dit sil in protte ferienfâldigje. As jo in kluster yn fiif minuten nimme en ynsette, is it folle makliker om te besykjen wat út te finen. Dit is folle handiger, om't rôlje yn in produksjeferzje dy't jo net hawwe hifke in wei nei nearne is. Soms wurket it en soms net. En dêrom is hope op sukses min.
Maxim Kotyakov, senior backend-yngenieur Avito: Ik sil in bytsje tafoegje oer testomjouwings fan in searje problemen dy't grutte bedriuwen konfrontearje. Wy hawwe in folweardich ClickHouse-akseptaasjekluster; yn termen fan gegevensskema's en ynstellingen is it in krekte kopy fan wat yn produksje is. Dit kluster wurdt ynset yn frij ferrinnewearre konteners mei in minimum oan boarnen. Wy skriuwe dêr in bepaald persintaazje fan de produksjegegevens, lokkich is it mooglik om de stream yn Kafka te replikearjen. Alles is dêr syngronisearre en skalearre - sawol yn termen fan kapasiteit as stream, en, yn teory, as alle oare dingen gelyk binne, soe it moatte gedrage as produksje yn termen fan metriken. Alles wat mooglik eksplosyf is, wurdt earst op dizze tribune rôle en dêr ferskate dagen litten oant klear. Mar fansels is dizze oplossing djoer, lestich en hat net-nul stipekosten.
Alexey Milovidov: Ik sil jo fertelle hoe't de testomjouwing fan ús freonen fan Yandex.Metrica is. Ien kluster hie 600-ûneven tsjinners, in oar hie 360, en d'r is in tredde en ferskate klusters. De test omjouwing foar ien fan harren is gewoan twa shards mei twa replika's yn elk. Wêrom twa stikken? Sadat jo net allinnich binne. En der moatte ek replika's komme. Krekt in bepaald minimumbedrach dat jo kinne betelje.
Dizze testomjouwing lit jo kontrolearje oft jo fragen wurkje en as der wat wichtich is brutsen. Mar faak ûntsteane problemen fan in folslein oare aard, as alles wurket, mar der binne wat lytse feroarings yn 'e lading.
Lit my dy in foarbyld jaan. Wy besletten om in nije ferzje fan ClickHouse te ynstallearjen. It is pleatst op in testomjouwing, automatisearre testen binne foltôge yn Yandex.Metrica sels, dy't gegevens fergelykje oer de âlde ferzje en de nije, dy't de hiele pipeline útfiere. En fansels, griene tests fan ús CI. Oars hiene wy dizze ferzje net iens foarsteld.
Alles is ynoarder. Wy begjinne te bewegen yn produksje. Ik krij in berjocht dat de lading op de grafiken ferskate kearen tanommen is. Wy rôlje de ferzje werom. Ik sjoch op de grafyk en sjoch: de lading eins ferhege ferskate kearen tidens de rollout, en fermindere werom doe't se rôle út. Doe begûnen wy de ferzje werom te rôljen. En de lading naam op deselde wize ta en foel op deselde wize werom. De konklúzje is dus dit: de lading is tanommen troch de yndieling, neat ferrassend.
Doe wie it lestich om kollega's te oertsjûgjen om de nije ferzje te ynstallearjen. Ik sis: "It is goed, rôlje út. Hâld de fingers oer, alles sil wurkje. No is de lading op 'e grafiken ferhege, mar alles is goed. Bliuw hingjen." Yn 't algemien hawwe wy dit dien, en dat is it - de ferzje waard frijlitten foar produksje. Mar hast mei elke layout ûntsteane ferlykbere problemen.
Kill query moat queries deadzje, mar it docht it net. Wêrom?
In brûker, in soarte fan analist, kaam nei my en makke in fersyk dat myn ClickHouse-kluster sette. Guon knooppunt of hiele kluster, ôfhinklik fan hokker replika of shard it fersyk gie. Ik sjoch dat alle CPU boarnen op dizze tsjinner binne yn in planke, alles is read. Tagelyk reagearret ClickHouse sels op oanfragen. En ik skriuw: "Lit my asjebleaft sjen, proseslist, hokker fersyk dizze waansin generearre."
Ik fyn dit fersyk en skriuw deadzje nei it. En ik sjoch dat der neat bart. Myn tsjinner is yn in planke, ClickHouse dan jout my wat kommando, lit sjen dat de tsjinner libbet, en alles is great. Mar ik haw degradaasje yn alle brûkersoanfragen, degradaasje begjint mei records yn ClickHouse, en myn kill-query wurket net. Wêrom? Ik tocht dat kill query soe deadzje queries, mar it docht it net.
No komt der in nochal nuver antwurd. It punt is dat deadzje query net deadzje queries.
Kill query kontrolearret in lyts fak mei de namme "Ik wol dat dizze query wurdt fermoarde." En it fersyk sels sjocht nei dizze flagge by it ferwurkjen fan elk blok. As it ynsteld is, hâldt it fersyk op mei wurkjen. It docht bliken dat gjinien deadzje it fersyk, hy sels moat kontrolearje alles en stopje. En dit moat wurkje yn alle gefallen dêr't it fersyk is yn 'e steat fan ferwurkjen blokken fan gegevens. It sil it folgjende blok gegevens ferwurkje, de flagge kontrolearje en stopje.
Dit wurket net yn gefallen dêr't it fersyk is blokkearre op guon operaasje. Wier, wierskynlik is dit net jo gefal, om't, neffens jo, it in ton serverboarnen brûkt. It is mooglik dat dit net wurket yn it gefal fan eksterne sortearring en yn guon oare details. Mar yn 't algemien moat dit net barre, it is in brek. En it iennichste wat ik kin oanbefelje is om ClickHouse te aktualisearjen.
Hoe de reaksjetiid te berekkenjen ûnder lêslading?
D'r is in tabel dy't itemaggregaten bewarret - ferskate tellers. It oantal rigels is likernôch hûndert miljoen. Is it mooglik om te rekkenjen op in foarsisbere reaksjetiid as jo pour 1K RPS foar 1K items?
Troch de kontekst te oardieljen, hawwe wy it oer de lêsbelesting, om't d'r gjin problemen binne mei skriuwen - sels tûzen, sels hûnderttûzen, en soms ferskate miljoen rigen kinne wurde ynfoege.
Lêzefragen binne hiel oars. Yn selekteare 1 kin ClickHouse sawat tsientûzenen oanfragen per sekonde útfiere, dus sels oanfragen foar ien kaai sille al wat boarnen fereaskje. En sokke puntfragen sille dreger wêze as yn guon kaai-wearde-databases, om't foar elke lêzing it nedich is om in blok gegevens troch yndeks te lêzen. Us yndeks adressearret net elk rekord, mar elk berik. Dat is, jo moatte it hiele berik lêze - dit is standert 8192 rigels. En jo sille it komprimearre gegevensblok moatte dekomprimearje fan 64 KB nei 1 MB. Typysk nimme sokke doelgerichte queries in pear millisekonden om te foltôgjen. Mar dit is de ienfâldichste opsje.
Litte wy wat ienfâldige rekenen besykje. As jo in pear millisekonden mei tûzen fermannichfâldigje, krije jo in pear sekonden. It is as is it ûnmooglik om te hâlden mei tûzen oanfragen per sekonde, mar yn feite is it mooglik, om't wy ferskate prosessorkearnen hawwe. Dat, yn prinsipe, ClickHouse kin soms 1000 RPS hâlde, mar foar koarte oanfragen, spesifyk rjochte.
As jo in ClickHouse-kluster moatte skaalje troch it oantal ienfâldige oanfragen, dan advisearje ik it ienfâldichste ding - fergrutsje it oantal replika's en stjoer oanfragen nei in willekeurige replika. As ien replika fiifhûndert oanfragen per sekonde hâldt, wat folslein realistysk is, dan sille trije replika's ien en in heal tûzen behannelje.
Soms kinne jo fansels ClickHouse ynstelle foar it maksimum oantal puntlêzingen. Wat is hjirfoar nedich? De earste is om de granulariteit fan 'e yndeks te ferminderjen. Yn dit gefal moat it net wurde fermindere ta ien, mar op basis dat it oantal yngongen yn 'e yndeks ferskate miljoen of tsientallen miljoenen per tsjinner wêze sil. As de tabel hûndert miljoen rigen hat, dan kin de granulariteit ynsteld wurde op 64.
Jo kinne de grutte fan it komprimearre blok ferminderje. D'r binne ynstellings foar dit min kompresje blok grutte, maksimale kompresje blokgrutte. Se kinne wurde fermindere, opnij oanfolle mei gegevens, en dan sille rjochte fragen rapper wêze. Mar noch altyd, ClickHouse is gjin databank mei kaai-wearde. In grut oantal lytse oanfragen is in load antipattern.
Kirill Shvakov: Ik sil advys jaan foar it gefal dat der gewoane akkounts binne. Dit is in frij standert situaasje as ClickHouse in soarte fan teller opslacht. Ik haw in brûker, hy is út sa'n en sa'n lân, en guon tredde fjild, en ik moat fergrutsje wat incrementally. Nim MySQL, meitsje in unike kaai - yn MySQL is it in dûbele kaai, en yn PostgreSQL is it in konflikt - en foegje in plusteken ta. Dit sil folle better wurkje.
As jo net folle gegevens hawwe, hat d'r net folle punt om ClickHouse te brûken. D'r binne gewoane databases en dy dogge dit goed.
Wat kin ik oanpasse yn ClickHouse sadat mear gegevens yn 'e cache binne?
Litte wy ús in situaasje foarstelle - de servers hawwe 256 GB RAM, yn 'e deistige routine nimt ClickHouse sawat 60-80 GB, by peak - oant 130. Wat kin wurde ynskeakele en oanpast sadat mear gegevens yn' e cache binne en, neffens, der binne minder reizen nei de skiif?
Typysk docht de side-cache fan it bestjoeringssysteem dit goed. As jo gewoan de boppekant iepenje, sjoch dêr cached of fergees - it seit ek hoefolle is cached - dan sille jo merke dat al it frije ûnthâld wurdt brûkt foar de cache. En by it lêzen fan dizze gegevens sil it lêzen wurde net fan 'e skiif, mar fan' e RAM. Tagelyk kin ik sizze dat de cache effektyf brûkt wurdt, om't it de komprimearre gegevens is dy't yn cache binne.
As jo lykwols wat ienfâldige fragen noch mear wolle fersnelle, is it mooglik om in cache yn te skeakeljen yn 'e dekomprimearre gegevens yn ClickHouse. It hjit net-komprimearre cache. Stel yn it konfiguraasjetriem config.xml de net-komprimearre cache-grutte yn op de wearde dy't jo nedich binne - ik advisearje net mear as de helte fan 'e frije RAM, om't de rest ûnder de side-cache sil gean.
Derneist binne d'r twa ynstellings foar fersyknivo. Earste ynstelling - brûke net-komprimearre cache - omfettet it gebrûk. It is oan te rieden om it yn te skeakeljen foar alle oanfragen, útsein swiere, dy't alle gegevens kinne lêze en de cache spoelje. En de twadde ynstelling is wat as it maksimum oantal rigels om de cache te brûken. It beheint automatysk grutte queries sadat se de cache omgean.
Hoe kin ik storage_configuration ynstelle foar opslach yn RAM?
Yn 'e nije ClickHouse-dokumintaasje lês ik de seksje relatearre . De beskriuwing befettet in foarbyld mei snelle SSD.
Ik freegje my ôf hoe't itselde kin wurde konfigurearre mei folume hot ûnthâld. En noch ien fraach. Hoe wurket selektearje mei dizze gegevens organisaasje, sil it lêze de hiele set of allinnich de iene dy't op skiif, en is dizze gegevens komprimearre yn it ûnthâld? En hoe wurket de prewhere seksje mei sa'n data-organisaasje?
Dizze ynstelling hat ynfloed op de opslach fan gegevensbrokken, en har opmaak feroaret op gjin inkelde manier.
Lit ús ris efkes neier sjen.
Jo kinne konfigurearje gegevens opslach yn RAM. Alles dat is konfigurearre foar de skiif is syn paad. Jo meitsje in tmpfs-partysje dy't is monteard op in paad yn it bestânsysteem. Jo spesifisearje dit paad as it paad foar it bewarjen fan gegevens foar de heulste partysje, stikken gegevens begjinne te kommen en wurde dêr skreaun, alles is goed.
Mar ik advisearje dit net te dwaan fanwegen lege betrouberens, hoewol as jo op syn minst trije replika's hawwe yn ferskate datasintra, dan is it mooglik. As der wat bart, wurde de gegevens weromset. Lit ús yntinke dat de tsjinner ynienen waard útskeakele en wer ynskeakele. De ôfskieding waard wer monteard, mar der wie neat. As de ClickHouse-tsjinner begjint, sjocht it dat it dizze stikken net hat, hoewol, neffens ZooKeeper-metadata, se der moatte wêze. Hy sjocht nei hokker replika's se hawwe, freget se oan en downloadt se. Op dizze manier wurde de gegevens wersteld.
Yn dizze sin is it opslaan fan gegevens yn RAM net fûneminteel oars as it opslaan op skiif, want as gegevens op skiif skreaun wurde, komt it ek earst yn 'e side-cache en wurdt letter fysyk skreaun. Dit hinget ôf fan 'e opsje foar montage fan bestânsysteem. Mar foar it gefal sil ik sizze dat ClickHouse net fsync by it ynfoegjen.
Yn dit gefal wurde de gegevens yn 'e RAM opslein yn krekt itselde formaat as op' e skiif. De seleksjefraach selekteart op deselde wize de stikken dy't lêzen wurde moatte, selekteart de nedige gegevensbereiken yn 'e stikken en lêst se. En prewhere wurket krekt itselde, likefolle oft de gegevens wiene yn RAM of op skiif.
Oant hokker oantal unike wearden is Low Cardinality effektyf?
Low Cardinality is tûk ûntwurpen. It kompilearret gegevenswurdboeken, mar se binne lokaal. As earste binne d'r ferskillende wurdboeken foar elk stik, en twadde, sels binnen ien stik kinne se foar elk berik ferskille. As it oantal unike wearden in drompelnûmer berikt - ien miljoen, tink ik - wurdt it wurdboek gewoan opslein en wurdt in nij oanmakke.
It antwurd is yn it algemien: foar elk lokaal berik - sis, foar elke dei - earne oant in miljoen unike wearden is Low Cardinality effektyf. Nei ôfrin komt der gewoan in fallback, wêryn in protte ferskillende wurdboeken brûkt wurde, en net ien. It sil wurkje likernôch itselde as in gewoane string kolom, miskien in bytsje minder effisjint, mar der sil gjin serieuze prestaasjes degradaasje.
Wat binne de bêste praktiken foar it sykjen fan in tabel mei fiif miljard rigen yn folsleine tekst?
Der binne ferskillende antwurden. De earste is om te sizzen dat ClickHouse gjin sykmasjine foar folsleine tekst is. Dêr binne spesjale systemen foar, bgl. и . Ik sjoch lykwols hieltyd mear minsken sizze dat se oerstappe fan Elasticsearch nei ClickHouse.
Wêrom bart dit? Se ferklearje dit troch it feit dat Elasticsearch ophâldt om te gean mei de lading op guon folumes, te begjinnen mei de bou fan yndeksen. Yndeksen wurde te omslachtich, en as jo de gegevens gewoan oerdrage nei ClickHouse, docht bliken dat se ferskate kearen effisjinter wurde opslein yn termen fan folume. Tagelyk wiene sykfragen faak net sa dat it nedich wie om in sin te finen yn 'e folsleine folume fan gegevens, rekken hâldend mei morfology, mar folslein oare. Fyn bygelyks wat opfolging fan bytes yn 'e logs oer de lêste pear oeren.
Yn dit gefal meitsje jo in yndeks yn ClickHouse, wêrfan it earste fjild de datum en tiid sil wêze. En de grutste besuniging fan gegevens sil basearre wêze op it datumberik. Binnen it selekteare datumberik is it yn 'e regel al mooglik om in folsleine-tekst-sykje út te fieren, sels mei de brute force-metoade mei like. De like operator yn ClickHouse is de meast effisjinte like operator dy't jo kinne fine. As jo fine wat better, fertel my.
Mar dochs, lykas is in folsleine scan. En folsleine scan kin stadich wêze net allinich op 'e CPU, mar ek op' e skiif. As jo ynienen ien terabyte oan gegevens per dei hawwe, en jo sykje oerdeis nei in wurd, dan moatte jo de terabyte scannen. En it is wierskynlik op reguliere hurde skiven, en op it lêst sille se op sa'n manier laden wurde dat jo gjin tagong krije ta dizze tsjinner fia SSH.
Yn dit gefal bin ik ree om noch ien lytse trúk oan te bieden. It is eksperiminteel - it kin wurkje, it kin miskien net. ClickHouse hat folsleine tekstyndeksen yn 'e foarm fan trigram Bloom-filters. Us kollega's by Arenadata hawwe dizze yndeksen al besocht, en se wurkje faak krekt lykas bedoeld.
Om se goed te brûken, moatte jo in goed begryp hawwe fan krekt hoe't se wurkje: wat in trigram Bloom-filter is en hoe't jo de grutte kinne kieze. Ik kin sizze dat se sille helpe foar fragen oer guon seldsume frases, substrings dy't selden fûn wurde yn 'e gegevens. Yn dit gefal sille subberiken wurde selektearre troch yndeksen en sille minder gegevens lêzen wurde.
Koartlyn hat ClickHouse noch mear avansearre funksjes tafoege foar sykjen yn folsleine tekst. Dit is, as earste, in syktocht nei in boskje substrings tagelyk yn ien pass, ynklusyf opsjes dy't case-sensitive, case-unsensitive binne, mei stipe foar UTF-8 of allinich foar ASCII. Kies de meast effektive dy't jo nedich hawwe.
Sykje nei meardere reguliere útdrukkingen yn ien pas is ek ferskynd. Jo hoege X net te skriuwen as ien substring of X as in oare substring. Jo skriuwe daliks, en alles wurdt sa effisjint mooglik dien.
Tredde is der no in ûngefear sykopdracht foar regexps en in ûngefear sykopdracht foar substrings. As immen in wurd ferkeard stavere hat, wurdt it socht foar de maksimale oerienkomst.
Wat is de bêste manier om tagong ta ClickHouse te organisearjen foar in grut oantal brûkers?
Fertel ús hoe't jo tagong it bêste kinne organisearje foar in grut oantal konsuminten en analysten. Hoe kinne jo in wachtrige foarmje, prioritearje maksimale simultane queries, en mei hokker ark?
As it kluster grut genôch is, dan soe in goede oplossing wêze om noch twa servers op te heljen, dy't in yngongspunt wurde foar analysten. Dat is, lit analysten gjin tagong krije ta spesifike shards yn it kluster, mar meitsje gewoan twa lege servers, sûnder gegevens, en konfigurearje tagongsrjochten op har. Yn dit gefal wurde brûkersynstellingen foar ferspraat oanfragen oerdroegen oan servers op ôfstân. Dat is, jo konfigurearje alles op dizze twa servers, en de ynstellings hawwe effekt op it hiele kluster.
Yn prinsipe hawwe dizze servers gjin gegevens, mar it bedrach fan RAM op har is tige wichtich foar it útfieren fan fersiken. De skiif kin ek brûkt wurde foar tydlike gegevens as eksterne aggregaasje of eksterne sortearring ynskeakele is.
It is wichtich om te sjen nei de ynstellingen dy't ferbûn binne mei alle mooglike grinzen. As ik no nei it Yandex.Metrica-kluster gean as analist en freegje in fersyk selektearje count út hits, dan krij ik daliks in útsûndering dat ik it fersyk net útfiere kin. It maksimum oantal rigen dat ik mei scan is hûndert miljard, en yn totaal binne der fyftich trillion fan harren yn ien tabel op it kluster. Dit is de earste beheining.
Litte wy sizze dat ik de rigelimyt fuortsmite en de query opnij útfiere. Dan sil ik de folgjende útsûndering sjen - ynstelling ynskeakele krêft yndeks by datum. Ik kin de fraach net foltôgje as ik gjin datumbereik haw oantsjutte. Jo hoege net te fertrouwe op analisten om it manuell oan te jaan. In typysk gefal is as in datum berik wurdt skreaun dêr't evenemint datum tusken wike. En dan spesifisearre se gewoan in beugel op it ferkearde plak, en ynstee fan en it die bliken te wêzen of - of URL-oerienkomst. As d'r gjin limyt is, sil it de URL-kolom krûpe en gewoan in ton boarnen fergrieme.
Derneist hat ClickHouse twa prioriteitsynstellingen. Spitigernôch binne se tige primityf. Ien wurdt gewoan neamd prioriteit. As prioriteit ≠ 0, en fersiken mei ien of oare prioriteit wurde útfierd, mar in fersyk mei in prioriteitswearde fan minder dan, wat in hegere prioriteit betsjut, wurdt útfierd, dan wurdt in fersyk mei in prioriteitswearde fan grutter, wat in legere prioriteit betsjut , is gewoan ophâlden en sil yn dizze tiid hielendal net wurkje.
Dit is in heul rûge ynstelling en is net geskikt foar gefallen dêr't it kluster in konstante lading hat. Mar as jo koarte, bursty fersiken hawwe dy't wichtich binne, en it kluster is meast idle, dizze opset is geskikt.
De folgjende prioriteit ynstelling wurdt neamd OS thread prioriteit. It stelt gewoan de moaie wearde yn foar alle thread-útfiering fan fersyk foar de Linux-planner. It wurket sa-sa, mar it wurket noch altyd. As jo de minimale moaie wearde ynstelle - it is de grutste yn wearde, en dus de leechste prioriteit - en set -19 foar fersiken mei hege prioriteit, dan sil de CPU fersiken mei lege prioriteit sawat fjouwer kear minder konsumearje as hege prioriteiten.
Jo moatte ek de maksimale útfieringstiid fan fersyk konfigurearje - sis, fiif minuten. De minimale snelheid fan query-útfiering is it coolste ding. Dizze ynstelling bestiet al in lange tiid, en it is net allinich nedich om te beweare dat ClickHouse net fertraget, mar om it te twingen.
Stel jo foar, jo hawwe ynsteld: as guon query minder dan ien miljoen rigen per sekonde ferwurket, kinne jo dat net dwaan. Dit skande ús goede namme, ús goede databank. Litte wy dit gewoan ferbiede. Der binne eins twa ynstellings. Ien wurdt neamd min útfier snelheid - yn rigels per sekonde, en de twadde wurdt timeout neamd foardat jo min útfieringssnelheid kontrolearje - standert fyftjin sekonden. Dat is, fyftjin sekonden is mooglik, en dan, as it stadich is, smyt gewoan in útsûndering en ôfbrekke it fersyk.
Jo moatte ek quota's ynstelle. ClickHouse hat in ynboude kwotafunksje dy't boarneferbrûk telt. Mar, spitigernôch, net hardware boarnen lykas CPU, skiven, mar logyske - it oantal ferwurke oanfragen, rigels en bytes lêzen. En jo kinne bygelyks maksimaal hûndert oanfragen yn fiif minuten en tûzen oanfragen per oere ynstelle.
Wêrom is it wichtich? Om't guon analytyske queries direkt mei de hân wurde útfierd fan 'e ClickHouse-kliïnt. En alles sil goed wêze. Mar as jo avansearre analysts yn jo bedriuw, se sille skriuwe in skript, en der kin in flater yn it skript. En dizze flater sil feroarsaakje dat it fersyk wurdt útfierd yn in ûneinige lus. Dit is wêr't wy ússels tsjin moatte beskermje.
Is it mooglik om de resultaten fan ien fraach oan tsien kliïnten te jaan?
Wy hawwe ferskate brûkers dy't graach komme mei heul grutte oanfragen op itselde punt yn 'e tiid. It fersyk is grut en wurdt yn prinsipe fluch útfierd, mar troch it feit dat der tagelyk in protte sokke fersiken binne, wurdt it tige pynlik. Is it mooglik om itselde fersyk út te fieren, dat tsien kear op in rige kaam, ien kear, en it resultaat oan tsien kliïnten jaan?
It probleem is dat wy de resultaten fan 'e cache of cache fan intermediate gegevens net hawwe. D'r is in side-cache fan it bestjoeringssysteem, dat sil foarkomme dat jo gegevens fan 'e skiif wer lêze, mar spitigernôch sille de gegevens noch wurde dekomprimeare, deserialisearre en opnij ferwurke.
Ik soe dit op ien of oare manier foarkomme wolle, itsij troch tuskenlizzende gegevens te cachen, of troch ferlykbere fragen yn in soarte fan wachtrige op te lizzen en in resultatencache ta te foegjen. Wy hawwe op it stuit ien pull-fersyk yn ûntwikkeling dy't in fersyk-cache tafoegje, mar allinich foar subqueries yn 'e yn- en join-seksjes - dat is, de oplossing is net kompleet.
Wy hawwe lykwols ek te krijen mei sa'n situaasje. In bysûnder kanonike foarbyld binne paginearre queries. Der is in rapport, it hat ferskate siden, en der is in fersyk foar limyt 10. Dan itselde ding, mar limyt 10,10. Dan noch in folgjende side. En de fraach is, wêrom telle wy dit alles elke kear? Mar no is d'r gjin oplossing, en d'r is gjin manier om it te foarkommen.
D'r is in alternative oplossing dy't wurdt pleatst as in sidecar neist ClickHouse - .
Kirill Shvakov: ClickHouse Proxy hat in ynboude taryflimiter en in ynboude resultatencache. In protte ynstellingen binne dêr makke omdat in ferlykber probleem oplost waard. Proxy lit jo oanfragen beheine troch se yn 'e wachtrige te setten en yn te stellen hoe lang de fersykcache libbet. As de oanfragen echt itselde wiene, sil Proxy se in protte kearen stjoere, mar sil mar ien kear nei ClickHouse gean.
Nginx hat ek in cache yn 'e fergese ferzje, en dit sil ek wurkje. Nginx hat sels ynstellings dat as fersiken tagelyk oankomme, it oaren sil fertrage oant ien foltôge is. Mar it is yn ClickHouse Proxy dat de opset folle better wurdt dien. It is spesifyk makke foar ClickHouse, spesifyk foar dizze oanfragen, dus it is geskikter. No, it is maklik te ynstallearjen.
Hoe sit it mei asynchrone operaasjes en materialisearre werjeften?
D'r is in probleem dat operaasjes mei de replaymotor asynchrone binne - earst wurde de gegevens skreaun, dan falt se yn. As in materialisearre tablet mei guon aggregaten ûnder it teken libbet, dan wurde der duplikaten oan skreaun. En as d'r gjin komplekse logika is, dan wurde de gegevens duplikearre. Wat kinne jo der oan dwaan?
D'r is in foar de hân lizzende oplossing - om in trigger út te fieren op in bepaalde klasse fan matviews tidens in asynchrone ynstoartingsoperaasje. Binne d'r sulveren kûgels of plannen om ferlykbere funksjonaliteit út te fieren?
It is it wurdich te begripen hoe't deduplikaasje wurket. Wat ik jo no sil fertelle is net relevant foar de fraach, mar foar it gefal dat it it wurdich is om te ûnthâlden.
By it ynfoegjen yn in replikearre tabel is d'r deduplikaasje fan 'e hiele ynfoege blokken. As jo itselde blok opnij ynfoegje mei itselde oantal deselde rigen yn deselde folchoarder, dan wurde de gegevens deduplicated. Jo sille ûntfange "Ok" as antwurd op ynfoegje, mar yn feite ien pakket fan gegevens wurdt skreaun, en it sil net duplicated.
Dit is nedich foar wissichheid. As jo "Ok" ûntfange by it ynfoegjen, dan binne jo gegevens ynfoege. As jo in flater ûntfange fan ClickHouse, betsjut dit dat se net ynfoege binne en jo de ynfoegje moatte werhelje. Mar as de ferbining ferbrutsen is by it ynfoegjen, dan wite jo net oft de gegevens ynfoege binne of net. De ienige opsje is om de ynfoeging wer te werheljen. As de gegevens eins waarden ynfoege en jo hawwe se opnij ynfoege, is d'r blokdeduplikaasje. Dit is nedich om duplikaten te foarkommen.
En it is ek wichtich hoe't it wurket foar materialisearre werjeften. As de gegevens waarden deduplicated doe't ynfoege yn de haadtabel, dan sil net gean yn de materialized werjefte ek.
No oer de fraach. Jo situaasje is komplisearre omdat jo duplikaten fan yndividuele rigels opnimme. Dat is, it is net it hiele pakket dat is duplicated, mar spesifike rigels, en se falle yn 'e eftergrûn. Yndied sille de gegevens yn 'e haadtabel ynstoarte, mar de net-ynklapte gegevens sille nei de materialisearre werjefte gean, en by fúzjes sil neat barre mei de materialisearre werjeften. Omdat in materialized werjefte is neat mear as in ynfoegje trigger. By oare operaasjes bart der neat ekstra oan.
En ik kin jo hjir net bliid meitsje. Jo moatte gewoan sykje nei in spesifike oplossing foar dit gefal. Is it bygelyks mooglik om it opnij te spyljen yn in materialisearre werjefte, en de deduplikaasjemetoade kin op deselde manier wurkje. Mar spitigernôch net altyd. As it aggregearret, sil it net wurkje.
Kirill Shvakov: Wy hiene ek krukkonstruksje werom yn 'e dei. D'r wie in probleem dat d'r advertinsje-yndrukken binne, en d'r binne wat gegevens dy't wy yn realtime kinne sjen litte - dit binne gewoan yndrukken. Se wurde komselden duplicated, mar as dit bart, sille wy se letter yn elts gefal ynstoarte. En d'r wiene dingen dy't net duplisearje koene - klikken en dit hiele ferhaal. Mar ik woe se ek hast fuort sjen litte.
Hoe binne de materialisearre opfettings makke? D'r wiene werjeften wêr't it direkt skreaun waard - it waard skreaun nei rûge gegevens, en skreaun nei werjeften. Dêr binne de gegevens op in stuit net sa goed, se wurde duplikearre, ensfh. En d'r is in twadde diel fan 'e tafel, wêr't se krekt itselde sjogge as materialisearre werjeften, dat is, se binne absolút identyk yn struktuer. Ien kear yn 'e tiid berekkenje wy de gegevens opnij, telle de gegevens sûnder duplikaten, skriuwe nei dy tabellen.
Wy gongen troch de API - dit sil net manuell wurkje yn ClickHouse. En de API sjocht: doe't ik haw de datum fan 'e lêste tafoeging oan' e tafel, dêr't it is garandearre dat de krekte gegevens is al berekkene, en it makket in fersyk oan ien tafel en nei in oare tabel. Fan ien selektearret it fersyk oant in bepaalde tiid, en fan 'e oare krijt it wat noch net berekkene is. En it wurket, mar net allinich fia ClickHouse.
As jo in soarte fan API hawwe - foar analysten, foar brûkers - dan is dit yn prinsipe in opsje. Jo telle altyd, altyd telle. Dit kin ien kear deis of op in oar momint dien wurde. Jo kieze foar josels in berik dat jo net nedich binne en net kritysk is.
ClickHouse hat in protte logs. Hoe kin ik sjen alles dat bart mei de tsjinner yn ien eachopslach?
ClickHouse hat in hiel grut oantal ferskillende logs, en dit oantal nimt ta. Yn nije ferzjes binne guon fan harren sels standert ynskeakele; yn âldere ferzjes moatte se ynskeakele wurde by it bywurkjen. Lykwols, der binne hieltyd mear fan harren. Uteinlik soe ik graach sjen wat der no bart mei myn server, miskien op in soarte fan gearfetting dashboard.
Hawwe jo in ClickHouse-team, as de teams fan jo freonen, dy't wat funksjonaliteit stypje fan klearmakke dashboards dy't dizze logs as klear produkt sjen litte? Uteinlik is gewoan sjen nei logs yn ClickHouse geweldig. Mar it soe heul cool wêze as it al klear wie yn 'e foarm fan in dashboard. Ik soe der in kick fan krije.
D'r binne dashboards, hoewol se net standerdisearre binne. Yn ús bedriuw brûke sawat 60 teams ClickHouse, en it frjemdste is dat in protte fan harren dashboards hawwe dy't se foar harsels makken, en wat oars. Guon teams brûke in ynterne Yandex.Cloud-ynstallaasje. Der binne wat klearebare rapporten, hoewol net alle nedige. Oaren hawwe har eigen.
Myn kollega's fan Metrica hawwe har eigen dashboard yn Grafana, en ik haw myn eigen foar har kluster. Ik sjoch nei dingen lykas cache-hit foar de serif-cache. En noch dreger is dat wy ferskate ark brûke. Ik makke myn dashboard mei in heul âld ark neamd Graphite-web. Hy is folslein ûnsjoch. En ik brûk it noch altyd op dizze manier, hoewol Grafana soe wierskynlik handiger en moaier wêze.
It basis ding yn dashboards is itselde. Dit binne systeemmetriken foar it kluster: CPU, ûnthâld, skiif, netwurk. Oaren - oantal simultane oanfragen, oantal simultane fúzjes, oantal oanfragen per sekonde, maksimum oantal brokken foar MergeTree-tabelpartysjes, replikaasjelag, replikaasjewachtrige grutte, oantal ynfoege rigen per sekonde, oantal ynfoege blokken per sekonde. Dit is alles wat net wurdt krigen fan logs, mar út metriken.
Vladimir Kolobaev: Alexey, ik wol it in bytsje korrigearje. Dêr is Grafana. Grafana hat in gegevensboarne, dat is ClickHouse. Dat is, ik kin oanfragen meitsje fan Grafana direkt nei ClickHouse. ClickHouse hat in tabel mei logs, it is itselde foar elkenien. As gefolch, ik wol tagong ta dizze log tabel yn Grafana en sjoch de oanfragen dy't myn tsjinner makket. It soe geweldich wêze om sa'n dashboard te hawwen.
Ik fytste it sels. Mar ik haw in fraach - as it allegear standerdisearre is, en Grafana wurdt brûkt troch elkenien, wêrom hat Yandex net sa'n offisjele dashboard?
Kirill Shvakov: Eins stipet de gegevensboarne dy't nei ClickHouse giet no Altinity. En ik wol gewoan in fektor jaan fan wêr't te graven en wa't te triuwe. Jo kinne se freegje, om't Yandex noch ClickHouse makket, en net it ferhaal der omhinne. Altinity is it haadbedriuw dat op it stuit ClickHouse befoarderet. Se sille him net ferlitte, mar sille him stypje. Om't, yn prinsipe, om in dashboard op 'e Grafana-webside te uploaden, moatte jo allinich registrearje en uploade - d'r binne gjin spesjale problemen.
Alexey Milovidov: Yn it ôfrûne jier hat ClickHouse in protte mooglikheden foar query-profilearring tafoege. D'r binne metriken foar elk fersyk oer boarnegebrûk. En krekt koartlyn hawwe wy in queryprofiler op noch leger nivo tafoege om te sjen wêr't in query elke millisekonde trochbringt. Mar om dizze funksjonaliteit te brûken, moat ik de konsolekliïnt iepenje en in fersyk ynfiere, dat ik altyd ferjit. Ik bewarre it earne en bliuwe ferjitte wêr krekt.
Ik winskje dat d'r in ark wie dat krekt sei, hjir binne jo swiere fragen, groepearre troch queryklasse. Ik drukte op ien, en se soene my fertelle dat it dêrom swier is. Der is no gjin sa'n oplossing. En it is echt hiel nuver dat as minsken my freegje: "Sis my, binne der kant-en-klare dashboards foar Grafana?", ik sis: "Gean nei de Grafana-webside, d'r is in "Dashboards"-mienskip, en d'r is in dashboard út Dimka, der is in dashboard út Kostyan. Ik wit net wat it is, ik haw it sels net brûkt."
Hoe beynfloedzje fúzjes sadat de tsjinner net crasht yn OOM?
Ik haw in tafel, der is mar ien partition yn 'e tabel, it is ReplaceingMergeTree. Ik skriuw der al fjouwer jier gegevens yn. Ik moast der in feroaring yn meitsje en wat gegevens wiskje.
Ik die dit, en tidens de ferwurking fan dit fersyk waard al it ûnthâld op alle tsjinners yn it kluster konsumearre, en alle tsjinners yn it kluster gongen yn OOM. Doe kamen se allegear byinoar op, begûnen dizze selde operaasje, dit gegevensblok te fusearjen, en foelen wer yn OOM. Doe kamen se wer oerein en foelen wer. En dit ding stoppe net.
Doe die bliken dat dit eins in flater wie dy't de jonges repareare. Dit is heul cool, tige tank. Mar der bleau in oerbliuwsel oer. En no, as ik tink oan it meitsjen fan in soarte fan fúzje yn 'e tabel, haw ik in fraach - wêrom kin ik dizze fúzjes op ien of oare manier net beynfloedzje? Bygelyks, beheine se troch it bedrach fan RAM nedich, of, yn prinsipe, troch it bedrach dat sil ferwurkje dizze bepaalde tafel.
Ik haw in tabel neamd "Metrics", ferwurkje it asjebleaft foar my yn twa triedden. D'r is net nedich om tsien of fiif fúzjes parallel te meitsjen, doch it yn twa. Ik tink dat ik genôch ûnthâld haw foar twa, mar it kin net genôch wêze om tsien te ferwurkjen. Wêrom bliuwt eangst? Om't de tafel groeit, en ienris sil ik te krijen hawwe mei in situaasje dy't yn prinsipe net mear komt troch in brek, mar om't de gegevens yn sa'n grut bedrach feroarje dat ik gewoan net genôch ûnthâld op 'e tsjinner. En dan sil de tsjinner crashe yn OOM by it fusearjen. Boppedat kin ik de mutaasje annulearje, mar Merji is der net mear.
Jo witte, by it fusearjen sil de tsjinner net yn OOM falle, om't by it fusearjen it bedrach fan RAM allinich brûkt wurdt foar ien lyts berik fan gegevens. Dat alles sil goed wêze, nettsjinsteande de hoemannichte gegevens.
Vladimir Kolobaev: Moai. Hjir is it momint sa dat nei't de brek is reparearre, haw ik in nije ferzje foar mysels downloade, en op in oare tafel, in lytsere, wêr't in protte partysjes binne, haw ik in ferlykbere operaasje útfierd. En tidens de fúzje waard sawat 100 GB RAM op 'e server ferbaarnd. Ik hie 150 beset, 100 iten, en in 50 GB finster oerbleaun, dus ik foel net yn OOM.
Wat beskermet my op it stuit tsjin falle yn OOM as it eins konsumearret 100 GB RAM? Wat te dwaan as ynienen de RAM op de fúzjes rint út?
Alexey Milovidov: Der is sa'n probleem dat it konsumpsje fan RAM spesifyk foar gearfoeging net beheind is. En it twadde probleem is dat as in soarte fan fúzje is tawiisd, dan moat it útfierd wurde om't it opnommen is yn it replikaasjelog. It replikaasjelog is de aksjes dy't nedich binne om de replika yn in konsekwinte steat te bringen. As jo gjin hânmjittige manipulaasjes meitsje dy't dit replikaasjelogboek weromdraaie, sil de fúzje op ien of oare manier útfierd wurde moatte.
Fansels soe it net oerstallich wêze om in RAM-beheining te hawwen dy't "gewoan yn gefal" beskermet tsjin OOM. It sil de fúzje net helpe om te foltôgjen, it sil opnij begjinne, in drompel berikke, in útsûndering smite, en dan opnij begjinne - hjir sil neat goeds fan komme. Mar yn prinsipe soe it nuttich wêze om dizze beheining yn te fieren.
Hoe sil de Golang-bestjoerder foar ClickHouse wurde ûntwikkele?
De Golang-bestjoerder, dy't skreaun is troch Kirill Shvakov, wurdt no offisjeel stipe troch it ClickHouse-team. Hy , hy is no grut en echt.
In lytse notysje. D'r is in prachtich en leafste repository fan normale foarmen fan ûneinige oarder - dit is Vertica. Se hawwe ek har eigen offisjele python-bestjoerder, dy't wurdt stipe troch de Vertica-ûntwikkelders. En ferskate kearen barde it dat de opslachferzjes en de bestjoerderferzjes hiel dramatysk divergearre, en de bestjoerder op in stuit stoppe mei wurkjen. En it twadde punt. Stipe foar dizze offisjele bestjoerder, liket my, wurdt útfierd troch it systeem "tepel" - jo skriuwe se in probleem, en it hinget foar altyd.
Ik haw twa fragen. No is de Golang-bestjoerder fan Kirill hast de standert manier om te kommunisearjen fan Golang mei ClickHouse. Behalve as immen noch kommunisearret fia de http-ynterface om't hy it sa fynt. Hoe sil de ûntwikkeling fan dizze sjauffeur fierder gean? Sil it wurde syngronisearre mei alle brekende feroarings yn it repository sels? En wat is de proseduere foar it beskôgjen fan in probleem?
Kirill Shvakov: De earste is hoe't alles burokratysk organisearre is. Dit punt waard net besprutsen, dus ik haw neat te antwurdzjen.
Om de fraach oer it probleem te beantwurdzjen, hawwe wy in bytsje skiednis fan 'e bestjoerder nedich. Ik wurke foar in bedriuw dat in protte gegevens hie. It wie in reklamespinner mei in grut tal eveneminten dy't earne opslein wurde moasten. En op in stuit ferskynde ClickHouse. Wy folje it mei gegevens, en earst wie alles goed, mar doe ferûngelokke ClickHouse. Op dat stuit hawwe wy besletten dat wy it net nedich hawwe.
In jier letter kamen wy werom op it idee om ClickHouse te brûken, en wy moasten dêr op ien of oare manier gegevens skriuwe. It ynliedende berjocht wie dit: de hardware is heul swak, d'r binne in pear boarnen. Mar wy hawwe altyd sa wurke, en dêrom seagen wy nei it lânseigen protokol.
Sûnt wy wurken yn Go, it wie dúdlik dat wy nedich in Go-sjauffeur. Ik die it hast folsleine tiid - it wie myn wurktaak. Wy brochten it op in bepaald punt, en yn prinsipe gie nimmen derfan út dat immen oars as wy it brûke soe. Doe kaam CloudFlare mei krekt itselde probleem, en in skoft wurken wy mei har heul soepel, om't se deselde taken hiene. Boppedat diene wy dit sawol yn ClickHouse sels as yn 'e bestjoerder.
Op in stuit bin ik gewoan stoppe mei it dwaan, om't myn aktiviteit yn termen fan ClickHouse en wurk in bytsje feroare. Dêrom wurde saken net sluten. Periodyk sette minsken dy't sels wat nedich hawwe har yn foar it depot. Dan sjoch ik nei it pull-fersyk en soms bewurkje ik sels wat, mar dit bart selden.
Ik wol werom nei de sjauffeur. Ferskate jierren lyn, doe't dit hiele ding begon, wie ClickHouse ek oars en mei ferskate mooglikheden. No hawwe wy in begryp fan hoe't jo de bestjoerder opnij meitsje, sadat it goed wurket. As dit bart, dan sil ferzje 2 yn alle gefallen ynkompatibel wêze fanwege de opboude krukken.
Ik wit net hoe te organisearjen dizze saak. Ik haw sels net folle tiid. As guon minsken de sjauffeur ôfmeitsje, kin ik har helpe en fertelle wat se moatte dwaan. Mar de aktive dielname fan Yandex yn 'e ûntwikkeling fan it projekt is noch net besprutsen.
Alexey Milovidov: Yn feite is der noch gjin burokrasy oer dizze sjauffeurs. It ienige ding is dat se wurde yntsjinne by in offisjele organisaasje, dat is, dizze bestjoerder wurdt erkend as de offisjele standertoplossing foar Go. Der binne wat oare bestjoerders, mar se komme apart.
Wy hawwe gjin ynterne ûntwikkeling foar dizze sjauffeurs. De fraach is oft wy in yndividuele persoan ynhiere kinne, net foar dizze bepaalde bestjoerder, mar foar de ûntwikkeling fan alle mienskipssjauffeurs, of kinne wy immen fan bûten fine.
It eksterne wurdboek wurdt net lade nei in herstart mei de ynstelling lazy_load ynskeakele. Wat te dwaan?
Wy hawwe de ynstelling lazy_load ynskeakele, en nei't de tsjinner opnij is opstart, ladet it wurdboek net op himsels. It wurdt allinich ferhege nei't de brûker tagong hat ta dit wurdboek. En de earste kear dat ik tagong ta it, jout it in flater. Is it mooglik om op ien of oare manier automatysk wurdboeken te laden mei ClickHouse, of moatte jo har reewilligens altyd sels kontrolearje, sadat brûkers gjin flaters krije?
Miskien hawwe wy in âlde ferzje fan ClickHouse, sadat it wurdboek net automatysk lade. Koe dit it gefal wêze?
As earste kinne wurdboeken twongen wurde laden mei in query systeem reload wurdboeken. Twad, oangeande de flater - as it wurdboek al is laden, dan sille de queries wurkje op basis fan de gegevens dy't laden binne. As it wurdboek noch net laden is, wurdt it by it fersyk direkt laden.
Dit is net heul handich foar swiere wurdboeken. Jo moatte bygelyks in miljoen rigen fan MySQL lûke. Immen makket in ienfâldige seleksje, mar dizze seleksje sil wachtsje op deselde miljoen rigen. D'r binne hjir twa oplossingen. De earste is om lazy_load út te skeakeljen. Twads, as de tsjinner op is, foardat jo de lading derop sette, dwaan systeem reload wurdboek of gewoan in query dwaan dy't in wurdboek brûkt. Dan wurdt it wurdboek laden. Jo moatte de beskikberens fan wurdboeken kontrolearje mei de ynstelling lazy_load ynskeakele, om't ClickHouse se net automatysk laadt.
It antwurd op de lêste fraach is of de ferzje is âld of it moat wurde debuggen.
Wat te dwaan mei it feit dat it systeem opnij laden wurdboeken gjin ien fan 'e protte wurdboeken laadt as op syn minst ien fan har crasht mei in flater?
D'r is in oare fraach oer systeemfernijingswurdboeken. Wy hawwe twa wurdboeken - ien is net laden, de twadde is laden. Yn dit gefal lade Systeem opnij laden wurdboeken gjin wurdboek, en jo moatte punt-foar-punt lade in spesifyk troch syn namme mei help fan systeem reload wurdboek. Is dit ek besibbe oan de ClickHouse-ferzje?
Ik wol dy bliid meitsje. Dit gedrach wie feroare. Dit betsjut dat as jo ClickHouse bywurkje, sil it ek feroarje. As jo net bliid binne mei jo hjoeddeistige gedrach systeem reload wurdboeken, update, en lit ús hoopje dat it feroaret foar it better.
Is d'r in manier om details yn 'e ClickHouse-konfiguraasje te konfigurearjen, mar se net werjaan yn gefal fan flaters?
De folgjende fraach giet oer flaters yn ferbân mei it wurdboek, nammentlik details. Wy hawwe de ferbiningsdetails opjûn yn 'e ClickHouse-konfiguraasje foar it wurdboek, en as der in flater is, ûntfange wy dizze details en wachtwurd as antwurd.
Wy hawwe dizze flater oplost troch details ta te foegjen oan 'e ODBC-bestjoerderkonfiguraasje. Is d'r in manier om de details yn 'e ClickHouse-konfiguraasje te konfigurearjen, mar dizze details net sjen te litten yn gefal fan flaters?
De echte oplossing hjir is om dizze bewiisbrieven oan te jaan yn odbc.ini, en yn ClickHouse sels spesifisearje allinich de ODBC Data Source Name. Dit sil net barre foar oare wurdboekboarnen - noch foar it wurdboek mei MySQL, noch foar de oaren, jo moatte it wachtwurd net sjen as jo in flaterberjocht ûntfange. Foar ODBC sil ik ek sjen - as it bestiet, moatte jo it gewoan fuortsmite.
Bonus: eftergrûnen foar Zoom fan gearkomsten
Troch op de foto te klikken, sille bonuseftergrûnen fan 'e gearkomsten iepenje foar de meast oanhâldende lêzers. Wy douwe it fjoer tegearre mei de Avito technology maskotten, wy oerlis mei kollega's út de keamer fan de systeembehearder of de âlde skoalle kompjûter club, en wy fiere deistige gearkomsten ûnder de brêge tsjin de eftergrûn fan graffiti.
Boarne: www.habr.com