HighLoad++ Mosca 2018, Sala Congressi. 9 novembre, 15:00
Abstract e presentazione:
Yuri Nasretdinov (VKontakte): il rapporto parlerà dell'esperienza di implementazione di ClickHouse nella nostra azienda: perché ne abbiamo bisogno, quanti dati memorizziamo, come li scriviamo e così via.
Materiali aggiuntivi:
Yuri Nasretdinov: - Ciao a tutti! Mi chiamo Yuri Nasretdinov, come mi è già stato presentato. Lavoro a VKontakte. Parlerò di come inseriamo i dati in ClickHouse dalla nostra flotta di server (decine di migliaia).
Cosa sono i log e perché raccoglierli?
Cosa ti diremo: cosa abbiamo fatto, perché avevamo bisogno di "ClickHouse", rispettivamente, perché l'abbiamo scelto, che tipo di prestazioni puoi ottenere approssimativamente senza configurare nulla di speciale. Ti parlerò ulteriormente delle tabelle buffer, dei problemi che abbiamo avuto con esse e delle nostre soluzioni che abbiamo sviluppato dall'open source: KittenHouse e Lighthouse.
Perché abbiamo dovuto fare qualcosa (va sempre tutto bene su VKontakte, giusto?). Volevamo raccogliere log di debug (e lì c'erano centinaia di terabyte di dati), forse in qualche modo sarebbe stato più conveniente calcolare le statistiche; e disponiamo di un parco di decine di migliaia di server da cui è necessario eseguire tutto ciò.
Perché abbiamo deciso? Probabilmente avevamo soluzioni per archiviare i log. Qui – esiste un tale "Backend VK" pubblico. Consiglio vivamente di abbonarsi.
Cosa sono i log? Questo è un motore che restituisce array vuoti. I motori in VK sono ciò che gli altri chiamano microservizi. Ed ecco un adesivo sorridente (molti Mi piace). Come mai? Bene, ascolta ulteriormente!
Cosa può essere utilizzato per archiviare i log? Impossibile non citare Hadup. Quindi, ad esempio, Rsyslog (memorizza questi log nei file). L'LSD. Chi sa cos'è l'LSD? No, non questo LSD. Memorizza anche i file, rispettivamente. Bene, ClickHouse è un'opzione strana.
Clickhouse e concorrenti: esigenze e opportunità
Cosa vogliamo? Vogliamo assicurarci di non doverci preoccupare troppo del funzionamento, in modo che funzioni fuori dagli schemi, preferibilmente con una configurazione minima. Vogliamo scrivere molto e scrivere velocemente. E vogliamo conservarlo per tutti i tipi di mesi, anni, cioè per molto tempo. Potremmo voler capire qualche problema con cui sono venuti da noi e hanno detto: "Qualcosa non funziona qui", e questo è successo 3 mesi fa), e vogliamo essere in grado di vedere cosa è successo 3 mesi fa " Compressione dei dati – è chiaro il motivo per cui sarebbe un vantaggio – perché riduce la quantità di spazio occupato.
E abbiamo un requisito così interessante: a volte scriviamo l'output di alcuni comandi (ad esempio i log), può essere abbastanza facilmente più di 4 kilobyte. E se questa cosa funziona su UDP, non è necessario spendere... non avrà alcun "overhead" per la connessione e per un gran numero di server questo sarà un vantaggio.
Vediamo cosa ci offre l'open source. Innanzitutto abbiamo il Logs Engine: questo è il nostro motore; In linea di principio può fare tutto, può anche scrivere lunghe righe. Beh, non comprime i dati in modo trasparente: possiamo comprimere noi stessi le colonne di grandi dimensioni se vogliamo... ovviamente non vogliamo (se possibile). L'unico problema è che sa donare solo ciò che rientra nella sua memoria; Per leggere il resto è necessario procurarsi il binlog di questo motore e, di conseguenza, ci vuole parecchio tempo.
Quali altre opzioni ci sono? Ad esempio, "Hadup". Facilità di utilizzo... Chi pensa che Hadup sia facile da configurare? Naturalmente non ci sono problemi con la registrazione. Durante la lettura a volte sorgono domande. In linea di principio, direi probabilmente di no, soprattutto per i log. Archiviazione a lungo termine - ovviamente sì, compressione dei dati - sì, stringhe lunghe - è chiaro che puoi registrare. Ma registrando da un gran numero di server... Devi comunque fare qualcosa da solo!
Rsyslog. Infatti l'abbiamo usato come opzione di backup per poterlo leggere senza scaricare il binlog, ma non può scrivere righe lunghe; in linea di principio non può scrivere più di 4 kilobyte. Devi eseguire tu stesso la compressione dei dati allo stesso modo. La lettura verrà dai file.
Poi c’è lo sviluppo “badushka” dell’LSD. In sostanza è uguale a "Rsyslog": supporta stringhe lunghe, ma non può funzionare tramite UDP e, infatti, per questo motivo, purtroppo, molte cose devono essere riscritte lì. L'LSD deve essere riprogettato per poter registrare da decine di migliaia di server.
E qui! Un'opzione divertente è ElasticSearch. Come dire? Se la cava bene con la lettura, cioè legge velocemente, ma non molto bene con la scrittura. Innanzitutto, se comprime i dati, è molto debole. Molto probabilmente, una ricerca completa richiede strutture dati più grandi rispetto al volume originale. È difficile da usare e spesso sorgono problemi. E, ancora una volta, registrando in Elastic: dobbiamo fare tutto da soli.
Qui ClickHouse è ovviamente un'opzione ideale. L'unica cosa è che la registrazione da decine di migliaia di server è un problema. Ma almeno c’è un problema e possiamo provare a risolverlo in qualche modo. E il resto del rapporto riguarda questo problema. Che tipo di prestazioni puoi aspettarti da ClickHouse?
Come lo inseriremo? Uniscialbero
Chi di voi non ha sentito parlare o non conosce “ClickHouse”? Devo dirtelo, vero? Molto veloce. L'inserimento lì - 1-2 gigabit al secondo, raffiche fino a 10 gigabit al secondo può effettivamente resistere a questa configurazione - ci sono due Xeon a 6 core (cioè nemmeno il più potente), 256 gigabyte di RAM, 20 terabyte in RAID (nessuno configurato, impostazioni predefinite). Alexey Milovidov, sviluppatore di ClickHouse, probabilmente è seduto lì a piangere perché non abbiamo configurato nulla (per noi ha funzionato tutto così). Di conseguenza, se i dati sono ben compressi, è possibile ottenere una velocità di scansione di circa 6 miliardi di linee al secondo. Se ti piace % su una stringa di testo - 100 milioni di righe al secondo, sembra abbastanza veloce.
Come lo inseriremo? Bene, sai che VK usa PHP. Inseriremo da ciascun PHP Worker tramite HTTP in “ClickHouse”, nella tabella MergeTree per ciascun record. Chi vede un problema con questo schema? Per qualche ragione, non tutti hanno alzato la mano. Lascia che ti dica.
In primo luogo, ci sono molti server, di conseguenza ci saranno molte connessioni (cattive). Quindi è meglio inserire i dati in MergeTree non più spesso di una volta al secondo. E chissà perché? Ok ok. Ti dirò qualcosa in più su questo. Un'altra domanda interessante è che non stiamo facendo analisi, non abbiamo bisogno di arricchire i dati, non abbiamo bisogno di server intermedi, vogliamo inserirli direttamente in "ClickHouse" (preferibilmente - più direttamente, meglio è).
Di conseguenza, come viene eseguito l'inserimento in MergeTree? Perché è meglio inserirlo non più spesso di una volta al secondo o meno spesso? Il fatto è che “ClickHouse” è un database a colonne e ordina i dati in ordine crescente della chiave primaria, e quando si esegue un inserimento, viene creato un numero di file almeno uguale al numero di colonne in cui sono ordinati i dati in ordine crescente della chiave primaria (viene creata una directory separata, un insieme di file su disco per ogni inserimento). Poi arriva l'inserimento successivo e sullo sfondo vengono combinati in “partizioni” più grandi. Poiché i dati sono ordinati, è possibile “unire” due file ordinati senza consumare molta memoria.
Ma, come puoi immaginare, se scrivi 10 file per ogni inserimento, ClickHouse (o il tuo server) terminerà rapidamente, quindi si consiglia di inserirli in grandi batch. Di conseguenza, non abbiamo mai messo in produzione il primo schema. Ne abbiamo subito lanciato uno, che qui il numero 2 ha:
Qui immaginiamo che ci siano circa un migliaio di server su cui abbiamo lanciato, c'è solo PHP. E su ogni server c'è il nostro agente locale, che abbiamo chiamato “Kittenhouse”, che mantiene una connessione con “ClickHouse” e inserisce dati ogni pochi secondi. Inserisce i dati non in MergeTree, ma in una tabella buffer, che serve proprio per evitare di inserirli direttamente in MergeTree.
Lavorare con le tabelle buffer
Cos'è? Le tabelle buffer sono parti di memoria frammentate (ovvero possono essere inserite frequentemente). Sono costituiti da diversi pezzi e ciascuno di essi funziona come un buffer indipendente e vengono scaricati in modo indipendente (se sono presenti molti pezzi nel buffer, ci saranno molti inserimenti al secondo). È possibile leggere da queste tabelle - quindi leggi l'unione del contenuto del buffer e della tabella genitore, ma in questo momento la scrittura è bloccata, quindi è meglio non leggere da lì. E le tabelle buffer mostrano un QPS molto buono, ovvero fino a 3mila QPS non avrai alcun problema durante l'inserimento. È chiaro che se il server perde energia, i dati possono andare persi, perché erano archiviati solo in memoria.
Allo stesso tempo, lo schema con un buffer complica ALTER, perché devi prima eliminare la vecchia tabella del buffer con il vecchio schema (i dati non scompariranno da nessuna parte, perché verranno svuotati prima che la tabella venga eliminata). Quindi "modifichi" la tabella che ti serve e crei nuovamente la tabella buffer. Di conseguenza, sebbene non sia presente una tabella buffer, i tuoi dati non fluiranno da nessuna parte, ma puoi averli su disco almeno localmente.
Cos'è Kittenhouse e come funziona?
Cos'è KittenHouse? Questo è un proxy. Indovina che lingua? Ho raccolto gli argomenti più hype nel mio rapporto: "Clickhouse", Vai, forse ricorderò qualcos'altro. Sì, questo è scritto in Go, perché non so davvero come scrivere in C, non voglio.
Di conseguenza, mantiene una connessione con ciascun server e può scrivere in memoria. Ad esempio, se scriviamo i log degli errori in Clickhouse, se Clickhouse non ha il tempo di inserire i dati (dopo tutto, se ne vengono scritti troppi), non gonfiamo la memoria, semplicemente buttiamo via il resto. Perché se scriviamo diversi gigabit al secondo di errori, probabilmente ne possiamo eliminare alcuni. Kittenhouse può farlo. Inoltre, può eseguire una consegna affidabile, ovvero scrivere su disco sul computer locale e una volta ogni volta (lì, una volta ogni paio di secondi) tenta di consegnare i dati da questo file. E all'inizio abbiamo utilizzato il normale formato Valori, non un formato binario, un formato di testo (come nel normale SQL).
Ma poi è successo questo. Abbiamo utilizzato una consegna affidabile, scritto i log, poi abbiamo deciso (era un cluster di test condizionale)... È stato pubblicato per diverse ore e poi ripristinato, e un inserimento è iniziato da un migliaio di server - si è scoperto che Clickhouse aveva ancora un "Thread on connessione" - rispettivamente, su mille connessioni, un inserimento attivo porta ad un carico medio sul server di circa mille e mezzo. Sorprendentemente, il server accettava le richieste, ma i dati venivano comunque inseriti dopo un po' di tempo; ma era molto difficile per il server servirlo...
Aggiungi nginx
Una soluzione di questo tipo per il modello Thread per connessione è nginx. Abbiamo installato nginx davanti a Clickhouse, impostando allo stesso tempo il bilanciamento per due repliche (la nostra velocità di inserimento è aumentata di 2 volte, anche se non è un dato di fatto che dovrebbe essere così) e limitato il numero di connessioni a Clickhouse, a a monte e, di conseguenza, più di 50 connessioni, sembra che non abbia senso inserirle.
Poi ci siamo resi conto che questo schema generalmente presenta degli svantaggi, perché qui abbiamo solo un nginx. Di conseguenza, se questo nginx si blocca, nonostante la presenza di repliche, perdiamo dati o, almeno, non scriviamo da nessuna parte. Ecco perché abbiamo creato il nostro bilanciamento del carico. Ci siamo anche resi conto che "Clickhouse" è ancora adatto ai log e anche il "demone" ha iniziato a scrivere i suoi log in "Clickhouse" - molto conveniente, a dire il vero. Lo usiamo ancora per altri “demoni”.
Poi abbiamo scoperto questo problema interessante: se si utilizza un metodo non standard di inserimento in modalità SQL, viene forzato un parser SQL completo basato su AST, che è piuttosto lento. Di conseguenza, abbiamo aggiunto impostazioni per garantire che ciò non accada mai. Abbiamo effettuato il bilanciamento del carico e i controlli sanitari, in modo che se uno muore, lasciamo comunque i dati. Ora abbiamo molte tabelle di cui abbiamo bisogno per avere diversi cluster Clickhouse. E abbiamo iniziato a pensare anche ad altri usi: ad esempio, volevamo scrivere i log dai moduli nginx, ma non sanno come comunicare utilizzando il nostro RPC. Bene, vorrei insegnare loro come inviare almeno in qualche modo, ad esempio ricevere eventi su localhost tramite UDP e quindi inoltrarli a Clickhouse.
Ad un passo dalla soluzione
Lo schema finale cominciò ad assomigliare a questo (la quarta versione di questo schema): su ogni server davanti a Clickhouse c'è nginx (sullo stesso server) e semplicemente inoltra le richieste a localhost con un limite al numero di connessioni di 50 pezzi. E questo schema funzionava già abbastanza, tutto andava abbastanza bene.
Abbiamo vissuto così per circa un mese. Tutti erano contenti, hanno aggiunto tabelle, hanno aggiunto, hanno aggiunto... In generale, si è scoperto che il modo in cui abbiamo aggiunto le tabelle buffer non era molto ottimale (mettiamola così). Abbiamo realizzato 16 pezzi in ogni tavola e un intervallo flash di un paio di secondi; avevamo 20 tavole e ciascuna tavola riceveva 8 inserti al secondo - e a questo punto è iniziata “Clickhouse”... i record hanno cominciato a rallentare. Non sono nemmeno andati fino in fondo... Nginx per impostazione predefinita aveva una cosa così interessante che se le connessioni terminavano a monte, restituiva semplicemente "502" a tutte le nuove richieste.
E qui abbiamo (ho appena guardato i log nella stessa Clickhouse) circa la metà delle richieste non riuscite. Di conseguenza, l'utilizzo del disco è stato elevato e sono state effettuate molte fusioni. Bene, cosa ho fatto? Naturalmente, non mi sono preoccupato di capire perché esattamente la connessione e l'upstream sono finiti.
Sostituzione di nginx con un proxy inverso
Ho deciso che dobbiamo gestirlo da soli, non dobbiamo lasciarlo a nginx: nginx non sa quali tabelle ci sono in Clickhouse e ho sostituito nginx con un proxy inverso, che ho scritto anch'io.
Cosa sta facendo? Funziona sulla base della libreria fasthttp “goshnoy”, cioè veloce, quasi veloce come nginx. Scusa, Igor, se sei presente qui (nota: Igor Sysoev è un programmatore russo che ha creato il server web nginx). Può capire che tipo di query sono – INSERT o SELECT – di conseguenza, contiene diversi pool di connessioni per diversi tipi di query.
Di conseguenza, anche se non avremo il tempo di completare le richieste di inserimento, passeranno le “seleziona”, e viceversa. E raggruppa i dati in tabelle buffer - con un piccolo buffer: se ci fossero errori, errori di sintassi e così via - in modo che non influenzino notevolmente il resto dei dati, perché quando li inseriamo semplicemente nelle tabelle buffer, noi aveva un piccolo "bachi" e tutti gli errori di sintassi riguardavano solo questo piccolo pezzo; e qui influenzeranno già un ampio buffer. Piccolo è 1 megabyte, cioè non così piccolo.
L'inserimento di una sincronizzazione e la sostituzione sostanziale di nginx fa essenzialmente la stessa cosa che nginx faceva prima: non è necessario modificare la "Kittenhouse" locale per questo. E poiché utilizza fasthttp, è molto veloce: puoi effettuare più di 100mila richieste al secondo per singoli inserimenti tramite un proxy inverso. In teoria, puoi inserire una riga alla volta nel proxy inverso di Kittenhouse, ma ovviamente non lo facciamo.
Lo schema cominciò ad assomigliare a questo: “Kittenhouse”, il proxy inverso raggruppa molte richieste in tabelle e, a loro volta, le tabelle buffer le inseriscono in quelle principali.
Killer è una soluzione temporanea, Kitten è permanente
Questo è un problema interessante... Qualcuno di voi ha usato fasthttp? Chi ha utilizzato fasthttp con richieste POST? Probabilmente, questo non avrebbe dovuto essere fatto, perché memorizza nel buffer il corpo della richiesta per impostazione predefinita e la dimensione del nostro buffer è stata impostata su 16 megabyte. Ad un certo punto l'inserimento ha smesso di tenere il passo e blocchi da 16 megabyte hanno cominciato ad arrivare da tutte le decine di migliaia di server, e sono stati tutti bufferizzati in memoria prima di essere inviati a Clickhouse. Di conseguenza, la memoria si è esaurita, è arrivato l'Out-Of-Memory Killer e ha ucciso il proxy inverso (o "Clickhouse", che teoricamente potrebbe "mangiare" più del proxy inverso). Il ciclo si è ripetuto. Non è un problema molto piacevole. Anche se ci siamo imbattuti in questo solo dopo diversi mesi di funzionamento.
Quello che ho fatto? Ancora una volta, non mi piace davvero capire cosa sia successo esattamente. Penso che sia abbastanza ovvio che non dovresti bufferizzare in memoria. Non sono riuscito a patchare fasthttp, anche se ci ho provato. Ma ho trovato un modo per fare in modo che non ci fosse bisogno di patchare nulla e ho ideato il mio metodo in HTTP: l'ho chiamato KITTEN. Beh, è logico: "VK", "Kitten"... Cos'altro?..
Se una richiesta arriva al server con il metodo Kitten, il server dovrebbe rispondere "miao" - logicamente. Se risponde a questo, si ritiene che comprenda questo protocollo, quindi intercetto la connessione (fasthttp ha un metodo del genere) e la connessione entra in modalità "grezza". Perché ne ho bisogno? Voglio controllare come avviene la lettura dalle connessioni TCP. TCP ha una proprietà meravigliosa: se nessuno legge dall'altra parte, la scrittura inizia ad attendere e la memoria non viene particolarmente spesa per questo.
E così leggo da circa 50 clienti alla volta (da cinquanta perché cinquanta dovrebbero sicuramente bastare, anche se la tariffa viene da un altro DC)... I consumi con questo approccio sono diminuiti almeno di 20 volte, ma io, a dire il vero, , non potrei misurare esattamente l'ora, perché è già inutile (ha già raggiunto il livello di errore). Il protocollo è binario, ovvero contiene il nome della tabella e i dati; non ci sono intestazioni http, quindi non ho utilizzato un socket web (non ho bisogno di comunicare con i browser, ho creato un protocollo adatto alle nostre esigenze). E tutto è andato bene con lui.
La tabella dei buffer è triste
Recentemente ci siamo imbattuti in un'altra caratteristica interessante delle tabelle buffer. E questo problema è già molto più doloroso degli altri. Immaginiamo questa situazione: stai già utilizzando attivamente Clickhouse, hai decine di server Clickhouse, e hai alcune richieste che impiegano molto tempo per essere lette (diciamo più di 60 secondi); e vieni e fai Alter in questo momento... Nel frattempo, le "seleziona" iniziate prima di "Alter" non saranno incluse in questa tabella, "Alter" non verrà avviato - probabilmente alcune caratteristiche di come funziona "Clickhouse" in questo posto. Forse questo può essere risolto? Oppure è impossibile?
In generale, è chiaro che in realtà questo non è un grosso problema, ma con le tabelle buffer diventa più doloroso. Perché, se, diciamo, il tuo "Alter" va in timeout (e potrebbe scadere su un altro host - non sul tuo, ma su una replica, per esempio), allora... Hai eliminato la tabella buffer, il tuo "Alter" ( o qualche altro host) è scaduto, quindi si è verificato un errore "Alter") - è comunque necessario assicurarsi che i dati continuino ad essere scritti: si creano nuovamente le tabelle buffer (secondo lo stesso schema della tabella padre), quindi "Alter" passa, finisce e il buffer della tabella inizia a differire nello schema dal genitore. A seconda di cosa fosse l'"Alter", l'inserto potrebbe non andare più in questa tabella buffer: questo è molto triste.
Esiste anche un simbolo del genere (forse qualcuno l'ha notato): si chiama query_thread_log nelle nuove versioni di Clickhouse. Per impostazione predefinita, in alcune versioni ce n'era uno. Qui abbiamo accumulato in un paio di mesi 840 milioni di dischi (100 gigabyte). Ciò è dovuto al fatto che lì sono stati scritti degli "inserti" (forse ora, a proposito, non sono scritti). Come ti ho detto, i nostri "inserti" sono piccoli: ne avevamo molti nelle tabelle buffer. È chiaro che questo è disabilitato: ti sto solo dicendo quello che ho visto sul nostro server. Perché? Questo è un altro argomento contro l'utilizzo delle tabelle buffer! Spotty è molto triste.
Chi sapeva che il nome di questo ragazzo era Spotty? I dipendenti di VK hanno alzato la mano. OK.
Informazioni sui progetti per “KitttenHouse”
Solitamente i piani non vengono condivisi, giusto? All’improvviso non li realizzerai e non sembrerai molto bello agli occhi degli altri. Ma correrò il rischio! Vogliamo fare quanto segue: le tabelle buffer, mi sembra, sono ancora una stampella e dobbiamo bufferizzare noi stessi l'inserimento. Ma non vogliamo ancora memorizzarlo nel buffer su disco, quindi bufferizzeremo l'inserimento in memoria.
Di conseguenza, quando viene effettuato un "inserimento", non sarà più sincrono: funzionerà già come tabella buffer, si inserirà nella tabella genitore (beh, un giorno dopo) e riporterà tramite un canale separato quali inserti sono passati e quali non aver.
Perché non posso uscire dall'inserimento sincrono? È molto più conveniente. Il fatto è che se inserisci da 10mila host, allora va tutto bene: otterrai un po 'da ciascun host, inserisci lì una volta al secondo, va tutto bene. Ma mi piacerebbe che questo schema funzionasse, ad esempio, da due macchine, in modo da poter scaricare ad alta velocità - magari non ottenere il massimo da Clickhouse, ma scrivere almeno 100 megabyte al secondo da una macchina tramite un proxy inverso - questo lo schema deve scalare sia per grandi che per piccole quantità, quindi non possiamo aspettare un secondo per ogni inserimento, quindi deve essere asincrono. E allo stesso modo, le conferme asincrone dovrebbero arrivare dopo che l'inserimento è stato completato. Sapremo se è passato o meno.
La cosa più importante è che in questo schema sappiamo con certezza se l'inserimento è avvenuto oppure no. Immagina questa situazione: hai una tabella buffer, ci hai scritto qualcosa e poi, diciamo, la tabella è entrata in modalità di sola lettura e ha provato a svuotare il buffer. Dove andranno i dati? Rimarranno nel buffer. Ma non possiamo esserne sicuri: e se si verificasse qualche altro errore, a causa del quale i dati non rimarranno nel buffer... (Si rivolge ad Alexey Milovidov, Yandex, sviluppatore ClickHouse) O rimarranno? Sempre? Alexey ci convince che andrà tutto bene. Non abbiamo motivo di non credergli. Ma comunque: se non utilizziamo le tabelle buffer, non ci saranno problemi con esse. Anche creare il doppio delle tabelle è scomodo, anche se in linea di principio non ci sono grossi problemi. Questo è il piano.
Parliamo di lettura
Ora parliamo della lettura. Abbiamo anche scritto il nostro strumento qui. Sembrerebbe, beh, perché scrivere il tuo strumento qui?... E chi ha usato Tabix? In qualche modo poche persone hanno alzato la mano... E chi è soddisfatto della performance di Tabix? Bene, non ne siamo soddisfatti e non è molto comodo per visualizzare i dati. Va bene per l'analisi, ma solo per la visualizzazione chiaramente non è ottimizzato. Quindi ho scritto la mia, la mia interfaccia.
È molto semplice: può solo leggere i dati. Non sa mostrare la grafica, non sa fare nulla. Ma può mostrare ciò di cui abbiamo bisogno: ad esempio quante righe ci sono nella tabella, quanto spazio occupa (senza suddividerla in colonne), cioè un'interfaccia molto semplice è ciò di cui abbiamo bisogno.
E sembra molto simile a Sequel Pro, ma realizzato solo su Bootstrap di Twitter e sulla seconda versione. Tu chiedi: "Yuri, perché nella seconda versione?" Che anno? 2018? In generale, l'ho fatto molto tempo fa per "Muscle" (MySQL) e ho appena cambiato un paio di righe nelle query lì, e ha iniziato a funzionare per "Clickhouse", per il quale un ringraziamento speciale! Perché il parser è molto simile a quello "muscolare" e le query sono molto simili: molto convenienti, soprattutto all'inizio.
Ebbene, può filtrare le tabelle, può mostrare la struttura e il contenuto della tabella, permette di ordinare, filtrare per colonne, mostra la query che ha dato come risultato, le righe interessate (quante come risultato), cioè il cose basilari per la visualizzazione dei dati. Molto veloce.
C'è anche un editore. Onestamente ho provato a rubare l'intero editor da Tabix, ma non ci sono riuscito. Ma in qualche modo funziona. In linea di principio, questo è tutto.
"Clickhouse" è adatto per le tane
Voglio dirti che Clickhouse, nonostante tutti i problemi descritti, si adatta molto bene ai log. Soprattutto, risolve il nostro problema: è molto veloce e ti consente di filtrare i log per colonne. In linea di principio, le tabelle buffer non hanno funzionato bene, ma di solito nessuno sa perché... Forse ora sai meglio dove avrai problemi.
TCP? In generale, in VK è consuetudine utilizzare UDP. E quando usavo TCP... Ovviamente nessuno mi ha detto: “Yuri, di cosa stai parlando! Non puoi, hai bisogno dell’UDP.” Si è scoperto che TCP non è così spaventoso. L'unica cosa è che, se hai decine di migliaia di composti attivi che scrivi, devi prepararli con un po' più attenzione; ma è possibile, e abbastanza facile.
Ho promesso di pubblicare "Kittenhouse" e "Lighthouse" su HighLoad Siberia se tutti si fossero iscritti al nostro "backend VK" pubblico... E sai, non tutti si sono iscritti... Ovviamente non ti chiederò di iscriverti al nostro pubblico. Siete ancora troppi, qualcuno potrebbe anche offendersi, ma comunque iscrivetevi (e qui devo fare gli occhi da gatto). Quello è . Grazie mille! Github è nostro . Con Clickhouse i tuoi capelli saranno morbidi e setosi.
Moderatore: - Amici, ora le domande. Subito dopo ti presentiamo l'attestato di apprezzamento e la tua segnalazione su VHS.
Yuri Nasretdinov (di seguito denominato YN): – Come hai potuto registrare il mio reportage su VHS se era appena finito?
Moderatore: – Inoltre, non puoi determinare completamente come funzionerà o meno “Clickhouse”! Amici, 5 minuti per le domande!
domande
Domanda del pubblico (di seguito denominata Q): - Buon pomeriggio. Grazie mille per la segnalazione. Ho due domande. Inizierò con una cosa frivola: il numero di lettere t nel nome "Kittenhouse" negli schemi (3, 4, 7...) influisce sulla soddisfazione dei gatti?
YN: - Quantità di cosa?
Z: – Lettera t. Ci sono tre t, da qualche parte intorno alle tre t.
YN: - Non ho risolto il problema? Beh, certo che lo fa! Questi sono prodotti diversi: ti ho solo ingannato per tutto questo tempo. Ok, sto scherzando, non importa. Ah, proprio qui! No, è la stessa cosa, ho fatto un errore di battitura.
Z: - Grazie. La seconda questione è seria. Per quanto ho capito, in Clickhouse le tabelle buffer vivono esclusivamente in memoria, non vengono bufferizzate su disco e, di conseguenza, non sono persistenti.
YN: - Sì.
Z: – E allo stesso tempo, il tuo client esegue il buffering su disco, il che implica una certa garanzia di consegna degli stessi log. Ma questo non è affatto garantito da Clickhouse. Spiegare come viene effettuata la garanzia, a causa di cosa?... Ecco questo meccanismo più nel dettaglio
YN: – Sì, in teoria non ci sono contraddizioni, perché quando Clickhouse cade, puoi effettivamente rilevarlo in un milione di modi diversi. Se Clickhouse si blocca (se termina in modo errato), puoi, grosso modo, riavvolgere un po' del tuo log che hai annotato e ricominciare dal momento in cui tutto andava esattamente bene. Diciamo che riavvolgi un minuto, cioè si considera che hai scaricato tutto in un minuto.
Z: – Cioè “Kittenhouse” tiene la finestra più a lungo e, in caso di caduta, riesce a riconoscerla e a riavvolgerla?
YN: – Ma questo è in teoria. In pratica, non lo facciamo e la consegna affidabile va da zero a infinite volte. Ma in media uno. Siamo convinti che se Clickhouse si arresta in modo anomalo per qualche motivo o i server si “riavviano”, allora perdiamo un po'. In tutti gli altri casi non accadrà nulla.
Z: - Ciao. Fin dall'inizio mi è sembrato che avreste effettivamente utilizzato UDP fin dall'inizio della relazione. Hai http, tutto il resto... E la maggior parte dei problemi che hai descritto, a quanto ho capito, sono stati causati da questa particolare soluzione...
YN: – Cosa usiamo TCP?
Z: - Essenzialmente sì.
YN: - No.
Z: – Era con fasthttp che hai avuto problemi, con la connessione hai avuto problemi. Se avessi usato solo UDP avresti risparmiato un po' di tempo. Beh, ci sarebbero problemi con i messaggi lunghi o qualcos'altro...
YN: - Con Cosa?
Z: – Con messaggi lunghi, poiché potrebbe non rientrare nella MTU, qualcos'altro... Beh, potrebbero esserci problemi propri. La domanda è: perché non UDP?
YN: – Credo che gli autori che hanno sviluppato TCP/IP siano molto più intelligenti di me e sappiano meglio di me come serializzare i pacchetti (in modo che vadano), allo stesso tempo regolare la finestra di invio, non sovraccaricare la rete, dare feedback su cosa non viene letto, senza contare dall'altra parte... Tutti questi problemi, secondo me, esisterebbero in UDP, solo che dovrei scrivere ancora più codice di quello che ho già scritto per implementare la stessa cosa da solo e molto probabilmente male. Non mi piace nemmeno molto scrivere in C, figuriamoci lì...
Z: - Semplicemente conveniente! Inviato ok e non aspettare nulla: è completamente asincrono. È arrivata una notifica che tutto andava bene, ciò significa che è arrivata; Se non arriva vuol dire che è brutto.
YN: – Ho bisogno di entrambi – Ho bisogno di poter inviare entrambi con garanzia di consegna e senza garanzia di consegna. Si tratta di due scenari diversi. Devo non perdere alcuni registri o non perderli entro limiti ragionevoli.
Z: – Non perderò tempo. Questo deve essere discusso di più. Grazie.
Moderatore: – Chi ha domande – mani al cielo!
Z: - Ciao, sono Sasha. Da qualche parte nel mezzo del rapporto è emersa la sensazione che, oltre a TCP, fosse possibile utilizzare una soluzione già pronta: una sorta di Kafka.
YN: – Beh... ti ho detto che non voglio usare server intermedi, perché... in Kafka risulta che abbiamo diecimila host; in effetti ne abbiamo di più: decine di migliaia di host. Può anche essere doloroso avere a che fare con Kafka senza alcun proxy. Inoltre, cosa più importante, fornisce comunque "latenza", fornisce host extra di cui è necessario disporre. Ma non voglio averli, voglio...
Z: "Ma alla fine è andata comunque così."
YN: – No, non ci sono host! Tutto funziona sugli host Clickhouse.
Z: - Bene, e "Kittenhouse", che è il contrario - dove vive?
YN: – Sull'host Clickhouse, non scrive nulla sul disco.
Z: - Supponiamo.
Moderatore: - Sei soddisfatto? Possiamo darti uno stipendio?
Z: - Si, puoi. In effetti, ci sono molte stampelle per ottenere la stessa cosa, e ora - la risposta precedente sul tema TCP contraddice, a mio avviso, questa situazione. Sembra che tutto avrebbe potuto essere fatto in ginocchio in molto meno tempo.
YN: – E anche il motivo per cui non volevo usare Kafka, perché nella chat di Clickhouse Telegram c’erano molte lamentele secondo cui, ad esempio, i messaggi di Kafka erano andati persi. Non da Kafka stesso, ma dall'integrazione di Kafka e Clickhaus; o qualcosa non si collegava lì. In parole povere bisognerebbe allora scrivere un cliente per Kafka. Non credo che possa esserci una soluzione più semplice o più affidabile.
Z: – Dimmi, perché non hai provato con le code o con qualche autobus comune? Dal momento che dici che con l'asincronia potresti inviare i log stessi attraverso la coda e ricevere la risposta in modo asincrono attraverso la coda?
YN: – Per favore suggerisci quali code potrebbero essere utilizzate?
Z: – Qualsiasi, anche senza garanzia che siano in ordine. Una specie di Redis, RMQ...
YN: – Ho la sensazione che molto probabilmente Redis non sarà in grado di ottenere un tale volume di inserimento nemmeno su un host (nel senso di più server) che estrae Clickhouse. Non posso sostenerlo con alcuna prova (non l'ho confrontato), ma mi sembra che Redis non sia la soluzione migliore qui. In linea di principio, questo sistema può essere considerato come una coda di messaggi improvvisata, ma adattata solo per “Clickhouse”
Moderatore: – Yuri, grazie mille. Propongo di terminare qui le domande e le risposte e di dire a chi tra coloro che hanno posto la domanda regaleremo il libro.
YN: – Vorrei regalare un libro alla prima persona che ha fatto una domanda.
Moderatore: - Meraviglioso! Grande! Favoloso! Molte grazie!
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com