A l'abril, els enginyers d'Avito es van reunir per a reunions en línia amb Alexey Milovidov, el desenvolupador principal de ClickHouse, i Kirill Shvakov, un desenvolupador de Golang d'Integros. Hem comentat com fem servir el sistema de gestió de bases de dades i quines dificultats ens enfrontem.
A partir de la reunió, hem elaborat un article amb les respostes dels experts a les nostres preguntes i del públic sobre còpies de seguretat, redistribució de dades, diccionaris externs, el controlador Golang i les actualitzacions de la versió de ClickHouse. Pot ser útil per als desenvolupadors que ja estan treballant activament amb el SGBD Yandex i estan interessats en el seu present i futur. Les respostes d'Aleksey Milovidov per defecte, tret que s'indiqui el contrari.
Compte, hi ha molt de text sota el tall. Esperem que el contingut amb preguntes us ajudi a navegar.
Contingut
Si no voleu llegir el text, podeu veure l'enregistrament de les tertúlies . Les marques de temps es troben al primer comentari a sota del vídeo.
ClickHouse s'actualitza constantment, però les nostres dades no. Què fer-hi?
ClickHouse s'actualitza constantment i les nostres dades que s'han processat per optimize final no s'actualitzen i es troben en una còpia de seguretat.
Suposem que hem tingut algun tipus de problema i les dades s'han perdut. Vam decidir restaurar i va resultar que les particions antigues, que s'emmagatzemen als servidors de còpia de seguretat, són molt diferents de la versió de ClickHouse que s'utilitza actualment. Què fer en una situació així, i és possible?
La situació en què heu restaurat les dades d'una còpia de seguretat en el format antic, però a la versió nova no estan connectades, és impossible. Ens assegurem que el format de dades a ClickHouse sempre segueixi sent compatible enrere. Això és molt més important que la compatibilitat enrere en la funcionalitat si el comportament d'alguna funció que s'utilitza rarament ha canviat. Les dades que s'emmagatzemen al disc, la nova versió de ClickHouse sempre haurien de poder llegir-les. Aquesta és la llei.
Quines són les pràctiques recomanades actuals per fer una còpia de seguretat de les dades de ClickHouse?
Com fer còpies de seguretat, tenint en compte que tenim optimitzar les operacions finals, una enorme base de dades de terabytes i dades que s'actualitzen, diguem-ne, durant els darrers tres dies, i després no els passa cap tràmit?
Podem elaborar la nostra pròpia solució i escriure al cap: recollir aquestes còpies de seguretat de tal i tal manera. Potser no cal que agafeu res, i la bicicleta es va inventar fa molt de temps?
Comencem amb les millors pràctiques. Els meus companys sempre aconsellen en resposta a preguntes sobre còpies de seguretat per recordar-los el servei Yandex.Cloud, on aquesta tasca ja s'ha resolt. Així que utilitzeu-lo si és possible.
No hi ha una solució completa, cent per cent integrada a ClickHouse, per a les còpies de seguretat. Hi ha alguns espais en blanc que podeu utilitzar. Per obtenir una solució completa, haureu de retocar una mica manualment o fer embolcalls en forma de scripts.
Començaré per les solucions més senzilles i acabaré amb les més sofisticades, depenent de la quantitat de dades i la mida del clúster. Com més gran és el clúster, més difícil serà la solució.
Si la taula de dades ocupa només uns quants gigabytes, la còpia de seguretat es pot fer així:
- Desa la definició de les taules, és a dir, les metadades − mostrar crear taula.
- Feu un abocador mitjançant el client ClickHouse − select * de la taula arxivar. De manera predeterminada, rebràs un fitxer en format TabSeparated. Si voleu ser més eficient, podeu utilitzar el format natiu.
Si la quantitat de dades és més gran, la còpia de seguretat trigarà més temps i molt espai. Això s'anomena còpia de seguretat lògica, no està lligada al format de dades ClickHouse. Si és així, amb un pessic podeu fer una còpia de seguretat i carregar-la a MySQL per a la recuperació.
Per a casos més avançats, ClickHouse té una capacitat integrada per crear una instantània de les particions al sistema de fitxers local. Aquesta funció està disponible com a sol·licitud. altera la partició de congelació de la taula. O simplement alterar la congelació de la taula és una instantània de tota la taula.
La instantània es crearà coherent per a una taula en un fragment, és a dir, és impossible crear una instantània coherent de tot el clúster d'aquesta manera. Però per a la majoria de tasques, no hi ha aquesta necessitat, i n'hi ha prou amb executar una sol·licitud a cada fragment i obtenir una instantània coherent. Es crea en forma d'enllaços durs i, per tant, no ocupa espai addicional. A continuació, copieu aquesta instantània al servidor de còpia de seguretat o a l'emmagatzematge que feu servir per fer còpies de seguretat.
Restaurar una còpia de seguretat d'aquest tipus és bastant fàcil. Primer, creeu taules segons les definicions de taules existents. A continuació, copieu les instantànies de partició desades a Directory-Detached per a aquestes taules i executeu la consulta adjuntar partició. Aquesta solució és molt adequada per a les quantitats de dades més greus.
De vegades necessiteu alguna cosa encara més genial, en els casos en què teniu desenes o fins i tot centenars de terabytes a cada servidor i centenars de servidors. Aquí hi ha una solució que vaig espiar dels companys de Yandex.Metrica. No el recomanaria a tothom: llegiu-lo i decidiu si és adequat o no.
Primer heu de crear diversos servidors amb prestatgeries de disc grans. A continuació, aixequeu diversos servidors ClickHouse en aquests servidors i configureu-los perquè funcionin com una altra rèplica per als mateixos fragments. A continuació, utilitzeu el sistema de fitxers d'aquests servidors o alguna eina que us permeti crear instantànies. Aquí hi ha dues opcions. La primera opció són instantànies LVM, la segona opció és ZFS a Linux.
Després d'això, cada dia necessiteu crear una instantània, s'assentarà i ocuparà una mica d'espai. Naturalment, si les dades canvien, amb el temps la quantitat d'espai augmentarà. Podeu obtenir aquesta instantània en qualsevol moment i restaurar les dades, una decisió tan estranya. A més, encara cal limitar aquestes rèpliques a la configuració perquè no intentin convertir-se en líders.
Serà possible organitzar una acumulació controlada de rèpliques als eixos?
Aquest any teniu previst fer eixos a ClickHouse. Serà possible organitzar-hi una acumulació controlada de rèpliques? Ens agradaria utilitzar-lo per protegir-nos d'escenaris negatius amb alteracions i altres canvis.
És possible fer algun tipus de retrocés per a alteracions? Per exemple, en un eix existent, preneu i digueu que fins aquest moment, apliqueu els canvis, i a partir d'aquest moment, deixeu d'aplicar els canvis?
Si una ordre arriba al nostre clúster i la trenca, tenim una rèplica condicional amb un retard d'una hora, on podem dir que l'utilitzem en aquest moment, però no hi aplicarem els canvis durant els darrers deu minuts?
Per començar, sobre l'endarreriment controlat de rèpliques. Hi va haver una sol·licitud d'aquest tipus per part dels usuaris i vam crear un problema a Github amb una sol·licitud: "Si algú ho necessita, posa un m'agrada, posa un cor". Ningú va apostar, i el tema estava tancat. Tanmateix, ja podeu obtenir aquesta oportunitat configurant ClickHouse. És cert, només a partir de la versió 20.3.
ClickHouse fusiona constantment les dades en segon pla - combina. Quan es fa una fusió, un conjunt de fragments de dades es substitueix per un tros més gran. Al mateix temps, les dades que hi havia abans continuen romanent al disc durant un temps.
En primer lloc, es continuen emmagatzemant mentre hi hagi consultes selectes que les utilitzin, per tal de garantir un funcionament no bloquejador. Les sol·licituds seleccionades es llegeixen en silenci dels fragments antics.
En segon lloc, també hi ha un llindar de temps: dades antigues es troben al disc durant vuit minuts. Aquests vuit minuts es poden personalitzar i convertir fins i tot en un dia. Això costarà espai al disc: depenent del flux de dades, resultarà que durant l'últim dia les dades no només es duplicaran, sinó que poden arribar a ser cinc vegades més. Però en cas d'un problema greu, podeu aturar el servidor ClickHouse i fer front a tot.
Ara la pregunta és com protegeix això dels alteracions. Val la pena mirar més a fons aquí, perquè en versions anteriors de ClickHouse, l'alter funcionava de tal manera que simplement canviava directament les peces. Hi ha una dada amb alguns fitxers, i nosaltres, per exemple, altera la columna de gota. Aleshores, aquesta columna s'elimina físicament de tots els trossos.
Però des de la versió 20.3, el mecanisme d'alteració s'ha canviat completament i ara els fragments de dades són sempre immutables. No canvien en absolut; ara els alteracions funcionen de la mateixa manera que les fusions. En lloc de canviar una peça al seu lloc, en creem una de nova. En el nou fragment, els fitxers que no han canviat es converteixen en enllaços durs i, si suprimim una columna, simplement faltarà al nou fragment. La peça antiga s'eliminarà de manera predeterminada després de vuit minuts, i aquí podeu modificar la configuració esmentada anteriorment.
El mateix passa amb els alteracions com les mutacions. Quan ho fas altera la supressió o alterar l'actualització, no canvia la peça, sinó que en crea una de nova. I després esborra l'antic.
Què passa si l'estructura de la taula ha canviat?
Com crear una còpia de seguretat que es va fer amb l'antic esquema? I la segona pregunta és sobre el cas de les instantànies i les eines del sistema de fitxers. Btrfs és adequat aquí en lloc de ZFS a Linux LVM?
Si ho fas adjuntar partició particions amb una estructura diferent, llavors ClickHouse us dirà que això no és possible. La solució és aquesta. El primer és crear una taula temporal del tipus MergeTree amb l'estructura antiga, adjuntar-hi dades mitjançant attach i emetre una consulta d'alteració. A continuació, podeu copiar o transferir aquestes dades i adjuntar-les de nou, o bé utilitzar la consulta altera la taula mou la partició.
Ara la segona pregunta és si és possible utilitzar Btrfs. Per començar, si teniu LVM, les instantànies de LVM són suficients i el sistema de fitxers pot ser ext4, no importa. Amb Btrts, tot depèn de la vostra experiència amb ell. Aquest és un sistema de fitxers madur, però encara hi ha algunes sospites sobre com funcionarà tot a la pràctica en un escenari concret. No recomanaria utilitzar-lo tret que tingueu Btrfs en producció.
Quines són les millors pràctiques actuals per a la redistribució de dades?
La qüestió de la redistribució és complexa i polièdrica. Aquí podeu respondre diverses opcions alhora. Podeu entrar des d'un costat i dir això: no hi ha cap opció de redistribució integrada a ClickHouse. Però em temo que aquesta resposta no convé a ningú. Per tant, podeu anar des de l'altre costat i dir que ClickHouse té moltes maneres de redistribuir les dades.
Si el clúster es queda sense espai o no pot gestionar la càrrega, afegiu servidors nous. Però aquests servidors estan buits per defecte, no hi ha dades, no hi ha càrrega. Heu de canviar les dades perquè es reparteixin de manera uniforme pel nou clúster més gran.
La primera manera de fer-ho és copiar part de les particions a nous servidors mitjançant la consulta altera la partició de recuperació de la taula. Per exemple, teníeu particions per mesos i agafeu el primer mes del 2017 i el copieu a un servidor nou i després copieu el tercer mes a un altre servidor nou. I així ho fas fins que es torna més o menys uniforme.
La transferència només es pot realitzar per a aquelles particions que no canvien durant la gravació. Per a particions noves, s'haurà de desactivar l'escriptura, perquè la seva transferència no és atòmica. En cas contrari, acabareu amb duplicats o buits a les dades. Tanmateix, aquest mètode és pràctic i funciona amb força eficàcia. Les particions comprimides ja fetes es transmeten per la xarxa, és a dir, les dades no es comprimeixen ni es recodifiquen.
Aquest mètode té un inconvenient i depèn de l'esquema de fragmentació, si us heu compromès a aquest esquema de fragmentació, quina clau de fragmentació teníeu. En el vostre exemple per al cas de les mètriques, la clau de fragmentació és un hash del camí. Quan seleccioneu una taula distribuïda, aquesta va a tots els fragments del clúster alhora i agafa dades d'allà.
Això vol dir que en realitat no us importa quines dades acaben en quin fragment. El més important és que les dades d'un camí acaben en un fragment, però quin no és important. En aquest cas, la transferència de particions ja fetes és perfecta, ja que amb consultes seleccionades, també rebrà dades completes, tant abans de la redistribució com després, l'esquema no importa realment.
Però hi ha casos que són més complicats. Si a nivell de lògica de l'aplicació confieu en un esquema de fragmentació especial, aquest client es troba en tal o tal fragment, i la sol·licitud es pot enviar immediatament allà i no a la taula distribuïda. O utilitzeu una versió bastant recent de ClickHouse i heu activat la configuració optimitzar saltar fragments no utilitzats. En aquest cas, durant la consulta de selecció, s'analitzarà l'expressió de la secció on i es calcularà a quins fragments s'ha d'anar segons l'esquema de fragmentació. Això funciona sempre que les dades es descomposin exactament d'acord amb aquest esquema de fragmentació. Si els heu canviat manualment, la correspondència pot canviar.
Així que aquesta és la manera número u. I estic esperant la teva resposta, és el mètode adequat o segueix endavant.
Vladimir Kolobaev, administrador principal del sistema a Avito: Alexey, el mètode que has esmentat no encaixa gaire bé quan necessites repartir la càrrega, inclosa la lectura. Podem agafar una partició que sigui mensual i podem portar el mes anterior a un altre node, però quan arribi una sol·licitud d'aquestes dades, només les carregarem. Però m'agradaria carregar tot el clúster, perquè, en cas contrari, durant algun temps, tota la càrrega de lectura serà processada per dos fragments.
Alexei Milovidov: La resposta aquí és estranya: sí, és dolenta, però pot funcionar. T'explicaré exactament com. Val la pena mirar l'escenari de càrrega que inclou les vostres dades. Si es tracta de dades de seguiment, és gairebé segur que la gran majoria de les sol·licituds són de dades noves.
Heu instal·lat nous servidors, heu migrat particions antigues, però també heu canviat com s'escriuen les dades noves. I les dades noves es repartiran per tot el clúster. Així, després de cinc minuts, les sol·licituds dels últims cinc minuts carregaran el clúster de manera uniforme, després d'un dia, les sol·licituds d'un dia carregaran el clúster de manera uniforme. I les sol·licituds del mes anterior, malauradament, només aniran a una part dels servidors del clúster.
Però sovint no tindreu sol·licituds per al febrer de 2019. El més probable és que si les sol·licituds arriben al 2019, seran per a tot el 2019, durant un interval de temps gran i no per a un interval petit. I aquestes sol·licituds també podran carregar el clúster de manera uniforme. Però, en general, la teva observació és força correcta que es tracta d'una solució ad hoc que no distribueix les dades de manera completament uniforme.
Tinc uns quants punts més per respondre la pregunta. Un d'ells tracta de com fer inicialment l'esquema de fragmentació de manera que hi hagi menys dolor per la reestructuració. Això no sempre és possible.
Per exemple, teniu dades de seguiment. Les dades de seguiment creixen per tres motius. El primer és l'acumulació de dades històriques. El segon és el creixement del trànsit. I el tercer és un augment del nombre de coses que estan subjectes a seguiment. Hi ha nous microserveis i mètriques que cal desar.
És possible que d'aquests, l'augment més gran es degui a la tercera raó: aquest és un augment de l'ús del seguiment. I en aquest cas, val la pena mirar la naturalesa de la càrrega, quines són les principals peticions de selecció. És probable que les principals consultes de selecció segueixin algun subconjunt de mètriques.
Per exemple, l'ús de la CPU en alguns servidors per part d'algun servei. Resulta que hi ha un subconjunt de claus amb les quals obteniu aquestes dades. I és probable que la sol·licitud d'aquestes dades sigui bastant senzilla i s'executi en desenes de mil·lisegons. S'utilitza per a serveis de monitorització, per a taulers. Espero entendre això correctament.
Vladimir Kolobaev: El cas és que sovint apel·lem a dades històriques, ja que comparem la posició actual amb la històrica en temps real. I és important per a nosaltres tenir accés ràpid a una gran quantitat de dades, i ClickHouse fa un gran treball amb això.
Tens tota la raó, la majoria de les sol·licituds de lectura que experimentem l'últim dia, com qualsevol sistema de seguiment. Però, al mateix temps, la càrrega de dades històriques també és força gran. Prové principalment d'un sistema d'alerta que passa cada trenta segons i diu a ClickHouse: "Dóna'm les dades de les últimes sis setmanes. I ara feu-me una mica de mitjana mòbil i comparem el valor actual amb el valor històric.
M'agradaria dir que per a sol·licituds tan fresques tenim una altra taula petita en la qual només emmagatzemem dos dies de dades, i les sol·licituds principals hi volen. Només enviem grans consultes històriques a una taula fragmentada gran.
Alexei Milovidov: Malauradament, resulta ser poc aplicable al vostre escenari, però descriuré dos esquemes de fragmentació dolents i complexos que no s'han d'utilitzar, però que s'utilitzen al servei d'amics.
Hi ha un clúster principal amb esdeveniments Yandex.Metrics. Els esdeveniments són pàgines vistes, clics i transicions. La majoria de les sol·licituds van a un lloc web específic. Obriu el servei Yandex.Metrica, teniu un lloc web: avito.ru, aneu a l'informe i es fa una sol·licitud per al vostre lloc web.
Però hi ha altres peticions, analítiques i globals, que fan els analistes interns. Per si de cas, observo que els analistes interns només fan sol·licituds per als serveis Yandex. Tanmateix, fins i tot els serveis Yandex ocupen una part important de totes les dades. Es tracta de sol·licituds no per a comptadors específics, sinó per a un filtratge més ampli.
Com organitzar les dades de manera que tot funcioni de manera eficient per a un comptador i també per a consultes globals? Una altra dificultat rau en el fet que el nombre de sol·licituds a ClickHouse per al clúster Metrics és de diversos milers per segon. Al mateix temps, un servidor ClickHouse no gestiona sol·licituds no trivials, per exemple, diversos milers per segon.
La mida del clúster és de sis-cents servidors. Si simplement estireu una taula distribuïda sobre aquest clúster i envieu-hi diversos milers de sol·licituds, serà encara pitjor que enviar-les a un servidor. D'altra banda, l'opció que les dades es distribueixin de manera uniforme, i anem a demanar des de tots els servidors, es descarta immediatament.
Hi ha una opció diametralment oposada. Imagineu-vos si dividim les dades per lloc i una sol·licitud d'un lloc va a un fragment. Ara el clúster podrà extreure deu mil sol·licituds per segon, però en un fragment una sol·licitud funcionarà massa lentament. Ja no augmentarà l'ample de banda. Sobretot si es tracta d'un lloc avito.ru. No revelaré cap secret si dic que Avito és un dels llocs més visitats de Runet. I processar-lo en un fragment seria una bogeria.
Per tant, l'esquema de fragmentació s'organitza d'una manera més complicada. Tot el clúster està dividit en una sèrie de clústers, que anomenem capes. Dins de cada cúmul hi ha de deu a diverses dotzenes de fragments. Hi ha trenta-nou clústers d'aquest tipus en total.
Com s'escala tot? El nombre de clústers no canvia: com fa trenta-nou anys, es manté igual. Però dins de cadascun d'ells, anem augmentant gradualment el nombre de fragments a mesura que s'acumulen les dades. I l'esquema de fragmentació en conjunt és aquest: la divisió en aquests clústers es fa per llocs web i, per entendre quin lloc es troba en quin clúster, generalment s'utilitza una metabase separada a MySQL. Un lloc - en un clúster. I en el seu interior es produeix el fragmentació segons els identificadors dels visitants.
Quan enregistrem, els dividim per la resta de l'identificador del visitant. Però quan s'afegeix un fragment nou, l'esquema de fragmentació canvia, continuem dividint, però amb la resta de dividir per un altre nombre. Això vol dir que un visitant ja es troba en diversos servidors i no hi podeu apostar. Això es fa únicament per garantir que les dades estiguin millor comprimides. I quan fem una consulta, anem a la taula Distribuïda, que mira el clúster i accedeix a desenes de servidors. Aquest és un esquema tan estúpid.
Però la meva història serà incompleta si no dic que hem abandonat aquest esquema. En el nou esquema, ho vam canviar tot i vam copiar totes les dades amb clickhouse-copier.
En el nou esquema, tots els llocs es divideixen en dues categories: grans i petits. No sé com es va triar el llindar allà, però com a resultat, va resultar que els llocs grans es registren en un clúster, on hi ha 120 fragments amb tres rèpliques a cadascun, és a dir, 360 servidors. I l'esquema de fragmentació és tal que qualsevol sol·licitud va a tots els fragments alhora. Si ara obriu qualsevol pàgina d'informes per a avito.ru a Yandex.Metrica, la sol·licitud anirà a 120 servidors. Hi ha pocs llocs grans a Runet. I les peticions no són mil per segon, sinó fins i tot menys de cent. Tot això és mastegat tranquil·lament per la taula Distribuïda, que cadascun d'ells processa 120 servidors.
I el segon clúster és per a llocs petits. Aquí hi ha un esquema de fragmentació per identificador del lloc i cada sol·licitud va a exactament un fragment.
ClickHouse té una utilitat de copiadora clickhouse. Pots parlar d'ella?
He de dir de seguida que aquesta solució és més feixuga i una mica menys productiva. L'avantatge és que esborra les dades completament segons l'esquema que especifiqueu. Però el desavantatge de la utilitat és que no es torna a dur a terme en absolut. Copia dades d'un esquema de clúster a un altre esquema de clúster.
Això vol dir que perquè funcioni, heu de tenir dos clústers. Es poden localitzar als mateixos servidors, però, tanmateix, les dades no es mouran de manera incremental, sinó que es copiaran.
Per exemple, hi havia quatre servidors, ara n'hi ha vuit. Creeu una taula distribuïda nova a tots els servidors, taules locals noves i inicieu clickhouse-copier, especificant-hi l'esquema de treball que hauria de llegir des d'allà, acceptar el nou esquema de fragmentació i transferir-hi dades. I necessitareu una vegada i mitja més espai als servidors antics que el que teniu ara, perquè les dades antigues han de romandre en ells, i la meitat de les mateixes dades antigues se'ls hi aniran a sobre. Si heu pensat per endavant que les dades s'han de tornar a repartir i hi ha espai, aquest mètode és adequat.
Com funciona la fotocopiadora clickhouse dins? Desglossa tot el treball en un conjunt de tasques per processar una partició d'una taula en un fragment. Totes aquestes tasques es poden executar en paral·lel, i clickhouse-copier pot executar diverses instàncies en màquines diferents, però el que fa per a una sola partició no és més que una selecció d'inserció. Les dades es llegeixen, es descomprimeixen, es reparticionen, es comprimeixen de nou, s'escriuen en algun lloc i es tornen a ordenar. Aquesta és una decisió més difícil.
Teniu una cosa pilot que es diu resharding. Què passa amb ella?
L'any 2017, vau tenir una cosa pilot anomenada resharding. Fins i tot hi ha una opció a ClickHouse. Entenc que no es va enlairar. Pots dir per què va passar? Sembla que és molt rellevant.
Tot el problema és que si necessiteu redistribuir les dades al seu lloc, cal una sincronització molt complexa per fer-ho atòmicament. Quan vam començar a veure com funciona aquesta sincronització, va quedar clar que hi ha problemes fonamentals. I aquests problemes fonamentals no només són teòrics, sinó que immediatament van començar a mostrar-se a la pràctica en forma d'alguna cosa que es pot explicar de manera molt senzilla: res funciona.
És possible combinar totes les parts de les dades abans de passar a discs lents?
Una pregunta sobre TTL amb l'opció de moure a disc lent en el context de les fusions. Hi ha una altra manera que cron per combinar totes les parts en una abans de passar a discs lents?
La resposta a la pregunta de si és possible enganxar d'alguna manera automàticament totes les peces en una abans de transferir-les és no. Em sembla que això no és necessari. No podeu combinar totes les parts en una, sinó que simplement confieu en el fet que es transferiran automàticament als discos lents.
Tenim dos criteris per a les normes de transferència. El primer és a mesura que s'omple. Si el nivell d'emmagatzematge actual té menys d'un determinat percentatge d'espai lliure, seleccionem un tros i el traslladem a un emmagatzematge més lent. O millor dit, no més lent, sinó el següent: com ho configureu.
El segon criteri és la mida. Parla del trasllat de peces grans. Podeu ajustar el llindar en funció de l'espai lliure en un disc ràpid i les dades es migraran automàticament.
Com migrar a noves versions de ClickHouse si no hi ha manera de comprovar la compatibilitat amb antelació?
Aquest tema es parla regularment tenint en compte diferents versions, i tanmateix. Què tan segur és actualitzar de la versió 19.11 a la 19.16 i, per exemple, de la 19.16 a la 20.3. Quina és la millor manera de passar a les noves versions sense poder comprovar la compatibilitat amb el sandbox per endavant?
Aquí hi ha algunes regles d'or. Primer - . És gran, però hi ha punts separats sobre canvis incompatibles cap enrere. No tracteu aquests articles com una bandera vermella. Normalment són incompatibilitats menors relacionades amb alguna funcionalitat de punta que probablement no utilitzeu.
En segon lloc, si no hi ha manera de comprovar la compatibilitat a la caixa de proves i voleu actualitzar immediatament en producció, la recomanació és que no cal que ho feu. Primer creeu una caixa de sorra i proveu. Si no hi ha un entorn de prova, és probable que no tingueu una empresa molt gran, el que significa que podeu copiar algunes de les dades al vostre ordinador portàtil i assegurar-vos que tot funcioni correctament. Fins i tot podeu mostrar algunes rèpliques localment a la vostra màquina. O podeu crear una versió nova en algun lloc proper i penjar-hi algunes dades, és a dir, crear un entorn de prova improvisat.
Una altra regla és no actualitzar-se durant una setmana després del llançament de la versió a causa d'errors de producció i correccions ràpides posteriors. Entenem la numeració de la versió de ClickHouse per no confondre'ns.
Hi ha la versió 20.3.4. El número 20 indica l'any de fabricació - 2020. Des del punt de vista del que hi ha dins, això no importa, així que no hi farem cas. A més - 20.3. El segon nombre -en aquest cas 3- l'augmentem cada vegada que publiquem una versió amb alguna funcionalitat nova. Si volem afegir alguna característica a ClickHouse, haurem d'augmentar aquest nombre. És a dir, a la versió 20.4 ClickHouse funcionarà encara millor. El tercer dígit és 20.3.4. Aquí 4 és el nombre de llançaments de pedaços en què no hem afegit funcions noves, però hem corregit alguns errors. I 4 vol dir que ho hem fet quatre vegades.
No us penseu que és una cosa terrible. En general, l'usuari pot instal·lar la darrera versió i funcionarà sense cap problema amb el temps d'activitat per any. Però imagineu-vos que en alguna funció de processament de mapes de bits, que van afegir els nostres companys xinesos, en passar arguments incorrectes, el servidor es bloqueja. Això ho hem d'arreglar. Llançarem una nova versió del pedaç i ClickHouse serà més estable.
Si teniu ClickHouse treballant en producció i es publica una nova versió de ClickHouse amb funcions addicionals, per exemple, la 20.4.1 és la primera, no us preneu a posar-la en producció el primer dia. Per què és necessària? Si encara no feu servir ClickHouse, podeu instal·lar-lo i, molt probablement, tot anirà bé. Però si ClickHouse ja funciona de manera estable, estigueu atents als pegats i actualitzacions: quins problemes solucionem.
Kirill Shvakov: Vull afegir una mica sobre els entorns de prova. Tothom té molta por dels entorns de prova i, per alguna raó, creu que si teniu un clúster ClickHouse molt gran, l'entorn de prova no hauria de ser més petit o almenys deu vegades més petit. No és gens així.
Ho puc dir amb el meu exemple. Tinc un projecte i hi ha ClickHouse. El nostre entorn de prova per a ell és una petita màquina virtual a Hetzner per vint euros, on es desplega absolutament tot. Per fer-ho, tenim una automatització completa a Ansible i, per tant, en principi, no hi ha cap diferència on rodar: en servidors de ferro o simplement en màquines virtuals.
Què es pot fer? Seria bo fer un exemple a la documentació de ClickHouse sobre com desplegar un petit clúster pel vostre compte: a Docker, a LXC, potser creeu un llibre de jugades Ansible, perquè diferents persones tenen diferents desplegaments. Això facilitarà moltes coses. Quan agafeu i desplegueu un clúster en cinc minuts, és molt més fàcil intentar esbrinar alguna cosa. És molt més convenient d'aquesta manera, perquè posar en producció una versió que no heu provat és un camí cap al no-res. De vegades funciona i de vegades no. I, per tant, esperar l'èxit és dolent.
Maxim Kotyakov, enginyer sènior de backend Avito: Afegiré una mica sobre entorns de prova d'una sèrie de problemes per a grans empreses. Tenim un clúster d'acceptació de ClickHouse complet, segons els esquemes de dades i la configuració, una còpia exacta del que està en producció. Aquest clúster es desplega en contenidors bastant podrits amb un mínim de recursos. Escrivim allà un cert percentatge de les dades de producció, ja que hi ha l'oportunitat de replicar el flux a Kafka. Tot està sincronitzat i escalat allà, tant en termes de capacitat com de flux, i, en teoria, en igualtat de coses, hauria de comportar-se com una producció en termes de mètriques. Tot allò potencialment explosiu s'enrotlla primer a aquest estand i s'infusiona allà durant diversos dies fins que estigui llest. Però, per descomptat, aquesta solució és cara, pesada i amb costos de suport diferents de zero.
Alexei Milovidov: Us explicaré com és l'entorn de prova dels nostres amics de Yandex.Metrica. Un clúster tenia uns 600 servidors, l'altre en tenia 360 i hi ha un tercer i diversos clústers. L'entorn de prova d'un d'ells són només dos fragments amb dues rèpliques cadascun. Per què dos fragments? Per no estar sol. I rèpliques, també, per ser. Només una quantitat mínima que us podeu permetre.
Aquest entorn de prova us permet comprovar l'estat de les sol·licituds i si alguna cosa està trencada de manera important. Però sovint sorgeixen problemes de naturalesa completament diferent, quan tot funciona, però hi ha alguns petits canvis amb la càrrega.
Et posaré un exemple. Vam decidir instal·lar una nova versió de ClickHouse. Està dissenyat en un entorn de prova, les proves automatitzades es passen al mateix Yandex.Metrica, que comparen dades de la versió antiga i de la nova, executant tot el pipeline. I per descomptat, proves verdes del nostre CI. En cas contrari, ni tan sols hauríem proposat aquesta versió.
Tot està bé. Comencem a entrar en producció. Rebo un missatge que la càrrega ha augmentat diverses vegades als gràfics. Estem recuperant la versió. Miro el gràfic i veig: la càrrega va augmentar realment diverses vegades durant el llançament i va tornar a disminuir quan es va desplegar. Llavors vam començar a revertir la versió. I la càrrega va augmentar de la mateixa manera i va caure enrere de la mateixa manera. Així que la conclusió és aquesta: la càrrega ha augmentat en relació amb el càlcul, res d'estranyar.
Aleshores va ser difícil convèncer els companys perquè instal·lessin la nova versió després de tot. Li dic: "Està bé, desplega. Creuem els dits, tot funcionarà. Ara la càrrega ha augmentat als gràfics, però tot està bé. Espera." En general, vam fer això i ja està: la versió es publica al lloc de producció. Però gairebé amb cada càlcul, sorgeixen problemes similars.
Se suposa que Kill query mata les consultes, però no ho fa. Per què?
Un usuari va venir a mi, una mena d'analista, i va crear una determinada sol·licitud, que va posar el meu clúster ClickHouse. Algun node o un clúster sencer, depenent de quina rèplica o fragment en què va entrar la sol·licitud. Veig que tots els recursos de la CPU d'aquest servidor estan a la prestatgeria, tot és vermell. Al mateix temps, el mateix ClickHouse respon a les sol·licituds. I escric: "Si us plau, mostra'm la llista de processos, quina sol·licitud va generar aquesta bogeria".
Trobo aquesta petició i escric kill-hi. I veig que no passa res. El meu servidor està al prestatge, ClickHouse em dóna algunes ordres, mostra que el servidor està viu i tot està bé. Però tinc degradació en totes les sol·licituds d'usuari, comença la degradació per entrada a ClickHouse i la meva consulta de matança no funciona. Per què? Vaig pensar que kill query havia de matar les consultes, però no ho fa.
Ara hi haurà una resposta força estranya. La qüestió és que la consulta de matança no mata les sol·licituds.
Kill query posa una petita casella de selecció anomenada "Vull que s'elimini aquesta consulta". I la pròpia sol·licitud, en processar cada bloc, mira aquesta bandera. Si està establert, la sol·licitud deixa de funcionar. Resulta que ningú mata la petició, ell mateix ha de comprovar-ho tot i parar. I això hauria de funcionar en tots els casos en què la sol·licitud es trobi en un estat de processament de bloqueig. Processarà el següent bloc de dades, comprovarà la bandera i s'aturarà.
Això no funciona en els casos en què la sol·licitud està bloquejada en alguna operació. És cert que aquest no és probablement el vostre cas, perquè, segons vosaltres, utilitza un munt de recursos del servidor. És possible que això no funcioni en el cas de la classificació externa i en alguns altres detalls. Però, en general, això no hauria de ser, això és un error. I l'únic que puc aconsellar és actualitzar ClickHouse.
Com calcular el temps de resposta amb càrrega de lectura?
Hi ha una taula que emmagatzema els agregats d'articles: diversos comptadors. El nombre de línies és d'uns cent milions. És possible comptar amb un temps de resposta previsible si aboqueu 1K RPS a 1K articles?
A jutjar pel context, estem parlant d'una càrrega de lectura, perquè no hi ha problemes amb l'escriptura: es poden inserir almenys mil, almenys cent mil i, de vegades, diversos milions de línies.
Les peticions de lectura són molt diferents. A la selecció 1, ClickHouse pot realitzar unes desenes de milers de sol·licituds per segon, de manera que fins i tot les sol·licituds d'una sola clau ja requeriran alguns recursos. I aquestes consultes puntuals seran més difícils que en algunes bases de dades de valors clau, perquè per a cada lectura cal llegir el bloc de dades per índex. El nostre índex no aborda cada registre, sinó cada rang. És a dir, heu de llegir tot el rang: aquestes són 8192 línies per defecte. I heu de descomprimir el bloc de dades comprimit de 64 KB a 1 MB. Normalment, aquestes consultes de punts triguen uns quants mil·lisegons. Però aquesta és l'opció més fàcil.
Anem a provar una mica d'aritmètica senzilla. Si multipliqueu uns quants mil·lisegons per mil, obteniu uns quants segons. Com si fos impossible mantenir mil peticions per segon, però de fet és possible, perquè tenim diversos nuclis de processador. Per tant, en principi, ClickHouse de 1000 RPS de vegades pot aguantar, però amb peticions curtes, és a dir, puntuals.
Si necessiteu escalar el clúster ClickHouse pel nombre de sol·licituds simples, us recomano el més senzill: augmentar el nombre de rèpliques i enviar sol·licituds a una rèplica aleatòria. Si una rèplica conté cinc-centes sol·licituds per segon, cosa que és completament realista, llavors tres rèpliques tindran mil i mig.
De vegades, per descomptat, també podeu configurar ClickHouse per al nombre màxim de lectures de punts. Què es necessita per a això? El primer és reduir la granularitat de l'índex. Al mateix temps, no s'hauria de reduir a un, sinó basant-se en que el nombre de registres a l'índex serà de diversos milions o desenes de milions per servidor. Si la taula té cent milions de files, es pot definir 64 com a granularitat.
Podeu reduir la mida del bloc comprimit. Hi ha configuracions per a això. mida mínima del bloc de compressió, mida màxima del bloc de compressió. Podeu reduir-los, tornar a carregar les dades i, a continuació, les consultes puntuals seran més ràpides. Tanmateix, ClickHouse no és una base de dades de valors clau. Un gran nombre de petites sol·licituds és un anti-patró de càrrega.
Kirill Shvakov: Aconsellaré per si hi ha comptables normals. Aquesta és una situació bastant estàndard quan s'emmagatzema algun tipus de comptador a ClickHouse. Tinc un usuari, és de tal o tal país, algun altre tercer camp, i necessito augmentar alguna cosa de manera incremental. Agafeu MySQL, feu una clau única (a MySQL és una clau duplicada, i a PostgreSQL és un conflicte) i afegiu un signe més. Això funcionarà molt millor.
Quan teniu poques dades, no té gaire sentit utilitzar ClickHouse. Hi ha bases de dades habituals i ho fan bé.
Què cal ajustar a ClickHouse perquè hi hagi més dades a la memòria cau?
Imaginem-nos la situació: els servidors tenen 256 GB de RAM, en la rutina diària ClickHouse triga uns 60-80 GB, al màxim, fins a 130. Què es pot habilitar i ajustar perquè hi hagi més dades a la memòria cau i, en conseqüència , hi ha menys viatges al disc?
Per regla general, la memòria cau de pàgines del sistema operatiu fa una bona feina d'aquesta tasca. Si només obriu la part superior, mireu allà a la memòria cau o lliure (també diu quant s'hi guarda a la memòria cau), podreu veure que tota la memòria lliure s'utilitza per a la memòria cau. I en llegir aquestes dades, no es llegiran des del disc, sinó des de la memòria RAM. Al mateix temps, puc dir que la memòria cau s'utilitza de manera eficaç, perquè són les dades comprimides les que s'emmagatzemen a la memòria cau.
Tanmateix, si voleu accelerar encara més algunes consultes senzilles, és possible habilitar una memòria cau a les dades descomprimides dins de ClickHouse. Es diu memòria cau sense comprimir. Al fitxer de configuració config.xml, configureu la mida de la memòria cau sense comprimir al valor que necessiteu; us recomano que no més de la meitat de la memòria RAM lliure, perquè la resta anirà sota la memòria cau de la pàgina.
A més, hi ha dos paràmetres de nivell de sol·licitud. Primera configuració - utilitzar la memòria cau sense comprimir - Inclou el seu ús. Es recomana habilitar-lo per a totes les sol·licituds, excepte les pesades, que poden llegir totes les dades i esborrar aquesta memòria cau. I la segona configuració és una cosa així com el nombre màxim de línies per utilitzar la memòria cau. Restringeix automàticament les sol·licituds grans perquè superin la memòria cau.
Com puc configurar storage_configuration per a l'emmagatzematge a la memòria RAM?
A la nova documentació de ClickHouse, he llegit la secció relacionada . A la descripció hi ha un exemple amb un SSD ràpid.
Em pregunto com podeu configurar el mateix amb la memòria calenta de volum. I una pregunta més. Com funciona selecte amb aquesta organització de dades, llegirà tot el conjunt o només el del disc, i aquestes dades es comprimeixen a la memòria? I com funciona la secció prewhere en aquesta organització de dades?
Aquesta configuració afecta l'emmagatzematge de peces de dades i el seu format no canvia de cap manera.
Fem una ullada més de prop.
Podeu configurar l'emmagatzematge de dades a la memòria RAM. Tot el que està configurat per a un disc és el seu camí. Creeu una partició tmpfs que es munta a alguna ruta del sistema de fitxers. Especifiqueu aquest camí com a camí d'emmagatzematge de dades per a la partició més calenta, les dades comencen a arribar i s'escriuran allà, tot està bé.
Però no us recomano fer-ho a causa de la poca fiabilitat, tot i que si teniu almenys tres rèpliques en diferents centres de dades, podeu fer-ho. Si és així, es restauraran les dades. Imagineu que el servidor es va apagar i tornar a encendre de sobte. El tram es va tornar a muntar, però hi ha un buit. A l'inici, el servidor ClickHouse veu que aquestes peces falten, tot i que, segons les metadades de ZooKeeper, haurien de ser-ho. Mira en quines rèpliques es troben, les demana i les descarrega. Així, les dades seran restaurades.
En aquest sentit, emmagatzemar dades a la memòria RAM no és fonamentalment diferent d'emmagatzemar-les al disc, perquè quan les dades s'escriuen al disc, també cauen primer a la memòria cau de la pàgina i s'escriuen físicament més tard. Depèn de com es munti el sistema de fitxers. Però per si de cas, diré que ClickHouse no fa fsync en inserir.
En aquest cas, les dades de la memòria RAM s'emmagatzemen exactament en el mateix format que al disc. La consulta de selecció selecciona els fragments que s'han de llegir de la mateixa manera, selecciona els intervals de dades necessaris als fragments i els llegeix. I prewhere funciona exactament igual, independentment de si les dades estaven a la memòria RAM o al disc.
Fins a quin nombre de valors únics és efectiva la Cardinalitat baixa?
La baixa cardinalitat és complicada. Recopila diccionaris de dades, però són locals. En primer lloc, els diccionaris són diferents per a cada peça, i en segon lloc, fins i tot dins d'una peça poden ser diferents per a cada rang. Quan el nombre de valors únics arriba a un llindar, un milió, crec, simplement es deixa de banda el diccionari i se'n crea un de nou.
La resposta és en general: per a cada rang local, per exemple, per a cada dia, en algun lloc fins a un milió de valors únics, la Cardinalitat baixa és efectiva. Després d'això, només hi haurà una alternativa, en la qual s'utilitzaran molts diccionaris diferents, i no només un. Funcionarà de la mateixa manera que una columna normal del tipus de cadena, potser una mica menys eficient, però no hi haurà una degradació greu del rendiment.
Quines són les pràctiques recomanades per a la cerca de text complet en una taula amb cinc mil milions de files?
Hi ha diferents respostes. El primer és dir que ClickHouse no és un motor de cerca de text complet. Hi ha sistemes especials per a això, per exemple, и . No obstant això, cada cop veig més gent que diu que es trasllada d'Elasticsearch a ClickHouse.
Per què passa això? Ho expliquen pel fet que Elasticsearch deixa de fer front a la càrrega d'alguns volums, començant per la construcció d'índexs. Els índexs es tornen massa feixucs, i si simplement transferiu les dades a ClickHouse, resulta que s'emmagatzemen diverses vegades més eficientment en termes de volum. Al mateix temps, les consultes de cerca sovint no eren de tal manera que calgués trobar alguna frase en tota la quantitat de dades, tenint en compte la morfologia, sinó completament diferents. Per exemple, per trobar les últimes hores als registres d'alguna subseqüència de bytes.
En aquest cas, creeu un índex a ClickHouse, el primer camp en el qual hi haurà la data amb l'hora. I el tall més gran de dades serà exactament per a l'interval de dates. Dins de l'interval de dates seleccionat, per regla general, ja és possible realitzar una cerca de text complet fins i tot utilitzant el mètode de força bruta amb like. La declaració like a ClickHouse és la declaració like més eficient que podeu trobar. Si en trobes un de millor, digues-m'ho.
Però tot i així, com és una exploració completa. I l'exploració completa pot ser lenta no només a la CPU, sinó també al disc. Si de sobte tens un terabyte de dades al dia i estàs buscant una paraula en un dia, hauràs d'escanejar un terabyte. I probablement sigui en discs durs normals i, com a resultat, es carregaran de tal manera que no entrareu a aquest servidor mitjançant SSH.
En aquest cas, estic disposat a oferir un petit truc més. És de la categoria d'experimental: pot funcionar o no. ClickHouse té índexs de text complet en forma de filtres de floració de trigrames. Els nostres companys d'Arenadata ja han provat aquests índexs, i sovint funcionen exactament com es pretenia.
Per utilitzar-los correctament, hauríeu de tenir una bona comprensió de com funcionen exactament: què és un filtre de floració de trigrames i com triar-ne la mida. Puc dir que ajudaran per a consultes sobre algunes frases rares, subcadenes que poques vegades es troben a les dades. En aquest cas, els subintervals es seleccionaran mitjançant índexs i es llegiran menys dades.
ClickHouse ha afegit recentment funcions encara més avançades per a la cerca de text complet. Es tracta, en primer lloc, de cercar un munt de subcadenes alhora en una passada, incloses les opcions que distingeixen entre majúscules i minúscules, que no distingeixen entre majúscules i minúscules, que són compatibles amb UTF-8 o només amb ASCII. Trieu el més eficient que necessiteu.
També es va cercar diverses expressions regulars en una passada. No cal escriure X com una subcadena o X com una altra subcadena. Escriu de seguida i tot es farà de la manera més eficient possible.
En tercer lloc, ara hi ha una cerca aproximada d'expressions regulars i una cerca aproximada de subcadenes. Si algú ha escrit una paraula amb un error ortogràfic, es buscarà la coincidència màxima.
Quina és la millor manera d'organitzar l'accés a ClickHouse per a un gran nombre d'usuaris?
Expliqueu-nos la millor manera d'organitzar l'accés per a un gran nombre de consumidors i analistes. Com formar una cua, prioritzar el màxim de consultes concurrents i amb quines eines?
Si el clúster és prou gran, una bona solució seria crear dos servidors més, que es convertiran en un punt d'entrada per als analistes. És a dir, no deixeu que els analistes entrin fragments de clúster específics, sinó que simplement creeu dos servidors buits, sense dades, i ja hi configureu drets d'accés. Al mateix temps, la configuració de l'usuari es transfereix a servidors remots durant les sol·licituds distribuïdes. És a dir, ho configureu tot en aquests dos servidors i la configuració té un efecte sobre tot el clúster.
En principi, aquests servidors no tenen dades, però la quantitat de memòria RAM és molt important per executar les sol·licituds. El disc també es pot utilitzar per a dades temporals si l'agregació externa o l'ordenació externa està habilitada.
És important mirar la configuració que s'associa amb tots els límits possibles. Si ara vaig al clúster Yandex.Metrics com a analista i estableixo una consulta seleccioneu el recompte entre les visites, llavors immediatament se'm donarà una excepció que no puc complir la sol·licitud. El nombre màxim de files que puc escanejar és de cent mil milions, i hi ha cinquanta bilions en total al clúster en una taula. Aquesta és la primera limitació.
Suposem que elimino el límit del nombre de files i torno a executar la consulta. Aleshores veuré la següent excepció: la configuració està activada força l'índex per data. No puc executar la consulta si no he especificat un interval de dates. No heu de confiar en els analistes per introduir-lo manualment. Un cas típic: s'escriu un interval de dates on la data de l'esdeveniment és entre una setmana. I després simplement no van especificar cap parèntesi allà, i en comptes de i va resultar ser una coincidència d'URL o - o. Si no hi ha límit, rastrejarà la columna d'URL i malgastarà un munt de recursos.
A més, ClickHouse té dues opcions de prioritat. Malauradament, són molt primitius. Un s'anomena simplement prioritat. Si la prioritat ≠ 0 i les sol·licituds amb certa prioritat s'executen, però s'executa una sol·licitud amb un valor de prioritat inferior, el que significa una prioritat més alta, s'executa una sol·licitud amb un valor de prioritat més gran que, el que significa una prioritat inferior. simplement suspès i no funcionarà en absolut durant aquest temps.
Aquesta és una configuració molt aproximada i no és adequada per a situacions en què hi ha una càrrega constant al clúster. Però si teniu sol·licituds breus i d'impuls que són importants i el clúster està majoritàriament inactiu, aquesta configuració servirà.
S'anomena la següent configuració de prioritat Prioritat del fil del sistema operatiu. Simplement exposa tots els fils d'execució de sol·licituds al bon valor per al planificador de Linux. Funciona així, però encara funciona. Si establiu el valor mínim agradable (és el valor més gran i, per tant, la prioritat més baixa) i establiu -19 per a sol·licituds d'alta prioritat, aleshores la CPU consumirà sol·licituds de baixa prioritat quatre vegades menys que les d'alta prioritat.
També heu d'establir el temps màxim d'execució de la consulta, per exemple, cinc minuts. La velocitat mínima d'execució de la sol·licitud és el millor. Aquesta configuració ha existit des de fa molt de temps i cal no només per afirmar que ClickHouse no s'alenteix, sinó per forçar-la.
Imagineu-vos que esteu configurant: si una consulta processa menys d'un milió de files per segon, no podeu fer-ho. Això deshonra el nostre bon nom, la nostra bona base de dades. Prohibem-ho. En realitat, hi ha dues configuracions. Es diu un velocitat d'execució mínima - en línies per segon, i el segon s'anomena temps d'espera abans de comprovar la velocitat mínima d'execució - quinze segons per defecte. És a dir, són possibles quinze segons, i després, si és lent, només heu de llançar una excepció: avortar la sol·licitud.
També cal establir quotes. ClickHouse té una funció de quota integrada que compta el consum de recursos. Però, malauradament, no els recursos de ferro com la CPU, els discos, sinó els lògics: el nombre de sol·licituds processades, línies i bytes llegits. I podeu configurar, per exemple, un màxim de cent peticions en cinc minuts i mil peticions per hora.
Per què és important? Com que algunes de les sol·licituds d'anàlisi es realitzaran manualment directament des del client ClickHouse. I tot anirà bé. Però si teniu analistes avançats a la vostra empresa, escriuran un script i pot haver-hi un error. I aquest error farà que la sol·licitud s'executi en un bucle infinit. Això és el que cal protegir.
És possible donar els resultats d'una sol·licitud a deu clients?
Tenim diversos usuaris als quals els agrada venir amb sol·licituds molt grans al mateix temps. La sol·licitud és gran, en principi s'executa ràpidament, però a causa del fet que hi ha moltes sol·licituds d'aquest tipus al mateix temps, es fa molt dolorosa. És possible executar la mateixa sol·licitud, que ha arribat deu vegades seguides, una vegada, i donar el resultat a deu clients?
El problema és que no tenim resultats de la memòria cau ni una memòria cau de dades intermèdia. Hi ha una memòria cau de pàgines del sistema operatiu, que us permetrà no tornar a llegir les dades del disc, però, malauradament, les dades encara es descomprimiran, deserialitzaran i es tornaran a processar.
M'agradaria evitar-ho d'alguna manera, ja sigui posant a la memòria cau dades intermèdies o alineant consultes similars en algun tipus de cua i afegint una memòria cau de resultats. Ara tenim una sol·licitud d'extracció en desenvolupament, que afegeix una memòria cau de sol·licituds, però només per a subsol·licituds a les seccions d'entrada i unió, és a dir, la solució és inferior.
Tanmateix, també tenim una situació així. Un exemple particularment canònic són les sol·licituds amb paginació. Hi ha un informe, té diverses pàgines, i hi ha una petició de límit 10. Aleshores el mateix, però límit 10,10. Després una altra pàgina. I la pregunta és, per què ho comptem tot cada cop? Però ara no hi ha solució, i no hi ha manera d'evitar-la.
Hi ha una solució alternativa que es col·loca com a sidecar al costat de ClickHouse: .
Kirill Shvakov: ClickHouse Proxy té un limitador de velocitat integrat i una memòria cau de resultats integrada. S'hi han fet moltes configuracions, perquè es va resoldre una tasca semblant. El servidor intermediari us permet limitar les sol·licituds posant-les en cua i configurar quant de temps dura la memòria cau de sol·licituds. Si les sol·licituds eren realment les mateixes, el Proxy les donarà moltes vegades i només anirà a ClickHouse una vegada.
Nginx també té una memòria cau a la versió gratuïta i això també funcionarà. Nginx fins i tot té configuracions de manera que si les sol·licituds arriben al mateix temps, aturarà les altres fins que se n'acabi una. Però és a ClickHouse Proxy on la configuració es millora molt. Va ser fet específicament per ClickHouse, específicament per a aquestes peticions, per la qual cosa és més adequat. Bé, és fàcil de configurar.
Què passa amb les operacions asíncrones i les vistes materialitzades?
Hi ha un problema tal que les operacions amb el motor de substitució són asíncrones: les dades primer s'escriuen i després es col·lapsen. Si una tauleta materialitzada amb alguns agregats viu sota la tauleta, s'escriuran duplicats. I si no hi ha una lògica complexa, les dades es duplicaran. Què es pot fer al respecte?
Hi ha una solució òbvia: implementar un activador en una classe de matview específica durant una operació de col·lapse asíncrona. Hi ha plans de "bales de plata" per implementar aquesta funcionalitat?
Val la pena entendre com funciona la deduplicació. El que estic a punt de dir no està relacionat amb la pregunta, però val la pena recordar-ho per si de cas.
Quan s'insereix en una taula replicada, hi ha una deduplicació de tots els blocs inserits. Si torneu a inserir el mateix bloc que conté el mateix nombre de les mateixes files en el mateix ordre, les dades es desdupliquen. Obtindreu "D'acord" en resposta a la inserció, però realment s'escriurà un lot de dades i no es duplicarà.
Això és necessari per a la certesa. Si obteniu "D'acord" durant la inserció, les vostres dades s'han inserit. Si rebeu un error de ClickHouse, no s'insereixen i haureu de repetir la inserció. Però si la connexió es trenca durant la inserció, no saps si les dades s'insereixen o no. L'única opció és tornar a repetir la inserció. Si les dades s'han inserit realment i les heu tornat a inserir, hi ha una deduplicació de blocs. És necessari per evitar duplicats.
I també és important com funciona per a les vistes materialitzades. Si les dades es van desduplicar quan es van inserir a la taula principal, tampoc aniran a la vista materialitzada.
Ara sobre la pregunta. La vostra situació és més complicada perquè esteu escrivint duplicats de línies individuals. És a dir, no es duplica tot el paquet, sinó línies específiques, i es col·lapsen en segon pla. De fet, les dades es col·lapsaran a la taula principal i les no col·lapsades aniran a la vista materialitzada i no passarà res a les vistes materialitzades durant la fusió. Perquè una vista materialitzada no és més que un activador a la inserció. No li passa res més durant altres operacions.
I aquí no puc ser feliç. Només cal buscar una solució específica per a aquest cas. Per exemple, és possible substituir-lo en una vista materialitzada, i el mètode de deduplicació, potser, funcionarà de la mateixa manera? Però, malauradament, no sempre. Si s'agrega, no funcionarà.
Kirill Shvakov: També vam tenir ossos al mateix temps. Hi ha hagut un problema perquè hi ha impressions d'anuncis i hi ha algunes dades que podem mostrar en temps real: només són impressions. Poques vegades es dupliquen, però si ho fan, els col·lapsarem igualment. I hi havia coses que no es poden duplicar: clics i tota aquesta història. Però també volia mostrar-los gairebé immediatament.
Com es van fer les vistes materialitzades? Hi havia vistes on s'escriu directament: hi ha un registre en dades en brut i està escrit en vistes. Allà, en algun moment, les dades no són molt correctes, es dupliquen, etc. I hi ha la segona part de la taula, on tenen exactament el mateix aspecte que les vistes materialitzades, és a dir, tenen exactament la mateixa estructura. De tant en tant, tornem a calcular les dades, comptem les dades sense duplicats, escrivim en aquestes taules.
Hem passat per l'API: això no funcionarà manualment a ClickHouse. I l'API mira: quan tinc la data de l'última incorporació a la taula, on es garanteix que ja s'han calculat les dades correctes, i fa una sol·licitud a una taula i a una altra taula. D'una sol·licitud selecciona fins a un determinat període de temps, i de l'altra s'obté el que encara no s'ha calculat. I funciona, però no mitjançant un ClickHouse.
Si teniu algun tipus d'API (per a analistes, per a usuaris), aleshores, en principi, aquesta és una opció. Sempre comptes, sempre comptes. Això es pot fer un cop al dia o en un altre moment. Trieu vosaltres mateixos la gamma que no necessiteu i que no és crítica.
ClickHouse té molts registres. Com puc veure tot el que li passa al servidor en un moment?
ClickHouse té un nombre molt gran de registres diferents, i aquest nombre està augmentant. En les noves versions, algunes d'elles fins i tot estan habilitades per defecte, en versions anteriors s'han d'habilitar en l'actualització. Tanmateix, cada cop n'hi ha més. M'agradaria veure finalment què està passant ara amb el meu servidor, potser en algun quadre de comandament de resum.
Teniu a l'equip de ClickHouse, o als equips dels vostres amics, que admetin alguna funcionalitat de taulers de control ja fets que mostraran aquests registres com a producte acabat? En definitiva, només mirar els registres a ClickHouse és fantàstic. Però estaria molt bé que ja estigués preparat en forma de tauler. M'hi posaria alta en això.
Hi ha taulers, encara que no estan estandarditzats. Tenim uns 60 equips a la nostra empresa que utilitzen ClickHouse, i el més estrany és que molts d'ells tenen taulers de control que ells mateixos han fet i una mica diferents. Alguns equips utilitzen la instal·lació interna de Yandex.Cloud. Hi ha alguns informes ja fets, encara que no tots són necessaris. Altres tenen la seva.
Els meus companys de Metrica tenen el seu propi tauler de control a Grafana, i jo tinc el meu per al seu propi clúster. Estic mirant coses com un èxit de memòria cau per a una memòria cau serif. I encara més difícil és que utilitzem diferents eines. Vaig crear el meu tauler amb una eina molt antiga anomenada Graphite-web. És completament lleig. I encara el faig servir així, encara que Grafana probablement seria més còmode i més bonic.
El bàsic dels taulers de comandament és el mateix. Aquestes són mètriques del sistema per al clúster: CPU, memòria, disc, xarxa. Altres són el nombre de sol·licituds simultànies, el nombre de combinacions simultànies, el nombre de sol·licituds per segon, el nombre màxim de fragments per a les particions de la taula MergeTree, el retard de replicació, la mida de la cua de replicació, el nombre de files inserides per segon, el nombre de blocs inserits per segon. Això és tot el que s'obté no dels registres, sinó de les mètriques.
Vladimir Kolobaev: Alexey, m'agradaria corregir una mica. Hi ha Grafana. Grafana té una font de dades que és ClickHouse. És a dir, puc fer sol·licituds de Grafana directament a ClickHouse. ClickHouse té una taula amb registres, és igual per a tothom. Com a resultat, vull accedir a aquesta taula de registre a Grafana i veure les sol·licituds que aplica el meu servidor. Seria fantàstic tenir un quadre de comandament així.
Jo mateix l'he fet amb bicicleta. Però tinc una pregunta: si tot està estandarditzat i tothom fa servir Grafana, per què Yandex no té un tauler de control tan oficial?
Kirill Shvakov: De fet, la font de dades que ClickHouse ara admet Altinity. I només vull donar un vector d'on excavar i a qui empènyer. Podeu preguntar-los, perquè Yandex encara fa ClickHouse, i no la història que l'envolta. Altinity és la principal empresa que actualment promociona ClickHouse. No l'abandonaran, sinó que li donaran suport. Perquè, en principi, per pujar un tauler al lloc web de Grafana només cal registrar-se i pujar-lo, no hi ha problemes particulars.
Alexei Milovidov: Durant l'últim any, ClickHouse ha afegit moltes funcions de perfil de consultes. Hi ha mètriques per a cada sol·licitud d'ús de recursos. I més recentment, s'ha afegit un perfilador de consultes de nivell encara més baix per veure on passa la consulta cada mil·lisegon. Però per utilitzar aquesta funcionalitat, he d'obrir el client de la consola i escriure una consulta que no deixo de oblidar. El vaig guardar en algun lloc i sempre oblido on exactament.
M'agradaria que hi hagués una eina que només digui: aquí teniu les vostres consultes pesades, agrupades per classe de consulta. Vaig fer clic en un, i em van dir que és pesat per tant. Ara no hi ha aquesta solució. I és realment estrany que quan la gent em pregunti: "Digues-me, hi ha taulers ja fets per a Grafana?", li digui: "Vés al lloc web de Grafana, hi ha una comunitat de Dashboards i hi ha un tauler de Dimka , allà de Kostyan. No sé què és, jo mateix no l'he fet servir".
Com influir en merdzhi perquè el servidor no caigui en OOM?
Tinc una taula, només hi ha una partició a la taula, és ReplaceingMergeTree. He estat escrivint dades durant quatre anys. Vaig haver de fer-hi un canvi i esborrar algunes dades.
Vaig fer això i, en el curs de processar aquesta sol·licitud, es va consumir tota la memòria de tots els servidors del clúster i tots els servidors del clúster van entrar a OOM junts. Llavors es van aixecar tots junts, van començar a fusionar la mateixa operació, aquest bloc de dades, i van tornar a caure en OOM. Després es van tornar a aixecar i van caure de nou. I aquesta cosa no va parar.
Llavors va resultar que aquest és en realitat un error que els nois van solucionar. Això és molt xulo, moltes gràcies. Però el residu va quedar. I ara, quan penso en la necessitat de fer una determinada fusió a la taula, tinc una pregunta: per què no puc agafar aquestes fusions i influir-hi d'alguna manera? Per exemple, limiteu-los per la quantitat de memòria RAM necessària o, en principi, pel seu nombre, que processarà aquesta taula en particular.
Tinc una taula anomenada "Mètriques", processeu-la en dos fluxos. No cal produir deu o cinc fusions en paral·lel, fes-ho en dos. Crec que en dos tinc prou memòria, però potser no n'hi ha prou per processar-ne deu. Per què es manté la por? Perquè la taula està creixent, i algun dia em trobaré amb una situació que, en principi, ja no es deu a un error, sinó al fet que les dades canviaran en una quantitat tan gran que simplement no tinc prou memòria. el servidor. I llavors el servidor caurà en OOM durant la fusió. A més, puc cancel·lar la mutació, però la fusió ha desaparegut.
Ja sabeu, quan es fusiona, el servidor no caurà en OOM, perquè quan es fusiona, la quantitat de RAM només s'utilitza per a un petit rang de dades. Així que tot anirà bé independentment de la quantitat de dades.
Vladimir Kolobaev: Bé. Aquí el moment és tal que després d'haver corregit un error, em vaig descarregar una nova versió i en una altra taula, més petita, on hi ha moltes particions, vaig fer una operació semblant. I durant la fusió, es van cremar uns 100 GB de RAM al servidor. En tenia 150 ocupats, n'he menjat 100 i quedava una finestra de 50 GB, així que no vaig caure en OOM.
Què em protegeix actualment de caure en OOM si realment consumeix 100 GB de RAM? Què fer en una situació si de sobte s'acaba la memòria RAM del merdzh?
Alexei Milovidov: Hi ha un problema tal que el consum de memòria RAM no es limita a merdzhi. I el segon problema és que si s'ha assignat una fusió, s'ha d'executar, perquè s'escriu al registre de rèplica. El registre de rèplica són les accions necessàries per portar la rèplica a un estat coherent. Si no feu manipulacions manuals perquè aquest registre de rèplica es revertirà, la fusió s'haurà de fer d'una manera o altra.
Per descomptat, no seria superflu tenir una limitació a la memòria RAM, que "per si de cas" protegeix contra OOM. No ajudarà a executar la fusió, tornarà a començar, arribarà a algun llindar, llançarà una excepció i després tornarà a començar; no en sortirà res de bo. Però, en principi, seria útil introduir aquesta restricció.
Com es desenvoluparà el controlador Golang per a ClickHouse?
El controlador de Golang escrit per Kirill Shvakov ara té el suport oficial de l'equip de ClickHouse. Ell , ara és gran i real.
Una petita nota. Hi ha un meravellós i estimat dipòsit de formes normals d'ordre infinit: això és Vertica. També tenen el seu propi controlador oficial de Python, que és mantingut pels desenvolupadors de Vertica. I en diverses ocasions va passar que les versions de l'emmagatzematge i les versions del conductor es van separar de manera força brusca i el conductor va deixar de funcionar en algun moment. I el segon punt. El suport per a aquest controlador oficial, em sembla, el manté el sistema "mugells": els escriviu un problema i es penja per sempre.
Tinc dues preguntes. Ara el controlador Golang de Kirill és una manera gairebé predeterminada de comunicar-se des de Golang amb ClickHouse. A menys que algú encara es comuniqui a través de la interfície http, perquè li agrada molt. Com es desenvoluparà aquest controlador? Es sincronitzarà amb alguns canvis de ruptura al mateix repositori? I quin és el procediment per considerar la qüestió?
Kirill Shvakov: El primer és com s'organitza tot burocràticament. Aquest punt no s'ha parlat, així que no tinc res a respondre.
Per respondre a la pregunta sobre el problema, necessitem una petita història del conductor. Vaig treballar per a una empresa que tenia moltes dades. Era un girador publicitari amb una gran quantitat d'esdeveniments que calia emmagatzemar en algun lloc. I en algun moment va aparèixer ClickHouse. Hi vam abocar dades i al principi tot estava bé, però després va caure ClickHouse. Aleshores vam decidir que no ens calia.
Un any més tard, vam tornar a la idea d'utilitzar ClickHouse i vam haver d'escriure dades d'alguna manera allà. L'entrada va ser aquesta: el ferro és molt feble, hi ha pocs recursos. Però sempre hem treballat així i, per tant, hem mirat cap al protocol autòcton.
Com que estàvem treballant en Go, estava clar que necessitàvem un conductor de Go. Ho vaig fer gairebé a temps complet: era la meva tasca laboral. Fins a cert punt, el vam plantejar i, en principi, ningú s'esperava que algú més que nosaltres el fes servir. Aleshores, CloudFlare va presentar exactament el mateix problema i durant un temps vam treballar molt bé amb ells, perquè tenien les mateixes tasques. I ho vam fer tant al mateix ClickHouse com al controlador.
En algun moment, simplement vaig deixar de fer-ho, perquè la meva activitat pel que fa a ClickHouse i amb la feina ha canviat una mica. Per tant, els temes no estan tancats. Periòdicament, les persones que necessiten alguna cosa es comprometen amb el repositori. Llavors miro la sol·licitud d'extracció i de vegades fins i tot edito alguna cosa jo mateix, però això rarament passa.
Vull tornar al conductor. Fa uns anys, quan va començar tot això, ClickHouse també era diferent i amb característiques diferents. Ara hi ha una comprensió de com refer el controlador perquè sigui bo. Si això passa, aleshores la versió 2 serà incompatible de totes maneres a causa de les crosses acumulades.
No sé com organitzar això. Jo mateix no tinc gaire temps. Si algunes persones acaben el conductor, els puc ajudar i dir-los què han de fer. Però és la participació activa de Yandex en el desenvolupament del projecte que encara no s'ha discutit de cap manera.
Alexei Milovidov: De fet, encara no hi ha cap burocràcia sobre aquests conductors. L'única cosa és que es traslladen a una organització oficial, és a dir, aquest controlador és reconegut com la solució oficial predeterminada per a Go. Hi ha altres conductors, però vénen per separat.
No tenim cap desenvolupament per a aquests controladors dins. La qüestió és si podem contractar una persona, no específicament per a aquest conductor, sinó per al desenvolupament de tots els conductors de la comunitat, o podem trobar algú de fora.
El diccionari extern no es genera després del reinici amb lazy_load activat. Què fer?
Tenim la configuració lazy_load activada i, després de reiniciar el servidor, el diccionari en si no augmenta. Només apareix després que l'usuari accedeixi a aquest diccionari. I llança un error a la primera trucada. És possible carregar d'alguna manera automàticament els diccionaris mitjançant ClickHouse, o sempre cal controlar-ne la preparació per tal que els usuaris no rebin errors?
Potser tenim una versió antiga de ClickHouse, de manera que el diccionari no es va carregar automàticament. Podria ser?
En primer lloc, els diccionaris es poden carregar força mitjançant la consulta recarregar els diccionaris del sistema. En segon lloc, sobre l'error: si el diccionari ja està carregat, les consultes funcionaran amb les dades que es van carregar. Si el diccionari encara no s'ha carregat, es carregarà just en el moment de la sol·licitud.
Per als diccionaris pesats, això no és gaire convenient. Per exemple, heu d'aconseguir un milió de files de MySQL. Algú fa una selecció senzilla, però aquesta selecció esperarà el mateix milió de files. Aquí hi ha dues solucions. El primer és desactivar lazy_load. El segon és quan el servidor s'aixeca, abans d'encendre la càrrega, fes-ho diccionari de recàrrega del sistema o simplement executar una consulta que utilitza un diccionari. Aleshores es carregarà el diccionari. Heu de controlar la disponibilitat dels diccionaris amb la configuració lazy_load activada, perquè ClickHouse no els obre automàticament.
La resposta a l'última pregunta és que la versió és antiga o s'ha de depurar.
Què passa amb el fet que el sistema recarrega els diccionaris no carrega cap dels molts diccionaris si almenys un d'ells falla amb un error?
Hi ha una altra pregunta sobre els diccionaris de recàrrega del sistema. Tenim dos diccionaris: un no està carregat, el segon està carregat. En aquest cas, els diccionaris de recàrrega del sistema no carreguen cap diccionari i n'heu de carregar-ne un de punt a punt amb el seu nom mitjançant el diccionari de recàrrega del sistema. Això també està relacionat amb la versió de ClickHouse?
Vull agradar. Aquest comportament ha canviat. Per tant, si actualitzeu ClickHouse, també canviarà. Si no està satisfet amb el comportament actual recarregar els diccionaris del sistema, actualitzeu i esperem que canviï per a millor.
Hi ha alguna manera de configurar els detalls a la configuració de ClickHouse, però no il·luminar-los en cas d'error?
La següent pregunta és sobre errors relacionats amb el diccionari, és a dir, detalls. Hem registrat els detalls de connexió a la configuració de ClickHouse al diccionari i, en cas d'error, rebem aquests detalls i la contrasenya com a resposta.
Hem resolt aquest error afegint detalls a la configuració del controlador ODBC. Hi ha alguna manera de configurar els detalls a la configuració de ClickHouse, però no de mostrar aquests detalls als errors?
Aquí, la solució és realment: especificar aquestes credencials a odbc.ini i al mateix ClickHouse, especificar només el nom de la font de dades ODBC. Això no passarà per a altres fonts de diccionari, ni per a un diccionari amb MySQL, ni per a la resta, no hauríeu de veure la contrasenya al missatge d'error. Per a ODBC, també miraré: si hi ha una cosa així, només cal eliminar-la.
Bonificació: fons per a Zuma de reunions
Si feu clic a la imatge dels lectors més persistents, s'obriran els fons de bonificació de les reunions. Apagar el foc juntament amb les mascotes tecnològiques d'Avito, conversar amb els companys de la sala de l'administrador del sistema o d'un club d'informàtica de la vella escola, i celebrar un diari sota el pont amb el teló de fons de grafitis.
Font: www.habr.com