Siccomu ClickHouse hè un sistema specializatu, hè impurtante piglià in contu e peculiarità di a so architettura quandu l'utilizanu. In questu rapportu, Alexey parlerà di esempi di errori tipici quandu si usa ClickHouse, chì pò purtà à un travagliu inefficient. Utilizendu esempi pratichi, mustraremu cumu l'scelta di unu o un altru schema di trattamentu di dati pò cambià u rendiment per ordini di grandezza.
Salut à tutti ! Mi chjamu Alexey, creau ClickHouse.
Prima, mi affrettaraghju à piacè immediatamente, ùn vi dicu micca oghje ciò chì hè ClickHouse. Per esse onesto, ne sò stancu. Vi dicu ogni volta ciò chì hè. È prubabilmente tutti sà digià.
Invece, vi dicu ciò chì hè u rake possibbili, vale à dì cumu ClickHouse pò esse misused. In fatti, ùn deve esse paura, perchè avemu sviluppatu ClickHouse cum'è un sistema chì hè simplice, còmuda, è travaglia fora di a scatula. Installatu tuttu, senza prublema.
Ma sempre, deve esse cunsideratu chì stu sistema hè specializatu è pudete facilmente sbattà in un casu d'usu inusual chì piglià stu sistema fora di a so zona di cunfortu.
Allora, chì sò i razzii ? In fondu, parleraghju di e cose evidenti. Tuttu hè ovvi à tutti, tutti capiscenu tuttu è ponu esse felici chì sò cusì intelligenti, è quelli chì ùn capiscenu micca amparà qualcosa di novu.
U primu esempiu sèmplice, chì, sfurtunatamenti, spessu accade, hè un gran numaru di inseriti cù picculi batch, vale à dì un gran numaru di picculi inseriti.
Se cunsideremu cumu ClickHouse realiza un inserimentu, pudete mandà almenu un terabyte di dati in una dumanda. Ùn hè micca un prublema.
È vedemu quale serà a prestazione tipica. Per esempiu, avemu una tavula cù dati Yandex.Metrics. Hits. 105 qualchi culonne. 700 bytes senza cumpressione. E avemu da inserisce in un bonu modu batchs di un milione di linii.
Inseremu in a tavola MergeTree, un mezu milione di fila per seconda sò ottenuti. Perfettu. In una tavula replicata - serà un pocu menu, circa 400 000 fila per seconda.
È se accende l'inserzione di quorum, uttene un pocu menu, ma sempre un rendimentu decentu, 250 000 volte per seconda. Quorum Insertion hè una funzione non documentata in ClickHouse*.
* da 2020, .
Chì succede se fate male? Inseremu una fila in a tavola MergeTree è uttene 59 fila per seconda. Questu hè 10 volte lento. In ReplicatedMergeTree - 000 fila per seconda. È se u quorum s'accende, allora 6 linee per seconda sò ottenute. In u mo parè, questu hè un tipu di merda assoluta. Cumu pudete rallentà cusì ? Dice ancu nantu à a mo T-shirt chì ClickHouse ùn deve micca rallentà. Ma ancu ciò chì succede qualchì volta.
In fatti, questu hè u nostru difettu. Pudemu fà u funziunamentu bè, ma ùn avemu micca fattu. È ùn avemu micca, perchè u nostru script ùn avia micca bisognu. Avemu digià avutu lotti. Avemu ricevutu solu lotti à l'entrata, è senza prublemi. Cunnette è tuttu funziona bè. Ma, sicuru, ogni tipu di scenarii sò pussibuli. Per esempiu, quandu avete una mansa di servitori nantu à quale data hè generata. È ùn anu micca inseritu dati cum'è spessu, ma anu sempre inseriti frequenti. È avete bisognu à evità questu.
Da un puntu di vista tecnicu, u fondu hè chì quandu fate un inserimentu in ClickHouse, i dati ùn entranu micca in ogni memtable. Ùn avemu mancu una vera struttura di log MergeTree, ma solu un MergeTree, perchè ùn ci hè nè log nè memTable. Scrivemu appena subitu i dati à u sistema di schedari, digià scompostu in culonni. È s'è vo avete 100 culonni, tandu più di 200 schedari deve esse scrittu à un cartulare separatu. Tuttu chistu hè assai ingombrante.
È a quistione nasce: "Cumu fà bè?" Se una tale situazione, avete sempre bisognu di scrive in qualchì manera dati à ClickHouse.
Metudu 1. Questu hè u modu più faciule. Aduprate qualchì tipu di fila distribuita. Per esempiu, Kafka. Pigliate solu e dati da Kafka, li batchemu una volta à seconda. È tuttu sarà bè, registrà, tuttu funziona bè.
I svantaghji sò chì Kafka hè un altru sistema di distribuzione ingombrante. Aghju capitu ancu s'ellu avete digià Kafka in a vostra cumpagnia. Hè bonu, hè convenientu. Ma s'ellu ùn hè micca quì, allora duvete pensà trè volte prima di trascinà un altru sistema distribuitu in u vostru prughjettu. È cusì vale a pena cunsiderà alternative.
Metudu 2. Eccu una alternativa cusì antica è à u stessu tempu assai simplice. Avete qualchì tipu di servitore chì genera i vostri logs. È scrive solu i vostri logs in un schedariu. È una volta un secondu, per esempiu, cambiamu u nome di stu schedariu, apre un novu. È un script separatu o da cron o un daemon piglia u schedariu più anticu è u scrive in ClickHouse. Sè vo scrivite logs una volta à seconda, allura tuttu sarà bè.
Ma u svantaghju di stu metudu hè chì se u vostru servitore nantu à quale i logs sò generati hè sparitu in un locu, allora i dati spariranu ancu.
Metudu 3. Ci hè un altru modu interessante, chì hè senza schedari tempurale à tutti. Per esempiu, avete qualchì tipu di spinner di publicità o qualchì altru daemon interessante chì genera dati. È pudete accumulà una mansa di dati ghjustu in a RAM, in u buffer. È quandu passa una quantità abbastanza di tempu, mette stu buffer da parte, creanu un novu, è inserisci ciò chì hà digià accumulatu in ClickHouse in un filu separatu.
Per d 'altra banda, a dati sparisce ancu cù kill -9. Se u vostru servitore falà, perderà sta dati. È un altru prublema hè chì se ùn pudete micca scrive à a basa di dati, allora i vostri dati s'acumuleranu in a RAM. È o a RAM scorri, o si perde solu dati.
Metudu 4. Un altru modu interessante. Avete qualchì prucessu di u servitore. È pò mandà dati à ClickHouse in una volta, ma fate in una cunnessione. Per esempiu, aghju mandatu una dumanda http cù codificazione di trasferimentu: chunked with insert. È genera chunks micca troppu raramenti, pudete mandà ogni linea, ancu s'ellu ci sarà un overhead per framing sta dati.
Tuttavia, in questu casu, i dati seranu mandati à ClickHouse immediatamente. È ClickHouse stessu li buffererà.
Ma ci sò ancu prublemi. Avà vi perde dati, cumpresi quandu u vostru prucessu hè ammazzatu è s'è u prucessu ClickHouse hè ammazzatu, perchè serà un inseritu incomplete. È in ClickHouse inserti sò atomichi finu à qualchì limitu specificatu in a dimensione di fila. In principiu, questu hè un modu interessante. Pò esse ancu usatu.
Metudu 5. Eccu un altru modu interessante. Questu hè un tipu di servitore sviluppatu da a cumunità per u batching di dati. Ùn aghju micca fighjatu da mè stessu, cusì ùn possu micca guarantiscia nunda. Tuttavia, ùn ci hè micca garantia per ClickHouse stessu. Questu hè ancu open source, ma da l'altra banda, pudete avè abituatu à qualchì standard di qualità chì pruvemu di furnisce. Ma per questa cosa - ùn sò micca sapè, andate à GitHub, fighjate u codice. Forse anu scrittu qualcosa di bonu.
* da u 2020, deve ancu esse aghjuntu à a considerazione .
Metudu 6. Un altru modu hè di utilizà tavule Buffer. U vantaghju di stu metudu hè chì hè assai faciule per cumincià à aduprà. Crea una tavola Buffer è inserisci in questu.
Ma u svantaghju hè chì u prublema ùn hè micca cumpletamente risolta. Se à un ritmu di u tipu MergeTree duvete raggruppà e dati per un batch per seconda, dopu à una tarifa in una tavola di buffer, avete bisognu di raggruppà almenu parechji milla per seconda. Se ci sò più di 10 000 per seconda, serà sempre male. È se inserisci in batch, allora avete vistu chì centu mila linee per seconda sò ottenuti quì. È questu hè digià nantu à dati abbastanza pisanti.
È ancu i buffer tables ùn anu micca un logu. È se qualcosa hè sbagliatu cù u vostru servitore, allora i dati seranu persi.
È cum'è bonus, avemu avutu recentemente l'uppurtunità di cullà dati da Kafka in ClickHouse. Ci hè un mutore di tavulinu - Kafka. Sò simplicemente creanu. È pudete appiccà vedute materializzate nantu à questu. In questu casu, caccià e dati da Kafka è inserisce in e tavule chì avete bisognu.
È ciò chì hè particularmente piacevule in questa opportunità hè chì ùn avemu micca fattu. Questa hè una funzione di a cumunità. È quandu dicu "caratteristica di a cumunità", a dicu senza disprezzu. Avemu lettu u codice, hà fattu una rivista, duverebbe travaglià bè.
* da u 2020, ci hè un supportu simili per .
Chì altru pò esse inconveniente o inespettatu quandu inserite dati? Se fate una dumanda di valori inseriti è scrivite alcune espressioni calculate in valori. Per esempiu, now () hè ancu una espressione evaluata. È in questu casu, ClickHouse hè furzatu à lancià l'interprete di queste espressioni per ogni linea, è u rendiment scenderà per ordini di grandezza. Hè megliu evitari.
* à u mumentu, u prublema hè cumplettamente risolta, ùn ci hè più regressione di rendiment quandu si usa l'espressioni in VALUES.
Un altru esempiu induve ci pò esse qualchi prublemi hè quandu i vostri dati nantu à un batch appartene à una mansa di partizioni. Per automaticamente, i partizioni ClickHouse per mese. È se inserisci un batch di un milione di fila, è ci sò dati per parechji anni, allora avete parechje decine di partizioni. È questu hè equivalente à u fattu chì ci saranu lotte parechje decine di volte più chjucu, perchè in l'internu sò sempre prima divisu in partizioni.
* Recentemente in ClickHouse in modu sperimentale aghjustatu supportu per u formatu compactu di chunks è chunks in RAM cù scrittura in anticipu, chì risolve quasi cumplettamente u prublema.
Avà cunzidira u sicondu tipu di prublema - typing di dati.
A tipografia di dati pò esse strettu, è qualchì volta stringa. String - questu hè quandu avete appena pigliatu è dichjaratu chì avete tutti i campi di tipu string. Succhia. Ùn avete micca fà quessa.
Scupritemu cumu fà bè in i casi induve vulete dì chì avemu qualchì campu, una stringa, è lascià ClickHouse capisce da sè stessu, ma ùn aghju micca piglià un bagnu di vapore. Ma hè sempre vale a pena mette in qualchì sforzu.
Per esempiu, avemu un indirizzu IP. In un casu, avemu salvatu cum'è una stringa. Per esempiu, 192.168.1.1. Altrimenti, serà un numeru di tipu UInt32 *. 32 bits hè abbastanza per un indirizzu IPv4.
Prima, curiosamente, i dati seranu cumpressi circa u listessu. Ci sarà una sfarenza, sicuru, ma micca cusì grande. Allora ùn ci sò micca prublemi speciali cù l'I / O di discu.
Ma ci hè una seria differenza in u tempu di CPU è u tempu di esecuzione di a dumanda.
Contemu u numeru di indirizzi IP unichi si sò almacenati cum'è numeri. Risulta 137 milioni di linii per seconda. Sì u listessu cum'è e linee, allora 37 milioni di linee per seconda. Ùn sò micca sapè perchè sta coincidenza hè accaduta. Aghju fattu queste dumande da mè stessu. Ma quantunque circa 4 volte più lento.
È se calculà a diferenza in u spaziu di discu, allora ci hè ancu una diferenza. È a diffarenza hè di circa un quartu, perchè ci sò assai indirizzi IP unichi. È s'ellu ci era ligna cù un picculu numeru di valori diffirenti, allora si sò stati tranquillamente compressi in u dizziunariu in circa u stessu voluminu.
È a sfarenza di u quadru di u tempu ùn si trova micca nantu à a strada. Forsi, di sicuru, ùn importa micca, ma quandu vecu una tale differenza, mi sentu tristu.
Cunsideremu diversi casi.
1. Un casu quandu avete pochi valori unichi diffirenti. In questu casu, usemu una pratica simplice chì probabilmente sapete è pudete aduprà per qualsiasi DBMS. Tuttu questu hè sensu micca solu per ClickHouse. Basta à scrive l'identificatori numerichi à a basa di dati. È pudete cunvertisce in strings è torna à u latu di a vostra applicazione.
Per esempiu, avete una regione. È pruvate à salvà cum'è una stringa. È serà scrittu quì: Mosca è Regione di Mosca. È quandu vecu chì "Mosca" hè scrittu quì, allora questu hè sempre nunda, è quandu hè MO, in qualchì manera diventa completamente tristu. Hè quantu byte.
Invece, simpricimenti scrivite u numeru Ulnt32 è 250. Avemu 250 in Yandex, ma u vostru pò esse diversu. In casu, diceraghju chì ClickHouse hà una capacità integrata di travaglià cù una geobase. Basta scrive un annuariu cù e regioni, cumpresa una gerarchica, vale à dì chì ci sarà Mosca, Regione di Mosca, è tuttu ciò chì avete bisognu. È pudete cunvertisce à u livellu di dumanda.
A seconda opzione hè quasi a stessa, ma cù supportu in ClickHouse. Hè un tipu di dati Enum. Basta scrive tutti i valori chì avete bisognu in l'Enum. Per esempiu, u tipu di dispusitivu è scrive quì: desktop, mobile, tablet, TV. Solu 4 opzioni.
U svantaghju hè chì avete bisognu di cambià periodicamente. Una sola opzione hè stata aghjunta. Facemu un altru table. In fatti, l'alter table in ClickHouse hè liberu. In particulare gratuitu per Enum perchè e dati nantu à u discu ùn cambianu micca. Ma in ogni modu, Alter acquista una serratura * nantu à a tavula è deve aspittà finu à chì tutte e selezzione sò finite. È solu dopu à questu altere serà eseguitu, vale à dì, ci sò ancu qualchi inconvenience.
* in e versioni recenti di ClickHouse, ALTER hè fattu completamente senza bloccu.
Un'altra opzione abbastanza unica per ClickHouse hè a cunnessione di dizionari esterni. Pudete scrive numeri in ClickHouse, è mantene i vostri cartulari in ogni sistema cunvene per voi. Per esempiu, pudete aduprà: MySQL, Mongo, Postgres. Pudete ancu creà u vostru propiu microserviziu, chì mandarà queste dati via http. È à u livellu ClickHouse, scrivite una funzione chì cunvertisce sta dati da numeri à strings.
Questu hè un modu specializatu, ma assai efficae, per fà un join nantu à una tavola esterna. È ci sò dui opzioni. In una opzione, sta dati sarà cumplettamente in cache, cumplettamente presente in a RAM è aghjurnata à certi intervalli. È in una altra opzione, se sta dati ùn si mette micca in a RAM, pudete parzialmente cache.
Eccu un esempiu. Ci hè Yandex.Direct. È ci hè una cumpagnia di publicità è banners. Ci hè probabilmente decine di milioni di cumpagnie di publicità. È apprussimatamente si mette in a RAM. È ci sò miliardi di banners, ùn sò micca adattati. È usemu un dizziunariu in cache da MySQL.
L'unicu prublema hè chì u dizziunariu in cache funziona bè se a rata di successu hè vicinu à 100%. S'ellu hè più chjucu, quandu si tratta di e dumande per ogni pacchettu di dati, serà necessariu di piglià veramente e chjave mancanti è andate à piglià e dati da MySQL. À propositu di ClickHouse, possu ancu guarantiscia chì - iè, ùn rallenta micca, ùn parleraghju micca di altri sistemi.
È cum'è bonus, i dizziunari sò un modu assai faciule per aghjurnà e dati in ClickHouse retroattivamente. Questu hè, avete avutu un rapportu nantu à l'imprese di publicità, l'utilizatori simpricimenti cambiatu a cumpagnia di publicità è in tutti i vechji dati, in tutti i rapporti, sta dati hà ancu cambiatu. Sè vo scrivite fila direttamente à a tavula, allura ùn sarà capaci di aghjurnà li.
Un altru modu quandu ùn sapete induve uttene l'identificatori per i vostri strings. pudete solu hash. È l'opzione più faciule hè di piglià un hash 64-bit.
L'unicu prublema hè chì, se l'hash hè 64-bit, allora avete quasi certamente scontri. Perchè s'ellu ci hè un miliardo di linii, allora a probabilità hè digià diventata tangibule.
È ùn saria micca assai bonu per hash i nomi di cumpagnie di publicità cusì. Se e campagne di publicità di e diverse cumpagnie si mischianu, allora ci sarà qualcosa incomprensibile.
È ci hè un truccu simplice. True, ùn hè micca assai adattatu per i dati serii, ma se qualcosa ùn hè micca assai seriu, allora solu aghjunghje un altru identificatore di cliente à a chjave di u dizziunariu. È tandu averete scontri, ma solu in un cliente. E avemu aduprà stu metudu per a mappa di ligame in Yandex.Metrica. Avemu urls quì, almacenamu hash. È sapemu chì ci sò cunflitti, sicuru. Ma quandu una pagina hè visualizata, allora a probabilità chì si trova in una pagina per un utilizatore chì certi urls si fermanu è questu serà nutatu, allora questu pò esse trascuratatu.
Cum'è un bonus, per parechje operazioni, solu l'hash sò abbastanza è e corde ùn ponu esse guardate in ogni locu.
Un altru esempiu si i stringi sò brevi, cum'è i domini di u situ web. Puderanu esse guardati cum'è. O, per esempiu, a lingua di u navigatore ru hè 2 bytes. Di sicuru, mi dispiace per i byte, ma ùn vi preoccupate, 2 bytes ùn sò micca una pietà. Per piacè mantenela cum'è, ùn vi preoccupate.
Un altru casu hè quandu, à u cuntrariu, ci sò assai corde è à u stessu tempu ci sò assai unichi in elli, è ancu u settore hè potenzalmentu illimitatu. Un esempiu tipicu hè e frasi di ricerca o URL. Frasi di ricerca, ancu per via di sbagli di battitura. Videmu quante frasi di ricerca uniche per ghjornu. È si trova chì sò quasi a mità di tutti l'avvenimenti. È in questu casu, pudete pensà chì avete bisognu di nurmalizà e dati, cuntà l'identificatori, mette in una tavola separata. Ma ùn avete micca fà quessa. Mantene queste linee cum'è.
Megliu - ùn inventate nunda, perchè s'ellu si guarda per separatamente, vi tuccherà à fà un unitu. È questu unisce hè in u megliu un accessu aleatoriu à a memoria, se si mette sempre in memoria. S'ellu ùn hè micca adattatu, allora ci saranu prublemi in generale.
È se i dati sò guardati in u locu, allora sò simpliciamente leghje in l'ordine ghjustu da u sistema di schedari è tuttu hè bè.
Sì avete urls o qualchì altru stringu longu cumplessu, allora duvete pensà à u fattu chì pudete calculà qualchì squeeze in anticipu è scrivite in una colonna separata.
Per urls, per esempiu, pudete almacenà u duminiu separatamente. È s'ellu avete veramente bisognu di un duminiu, allora solu aduprà sta colonna, è l'urls si trovanu, è ùn li toccu mancu.
Videmu quale hè a diffarenza. ClickHouse hà una funzione specializata chì calcula u duminiu. Hè assai veloce, l'avemu ottimisatu. È, per esse onestu, ùn hè mancu cunfurmità cù u RFC, ma quantunque cunsidereghja tuttu ciò chì avemu bisognu.
È in un casu, avemu solu ottene l'urls è calculà u duminiu. Risulta 166 millisecondi. È s'è vo pigliate un duminiu ready-made, allura si gira solu 67 millisecondi, vale à dì, quasi trè volte più veloce. È più veloce, micca perchè avemu bisognu di fà qualchi calculi, ma perchè leghje menu dati.
Per una certa ragione, una dumanda, chì hè più lenta, riceve più veloce in gigabyte per seconda. Perchè leghje più gigabyte. Questu hè dati cumpletamente redundante. A dumanda pare chì currerà più veloce, ma dura più tempu per compie.
E se fighjate à a quantità di dati nantu à u discu, risulta chì l'URL hè 126 megabytes, è u duminiu hè solu 5 megabytes. Risulta 25 volte menu. Tuttavia, a dumanda hè sempre solu 4 volte più veloce. Ma hè perchè i dati sò caldi. È s'ellu era friddu, saria probabilmente 25 volte più veloce per via di l'I / O di u discu.
In modu, se evaluate quantu u duminiu hè menu di l'URL, allora si trova nantu à una volta 4. Ma per una certa ragione, i dati nantu à u discu pigghianu 25 volte menu. Perchè? A causa di cumpressione. È l'url hè cumpressu, è u duminiu hè cumpressu. Ma spessu l'url cuntene una mansa di basura.
E, sicuru, vale a pena aduprà i tipi di dati ghjusta chì sò specificamente pensati per i valori ghjusti o chì si adattanu. Sè site in IPv4 allora almacenà UInt32 *. Se IPv6, allora FixedString (16), perchè un indirizzu IPv6 hè 128 bits, vale à dì, magazzinu direttamente in formatu binariu.
Ma chì sì qualchì volta avete indirizzi IPv4 è qualchì volta IPv6? Iè, pudete tene tutti dui. Una colonna per IPv4, una altra per IPv6. Di sicuru, ci hè una opzione per mapà IPv4 à IPv6. Questu hà da travaglià ancu, ma s'ellu hè spessu bisognu di un indirizzu IPv4 in e vostre dumande, allora saria bellu di mette in una colonna separata.
* ClickHouse hà avà tippi di dati IPv4, IPv6 separati chì almacenanu e dati in modu efficiente cum'è numeri, ma i rapprisentanu cum'è convenientemente cum'è stringhe.
Hè impurtante ancu di nutà chì vale a pena preprocessing i dati in anticipu. Per esempiu, alcuni logs crudi venenu à voi. È, forsi, ùn deve micca mette in ClickHouse subitu, ancu s'ellu hè assai tentatore di fà nunda è tuttu funziona. Ma hè sempre vale a pena di realizà quelli calculi chì sò pussibuli.
Per esempiu, a versione di u navigatore. In qualchì dipartimentu vicinu, chì ùn vogliu micca indicà u dettu, a versione di u navigatore hè guardatu cusì cusì, vale à dì cum'è una stringa: 12.3. E poi, per fà un rapportu, piglianu sta stringa è dividenu per un array, è dopu da u primu elementu di l'array. Naturalmente, tuttu rallenta. Aghju dumandatu perchè facenu questu. M'hà dettu chì ùn li piace micca l'ottimisazione prematura. È ùn mi piace micca u pessimisimu prematuru.
Dunque, in questu casu, saria più curretta di dividisce in 4 colonne. Ùn àbbia paura quì, perchè questu hè ClickHouse. ClickHouse hè una basa di dati di colonna. E più culonne pulite, megliu. Ci sarà 5 BrowserVersion, fate 5 colonne. Questu hè bè.
Avà cunsiderà ciò chì deve fà s'ellu avete assai stringi assai longu, arrays assai longu. Ùn anu micca bisognu à esse guardatu in ClickHouse in tuttu. Invece, pudete almacenà solu un identificatore in ClickHouse. E sti lunghe fila li spinghjenu in un altru sistema.
Per esempiu, unu di i nostri servizii analitici hà alcuni parametri di l'avvenimentu. E se parechji paràmetri venenu à l'avvenimenti, salvemu solu i primi 512 chì venenu à traversu. Perchè 512 ùn hè micca una pietà.
È s'è vo ùn pò decide nantu à i vostri tipi di dati, allura vi ponu dinù scrive dati à ClickHouse, ma à una tavola pruvisoriu di u tipu Log, chì hè spiciali di dati tempurale. Dopu quì, pudete analizà quale tipu di distribuzione di valori avete quì, ciò chì generalmente ci hè è custituiscenu i tipi curretti.
* Avà ClickHouse hà un tipu di dati chì vi permette di almacenà in modu efficace e corde cù menu sforzu.
Avà cunsiderà un altru casu interessante. Calchì volta e cose travaglianu in una manera strana per a ghjente. Vaiu è vecu questu. È immediatamente pare chì questu hè statu fattu da un amministratore assai espertu è intelligente chì hà una vasta sperienza in a stallazione di a versione 3.23 di MySQL.
Quì vedemu mille tavule, ognuna di quali cuntene u restu di dividendu ùn hè micca chjaru ciò chì da mille.
In principiu, rispettu l'esperienza di l'altri, cumpresu a capiscenu chì tipu di soffrenza pò esse acquistata.
E i mutivi sò più o menu chjaru. Quessi sò vechji stereotipi chì ponu esse accumulati mentre travagliavanu cù altri sistemi. Per esempiu, e tavule MyISAM ùn anu micca una chjave primaria clustered. È sta manera di spartera di dati pò esse un tentativu dispiratu per ottene a listessa funziunalità.
Un altru mutivu hè chì hè difficiule di fà qualsiasi operazione di alterazione nantu à tavule grande. Tuttu serà bluccatu. Ancu s'è in versioni muderni di MySQL, stu prublema ùn hè più cusì seriu.
O, per esempiu, microsharding, ma più nantu à questu dopu.
In ClickHouse, ùn avete micca bisognu di fà questu, perchè, prima, a chjave primaria hè raggruppata, i dati sò urdinati da a chjave primaria.
E qualchì volta a ghjente mi dumanda: "Cumu cambia a prestazione di e dumande di gamma in ClickHouse cù a dimensione di a tavula?". Dicu chì ùn cambia nunda. Per esempiu, avete una tavula cù un miliardo di fila è leghje un intervallu di un milione di fila. Tuttu hè bè. Se a tavula hà un trilione di fila è leghje un milione di fila, allora serà quasi u listessu.
È, in segundu, qualsiasi pezzi cum'è partizioni manuali ùn sò micca necessariu. Se andate è fighjate ciò chì hè nantu à u sistema di fugliale, vi vede chì una tavola hè una cosa abbastanza seria. È quì dentru ci hè qualcosa cum'è partizioni. Questu hè, ClickHouse face tuttu per voi è ùn avete micca bisognu di soffre.
Alter in ClickHouse hè liberu se cambia a colonna aghjunghje / drop.
È ùn deve micca fà tavule chjuche, perchè s'è vo avete 10 fila o 10 000 fila in u vostru tavulinu, allora ùn importa micca. ClickHouse hè un sistema chì ottimisimu u throughput, micca a latenza, per quessa ùn hà micca sensu di processà 10 linee.
Hè currettu aduprà una grande tavola. Eliminate i vechji stereotipi, tuttu sarà bè.
È cum'è bonus, in l'ultima versione, avemu l'uppurtunità di fà una chjave di particione arbitraria per fà ogni tipu di operazioni di mantenimentu in partizioni individuali.
Per esempiu, avete bisognu di parechje tavule chjuche, per esempiu, quandu ci hè bisognu di processà qualchi dati intermedii, ricevete chunks è avete bisognu di fà una trasfurmazioni nantu à elli prima di scrive à a tavola finale. Per questu casu, ci hè un maravigliu mutore di table - StripeLog. Hè cum'è TinyLog, solu megliu.
* Avà ClickHouse hà più .
Un altru anti-pattern hè microsharding. Per esempiu, avete bisognu di shard data è avete 5 servitori, è dumane ci saranu 6 servitori. È pensate cumu per riequilibrà sta dati. È invece, ùn site micca split in 5 shards, ma in 1 shards. È dopu mappe ognuna di sti microshards à un servitore separatu. È avete successu in un servitore, per esempiu, 000 ClickHouse, per esempiu. Esempiu separatu nantu à porti separati o basa di dati separati.
Ma in ClickHouse questu ùn hè micca assai bonu. Perchè ancu una istanza di ClickHouse prova d'utilizà tutte e risorse di u servitore dispunibili per processà una dumanda. Questu hè, avete qualchì tipu di servitore è quì, per esempiu, 56 core di processore. Eseguite una dumanda chì dura un secondu è aduprà 56 core. È se avete postu 200 ClickHouses nantu à un servitore quì, allora risulta chì 10 000 fili cumincianu. In generale, tuttu serà assai male.
Un altru mutivu hè chì a distribuzione di u travagliu in questi casi serà ineguale. Qualchidunu finiscinu prima, altri finiranu dopu. Se tuttu questu hè accadutu in un casu, allora ClickHouse stessu averia capitu cumu distribuisce currettamente i dati trà i flussi.
È un altru mutivu hè chì avete a cumunicazione interprocessore nantu à TCP. I dati anu da esse serializatu, deserializatu, è questu hè un gran numaru di microshards. Solu ùn funziona micca.
Un altru antipattern, ancu s'ellu ùn pò micca esse chjamatu antipattern. Questa hè una grande quantità di pre-agregazione.
In generale, a preaggregazione hè bona. Avete avutu un miliardo di fila, l'avete aggregatu è diventatu 1 fila, è avà a dumanda hè eseguita istantaneamente. Tuttu hè grande. Hè cusì chì pudete fà. È per questu, ancu ClickHouse hà un tipu speciale di tavula AggregatingMergeTree chì face aggregazione incrementale cum'è dati sò inseriti.
Ma ci sò i tempi quandu pensate chì avemu da aggregate data cum'è questu è aggregate data cum'è questu. È in qualchì dipartimentu vicinu, ùn vogliu micca dì quale sia, usanu tavule SummingMergeTree per riassume da a chjave primaria, è 20 culonni sò usati cum'è chjave primaria. In casu, aghju cambiatu i nomi di certi culonni per a cuspirazione, ma questu hè.
E tali prublemi sorgi. Prima, a quantità di dati chì avete ùn hè micca ridutta troppu. Per esempiu, hè ridutta da trè volte. Trè volte saria un bonu prezzu per permette l'analitiche illimitate chì vene cun avè dati micca aggregati. Se i dati sò aggregati, allora avete solu statistiche miserable invece di analitiche.
È ciò chì hè particularmente bonu? Chì queste persone da u dipartimentu prossimu, andate è dumandate qualchì volta per aghjunghje una colonna più à a chjave primaria. Questu hè, avemu aggregatu i dati cusì, è avà vulemu un pocu di più. Ma ùn ci hè micca una chjave primaria in ClickHouse. Dunque, avete da scrive qualchi script in C ++. È ùn mi piace micca scripts, ancu s'ellu sò in C++.
E se fighjate per ciò chì ClickHouse hè stata creata, allora i dati non-agregati sò esattamente u scenariu per quale hè natu. Sè vo aduprate ClickHouse per dati micca aggregati, allora fate tuttu bè. Sè vo site aggregate, allora questu hè qualchì volta perdonabile.
Un altru casu interessante hè e dumande in un ciclu infinitu. A volte andu à qualchì servitore di produzzione è fighjulà a lista di processu di mostra quì. È ogni volta chì scopre chì qualcosa di terribili succede.
Per esempiu, quì hè questu. Hè subitu chjaru chì era pussibule di fà tuttu in una dumanda. Basta à scrive l'url è a lista quì.
Perchè parechje tali richieste in un ciclu infinitu male? Se l'indici ùn hè micca utilizatu, allora avete parechje passate nantu à i stessi dati. Ma se un indice hè utilizatu, per esempiu, avete una chjave primaria in ru è scrive url = qualcosa quì. È pensate chì una url serà lettu puntuale da a tavula, tuttu sarà bè. Ma veramente nò. Perchè ClickHouse face tuttu in batch.
Quandu hà bisognu di leghje una certa gamma di dati, leghje un pocu più, perchè l'indici in ClickHouse hè sparse. Stu indice ùn permette micca di truvà una fila individuale in a tavula, solu un tipu di intervallu. È i dati sò cumpressi in blocchi. Per leghje una linea, avete bisognu di piglià tuttu u bloccu è uncompress. È s'è vo eseguite una mansa di dumande, avete assai intersezzione di tali, è avete assai travagliu fattu una volta è più.
È cum'è bonus, pudete vede chì in ClickHouse ùn deve esse paura di trasfiriri ancu megabyte è ancu centinaie di megabytes à a sezione IN. Mi ricordu da a nostra pratica chì se passemu una mansa di valori \u100b\u10in a sezione IN in MySQL, per esempiu, passemu XNUMX megabyte di certi numeri quì, allora MySQL manghja XNUMX gigabyte di memoria è nunda di più succede à it, tuttu funziona male.
È a seconda cosa hè chì in ClickHouse, se e vostre dumande utilizanu un indice, allora ùn hè micca sempre più lento di una scansione completa, vale à dì, se avete bisognu di leghje quasi tutta a tavola, andarà in sequenza è leghje a tavola sana. In generale, ellu capisce.
Tuttavia, ci sò qualchi difficultà. Per esempiu, chì IN cù una subquery ùn usa micca l'indici. Ma questu hè u nostru prublema è avemu bisognu di risolve. Ùn ci hè nunda di fundamentale quì. Facemu *.
È un'altra cosa interessante hè chì s'è vo avete una dumanda assai longa è u prucessu di dumanda distribuitu si passa, allura sta dumanda assai longa serà mandata à ogni servitore senza compressione. Per esempiu, 100 megabytes è 500 servitori. È, per quessa, 50 gigabytes seranu trasferiti nantu à a reta. Ci sarà trasfiruta è poi tuttu sarà eseguitu successu.
* digià aduprà; tuttu era riparatu cum'è prumessu.
È hè abbastanza cumuni se e richieste venenu da l'API. Per esempiu, avete fattu un tipu di serviziu. È se qualchissia hà bisognu di u vostru serviziu, allora avete apertu l'API è literalmente dui ghjorni dopu vi vede chì qualcosa incomprensibile succede. Tuttu hè sovraccaricatu è alcune richieste terribili venenu chì ùn deve mai esse.
È ci hè solu una suluzione. Sè avete apertu l'API, allora vi tuccherà à cutà. Per esempiu, per entre qualchì quota. Ùn ci hè micca altre opzioni ragiunate. Altrimenti, scriveranu immediatamente un script è ci saranu prublemi.
E ClickHouse hà una funzione speciale - questu hè u calculu di quote. Inoltre, pudete trasferisce a vostra chjave di quota. Questu hè, per esempiu, un ID d'utilizatore internu. E quote seranu calculate indipindentamente per ognunu di elli.
Avà un'altra cosa interessante. Questa hè a replicazione manuale.
Cunnoscu parechji casi induve, malgradu ClickHouse avè un supportu di replicazione integratu, a ghjente riplica ClickHouse manualmente.
Chì ghjè u principiu? Avete un pipeline di trattamentu di dati. È travaglia indipindente, per esempiu, in diversi centri di dati. Scrivite i stessi dati in u listessu modu à ClickHouse, cum'è. True, a pratica mostra chì i dati anu sempre diverge per via di qualchi peculiarità in u vostru codice. Spergu chì in u vostru.
È periodicamente avete sempre a sincronizazione manualmente. Per esempiu, una volta à u mese l'amministratori facenu rsync.
In fatti, hè assai più faciule d'utilizà a replicazione integrata in ClickHouse. Ma pò esse qualchì contraindicazione, perchè per questu avete bisognu di utilizà ZooKeeper. Ùn diceraghju nunda di male di ZooKeeper, in principiu, u sistema funziona, ma succede chì a ghjente ùn l'utiliza micca per via di java-fobia, perchè ClickHouse hè un sistema cusì bonu scrittu in C ++ chì pudete aduprà è tuttu sarà bè. È ZooKeeper in java. È in qualchì manera ùn vulete mancu vede, ma poi pudete aduprà a replicazione manuale.
ClickHouse hè un sistema praticu. Piglia in contu i vostri bisogni. Sè vo avete riplicazioni manuali, allura vi ponu creà una tavula Distributed chì sguardi à i vostri rèplichi manuali è faci un failover trà elli. E ci hè ancu una opzione speciale chì vi permette di evità flops, ancu s'è i vostri linii sò sistematicamente divergenti.
In più, ci ponu esse prublemi s'è vo aduprate mutori di table primitive. ClickHouse hè un tali custruttore chì hà una mansa di diversi motori di tabella. Per tutti i casi serii, cum'è scrittu in a documentazione, utilizate tavule di a famiglia MergeTree. È tuttu u restu - questu hè cusì, per casi individuali o per testi.
In una tavola MergeTree, ùn avete micca bisognu di data è ora. Pudete ancu aduprà. Se ùn ci hè micca data è ora, scrivite chì u default hè 2000. Funcionerà è ùn hà micca bisognu di risorse.
È in a nova versione di u servitore, pudete ancu specificà chì avete un particionamentu persunalizatu senza una chjave di partizione. Serà u listessu.
Per d 'altra banda, i mutori di table primitive ponu esse utilizati. Per esempiu, compie i dati una volta è vede, torce è sguassate. Pudete aduprà Log.
O almacenà i picculi volumi per u processu intermediu hè StripeLog o TinyLog.
A memoria pò esse usata s'ellu ci hè una piccula quantità di dati è solu torce qualcosa in a RAM.
ClickHouse ùn piace micca assai dati rinormalizzati.
Eccu un esempiu tipicu. Questu hè un gran numaru di urls. Li mette in a tavola adiacente. E dopu avemu decisu di fà JOIN cun elli, ma questu ùn hà micca travagliatu, in regula, perchè ClickHouse sustene solu Hash JOIN. Se ùn ci hè micca abbastanza RAM per parechje dati cù quale cunnette, allora JOIN ùn funziona micca *.
Se i dati sò di alta cardinalità, allora ùn vi preoccupate, guardate in una forma denormalizzata, l'URL sò direttamente in situ in a tavola principale.
* è avà ClickHouse hà ancu una unione di fusione, è funziona in cundizioni induve i dati intermedi ùn si mette micca in a RAM. Ma questu hè inefficace è a raccomandazione resta valida.
Un paru più esempi, ma aghju digià dubbitu s'ellu sò anti-patterns o micca.
ClickHouse hà un inconveniente cunnisciutu. Ùn sapi micca cumu aghjurnà *. In un certu sensu, questu hè ancu bonu. Sè vo avete qualchi dati impurtanti, per esempiu, cuntabili, allura nimu hà da pudè mandà li, perchè ùn ci hè micca aghjurnamenti.
* U supportu per l'aghjurnamentu è l'eliminazione in u modu batch hè statu longu aghjustatu.
Ma ci sò qualchi modi spiciali chì permettenu l'aghjurnamenti per apparisce in u fondu. Per esempiu, tavule di tipu ReplaceMergeTree. Facenu l'aghjurnamenti durante a fusione di fondo. Pudete furzà questu cù ottimisà a tavola. Ma ùn fate micca troppu spessu, perchè soprascriverà completamente a partizione.
JOIN distribuiti in ClickHouse - questu hè ancu pocu trattatu da u pianificatore di query.
Male, ma qualchì volta bè.
Usendu ClickHouse solu per leghje i dati torna cù select *.
Ùn vi cunsigliu micca di utilizà ClickHouse per calculi voluminosi. Ma questu ùn hè micca cumplettamente veru, perchè avemu digià alluntanatu da sta raccomandazione. È recentemente aghjustatu a capacità di applicà mudelli di apprendimentu di machine in ClickHouse - Catboost. È mi preoccupa, perchè pensu : « Chì orrore. Questu hè quantu ciculi per byte risulta! Hè una pena per mè di inizià i cicli di clock in byte.
Ma ùn àbbia paura, stallà ClickHouse, tuttu sarà bè. Se qualcosa, avemu una cumunità. Per via, a cumunità hè voi. È s'è vo avete qualchì prublema, pudete almenu andà à u nostru chat, è speru chì vi sarà aiutatu.
I vostri dumanni
Grazie per u rapportu! Induve si lamentà di u crash di ClickHouse?
Pudete lagnà à mè personalmente avà.
Recentemente aghju cuminciatu à aduprà ClickHouse. Immediatamente abbandunatu l'interfaccia cli.
Chì puntuazione.
Un pocu dopu, aghju abbandunatu u servitore cù una piccula selezzione.
Avete talentu.
Aghju apertu un bug di GitHub, ma hè statu ignoratu.
Avemu da vede.
Aleksey m'hà ingannatu per assistisce à u rapportu, prumettendu di dirmi cumu si stringhje i dati in l'internu.
Hè assai semprici.
Questu hè ciò chì aghju realizatu ieri. Più specifichi.
Ùn ci sò micca trucchi terribili. Hè solu cumpressione di bloccu per bloccu. U default hè LZ4, pudete attivà ZSTD *. Blocchi da 64 kilobyte à 1 megabyte.
* Ci hè ancu supportu per i codecs di cumpressione specializati chì ponu esse aduprati in catena cù altri algoritmi.
Sò i blocchi solu dati crudi?
Micca esattamente crudu. Ci sò arrays. Se tenete una colonna numerica, allora i numeri in una fila sò stacked in un array.
Hè chjaru.
Alexey, un esempiu chì era cun uniqExact over IPs, vale à dì u fattu chì uniqExact dura più di cuntà per stringhe chì per numeri, è cusì. E s'è applicàmu una finta cù l'arechje è cast à u mumentu di a correzzione ? Questu hè, pare chì avete dettu chì ùn hè micca assai diffirenti nantu à u discu. Sè avemu leghje linii da u discu, cast, allura avemu aggregates più veloce o micca? O semu sempre guadagnà marginalmente quì? Mi pare chì l'avete pruvatu, ma per una certa ragione ùn l'hà micca indicatu in u benchmark.
Pensu chì serà più lento chè nisun cast. In questu casu, l'indirizzu IP deve esse analizatu da a stringa. Di sicuru, in ClickHouse, l'analisi di l'indirizzu IP hè ancu ottimizatu. Avemu pruvatu assai duru, ma in u stessu locu avete i numeri scritti in forma di decimila. Assai scomodu. Per d 'altra banda, a funzione uniqExact hà da travaglià più lenta nantu à e corde, micca solu perchè queste sò corde, ma ancu perchè una spicializazioni differenti di l'algoritmu hè sceltu. I stringi sò solu trattati in modu diversu.
E si pigliamu un tipu di dati più primitivu? Per esempiu, anu scrittu l'identificatore di l'utilizatore chì avemu in, l'anu scrittu cum'è una linea, è poi chjappà, serà più divertente o micca?
I dubbitu. Pensu chì serà ancu più tristu, perchè dopu tuttu, l'analisi di numeri hè un prublema seriu. Mi pare chì stu cullega hà ancu avutu un rapportu nantu à quantu hè difficiule di analizà numeri in decimila, ma forse micca.
Alexey, grazie assai per u rapportu! È ti ringraziu assai per ClickHouse! Aghju una quistione nantu à i piani. Ci hè una funzione in i piani per aghjurnà i dizionari incompletamente?
vale à dì un reboot parziale?
Iè Iè. Cum'è l'abilità di stabilisce un campu di MySQL quì, vale à dì aghjurnà dopu in modu chì solu questi dati sò caricati se u dizziunariu hè assai grande.
Funzione assai interessante. È, mi pare, una persona l'hà suggeritu in u nostru chat. Forse era ancu voi.
Ùn pensu micca cusì.
Grande, avà risulta chì duie dumande. È pudete cumincià à fà lentamente. Ma vogliu avvistà subitu chì sta funzione hè abbastanza simplice di implementà. Questu hè, in teoria, basta à scrive u numeru di versione in a tavula è dopu scrive: a versione hè menu di tali è cusì. È questu significa chì, assai prubabilmente, l'avemu da offre à l'amatori. Sò un entusiasta ?
Iè, ma sfurtunatamenti micca in C++.
I vostri culleghi ponu scrive in C++?
Truveraghju qualcunu.
Perfettu*.
* a funzione hè stata aghjunta dui mesi dopu à u rapportu - hè stata sviluppata da l'autore di a quistione è sottumessa da u so .
Grazie!
Bonghjornu! Grazie per u rapportu! Avete mintuatu chì ClickHouse cunsuma tutte e risorse dispunibuli assai bè. È u parlante vicinu à Luxoft hà parlatu di a so decisione per u Postu Russu. Ellu disse chì li piacia assai ClickHouse, ma ùn l'anu micca utilizatu invece di u so cuncurrente principale precisamente perchè manghja tuttu u processatore. È ùn pudianu mette in a so architettura, in u so ZooKeeper cù dockers. Hè pussibule limità in qualchì manera ClickHouse per ùn cunsumà micca tuttu ciò chì hè dispunibule per ellu?
Iè, hè pussibule è assai faciule. Se vulete cunsumà menu core, allora scrivite set max_threads = 1. È questu hè tuttu, eseguirà a dumanda in un core. Inoltre, pudete specificà diverse paràmetri per diversi utilizatori. Allora ùn hè micca prublema. E dite à i vostri culleghi di Luxoft chì ùn hè micca bè chì ùn anu micca truvatu questu paràmetru in a documentazione.
Alexey, salutu! Vogliu fà sta quistione. Questa ùn hè micca a prima volta chì aghju intesu chì parechje persone cumincianu à utilizà ClickHouse cum'è repository per i logs. À u rapportu, avete dettu di ùn fà micca questu, vale à dì chì ùn avete micca bisognu di almacenà linee longu. Chì ne pensate ?
Prima, i logs sò generalmente micca longu fila. Ci sò, sicuru, eccezzioni. Per esempiu, qualchì serviziu scrittu in java tira una eccezzioni, hè registratu. È cusì in un ciclu infinitu, è scappendu u spaziu di u discu duru. A suluzione hè assai sèmplice. Sì i linii sò assai longu, allora tagliate. Chì significa longu? Decine di kilobyte hè male *.
* in e versioni recenti di ClickHouse, a "granularità adattativa di l'indici" hè attivata, chì elimina u prublema di almacenà stringhe longu per a maiò parte.
Hè un kilobyte normale?
Okay
Bonghjornu! Grazie per u rapportu! Aghju digià dumandatu nantu à questu in u chat, ma ùn mi ricordu micca s'ellu aghju ricevutu una risposta. Ci hè un pianu per allargà a sezione WITH in una moda CTE?
Ancu micca. A sezione WITH hè un pocu frivola. Hè cum'è una piccula funzione per noi.
Capiscu. Grazie!
Grazie per u rapportu! Moltu interessante! question globale. Hè previstu di fà, forsi in a forma di qualchì tipu di stubs, mudificazione di a cancellazione di dati?
Necessariamente. Questu hè u nostru primu compitu in a nostra fila. Avà pensemu attivamente à cumu fà tuttu bè. È duvete principià à appughjà u teclatu *.
* pressatu i buttoni di u teclatu è tuttu hè statu fattu.
Affetterà in qualche manera u rendiment di u sistema o micca? L'inserimentu serà cusì veloce cum'è avà?
Forsi i sguassati stessi, l'aghjurnamenti stessi seranu assai pisanti, ma questu ùn hà micca affettatu a prestazione di selezzione è a prestazione di inseriti in ogni modu.
È una altra piccula quistione. À a presentazione, avete parlatu di a chjave primaria. In cunsiquenza, avemu a partizione, chì hè mensuale per difettu, nò? È quandu avemu stabilitu un intervallu di data chì si mette in un mese, allora leghjemu solu sta partizione, nò?
Sì.
Una quistione. Se ùn pudemu micca selezziunà alcuna chjave primaria, allora hè ghjustu di fà esattamente da u campu "Data" in modu chì in u fondu ci hè una ristrutturazione più chjuca di sta dati per ch'elli si mettenu in una manera più ordinata? Se ùn avete micca e dumande di intervallu è ùn pudete ancu selezziunà alcuna chjave primaria, vale a pena mette una data in a chjave primaria?
Sì.
Forsi hè sensu di mette in a chjave primaria un campu da quale i dati seranu megliu cumpressi si sò ordinati da stu campu. Per esempiu, ID d'utilizatore. User, per esempiu, vai à u listessu situ. In questu casu, mette l'ID di l'utilizatore è u tempu. È tandu i vostri dati seranu megliu cumpressu. In quantu à a data, s'ellu ùn avete micca veramente è ùn avete mai dumande di intervallu nantu à e date, ùn pudete micca mette a data in a chjave primaria.
OK ti ringraziu assai!
Source: www.habr.com