Am Abrëll hunn Avito Ingenieuren sech fir Online Reunioune mam Haapt ClickHouse Entwéckler Alexey Milovidov a Kirill Shvakov, engem Golang Entwéckler vun Integros versammelt. Mir hunn diskutéiert wéi mir en Datebankmanagementsystem benotzen a wéi eng Schwieregkeete mir begéinen.
Baséierend op der Versammlung hu mir en Artikel zesummegestallt mat Experten Äntwerten op eis an d'Froen vum Publikum iwwer Backups, Datenresharding, extern Dictionnairen, de Golang Chauffer an d'Aktualiséierung vun ClickHouse Versiounen. Et kann nëtzlech sinn fir Entwéckler, déi schonn aktiv mat der Yandex DBMS schaffen an un seng heiteg an Zukunft interesséiert sinn. Par défaut sinn d'Äntwerten vum Alexey Milovidov, wann net anescht geschriwwen.
Opgepasst, et ass vill Text ënner dem Schnëtt. Mir hoffen datt den Inhalt mat Froen Iech hëlleft ze navigéieren.
Inhalt
Wann Dir den Text net wëllt liesen, kënnt Dir d'Opname vun de Versammlungen kucken . Timecodes sinn am éischte Kommentar ënner dem Video.
ClickHouse gëtt dauernd aktualiséiert, awer eis Daten sinn net. Wat maachen doriwwer?
ClickHouse gëtt dauernd aktualiséiert, an eis Donnéeën, déi final veraarbecht optimiséiert goufen, ginn net aktualiséiert a sinn an enger Backupkopie.
Loosst eis soen datt mir e Problem haten an d'Donnéeën verluer sinn. Mir hu beschloss ze restauréieren, an et huet sech erausgestallt datt déi al Partitionen, déi op de Backup-Server gespäichert sinn, ganz anescht sinn wéi déi aktuell benotzt Versioun vum ClickHouse. Wat an esou enger Situatioun ze maachen, an ass et méiglech?
Eng Situatioun an där Dir Daten aus engem Backup an engem alen Format restauréiert hutt, awer et verbënnt net mat der neier Versioun, ass onméiglech. Mir suergen dofir datt d'Datenformat am ClickHouse ëmmer zréckkompatibel bleift. Dëst ass vill méi wichteg wéi Réckkompatibilitéit an der Funktionalitéit wann d'Behuele vun enger selten benotzter Funktioun geännert huet. Déi nei Versioun vum ClickHouse sollt ëmmer fäeg sinn d'Donnéeën ze liesen déi op der Disk gespäichert sinn. Dëst ass d'Gesetz.
Wat sinn déi aktuell bescht Praktiken fir Backup vun Daten aus ClickHouse?
Wéi maachen ech Backups, berécksiichtegt datt mir endgülteg Operatiounen optimiséieren, eng rieseg Datebank vun Terabytes, an Daten déi aktualiséiert ginn, soen, fir déi lescht dräi Deeg, an da passéieren keng Prozeduren?
Mir kënnen eis eege Léisung maachen an op de Bash schreiwen: sammelt dës Backupkopien op esou an esou eng Manéier. Vläicht ass et net néideg eppes ze kräischen, an de Vëlo ass scho laang erfonnt?
Loosst eis mat de beschten Praktiken ufänken. Meng Kollegen roden ëmmer, als Äntwert op Froen iwwer Backups, hinnen un de Yandex.Cloud Service ze erënneren, wou dëse Problem scho geléist gouf. Also benotzt et wann méiglech.
Et gëtt keng komplett Léisung fir Backups, honnert Prozent a ClickHouse agebaut. Et ginn e puer eidel déi benotzt kënne ginn. Fir eng komplett Léisung ze kréien, musst Dir entweder e bësse manuell manipuléieren, oder Wrapper a Form vu Scripten erstellen.
Ech fänke mat den einfachsten Léisungen un a mat de raffinéiertsten ophalen, ofhängeg vum Volume vun den Donnéeën an der Gréisst vum Cluster. Wat méi grouss de Cluster ass, dest méi komplex gëtt d'Léisung.
Wann den Dësch mat Daten nëmmen e puer Gigabytes besetzt, kann de Backup esou gemaach ginn:
- Table Definitioun späicheren dh Metadaten - weisen schafen Dësch.
- Maacht en Dump mam ClickHouse Client - wielt * vum Dësch ze Fichier. Par défaut kritt Dir eng Datei am TabSeparated Format. Wann Dir méi effizient wëllt sinn, kënnt Dir et am Native Format maachen.
Wann d'Quantitéit vun Daten méi grouss ass, da wäert de Backup méi Zäit a vill Plaz huelen. Dëst gëtt e logesche Backup genannt; et ass net mam ClickHouse Dateformat gebonnen. Wann et ass, da kënnt Dir als leschten Auswee e Backup huelen an en op MySQL eropluede fir d'Erhuelung.
Fir méi fortgeschratt Fäll huet ClickHouse eng agebaute Fäegkeet fir e Snapshot vu Partitionen am lokalen Dateiesystem ze kreéieren. Dës Fonktioun ass verfügbar als Ufro änneren Dësch Afréiere Partition. Oder einfach änneren Dësch Afréiere - Dëst ass e Snapshot vum ganzen Dësch.
De Snapshot gëtt konsequent fir een Dësch op engem Shard erstallt, dat heescht, et ass onméiglech fir e konsequent Snapshot vum ganze Cluster op dës Manéier ze kreéieren. Awer fir déi meescht Aufgaben ass et net sou néideg, an et ass genuch fir eng Ufro op all Shard auszeféieren an e konsequent Snapshot ze kréien. Et gëtt a Form vun Hardlinks erstallt an dofir brauch net zousätzlech Plaz. Als nächst kopéiert Dir dëse Snapshot op de Backup-Server oder op d'Späichere, déi Dir fir Backups benotzt.
Sou e Backup restauréieren ass ganz einfach. Als éischt, erstellt Dëscher mat existéierende Tabelldefinitioune. Als nächst kopéiert déi gespäichert Schnappschëss vun de Partitionen op Directory-Detached fir dës Dëscher a lafen d'Ufro Partition befestegt. Dës Léisung ass ganz gëeegent fir déi seriöste Volumen vun Daten.
Heiansdo brauch Dir eppes nach méi cool - a Fäll wou Dir zéng oder souguer Honnerte vun Terabytes op all Server an Honnerte vu Serveren hutt. Et gëtt eng Léisung hei, déi ech vu menge Kollege vu Yandex.Metrica opgeholl hunn. Ech géif et net jidderengem recommandéieren - liest et an entscheet fir Iech selwer ob et gëeegent ass oder net.
Als éischt musst Dir e puer Servere mat groussen Disk Regaler erstellen. Als nächst, op dëse Serveren, erhéijen e puer ClickHouse Serveren a konfiguréieren se sou datt se als eng aner Replika fir déiselwecht Schnëtt funktionnéieren. A benotzt dann e Dateiesystem oder en Tool op dëse Serveren, deen Iech erlaabt Snapshots ze kreéieren. Et ginn zwou Méiglechkeeten hei. Déi éischt Optioun ass LVM Snapshots, déi zweet Optioun ass ZFS op Linux.
Duerno musst Dir all Dag e Snapshot erstellen, et wäert leien an e bësse Plaz ophuelen. Natierlech, wann d'Donnéeën ännert, wäert d'Quantitéit u Raum mat der Zäit eropgoen. Dëse Snapshot kann zu all Moment erausgeholl ginn an d'Donnéeën restauréiert ginn, sou eng komesch Léisung. Plus, mir mussen och dës Repliken an der Configuratioun limitéieren fir datt se net probéieren Leader ze ginn.
Ass et méiglech eng kontrolléiert Lag vu Repliken an de Schaften ze organiséieren?
Dëst Joer plangt Dir Schaften am ClickHouse ze maachen. Wäert et méiglech sinn eng kontrolléiert Lag vun Repliken an hinnen ze organiséieren? Mir wëllen et benotze fir eis virun negativen Szenarie mat Ännerungen an aner Ännerungen ze schützen.
Ass et méiglech eng Zort Réckroll fir Ännerungen ze maachen? Zum Beispill, an engem bestehend Schacht, huelen a soen, datt bis dëse Moment Dir d'Ännerungen gëlle, a vun dësem Moment Dir ophalen d'Ännerungen ze gëllen?
Wann e Kommando an eise Stärekoup komm ass an et gebrach huet, dann hu mir eng bedingt Replika mat enger Stonn Lag, wou mir kënne soen datt mir et am Moment benotzen, awer mir wäerte keng Ännerunge fir déi lescht zéng Minutten applizéieren?
Éischtens, iwwer déi kontrolléiert Lag vu Repliken. Et gouf sou eng Ufro vun de Benotzer, a mir hunn en Thema op Github erstallt mat der Ufro: "Wann een dat brauch, gär et, setzt en Häerz." Keen huet geliwwert, an d'Emissioun gouf zougemaach. Wéi och ëmmer, Dir kënnt dës Geleeënheet scho kréien andeems Dir ClickHouse opstellt. Richteg, nëmmen ab Versioun 20.3.
ClickHouse mécht dauernd Datenfusion am Hannergrond. Wann eng Fusioun ofgeschloss ass, gëtt e bestëmmte Set vu Stécker vun Daten duerch e méi grousst Stéck ersat. Zur selwechter Zäit bleiwen d'Stécker vun Daten, déi virdru do waren, fir eng Zäit op der Disk bleiwen.
Als éischt gi se weider gelagert soulaang et ausgewielte Ufroe sinn déi se benotzen, fir net blockéierend Operatioun ze bidden. Wielt Ufroe ginn einfach aus alen Stécker gelies.
Zweetens gëtt et och eng Zäitschwell - al Stécker vun Daten leien op der Disk fir aacht Minutten. Dës aacht Minutte kënne personaliséiert ginn a souguer an een Dag ëmgewandelt ginn. Dëst wäert Disk Space kaschten: ofhängeg vum Datefloss, stellt sech eraus datt am leschten Dag d'Donnéeën net nëmmen verduebelt ginn, se kënnen fënnef Mol méi ginn. Awer wann et e seriöse Problem ass, kënnt Dir de ClickHouse Server stoppen an alles sortéieren.
Elo stellt sech d'Fro wéi dëst géint Ännerunge schützt. Et lount sech hei méi déif ze kucken, well an eelere Versioune vu ClickHouse huet den Alter esou funktionéiert datt et einfach Stécker direkt geännert huet. Et gëtt e Stéck Daten mat e puer Dateien, a mir maachen z.B. änneren Drop Kolonn. Da gëtt dës Kolonn kierperlech aus all Stécker geläscht.
Awer mat der Versioun 20.3 unzefänken, ass den Ännerungsmechanismus komplett geännert ginn, an elo sinn Datenstécker ëmmer onverännerbar. Si änneren guer net - Ännerunge funktionnéieren elo sou vill wéi Fusioune. Amplaz e Stéck op der Plaz ze ersetzen, kreéiere mir en neit. Am neie Stéck ginn Dateien déi net geännert hunn Hardlinks, a wa mir eng Kolonn läschen, da fehlt se einfach am neie Stéck. Dat alt Stéck gëtt no aacht Minutten par défaut geläscht, an hei kënnt Dir d'Astellungen uewe genannten upassen.
Datselwecht gëllt fir Ännerunge wéi Mutatiounen. Wann Dir maacht änneren läschen oder update änneren, et ännert net d'Stéck, mee schaaft en neit. An dann läscht déi al.
Wat wann d'Tabellstruktur geännert huet?
Wéi restauréiert ech e Backup dee mam alen Schema gemaach gouf? An déi zweet Fro ass iwwer de Fall mat Snapshots a Dateisystem Tools. Ass Btrfs gutt hei amplaz ZFS op Linux LVM?
Wann Dir maacht Partition befestegt Partitionen mat enger anerer Struktur, da wäert ClickHouse Iech soen datt dëst net méiglech ass. Dëst ass d'Léisung. Déi éischt ass eng temporär Tabell vum MergeTree-Typ mat der aler Struktur ze kreéieren, Daten do mat Befestigung ze befestigen an eng Ännerungsufro ze maachen. Da kënnt Dir dës Donnéeën entweder kopéieren oder iwwerdroen an erëm befestegt, oder eng Ufro benotzen änneren Dësch Plënneren Partitur.
Elo ass déi zweet Fro ob Btrfs kënne benotzt ginn. Fir unzefänken, wann Dir LVM hutt, da sinn LVM Snapshots genuch, an de Dateiesystem kann ext4 sinn, et ass egal. Mat Btrts hänkt alles vun Ärer Erfahrung beim Gebrauch of. Dëst ass e reife Dateiesystem, awer et ginn nach ëmmer e puer Verdacht iwwer wéi alles an der Praxis an engem bestëmmte Szenario funktionnéiert. Ech géif net recommandéieren dëst ze benotzen ausser Dir hutt Btrfs an der Produktioun.
Wat sinn déi aktuell bescht Praktiken am Dateschutz?
D'Fro vum Resharding ass komplex a villsäiteg. Et gi verschidde méiglech Äntwerten hei. Dir kënnt vun enger Säit goen an dëst soen - ClickHouse huet keng agebaute Resharding Feature. Mee ech fäerten, datt dës Äntwert kee passt. Dofir kënnt Dir vun der anerer Säit goen a soen datt ClickHouse vill Weeër huet fir Daten ze reshardéieren.
Wann de Stärekoup aus Plaz leeft oder et kann d'Laascht net handhaben, füügt Dir nei Serveren derbäi. Awer dës Servere sinn als Standard eidel, et gi keng Daten op hinnen, et gëtt keng Laascht. Dir musst d'Donnéeën nei arrangéieren sou datt se gläichméisseg iwwer den neien, méi grousse Stärekoup verdeelt ginn.
Déi éischt Manéier dëst ka gemaach ginn ass en Deel vun de Partitionen op nei Serveren ze kopéieren mat enger Ufro Änneren d'Tabellefech-Partition. Zum Beispill, hutt Dir Partitionen vum Mount, an Dir huelt den éischte Mount vun 2017 a kopéiert et op en neie Server, kopéiert dann den drëtte Mount op en aneren neie Server. An Dir maacht dat bis et méi oder manner gläichméisseg gëtt.
Transfer kann nëmme fir déi Partitionen duerchgefouert ginn, déi net während der Opnam änneren. Fir frësch Cloisonnementer, Opnam muss behënnert ginn, well hir Transfert net atomarer ass. Soss wäert Dir mat Duplikaten oder Lücken an den Donnéeën ophalen. Wéi och ëmmer, dës Method ass praktesch a funktionnéiert ganz effektiv. Fäerdeg kompriméiert Partitionen ginn iwwer de Netz iwwerdroen, dat heescht, d'Donnéeën ginn net kompriméiert oder nei kodéiert.
Dës Method huet een Nodeel, an et hänkt op der sharding Schema, ob Dir zu dësem sharding Schema verpflichte, wat sharding Schlëssel Dir hat. An Ärem Beispill fir de Fall mat Metriken, ass de Sharding Schlëssel den Hash vum Wee. Wann Dir e Verdeelt Dësch wielt, geet et op all Schnëtt am Stärekoup op eemol an hëlt Daten vun do.
Dëst bedeit datt et Iech tatsächlech egal ass wéi eng Donnéeën op wéi engem Shard opgetruede sinn. D'Haaptsaach ass datt d'Donnéeën op engem Wee op engem Schnëtt enden, awer wéi eng ass net wichteg. An dësem Fall ass d'Transfert vu fäerdege Partitionen perfekt, well mat ausgewielten Ufroen kritt Dir och komplett Donnéeën - ob virum Resharding oder duerno, de Schema ass net wierklech wichteg.
Awer et gi Fäll déi méi komplizéiert sinn. Wann op der Applikatioun Logik Niveau Dir op eng speziell sharding Schema vertrauen, datt dëse Client op esou an esou engem shard läit, an der Demande kann direkt do geschéckt ginn, an net op d'Verdeelt Dësch. Oder Dir benotzt eng zimlech rezent Versioun vum ClickHouse an hutt d'Astellung aktivéiert optimiséieren iwwerspréngt onbenotzt Schnëtt. An dësem Fall, während der Auswiel Ufro, gëtt den Ausdrock an der wou Sektioun analyséiert an et gëtt berechent wéi eng Schnëtt musse benotzt ginn no dem Scherpschema. Dëst funktionnéiert virausgesat datt d'Donnéeën genau no dësem Sharding Schema opgedeelt sinn. Wann Dir se manuell nei arrangéiert hutt, kann d'Korrespondenz änneren.
Also ass dëst Method Nummer eent. An ech waarden op Är Äntwert, ob d'Method gëeegent ass, oder loosst eis weidergoen.
Vladimir Kolobaev, Lead System Administrator bei Avito: Alexey, d'Method déi Dir ernimmt hutt funktionnéiert net ganz gutt wann Dir d'Laascht verbreet musst, och d'Liesen. Mir kënnen eng Partition huelen déi monatlecht ass a kann de viregte Mount op en aneren Node huelen, awer wann eng Ufro fir dës Donnéeën kënnt, luede mir se nëmmen. Mir wëllen awer de ganze Cluster lueden, well soss gëtt fir eng Zäit déi ganz Lieslaascht duerch zwee Schnëtt veraarbecht.
Alexey Milovidov: D'Äntwert hei ass komesch - jo, et ass schlecht, awer et kéint funktionnéieren. Ech erkläre genau wéi. Et ass derwäert de Lastszenario ze kucken deen hannert Ären Donnéeën kënnt. Wann dëst d'Iwwerwaachungsdaten ass, da kënne mir bal sécher soen datt déi grouss Majoritéit vun den Ufroe fir frësch Daten sinn.
Dir hutt nei Serveren installéiert, al Partitionen migréiert, awer och geännert wéi frësch Daten opgeholl ginn. A frësch Daten wäerten am ganze Cluster verbreet ginn. Also, no just fënnef Minutten, Ufroe fir déi lescht fënnef Minutten wäert de Stärekoup gläichméisseg lueden; no engem Dag wäerten Ufroe fir XNUMX Stonnen de Stärekoup gläichméisseg lueden. An Ufroe fir de leschte Mount, leider, ginn nëmmen op en Deel vun de Clusterserveren.
Awer dacks hutt Dir keng Ufroe speziell fir Februar 2019. Wahrscheinlech, wann Ufroen an 2019 goen, da wäerte se fir de ganze Joer 2019 sinn - fir eng grouss Zäit, an net fir e puer kleng Gamme. An esou Ufroe wäerten och fäeg sinn de Cluster gläichméisseg ze laden. Awer allgemeng ass Är Remarque absolut richteg datt dëst eng ad hoc Léisung ass, déi d'Donnéeën net komplett gläichméisseg verdeelt.
Ech hunn e puer méi Punkte fir d'Fro ze beäntweren. Ee vun hinnen ass iwwer wéi een am Ufank e Schnëttschema designt, sou datt d'Wiederschierm manner Schmerz verursaacht. Dëst ass net ëmmer méiglech.
Zum Beispill hutt Dir Iwwerwaachungsdaten. Iwwerwaachungsdaten wuessen aus dräi Grënn. Déi éischt ass d'Akkumulation vun historeschen Donnéeën. Déi zweet ass de Verkéierswuesstem. An déi drëtt ass eng Erhéijung vun der Unzuel vun de Saachen déi iwwerwaacht ginn. Et ginn nei Mikroservicer a Metriken déi musse gespäichert ginn.
Et ass méiglech datt vun dësen déi gréissten Erhéijung mam drëtte Grond assoziéiert - d'Erhéijung vun der Benotzung vun der Iwwerwaachung. An an dësem Fall ass et derwäert ze kucken op d'Natur vun der Laascht, wat sinn d'Haaptauswiel Ufroen. Basis Auswiel Ufroe wäerten héchstwahrscheinlech op e puer Ënnerdeeler vu Metriken baséieren.
Zum Beispill, CPU Benotzung op e puer Serveren vun engem Service. Et stellt sech eraus datt et e gewëssen Ënnerdeel vu Schlësselen ass, mat deenen Dir dës Donnéeën kritt. An d'Ufro selwer fir dës Donnéeën ass héchstwahrscheinlech ganz einfach a gëtt an zéng Millisekonnen ofgeschloss. Benotzt fir Iwwerwaachungsservicer an Dashboards. Ech hoffen ech verstinn dat richteg.
Vladimir Kolobaev: D'Tatsaach ass, datt mir ganz dacks op historesch Donnéeën appelléieren, well mir déi aktuell Situatioun mat der historescher an Echtzäit vergläichen. An et ass wichteg fir eis séier Zougang zu enger grousser Quantitéit vun Donnéeën ze hunn, an ClickHouse mécht eng exzellent Aarbecht mat dëser.
Dir hutt absolut Recht, mir erliewen déi meescht vun de Liesufroen am leschten Dag, wéi all Iwwerwaachungssystem. Awer zur selwechter Zäit ass d'Laascht op historesch Daten och zimlech grouss. Et ass am Fong vun engem Alarmsystem, deen all drësseg Sekonnen ronderëm geet an dem ClickHouse seet: "Gëff mir d'Donnéeën fir déi lescht sechs Wochen. Elo bauen mir eng Aart vu bewegend Duerchschnëtt vun hinnen, a loosst eis den aktuelle Wäert mat dem historeschen vergläichen.
Ech wëll soen, datt mir fir esou ganz rezent Ufroe nach eng aner kleng Tabell hunn, an där mir nëmmen zwee Deeg Daten späicheren, an d'Haaptufroe fléien an et. Mir schécken nëmmen grouss historesch Ufroen op de grousse sharded Dësch.
Alexey Milovidov: Leider stellt sech eraus datt et schlecht applicabel ass fir Ären Szenario, awer ech wäert Iech eng Beschreiwung vun zwee schlechten a komplexe Schnëttschemaen soen, déi net gebraucht ginn, awer déi an de Service vu menge Frënn benotzt ginn.
Et gëtt en Haaptcluster mat Yandex.Metrica Eventer. Eventer sinn Säit Meenung, Klicks, an Konversiounen. Déi meescht Ufroe ginn op eng spezifesch Websäit. Dir öffnen de Yandex.Metrica Service, Dir hutt eng Websäit - avito.ru, gitt op de Bericht, an eng Demande gëtt fir Är Websäit gemaach.
Awer et ginn aner Ufroen - analytesch a global - déi vun internen Analysten gemaach ginn. Just am Fall, notéieren ech datt intern Analysten Ufroe nëmme fir Yandex Servicer maachen. Awer trotzdem besetzen och Yandex Servicer e groussen Undeel vun all Daten. Dëst sinn Ufroe net fir spezifesch Zähler, mee fir méi breet Filteren.
Wéi organiséieren d'Donnéeën esou datt alles effizient fir ee Konter funktionnéiert, an och global Ufroen? Eng aner Schwieregkeet ass datt d'Zuel vun den Ufroen am ClickHouse fir de Metric Cluster e puer dausend pro Sekonn ass. Zur selwechter Zäit kann een ClickHouse Server net net-trivial Ufroen handhaben, zum Beispill e puer dausend pro Sekonn.
D'Clustergréisst ass sechshonnert-eppes Serveren. Wann Dir einfach en Verdeelt Dësch iwwer dëse Stärekoup zitt an e puer dausend Ufroen do schéckt, gëtt et nach méi schlëmm wéi se op ee Server ze schécken. Op der anerer Säit gëtt d'Optioun datt d'Donnéeën gläichméisseg verdeelt sinn, a mir ginn an Ufro vun all Server, gëtt direkt entlooss.
Et gëtt eng Optioun déi diametral Géigendeel ass. Stellt Iech vir, wa mir d'Donnéeën iwwer Siten zerstéieren, an eng Ufro fir ee Site op e Schnëtt geet. Elo wäert de Stärekoup zéngdausend Ufroe pro Sekonn handhaben, awer op engem Shard funktionnéiert all Ufro ze lues. Et wäert net méi Skala a punkto Débit. Besonnesch wann dëst de Site avito.ru ass. Ech wäert d'Geheimnis net verroden wann ech soen datt Avito ee vun de meescht besichte Siten am RuNet ass. An et op engem Schnëtt ze veraarbecht wier Wahnsinn.
Dofir ass d'Sharding Schema op eng méi lëschteg Manéier entworf. De ganze Cluster ass an eng Rei vu Cluster opgedeelt, déi mir Schichten nennen. All Stärekoup enthält vun enger Dosen bis e puer Dosen Schäerft. Et ginn néngdrësseg esou Cluster am Ganzen.
Wéi gëtt dëst alles Skala? D'Zuel vun de Stärekéip ännert sech net - wéi et virun e puer Joer drësseg-néng war, bleift et esou. Awer bannent jidderee vun hinnen erhéije mir d'Zuel vun de Stécker graduell wéi mir Daten sammelen. An d'Sharding Schema als Ganzt ass esou: dës Cluster sinn op Websäiten opgedeelt, a fir ze verstoen wéi eng Websäit op wéi engem Cluster ass, gëtt eng separat Metabase am MySQL benotzt. Ee Site - op engem Stärekoup. An dobannen geschitt Sharding no Visiteur IDen.
Beim Opnam deele mir se duerch de Rescht vun der Divisioun vun der Visiteur ID. Awer wann Dir en neie Schärft bäidréit, ännert d'Sharding Schema; Mir fuere weider opzedeelen, awer mat engem Rescht vun der Divisioun duerch eng aner Zuel. Dat heescht, datt ee Visiteur schonn op e puer Serveren läit, an Dir kënnt net op dëser vertrauen. Dëst gëtt eleng gemaach fir sécherzestellen datt d'Donnéeë besser kompriméiert sinn. A wa mir Ufroe maachen, gi mir op den Verdeelt Dësch, deen de Stärekoup kuckt an op Dosende vu Serveren zougräift. Dëst ass sou en domm Schema.
Awer meng Geschicht wäert onkomplett sinn wann ech net soen datt mir dëse Schema opginn hunn. Am neie Schema hu mir alles geännert an all d'Donnéeën mat Clickhouse-Copier kopéiert.
Am neie Schema sinn all Siten an zwou Kategorien opgedeelt - grouss a kleng. Ech weess net wéi d'Schwell gewielt gouf, awer d'Resultat ass datt grouss Siten op engem Stärekoup opgeholl ginn, wou et 120 Stécker mat dräi Repliken all - dat ass 360 Server. An de Schema vum Schnëtt ass sou datt all Ufro un all Schnëtt gläichzäiteg geet. Wann Dir elo all Bericht Säit fir avito.ru an Yandex.Metrica opmaacht, wäert d'Ufro op 120 Server goen. Et gi puer grouss Siten am RuNet. An d'Demande sinn net dausend pro Sekonn, awer och manner wéi honnert. All dëst gëtt roueg vum Distributed Dësch gekauft, dee jidderee vun hinnen mat 120 Server veraarbecht.
An den zweete Cluster ass fir kleng Siten. Hei ass e Sharding Schema baséiert op der Site ID, an all Ufro geet genee ee Shard.
ClickHouse huet e Clickhouse-Copier Utility. Kënnt Dir eis iwwer hatt soen?
Ech wäert direkt soen datt dës Léisung méi ëmständlech an e bësse manner produktiv ass. De Virdeel ass datt et d'Donnéeën komplett schmiert no dem Muster deen Dir spezifizéiert. Awer den Nodeel vum Utility ass datt et guer net reshardt. Et kopéiert Daten vun engem Clusterschema an en anert Clusterschema.
Dëst bedeit datt fir datt et funktionnéiert, musst Dir zwee Cluster hunn. Si kënnen op de selwechte Server lokaliséiert ginn, awer trotzdem ginn d'Donnéeën net inkrementell geréckelt, awer kopéiert.
Zum Beispill, et waren véier Serveren, elo sinn et aacht. Dir erstellt en neien Verdeelt Dësch op all Server, nei lokal Dëscher a lancéiert Clickhouse-Copier, beweist an deem d'Aarbechtsschema datt et vun do soll liesen, akzeptéiert dat neit Sharding Schema an transferéiert d'Donnéeën dohinner. An op ale Server brauch Dir annerhallef Mol méi Plaz wéi elo, well déi al Donnéeën mussen drop bleiwen, an d'Halschent vun deenen selwechten alen Donnéeën dorop ukommen. Wann Dir am Viraus geduecht hutt datt d'Donnéeën ëmgeschalt musse ginn an et Plaz ass, dann ass dës Method gëeegent.
Wéi funktionnéiert Clickhouse-Copier dobannen? Et brécht all d'Aarbecht an eng Rei vun Aufgaben fir eng Partition vun engem Dësch op engem Shard ze veraarbecht. All dës Aufgaben kënnen parallel ausgefouert ginn, a Clickhouse-Copier kann op verschidde Maschinnen a ville Fäll lafen, awer wat et fir eng Partition mécht ass näischt méi wéi eng Insert-Auswiel. D'Donnéeë ginn gelies, dekompriméiert, repartitionéiert, dann erëm kompriméiert, iergendwou geschriwwen a nei sortéiert. Dëst ass eng méi haart Entscheedung.
Dir hat eng Pilot Saach genannt resharding. Wat mat hir?
Zréck an 2017, hutt Dir eng Pilot Saach genannt resharding. Et gëtt souguer eng Optioun am ClickHouse. Wéi ech et verstinn, huet et net ofgeholl. Kënnt Dir mir soen firwat dat geschitt ass? Et schéngt ganz relevant ze sinn.
De ganze Problem ass datt wann et néideg ass Daten op der Plaz ze resharden, ass ganz komplex Synchroniséierung erfuerderlech fir dëst atomesch ze maachen. Wéi mir ugefaang hunn ze kucken wéi dës Synchroniséierung funktionnéiert, gouf kloer datt et fundamental Probleemer gëtt. An dës grondleeënd Problemer sinn net nëmmen theoretesch, mä direkt ugefaang selwer an der Praxis an der Form vun eppes ze weisen, datt ganz einfach erkläert ginn - näischt funktionnéiert.
Ass et méiglech all Stécker vun Daten zesummen ze fusionéieren ier se op luesen Disken geplënnert ginn?
Fro iwwer TTL mam Plënneren op luesen Disk Optioun am Kontext vun Fusioun. Gëtt et e Wee, anescht wéi iwwer Cron, all Deeler an een ze fusionéieren ier se op luesen Disken geplënnert ginn?
D'Äntwert op d'Fro ass et méiglech iergendwéi automatesch all d'Stécker an een ze pechen ier Dir se transferéiert - nee. Ech mengen dat ass net néideg. Dir musst net all Deeler an een fusionéieren, awer einfach op d'Tatsaach zielen datt se automatesch op luesen Disken transferéiert ginn.
Mir hunn zwee Critèrë fir Transfert Regelen. Déi éischt ass wéi et gefëllt ass. Wann déi aktuell Stockage Tier manner wéi e bestëmmte Prozentsaz vun fräi Plaz huet, wielt mir ee Stéck a réckelen et méi lues Stockage. Oder éischter, net méi lues, mä déi nächst - wéi Dir konfiguréiert.
Déi zweet Critère ass Gréisst. Et geet drëm grouss Stécker ze beweegen. Dir kënnt d'Schwell no der fräier Plaz op der Fast Disk ajustéieren, an d'Donnéeë ginn automatesch transferéiert.
Wéi migréiere ech op nei Versioune vum ClickHouse wann et kee Wee ass fir d'Kompatibilitéit am Viraus ze kontrolléieren?
Dëst Thema gëtt regelméisseg diskutéiert verschidde Versiounen berücksichtegt, an nach ëmmer. Wéi sécher ass et vun der Versioun 19.11 op 19.16 an zum Beispill vun 19.16 op 20.3. Wat ass de beschte Wee fir op nei Versiounen ze migréieren ouni d'Kompatibilitéit am Viraus an der Sandkëscht ze kontrolléieren?
Et gi verschidde "gëllene" Regelen hei. Éischten - . Et ass grouss, awer et gi separat Paragrafen iwwer réckgängeg inkompatibel Ännerungen. Gitt dës Punkten net als e roude Fändel. Dëst sinn normalerweis kleng Inkompatibilitéiten déi eng Randfunktionalitéit involvéieren déi Dir ganz wahrscheinlech net benotzt.
Zweetens, wann et kee Wee ass fir d'Kompatibilitéit an der Sandkëscht z'iwwerpréiwen, an Dir wëllt direkt an der Produktioun aktualiséieren, ass d'Empfehlung datt Dir dëst net braucht. Erstellt als éischt eng Sandkëscht an Test. Wann et keen Testëmfeld gëtt, hutt Dir héchstwahrscheinlech keng ganz grouss Firma, dat heescht datt Dir e puer vun den Donnéeën op Äre Laptop kopéiere kënnt a sécherstellen datt alles richteg funktionnéiert. Dir kënnt souguer e puer Repliken lokal op Ärer Maschinn erhéijen. Oder Dir kënnt eng nei Versioun iergendwou an der Géigend ophuelen an e puer vun den Donnéeën do eroplueden - dat heescht, en improviséierte Testëmfeld erstellen.
Eng aner Regel ass net fir eng Woch no der Verëffentlechung vun der Versioun ze aktualiséieren wéinst Bugs an der Produktioun a spéider Quick Fixes. Loosst eis d'Nummeréierung vu ClickHouse Versiounen erausfannen fir net duercherneen ze ginn.
Et gëtt Versioun 20.3.4. D'Nummer 20 weist d'Joer vun der Fabrikatioun un - 2020. Aus der Siicht vu wat dobannen ass, ass dat egal, also wäerte mir net oppassen. Nächst - 20.3. Mir erhéijen déi zweet Zuel - an dësem Fall 3 - all Kéier wann mir eng Verëffentlechung mat e puer nei Funktionalitéit erausginn. Wa mir eng Feature op ClickHouse wëllen addéieren, musse mir dës Zuel erhéijen. Dat ass, an der Versioun 20.4 ClickHouse wäert nach besser funktionnéieren. Déi drëtt Ziffer ass 20.3.4. Hei 4 ass d'Zuel vu Patch Verëffentlechungen an deenen mir keng nei Features bäigefüügt hunn, awer e puer Bugs fixéiert hunn. A 4 heescht datt mir et véiermol gemaach hunn.
Denkt net datt dëst eppes schreckleches ass. Normalerweis kann de Benotzer déi lescht Versioun installéieren an et funktionnéiert ouni Probleemer mat Uptime pro Joer. Awer stellt Iech vir datt an enger Funktioun fir Bitmaps ze veraarbecht, déi vun eise chinesesche Komeroden bäigefüügt gouf, de Server crasht wann Dir falsch Argumenter passéiert. Mir hunn eng Verantwortung dëst ze fixéieren. Mir wäerten eng nei Patch Versioun erausginn an ClickHouse wäert méi stabil ginn.
Wann Dir ClickHouse an der Produktioun leeft, an eng nei Versioun vum ClickHouse kënnt mat zousätzlech Funktiounen eraus - zum Beispill, 20.4.1 ass deen éischten, presséiert et net op den éischten Dag a Produktioun ze setzen. Firwat ass et iwwerhaapt gebraucht? Wann Dir net schonn ClickHouse benotzt, da kënnt Dir et installéieren, a wahrscheinlech wäert alles gutt sinn. Awer wann ClickHouse scho stabil funktionnéiert, da behalen Patches an Updates fir ze kucken wat fir Probleemer mir fixéieren.
Kirill Shvakov: Ech géif gären e bëssen iwwer Test Ëmfeld derbäi. Jiddereen ass ganz Angscht virun Testëmfeld an aus iergendengem Grond gleewen se datt wann Dir e ganz grousse ClickHouse-Cluster hutt, da sollt d'Testëmfeld net manner oder op d'mannst zéng Mol méi kleng sinn. Et ass guer net esou.
Ech kann Iech aus mengem eegene Beispill soen. Ech hunn e Projet, an et gëtt ClickHouse. Eis Testëmfeld ass just fir hien - dëst ass eng kleng virtuell Maschinn zu Hetzner fir zwanzeg Euro, wou absolut alles ofgesat ass. Fir dëst ze maachen, hu mir voll Automatisatioun an Ansible, an dofir, am Prinzip, mécht et keen Ënnerscheed wou goen - op Hardware Serveren oder just an virtuell Maschinnen ofsetzen.
Wat kann gemaach ginn? Et wier flott e Beispill an der ClickHouse Dokumentatioun ze bidden wéi een e klenge Cluster an Ärem eegenen Heem ofsetzt - am Docker, am LXC, vläicht en Ansible Playbook erstellen, well verschidde Leit hunn verschidden Deployementer. Dëst wäert vill vereinfachen. Wann Dir e Cluster a fënnef Minutten hëlt an ofsetzt, ass et vill méi einfach ze probéieren eppes erauszefannen. Dëst ass vill méi praktesch, well an eng Produktiounsversioun drécken déi Dir net getest hutt ass eng Strooss no néierens. Heiansdo funktionnéiert et an heiansdo net. An dofir ass d'Hoffnung op Erfolleg schlecht.
Maxim Kotyakov, Senior Backend Engineer Avito: Ech wäert e bëssen iwwer Test Ëmfeld aus enger Serie vu Problemer mat grousse Firmen konfrontéiert. Mir hunn e vollwäertege ClickHouse Akzeptanzcluster; a punkto Dateschemaen an Astellungen ass et eng exakt Kopie vun deem wat an der Produktioun ass. Dëse Stärekoup gëtt an zimlech ofgeschniddene Container mat engem Minimum u Ressourcen ofgesat. Mir schreiwen e gewësse Prozentsaz vun de Produktiounsdaten do, glécklecherweis ass et méiglech de Stream am Kafka ze replizéieren. Alles do ass synchroniséiert a skaléiert - souwuel wat d'Kapazitéit a Flux ugeet, an, an der Theorie, all aner Saache gläich, et soll sech wéi d'Produktioun a punkto Metriken behuelen. Alles potentiell explosive gëtt fir d'éischt op dëse Stand gewalzt an e puer Deeg do gelooss bis fäerdeg. Awer natierlech ass dës Léisung deier, schwéier an huet net-null Ënnerstëtzungskäschte.
Alexey Milovidov: Ech soen Iech wéi d'Testëmfeld vun eise Frënn aus Yandex.Metrica ass. Ee Stärekoup hat 600 komesch Serveren, en aneren hat 360, an et gëtt en Drëttel a verschidde Stärekéip. D'Testëmfeld fir ee vun hinnen ass einfach zwee Stécker mat zwee Repliken an all. Firwat zwee Stécker? Fir datt Dir net eleng sidd. An et sollen och Repliken ginn. Just e gewëssen Mindestbetrag deen Dir leeschte kënnt.
Dëst Testëmfeld erlaabt Iech ze kontrolléieren ob Är Ufroe funktionnéieren an ob eppes gréissers gebrach ass. Awer dacks entstinn Problemer vun enger ganz anerer Natur, wann alles funktionnéiert, awer et ginn e puer kleng Ännerungen an der Laascht.
Loosst mech Iech e Beispill ginn. Mir hunn decidéiert eng nei Versioun vum ClickHouse z'installéieren. Et gouf op engem Testëmfeld gepost, automatiséiert Tester goufen an Yandex.Metrica selwer ofgeschloss, déi Daten iwwer déi al Versioun an déi nei vergläicht, déi ganz Pipeline lafen. An natierlech gréng Tester vun eisem CI. Soss hätte mir dës Versioun net mol proposéiert.
Alles ass gutt. Mir fänken un an d'Produktioun ze plënneren. Ech kréien e Message datt d'Laascht op d'Grafiken e puer Mol eropgaang ass. Mir rullen d'Versioun zréck. Ech kucken op d'Grafik a gesinn: d'Laascht huet tatsächlech e puer Mol während der Rollout eropgaang, an ass zréck erofgaang wann se ausgerullt sinn. Dunn hu mir ugefaang d'Versioun zréckzerollen. An d'Laascht ass op déiselwecht Manéier eropgaang an ass op déiselwecht Manéier zréckgefall. Also d'Konklusioun ass dëst: d'Laascht ass eropgaang wéinst dem Layout, näischt iwwerraschend.
Duerno war et schwéier d'Kollegen ze iwwerzeegen déi nei Versioun z'installéieren. Ech soen: "Et ass an der Rei, rullt eraus. Halt d'Daumen, alles funktionnéiert. Elo ass d'Laascht op d'Grafiken eropgaang, awer alles ass gutt. Halt drun." Am Allgemengen hu mir dat gemaach, an dat ass et - d'Versioun gouf fir d'Produktioun verëffentlecht. Awer bal mat all Layout entstinn ähnlech Problemer.
Kill Query soll Ufroen ëmbréngen, awer et mécht et net. Firwat?
E Benotzer, eng Aart Analyst, ass bei mech komm an huet eng Ufro erstallt déi mäi ClickHouse Cluster gesat huet. E puer Node oder ganze Stärekoup, jee no wéi eng Replika oder Shard d'Ufro goung. Ech gesinn datt all CPU Ressourcen op dësem Server an engem Regal sinn, alles ass rout. Zur selwechter Zäit reagéiert ClickHouse selwer op Ufroen. An ech schreiwen: "Weist mir w.e.g., Prozesslëscht, wéi eng Ufro dëse Wahnsinn generéiert huet."
Ech fannen dës Ufro a schreiwen ëmbréngen. An ech gesinn, datt näischt geschitt. Mäi Server ass an engem Regal, ClickHouse gëtt mir dann e puer Kommandoen, weist datt de Server lieweg ass, an alles ass super. Awer ech hunn Degradatioun an all Benotzer Ufroen, Degradatioun fänkt mat records am ClickHouse un, a meng Kill Query funktionnéiert net. Firwat? Ech hu geduecht datt Kill Query soll Ufroen ëmbréngen, awer et mécht et net.
Elo gëtt et eng zimlech komesch Äntwert. De Punkt ass datt Kill Query net Ufroen ëmbréngt.
Kill Query kontrolléiert eng kleng Këscht mam Numm "Ech wëll datt dës Ufro ëmbruecht gëtt." An d'Ufro selwer kuckt op dëse Fändel wann Dir all Block veraarbecht. Wann et agestallt ass, stoppt d'Ufro ze schaffen. Et stellt sech eraus datt keen d'Demande ëmbréngt, hie selwer muss alles kontrolléieren an ophalen. An dëst soll an alle Fäll funktionnéieren, wou d'Ufro am Zoustand vun der Veraarbechtung vun Datenblocken ass. Et wäert den nächste Block vun Daten veraarbecht, de Fändel kontrolléieren a stoppen.
Dëst funktionnéiert net a Fäll wou d'Ufro op enger Operatioun blockéiert ass. Richteg, dat ass héchstwahrscheinlech net Äre Fall, well, laut Iech, et eng Tonne Serverressourcen benotzt. Et ass méiglech datt dëst net am Fall vun der externer Sortéierung an an e puer aner Detailer funktionnéiert. Awer am Allgemengen sollt dëst net geschéien, et ass e Feeler. An dat eenzegt wat ech recommandéieren kann ass ClickHouse ze aktualiséieren.
Wéi berechent d'Äntwertzäit ënner Lieslaascht?
Et gëtt en Dësch deen Artikelaggregate späichert - verschidde Konter. D'Zuel vun de Linnen ass ongeféier honnert Milliounen. Ass et méiglech op eng prévisibel Äntwertzäit ze zielen wann Dir 1K RPS fir 1K Artikele gitt?
Nom Kontext beurteelen, schwätze mir iwwer d'Lieslaascht, well et gi keng Probleemer mam Schreiwen - souguer dausend, souguer honnertdausend, an heiansdo e puer Millioune Reihen kënnen agefouert ginn.
Lieserfuerderunge si ganz anescht. A wielt 1, ClickHouse kann ongeféier Zéngdausende vun Ufroe pro Sekonn ausféieren, sou datt souguer Ufroe fir ee Schlëssel scho e puer Ressourcen erfuerderen. An esou Punktufroe wäerte méi schwéier sinn wéi an e puer Schlësselwäert-Datenbanken, well fir all Liesen ass et néideg e Block vun Daten no Index ze liesen. Eisen Index adresséiert net all Rekord, mee all Gamme. Dat ass, Dir musst de ganze Gamme liesen - dëst ass 8192 Linnen als Standard. An Dir musst de kompriméierte Dateblock vu 64 KB op 1 MB dekompriméieren. Typesch huelen esou geziilt Ufroen e puer Millisekonnen fir ze kompletéieren. Mä dëst ass déi einfachst Optioun.
Loosst eis eng einfach Arithmetik probéieren. Wann Dir e puer Millisekonnen mat dausend multiplizéiert, kritt Dir e puer Sekonnen. Et ass wéi wann et onméiglech ass mat dausend Ufroe pro Sekonn ze halen, awer tatsächlech ass et méiglech, well mir e puer Prozessorkären hunn. Also, am Prinzip, kann ClickHouse heiansdo 1000 RPS halen, awer fir kuerz Ufroen, speziell gezielt.
Wann Dir e ClickHouse Stärekoup mat der Unzuel vun einfachen Ufroe musse skaléieren, da recommandéieren ech déi einfachst Saach - d'Zuel vun de Repliken erhéijen an Ufroen op eng zoufälleg Replika schécken. Wann eng Replica fënnefhonnert Ufroe pro Sekonn hält, wat komplett realistesch ass, da wäerten dräi Repliken annerhallef Tausend behandelen.
Heiansdo kënnt Dir selbstverständlech ClickHouse fir déi maximal Unzuel vu Punktlesungen konfiguréieren. Wat ass dofir gebraucht? Déi éischt ass d'Granularitéit vum Index ze reduzéieren. An dësem Fall soll et net op een reduzéiert ginn, mä op der Basis datt d'Zuel vun den Entréen am Index e puer Millioune oder zéng Millioune pro Server wäert sinn. Wann den Dësch honnert Millioune Reihen huet, da kann d'Granularitéit op 64 gesat ginn.
Dir kënnt d'Gréisst vum kompriméierte Block reduzéieren. Et gi Astellunge fir dëst min Kompress Block Gréisst, maximal Kompress Block Gréisst. Si kënne reduzéiert ginn, mat Daten nei gefüllt ginn, an da wäerte geziilt Ufroe méi séier sinn. Awer ëmmer nach, ClickHouse ass keng Schlësselwäert Datebank. Eng grouss Zuel vu klenge Ufroen ass e Laaschtantimuster.
Kirill Shvakov: Ech ginn Rotschléi am Fall wou et gewéinlech Konten do sinn. Dëst ass eng zimlech Standardsituatioun wann ClickHouse eng Aart vu Konter späichert. Ech hunn e Benotzer, hien ass aus esou an esou engem Land, an e puer drëtt Feld, an ech muss eppes inkrementell erhéijen. Huelt MySQL, maacht en eenzegaartege Schlëssel - am MySQL ass et en Duplikat Schlëssel, an am PostgreSQL ass et e Konflikt - a füügt e Plus Zeechen. Dëst wäert vill besser Aarbecht.
Wann Dir net vill Daten hutt, ass et net vill Sënn fir ClickHouse ze benotzen. Et gi regelméisseg Datenbanken a si maachen dat gutt.
Wat kann ech am ClickHouse upassen fir datt méi Daten am Cache sinn?
Loosst eis eng Situatioun virstellen - d'Serveren hunn 256 GB RAM, an der deeglecher Routine hëlt ClickHouse ongeféier 60-80 GB, um Peak - bis zu 130. Wat kann aktivéiert a tweaked ginn, sou datt méi Daten am Cache sinn an deementspriechend, et gi manner Reesen op den Disk?
Typesch mécht de Säitecache vum Betribssystem eng gutt Aarbecht dovun. Wann Dir just d'Spëtzt opmaacht, kuckt do Cache oder gratis - et seet och wéi vill Cache ass - da mierkt Dir datt all déi gratis Erënnerung fir de Cache benotzt gëtt. A wann Dir dës Donnéeën liest, gëtt se net vun der Disk gelies, mee vum RAM. Zur selwechter Zäit kann ech soen datt de Cache effektiv benotzt gëtt, well et déi kompriméiert Donnéeën ass, déi cache sinn.
Wéi och ëmmer, wann Dir e puer einfach Ufroen nach méi séier wëllt beschleunegen, ass et méiglech e Cache an den dekompriméierten Donnéeën am ClickHouse z'aktivéieren. Et gëtt genannt onkompriméiert Cache. An der Config.xml Konfiguratiounsdatei setze déi onkompriméiert Cachegréisst op de Wäert deen Dir braucht - ech recommandéieren net méi wéi d'Halschent vum gratis RAM, well de Rescht ënner dem Säitecache geet.
Zousätzlech, ginn et zwou Ufro Niveau Astellunge. Éischt Astellung - benotzen onkompriméiert Cache - enthält seng Notzung. Et ass recommandéiert et fir all Ufroen z'aktivéieren, ausser schwéier déi, déi all d'Donnéeën liesen an de Cache spülen. An déi zweet Astellung ass eppes wéi déi maximal Unzuel vun Zeilen fir de Cache ze benotzen. Et limitéiert automatesch grouss Ufroen sou datt se de Cache ëmgoen.
Wéi kann ech storage_configuration fir Stockage am RAM konfiguréieren?
An der neier ClickHouse Dokumentatioun liesen ech d'Sektioun am Zesummenhang . D'Beschreiwung enthält e Beispill mat schnelle SSD.
Ech wonneren, wéi déi selwecht Saach mat Volume waarm Erënnerung konfiguréiert ginn. An nach eng Fro. Wéi funktionéiert d'Auswiel mat dëser Datenorganisatioun, liest se de ganze Set oder nëmmen deen deen op der Disk ass, a sinn dës Donnéeën an der Erënnerung kompriméiert? A wéi funktionnéiert d'Prewhere Sektioun mat esou enger Dateorganisatioun?
Dës Astellung beaflosst d'Späichere vun Datenstécker, an hiert Format ännert sech op kee Fall.
Loosst eis méi no kucken.
Dir kënnt Datenspeicher am RAM konfiguréieren. Alles wat fir den Disk konfiguréiert ass ass säi Wee. Dir erstellt eng tmpfs Partition déi op e puer Wee am Dateiesystem montéiert ass. Dir spezifizéiert dëse Wee als de Wee fir Daten fir déi wäermst Partition ze späicheren, Stécker vun Daten fänken un ze kommen an do geschriwwe ginn, alles ass gutt.
Awer ech recommandéieren dëst net ze maachen wéinst der gerénger Zouverlässegkeet, obwuel Dir op d'mannst dräi Repliken an verschiddenen Datenzenter hutt, dann ass et méiglech. Wann eppes geschitt, ginn d'Donnéeën restauréiert. Loosst eis virstellen datt de Server op eemol ausgeschalt gouf an erëm ageschalt gouf. D'Partition gouf erëm montéiert, awer et war näischt do. Wann de ClickHouse Server ufänkt, gesäit et datt et dës Stécker net huet, obwuel se no ZooKeeper Metadaten sollten do sinn. Hie kuckt op wéi eng Repliken se hunn, freet se an luet se erof. Op dës Manéier ginn d'Donnéeën restauréiert.
An dësem Sënn ass d'Späichere vun Daten am RAM net grondsätzlech anescht wéi se op der Disk ze späicheren, well wann d'Donnéeën op den Disk geschriwwe ginn, enden se och fir d'éischt am Säit-Cache a gëtt spéider kierperlech geschriwwe. Dëst hänkt vun der Opriichteoptioun vum Dateisystem of. Awer just am Fall wäert ech soen datt ClickHouse net fsynchroniséiert beim Asetzen.
An dësem Fall sinn d'Donnéeën am RAM am selwechte Format gespäichert wéi op der Disk. D'Auswiel Ufro op déiselwecht Manéier wielt d'Stécker déi gelies musse ginn, wielt déi néideg Dateberäicher an de Stécker a liest se. A prewhere Wierker genee déi selwecht, egal ob d'Donnéeën am RAM oder op Scheif waren.
Bis zu wéi enger Unzuel vun eenzegaartege Wäerter ass Low Cardinality effektiv?
Niddereg Kardinalitéit ass clever entworf. Et kompiléiert Datendictionnairen, awer si sinn lokal. Als éischt ginn et verschidden Dictionnairen fir all Stéck, an zweetens, souguer an engem Stéck kënne se fir all Gamme anescht sinn. Wann d'Zuel vun eenzegaartege Wäerter eng Schwellzuel erreecht - eng Millioun, mengen ech - gëtt d'Wörterbuch einfach ofgeschaaft an en neit erstallt.
D'Äntwert ass allgemeng: fir all lokal Gamme - soen, fir all Dag - iergendwou bis zu enger Millioun eenzegaarteg Wäerter Low Kardinalitéit ass effektiv. Duerno gëtt et einfach e Réckfall, an deem vill verschidde Dictionnairen agesat ginn, an net nëmmen een. Et funktionnéiert ongeféier d'selwecht wéi eng regulär String Kolonn, vläicht e bësse manner effizient, awer et gëtt keng sérieux Leeschtungsverschlechterung.
Wat sinn déi bescht Praktiken fir Volltext Sich no engem Dësch mat fënnef Milliarde Reihen?
Et gi verschidden Äntwerten. Déi éischt ass ze soen datt ClickHouse keng Volltext Sichmotor ass. Et gi speziell Systemer dofir, z.B. и . Wéi och ëmmer, ech gesinn ëmmer méi Leit soen datt se vun Elasticsearch op ClickHouse wiesselen.
Firwat geschitt dat? Si erklären dëst duerch d'Tatsaach datt Elasticsearch ophält mat der Laascht op e puer Bänn ze këmmeren, ugefaange mat der Konstruktioun vun Indexen. Indexen ginn ze ëmständlech, a wann Dir einfach d'Donnéeën op ClickHouse transferéiert, stellt sech eraus datt se e puer Mol méi effizient a Volumen gespäichert ginn. Zur selwechter Zäit waren d'Sichsufroen dacks net sou datt et néideg war e puer Saz am ganzen Datevolumen ze fannen, mat der Morphologie berücksichtegt, awer ganz aner. Zum Beispill, fannt Dir e puer Nofolger vu Bytes an de Logbicher an de leschte Stonnen.
An dësem Fall erstellt Dir en Index am ClickHouse, dat éischt Feld vun deem den Datum an d'Zäit ass. An de gréissten Dateofschnëtt wäert op der Datumbereich baséieren. Am ausgewielten Datumbereich ass et als Regel scho méiglech eng Volltext Sich auszeféieren, och mat der Brute Force Method mat wéi. De ähnleche Bedreiwer am ClickHouse ass deen effizientesten wéi Bedreiwer deen Dir fannt. Wann Dir eppes Besseres fannt, sot mir.
Awer nach ëmmer, wéi ass e komplette Scan. A voll Scan kann lues sinn net nëmmen op der CPU, awer och op der Scheif. Wann Dir op eemol een Terabyte vun Daten pro Dag hutt, an Dir sicht während dem Dag no engem Wuert, da musst Dir den Terabyte scannen. An et ass méiglecherweis op normale Festplazen, a schlussendlech ginn se sou gelueden datt Dir net fäeg ass op dëse Server iwwer SSH ze kommen.
An dësem Fall sinn ech prett fir e méi klengen Trick ze bidden. Et ass experimentell - et kéint funktionnéieren, et kéint net. ClickHouse huet Volltext Indexen a Form vun Trigram Bloom Filteren. Eis Kollegen vun Arenadata hunn dës Indexer scho probéiert, a si funktionnéieren dacks genau wéi virgesinn.
Fir se richteg ze benotzen, sollt Dir e gutt Verständnis hunn wéi se funktionnéieren: wat en Trigram Bloom Filter ass a wéi Dir seng Gréisst wielt. Ech kann soen datt se hëllefe fir Ufroen op e puer selten Ausdréck, Substrings déi selten an den Donnéeën fonnt ginn. An dësem Fall ginn Ënnerberäicher duerch Indizes ausgewielt a manner Daten ginn gelies.
Viru kuerzem huet ClickHouse nach méi fortgeschratt Funktiounen fir Volltext Sich bäigefüügt. Dëst ass, éischtens, eng Sich no enger Rëtsch Substrings gläichzäiteg an engem Pass, inklusiv Optiounen déi case-sensibel sinn, case-onsensitiv, mat Ënnerstëtzung fir UTF-8 oder nëmme fir ASCII. Wielt déi effektivsten déi Dir braucht.
Sich no multiple reguläre Ausdréck an engem Pass ass och opgetaucht. Dir musst X net wéi eng Ënnerstring oder X wéi eng aner Ënnerstring schreiwen. Dir schreift direkt, an alles gëtt sou effizient wéi méiglech gemaach.
Drëttens gëtt et elo eng geschätzte Sich no Regexps an eng geschätzte Sich no Substrings. Wann iergendeen e Wuert falsch geschriwwen huet, gëtt et fir de maximale Match gesicht.
Wat ass de beschte Wee fir Zougang zu ClickHouse fir eng grouss Zuel vu Benotzer ze organiséieren?
Sot eis wéi Dir am Beschten Zougang fir eng grouss Zuel vu Konsumenten an Analysten organiséiert. Wéi bilden ech eng Schlaang, prioritär maximal concurrent Ufroen, a mat wéi engem Tools?
Wann de Cluster grouss genuch ass, da wier eng gutt Léisung zwee méi Serveren z'erhéijen, déi en Entrée fir Analysten ginn. Dat ass, erlaben net Analysten Zougang zu spezifesch shards am Stärekoup, mä einfach zwee eidel Serveren schafen, ouni Donnéeën, an Accès Rechter op hinnen konfiguréieren. An dësem Fall ginn d'Benotzer Astellunge fir verdeelt Ufroe op Fernserver transferéiert. Dat ass, Dir konfiguréiert alles op dësen zwee Serveren, an d'Astellungen hunn en Effekt op de ganze Stärekoup.
Am Prinzip hunn dës Serveren keng Donnéeën, awer d'Quantitéit vum RAM op hinnen ass ganz wichteg fir Ufroen auszeféieren. D'Disk kann och fir temporär Daten benotzt ginn wann extern Aggregatioun oder extern Sortéierung aktivéiert ass.
Et ass wichteg d'Astellungen ze kucken, déi mat all méigleche Limiten verbonne sinn. Wann ech elo als Analyst an de Yandex.Metrica Cluster goen an eng Demande froen wielt Grof vun Hits, da kréien ech direkt eng Ausnam, datt ech d'Ufro net kann ausféieren. Déi maximal Unzuel vun Zeilen, déi ech erlaabt ze scannen ass honnert Milliarden, an am Ganzen sinn et fofzeg Billioune vun hinnen an enger Tabell am Stärekoup. Dëst ass déi éischt Limitatioun.
Loosst eis soen datt ech d'Zeillimit ewechhuelen an d'Ufro nach eng Kéier lafen. Da wäert ech déi folgend Ausnam gesinn - Astellung aktivéiert Kraaft Index vum Datum. Ech kann d'Ufro net fäerdeg maachen wann ech keng Datumbereich uginn hunn. Dir musst net op Analysten vertrauen fir et manuell ze spezifizéieren. En typesche Fall ass wann en Datumbereich geschriwwe gëtt wou Eventdatum tëscht Woch. An dann hunn se einfach eng Klammer op der falscher Plaz uginn, an amplaz an et huet sech erausgestallt oder - oder URL Match. Wann et keng Limit gëtt, kräizt et d'URL Kolonn a verschwendt just eng Tonne Ressourcen.
Zousätzlech, ClickHouse huet zwee Prioritéit Astellunge. Leider si se ganz primitiv. Een gëtt einfach genannt Prioritéit. Wann Prioritéit ≠ 0, an Ufroe mat enger Prioritéit ausgefouert ginn, awer eng Ufro mat engem Prioritéitswäert vu manner wéi, dat heescht eng méi héich Prioritéit, gëtt ausgefouert, dann eng Ufro mat engem Prioritéitswäert vu méi grouss, dat heescht eng méi niddereg Prioritéit , ass einfach suspendéiert a wäert während dëser Zäit guer net schaffen.
Dëst ass e ganz ruppeg Kader an ass net gëeegent fir Fäll wou de Cluster eng konstant Belaaschtung huet. Awer wann Dir kuerz, bursty Ufroen hutt déi wichteg sinn, an de Stärekoup ass meeschtens Idle, ass dëse Setup gëeegent.
Déi nächst Prioritéit Astellung genannt OS thread Prioritéit. Et setzt einfach de schéine Wäert fir all Ufro Ausféierung Threads fir de Linux Scheduler. Et funktionnéiert sou-sou, awer et funktionnéiert nach ëmmer. Wann Dir de Minimum schéine Wäert setzt - et ass dee gréissten am Wäert, an dofir déi niddregst Prioritéit - a setzt -19 fir Ufroe mat héijer Prioritéit, da verbraucht d'CPU niddereg-Prioritéit Ufroen ongeféier véier Mol manner wéi héich Prioritéit.
Dir musst och déi maximal Ufro Ausféierung Zäit konfiguréieren - sot fënnef Minutten. Déi minimal Geschwindegkeet vun der Ausféierung vun Ufroen ass déi coolst Saach. Dës Astellung ass scho laang ronderëm, an et ass erfuerderlech net nëmmen ze behaapten datt ClickHouse net verlangsamt, awer et ze zwéngen.
Stellt Iech vir, Dir ageriicht: wann e puer Ufroën manner wéi eng Millioun Reihen pro Sekonn veraarbecht, kënnt Dir dat net maachen. Dëst schued eise gudden Numm, eis gutt Datebank. Loosst eis dat einfach verbidden. Et ginn eigentlech zwou Astellungen. Ee gëtt genannt min Ausféierungsgeschwindegkeet - a Linnen pro Sekonn, an déi zweet gëtt Timeout genannt ier Dir min Ausféierungsgeschwindegkeet iwwerpréift - fofzéng Sekonnen als Standard. Dat ass, fofzéng Sekonnen ass méiglech, an dann, wann et lues ass, da just eng Ausnam geheien an d'Demande ofbriechen.
Dir musst och Quoten opstellen. ClickHouse huet eng agebaute Quote Feature déi Ressourceverbrauch zielt. Awer, leider, net Hardware Ressourcen wéi CPU, Disken, awer logesch - d'Zuel vun de veraarbechten Ufroen, Linnen a Bytes gelies. An Dir kënnt zum Beispill maximal honnert Ufroe bannent fënnef Minutten an dausend Demanden pro Stonn konfiguréieren.
Firwat ass et wichteg? Well e puer analytesch Ufroe manuell direkt vum ClickHouse Client ausgefouert ginn. An alles wäert gutt sinn. Awer wann Dir fortgeschratt Analysten an Ärer Firma hutt, schreiwen se e Skript, an et kann e Feeler am Skript sinn. An dëse Feeler verursaacht datt d'Ufro an enger onendlecher Loop ausgefouert gëtt. Dëst ass wat mir eis musse schützen.
Ass et méiglech d'Resultater vun enger Ufro un zéng Clienten ze ginn?
Mir hunn e puer Benotzer déi gär mat ganz groussen Ufroe gläichzäiteg erakommen. D'Ufro ass grouss an am Prinzip séier ausgefouert, awer wéinst der Tatsaach, datt et vill esou Ufroe gläichzäiteg gëtt, gëtt et ganz ustrengend. Ass et méiglech déi selwecht Ufro auszeféieren, déi zéng Mol hannereneen, eemol ukomm ass, an d'Resultat un zéng Clienten ginn?
De Problem ass datt mir d'Resultater vum Cache oder Cache vun Zwëschendaten net hunn. Et gëtt e Säitcache vum Betribssystem, deen Iech verhënnert datt Dir Daten vun der Disk erëm liest, awer leider ginn d'Donnéeën nach ëmmer dekompriméiert, deserialiséiert a veraarbecht.
Ech wéilt dëst iergendwéi vermeiden, entweder duerch Cache vun Zwëschendaten, oder andeems Dir ähnlech Ufroen an enger Aart Schlaang opstellt an e Resultatcache bäidréit. Mir hunn de Moment eng Pull-Ufro an der Entwécklung, déi en Ufro-Cache bäidréit, awer nëmme fir Ënnerufroen an den In- a Joint-Sektiounen - dat ass, d'Léisung ass onkomplett.
Mir sinn awer och mat esou enger Situatioun konfrontéiert. E besonnesch kanonescht Beispill ass paginéiert Ufroen. Et gëtt e Rapport, et huet e puer Säiten, an et gëtt eng Demande fir Limite 10. Dann déi selwecht Saach, mee Limite 10,10. Dann eng aner nächst Säit. An d'Fro ass, firwat ziele mir all dat all Kéier? Awer elo gëtt et keng Léisung, an et gëtt kee Wee et ze vermeiden.
Et gëtt eng alternativ Léisung déi als Sidecar nieft ClickHouse plazéiert ass - .
Kirill Shvakov: ClickHouse Proxy huet en agebauten Tauxlimiter an en agebaute Resultatcache. Vill Astellunge goufen do gemaach well en ähnleche Problem geléist gouf. Proxy erlaabt Iech Ufroen ze limitéieren andeems se se an der Schlaang setzen a konfiguréieren wéi laang den Ufro-Cache lieft. Wann d'Ufroe wierklech d'selwecht waren, wäert Proxy se vill Mol schécken, awer nëmmen eemol op ClickHouse goen.
Nginx huet och e Cache an der gratis Versioun, an dëst wäert och funktionnéieren. Nginx huet souguer Astellungen datt wann Ufroe zur selwechter Zäit ukommen, et anerer verlangsamen bis een fäerdeg ass. Awer et ass am ClickHouse Proxy datt de Setup vill besser gemaach gëtt. Et gouf speziell fir ClickHouse gemaach, speziell fir dës Ufroen, also ass et méi gëeegent. Gutt, et ass einfach ze installéieren.
Wat iwwer asynchron Operatiounen a materialiséierte Meenungen?
Et gëtt e Problem datt d'Operatiounen mam Replaymotor asynchron sinn - als éischt ginn d'Donnéeën geschriwwe, da klappt se zesummen. Wann e materialiséierte Tablet mat e puer Aggregaten ënner dem Schëld lieft, da ginn Duplikaten op et geschriwwe ginn. A wann et keng komplex Logik ass, da ginn d'Donnéeën duplizéiert. Wat kënnt Dir doriwwer maachen?
Et gëtt eng offensichtlech Léisung - en Ausléiser op enger bestëmmter Klass vu Matviews während enger asynchroner Zesummebroch Operatioun ëmzesetzen. Ginn et Sëlwer Kugelen oder Pläng fir ähnlech Funktionalitéit ëmzesetzen?
Et ass derwäert ze verstoen wéi Deduplikatioun funktionnéiert. Wat ech Iech elo soen ass net relevant fir d'Fro, awer just am Fall wou et derwäert ass ze erënneren.
Wann Dir an eng replizéiert Tabelle setzt, gëtt et Deduplikatioun vun de ganze agebaute Blocken. Wann Dir dee selwechte Block mat der selwechter Zuel vun de selwechte Reihen an der selwechter Uerdnung nei asetzt, da ginn d'Donnéeën deduplizéiert. Dir kritt "Ok" als Äntwert op d'Insert, awer tatsächlech gëtt e Paket vun Daten geschriwwe, an et gëtt net duplizéiert.
Dëst ass néideg fir Sécherheet. Wann Dir "Ok" wärend der Aféierung kritt, da sinn Är Donnéeën agefouert ginn. Wann Dir e Feeler vu ClickHouse kritt, heescht et datt se net agefouert goufen an Dir musst d'Insertioun widderhuelen. Awer wann d'Verbindung während der Aféierung gebrach ass, da wësst Dir net ob d'Donnéeën agefouert goufen oder net. Déi eenzeg Optioun ass d'Insertioun erëm ze widderhuelen. Wann d'Donnéeën tatsächlech agefouert goufen an Dir se nei agefouert hutt, gëtt et Blockdeduplikatioun. Dëst ass néideg fir Duplikate ze vermeiden.
An et ass och wichteg wéi et funktionnéiert fir materialiséiert Meenungen. Wann d'Donnéeën deduplizéiert goufen wann se an d'Haapttabell agefouert goufen, da ginn se och net an déi materialiséierter Vue.
Elo iwwer d'Fro. Är Situatioun ass méi komplizéiert well Dir Duplikate vun eenzelne Linnen ophëlt. Dat ass, et ass net de ganze Pak deen duplizéiert ass, awer spezifesch Linnen, a si zerbriechen am Hannergrond. Tatsächlech wäerten d'Donnéeën an der Haapttabell zesummeklappen, awer déi net zesummegeklappt Daten ginn an d'materialiséierter Vue, a wärend der Fusioun geschitt näischt mat de materialiséierte Usiichten. Well eng materialiséiert Vue ass näischt méi wéi en Insert Ausléiser. Während aner Operatiounen geschitt näischt zousätzlech.
An ech kann Iech hei net glécklech maachen. Dir musst just no enger spezifescher Léisung fir dëse Fall sichen. Zum Beispill ass et méiglech et an enger materialiséierter Vue ze widderhuelen, an d'Deduplikatiounsmethod kéint déiselwecht Manéier funktionnéieren. Mee leider net ëmmer. Wann et aggregéiert ass, funktionnéiert et net.
Kirill Shvakov: Mir haten och Crèche Bau zréck am Dag. Et war e Problem, datt et Reklammen Impressiounen ginn, an et sinn e puer Donnéeën, datt mir an Echtzäit weisen kann - dat si just Impressiounen. Si ginn selten duplizéiert, awer wann dat geschitt, wäerte mir se souwisou méi spéit zesummeklappen. An et waren Saachen déi net duplizéiert kënne ginn - Klick an déi ganz Geschicht. Mee ech wollt se och bal direkt weisen.
Wéi goufen déi materialiséiert Meenungen gemaach? Et waren Meenungen wou et direkt geschriwwe gouf - et gouf op rau Donnéeën geschriwwe, a geschriwwe fir Meenungen. Do sinn iergendwann d'Donnéeën net ganz korrekt, se ginn duplizéiert, asw. An et gëtt en zweeten Deel vum Dësch, wou se genee d'selwecht ausgesinn wéi materialiséierter Meenung, dat heescht, si sinn absolut identesch a Struktur. Heiansdo berechnen mir d'Donnéeën nei, zielen d'Donnéeën ouni Duplikaten, schreiwen op dës Dëscher.
Mir sinn duerch d'API gaang - dëst funktionnéiert net am ClickHouse manuell. An der API kuckt: wann ech den Datum vun der leschter Zousaz op den Dësch hunn, wou et garantéiert ass, datt déi richteg Donnéeën schonn berechent ginn, an et mécht eng Demande un een Dësch an engem aneren Dësch. Vun engem wielt d'Ufro bis zu enger gewëssen Zäit, a vun der anerer kritt se dat wat nach net berechent gouf. An et funktionnéiert, awer net duerch ClickHouse eleng.
Wann Dir eng Aart API hutt - fir Analysten, fir Benotzer - dann ass dëst am Prinzip eng Optioun. Dir zielt ëmmer, ëmmer zielt. Dëst kann eemol am Dag oder zu enger anerer Zäit gemaach ginn. Dir wielt fir Iech selwer eng Rei déi Dir net braucht an net kritesch ass.
ClickHouse huet vill Logbicher. Wéi kann ech alles gesinn, datt op de Server op ee Bléck geschitt?
ClickHouse huet eng ganz grouss Zuel vu verschiddene Logbicher, an dës Zuel geet erop. An neie Versioune sinn e puer vun hinnen souguer als Standard aktivéiert; an eelere Versioune musse se beim Update aktivéiert ginn. Allerdéngs ginn et ëmmer méi vun hinnen. Schlussendlech géif ech gär gesinn wat elo mat mengem Server geschitt, vläicht op enger Aart vu Resumé-Dashboard.
Hutt Dir e ClickHouse Team, oder Teams vun Äre Frënn, déi e puer Funktionalitéit vu fäerdege Dashboards ënnerstëtzen, déi dës Logbicher als fäerdeg Produkt weisen? Schlussendlech, just no Logbicher am ClickHouse ze kucken ass super. Awer et wier ganz cool wann et scho a Form vun engem Dashboard virbereet wier. Ech géif e Kick aus dëser kréien.
Et gi Dashboards, obwuel se net standardiséiert sinn. An eiser Firma benotzen ongeféier 60 Teams ClickHouse, an déi komeschst Saach ass datt vill vun hinnen Dashboards hunn déi se fir sech selwer gemaach hunn, a liicht anescht. E puer Teams benotzen eng intern Yandex.Cloud Installatioun. Et ginn e puer fäerdeg Rapporten, obwuel net all déi néideg. Anerer hunn hir eege.
Meng Kollegen aus Metrica hunn hiren eegene Dashboard zu Grafana, an ech hunn meng eegen fir hire Cluster. Ech kucken op Saachen wéi Cache Hit fir de Serif Cache. An nach méi schwéier ass datt mir verschidden Tools benotzen. Ech hunn mäi Dashboard erstallt mat engem ganz alen Tool mam Numm Graphite-Web. Hien ass komplett ellen. An ech benotzen et nach ëmmer esou, obwuel Grafana wahrscheinlech méi bequem a schéin wier.
Déi Basis Saach an Dashboards ass d'selwecht. Dëst sinn Systemmetriken fir de Stärekoup: CPU, Erënnerung, Disk, Netzwierk. Aner - Zuel vu simultan Ufroen, Zuel vu simultan Fusioune, Unzuel vun Ufroen pro Sekonn, maximal Unzuel vu Stécker fir MergeTree Dëschpartitionen, Replikatiounslag, Replikatiounsschlaanggréisst, Zuel vun agebaute Reihen pro Sekonn, Zuel vun agebaute Blocken pro Sekonn. Dëst ass alles wat net aus Logbicher kritt gëtt, mee vu Metriken.
Vladimir Kolobaev: Alexey, ech wéilt et e bësse korrigéieren. Do ass Grafana. Grafana huet eng Datenquell, dat ass ClickHouse. Dat ass, ech kann Ufroe vu Grafana direkt un ClickHouse maachen. ClickHouse huet en Dësch mat Logbicher, et ass d'selwecht fir jiddereen. Als Resultat wëll ech Zougang zu dësem Logtabel zu Grafana kréien an d'Ufroe gesinn, déi mäi Server mécht. Et wier super fir esou en Dashboard ze hunn.
Ech hunn et selwer mam Vëlo gefuer. Awer ech hunn eng Fro - wann et alles standardiséiert ass, a Grafana gëtt vu jidderee benotzt, firwat huet Yandex net sou en offiziellen Dashboard?
Kirill Shvakov: Tatsächlech ënnerstëtzt d'Datequell déi op ClickHouse geet elo Altinity. An ech wëll just e Vecteure ginn vu wou ze graven a wien ze drécken. Dir kënnt se froen, well Yandex mécht ëmmer ClickHouse, an net d'Geschicht ronderëm. Altinity ass d'Haaptfirma déi de Moment ClickHouse fördert. Si wäerten hien net opginn, awer ënnerstëtzen hien. Well, am Prinzip, fir en Dashboard op d'Grafana Websäit eropzelueden, musst Dir nëmmen registréieren an eroplueden - et gi keng speziell Probleemer.
Alexey Milovidov: Am leschte Joer huet ClickHouse vill Ufroprofiléierungsfäegkeeten bäigefüügt. Et gi Metriken fir all Ufro iwwer Ressourceverbrauch. A viru kuerzem hu mir en nach méi nidderegen Niveau Query Profiler bäigefüügt fir ze kucken wou eng Ufro all Millisekonnen verbréngt. Awer fir dës Funktionalitéit ze benotzen, muss ech de Konsol Client opmaachen an eng Ufro tippen, déi ech ëmmer vergiessen. Ech hunn et iergendwou gespäichert a vergiessen ëmmer wou genau.
Ech wënschen et wier en Tool dat just gesot huet, hei sinn Är schwéier Ufroen, gruppéiert no Ufroklass. Ech gedréckt op engem, a si géifen mir soen, datt et dofir schwéier ass. Et gëtt elo keng esou Léisung. An et ass wierklech ganz komesch, datt wann d'Leit mech froen: "Sot mir, ginn et fäerdeg Dashboards fir Grafana?", Ech soen: "Gitt op d'Websäit vun Grafana, et gëtt eng "Dashboards" Gemeinschaft, an et gëtt en Dashboard aus Dimka, et gëtt en Dashboard aus Kostyan. Ech weess net wat et ass, ech hunn et selwer net benotzt.
Wéi Afloss Fusioun sou datt de Server net an OOM Crash?
Ech hunn en Dësch, et gëtt nëmmen eng Partition an der Tabell, et ass ErsatzMergeTree. Ech schreiwen daten an et fir véier Joer. Ech hu missen eng Ännerung dran maachen an e puer Donnéeën läschen.
Ech hunn dat gemaach, a während der Veraarbechtung vun dëser Ufro gouf all d'Erënnerung op all Serveren am Stärekoup verbraucht, an all d'Serveren am Stärekoup gaangen an OOM. Dunn sinn se all zesummen opgestan, ugefaang dës selwecht Operatioun ze fusionéieren, dësen Dateblock, a sinn erëm an OOM gefall. Dunn sinn se erëm opgestan an erëm gefall. An dës Saach huet net opgehalen.
Dunn huet sech erausgestallt datt dëst tatsächlech e Feeler war deen d'Jongen fixéiert hunn. Dëst ass ganz cool, villmools Merci. Awer e Rescht ass bliwwen. An elo, wann ech drun denken, eng Zort Fusioun an der Tabell ze maachen, hunn ech eng Fro - firwat kann ech dës Fusioun net iergendwéi beaflossen? Zum Beispill limitéieren se duerch d'Quantitéit vum RAM erfuerderlech, oder, am Prinzip, duerch de Betrag deen dës speziell Dësch veraarbecht.
Ech hunn en Dësch mam Numm "Metrics", veraarbecht et w.e.g. fir mech an zwee Threads. Et ass net néideg zéng oder fënnef Fusioun parallel ze kreéieren, maacht et an zwee. Ech mengen datt ech genuch Erënnerung fir zwee hunn, awer et ass vläicht net genuch fir zéng ze veraarbecht. Firwat bleift Angscht? Well den Dësch wiisst, an ech wäert iergendwann mat enger Situatioun konfrontéieren, déi am Prinzip net méi un engem Käfer ass, mee well d'Daten sou vill änneren, datt ech einfach net genuch Erënnerung op der Server. An dann de Server Crash an OOM wann Fusioun. Ausserdeem kann ech d'Mutatioun annuléieren, awer de Merji ass net méi do.
Dir wësst, wann Dir fusionéiert, wäert de Server net an OOM falen, well beim Fusioun gëtt d'Quantitéit vum RAM nëmme fir eng kleng Palette vun Daten benotzt. Also alles wäert gutt sinn onofhängeg vun der Quantitéit un Daten.
Vladimir Kolobaev: Gutt. Hei ass de Moment esou datt nodeems de Feeler fixéiert gouf, hunn ech eng nei Versioun fir mech erofgelueden, an op engem aneren Dësch, e méi klengen, wou et vill Partitionen sinn, hunn ech eng ähnlech Operatioun gemaach. A während der Fusioun gouf ongeféier 100 GB RAM um Server verbrannt. Ech hat 150 besat, 100 giess, an eng 50 GB Fënster lénks, also ech gefall net an OOM.
Wat schützt mech am Moment fir an OOM ze falen wann et tatsächlech 100 GB RAM verbraucht? Wat maache wann op eemol de RAM op der Fusioun leeft?
Alexey Milovidov: Et gëtt esou e Problem, datt de Konsum vun RAM speziell fir Fusioun net limitéiert ass. An den zweete Problem ass datt wann eng Zort Fusioun zougewisen ass, da muss se ausgefouert ginn well et am Replikatiounsprotokoll opgeholl gëtt. De Replikatiounslog ass d'Aktiounen déi néideg sinn fir d'Replika an e konsequente Staat ze bréngen. Wann Dir keng manuell Manipulatioune maacht, déi dëse Replikatiounsprotokoll zréckrollen, muss d'Fusioun op déi eng oder aner Manéier gemaach ginn.
Natierlech wier et net iwwerflësseg eng RAM Begrenzung ze hunn déi "just am Fall" géint OOM schützt. Et wäert d'Fusioun net hëllefen ze kompletéieren, et wäert erëm ufänken, e puer Schwell erreechen, eng Ausnahm werfen, an dann erëm ufänken - näischt Gutt wäert aus dësem kommen. Mä am Prinzip wier et nëtzlech dës Restriktioun anzeféieren.
Wéi gëtt de Golang Driver fir ClickHouse entwéckelt?
De Golang Chauffer, dee vum Kirill Shvakov geschriwwe gouf, gëtt elo offiziell vum ClickHouse Team ënnerstëtzt. Hien , hien ass elo grouss an real.
Eng kleng Notiz. Et gëtt eng wonnerbar a beléifte Repository vun normale Forme vun onendlecher Uerdnung - dëst ass Vertica. Si hunn och hiren eegene offiziellen Python-Treiber, dee vun den Vertica Entwéckler ënnerstëtzt gëtt. An e puer Mol ass et geschitt datt d'Späicherversioune an d'Treiberversioune ganz dramatesch divergéiert hunn, an de Chauffer iergendwann opgehalen ze schaffen. An den zweete Punkt. Ënnerstëtzung fir dësen offiziellen Chauffer, et schéngt mir, gëtt vum "Nipple" System duerchgefouert - Dir schreift hinnen en Thema, an et hänkt fir ëmmer.
Ech hunn zwou Froen. Elo ass de Kirill Golang Chauffer bal de Standard Wee fir vu Golang mat ClickHouse ze kommunizéieren. Ausser wann een nach iwwer den http Interface kommunizéiert well hien et esou gär huet. Wéi geet d'Entwécklung vun dësem Chauffer weider? Gëtt et mat all briechen Ännerungen am Repository selwer synchroniséiert? A wat ass d'Prozedur fir en Thema ze berücksichtegen?
Kirill Shvakov: Déi éischt ass wéi alles bürokratesch organiséiert ass. Dëse Punkt gouf net diskutéiert, also hunn ech näischt ze äntweren.
Fir d'Fro iwwer d'Thema ze beäntweren, brauche mir eng kleng Geschicht vum Chauffer. Ech hunn fir eng Firma geschafft déi vill Daten hat. Et war e Werbespinner mat enger riesecher Unzuel vun Eventer déi iergendwou musse gespäichert ginn. An iergendwann erschéngt ClickHouse. Mir hunn et mat Daten gefüllt, an am Ufank war alles gutt, awer dunn ass ClickHouse erofgefall. Dee Moment hu mir décidéiert datt mir et net brauchen.
E Joer méi spéit si mir zréck op d'Iddi fir ClickHouse ze benotzen, a mir hu missen do iergendwéi Daten schreiwen. Den Aféierungsbericht war dëst: d'Hardware ass ganz schwaach, et gi wéineg Ressourcen. Mä mir hunn ëmmer esou geschafft, an dofir hu mir op de gebiertege Protokoll gekuckt.
Well mir am Go geschafft hunn, war et kloer datt mir e Go Chauffer gebraucht hunn. Ech hunn et bal Vollzäit gemaach - et war meng Aarbechtsaufgab. Mir hunn et op e bestëmmte Punkt bruecht, a prinzipiell huet keen ugeholl datt een anere wéi mir et géif notzen. Duerno koum CloudFlare mat genee dee selwechte Problem, a mir hunn eng Zäit laang mat hinnen geschafft, well se déiselwecht Aufgaben haten. Ausserdeem hu mir dat souwuel am ClickHouse selwer gemaach wéi och am Chauffer.
Iergendwann hunn ech et einfach opgehalen, well meng Aktivitéit a Punkto ClickHouse an Aarbecht e bësse geännert huet. Dofir sinn Themen net zougemaach. Periodesch verpflichte Leit déi selwer eppes brauchen fir de Repository. Da kucken ech op d'Pull-Ufro an heiansdo änneren ech souguer eppes selwer, awer dat geschitt seelen.
Ech wëll zréck op de Chauffer. Virun e puer Joer, wéi dës ganz Saach ugefaang huet, war ClickHouse och anescht a mat verschiddene Fäegkeeten. Elo hu mir e Verständnis wéi een de Chauffer nei mécht fir datt et gutt funktionnéiert. Wann dat passéiert, da wäert d'Versioun 2 op jidde Fall inkompatibel sinn wéinst de cumuléierten Krutchen.
Ech weess net wéi ech dës Matière organiséieren. Ech hu selwer net vill Zäit. Wann e puer Leit de Chauffeur fäerdeg maachen, kann ech hinnen hëllefen an hinnen soen wat ze maachen. Awer déi aktiv Participatioun vu Yandex an der Entwécklung vum Projet ass nach net diskutéiert ginn.
Alexey Milovidov: Tatsächlech gëtt et nach keng Bürokratie iwwer dës Chauffeuren. Déi eenzeg Saach ass datt se un eng offiziell Organisatioun presentéiert ginn, dat heescht, dëse Chauffer gëtt als offiziell Standardléisung fir Go unerkannt. Et ginn e puer aner Chauffeuren, mä si kommen separat.
Mir hu keng intern Entwécklung fir dës Chauffeuren. D'Fro ass, ob mir eng eenzel Persoun kënnen astellen, net fir dee bestëmmte Chauffeur, mä fir d'Entwécklung vun alle Gemengefuerer, oder kënne mir een vu baussen fannen.
Den externen Wierderbuch lued net no engem Neistart mat der Lazy_load-Astellung aktivéiert. Wat kann een maachen?
Mir hunn d'lazy_load-Astellung aktivéiert, an nodeems de Server nei gestart ass, lued de Wierderbuch net eleng. Et gëtt eréischt erhéicht nodeems de Benotzer dëst Wierderbuch zougräift. An déi éischte Kéier ech Zougang et, gëtt et e Feeler. Ass et méiglech iergendwéi automatesch Dictionnairen mat ClickHouse ze lueden, oder musst Dir ëmmer selwer hir Bereetschaft kontrolléieren fir datt d'Benotzer keng Feeler kréien?
Vläicht hu mir eng al Versioun vum ClickHouse, sou datt d'Wörterbuch net automatesch lued. Konnt dat de Fall sinn?
Als éischt kënnen Dictionnairen gezwongen geluede ginn mat enger Ufro System Reload Dictionnairen. Zweetens, wat de Feeler ugeet - wann d'Wörterbuch scho gelueden ass, da funktionnéieren d'Ufroen op Basis vun den Daten déi geluede goufen. Wann d'Wörterbuch nach net gelueden ass, gëtt et direkt während der Ufro gelueden.
Dëst ass net ganz bequem fir schwéier Dictionnairen. Zum Beispill musst Dir eng Millioun Reihen aus MySQL zéien. Een mécht en einfache Choix, awer dës Auswiel wäert op déiselwecht Millioun Reihen waarden. Et ginn zwou Léisungen hei. Déi éischt ass fir lazy_load auszeschalten. Zweetens, wann de Server op ass, ier Dir d'Laascht drop setzt, maacht System Reload Wierderbuch oder maacht just eng Ufro déi e Wierderbuch benotzt. Da gëtt d'Wörterbuch gelueden. Dir musst d'Disponibilitéit vun Dictionnairen kontrolléieren mat der Lazy_load-Astellung aktivéiert, well ClickHouse se net automatesch lued.
D'Äntwert op déi lescht Fro ass entweder d'Versioun ass al oder et muss debugged ginn.
Wat maache mat der Tatsaach, datt d'Dictionnaire vum System nei lued keng vun de ville Dictionnairen lued, wann op d'mannst ee vun hinnen mat engem Feeler ofbriechen?
Et gëtt eng aner Fro iwwer System Reload Dictionnairen. Mir hunn zwee Dictionnairen - een ass net gelueden, dat zweet ass gelueden. An dësem Fall lued System Reload Dictionnairen kee Wierderbuch, an Dir musst Punkt-fir-Punkt e spezifesche mat sengem Numm lueden andeems Dir System Reload Wierderbuch benotzt. Ass dëst och mat der ClickHouse Versioun verbonnen?
Ech wëll Iech glécklech maachen. Dëst Verhalen huet geännert. Dëst bedeit datt wann Dir ClickHouse aktualiséiert, et wäert och änneren. Wann Dir net zefridden sidd mat Ärem aktuelle Verhalen System Reload Dictionnairen, Update, a loosst eis hoffen datt et sech zum bessere ännert.
Gëtt et e Wee fir Detailer an der ClickHouse Configuratioun ze konfiguréieren, awer net am Fall vu Feeler ze weisen?
Déi nächst Fro ass iwwer Feeler am Zesummenhang mam Wierderbuch, nämlech Detailer. Mir hunn d'Verbindungsdetailer an der ClickHouse Config fir d'Wörterbuch spezifizéiert, a wann et e Feeler ass, kréie mir dës Detailer a Passwuert als Äntwert.
Mir hunn dëse Feeler geléist andeems Dir Detailer an d'ODBC Treiberkonfiguratioun bäigefüügt. Gëtt et e Wee fir d'Detailer an der ClickHouse Configuratioun ze konfiguréieren, awer dës Detailer net am Fall vu Feeler ze weisen?
Déi richteg Léisung hei ass dës Umeldungsinformatiounen an odbc.ini ze spezifizéieren, an am ClickHouse selwer spezifizéieren nëmmen den ODBC Datequell Numm. Dëst geschitt net fir aner Wierderbuchquellen - weder fir d'Wörterbuch mat MySQL, nach fir déi aner, Dir sollt d'Passwuert net gesinn wann Dir eng Fehlermeldung kritt. Fir ODBC wäert ech och kucken - wann et existéiert, musst Dir et just ewechhuelen.
Bonus: Hannergrënn fir Zoom vu Versammlungen
Andeems Dir op d'Bild klickt, ginn Bonushannergrënn vun de Versammlungen fir déi persistent Lieser op. Mir hunn d'Feier zesumme mat den Avito-Technologie Maskottchen geläscht, mir iwwerpréifen mat Kollegen aus dem Systemverwaltungsraum oder dem Old-School Computerclub, a mir maachen alldeeglech Versammlungen ënner der Bréck géint den Hannergrond vu Graffiti.
Source: will.com