Zënter ClickHouse ass e spezialiséierte System, wann Dir et benotzt, ass et wichteg d'Features vu senger Architektur ze berücksichtegen. An dësem Bericht wäert Alexey iwwer Beispiller vu gemeinsame Feeler schwätzen wann Dir ClickHouse benotzt, wat zu ineffektiver Aarbecht féieren kann. Praktesch Beispiller wäerte weisen wéi d'Auswiel vun engem oder aneren Dateveraarbechtungsschema d'Performance duerch Uerdnung vun der Gréisst änneren kann.
Moien alleguer! Mäin Numm ass Alexey, ech maachen ClickHouse.
Als éischt, ech séier fir Iech direkt ze gefalen, haut wäert ech Iech net soen wat ClickHouse ass. Fir éierlech ze sinn, sinn ech midd dovun. All Kéier wann ech Iech soen wat et ass. A wahrscheinlech weess jiddereen schonn.
Amplaz soen ech Iech wéi eng méiglech Feeler et sinn, dat ass, wéi Dir ClickHouse falsch benotze kënnt. Tatsächlech ass et net néideg ze fäerten, well mir ClickHouse entwéckelen als e System deen einfach ass, praktesch a funktionnéiert aus der Këscht. Ech installéiert et, keng Problemer.
Awer Dir musst nach ëmmer berücksichtegen datt dëse System spezialiséiert ass an Dir kënnt ganz einfach op en ongewéinleche Gebrauchsfall kommen, deen dëse System aus senger Komfortzone hëlt.
Also, wéi eng Rake gëtt et? Meeschtens wäert ech iwwer offensichtlech Saachen schwätzen. Alles ass evident fir jiddereen, jidderee versteet alles a ka frou sinn datt se sou schlau sinn, an déi, déi net verstinn, léieren eppes Neies.
Dat éischt an einfachst Beispill, dat leider oft geschitt ass, ass eng grouss Zuel vun Inserts mat klenge Chargen, dh eng grouss Zuel vu klengen Inserts.
Wa mir betruechten wéi ClickHouse Insert mécht, da kënnt Dir op d'mannst e Terabyte vun Daten an enger Ufro schécken. Et ass kee Problem.
A loosst eis kucken wat déi typesch Leeschtung wier. Zum Beispill hu mir en Dësch vun Yandex.Metrica Daten. Hits. 105 puer Kolonnen. 700 Bytes onkompriméiert. A mir wäerten op eng gutt Manéier a Chargen vun enger Millioun Zeile setzen.
Mir setzen MergeTree an den Dësch, et stellt sech eng hallef Millioun Zeile pro Sekonn eraus. Super. An enger replizéierter Tabell wäert et e bësse méi kleng sinn, ongeféier 400 Reihen pro Sekonn.
A wann Dir d'Quorum-Insertioun aktivéiert, kritt Dir e bësse manner, awer ëmmer anstänneg Leeschtung, 250 Begrëffer pro Sekonn. Quorum Insertion ass eng ondokumentéiert Feature am ClickHouse*.
* ab 2020, .
Wat geschitt wann Dir eppes Schlechtes maacht? Mir setzen eng Zeil an d'MergeTree Dësch a kréien 59 Zeile pro Sekonn. Dat ass 10 Mol méi lues. An ReplicatedMergeTree - 000 Reihen pro Sekonn. A wann de Quorum ageschalt ass, da gëtt et 6 Zeilen pro Sekonn. Menger Meenung no ass dat eng Aart vun absoluten Dreck. Wéi kënnt Dir esou luesen? Ech hunn et souguer op mengem T-Shirt geschriwwen datt ClickHouse net méi lues sollt. Awer trotzdem geschitt et heiansdo.
Tatsächlech ass dëst eise Mängel. Mir konnten einfach alles gutt maachen, awer mir hunn net. A mir hunn et net gemaach well eise Skript et net erfuerdert huet. Mir haten schonn Butches. Mir kruten just Chargen bei eiser Entrée, a keng Problemer. Mir setzen et an alles funktionnéiert gutt. Awer natierlech sinn all méiglech Szenarie méiglech. Zum Beispill, wann Dir eng Rëtsch Serveren hutt op deenen Daten generéiert ginn. A si setzen net sou dacks Daten an, awer si kommen nach ëmmer mat dacks Inserts op. A mir mussen dat iergendwéi vermeiden.
Aus enger technescher Siicht ass de Punkt datt wann Dir en Insert am ClickHouse maacht, d'Donnéeën net an engem Membabel ophalen. Mir hunn net emol eng richteg Log Struktur MergeTree, mee just eng MergeTree, well et weder e Log nach e memTable ass. Mir schreiwen einfach direkt d'Donnéeën an de Dateiesystem, schonn a Kolonnen arrangéiert. A wann Dir 100 Sailen hutt, da musse méi wéi 200 Dateien an engem getrennten Verzeechnes geschriwwe ginn. All dëst ass ganz ëmständlech.
An d'Fro stellt sech: "Wéi et richteg ze maachen?" Wann d'Situatioun esou ass, datt Dir nach iergendwéi Daten am ClickHouse muss ophuelen.
Method 1. Dëst ass am einfachsten. Benotzt eng Zort verdeelt Schlaang. Zum Beispill, Kafka. Dir extrahéiert einfach Daten aus Kafka a batch se eemol pro Sekonn. An alles wäert gutt sinn, Dir notéiert, alles funktionnéiert gutt.
D'Nodeeler sinn datt Kafka en anere voluminöse verdeelte System ass. Ech verstinn och wann Dir schonn Kafka an Ärer Firma hutt. Et ass gutt, et ass bequem. Awer wann et net existéiert, da sollt Dir dräimol denken ier Dir nach en anert verdeelt System an Äre Projet zitt. An dofir ass et derwäert Alternativen ze berücksichtegen.
Method 2. Dëst ass eng al-Schoul Alternativ a gläichzäiteg ganz einfach. Hutt Dir eng Zort Server déi Är Logbicher generéiert. An et schreift just Är Logbicher op eng Datei. An eemol pro Sekonn, zum Beispill, ëmbenennen mir dëse Fichier an räissen en neien of. An e separaten Skript, entweder iwwer Cron oder e puer Daemon, hëlt déi eelst Datei a schreift se op ClickHouse. Wann Dir Logbicher eemol pro Sekonn ophëlt, da wäert alles gutt sinn.
Awer den Nodeel vun dëser Method ass datt wann Äre Server op deem d'Logbicher generéiert iergendwou verschwënnt, da verschwannen d'Donnéeën och.
Method 3. Et gëtt eng aner interessant Method, déi guer keng temporär Dateien erfuerdert. Zum Beispill, hutt Dir eng Zort Reklamm Spinner oder en aneren interessanten Daemon deen Daten generéiert. An Dir kënnt eng Rëtsch Daten direkt am RAM sammelen, am Puffer. A wann genuch Zäit vergaang ass, setzt Dir dëse Puffer op der Säit, erstellt en neien, an an engem getrennten Fuedem setzt dat an de ClickHouse.
Op der anerer Säit verschwannen d'Donnéeën och mat Kill -9. Wann Äre Server crasht, verléiert Dir dës Donnéeën. An en anere Problem ass datt wann Dir net konnt an d'Datebank schreiwen, da sammelen Är Donnéeën am RAM. An entweder de RAM leeft aus, oder Dir wäert einfach Daten verléieren.
Method 4. Aner interessant Method. Hutt Dir eng Zort Server Prozess. An et kann Daten direkt un ClickHouse schécken, awer maacht et an enger Verbindung. Zum Beispill hunn ech eng http-Ufro mat Transfer-Kodéierung geschéckt: chunked with insert. An et generéiert Stécker net ze selten, Dir kënnt all Zeil schécken, obwuel et Overhead gëtt fir dës Donnéeën ze framen.
Wéi och ëmmer, an dësem Fall ginn d'Donnéeën direkt un ClickHouse geschéckt. A ClickHouse wäert se selwer bufferen.
Awer och Problemer entstinn. Elo verléiert Dir Daten, och wann Äre Prozess ëmbruecht gëtt a wann de ClickHouse-Prozess ëmbruecht gëtt, well et en onkomplett Insert ass. An am ClickHouse Inserts sinn atomar bis zu engem bestëmmte spezifizéierte Schwell an der Gréisst vun de Reihen. Am Prinzip ass dëst eng interessant Manéier. Kann och benotzt ginn.
Method 5. Hei ass eng aner interessant Method. Dëst ass eng Aart vu Gemeinschaft-entwéckelte Server fir Datenbatching. Ech hunn et selwer net gekuckt, also kann ech näischt garantéieren. Wéi och ëmmer, keng Garantien gi fir ClickHouse selwer geliwwert. Dëst ass och Open Source, awer op der anerer Säit kënnt Dir un e Qualitéitsstandard gewinnt sinn, dee mir probéieren ze bidden. Awer fir dës Saach - ech weess et net, gitt op GitHub, kuckt de Code. Vläicht hunn se eppes normal geschriwwen.
* ab 2020, sollt och zur Iwwerleeung bäigesat ginn .
Method 6. Aner Method ass Buffer Dëscher ze benotzen. De Virdeel vun dëser Method ass datt et ganz einfach ass ze benotzen. Erstellt eng Buffer-Tabelle a setzt se dran.
Den Nodeel ass datt de Problem net komplett geléist ass. Wann, an engem Taux wéi MergeTree, Dir musst Daten mat enger Batch pro Sekonn gruppéieren, dann an engem Taux an enger Puffertabelle musst Dir op d'mannst bis zu e puer Tausend pro Sekonn gruppéieren. Wann et méi wéi 10 pro Sekonn ass, wäert et nach ëmmer schlecht sinn. A wann Dir et a Chargen setzt, da gesitt Dir datt et honnertdausend Zeilen pro Sekonn ass. An dat ass schonn op zimlech schwéier Donnéeën.
An och Puffer Dëscher hunn net e Log. A wann et eppes falsch mat Ärem Server ass, da ginn d'Donnéeën verluer.
An als Bonus hu mir viru kuerzem d'Méiglechkeet bei ClickHouse fir Daten aus Kafka ze recuperéieren. Et gëtt en Dësch Motor - Kafka. Dir kreéiert einfach. An Dir kënnt materialiséiert Representatioune dran hänken. An dësem Fall wäert et selwer Daten aus Kafka extrahéieren an se an d'Dëscher setzen déi Dir braucht.
A wat besonnesch an dëser Geleeënheet ass, ass datt et net mir waren, déi et gemaach hunn. Dëst ass eng Gemeinschaftsfunktioun. A wann ech soen "Gemeinschaft Fonktioun", Ech mengen et ouni Veruechtung. Mir liesen de Code, hunn eng Iwwerpréiwung gemaach, et soll gutt funktionnéieren.
* ab 2020 ass ähnlech Ënnerstëtzung fir .
Wat soss kéint onbequem oder onerwaart sinn wann Dir Daten asetzt? Wann Dir eng Insert Wäerter Ufro maacht a schreift e puer berechent Ausdréck a Wäerter. Zum Beispill, elo () ass och e berechent Ausdrock. An an dësem Fall ass ClickHouse gezwongen den Dolmetscher vun dësen Ausdréck op all Zeil ze lancéieren, an d'Performance falen duerch Uerderen vun der Gréisst. Et ass besser dëst ze vermeiden.
* am Moment ass de Problem komplett geléist, et gëtt keng Leeschtungsregressioun méi wann Dir Ausdréck a VALUES benotzt.
En anert Beispill ass wann et e puer Probleemer ka sinn wann Dir Daten op enger Batch hutt déi zu enger Rëtsch Partitionen gehéiert. Par défaut, ClickHouse Partitionen sinn duerch Mount. A wann Dir eng Partie vun enger Millioun Zeilen asetzt, an et gëtt Daten fir e puer Joer, da wäert Dir e puer Dosen Partitionen do hunn. An dat entsprécht der Tatsaach, datt et e puer zéng mol méi kleng an der Gréisst Chargen ginn, well bannen sinn se ëmmer éischt an Partitionen opgedeelt.
* Viru kuerzem, am experimentellen Modus, huet ClickHouse Ënnerstëtzung bäigefüügt fir de kompakten Format vu Stécker a Stécker am RAM mat Schreiwe-Ahead Log, wat de Problem bal komplett léist.
Loosst eis elo déi zweet Zort vu Problem kucken - Daten Tippen.
Datetyping kann strikt oder String sinn. String ass wann Dir et just geholl hutt an deklaréiert datt all Är Felder vum Typ String sinn. Dëst suckt. Et ass net néideg dëst ze maachen.
Loosst eis erausfannen, wéi Dir et an deene Fäll richteg maache wëllt, wann Dir wëllt soen datt mir e Feld hunn, eng String, a loosst ClickHouse et eleng erausfannen, an ech wäert net beméien. Mee et lount sech nach e bëssen Effort ze maachen.
Zum Beispill hu mir eng IP Adress. An engem Fall hu mir et als String gespäichert. Zum Beispill, 192.168.1.1. An an engem anere Fall wäert et eng Zuel vun Typ UInt32 * sinn. 32 Bit ass genuch fir eng IPv4 Adress.
Als éischt, komesch genuch, ginn d'Donnéeën ongeféier gläich kompriméiert. Et gëtt natierlech en Ënnerscheed, awer net sou grouss. Also et gi keng speziell Probleemer mat Disk I / O.
Awer et gëtt e seriösen Ënnerscheed an der Prozessorzäit an der Ufro Ausféierungszäit.
Loosst eis d'Zuel vun eenzegaartegen IP Adressen zielen wa se als Zuelen gespäichert sinn. Dat klappt op 137 Millioune Linnen pro Sekonn. Wann datselwecht a Form vu Saiten ass, dann 37 Millioune Linnen pro Sekonn. Ech weess net firwat dësen Zoufall geschitt ass. Ech hunn dës Ufroe selwer gemaach. Awer nach ëmmer ongeféier 4 mol méi lues.
A wann Dir den Ënnerscheed am Disk Space berechent, da gëtt et och en Ënnerscheed. An den Ënnerscheed ass ongeféier ee Véierel, well et sinn zimlech vill eenzegaarteg IP Adressen. A wann et Zeilen mat enger klenger Unzuel vu verschiddene Bedeitunge wieren, da wiere se einfach no dem Wierderbuch an ongeféier dee selwechte Volume kompriméiert.
An de véierfache Zäitdifferenz läit net op der Strooss. Villäicht gitt Dir natierlech näischt, mee wann ech esou en Ënnerscheed gesinn, mécht et mech traureg.
Loosst eis op verschidde Fäll kucken.
1. Ee Fall wann Dir puer verschidden eenzegaarteg Wäerter hunn. An dësem Fall benotze mir eng einfach Praxis déi Dir wahrscheinlech wësst a ka fir all DBMS benotzen. Dëst alles mécht Sënn net nëmme fir ClickHouse. Schreift just numeresch Identifizéierer an d'Datebank. An Dir kënnt op Strings konvertéieren an zréck op der Säit vun Ärer Applikatioun.
Zum Beispill, Dir hutt eng Regioun. An Dir probéiert et als String ze retten. An et wäert do geschriwwe ginn: Moskau a Moskau Regioun. A wann ech gesinn datt et "Moskau" steet, ass et näischt, awer wann et Moskau ass, gëtt et iergendwéi komplett traureg. Dëst ass wéi vill Bytes.
Amplaz, schreiwen mir einfach d'Zuel Ulnt32 an 250. Mir hunn 250 zu Yandex, mä Är kann anescht ginn. Just am Fall wäert ech soen datt ClickHouse eng agebaute Fäegkeet huet fir mat enger Geobase ze schaffen. Dir schreift einfach e Verzeechnes mat Regiounen, dorënner eng hierarchesch, dh et gëtt Moskau, Moskau Regioun, an alles wat Dir braucht. An Dir kënnt um Ufroniveau konvertéieren.
Déi zweet Optioun ass ongeféier d'selwecht, awer mat Ënnerstëtzung am ClickHouse. Dëst ass den Enum Datentyp. Dir schreift einfach all Wäerter déi Dir braucht am Enum. Zum Beispill, Typ vun Apparat a schreiwen do: Desktop, Handy, Tablet, TV. Et gi 4 Optiounen am Ganzen.
Den Nodeel ass datt Dir et periodesch änneren musst. Just eng Optioun dobäi. Loosst eis den Dësch änneren. Tatsächlech ass den Änneren Dësch am ClickHouse gratis. Besonnesch fräi fir Enum well d'Donnéeën op Scheif net änneren. Awer trotzdem kritt den Alter e Spär * um Dësch a muss waarden bis all Auswiel ausgefouert gëtt. An nëmmen no dëser wäert änneren ausgefouert ginn, dh et sinn nach e puer Nodeeler.
* an de leschten Versioune vum ClickHouse ass ALTER komplett net blockéierend gemaach.
Eng aner Optioun déi zimmlech eenzegaarteg ass fir ClickHouse ass extern Dictionnairen ze verbannen. Dir kënnt Zuelen an ClickHouse schreiwen, an Är Verzeichnisser an all System bequem fir Iech halen. Zum Beispill kënnt Dir benotzen: MySQL, Mongo, Postgres. Dir kënnt souguer Ären eegene Mikroservice erstellen deen dës Donnéeën iwwer http schéckt. An um ClickHouse Niveau schreift Dir eng Funktioun déi dës Donnéeën vun Zuelen an Strings konvertéiert.
Dëst ass e spezialiséierten awer ganz effiziente Wee fir e Bäitrëtt op engem externen Dësch ze maachen. An et ginn zwou Méiglechkeeten. An enger Ausdrock ginn dës Donnéeën komplett cache, voll am RAM präsent a mat enger Frequenz aktualiséiert. An an enger anerer Optioun, wann dës Donnéeën net an de RAM passen, da kënnt Dir se deelweis cache.
Hei ass e Beispill. Et gëtt Yandex.Direct. An et gëtt eng Werbefirma a Banneren. Et gi wahrscheinlech ongeféier zéngdausende vu Millioune Reklammefirmen. A si passen ongeféier an de RAM. An et gi Milliarde Banneren, si passen net. A mir benotzen e Cache Wierderbuch vu MySQL.
Deen eenzege Problem ass datt de cachéierte Wierderbuch gutt funktionnéiert wann den Hitrate no bei 100% ass. Wann et méi kleng ass, da wann Dir Ufroe fir all Batch vun Daten veraarbecht, musst Dir tatsächlech déi fehlend Schlësselen huelen an d'Donnéeë vu MySQL kréien. Iwwer ClickHouse kann ech nach ëmmer garantéieren datt - jo, et verlangsamt net, ech wäert net iwwer aner Systemer schwätzen.
An als Bonus sinn Dictionnairen e ganz einfache Wee fir Daten am ClickHouse retroaktiv ze aktualiséieren. Dat ass, Dir hat e Bericht iwwer Werbefirmen, de Benotzer huet einfach d'Werbefirma geännert an an all alen Donnéeën, an all Berichter, hunn dës Donnéeën och geännert. Wann Dir Zeilen direkt un den Dësch schreift, ass et onméiglech se ze aktualiséieren.
Eng aner Manéier wann Dir net wësst wou Dir d'Identifikatoren fir Är Saiten kritt. Dir kënnt et einfach hash. Ausserdeem ass déi einfachst Optioun e 64-Bit Hash ze huelen.
Deen eenzege Problem ass datt wann den Hash 64-Bit ass, da wäert Dir bal sécher Kollisiounen hunn. Well wann et eng Milliard Linnen do sinn, da gëtt d'Wahrscheinlechkeet schonn opmierkbar.
An et wier net ganz gutt, d'Nimm vun de Werbefirmen op dës Manéier ze hashéieren. Wann d'Werbekampagnen vu verschiddene Firmen vermëschen, da gëtt et eppes Onverständlech.
An et gëtt en einfachen Trick. Richteg, et ass och net ganz gëeegent fir sérieux Donnéeën, awer wann eppes net ganz eescht ass, da füügt just de Client Identifizéierer un den Wierderbuchschlëssel. An da wäert Dir Kollisiounen hunn, awer nëmmen bannent engem Client. A mir benotzen dës Method fir Linkkaarten an Yandex.Metrica. Mir hunn URLen do, mir späicheren Hashes. A mir wëssen, datt et natierlech Kollisioune gëtt. Awer wann d'Säit ugewise gëtt, kann d'Wahrscheinlechkeet vernoléissegt ginn datt op enger Säit vun engem Benotzer e puer URLen zesummenhänken an dëst bemierkt.
Als Bonus si fir vill Operatiounen eleng Hashes genuch an d'Saiten selwer brauche net iwwerall gelagert ze ginn.
En anert Beispill ass wann d'Strings kuerz sinn, zum Beispill Websäit Domainen. Si kënne gespäichert ginn wéi se sinn. Oder zum Beispill d'Browsersprooch ru ass 2 Bytes. Natierlech hunn ech wierklech leed fir d'Bytes, awer maach der keng Suergen, 2 Bytes sinn net schued. Halt et w.e.g. sou wéi et ass, maach der keng Suergen.
En anere Fall ass wann, am Géigendeel, et vill Zeilen sinn an et vill eenzegaarteg sinn an hinnen, an och de Set ass potenziell onlimitéiert. En typescht Beispill ass Sich Ausdréck oder URLen. Sich Ausdréck, dorënner Tippfehler. Loosst eis kucken wéi vill eenzegaarteg Sich Sätze pro Dag sinn. An et stellt sech eraus datt si bal d'Halschent vun all Eventer sinn. An an dësem Fall kënnt Dir denken datt Dir d'Donnéeën normaliséiere musst, d'Identificateuren zielen an se an eng separat Tabell setzen. Awer Dir braucht dat net ze maachen. Halt just dës Linnen wéi se sinn.
Et ass besser näischt ze erfannen, well wann Dir et separat späichert, musst Dir e Bäitrëtt maachen. An dëst Joint ass am beschten en zoufälleg Zougang zu Erënnerung, wann et nach an Erënnerung passt. Wann et net passt, da gëtt et Problemer.
A wann d'Donnéeën op der Plaz gespäichert sinn, da ginn se einfach an der erfuerderter Uerdnung vum Dateiesystem gelies an alles ass gutt.
Wann Dir URLen oder eng aner komplex laang String hutt, ass et derwäert ze berücksichtegen datt Dir eng Zort Extrait am Viraus berechent an et an enger separater Kolonn schreift.
Fir URLen, zum Beispill, kënnt Dir d'Domain separat späicheren. A wann Dir wierklech en Domain braucht, da benotzt just dës Kolonn, an d'URLen leien do, an Dir wäert se net emol beréieren.
Loosst eis kucken wat den Ënnerscheed ass. ClickHouse huet eng spezialiséiert Funktioun déi d'Domain berechent. Et ass ganz séier, mir hunn et optimiséiert. An, fir éierlech ze sinn, entsprécht et net emol dem RFC, awer trotzdem berücksichtegt et alles wat mir brauchen.
An an engem Fall wäerte mir einfach d'URLen kréien an d'Domain berechnen. Dat funktionéiert op 166 Millisekonnen. A wann Dir e fäerdege Domain hëlt, da gëtt et nëmmen 67 Millisekonnen, also bal dräimol méi séier. An et ass méi séier net well mir e puer Berechnunge musse maachen, mee well mir manner Daten liesen.
Dofir huet eng Ufro, déi méi lues ass, eng méi héich Geschwindegkeet vu Gigabyte pro Sekonn. Well et liest méi gigabytes. Dëst ass komplett onnéideg Daten. D'Ufro schéngt méi séier ze lafen, awer et dauert méi laang fir ze kompletéieren.
A wann Dir d'Quantitéit vun Daten op der Disk kuckt, stellt sech eraus datt d'URL 126 Megabytes ass, an d'Domain nëmmen 5 Megabytes. Et stellt sech 25 Mol manner eraus. Awer trotzdem gëtt d'Ufro nëmme 4 Mol méi séier ausgefouert. Awer dat ass well d'Donnéeën waarm sinn. A wann et kal wier, wier et wuel 25 Mol méi séier wéinst Disk I/O.
Iwwregens, wann Dir schätzt wéi vill méi kleng en Domain ass wéi eng URL, da gëtt et ongeféier 4 Mol méi kleng, awer aus iergendengem Grond huelen d'Donnéeën 25 Mol manner op Disk. Firwat? Wéinst der Kompressioun. An d'URL ass kompriméiert, an d'Domain ass kompriméiert. Awer dacks enthält d'URL eng Rëtsch Dreck.
An, natierlech, bezilt et déi richteg Datentypen ze benotzen, déi speziell fir déi gewënschte Wäerter entworf sinn oder déi passend sinn. Wann Dir am IPv4 sidd, da späichert UInt32 *. Wann IPv6, dann FixedString(16), well d'IPv6 Adress ass 128 Bits, dh direkt am binäre Format gespäichert.
Awer wat wann Dir heiansdo IPv4 Adressen hutt an heiansdo IPv6? Jo, Dir kënnt béid späicheren. Eng Kolonn fir IPv4, eng aner fir IPv6. Natierlech gëtt et eng Optioun fir IPv4 an IPv6 ze weisen. Dëst wäert och funktionnéieren, awer wann Dir dacks eng IPv4 Adress an Ufroe braucht, da wier et flott et an enger separater Kolonn ze setzen.
* ClickHouse huet elo getrennten IPv4, IPv6 Datentypen déi Daten esou effizient späicheren wéi Zuelen, awer se sou bequem wéi Strings representéieren.
Et ass och wichteg ze bemierken datt et derwäert ass d'Daten am Viraus ze preparéieren. Zum Beispill kritt Dir e puer Matière Logbicher. A vläicht sollt Dir se net einfach direkt an ClickHouse setzen, obwuel et ganz verlockend ass näischt ze maachen an alles funktionnéiert. Awer et ass nach ëmmer derwäert déi Berechnungen auszeféieren déi méiglech sinn.
Zum Beispill, Browser Versioun. An e puer Emgéigend Departement, op déi ech net wëll de Fanger weisen, ass d'Browser Versioun esou gespäichert, dat heescht, als String: 12.3. An dann, fir e Bericht ze maachen, huelen se dës String an deelen se an eng Array, an dann an dat éischt Element vun der Array. Natierlech geet alles méi lues. Ech gefrot firwat se dat maachen. Si hunn mir gesot datt se net fréi Optimiséierung gär hunn. An ech hu keng virzäiteg Pessimiséierung.
Also an dësem Fall wier et méi richteg an 4 Kolonnen opzedeelen. Fäert net hei, well dëst ass ClickHouse. ClickHouse ass eng Kolonn Datebank. A wat méi ordentlech kleng Sailen, wat besser. Et gëtt 5 BrowserVersiounen, maachen 5 Kolonnen. Dëst ass gutt.
Loosst eis elo kucken wat ze maachen wann Dir vill ganz laang Saiten hutt, ganz laang Arrays. Si musse guer net am ClickHouse gespäichert ginn. Amplaz kënnt Dir nëmmen en Identifizéierer am ClickHouse späicheren. A setzt dës laang Linnen an en anere System.
Zum Beispill, ee vun eisen Analyseservicer huet e puer Eventparameter. A wann et vill Parameteren fir Eventer gëtt, späichere mir einfach déi éischt 512 déi opkommen.Well 512 ass net schued.
A wann Dir net iwwer Är Datentypen entscheeden kënnt, da kënnt Dir och Daten am ClickHouse notéieren, awer an enger temporärer Tabell vum Logtyp, speziell fir temporär Donnéeën. Duerno kënnt Dir analyséieren wéi eng Verdeelung vu Wäerter Dir do hutt, wat et am Allgemengen ass, an déi richteg Aarte erstellen.
* ClickHouse huet elo en Datentyp wat Iech erlaabt Strings effizient mat manner Effort ze späicheren.
Loosst eis elo en anere interessante Fall kucken. Heiansdo funktionnéiere Saachen komesch fir Leit. Ech kommen eran a gesinn dat. An et schéngt direkt datt dëst vun e puer ganz erfuerene, intelligenten Admin gemaach gouf, deen extensiv Erfarung huet fir MySQL Versioun 3.23 opzestellen.
Hei gesi mir dausend Dëscher, jidderee vun deenen de Rescht vun der Divisioun notéiert, wien weess wat mat dausend.
Prinzipiell respektéieren ech d'Erfahrung vun anere Leit, och d'Versteesdemech vun der Leed, déi duerch dës Erfahrung erreeche kann.
An d'Grënn si méi oder manner kloer. Dëst sinn al Stereotypen déi kënne accumuléiert sinn wärend Dir mat anere Systemer geschafft hutt. Zum Beispill, MyISAM Dëscher hu kee clustered Primärschlëssel. An dës Manéier fir Daten opzedeelen kann e verzweifelte Versuch sinn déiselwecht Funktionalitéit ze kréien.
En anere Grond ass datt et schwéier ass all Ännerungsoperatiounen op groussen Dëscher ze maachen. Alles wäert blockéiert ginn. Och wann an de modernen Versioune vu MySQL dëse Problem net méi esou eescht ass.
Oder zum Beispill Microsharding, awer méi spéit méi doriwwer.
Et ass net néideg dëst am ClickHouse ze maachen, well als éischt ass de primäre Schlëssel clusteréiert, d'Donnéeën ginn duerch de primäre Schlëssel bestallt.
An heiansdo froen d'Leit mech: "Wéi variéiert d'Performance vun de Range-Ufroen am ClickHouse ofhängeg vun der Tabellgréisst?" Ech soen et ännert sech guer net. Zum Beispill, hutt Dir en Dësch mat enger Milliard Zeile an Dir liest eng Rei vun enger Millioun Zeile. Alles ass gutt. Wann et eng Billioun Zeile an enger Tabell sinn an Dir liest eng Millioun Zeile, da wäert et bal d'selwecht sinn.
An, zweetens, all Zorte vu Saachen wéi manuell Partitionen sinn net erfuerderlech. Wann Dir gitt a kuckt wat um Dateiesystem ass, gesitt Dir datt den Dësch e relativ groussen Deal ass. An et gëtt eppes wéi Partitionen dobannen. Dat ass, ClickHouse mécht alles fir Iech an Dir musst net leiden.
Alter am ClickHouse ass gratis wann Änneren add / drop Kolonn änneren.
An Dir sollt net kleng Dëscher maachen, well wann Dir 10 Reihen oder 10 Reihen an enger Tabell hutt, dann ass et guer net wichteg. ClickHouse ass e System deen den Duerchgang optiméiert, net latency, sou datt et kee Sënn mécht 000 Zeilen ze veraarbecht.
Et ass richteg ee groussen Dësch ze benotzen. Gitt vun alen Stereotypen lass, alles wäert gutt sinn.
An als Bonus, an der leschter Versioun hu mir elo d'Fähegkeet en arbiträre Partitionéierungsschlëssel ze kreéieren fir all Zort Ënnerhalt Operatiounen op eenzel Partitionen auszeféieren.
Zum Beispill, Dir braucht vill kleng Dëscher, zum Beispill, wann et néideg ass e puer Zwëschendaten ze veraarbechten, kritt Dir Stécker an Dir musst eng Transformatioun op hinnen maachen ier Dir op d'Finale Dësch schreift. Fir dëse Fall gëtt et eng wonnerbar Dëschmotor - StripeLog. Et ass e bësse wéi TinyLog, nëmme besser.
* elo huet ClickHouse och .
En anert Antimuster ass Microsharding. Zum Beispill, Dir musst Daten zerstéieren an Dir hutt 5 Server, a muer gëtt et 6 Server. An Dir denkt drun wéi Dir dës Donnéeën rebalancéiert. An amplaz brécht Dir net a 5 Stécker, mee an 1 Stécker. An dann Kaart Dir all eenzel vun dësen microshards zu engem separat Server. An Dir kritt zum Beispill 000 ClickHouses op engem Server, zum Beispill. Separat Instanzen op getrennten Häfen oder getrennten Datenbanken.
Awer dëst ass net ganz gutt am ClickHouse. Well souguer eng ClickHouse Instanz probéiert all verfügbare Serverressourcen ze benotzen fir eng Ufro ze veraarbecht. Dat ass, Dir hutt eng Zort Server an et huet zum Beispill 56 Prozessorkären. Dir leeft eng Ufro déi eng Sekonn dauert an et wäert 56 Kären benotzen. A wann Dir 200 ClickHouses do op engem Server gesat hutt, da stellt sech eraus datt 10 Threads ufänken. Am Allgemengen wäert alles ganz schlecht sinn.
En anere Grond ass datt d'Verdeelung vun der Aarbecht iwwer dës Instanzen ongläich wäert sinn. E puer wäerte méi fréi fäerdeg sinn, anerer wäerte méi spéit fäerdeg sinn. Wann dat alles an enger Instanz geschitt ass, da géif ClickHouse selwer erausfannen wéi d'Daten korrekt tëscht de Threads verdeelen.
An en anere Grond ass datt Dir Interprozessor Kommunikatioun iwwer TCP hutt. D'Donnéeë musse serialiséiert ginn, deserialiséiert ginn, an dëst ass eng rieseg Unzuel u Mikroshards. Et wäert einfach net effektiv funktionnéieren.
En anert Antimuster, obwuel et kaum en Antimuster genannt ka ginn. Dëst ass eng grouss Quantitéit vu Pre-Aggregatioun.
Am Allgemengen ass d'Pre-Aggregatioun gutt. Dir hat eng Milliard Reihen, Dir hutt et aggregéiert an et gouf 1 Reihen, an elo gëtt d'Ufro direkt ausgefouert. Alles ass super. Dir kënnt dëst maachen. A fir dëst huet souguer ClickHouse e speziellen Dëschtyp, AggregatingMergeTree, deen inkrementell Aggregatioun ausféiert wéi d'Donnéeën agefouert ginn.
Awer et ginn Zäiten wou Dir denkt datt mir Daten wéi dës aggregéiere wéi dës. An an e puer Nopeschdepartementer wëll ech och net soen wéi eng, si benotze SummingMergeTree Dëscher fir mam primäre Schlëssel ze resuméieren, a ronn 20 Kolonnen ginn als primäre Schlëssel benotzt. Just am Fall, hunn ech d'Nimm vun e puer Kolonnen fir Geheimnis geännert, awer dat ass zimlech et.
An esou Problemer entstinn. Als éischt gëtt Ären Datevolumen net ze vill erof. Zum Beispill geet et ëm dräimol erof. Dräi Mol wier e gudde Präis fir déi onlimitéiert Analysefäegkeeten ze leeschten déi entstinn wann Är Donnéeën net aggregéiert sinn. Wann d'Donnéeën aggregéiert sinn, da kritt Dir amplaz vun der Analyse nëmmen traureg Statistiken.
A wat ass esou speziell doriwwer? D'Tatsaach ass, datt dës Leit aus dem Nopeschdepartement heiansdo goen a froen fir eng aner Kolonn op de primäre Schlëssel ze addéieren. Dat ass, mir hunn d'Donnéeën esou aggregéiert, awer elo wëlle mir e bësse méi. Awer ClickHouse huet keen alter primäre Schlëssel. Dofir musse mir e puer Scripten an C ++ schreiwen. An ech hu keng Skripte gär, och wann se an C ++ sinn.
A wann Dir kuckt fir wat ClickHouse erstallt gouf, da sinn net aggregéiert Daten genau de Szenario fir deen se gebuer gouf. Wann Dir ClickHouse fir net aggregéiert Donnéeën benotzt, da maacht Dir et richteg. Wann Dir aggregéiert, ass dëst heiansdo verginn.
En aneren interessante Fall ass Ufroen an enger onendlecher Loop. Heiansdo ginn ech op e puer Produktiounsserver a kucken op Showprocesslist do. An all Kéiers entdeckt ech datt eppes schreckleches geschitt.
Zum Beispill, esou. Et ass direkt kloer datt alles an enger Ufro gemaach ka ginn. Schreift einfach d'URL an d'Lëscht do.
Firwat si vill esou Ufroen an enger endloser Loop schlecht? Wann en Index net benotzt gëtt, da wäert Dir vill Passë iwwer déiselwecht Donnéeën hunn. Awer wann den Index benotzt gëtt, zum Beispill, hutt Dir e primäre Schlëssel fir ru an Dir schreift url = eppes do. An Dir denkt datt wann nëmmen eng URL aus der Tabell gelies gëtt, alles gutt wäert sinn. Awer eigentlech nee. Well ClickHouse mécht alles a Chargen.
Wann hien e bestëmmte Spektrum vun Donnéeë muss liesen, liest hien e bësse méi, well den Index am ClickHouse schaarf ass. Dësen Index erlaabt Iech net eng eenzel Zeil an der Tabell ze fannen, nëmmen eng Rei vun iergendenger Aart. An d'Donnéeën sinn a Blocks kompriméiert. Fir eng Zeil ze liesen, musst Dir de ganze Block huelen an entloossen. A wann Dir eng Rëtsch Ufroe maacht, hutt Dir vill Iwwerlappung, an Dir wäert vill Aarbecht ëmmer erëm maachen.
An als Bonus kënnt Dir feststellen datt am ClickHouse Dir sollt net fäerten souguer Megabytes a souguer Honnerte vu Megabytes op d'IN Sektioun ze transferéieren. Ech erënnere mech aus eiser Praxis datt wa mir a MySQL eng Rëtsch Wäerter an d'IN Sektioun transferéieren, zum Beispill mir 100 Megabytes vun e puer Zuelen dohinner transferéieren, da ësst MySQL 10 Gigabytes Erënnerung an näischt geschitt domat, alles funktionnéiert schlecht.
An déi zweet ass datt am ClickHouse, wann Är Ufroen en Index benotzen, dann ass et ëmmer net méi lues wéi e vollen Scan, dat heescht wann Dir bal de ganzen Dësch liest, da geet et sequenziell an liest de ganzen Dësch. Am Allgemengen wäert hien et selwer erausfannen.
Awer trotzdem ginn et e puer Schwieregkeeten. Zum Beispill, d'Tatsaach, datt IN mat enger Ënnerquery den Index net benotzt. Awer dëst ass eise Problem a mir mussen et fixéieren. Et gëtt näischt fundamental hei. Mir flécken et *.
An eng aner interessant Saach ass datt wann Dir eng ganz laang Ufro hutt a verdeelt Ufroveraarbechtung amgaang ass, da gëtt dës ganz laang Ufro un all Server ouni Kompressioun geschéckt. Zum Beispill, 100 megabytes an 500 Serveren. An deementspriechend wäert Dir 50 Gigabytes iwwer d'Netz transferéieren. Et gëtt iwwerdroen an da gëtt alles erfollegräich ofgeschloss.
* scho benotzt; Alles war fixéiert wéi versprach.
An e zimlech allgemenge Fall ass wann Ufroe vun der API kommen. Zum Beispill hutt Dir eng Aart vun Ärem eegene Service erstallt. A wann een Äre Service brauch, da öffnet Dir d'API a wuertwiertlech zwee Deeg méi spéit gesitt Dir datt eppes onverständleches geschitt. Alles ass iwwerlaascht an e puer schrecklech Ufroe kommen eran, déi ni sollte geschéien.
An et gëtt nëmmen eng Léisung. Wann Dir d'API opgemaach hutt, da musst Dir se ofschneiden. Zum Beispill eng Aart vu Quoten aféieren. Et gi keng aner normal Optiounen. Soss schreiwen se direkt e Skript an et gëtt Problemer.
A ClickHouse huet eng speziell Feature - Quoteberechnung. Ausserdeem kënnt Dir Äre Kontingentschlëssel transferéieren. Dëst ass zum Beispill déi intern Benotzer ID. A Quoten ginn onofhängeg fir jidderee vun hinnen berechent.
Elo eng aner interessant Saach. Dëst ass manuell Replikatioun.
Ech weess vu ville Fäll wou, trotz ClickHouse agebaute Replikatiounssupport, d'Leit ClickHouse manuell replizéieren.
Wat ass de Prinzip? Dir hutt eng Datenveraarbechtungspipeline. An et funktionnéiert onofhängeg, zum Beispill, a verschiddenen Datenzenteren. Dir schreift déiselwecht Daten op déiselwecht Manéier am ClickHouse. Richteg, d'Praxis weist datt d'Donnéeën ëmmer nach divergéieren wéinst e puer Features an Ärem Code. Ech hoffen et ass an Ärem.
A vun Zäit zu Zäit musst Dir nach ëmmer manuell synchroniséieren. Zum Beispill, eemol am Mount Administrateuren rsync.
Tatsächlech ass et vill méi einfach d'Replikatioun a ClickHouse ze benotzen. Awer et kann e puer Kontraindikatiounen sinn, well fir dëst musst Dir ZooKeeper benotzen. Ech soen näischt Schlechtes iwwer ZooKeeper, am Prinzip funktionnéiert de System, awer et geschitt datt d'Leit et net benotzen wéinst Java-Phobie, well ClickHouse ass sou e gudde System, geschriwwen an C++, deen Dir benotze kënnt an alles gëtt gutt . An ZooKeeper ass am Java. An iergendwéi wëllt Dir net emol kucken, awer da kënnt Dir manuell Replikatioun benotzen.
ClickHouse ass e praktesche System. Si berücksichtegt Är Besoinen. Wann Dir manuell Replikatioun hutt, da kënnt Dir eng Verdeelt Tabell erstellen déi Är manuell Replika kuckt an e Failover tëscht hinnen mécht. An et gëtt souguer eng speziell Optioun, déi Iech erlaabt Flops ze vermeiden, och wann Är Linnen systematesch divergéieren.
Weider Problemer kënnen entstoen wann Dir primitiv Dësch Motore benotzt. ClickHouse ass e Konstruktor deen eng Rëtsch verschidden Dëschmotoren huet. Fir all sérieux Fäll, wéi an der Dokumentatioun geschriwwen, benotzt Dëscher aus der MergeTree Famill. An all de Rescht - dat ass sou, fir eenzel Fäll oder fir Tester.
An engem MergeTree Dësch, Dir braucht keen Datum an Zäit ze hunn. Dir kënnt et nach ëmmer benotzen. Wann et keen Datum an Zäit ass, schreift datt de Standard 2000 ass. Dëst wäert funktionnéieren a brauch keng Ressourcen.
An an der neier Versioun vum Server kënnt Dir souguer spezifizéieren datt Dir personaliséiert Partitionéierung ouni Partitionsschlëssel hutt. Et wäert d'selwecht sinn.
Op der anerer Säit kënnt Dir primitiv Dëschmotoren benotzen. Fëllt zum Beispill d'Donnéeën eemol aus a kuckt, verdréit a läscht. Dir kënnt Log benotzen.
Oder kleng Bänn fir Zwëschenveraarbechtung späicheren ass StripeLog oder TinyLog.
Erënnerung kann benotzt ginn wann d'Quantitéit vun Daten kleng ass an Dir kënnt einfach eppes am RAM twiddle.
ClickHouse huet net wierklech renormaliséiert Daten gär.
Hei ass en typescht Beispill. Dëst ass eng grouss Zuel vun URLen. Dir setzt se an den nächsten Dësch. An dunn hunn se décidéiert JOIN mat hinnen ze maachen, awer dëst funktionnéiert net, als Regel, well ClickHouse nëmmen Hash JOIN ënnerstëtzt. Wann et net genuch RAM ass fir vill Donnéeën déi verbonne musse sinn, da funktionnéiert JOIN net *.
Wann d'Donnéeë vu héich Kardinalitéit sinn, da maach der keng Suergen, späichert se an enger denormaliséierter Form, d'URLen sinn direkt an der Haapttabelle.
* an elo ClickHouse huet och eng Fusioun matmaachen, an et Wierker an Konditiounen wou Tëschenzäit Donnéeën passt net an de RAM. Awer dëst ass ineffektiv an d'Empfehlung bleift a Kraaft.
E puer méi Beispiller, awer ech bezweifelen schonn ob se Anti-Muster sinn oder net.
ClickHouse huet ee bekannte Feeler. Et weess net wéi et aktualiséiert gëtt *. Op e puer Weeër ass dëst souguer gutt. Wann Dir e puer wichteg Donnéeën hunn, zum Beispill, Comptablesmethod, da wäert keen et kënnen ze schécken, well et keng Aktualiséierungen.
* Ënnerstëtzung fir Update a Läschen am Batchmodus ass viru laanger Zäit bäigefüügt.
Awer et ginn e puer speziell Weeër déi Updates erlaben wéi am Hannergrond. Zum Beispill, Dëscher wéi ReplaceMergeTree. Si maachen Aktualiséierungen während Hannergrond Fusioun. Dir kënnt dëst mat Optimisatiounstabell zwéngen. Maacht dat awer net ze oft, well et d'Partition komplett iwwerschreift.
Verdeelt JOINs am ClickHouse ginn och schlecht vum Ufroplaner gehandhabt.
Schlecht, awer heiansdo Ok.
Benotzt ClickHouse nëmmen fir Daten zréck ze liesen andeems Dir wielt *.
Ech géif net recommandéieren ClickHouse fir ëmständlech Berechnungen ze benotzen. Dat stëmmt awer net ganz, well mer elo scho vun dëser Recommandatioun fort goen. A mir hunn viru kuerzem d'Fäegkeet bäigefüügt fir Maschinnléiermodeller an ClickHouse - Catboost z'applizéieren. An et stéiert mech well ech denken: "Wat en Horror. Dëst ass wéivill Zyklen pro Byte et stellt sech eraus! Ech haassen wierklech Aueren op Bytes verschwenden.
Awer keng Angscht, installéiert ClickHouse, alles wäert gutt sinn. Wann eppes, mir hunn eng Communautéit. Iwwregens, d'Gemeinschaft sidd Dir. A wann Dir Problemer hutt, kënnt Dir op d'mannst bei eis Chat goen, an hoffentlech hëllefen se Iech.
Är Froen
Merci fir de Bericht! Wou kann ech beschwéieren iwwer ClickHouse Crash?
Dir kënnt mech elo perséinlech beschwéieren.
Ech hunn viru kuerzem ugefaang ClickHouse ze benotzen. Ech hunn direkt de Cli Interface erofgelooss.
Wat e Score.
E bësse méi spéit hunn ech de Server mat engem klenge Choix erofgefall.
Dir hutt Talent.
Ech hunn e GitHub Käfer opgemaach, awer et gouf ignoréiert.
Mir wäerte gesinn.
Den Alexey huet mech gefeelt an de Bericht deelzehuelen, versprach mir ze soen wéi Dir Zougang zu den Daten dobannen hutt.
Et ass ganz einfach.
Ech hunn dat gëschter gemierkt. Méi Spezifizitéiten.
Et gi keng schrecklech Tricken do. Et gëtt just Block-by-Block Kompressioun. De Standard ass LZ4, Dir kënnt ZSTD aktivéieren *. Blockéiert vu 64 kilobytes op 1 megabyte.
* et gëtt och Ënnerstëtzung fir spezialiséiert Kompressiounscodecs déi an enger Kette mat aneren Algorithmen benotzt kënne ginn.
Sinn d'Blöcke just rau Daten?
Net ganz rau. Et gi Arrays. Wann Dir eng numeresch Kolonn hutt, da ginn d'Zuelen an enger Zeil an enger Array gesat.
Et ass kloer.
Alexey, e Beispill dat mat uniqExact iwwer IPs war, dh d'Tatsaach datt uniqExact méi laang dauert fir duerch Zeilen ze berechnen wéi duerch Zuelen, a sou weider. Wat wa mir e Feint mat eisen Oueren benotzen a Goss zur Zäit vun der Korrektur? Dat ass, Dir schéngt gesot ze hunn datt op eisem Disk et net ganz anescht ass. Wa mir Linnen vun der Disk a Goss liesen, wäerten eis Aggregater méi séier sinn oder net? Oder wäerte mir hei nach e bëssen gewannen? Et schéngt mir datt Dir dëst getest hutt, awer aus iergendengem Grond et net am Benchmark uginn.
Ech mengen et wäert méi lues sinn wéi ouni Casting. An dësem Fall muss d'IP Adress aus der String parséiert ginn. Natierlech, bei ClickHouse, ass eis IP Adress Parsing och optimiséiert. Mir hu ganz schwéier probéiert, awer do hutt Dir d'Zuelen an zéngdausendste Form geschriwwen. Ganz onwuel. Op der anerer Säit funktionnéiert d'uniqExact Funktioun méi lues op Strings, net nëmme well dës Strings sinn, awer och well eng aner Spezialisatioun vum Algorithmus ausgewielt gëtt. Strings ginn einfach anescht veraarbecht.
Wat wa mir e méi primitiv Datentyp huelen? Zum Beispill hu mir d'Benotzer-ID opgeschriwwen, déi mir dran hunn, et als Zeil opgeschriwwen, an dann verschwonnen, wäert et méi lëschteg sinn oder net?
Ech bezweifelen. Ech mengen et wäert nach méi traureg sinn, well schliisslech ass d'Parséiere vun Zuelen e seriöse Problem. Et schéngt mir datt dëse Kolleg souguer e Bericht gemaach huet wéi schwéier et ass fir Zuelen an zéngdausendste Form ze analyséieren, awer vläicht net.
Alexey, villmools Merci fir de Bericht! A villmools Merci fir ClickHouse! Ech hunn eng Fro iwwer Pläng. Ginn et Pläng fir eng Feature fir Dictionnairen onkomplett ze aktualiséieren?
Dat ass, deelweis Neistart?
Jo Jo. Wéi d'Fäegkeet fir e MySQL-Feld do ze setzen, dh update no sou datt nëmmen dës Donnéeën gelueden sinn wann d'Wörterbuch ganz grouss ass.
Eng ganz interessant Feature. An ech mengen datt eng Persoun et an eisem Chat proposéiert huet. Vläicht war et souguer Dir.
Ech mengen net.
Super, elo stellt sech eraus datt et zwou Ufroe ginn. An Dir kënnt et lues ufänken. Awer ech wëll Iech direkt warnen datt dës Feature ganz einfach ass ze implementéieren. Dat ass, an Theorie, braucht Dir just d'Versioun Zuel an der Tabell ze schreiwen an dann schreiwen: Versioun manner wéi esou an esou. Dat heescht, datt, héchstwahrscheinlech, wäerte mir dat fir Enthusiaster bidden. Sidd Dir en Enthusiast?
Jo, awer leider net an C++.
Wësse Är Kollegen wéi se an C++ schreiwen?
Ech fannen een.
Super*.
* d'Fonktioun gouf zwee Méint nom Bericht bäigefüügt - den Auteur vun der Fro huet et entwéckelt a seng geschéckt .
Merci!
Hallo! Merci fir de Bericht! Dir hutt gesot datt ClickHouse ganz gutt ass fir all d'Ressourcen ze konsuméieren déi et verfügbar ass. An de Spriecher nieft Luxoft huet iwwer seng Léisung fir Russian Post geschwat. Hien huet gesot datt si de ClickHouse wierklech gär hunn, awer si hunn et net benotzt amplaz vun hirem Haaptkonkurrent, well et all d'CPU iessen. A si konnten et net an hir Architektur pluggen, an hiren ZooKeeper mat Docker. Ass et méiglech ClickHouse iergendwéi ze limitéieren sou datt et net alles verbraucht wat et verfügbar ass?
Jo, et ass méiglech a ganz einfach. Wann Dir manner Kären konsuméiere wëllt, da schreift einfach set max_threads = 1. An dat ass et, et wäert d'Ufro an engem Kär ausféieren. Ausserdeem kënnt Dir verschidden Astellunge fir verschidde Benotzer uginn. Also kee Problem. A sot äre Kollege vu Luxoft, datt et net gutt ass, datt si dës Astellung net an der Dokumentatioun fonnt hunn.
Alexey, Moien! Ech géif gären iwwer dës Fro stellen. Dëst ass net déi éischte Kéier datt ech héieren hunn datt vill Leit ufänken ClickHouse als Späichere fir Logbicher ze benotzen. Am Bericht sot Dir dëst net ze maachen, dh Dir braucht keng laang Saiten ze späicheren. Wat mengt Dir doriwwer?
Als éischt sinn Logbicher, als Regel, net laang Saiten. Et ginn natierlech Ausnahmen. Zum Beispill, e Service, deen an Java geschriwwe gëtt, werft eng Ausnam, et gëtt protokolléiert. A sou weider an enger endloser Loop, an de Raum op der Festplack leeft aus. D'Léisung ass ganz einfach. Wann d'Linnen ganz laang sinn, da schneiden se. Wat heescht laang? Zéng Kilobyte si schlecht*.
* an de leschte Versioune vu ClickHouse ass "adaptive Indexgranularitéit" aktivéiert, wat de Problem eliminéiert fir laang Reihen fir de gréissten Deel ze späicheren.
Ass e Kilobyte normal?
Et ass normal.
Hallo! Merci fir de Bericht! Ech hunn schonn iwwer dëst am Chat gefrot, awer ech erënnere mech net ob ech eng Äntwert krut. Ginn et Pläng fir d'WITH Sektioun iergendwéi wéi CTE auszebauen?
Nach net. Eis WITH Sektioun ass e bësse frivol. Et ass wéi eng kleng Feature fir eis.
Ech verstinn. Merci!
Merci fir de Bericht! Ganz interessant! Global Fro. Ginn et Pläng fir d'Dateläschung z'änneren, vläicht a Form vun enger Aart vu Stécker?
Noutwendeg. Dëst ass eis éischt Aufgab an eiser Schlaang. Mir denken elo aktiv un wéi alles richteg ze maachen. An Dir sollt d'Tastatur drécken * ufänken.
* Dréckt d'Knäppercher op der Tastatur an huet alles gemaach.
Wäert dëst iergendwéi d'Systemleistung beaflossen oder net? Wäert d'Insertioun sou séier sinn wéi elo?
Vläicht d'Läschen selwer an d'Aktualiséierunge selwer wäerte ganz schwéier sinn, awer dëst wäert net d'Performance vu Selektiounen oder d'Performance vun Inserts beaflossen.
An nach eng kleng Fro. Bei der Presentatioun hutt Dir iwwer de primäre Schlëssel geschwat. Deementspriechend hu mir Partitionéierung, déi monatlecht par défaut ass, richteg? A wa mir eng Datumbereich setzen déi an e Mount passt, da gëtt nëmmen dës Partition gelies, oder?
Jo.
Eng Fro. Wa mir keng Primärschlëssel kënnen auswielen, ass et dann richteg fir et speziell no dem "Datum" Feld ze maachen, sou datt et am Hannergrond manner Ëmarrangement vun dësen Donnéeën ass fir datt se méi uerdentlech passen? Wann Dir keng Gammesufroen hutt an Dir kënnt net emol e primäre Schlëssel auswielen, ass et derwäert en Datum an de primäre Schlëssel ze setzen?
Jo.
Vläicht mécht et Sënn fir e Feld an de primäre Schlëssel ze setzen deen d'Donnéeën besser kompriméiert wann se no dësem Feld zortéiert sinn. Zum Beispill, Benotzer ID. Benotzer, zum Beispill, geet op déi selwecht Site. An dësem Fall, setzen d'Benotzer ID an Zäit. An da ginn Är Donnéeën besser kompriméiert. Wat den Datum ugeet, wann Dir wierklech net hutt an ni Range Ufroen op Datumen hutt, da musst Dir den Datum net an de primäre Schlëssel setzen.
OK villmools Merci!
Source: will.com