HighLoad++ Moscou 2018, Palau de Congressos. 9 de novembre, 15:00 h
Resums i presentació:
Yuri Nasretdinov (VKontakte): l'informe parlarà de l'experiència d'implementar ClickHouse a la nostra empresa: per què ho necessitem, quantes dades emmagatzemem, com les escrivim, etc.
Materials addicionals:
Yuri Nasretdinov: - Hola a tots! Em dic Yuri Nasretdinov, com ja m'han presentat. Treballo a VKontakte. Parlaré de com inserim dades a ClickHouse des de la nostra flota de servidors (desenes de milers).
Què són els registres i per què els recullen?
Què us direm: què vam fer, per què necessitàvem "ClickHouse", respectivament, per què l'hem escollit, quin tipus de rendiment podeu obtenir aproximadament sense configurar res especial. Us parlaré més sobre les taules de memòria intermèdia, sobre els problemes que vam tenir amb elles i sobre les nostres solucions que vam desenvolupar a partir de codi obert: KittenHouse i Lighthouse.
Per què hem de fer res (tot sempre és bo a VKontakte, oi?). Volíem recollir registres de depuració (i hi havia centenars de terabytes de dades), potser d'alguna manera seria més convenient calcular estadístiques; i tenim una flota de desenes de milers de servidors des dels quals cal fer tot això.
Per què vam decidir? Probablement teníem solucions per emmagatzemar els registres. Aquí hi ha un "Backend VK" tan públic. Us recomano molt subscriure-hi.
Què són els registres? Aquest és un motor que retorna matrius buides. Els motors a VK són el que altres anomenen microserveis. I aquí hi ha un adhesiu somrient (molt de likes). Com és això? Bé, escolta més!
Què es pot utilitzar per emmagatzemar els registres? És impossible no esmentar Hadup. Després, per exemple, Rsyslog (emmagatzemar aquests registres en fitxers). LSD. Qui sap què és l'LSD? No, aquest LSD no. Emmagatzema també fitxers, respectivament. Bé, ClickHouse és una opció estranya.
Clickhouse i competidors: requisits i oportunitats
Què volem? Volem assegurar-nos que no ens haguem de preocupar massa pel funcionament, perquè funcioni fora de la caixa, preferiblement amb una configuració mínima. Volem escriure molt, i escriure ràpidament. I el volem mantenir durant tot tipus de mesos, anys, és a dir, durant molt de temps. És possible que volem entendre algun problema amb el qual ens van venir i van dir: "Alguna cosa no funciona aquí", i això va ser fa 3 mesos), i volem poder veure què va passar fa 3 mesos". La compressió de dades, està clar per què seria un avantatge, perquè redueix la quantitat d'espai que ocupa.
I tenim un requisit tan interessant: de vegades escrivim la sortida d'algunes ordres (per exemple, registres), pot ser més de 4 kilobytes amb força facilitat. I si això funciona amb UDP, llavors no cal gastar... no tindrà cap "càrrega general" per a la connexió, i per a un gran nombre de servidors això serà un avantatge.
Vegem què ens ofereix el codi obert. En primer lloc, tenim el motor de registres: aquest és el nostre motor; En principi, pot fer de tot, fins i tot pot escriure línies llargues. Bé, no comprimeix les dades de manera transparent: podem comprimir columnes grans nosaltres mateixos si ho volem..., per descomptat, no volem (si és possible). L'únic problema és que sap donar només allò que cap a la seva memòria; Per llegir la resta, cal obtenir el binlog d'aquest motor i, en conseqüència, triga força temps.
Quines altres opcions hi ha? Per exemple, "Hadup". Facilitat d'operació... Qui creu que Hadup és fàcil de muntar? Per descomptat, no hi ha problemes amb la gravació. En llegir, de vegades sorgeixen preguntes. En principi, diria que probablement no, sobretot per als registres. Emmagatzematge a llarg termini, és clar, sí, compressió de dades, sí, cadenes llargues, és clar que podeu gravar. Però gravant des d'un gran nombre de servidors... Encara has de fer alguna cosa tu mateix!
Rsyslog. De fet, l'hem utilitzat com a opció de còpia de seguretat per poder llegir-lo sense bolcar el binlog, però no pot escriure línies llargues; en principi, no pot escriure més de 4 kilobytes. Heu de fer la compressió de dades de la mateixa manera vosaltres mateixos. La lectura vindrà dels fitxers.
Després hi ha el desenvolupament "badushka" de LSD. Essencialment el mateix que "Rsyslog": admet cadenes llargues, però no pot funcionar amb UDP i, de fet, per això, malauradament, hi ha moltes coses que s'han de reescriure. L'LSD s'ha de redissenyar per poder gravar des de desenes de milers de servidors.
I aquí! Una opció divertida és ElasticSearch. Com dir-ho? Li va bé amb la lectura, és a dir, llegeix ràpidament, però no molt bé amb l'escriptura. En primer lloc, si comprimeix dades, és molt feble. El més probable és que una cerca completa requereixi estructures de dades més grans que el volum original. És difícil d'operar i sovint sorgeixen problemes amb ell. I, de nou, gravar a Elastic: ho hem de fer tot nosaltres mateixos.
Aquí ClickHouse és una opció ideal, per descomptat. L'única cosa és que la gravació des de desenes de milers de servidors és un problema. Però almenys hi ha un problema, podem intentar resoldre'l d'alguna manera. I la resta de l'informe tracta sobre aquest problema. Quin tipus de rendiment podeu esperar de ClickHouse?
Com el posarem? MergeTree
Qui d'entre vosaltres no ha sentit ni sap parlar de "ClickHouse"? T'ho he de dir, oi? Molt ràpid. La inserció allà: 1-2 gigabits per segon, ràfegues de fins a 10 gigabits per segon realment poden suportar aquesta configuració; hi ha dos Xeons de 6 nuclis (és a dir, ni tan sols el més potent), 256 gigabytes de RAM, 20 terabytes. en RAID (ningú configurat, configuració predeterminada). Alexey Milovidov, desenvolupador de ClickHouse, probablement està assegut allà plorant perquè no vam configurar res (tot ens va funcionar així). En conseqüència, es pot obtenir una velocitat d'escaneig d'uns 6 milions de línies per segon, per exemple, si les dades estan ben comprimides. Si us agrada el % en una cadena de text: 100 milions de línies per segon, és a dir, sembla força ràpid.
Com el posarem? Bé, ja sabeu que VK utilitza PHP. Introduirem des de cada treballador PHP via HTTP a "ClickHouse", a la taula MergeTree per a cada registre. Qui veu un problema amb aquest esquema? Per alguna raó, no tothom va aixecar la mà. Deixa'm dir-te.
En primer lloc, hi ha molts servidors; en conseqüència, hi haurà moltes connexions (mala). Aleshores, és millor inserir dades a MergeTree no més d'una vegada per segon. I qui sap per què? D'acord d'acord. Us explicaré una mica més sobre això. Una altra pregunta interessant és que no estem fent anàlisis, no necessitem enriquir les dades, no necessitem servidors intermedis, volem inserir directament a "ClickHouse" (preferiblement, com més directament, millor).
En conseqüència, com es fa la inserció a MergeTree? Per què és millor inserir-hi no més d'una vegada per segon o menys? El fet és que "ClickHouse" és una base de dades de columna i ordena les dades en ordre ascendent de la clau primària, i quan feu una inserció, es creen un nombre de fitxers com a mínim igual al nombre de columnes en què s'ordenen les dades. en ordre ascendent de la clau primària (es crea un directori separat, un conjunt de fitxers al disc per a cada inserció). Llavors ve la següent inserció, i al fons es combinen en "particions" més grans. Com que les dades estan ordenades, és possible "fusionar" dos fitxers ordenats sense consumir molta memòria.
Però, com podeu endevinar, si escriviu 10 fitxers per a cada inserció, ClickHouse (o el vostre servidor) acabarà ràpidament, per la qual cosa es recomana inserir-los en lots grans. En conseqüència, mai vam llançar el primer esquema en producció. Immediatament n'hem llançat un, que aquí el número 2 té:
Aquí imagineu que hi ha uns mil servidors en els quals hem llançat, només hi ha PHP. I a cada servidor hi ha el nostre agent local, que hem anomenat "Kittenhouse", que manté una connexió amb "ClickHouse" i insereix dades cada pocs segons. Insereix dades no a MergeTree, sinó a una taula de memòria intermèdia, que serveix precisament per evitar inserir-les directament a MergeTree immediatament.
Treballar amb taules de memòria intermèdia
Què és això? Les taules de memòria intermèdia són una peça de memòria que es fragmenta (és a dir, es pot inserir-hi amb freqüència). Consten de diverses peces, i cadascuna de les peces funciona com un buffer independent i s'aflueixen de manera independent (si teniu moltes peces al buffer, hi haurà moltes insercions per segon). És possible llegir a partir d'aquestes taules, llavors llegiu la unió del contingut de la memòria intermèdia i la taula pare, però en aquest moment l'escriptura està bloquejada, per la qual cosa és millor no llegir des d'allà. I les taules de memòria intermèdia mostren molt bons QPS, és a dir, fins a 3 mil QPS no tindreu cap problema a l'hora d'inserir. És evident que si el servidor perd energia, les dades es poden perdre, perquè només s'emmagatzemaven a la memòria.
Al mateix temps, l'esquema amb una memòria intermèdia complica ALTER, perquè primer cal eliminar la taula de memòria intermèdia antiga amb l'esquema antic (les dades no desapareixeran enlloc, perquè s'esborraran abans que s'elimini la taula). A continuació, "altereu" la taula que necessiteu i torneu a crear la taula de memòria intermèdia. En conseqüència, tot i que no hi ha una taula de memòria intermèdia, les vostres dades no fluiran enlloc, però les podeu tenir al disc almenys localment.
Què és Kittenhouse i com funciona?
Què és KittenHouse? Aquest és un proxy. Endevineu quina llengua? Vaig recollir els temes més exagerats al meu informe: "Clickhouse", Go, potser recordaré alguna cosa més. Sí, això està escrit en Go, perquè realment no sé escriure en C, no vull.
En conseqüència, manté una connexió amb cada servidor i pot escriure a la memòria. Per exemple, si escrivim registres d'errors a Clickhouse, aleshores si Clickhouse no té temps d'inserir dades (al cap i a la fi, si s'escriu massa), aleshores no augmentem la memòria; simplement llencem la resta. Perquè si escrivim diversos gigabits per segon d'errors, probablement podrem llençar-ne alguns. Kittenhouse pot fer això. A més, pot realitzar un lliurament fiable, és a dir, escriure al disc de la màquina local i una vegada cada vegada (allà, cada dos segons) intenta lliurar dades d'aquest fitxer. I al principi vam utilitzar el format de valors normal, no un format binari, un format de text (com en SQL normal).
Però després això va passar. Vam utilitzar un lliurament fiable, vam escriure registres, després vam decidir (era un clúster de prova condicional)... Es va treure durant diverses hores i es va tornar a activar, i va començar una inserció des de mil servidors; va resultar que Clickhouse encara tenia un "Thread on connection": en conseqüència, en mil connexions, una inserció activa condueix a una càrrega mitjana al servidor d'uns mil i mig. Sorprenentment, el servidor va acceptar peticions, però les dades encara es van inserir després d'un temps; però al servidor va ser molt difícil servir-ho...
Afegeix nginx
Aquesta solució per al model Thread per connexió és nginx. Hem instal·lat nginx davant de Clickhouse, alhora que hem configurat l'equilibri per a dues rèpliques (la nostra velocitat d'inserció va augmentar 2 vegades, tot i que no és un fet que hagi de ser així) i hem limitat el nombre de connexions a Clickhouse, al aigües amunt i, per tant, més , que en 50 connexions, sembla que no té sentit inserir.
Aleshores ens vam adonar que aquest esquema generalment té desavantatges, perquè només tenim un nginx aquí. En conseqüència, si aquest nginx es bloqueja, malgrat la presència de rèpliques, perdem dades o, almenys, no escrivim enlloc. Per això hem fet el nostre propi equilibri de càrrega. També ens vam adonar que "Clickhouse" encara és adequat per a registres, i el "dimoni" també va començar a escriure els seus registres a "Clickhouse", molt convenient, per ser honest. Encara el fem servir per a altres "dimonis".
Aleshores vam descobrir aquest problema interessant: si utilitzeu un mètode no estàndard d'inserció en mode SQL, força un analitzador SQL complet basat en AST, que és bastant lent. En conseqüència, hem afegit una configuració per assegurar-nos que això no passi mai. Vam fer equilibri de càrrega, controls de salut, de manera que si un mor, encara deixem les dades. Ara tenim un munt de taules que necessitem per tenir diferents clústers de Clickhouse. I també vam començar a pensar en altres usos; per exemple, volíem escriure registres des dels mòduls nginx, però no saben com comunicar-se amb el nostre RPC. Bé, m'agradaria ensenyar-los com enviar almenys d'alguna manera, per exemple, per rebre esdeveniments a localhost mitjançant UDP i després reenviar-los a Clickhouse.
A un pas de la solució
L'esquema final va començar a semblar així (la quarta versió d'aquest esquema): a cada servidor davant de Clickhouse hi ha nginx (al mateix servidor) i simplement envia les sol·licituds a localhost amb un límit de 50 peces en el nombre de connexions. . I aquest esquema ja funcionava bastant, tot estava força bé amb ell.
Vam viure així durant aproximadament un mes. Tothom estava content, van afegir taules, van afegir, van afegir... En general, va resultar que la manera com vam afegir taules de buffer no era molt òptima (diguem-ho així). Vam fer 16 peces a cada taula i un interval de flash d'un parell de segons; teníem 20 taules i cada taula rebia 8 insercions per segon, i en aquest moment va començar "Clickhouse"... els registres van començar a disminuir. No només no van passar... Per defecte, nginx tenia una cosa tan interessant que si les connexions acabaven a l'aigües amunt, simplement retornava "502" a totes les sol·licituds noves.
I aquí tenim (acabo de mirar els registres del mateix Clickhouse) aproximadament el mig per cent de les sol·licituds han fallat. En conseqüència, la utilització del disc era alta, hi va haver moltes fusions. Bé, què he fet? Naturalment, no em vaig molestar en esbrinar per què van acabar exactament la connexió i aigües amunt.
Substitució de nginx per un servidor intermediari invers
Vaig decidir que ho hem de gestionar nosaltres mateixos, no cal que ho deixem a nginx: nginx no sap quines taules hi ha a Clickhouse, i vaig substituir nginx per un proxy invers, que també vaig escriure jo mateix.
Què està fent? Funciona basat en la biblioteca fasthttp "goshnoy", és a dir, ràpid, gairebé tan ràpid com nginx. Ho sento, Igor, si sou present aquí (nota: Igor Sysoev és un programador rus que va crear el servidor web nginx). Pot entendre quin tipus de consultes són - INSERT o SELECT - en conseqüència, conté diferents grups de connexions per a diferents tipus de consultes.
En conseqüència, encara que no tinguem temps per completar les sol·licituds d'inserció, les "seleccions" passaran, i viceversa. I agrupa les dades en taules de memòria intermèdia -amb un petit buffer: si hi hagués errors, errors de sintaxi, etc.- de manera que no afectarien molt la resta de dades, perquè quan simplement les inserim en taules de memòria intermèdia, tenia un petit "bachi", i tots els errors de sintaxi només afectaven a aquesta petita peça; i aquí ja afectaran un gran buffer. Petit és 1 megabyte, és a dir, no tan petit.
Inserir una sincronització i substituir essencialment nginx fa essencialment el mateix que feia abans nginx: no cal que canvieu el "Kittenhouse" local per a això. I com que fa servir fasthttp, és molt ràpid: podeu fer més de 100 mil sol·licituds per segon per a insercions individuals mitjançant un servidor intermediari invers. Teòricament, podeu inserir una línia a la vegada al servidor intermediari invers de kittenhouse, però, per descomptat, no ho fem.
L'esquema va començar a ser així: "Kittenhouse", el proxy invers agrupa moltes peticions en taules i, al seu torn, les taules de memòria intermèdia les insereixen a les principals.
Killer és una solució temporal, Kitten és permanent
Aquest és un problema interessant... Algú de vosaltres ha utilitzat fasthttp? Qui va utilitzar fasthttp amb sol·licituds POST? Probablement, això realment no s'hauria d'haver fet, perquè emmagatzema el cos de la sol·licitud de manera predeterminada i la nostra mida de memòria intermèdia es va establir en 16 megabytes. La inserció va deixar de mantenir-se al dia en algun moment i van començar a arribar trossos de 16 megabytes de les desenes de milers de servidors, i tots es van guardar en memòria intermèdia abans d'enviar-los a Clickhouse. En conseqüència, la memòria es va esgotar, l'assassí sense memòria va venir i va matar el proxy invers (o "Clickhouse", que teòricament podria "menjar" més que el proxy invers). El cicle es va repetir. No és un problema molt agradable. Tot i que només ens vam trobar amb això després de diversos mesos de funcionament.
El que he fet? Un cop més, no m'agrada molt entendre què va passar exactament. Crec que és bastant obvi que no hauríeu d'emmagatzemar a la memòria. No he pogut pegar ràpid http, tot i que ho he intentat. Però vaig trobar una manera de fer-ho de manera que no hi hagués necessitat de pegar res, i vaig inventar el meu propi mètode en HTTP: el vaig anomenar GATTEN. Bé, és lògic: "VK", "Gatlet"... Què més?...
Si una sol·licitud arriba al servidor amb el mètode Kitten, el servidor hauria de respondre "miau" - lògicament. Si respon a això, es considera que entén aquest protocol i, a continuació, intercepto la connexió (fasthttp té aquest mètode) i la connexió passa al mode "crue". Per què ho necessito? Vull controlar com es produeix la lectura de connexions TCP. TCP té una propietat meravellosa: si ningú llegeix des de l'altre costat, l'escriptura comença a esperar i la memòria no es gasta especialment en això.
I així vaig llegir d'uns 50 clients alhora (a partir de cinquanta perquè segur que n'hi hauria prou amb cinquanta, encara que la tarifa vingui d'un altre DC)... El consum ha disminuït amb aquest plantejament almenys 20 vegades, però jo, sincerament , no he pogut mesurar exactament quina hora, perquè ja no té sentit (ja ha arribat al nivell d'error). El protocol és binari, és a dir, conté el nom i les dades de la taula; no hi ha capçaleres http, així que no vaig fer servir cap socket web (no necessito comunicar-me amb els navegadors: vaig fer un protocol que s'adaptava a les nostres necessitats). I tot li va anar bé.
La taula de buffer és trista
Recentment hem trobat una altra característica interessant de les taules de memòria intermèdia. I aquest problema ja és molt més dolorós que els altres. Imaginem-nos aquesta situació: ja esteu utilitzant Clickhouse activament, teniu desenes de servidors de Clickhouse i teniu algunes sol·licituds que triguen molt a llegir-se (per exemple, més de 60 segons); i vens i fas Alter en aquest moment... Mentrestant, les "seleccions" que van començar abans d'"Alter" no s'inclouran en aquesta taula, "Alter" no començarà, probablement algunes característiques de com funciona "Clickhouse" a aquest lloc. Potser això es pot arreglar? O és impossible?
En general, està clar que en realitat aquest no és un problema tan gran, però amb les taules de memòria intermèdia es fa més dolorós. Perquè, si, diguem, el vostre temps d'espera "Alter" (i pot ser que el temps d'espera en un altre amfitrió, no en el vostre, sinó en una rèplica, per exemple), aleshores... Heu suprimit la taula de memòria intermèdia, el vostre "Alter" ( o algun altre amfitrió) s'ha esgotat. Aleshores s'ha produït un error "Alterar"); encara heu d'assegurar-vos que les dades es continuen escrivint: torneu a crear les taules de memòria intermèdia (segons el mateix esquema que la taula pare) "Alter" passa, acaba després de tot i el buffer de la taula comença a diferir en l'esquema del pare. Depenent del que fos l'"Alter", és possible que la inserció ja no vagi a aquesta taula de memòria intermèdia; això és molt trist.
També hi ha aquest signe (potser algú se n'ha adonat): s'anomena query_thread_log a les noves versions de Clickhouse. Per defecte, en alguna versió n'hi havia un. Aquí hem acumulat 840 milions de registres en un parell de mesos (100 gigabytes). Això es deu al fet que s'hi van escriure "insercions" (potser ara, per cert, no estan escrites). Com us he dit, les nostres "insercions" són petites: teníem moltes "insercions" a les taules de memòria intermèdia. Està clar que això està desactivat; només us dic el que vaig veure al nostre servidor. Per què? Aquest és un altre argument contra l'ús de taules de memòria intermèdia! Spotty està molt trist.
Qui sabia que aquest home es deia Spotty? Els empleats de VK van aixecar la mà. D'ACORD.
Sobre els plans de "KitttenHouse"
Els plans normalment no es comparteixen, oi? De sobte no els compliràs i no et quedaràs molt bé als ulls dels altres. Però m'arriscaré! Volem fer el següent: les taules de buffer, em sembla, encara són una crossa i hem d'amortitzar la inserció nosaltres mateixos. Però encara no volem emmagatzemar-lo al disc, així que guardarem la inserció a la memòria.
En conseqüència, quan es fa una "inserció", ja no serà sincrònica: ja funcionarà com a taula de memòria intermèdia, s'inserirà a la taula pare (bé, algun dia més tard) i informarà a través d'un canal separat quines insercions han passat i quines. no tenir.
Per què no puc deixar la inserció síncrona? És molt més convenient. El fet és que si inseriu des de 10 mil amfitrions, aleshores tot està bé: obtindreu una mica de cada amfitrió, hi introduïu una vegada per segon, tot està bé. Però m'agradaria que aquest esquema funcionés, per exemple, des de dues màquines, de manera que pugueu descarregar-vos a gran velocitat, potser no treure el màxim profit de Clickhouse, però escriu almenys 100 megabytes per segon des d'una màquina mitjançant un servidor intermediari invers. aquest l'esquema s'ha d'escalar tant a grans com a petites quantitats, de manera que no podem esperar un segon per a cada inserció, de manera que ha de ser asíncron. I de la mateixa manera, les confirmacions asíncrones haurien de venir un cop finalitzada la inserció. Sabrem si ha passat o no.
El més important és que en aquest esquema sabem del cert si la inserció es va produir o no. Imagineu aquesta situació: teniu una taula de memòria intermèdia, hi vau escriure alguna cosa i, per exemple, la taula va entrar en mode de només lectura i va intentar esborrar la memòria intermèdia. On aniran les dades? Es mantindran al buffer. Però no podem estar segurs d'això: què passa si hi ha algun altre error, a causa del qual les dades no romandran a la memòria intermèdia... (S'adreça a Alexey Milovidov, Yandex, desenvolupador de ClickHouse) O es mantindrà? Sempre? Alexey ens convenç que tot anirà bé. No tenim cap motiu per no creure'l. Però igualment: si no fem servir taules de memòria intermèdia, no hi haurà cap problema. Crear el doble de taules també és inconvenient, tot i que en principi no hi ha grans problemes. Aquest és el pla.
Parlem de lectura
Ara parlem de la lectura. També hem escrit la nostra pròpia eina aquí. Sembla, bé, per què escriu el teu propi instrument aquí?... I qui va utilitzar Tabix? D'alguna manera poca gent va aixecar la mà... I qui està satisfet amb l'actuació de Tabix? Bé, no estem contents amb això, i no és molt convenient per veure dades. Està bé per analítiques, però només per veure-ho clarament no està optimitzat. Així que vaig escriure la meva, la meva pròpia interfície.
És molt senzill: només pot llegir dades. No sap mostrar gràfics, no sap fer res. Però pot mostrar el que necessitem: per exemple, quantes files hi ha a la taula, quant espai ocupa (sense dividir-lo en columnes), és a dir, una interfície molt bàsica és el que necessitem.
I s'assembla molt a Sequel Pro, però només es fa a Bootstrap de Twitter i la segona versió. Pregunteu: "Yuri, per què a la segona versió?" Quin any? 2018? En general, ho vaig fer fa molt de temps per a "Muscle" (MySQL) i només vaig canviar un parell de línies a les consultes allà, i va començar a funcionar per a "Clickhouse", per la qual cosa agraïm especialment! Com que l'analitzador és molt semblant al "muscular" i les consultes són molt semblants, molt convenient, sobretot al principi.
Bé, pot filtrar taules, pot mostrar l'estructura i el contingut de la taula, permet ordenar, filtrar per columnes, mostra la consulta que ha donat com a resultat el resultat, les files afectades (quantes com a resultat), és a dir, el coses bàsiques per visualitzar dades. Bastant ràpid.
També hi ha un editor. Sincerament, vaig intentar robar tot l'editor de Tabix, però no vaig poder. Però d'alguna manera funciona. En principi, això és tot.
"Clickhouse" és adequat per a caus
Vull dir-vos que Clickhouse, malgrat tots els problemes descrits, és molt adequat per als troncs. El més important és que resol el nostre problema: és molt ràpid i us permet filtrar els registres per columnes. En principi, les taules de buffer no han funcionat bé, però normalment ningú sap per què... Potser ara saps millor on tindreu problemes.
TCP? En general, a VK és habitual utilitzar UDP. I quan vaig fer servir TCP... Per descomptat, ningú em va dir: “Yuri, de què estàs parlant! No pots, necessites UDP". Va resultar que TCP no fa tanta por. L'única cosa és que si tens desenes de milers de compostos actius que escriviu, cal preparar-lo amb una mica més de cura; però és possible, i bastant fàcil.
Em vaig comprometre a publicar "Kittenhouse" i "Lighthouse" a HighLoad Siberia si tothom s'ha subscrit al nostre "backend VK" públic... I ja saps, no tothom s'ha subscrit... Per descomptat, no exigiré que us subscriviu al nostre públic. Encara sou massa, potser algú s'ha ofès, però tot i així, si us plau, subscriviu-vos (i aquí he de fer ulls com els de gat). Això és . Moltes gràcies! Github és nostre . Amb Clickhouse el teu cabell quedarà suau i sedós.
Moderador: - Amics, ara per preguntes. Just després us presentem el certificat d'agraïment i el vostre informe en VHS.
Yuri Nasretdinov (d'ara endavant, YN): – Com vau poder gravar el meu informe en VHS si acabava d'acabar?
Moderador: – Vostè també no pot determinar completament com funcionarà o no "Clickhouse"! Amics, 5 minuts per preguntes!
Les vostres preguntes
Pregunta de l'audiència (d'ara endavant, Q): - Bona tarda. Moltes gràcies pel reportatge. Tinc dues preguntes. Començaré per una cosa frívola: el nombre de lletres t del nom "Kittenhouse" als diagrames (3, 4, 7...) afecta la satisfacció dels gats?
YN: -Quantitat de què?
Z: – Lletra t. Hi ha tres T, al voltant de tres T.
YN: - No ho he arreglat? Bé, és clar que sí! Aquests són productes diferents: només us he estat enganyant durant tot aquest temps. D'acord, estic de broma, no importa. Ah, aquí mateix! No, és el mateix, he fet una errada d'ortografia.
Z: - Gràcies. La segona pregunta és seriosa. Pel que tinc entès, a Clickhouse, les taules de memòria intermèdia viuen exclusivament a la memòria, no s'emmagatzemen al disc i, per tant, no són persistents.
YN: - Sí.
Z: – I al mateix temps, el vostre client emmagatzema al disc, la qual cosa implica una certa garantia de lliurament d'aquests mateixos registres. Però això no està garantit de cap manera a Clickhouse. Expliqueu com es duu a terme la garantia, per què?.. Aquí teniu aquest mecanisme amb més detall
YN: – Sí, teòricament aquí no hi ha contradiccions, perquè quan cau Clickhouse, en realitat es pot detectar de mil maneres diferents. Si Clickhouse es bloqueja (si acaba incorrectament), podeu, a grans trets, rebobinar una mica del vostre registre que vau anotar i començar des del moment en què tot estava exactament bé. Suposem que rebobina un minut, és a dir, es considera que ho has rentat tot en un minut.
Z: – És a dir, “Kittenhouse” aguanta la finestra més temps i, en cas de caiguda, pot reconèixer-la i rebobinar-la?
YN: – Però això és en teoria. A la pràctica, no fem això, i el lliurament fiable és de zero a infinits vegades. Però de mitjana una. Estem satisfets que si Clickhouse es bloqueja per algun motiu o els servidors es "reinicien", perdem una mica. En tots els altres casos, no passarà res.
Z: - Hola. Des del primer moment em va semblar que de fet utilitzaríeu UDP des del principi de l'informe. Tens http, tot això... I la majoria dels problemes que has descrit, segons tinc entès, van ser causats per aquesta solució en particular...
YN: – Què fem servir TCP?
Z: - Bàsicament sí.
YN: - No.
Z: – Va ser amb fasthttp que vau tenir problemes, amb la connexió vau tenir problemes. Si acabés d'utilitzar UDP, t'hauries estalviat temps. Bé, hi hauria problemes amb missatges llargs o alguna cosa més...
YN: - Amb què?
Z: – Amb missatges llargs, ja que potser no encaixa a la MTU, una altra cosa... Bé, pot haver-hi problemes propis. La pregunta és: per què no UDP?
YN: – Crec que els autors que van desenvolupar TCP/IP són molt més intel·ligents que jo i saben millor que jo com serialitzar els paquets (perquè surtin), alhora que ajusten la finestra d'enviament, no sobrecarreguen la xarxa, donen comentaris sobre què no es llegeix, sense comptar amb l'altra banda... Tots aquests problemes, al meu entendre, existirien en UDP, només que jo hauria d'escriure encara més codi del que ja vaig escriure per tal d'implementar el mateix i molt probablement. malament. Ni tan sols m'agrada molt escriure en C, i molt menys...
Z: - Simplement convenient! S'ha enviat bé i no esperis res: és completament asíncron. Va tornar una notificació que tot estava bé; això vol dir que va arribar; Si no arriba, vol dir que és dolent.
YN: – Necessito les dues – Necessito poder enviar les dues amb garantia de lliurament i sense garantia de lliurament. Són dos escenaris diferents. Necessito no perdre alguns registres o no perdre'ls dins del raó.
Z: —No perdré el temps. Això s'ha de parlar més. Gràcies.
Moderador: – Qui té preguntes – mans al cel!
Z: - Hola, sóc la Sasha. En algun lloc del mig de l'informe, va aparèixer la sensació que, a més de TCP, era possible utilitzar una solució ja feta: una mena de Kafka.
YN: – Bé... et vaig dir que no vull fer servir servidors intermedis, perquè... a Kafka, resulta que tenim deu mil hosts; de fet, tenim més: desenes de milers d'amfitrions. També pot ser dolorós fer-ho amb Kafka sense cap proxy. A més, el més important, encara dóna "latència", ofereix amfitrions addicionals que necessiteu. Però no vull tenir-los, vull...
Z: "Però al final va resultar així de totes maneres".
YN: – No, no hi ha amfitrions! Tot això funciona als amfitrions de Clickhouse.
Z: - Bé, i "Kittenhouse", que és al revés, on viu?
YN: – A l'amfitrió Clickhouse, no escriu res al disc.
Z: - Suposem.
Moderador: - Estàs satisfet? Et podem donar un sou?
Z: - Si, tu pots. De fet, hi ha moltes crosses per aconseguir el mateix, i ara, la resposta anterior sobre el tema de TCP contradiu, al meu entendre, aquesta situació. Em sembla que tot s'hauria pogut fer de genolls en molt menys temps.
YN: – I també per què no volia fer servir Kafka, perquè hi havia força queixes al xat de Clickhouse Telegram que, per exemple, es van perdre missatges de Kafka. No del mateix Kafka, sinó en la integració de Kafka i Clickhaus; o alguna cosa no s'hi connectava. A grans trets, llavors seria necessari escriure un client per a Kafka. No crec que hi hagi una solució més senzilla o més fiable.
Z: – Digues-me, per què no has provat cap cua o algun tipus d’autobús comú? Com que dieu que amb asincronia podríeu enviar els mateixos registres a través de la cua i rebre la resposta de manera asíncrona a través de la cua?
YN: – Si us plau, suggereix quines cues es podrien utilitzar?
Z: – Qualsevol, fins i tot sense garantia que estan en ordre. Una mena de Redis, RMQ...
YN: – Tinc la sensació que el més probable és que Redis no serà capaç d'aconseguir aquest volum d'inserció ni tan sols en un host (en el sentit de diversos servidors) que tregui Clickhouse. No puc avalar-ho amb cap evidència (no ho he comparat), però em sembla que Redis no és la millor solució aquí. En principi, aquest sistema es pot considerar com una cua de missatges improvisada, però que només s'adapta a "Clickhouse"
Moderador: —Yuri, moltes gràcies. Proposo acabar aquí les preguntes i respostes i dir a quins dels qui van fer la pregunta donarem el llibre.
YN: – M'agradaria regalar un llibre a la primera persona que va fer una pregunta.
Moderador: - Meravellós! Genial! Fabulós! Moltes gràcies!
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com