{"id":80775,"date":"2020-05-08T13:42:47","date_gmt":"2020-05-08T11:42:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah"},"modified":"2020-05-08T13:42:47","modified_gmt":"2020-05-08T11:42:47","slug":"clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","title":{"rendered":"ClickHouse per utenti avanzati: domande e risposte","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ad aprile, gli ingegneri di Avito si sono riuniti per un incontro online con il principale sviluppatore di ClickHouse, Alexey Milovidov, e Kirill Shvakov, sviluppatore Golang della societ\u00e0 Integros. Hanno discusso di come utilizziamo il sistema di gestione dei database e delle sfide che affrontiamo. <\/p>\n<p><\/p>\n<p>Sulla base di questo incontro, abbiamo redatto un articolo con le risposte degli esperti alle nostre domande e a quelle del pubblico su backup, resharding dei dati, dizionari esterni, driver Golang e aggiornamenti delle versioni di ClickHouse. Pu\u00f2 risultare utile per gli sviluppatori che gi\u00e0 lavorano attivamente con il DBMS di Yandex e sono interessati al presente e al futuro dello stesso. Di norma, le risposte di Alexey Milovidov sono indicate come tali, a meno che non sia diversamente specificato. <\/p>\n<p><\/p>\n<p>Attenzione, sotto questa sezione ci sono molti testi. Speriamo che il contenuto delle domande ti aiuti a orientarti.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse per utenti avanzati: domande e risposte\" src=\"\/wp-content\/uploads\/2020\/05\/242b1d8d002fe115614435c242297fd2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"soderzhanie\">Contenuto<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse viene continuamente aggiornato, mentre i nostri dati no. Cosa fare al riguardo?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">Quali sono le migliori pratiche attualmente disponibili per il backup dei dati da ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">\u00c8 possibile organizzare un ritardo controllato delle repliche nei flussi?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">Cosa fare se la struttura della tabella \u00e8 cambiata?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">Quali sono le migliori pratiche attuali per il resharing dei dati?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">In ClickHouse esiste uno strumento chiamato clickhouse-copier. Puoi parlarne?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Avevate un progetto pilota chiamato resharding. Cosa ne \u00e8 stato?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">\u00c8 possibile unire tutte le parti dei dati in un'unica entit\u00e0 prima di passarle su hard disk lenti?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Come migrare a nuove versioni di ClickHouse se non \u00e8 possibile verificare in anticipo la compatibilit\u00e0?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">Kill query dovrebbe terminare le query, ma non lo fa. Perch\u00e9?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">Come calcolare il tempo di risposta sotto carico in lettura?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">Cosa ottimizzare in ClickHouse affinch\u00e9 maggiore quantit\u00e0 di dati venga mantenuta nella cache?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Come si pu\u00f2 configurare storage_configuration per la memorizzazione in RAM?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">Fino a quanti valori univoci \u00e8 efficace Low Cardinality?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Quali sono le migliori pratiche per la ricerca full-text su una tabella con cinque miliardi di righe?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Come gestire l'accesso a ClickHouse per un gran numero di utenti?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">\u00c8 possibile fornire i risultati di una query a dieci clienti?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">Cosa fare con le operazioni asincrone e le viste materializzate?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">In ClickHouse ci sono molti log. Come posso vedere tutto ci\u00f2 che accade con il server in tempo reale?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">Come intervenire sui merge affinch\u00e9 il server non vada in OOM?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Come si svilupper\u00e0 il driver Golang per ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">Un dizionario esterno non si attiva dopo un riavvio con l'impostazione lazy_load attivata. Cosa fare?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">Cosa fare se il system reload dictionaries non carica nessuno dei numerosi dizionari, se anche solo uno di essi presenta un errore?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">Esiste un modo per configurare le credenziali nel file di configurazione di ClickHouse senza rivelarle in caso di errori?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Bonus: sfondi per Zoom dagli incontri<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Se non vuoi leggere il testo, puoi guardare la registrazione dell'incontro <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">sul nostro canale YouTube<\/a><\/noindex>. I timestamp sono nel primo commento sotto il video.<\/p><\/blockquote>\n<p><\/p>\n<h2 id=\"anchorold-dataanchorclickhouse-postoyanno-obnovlyaetsya-a-nashi-dannyenbsp-net-chto-snbspetim-delat\"><noindex><a rel=\"nofollow\" name=\"old-data\"><\/a><\/noindex>ClickHouse viene continuamente aggiornato, mentre i nostri dati non lo sono. Cosa fare al riguardo?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse si aggiorna regolarmente, ma i dati che sono stati ottimizzati finalizzati non si aggiornano e rimangono nel backup. <\/p>\n<p>Supponiamo che abbiamo avuto qualche problema e i dati siano stati persi. Abbiamo deciso di ripristinare e ci siamo accorti che le vecchie partizioni, conservate nei server di backup, divergono significativamente dalla versione di ClickHouse attualmente in uso. Cosa fare in questo caso, \u00e8 una situazione possibile?<\/p><\/blockquote>\n<p>Una situazione in cui ripristini dati da un backup in un formato obsoleto e non si collegano nella nuova versione non \u00e8 possibile. Ci assicuriamo che il formato dei dati in ClickHouse rimanga sempre retrocompatibile. Questo \u00e8 molto pi\u00f9 importante della retrocompatibilit\u00e0 delle funzionalit\u00e0, se il comportamento di una funzione raramente utilizzata cambia. I dati memorizzati su disco devono sempre poter essere letti dalla nuova versione di ClickHouse. Questa \u00e8 una regola. <\/p>\n<p><\/p>\n<h2 id=\"anchorbackup-best-practiciesanchorkakie-luchshie-praktiki-est-nanbspdannyy-moment-ponbsprezervnomu-kopirovaniyu-dannyh-iznbspclickhouse\"><noindex><a rel=\"nofollow\" name=\"backup-best-practicies\"><\/a><\/noindex>Quali sono le migliori pratiche attualmente disponibili per il backup dei dati da ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>Come effettuare backup considerando che abbiamo operazioni di ottimizzazione finale, un'enorme base di dati di terabyte e dati aggiornati, supponiamo, negli ultimi tre giorni, senza ulteriori procedure su di essi? <\/p>\n<p>Possiamo sviluppare una nostra soluzione e scrivere uno script su bash: fare backup in questo modo e in quest'altro. Magari non \u00e8 necessario inventare nulla da zero, c'\u00e8 gi\u00e0 qualcosa di simile? <\/p><\/blockquote>\n<p>Per cominciare, riguardo le migliori pratiche. I miei colleghi consigliano sempre, in risposta a domande sui backup, di menzionare il servizio \"Yandex.Cloud\", dove questo compito \u00e8 gi\u00e0 risolto. Quindi, sfruttalo se possibile. <\/p>\n<p><\/p>\n<p>Non esiste una soluzione completa, completamente integrata in ClickHouse, per i backup. Ci sono alcune impostazioni di base che possono essere utilizzate. Per ottenere una soluzione completa, sar\u00e0 necessario lavorare un po' manualmente o creare wrapper sotto forma di script.<\/p>\n<p><\/p>\n<p>Inizier\u00f2 con le soluzioni pi\u00f9 semplici e terminer\u00f2 con quelle pi\u00f9 complesse a seconda della quantit\u00e0 di dati e delle dimensioni del cluster. Pi\u00f9 grande \u00e8 il cluster, pi\u00f9 difficile diventa la soluzione.<\/p>\n<p><\/p>\n<p>Se la tabella con i dati occupa solo alcuni gigabyte, il backup pu\u00f2 essere effettuato in questo modo: <\/p>\n<p><\/p>\n<ol>\n<li>Salvare la definizione delle tabelle, cio\u00e8 i metadati \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Creare un dump utilizzando il client ClickHouse \u2014 <strong>select<\/strong> * <strong>from table<\/strong> in un file. Per impostazione predefinita, otterrai un file in formato TabSeparated. Se desideri un formato pi\u00f9 efficiente, puoi utilizzare il formato Native. <\/li>\n<\/ol>\n<p><\/p>\n<p>Se il volume dei dati \u00e8 maggiore, il backup richieder\u00e0 pi\u00f9 tempo e occuper\u00e0 molto spazio. Questo \u00e8 chiamato backup logico, non \u00e8 legato al formato dei dati di ClickHouse. Se ne hai uno, in casi estremi puoi prenderlo e caricarlo in MySQL per il ripristino. <\/p>\n<p><\/p>\n<p>Per casi pi\u00f9 avanzati, ClickHouse offre la possibilit\u00e0 di creare uno snapshot delle partizioni nel file system locale. Questa funzione \u00e8 disponibile sotto forma di query. <strong>alter table freeze partition<\/strong>. O semplicemente <strong>alter table freeze<\/strong> \u2014 \u00e8 uno snapshot dell'intera tabella. <\/p>\n<p><\/p>\n<p>Lo snapshot sar\u00e0 creato in modo consistente per una tabella su un singolo shard, quindi non \u00e8 possibile creare uno snapshot consistente per l'intero cluster in questo modo. Ma per la maggior parte delle esigenze, non \u00e8 necessario, e basta eseguire la query su ogni shard per ottenere uno snapshot consistente. Viene creato come hard link e quindi non occupa spazio aggiuntivo. Successivamente, puoi copiare questo snapshot su un server di backup o in un'archiviazione che utilizzi per i backup.<\/p>\n<p><\/p>\n<p>Ripristinare un tale backup \u00e8 piuttosto semplice. Prima di tutto, crei le tabelle in base alle definizioni esistenti. Poi copi gli snapshot salvati delle partizioni nella Directory-Detached per le tabelle dati e esegui la query <strong>attach partition<\/strong>. Questa soluzione \u00e8 adatta per volumi di dati molto significativi. <\/p>\n<p><\/p>\n<p>A volte \u00e8 necessario qualcosa di ancora pi\u00f9 avanzato \u2014 nei casi in cui hai decine o addirittura centinaia di terabyte su ogni server e centinaia di server. Qui c'\u00e8 una soluzione che ho osservato dai colleghi di \"Yandex.Metrica\". Non lo raccomanderei a tutti \u2014 leggi e decidi tu stesso se \u00e8 adatta. <\/p>\n<p><\/p>\n<p>In primo luogo, \u00e8 necessario creare diversi server con grandi scaffali per dischi. Successivamente, su questi server,  si devono installare diversi server ClickHouse e configurarli in modo che funzionino come un'altra replica per gli stessi shard. E poi utilizzare su questi server un file system o uno strumento che consenta di creare snapshot. Qui ci sono due opzioni. La prima opzione sono gli snapshot LVM, la seconda opzione \u00e8 ZFS su Linux. <\/p>\n<p><\/p>\n<p>Dopo di ci\u00f2, ogni giorno \u00e8 necessario creare uno snapshot, che occupa e richiede spazio. Ovviamente, se i dati cambiano, col passare del tempo il volume dello spazio aumenter\u00e0. \u00c8 possibile recuperare questo snapshot in qualsiasi momento e ripristinare i dati, una soluzione piuttosto insolita. Inoltre, \u00e8 necessario limitare queste repliche nella configurazione, per evitare che tentino di diventare leader.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>\u00c8 possibile organizzare un ritardo controllato delle repliche nei flussi?<\/h2>\n<p><\/p>\n<blockquote><p>Quest'anno prevedi di implementare i rulli in ClickHouse. Sar\u00e0 possibile organizzare un ritardo controllato delle repliche in essi? Vorremmo utilizzare questa funzione per proteggerci da scenari negativi con alterazioni e altre modifiche. <\/p>\n<p>\u00c8 possibile fare qualche rollback per gli alter? Ad esempio, in un rullo esistente dire di applicare modifiche fino a quel punto e smettere di applicarle da quel momento in poi?<\/p>\n<p>Se nel nostro cluster \u00e8 arrivato un comando e lo ha danneggiato, abbiamo una replica condizionale con un ritardo di un'ora in cui possiamo dire: utilizziamo proprio quella al momento, ma non applicheremo le ultime dieci minuti di modifiche? <\/p><\/blockquote>\n<p>Iniziamo con il ritardo controllato delle repliche. Abbiamo ricevuto una richiesta dagli utenti e abbiamo creato un'issue su GitHub con la richiesta: \"Se a qualcuno serve, metti un like o un cuore\". Nessuno ha messo like, e l'issue \u00e8 stata chiusa. Tuttavia, gi\u00e0 adesso \u00e8 possibile ottenere tale funzionalit\u00e0, configurando ClickHouse. Tuttavia, solo a partire dalla versione 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse esegue costantemente merge dei dati in background. Quando viene eseguito il merge, un certo insieme di parti di dati viene sostituito con una parte pi\u00f9 grande. In questo processo, le parti di dati precedenti rimangono su disco per un certo periodo.<\/p>\n<p><\/p>\n<p>In primo luogo, continuano ad essere conservate fino a quando ci sono query di selezione che le utilizzano, per garantire un funzionamento non bloccante. Le query di selezione leggono senza problemi dalle vecchie parti.<\/p>\n<p><\/p>\n<p>In secondo luogo, esiste anche una soglia temporale: i vecchi blocchi di dati rimangono sul disco per otto minuti. Questi otto minuti possono essere configurati e trasformati anche in un giorno. Ci\u00f2 comporter\u00e0 un costo in termini di spazio su disco: a seconda del flusso di dati, potrebbe succedere che negli ultimi giorni i dati non raddoppino, ma aumentino anche di cinque volte. Tuttavia, in caso di problemi gravi, sar\u00e0 possibile fermare il server ClickHouse e risolvere tutto.<\/p>\n<p><\/p>\n<p>Ora sorge la domanda su come questo protegga dagli alter. Qui \u00e8 utile approfondire, poich\u00e9 nelle versioni precedenti di ClickHouse, l'alter funzionava in modo tale da cambiare semplicemente direttamente i blocchi. C'\u00e8 un blocco di dati con alcuni file e facciamo, per esempio, <strong>alter drop column<\/strong>. Allora questa colonna viene fisicamente rimossa da tutti i blocchi.<\/p>\n<p><\/p>\n<p>Ma a partire dalla versione 20.3, il meccanismo degli alter \u00e8 stato completamente modificato, e ora i blocchi di dati sono sempre immutabili. Non cambiano affatto: gli alter ora funzionano in modo simile ai merge. Invece di cambiare un blocco sul posto, ne creiamo uno nuovo. Nel nuovo blocco, i file che non sono cambiati diventano hard link e, se abbiamo rimosso una colonna, questa semplicemente non sar\u00e0 presente nel nuovo blocco. Il vecchio blocco verr\u00e0 eliminato di default dopo otto minuti, e qui si possono regolare le impostazioni di cui si \u00e8 parlato prima. <\/p>\n<p><\/p>\n<p>Lo stesso vale per gli alter di tipo mutazione. Quando si fa <strong>alter delete<\/strong> o <strong>alter update<\/strong>, non modifica il chunk, ma crea uno nuovo. Poi elimina il vecchio.<\/p>\n<p><\/p>\n<h2 id=\"anchorsoooo-changeableanchorkak-byt-esli-struktura-tablicy-pomenyalas\"><noindex><a rel=\"nofollow\" name=\"soooo-changeable\"><\/a><\/noindex>Cosa fare se la struttura della tabella \u00e8 cambiata?<\/h2>\n<p><\/p>\n<blockquote><p>Come ripristinare un backup effettuato con una vecchia struttura? E la seconda domanda riguarda il caso con gli snapshot e i sistemi di file. \u00c8 adatta qui Btrfs invece di ZFS su Linux LVM?<\/p><\/blockquote>\n<p>Se si fa <strong>attach partition<\/strong> partizioni con una struttura diversa, quindi ClickHouse ti dir\u00e0 che non \u00e8 possibile. La soluzione \u00e8 la seguente. Prima - creare una tabella temporanea di tipo MergeTree con la vecchia struttura, collegarvi i dati tramite attach, eseguire la query alter. Poi si pu\u00f2 o copiare o trasferire questi dati e fare attach di nuovo, oppure usare la query <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Ora la seconda domanda - si pu\u00f2 utilizzare Btrfs. Per iniziare, se hai LVM, basta avere snapshot LVM, e il filesystem pu\u00f2 essere anche ext4, non ha importanza. Con Btrfs dipende dalla tua esperienza con il suo utilizzo. \u00c8 un filesystem maturo, ma ci sono comunque alcuni sospetti su come funzioner\u00e0 nella pratica in uno scenario specifico. Non lo consiglierei se non hai Btrfs in produzione.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-best-practicesanchorkakie-seychas-luchshie-praktiki-vnbspreshardinge-dannyh\"><noindex><a rel=\"nofollow\" name=\"resharding-best-practices\"><\/a><\/noindex>Quali sono le migliori pratiche attuali per il resharing dei dati?<\/h2>\n<p><\/p>\n<p>La domanda sul re-sharding \u00e8 complessa e sfaccettata. Qui si pu\u00f2 rispondere con diverse opzioni. Si pu\u00f2 iniziare da un lato e dire - non ci sono possibilit\u00e0 di re-sharding integrate in ClickHouse. Ma temo che questa risposta non soddisfer\u00e0 nessuno. Quindi si pu\u00f2 considerare dall'altro lato e dire che in ClickHouse ci sono molti modi per effettuare il re-sharding dei dati. <\/p>\n<p><\/p>\n<p>Se lo spazio sul cluster si esaurisce o non riesce a gestire il carico, si aggiungono nuovi server. Ma questi server inizialmente sono vuoti, non ci sono dati su di loro, e non hanno alcun carico. \u00c8 necessario ripartire i dati affinch\u00e9 siano uniformemente distribuiti sul nuovo cluster ampliato.<\/p>\n<p><\/p>\n<p>Il primo modo per farlo \u00e8 copiare alcune partizioni sui nuovi server utilizzando la query <strong>alter table fetch partition<\/strong>. Ad esempio, avevi partizioni mensili, e prendi il primo mese del 2017 e lo copi su un nuovo server, poi copi il terzo mese su un altro nuovo server. E cos\u00ec fai fino a che non diventa pi\u00f9 o meno uniforme.<\/p>\n<p><\/p>\n<p>Il trasferimento pu\u00f2 avvenire solo per quelle partizioni che non cambiano durante la scrittura. Per le partizioni recenti, sar\u00e0 necessario disattivare la scrittura, poich\u00e9 il loro trasferimento non \u00e8 atomico. Altrimenti si otterranno duplicati o mancanze nei dati. Tuttavia, questo metodo \u00e8 pratico e funziona abbastanza efficacemente. Le partizioni compresse vengono trasferite in rete, cio\u00e8 i dati non vengono ri-compressi n\u00e9 riconvertiti.<\/p>\n<p><\/p>\n<p>Questo metodo ha un inconveniente, ed \u00e8 legato allo schema di sharding: se hai progettato per questo schema di sharding, quale fosse la tua chiave di sharding. Nel tuo esempio per il caso delle metriche, la chiave di sharding \u00e8 un hash del percorso. Quando fai una select nella tabella Distributed, essa va immediatamente su tutti gli shard del cluster e preleva i dati da l\u00ec. <\/p>\n<p><\/p>\n<p>Questo significa che, in effetti, per te non ha importanza quali dati si trovano su quale shard. L'importante \u00e8 che i dati lungo un certo percorso si trovino su uno shard, mentre quale esso sia, non \u00e8 rilevante. In questo caso, il trasferimento delle partizioni esistenti \u00e8 perfetto, perch\u00e9 nelle query select tu otterrai comunque i dati completi, sia prima che dopo lo resharding; la struttura non conta molto.<\/p>\n<p><\/p>\n<p>Ma ci sono casi pi\u00f9 complessi. Se a livello logico dell'applicazione prevedi uno schema di sharding speciale, in cui questo cliente si trova su uno specifico shard e la query pu\u00f2 essere inviata direttamente l\u00ec e non nella tabella distribuita. Oppure stai usando una versione abbastanza recente di ClickHouse e hai abilitato l'impostazione <strong>optimize skip unused shards<\/strong>. In questo caso, durante la query select, l'espressione nella sezione where verr\u00e0 analizzata e verr\u00e0 calcolato su quali shard sia necessario andare secondo lo schema di sharding. Questo funziona a condizione che i dati siano effettivamente distribuiti in conformit\u00e0 con questo schema di sharding. Se li hai spostati manualmente, la corrispondenza potrebbe cambiare.<\/p>\n<p><\/p>\n<p>Quindi, questo \u00e8 il metodo numero uno. Attendo la tua risposta, se \u00e8 adatto o se andiamo avanti.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobayev, lead system administrator di Avito<\/strong>: Alexey, il metodo che hai menzionato non si adatta bene quando si deve distribuire anche il carico di lettura. Possiamo prendere una partizione mensile e possiamo spostare il mese precedente su un'altra nodo, ma quando arriver\u00e0 la richiesta per questi dati, caricheremo solo quella. Vorremmo invece distribuire il carico su tutto il cluster, perch\u00e9, in caso contrario, per un certo periodo tutte le richieste di lettura saranno gestite da due shard.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> La risposta qui \u00e8 strana: s\u00ec, \u00e8 male, ma pu\u00f2 funzionare. Spiego come. \u00c8 importante considerare lo scenario di carico che si trova dietro ai tuoi dati. Se si tratta di dati di monitoraggio, quasi sicuramente si pu\u00f2 dire che la stragrande maggioranza delle richieste va a dati freschi. <\/p>\n<p><\/p>\n<p>Hai installato nuovi server, hai trasferito le vecchie partizioni, ma hai anche modificato il modo in cui vengono registrati i dati freschi. E i dati freschi saranno distribuiti su tutto il cluster. Quindi, gi\u00e0 dopo cinque minuti, le richieste per i dati degli ultimi cinque minuti caricheranno uniformemente il cluster; dopo un giorno, le richieste per il giorno intero caricheranno uniformemente il cluster. Purtroppo, le richieste per il mese precedente andranno solo su una parte dei server del cluster.<\/p>\n<p><\/p>\n<p>Ma spesso non avrai richieste specifiche per febbraio 2019. Probabilmente, se ci sono richieste per l'anno 2019, saranno per l'intero anno 2019 \u2014 per un ampio intervallo di tempo, e non per un piccolo intervallo. E anche queste richieste potranno caricare uniformemente il cluster. Ma in generale, la tua osservazione \u00e8 del tutto corretta: si tratta di una soluzione ad hoc che non distribuisce i dati in modo uniforme.<\/p>\n<p><\/p>\n<p>Ho alcuni ulteriori punti da considerare per rispondere alla domanda. Uno di questi \u00e8 come progettare inizialmente lo schema di sharding in modo che ci sia meno dolore nello resharding. Questo non \u00e8 sempre possibile.<\/p>\n<p><\/p>\n<p>Ad esempio, hai dati di monitoraggio. I dati di monitoraggio crescono per tre motivi. Primo \u2014 accumulo di dati storici. Secondo \u2014 aumento del traffico. E terzo \u2014 incremento del numero di elementi sotto monitoraggio. Nuovi microservizi e metriche da salvare stanno emergendo. <\/p>\n<p><\/p>\n<p>\u00c8 possibile che il maggiore aumento sia legato proprio alla terza ragione \u2014 cio\u00e8 all'aumento dell'uso del monitoraggio. E in questo caso \u00e8 utile considerare la natura del carico, quali sono le principali richieste di select. Le principali richieste di select, molto probabilmente, saranno per un certo sottoinsieme di metriche.<\/p>\n<p><\/p>\n<p>Ad esempio, l'uso della CPU su alcuni server da parte di un determinato servizio. Dunque, c'\u00e8 un certo sottoinsieme di chiavi da cui estrai questi dati. E la richiesta stessa per questi dati, molto probabilmente, \u00e8 abbastanza semplice e viene eseguita in decine di millisecondi. Viene utilizzata per i servizi di monitoraggio, per i dashboard. Spero di averlo capito correttamente.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobayev:<\/strong> Il fatto \u00e8 che spesso facciamo riferimento ai dati storici, poich\u00e9 confrontiamo in tempo reale la situazione attuale con quella storica. E per noi \u00e8 importante avere accesso rapido a un grande volume di dati, e ClickHouse gestisce questo compito eccellentemente.<\/p>\n<p><\/p>\n<p>Hai assolutamente ragione, la maggior parte delle richieste di lettura le riscontriamo nell'ultimo giorno, proprio come qualsiasi sistema di monitoraggio. Tuttavia, anche i dati storici presentano un carico piuttosto elevato. Questo \u00e8 principalmente a causa del sistema di allerta, che ogni trenta secondi chiede a ClickHouse: \u00abRestituisci i dati delle ultime sei settimane. Ora costruisci una media mobile da questi dati e confrontiamo il valore attuale con quello storico\u00bb. <\/p>\n<p><\/p>\n<p>Vorrei dire che per tali richieste molto recenti abbiamo un'altra piccola tabella, dove conserviamo i dati per soli due giorni, e le richieste principali vengono indirizzate a essa. Nella grande tabella sharded inviamo solo le richieste storiche pi\u00f9 consistenti.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Sfortunatamente, per il tuo scenario questo risulta piuttosto inapplicabile, ma ti descriver\u00f2 due schemi di sharding complessi e inadeguati che non dovrebbero essere utilizzati, ma che sono impiegati nel servizio dei miei amici. <\/p>\n<p><\/p>\n<p>Esiste un cluster principale con gli eventi di \u00abYandex.Metrics\u00bb. Gli eventi sono pagine visualizzate, clic e transizioni. La maggior parte delle richieste riguarda un sito web specifico. Apri il servizio \u00abYandex.Metrics\u00bb, hai un sito \u2014 avito.ru, accedi al report e viene effettuata una richiesta riguardante il tuo sito.<\/p>\n<p><\/p>\n<p>Ma ci sono anche altre richieste \u2014 analitiche e globali, effettuate dagli analisti interni. Vorrei sottolineare che gli analisti interni fanno richieste solo sui servizi di \u00abYandex\u00bb. Tuttavia, anche i servizi di \u00abYandex\u00bb occupano una parte considerevole di tutti i dati. Queste richieste non riguardano contatori specifici, ma una filtrazione pi\u00f9 ampia.<\/p>\n<p><\/p>\n<p>Come puoi organizzare i dati in modo che funzioni efficacemente sia per un singolo contatore che per le richieste globali? La complessit\u00e0 sta anche nel fatto che il numero di richieste a ClickHouse nel cluster \u00abMetrics\u00bb \u00e8 di diverse migliaia al secondo. Allo stesso tempo, non tutti i server ClickHouse possono gestire richieste non banali di migliaia al secondo.<\/p>\n<p><\/p>\n<p>Le dimensioni del cluster sono di oltre seicento server. Se semplicemente sovrapponiamo una tabella distribuita a questo cluster e inviamo diverse migliaia di richieste, la situazione diventa ancora peggiore che inviarle a un singolo server. D'altra parte, scartiamo l'opzione di distribuzione uniforme dei dati, e di fare richieste a tutti i server.<\/p>\n<p><\/p>\n<p>C'\u00e8 un'opzione diametralmente opposta. Immagina di sharding dei dati per siti, e la richiesta per un singolo sito andr\u00e0 a uno shard. Ora il cluster potrebbe gestire diecimila richieste al secondo, ma in uno shard specifico una richiesta potrebbe rallentare notevolmente. Non sar\u00e0 pi\u00f9 scalabile in termini di capacit\u00e0. Soprattutto se si tratta del sito avito.ru. Non sveler\u00f2 alcun segreto dicendo che Avito \u00e8 uno dei siti pi\u00f9 visitati nella Runet. E gestirlo su un singolo shard sarebbe insensato.<\/p>\n<p><\/p>\n<p>Pertanto, lo schema di sharding \u00e8 strutturato in modo pi\u00f9 ingegnoso. L'intero cluster \u00e8 suddiviso in un certo numero di cluster, che chiamiamo strati. All'interno di ciascun cluster ci sono da una decina a diverse decine di shard. In totale ci sono trentanove di questi cluster. <\/p>\n<p><\/p>\n<p>Come si scala tutto questo? Il numero di cluster rimane invariato \u2014 come erano trentanove anni fa, cos\u00ec sono rimasti. Ma all'interno di ciascuno di essi aumentiamo gradualmente il numero di shard man mano che accumuliamo dati. E lo schema di sharding in generale \u00e8 cos\u00ec: la suddivisione in questi cluster avviene per siti web, e per sapere quale sito si trova in quale cluster, utilizziamo un database separato in MySQL. Un sito \u2014 in un cluster. E all'interno di esso, lo sharding si basa sugli identificatori dei visitatori.<\/p>\n<p><\/p>\n<p>Quando scriviamo, li suddividiamo in base al resto della divisione dell'identificatore del visitatore. Ma quando aggiungiamo un nuovo shard, lo schema di sharding cambia, continuiamo a suddividere, ma facendo riferimento a un altro numero. Questo significa che un visitatore \u00e8 effettivamente distribuito su pi\u00f9 server, e non possiamo fare affidamento su questo. Questo \u00e8 fatto esclusivamente per garantire che i dati siano compressi meglio. E per le richieste ci dirigiamo verso una tabella distribuita che consulta il cluster e si rivolge a decine di server. \u00c8 uno schema piuttosto complicato.<\/p>\n<p><\/p>\n<p>Ma il mio racconto sarebbe incompleto se non dicessi che abbiamo abbandonato questo schema. Nella nuova configurazione abbiamo cambiato tutto e copiato tutti i dati utilizzando clickhouse-copier.<\/p>\n<p><\/p>\n<p>Nella nuova architettura, tutti i siti sono suddivisi in due categorie: grandi e piccoli. Non so come sia stato scelto il limite, ma alla fine si \u00e8 deciso che i siti grandi vengono registrati su un unico cluster, che comprende 120 shard con tre repliche ciascuno - cio\u00e8 360 server. La schematizzazione degli shard \u00e8 tale che qualsiasi richiesta va simultaneamente a tutti gli shard. Se adesso aprite qualsiasi pagina di report su \u00abYandex.Metrica\u00bb per avito.ru, la richiesta andr\u00e0 a 120 server. Ci sono pochi grandi siti nel Runet. E le richieste risultano essere non mille al secondo, ma anche meno di cento. Tutto questo \u00e8 gestito tranquillamente dalla tabella Distributed, che ognuno di essi tratta con 120 server.<\/p>\n<p><\/p>\n<p>E il secondo cluster \u00e8 per i siti piccoli. Qui la schematizzazione degli shard \u00e8 basata sull'identificativo del sito, e ogni richiesta va esattamente a uno shard.<\/p>\n<p><\/p>\n<h2 id=\"anchorclickhouse-copieranchorv-clickhouse-est-utilita-clickhouse-copier-mozhete-pronbspneyo-rasskazat\"><noindex><a rel=\"nofollow\" name=\"clickhouse-copier\"><\/a><\/noindex>In ClickHouse esiste uno strumento chiamato clickhouse-copier. Puoi parlarne?<\/h2>\n<p><\/p>\n<p>Dico subito che questa soluzione \u00e8 pi\u00f9 ingombrante e leggermente meno performante. Il vantaggio \u00e8 che distribuisce i dati completamente secondo lo schema che indicherete. Ma lo svantaggio dello strumento \u00e8 che non effettua lo resharding. Copia i dati da uno schema di cluster a un altro schema di cluster.<\/p>\n<p><\/p>\n<p>Ci\u00f2 significa che per il suo funzionamento dovete avere due cluster. Possono essere situati sugli stessi server, ma i dati non verranno spostati incrementally, ma saranno copiati. <\/p>\n<p><\/p>\n<p>Ad esempio, da quattro server ad otto. Creerete una nuova tabella Distributed su tutti i server, nuove tabelle locali e avviate clickhouse-copier, specificando in esso lo schema di lavoro, che deve leggere da l\u00ec, accettare il nuovo schema di shard e spostare i dati l\u00ec. E sui vecchi server avrete bisogno di uno spazio circa 1.5 volte superiore a quello attuale, perch\u00e9 i vecchi dati devono rimanere l\u00ec e ci sar\u00e0 anche una porzione di questi stessi vecchi dati. Se in anticipo avete pensato che i dati devono essere reshadrizzati e c'\u00e8 spazio, questo metodo funzioner\u00e0.<\/p>\n<p><\/p>\n<p>Come funziona internamente clickhouse-copier? Divide tutto il lavoro in un insieme di compiti per il trattamento di una partizione di una tabella su uno shard. Tutti questi compiti possono essere eseguiti in parallelo, e clickhouse-copier pu\u00f2 essere avviato su macchine diverse in pi\u00f9 istanze, ma ci\u00f2 che fa per una partizione \u00e8 nient'altro che insert select. I dati vengono letti, decompressi, redistribuiti, poi compressi di nuovo, scritti da qualche parte e riordinati. Si tratta di una soluzione pi\u00f9 pesante.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-toolanchoru-vas-byla-pilotnaya-shtuka-kotoraya-nazyvalas-resharding-chto-snbspney\"><noindex><a rel=\"nofollow\" name=\"resharding-tool\"><\/a><\/noindex>Avevate un progetto pilota chiamato resharding. Cosa ne \u00e8 stato?<\/h2>\n<p><\/p>\n<blockquote><p>Avevate gi\u00e0 nel 2017 un progetto pilota chiamato resharding. C\u2019\u00e8 anche un'opzione in ClickHouse. Da quel che capisco, non ha avuto successo. Potete spiegare perch\u00e9 \u00e8 andata cos\u00ec? Sembra abbastanza attuale.<\/p><\/blockquote>\n<p>Il problema \u00e8 che, in caso di bisogno di reshadrizzare i dati, richiede una sincronizzazione piuttosto complessa affinch\u00e9 questo avvenga in modo atomico. Quando abbiamo iniziato a studiare come \u00e8 organizzata questa sincronizzazione, \u00e8 diventato chiaro che ci sono problemi fondamentali. E questi problemi fondamentali non sono solo teorici, ma si sono subito manifestati in pratica con un semplice fatto: non funziona nulla.<\/p>\n<p><\/p>\n<h2 id=\"anchormove-to-slow-diskanchormozhno-li-slivat-vse-chasti-dannyh-voedino-perednbspperemescheniem-nanbspmedlennye-diski\"><noindex><a rel=\"nofollow\" name=\"move-to-slow-disk\"><\/a><\/noindex>\u00c8 possibile unire tutte le parti dei dati in un'unica entit\u00e0 prima di passarle su hard disk lenti?<\/h2>\n<p><\/p>\n<blockquote><p>Domanda su TTL con l'opzione move to slow disk nel contesto delle fusioni. C'\u00e8 un modo, oltre a cron, per unire tutte le parti in una prima di trasferirle sui dischi lenti?<\/p><\/blockquote>\n<p>La risposta alla domanda, se sia possibile in qualche modo unire automaticamente tutti i pezzi in uno prima del trasferimento, \u00e8 no. Non penso sia necessario. Non \u00e8 necessario unire tutte le parti in una, ma semplicemente contare sul fatto che verranno trasferite automaticamente su dischi lenti. <\/p>\n<p><\/p>\n<p>Abbiamo due criteri per le regole di trasferimento. Il primo \u00e8 in base al riempimento. Se al livello attuale di archiviazione c'\u00e8 meno di una certa percentuale di spazio libero, scegliamo un pezzo e lo trasferiamo su uno storage pi\u00f9 lento. In verit\u00e0 non pi\u00f9 lento, ma il successivo - come impostato.<\/p>\n<p><\/p>\n<p>Il secondo criterio \u00e8 per dimensione. Si occupa del trasferimento di pezzi grandi. Puoi regolare la soglia di spazio libero sul disco veloce, e i dati verranno trasferiti automaticamente.<\/p>\n<p><\/p>\n<h2 id=\"anchorup-to-dateanchorkak-pereezzhat-nanbspnovye-versii-clickhouse-esli-net-vozmozhnosti-zaranee-proverit-sovmestimost\"><noindex><a rel=\"nofollow\" name=\"up-to-date\"><\/a><\/noindex>Come migrare a nuove versioni di ClickHouse se non \u00e8 possibile verificare in anticipo la compatibilit\u00e0?<\/h2>\n<p><\/p>\n<blockquote><p>Questo argomento viene discusso regolarmente <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">in chat Telegram ClickHouse<\/a><\/noindex> tenendo conto delle diverse versioni, \u00e8 comunque. Quanto \u00e8 sicuro aggiornarsi dalla versione 19.11 alla 19.16 e, per esempio, dalla 19.16 alla 20.3? Qual \u00e8 il modo migliore per passare a nuove versioni, senza avere la possibilit\u00e0 di verificare preventivamente la compatibilit\u00e0 in un ambiente sandbox?<\/p><\/blockquote>\n<p>Ci sono alcune \"regole d'oro\". <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">leggere il changelog<\/a><\/noindex>. \u00c8 ampio, ma ci sono punti specifici relativi alle modifiche retrocompatibili. Non dovresti considerare questi punti come segnali d'allerta. Di solito si tratta di piccole incompatibilit\u00e0 legate a funzionalit\u00e0 marginali che, molto probabilmente, non stai utilizzando.<\/p>\n<p><\/p>\n<p>In secondo luogo, se non hai la possibilit\u00e0 di testare la compatibilit\u00e0 in un sandbox e desideri eseguire l'aggiornamento direttamente in produzione, il consiglio \u00e8: non farlo. Prima crea un ambiente di test e verifica. Se non hai un ambiente di test, probabilmente non hai un'azienda molto grande, il che significa che puoi copiare parte dei dati sul tuo laptop e verificare l\u00ec che tutto funzioni correttamente. Puoi anche far girare diverse repliche localmente sul tuo computer. Oppure, puoi avviare una nuova versione da qualche parte vicino e caricare parte dei dati \u2013 cio\u00e8 creare un ambiente di test improvvisato. <\/p>\n<p><\/p>\n<p>Un'altra regola \u00e8 che non dovresti aggiornare per una settimana dopo il rilascio della versione per monitorare eventuali bug in produzione e i successivi fix rapidi. Analizziamo la numerazione delle versioni di ClickHouse per non confonderci. <\/p>\n<p><\/p>\n<p>C'\u00e8 la versione 20.3.4. Il numero 20 indica l'anno di rilascio \u2013 2020. Da un punto di vista interno, questo non ha alcun significato, quindi non ci focalizzeremo su questo. Il secondo numero \u2013 20.3. Ogni volta che rilasciamo una versione con nuove funzionalit\u00e0, aumentiamo il secondo numero. Se vogliamo aggiungere un'opzione a ClickHouse, dobbiamo aumentare questo numero. Quindi, con la versione 20.4, ClickHouse funzioner\u00e0 ancora meglio. Il terzo numero \u2013 20.3.4. Qui 4 rappresenta il numero di patch release in cui non abbiamo aggiunto nuove funzionalit\u00e0, ma abbiamo corretto alcuni bug. E 4 indica che lo abbiamo fatto quattro volte.<\/p>\n<p><\/p>\n<p>Non pensare che sia qualcosa di terribile. Di solito, un utente pu\u00f2 installare l'ultima versione e funzioner\u00e0 senza problemi di uptime per un anno. Ma immagina che in qualche funzione per l'elaborazione di bitmap, aggiunta dai nostri amici cinesi, passando argomenti errati, il server si blocchi. Dobbiamo risolvere questo problema. Rilasceremo una nuova versione patch e ClickHouse diventer\u00e0 pi\u00f9 stabile.<\/p>\n<p><\/p>\n<p>Se hai ClickHouse in produzione e viene rilasciata una nuova versione di ClickHouse con funzionalit\u00e0 aggiuntive \u2013 ad esempio, 20.4.1 \u2013 non affrettarti ad installarla in produzione il primo giorno. Qual \u00e8 la necessit\u00e0? Se non stai ancora utilizzando ClickHouse, puoi installarla e, molto probabilmente, andr\u00e0 bene. Ma se ClickHouse funziona gi\u00e0 stabilmente, fai attenzione alle patch e agli aggiornamenti \u2013 quali problemi stiamo risolvendo.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Voglio aggiungere qualcosa sulle ambienti di test. Tutti temono ambienti di test e per qualche motivo pensano che se hai un grande cluster ClickHouse, anche l'ambiente di test deve essere almeno grande quanto o anche dieci volte pi\u00f9 piccolo. Non \u00e8 affatto cos\u00ec.<\/p>\n<p><\/p>\n<p>Posso dire per esperienza personale. Ho un progetto con ClickHouse. La nostra ambiente di test per questo progetto \u00e8 una piccola macchina virtuale in Hetzner che costa venti euro, dove \u00e8 tutto implementato. Per farlo, abbiamo una completa automazione in Ansible e quindi non c'\u00e8 differenza se dobbiamo implementare su server fisici o semplicemente su macchine virtuali.<\/p>\n<p><\/p>\n<p>Cosa si potrebbe fare? Sarebbe utile includere nella documentazione di ClickHouse un esempio su come implementare un piccolo cluster \u2013 in Docker, in LXC, forse creare un playbook Ansible, poich\u00e9 le persone hanno diversi tipi di deployment. Questo semplificherebbe molto le cose. Quando puoi installare un cluster in cinque minuti, \u00e8 molto pi\u00f9 facile cercare di capire come funziona. \u00c8 molto pi\u00f9 conveniente, perch\u00e9 installare la versione di produzione che non hai testato \u00e8 una strada senza uscita. A volte funziona, altre volte no. Perci\u00f2 sperare in successo non \u00e8 una buona idea.<\/p>\n<p><\/p>\n<p><strong>Maksim Kotjakov, senior backend engineer di Avito:<\/strong> Aggiungo qualche informazione sugli ambienti di test legati ai problemi delle grandi aziende. Abbiamo un cluster di accettazione ClickHouse, che \u00e8 una copia esatta di ci\u00f2 che abbiamo in produzione, sia per quanto riguarda gli schemi dei dati che le configurazioni. Questo cluster \u00e8 implementato in contenitori piuttosto poveri con risorse minime. Scriviamo una certa percentuale dei dati di produzione l\u00ec, poich\u00e9 abbiamo la possibilit\u00e0 di replicare il flusso in Kafka. Tutto \u00e8 sincronizzato e scalato: sia in termini di potenza che di flusso, e, in teoria, dovrebbe comportarsi metricamente come la produzione, a parit\u00e0 di condizioni. Tutto ci\u00f2 che \u00e8 potenzialmente esplosivo prima viene testato su questo ambiente e riposa l\u00ec per alcuni giorni fino a quando non \u00e8 pronto. Ma naturalmente, questa soluzione \u00e8 costosa, pesante e comporta costi di supporto non indifferenti. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Parler\u00f2 dell'ambiente di test dei nostri amici di \u00abYandex.Metrica\u00bb. Un cluster aveva oltre 600 server, un altro 360, e ce n'\u00e8 anche un terzo e diversi altri cluster. L'ambiente di test per uno di essi consiste semplicemente in due shard con due repliche ciascuno. Perch\u00e9 due shard? Per non averne solo uno. E anche per avere delle repliche. \u00c8 solo una quantit\u00e0 minima che possiamo permetterci.<\/p>\n<p><\/p>\n<p>Questo ambiente di test consente di verificare il funzionamento delle query e di accertarsi che non ci siano stati problemi gravi. Tuttavia, spesso si presentano problemi di natura completamente diversa, dove tutto funziona, ma ci sono alcune piccole variazioni nel carico.<\/p>\n<p><\/p>\n<p>Fornisco un esempio. Abbiamo deciso di installare una nuova versione di ClickHouse. \u00c8 stata distribuita nell'ambiente di test, sono stati eseguiti test automatizzati all'interno della stessa \u00abYandex.Metrica\u00bb, che confrontano i dati sulla vecchia versione e sulla nuova, eseguendo l'intero pipeline. E naturalmente, i test del nostro CI sono andati a buon fine. Altrimenti non avremmo nemmeno proposto questa versione.<\/p>\n<p><\/p>\n<p>Tutto va benissimo. Iniziamo a distribuire in produzione. Ricevo un messaggio che indica che il carico sui grafici \u00e8 aumentato di diverse volte. Torniamo indietro con la versione. Controllo il grafico e vedo: il carico \u00e8 davvero aumentato di diverse volte durante la distribuzione e poi \u00e8 tornato a diminuire quando \u00e8 stata completata la distribuzione. Poi abbiamo iniziato a tornare indietro con la versione. E il carico \u00e8 aumentato allo stesso modo e poi \u00e8 nuovamente sceso. Quindi la conclusione \u00e8 che il carico \u00e8 aumentato a causa della distribuzione, nulla di sorprendente.<\/p>\n<p><\/p>\n<p>Dopo \u00e8 stato difficile convincere i colleghi a installare comunque la nuova versione. Dico: \u00abVa tutto bene, distribuitela. Incrociate le dita, andr\u00e0 tutto bene. Ora il carico \u00e8 aumentato sui grafici, ma va tutto bene. Resistete\u00bb. In generale, l'abbiamo fatto e cos\u00ec la versione \u00e8 stata distribuita in produzione. Ma quasi ad ogni distribuzione sorgono problemi simili.<\/p>\n<p><\/p>\n<h2 id=\"anchorkill-queryanchorkill-query-dolzhen-ubivat-zaprosy-no-on-etogo-ne-delaet-pochemu\"><noindex><a rel=\"nofollow\" name=\"kill-query\"><\/a><\/noindex>Kill query dovrebbe terminare le query, ma non lo fa. Perch\u00e9?<\/h2>\n<p><\/p>\n<blockquote><p>Un utente, un analista, si \u00e8 avvicinato a me e ha creato una query che ha bloccato il mio cluster ClickHouse. Una qualche nodo o l'intero cluster, a seconda di quale replica o shard \u00e8 stata colpita dalla query. Vedo che tutte le risorse CPU su quel server sono al massimo, tutto \u00e8 rosso. Tuttavia, ClickHouse continua a rispondere alle query. E scrivo: \u00abMostrami per favore la lista dei processi, quale query ha generato questo caos\u00bb.<\/p>\n<p>Trovo quella query e scrivo il comando kill. E vedo che non succede nulla. Il mio server \u00e8 al massimo, ClickHouse continua a restituirmi alcuni comandi, mostrando che il server \u00e8 vivo e tutto va bene. Ma ho una degradazione in tutte le query degli utenti, inizia a verificarsi una degradazione nella scrittura in ClickHouse, e il mio comando kill non funziona. Perch\u00e9? Pensavo che il comando kill dovesse terminare le query, ma non \u00e8 cos\u00ec.<\/p><\/blockquote>\n<p>Ora arriver\u00e0 una risposta piuttosto strana. Il fatto \u00e8 che il comando kill non termina le query. <\/p>\n<p><\/p>\n<p>Il comando kill imposta un piccolo flag chiamato \u00abvoglio che questa query venga terminata\u00bb. E la query, durante l'elaborazione di ogni blocco, controlla questo flag. Se \u00e8 impostato, la query smette di funzionare. Risultato: nessuno termina la query, deve essere lei stessa a verificare e fermarsi. E questo dovrebbe funzionare in tutti i casi in cui la query \u00e8 in stato di elaborazione dei blocchi di dati. Elaborer\u00e0 il blocco successivo, controller\u00e0 il flag e si fermer\u00e0.<\/p>\n<p><\/p>\n<p>Questo non funziona nei casi in cui la query \u00e8 bloccata in qualche operazione. Tuttavia, probabilmente non \u00e8 il tuo caso, perch\u00e9, da quanto dici, utilizza molte risorse del server. \u00c8 possibile che non funzioni in caso di ordinamento esterno e in alcuni altri dettagli. Ma in generale non dovrebbe funzionare cos\u00ec, \u00e8 un bug. E l'unica cosa che posso consigliare \u00e8 aggiornare ClickHouse.<\/p>\n<p><\/p>\n<h2 id=\"anchorreading-timeanchorkak-rasschitat-vremya-otveta-pri-chitayuschey-nagruzke\"><noindex><a rel=\"nofollow\" name=\"reading-time\"><\/a><\/noindex>Come calcolare il tempo di risposta con un carico in lettura?<\/h2>\n<p><\/p>\n<blockquote><p>C'\u00e8 una tabella che memorizza gli aggregati per item \u2014 vari contatori. Il numero di righe \u00e8 di circa cento milioni. Si pu\u00f2 contare su un tempo di risposta prevedibile se vengono inviati 1K RPS per 1K item? <\/p><\/blockquote>\n<p>A giudicare dal contesto, si parla di carico di lettura, perch\u00e9 non ci sono problemi con la scrittura \u2014 si possono inserire mille, centomila o anche diversi milioni di righe. <\/p>\n<p><\/p>\n<p>Le query di lettura possono essere molto diverse. In select 1, ClickHouse pu\u00f2 eseguire circa decine di migliaia di query al secondo, quindi anche le query su una sola chiave richiederanno alcune risorse. Queste query puntuali saranno pi\u00f9 complesse rispetto a quelle in alcune banche dati key-value, perch\u00e9 per ogni lettura \u00e8 necessario leggere un blocco di dati per indice. L'indice non si riferisce a ogni singolo record, ma a ogni intervallo. Quindi sar\u00e0 necessario leggere l'intero intervallo \u2014 8192 righe per impostazione predefinita. E sar\u00e0 necessario decomprimere un blocco di dati compresso di 64 Kb fino a 1 Mb. Di solito, queste query puntuali richiedono da alcuni millisecondi. Ma questo \u00e8 il caso pi\u00f9 semplice.<\/p>\n<p><\/p>\n<p>Proviamo a fare dei semplici calcoli. Se moltiplichiamo alcuni millisecondi per mille, otteniamo alcuni secondi. Sembrerebbe che non si possano gestire mille richieste al secondo, ma in realt\u00e0 \u00e8 possibile, perch\u00e9 abbiamo pi\u00f9 core del processore. Quindi, in linea di principio, ClickHouse pu\u00f2 gestire occasionalmente 1000 RPS, ma su richieste brevi, appunto puntuali.<\/p>\n<p><\/p>\n<p>Se \u00e8 necessario scalare un cluster ClickHouse in base al numero di query semplici, consiglio la cosa pi\u00f9 semplice \u2014 aumentare il numero di repliche e indirizzare le query a una replica casuale. Se una replica gestisce cinquecento richieste al secondo, il che \u00e8 del tutto realistico, tre repliche gestiranno millecinquecento.<\/p>\n<p><\/p>\n<p>A volte, ovviamente, \u00e8 possibile anche configurare ClickHouse per il massimo numero di letture puntuali. Cosa serve per questo? Prima di tutto \u2014 ridurre la granularit\u00e0 dell'indice. Tuttavia, la granularit\u00e0 non dovrebbe essere ridotta a uno, ma considerando che il numero di record nell'indice sar\u00e0 di diversi milioni o decine di milioni per server. Se nella tabella ci sono cento milioni di righe, si pu\u00f2 impostare una granularit\u00e0 di 64.<\/p>\n<p><\/p>\n<p>\u00c8 possibile ridurre la dimensione del blocco compresso. Ci sono delle impostazioni <strong>dimensione minima del blocco compresso<\/strong>, <strong>dimensione massima del blocco compresso<\/strong>. Si possono ridurre, ricaricare i dati e cos\u00ec le query puntuali saranno pi\u00f9 veloci. Tuttavia, ClickHouse non \u00e8 una banca dati key-value. Un numero elevato di piccole query rappresenta un antipattern di carico.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Ecco un consiglio nel caso ci siano contatori comuni. Si tratta di una situazione abbastanza standard, quando in ClickHouse viene memorizzato un contatore. Ho un utente, proviene da un certo paese, ha un terzo campo, e deve incrementare qualcosa. Prendi MySQL, crea una chiave unica \u2014 in MySQL \u00e8 la duplicate key, mentre in PostgreSQL \u00e8 la conflict \u2014 e incrementa. Funzioner\u00e0 molto meglio. <\/p>\n<p><\/p>\n<p>Quando hai pochi dati, non ha molto senso usare ClickHouse. Ci sono banche dati normali, e queste gestiscono bene la situazione. <\/p>\n<p><\/p>\n<h2 id=\"anchorpimp-my-clickhouseanchorchto-podtyunit-v-clickhouse-chtoby-bolshe-dannyh-bylo-vnbspkeshe\"><noindex><a rel=\"nofollow\" name=\"pimp-my-clickhouse\"><\/a><\/noindex>Cosa ottimizzare in ClickHouse affinch\u00e9 ci sia pi\u00f9 dati nella cache?<\/h2>\n<p><\/p>\n<blockquote><p>Immaginiamo una situazione \u2014 sui server ci sono 256 Gb di RAM, nella routine quotidiana ClickHouse utilizza circa 60-80 Gb, al picco fino a 130. Cosa si pu\u00f2 attivare e ottimizzare per avere pi\u00f9 dati nella cache e, di conseguenza, meno accessi al disco?<\/p><\/blockquote>\n<p>Di solito, il page cache del sistema operativo gestisce bene questo compito. Se apri semplicemente top e guardi l\u00e0 cached o free \u2014 \u00e8 indicato anche quanta memoria \u00e8 stata memorizzata nella cache \u2014 puoi notare che tutta la memoria libera \u00e8 utilizzata per la cache. E questi dati, durante la lettura, saranno letti non dal disco, ma dalla RAM. Posso dire che la cache viene utilizzata in modo efficiente perch\u00e9 vengono cachati proprio i dati compressi.<\/p>\n<p><\/p>\n<p>Tuttavia, se desideri accelerare ulteriormente alcune query semplici, c'\u00e8 la possibilit\u00e0 di attivare all'interno di ClickHouse la cache nei dati decompressi. Si chiama <strong>uncompressed cache<\/strong>. Nel file di configurazione config.xml impostare uncompressed cache size sul valore desiderato \u2014 consiglio di non superare met\u00e0 della RAM libera, perch\u00e9 il resto andr\u00e0 alla page cache. <\/p>\n<p><\/p>\n<p>Inoltre, ci sono due impostazioni a livello di query. La prima impostazione \u00e8 <strong>use uncompressed cache<\/strong> \u2014 attiva il suo utilizzo. Si consiglia di attivarlo per tutte le query, tranne quelle pesanti, che potrebbero leggere tutti i dati e svuotare questa cache. E la seconda impostazione \u00e8 simile a un numero massimo di righe per usare la cache. Questa limita automaticamente le query grandi per escluderle dalla cache.<\/p>\n<p><\/p>\n<h2 id=\"anchorstorage-configurationanchorkak-mozhno-nastroit-storage_configuration-dlya-hraneniya-v-operativke\"><noindex><a rel=\"nofollow\" name=\"storage-configuration\"><\/a><\/noindex>Come si pu\u00f2 configurare storage_configuration per la memorizzazione in RAM?<\/h2>\n<p><\/p>\n<blockquote><p>Nella nuova documentazione di ClickHouse ho trovato una sezione relativa <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.tech\/docs\/en\/single\/#table_engine-mergetree-multiple-volumes\">con data storage<\/a><\/noindex>. Nella descrizione c'\u00e8 un esempio con fast SSD. <\/p>\n<p>\u00c8 interessante capire come si possa configurare la stessa cosa con&nbsp;volume hot memory. E un'altra domanda. Come funziona select con&nbsp;questa organizzazione dei dati, legger\u00e0 l'intero set o solo quello che si trova sul&nbsp;disco, e i dati vengono compressi in&nbsp;memoria? E come funziona la sezione prewhere con&nbsp;questo tipo di organizzazione dei dati?<\/p><\/blockquote>\n<p>Questa configurazione influisce sul&nbsp;salvataggio dei blocchi di dati, e il loro formato non cambia affatto.<br \/>\nEsaminiamo pi\u00f9 nel dettaglio. <\/p>\n<p><\/p>\n<p>\u00c8 possibile configurare il salvataggio dei dati in&nbsp;memoria. Tutto ci\u00f2 che si configura per&nbsp;il disco&nbsp;\u00e8 il suo percorso. Crei una partizione tmpfs, montata in un certo percorso nel&nbsp;file system. Indica questo percorso come il percorso per&nbsp;il salvataggio dei dati per&nbsp;la partizione hot pi\u00f9 attiva, dove iniziano ad arrivare e a scrivere i blocchi di dati, tutto bene. <\/p>\n<p><\/p>\n<p>Ma non consiglio di farlo a causa&nbsp;della bassa affidabilit\u00e0, anche se, se hai almeno tre repliche in&nbsp;centri dati diversi, allora si pu\u00f2 fare. Se succede qualcosa, i dati possono essere recuperati. Immagina che il server si spenga e si riaccenda. La partizione si monta di nuovo, ma si trova vuota. Il server ClickHouse all'avvio vede che questi blocchi mancano, anche se, secondo i metadati di ZooKeeper, dovrebbero essere presenti. Controlla su quali repliche sono disponibili, le richiede e le scarica. In questo modo i dati vengono ripristinati. <\/p>\n<p><\/p>\n<p>In questo senso, il salvataggio dei dati in&nbsp;memoria non \u00e8 fondamentalmente diverso dal loro salvataggio su&nbsp;disco, perch\u00e9 durante la scrittura dei dati su&nbsp;disco, essi passano prima attraverso la page cache e vengono registrati fisicamente in modo ritardato. Questo dipende dalla modalit\u00e0 di montaggio del file system. Ma per precauzione dico che ClickHouse non esegue fsync durante&nbsp;l'insert.<\/p>\n<p><\/p>\n<p>Tuttavia, i dati in&nbsp;memoria sono conservati nello stesso formato che hanno su&nbsp;disco. La query select seleziona esattamente i blocchi da leggere, nei blocchi vengono selezionati i necessari intervalli di dati e vengono letti. E prewhere funziona esattamente allo stesso modo, indipendentemente dal fatto che i dati fossero in&nbsp;memoria o su&nbsp;disco.<\/p>\n<p><\/p>\n<h2 id=\"anchorlow-cardinalityanchordo-kakogo-kolichestva-unikalnyh-znacheniy-effektiven-low-cardinality\"><noindex><a rel=\"nofollow\" name=\"low-cardinality\"><\/a><\/noindex>Fino a quanti valori univoci \u00e8 efficace Low Cardinality?<\/h2>\n<p><\/p>\n<p>Low Cardinality \u00e8 progettato in modo intelligente. Costruisce dizionari di dati, ma sono locali. Prima di tutto, ci sono dizionari specifici per&nbsp;ogni blocco, in secondo luogo, anche all'interno di un blocco possono essere diversi per&nbsp;ogni intervallo. Quando il numero di valori unici raggiunge una soglia \u2014 se non ricordo male, un milione \u2014 il dizionario viene semplicemente messo da parte e ne viene creato uno nuovo.<\/p>\n<p><\/p>\n<p>La risposta in generale: per&nbsp;ogni intervallo locale \u2014 ad esempio, per&nbsp;ogni giorno \u2014 fino a un milione di valori unici Low Cardinality \u00e8 efficace. Oltre paser\u00e0 semplicemente a un fallback, in cui verranno utilizzati molti dizionari diversi, e non uno solo. Funzioner\u00e0 pi\u00f9 o meno come una colonna di tipo string, forse un po' meno efficiente, ma senza gravi degradi delle prestazioni. <\/p>\n<p><\/p>\n<h2 id=\"anchorfulltext-searchanchorkakie-luchshie-praktiki-ponbsppolnotekstovomu-poisku-ponbsptablice-snbsppyatyu-milliardami-strok\"><noindex><a rel=\"nofollow\" name=\"fulltext-search\"><\/a><\/noindex>Quali sono le migliori pratiche per la ricerca full-text su una tabella con cinque miliardi di righe?<\/h2>\n<p><\/p>\n<p>Ci sono diverse possibilit\u00e0 di risposta. La prima&nbsp;\u2014 dire che ClickHouse non \u00e8 un sistema per la ricerca testuale completa. Per questo ci sono sistemi specifici come&nbsp; <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/enterprise-search\">Elasticsearch<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"http:\/\/sphinxsearch.com\/\">Sphinx<\/a><\/noindex>. Tuttavia, incontro sempre pi\u00f9 spesso persone che dicono di passare da&nbsp;Elasticsearch a&nbsp;ClickHouse.<\/p>\n<p><\/p>\n<p>Perch\u00e9 succede questo? Lo spiegano dicendo che Elasticsearch smette di gestire il carico a un certo volume, a partire dalla costruzione degli indici. Gli indici diventano troppo ingombranti e, se semplicemente si trasferiscono i dati in&nbsp;ClickHouse, si scopre che sono conservati in modo molto pi\u00f9 efficiente in termini di volume. Inoltre, le ricerche non erano spesso del tipo che necessitano di trovare una certa frase all'interno di tutto il volume dei dati, considerando la morfologia, ma cose completamente diverse. Ad esempio, trovare nelle log di&nbsp;alcune sottosequenze di byte negli ultimi ore.<\/p>\n<p><\/p>\n<p>In questo caso, in&nbsp;ClickHouse crei un indice, il primo campo del quale sar\u00e0 la data con&nbsp;l'ora. E il maggior filtraggio dei dati avverr\u00e0 precisamente in base all'intervallo di date. All'interno dell'intervallo di date selezionato, di norma, \u00e8 possibile effettuare una ricerca testuale completa anche con il metodo brute force utilizzando like. L'operatore like in&nbsp;ClickHouse \u00e8 il pi\u00f9 efficiente che puoi trovare. Se trovi qualcosa di meglio, fammelo sapere. <\/p>\n<p><\/p>\n<p>Ma comunque like \u00e8 un full scan. E il full scan pu\u00f2 essere lento non solo per la CPU, ma anche per il disco. Se per&nbsp;caso hai un terabyte di dati al giorno, e in un giorno cerchi una certa parola, allora dovrai scansionare un terabyte. E probabilmente \u00e8 su normali dischi rigidi, e alla fine saranno caricati in modo tale che non potrai accedere a quel server via SSH.<\/p>\n<p><\/p>\n<p>In questo caso, sono pronto a suggerire un ulteriore piccolo trucco. \u00c8 un'idea un po' sperimentale \u2014 potrebbe funzionare, oppure no. In ClickHouse ci sono indici di ricerca full-text sotto forma di filtri di Bloom trigrammatici. I nostri colleghi di Arenadata li hanno gi\u00e0 testati e spesso funzionano esattamente come previsto.<\/p>\n<p><\/p>\n<p>Per utilizzare correttamente questi indici, \u00e8 importante comprendere bene come funzionano: cosa sono i filtri di Bloom trigrammatici e come scegliere la loro dimensione. Posso dirti che possono essere utili per le query su frasi rare, sottostringhe che si presentano raramente nei dati. In questo caso, verranno selezionati sottointervalli dagli indici e verranno letti meno dati.<\/p>\n<p><\/p>\n<p>Recentemente, ClickHouse ha introdotto funzioni ancora pi\u00f9 avanzate per la ricerca full-text. Prima di tutto, la possibilit\u00e0 di cercare molte sottostringhe in un solo passaggio, incluse le opzioni con o senza distinzione tra maiuscole e minuscole, con supporto per UTF-8 o solo per ASCII. Scegli l'opzione pi\u00f9 efficiente per le tue esigenze. <\/p>\n<p><\/p>\n<p>\u00c8 stata anche introdotta la ricerca di pi\u00f9 espressioni regolari in un solo passaggio. Non \u00e8 necessario scrivere X like una sottostringa o X like un'altra sottostringa. Scrivi tutto in una volta e tutto viene eseguito nel modo pi\u00f9 efficiente possibile.<\/p>\n<p><\/p>\n<p>In terzo luogo, ora c'\u00e8 la ricerca approssimativa per le regex e la ricerca di sottostringhe. Se qualcuno scrive una parola con un errore di battitura, verr\u00e0 cercata in base alla corrispondenza massima.<\/p>\n<p><\/p>\n<h2 id=\"anchorhello-and-welcomeanchorkak-luchshe-organizovat-dostup-vnbspclickhouse-dlyanbspbolshogo-kolichestva-polzovateley\"><noindex><a rel=\"nofollow\" name=\"hello-and-welcome\"><\/a><\/noindex>Come gestire l'accesso a ClickHouse per un gran numero di utenti?<\/h2>\n<p><\/p>\n<blockquote><p>Parlami di come organizzare l'accesso per un gran numero di consumatori e analisti. Come formare una coda, dare priorit\u00e0 alle query max concurrent queries e quali strumenti utilizzare?<\/p><\/blockquote>\n<p>Se il cluster \u00e8 abbastanza grande, una buona soluzione sarebbe aggiungere altri due server, che diventeranno il punto di accesso per gli analisti. In altre parole, non dovresti lasciare che gli analisti accedano ai singoli shard del cluster, ma semplicemente creare due server vuoti, senza dati, e impostare i diritti di accesso su di essi. Le impostazioni degli utenti relative alle query distribuite vengono trasferite ai server remoti. Quindi, configuri tutto su questi due server, e le impostazioni hanno effetto su tutto il cluster.<\/p>\n<p><\/p>\n<p>Questi server non hanno dati, ma la quantit\u00e0 di RAM su di essi \u00e8 molto importante per l'esecuzione delle query. Il disco pu\u00f2 anche essere utilizzato per i dati temporanei se \u00e8 abilitata l'aggregazione esterna o l'ordinamento esterno.<\/p>\n<p><\/p>\n<p>\u00c8 importante esaminare le impostazioni relative a tutti i possibili limiti. Se ora accedo al cluster \"Yandex.Metrics\" come analista e faccio una query <strong>select count from hits<\/strong>, ricever\u00f2 immediatamente un'eccezione che mi dice che non posso eseguire la query. Il numero massimo di righe che mi \u00e8 consentito analizzare \u00e8 cento miliardi, mentre nel cluster ce ne sono cinquantatr\u00e9 trilioni in un'unica tabella. Questo \u00e8 il primo limite. <\/p>\n<p><\/p>\n<p>Supponiamo che rimuova il limite sul numero di righe e esegua nuovamente la query. Allora vedr\u00f2 la seguente eccezione \u2014 l'impostazione \u00e8 attivata <strong>force index by date<\/strong>. Non posso eseguire la query se non specifico un intervallo di date. Non aspettarti che gli analisti lo indichino manualmente. Un caso tipico \u2014 \u00e8 stato scritto un intervallo di date where event date between una settimana. E poi, se non viene indicata correttamente la parentesi, invece di and si ottiene or \u2014 or URL match. Se non ci sono limiti, inizier\u00e0 a scansionare la colonna URL e consumer\u00e0 un'enorme quantit\u00e0 di risorse.<\/p>\n<p><\/p>\n<p>Inoltre, in ClickHouse ci sono due impostazioni per le priorit\u00e0. Sfortunatamente, sono molto primitive. Una \u00e8 semplicemente chiamata <strong>priorit\u00e0<\/strong>. Se priority \u2260 0, e vengono eseguite query con una certa priorit\u00e0, ma nel frattempo viene eseguita una query con priorit\u00e0 inferiore, il che significa una priorit\u00e0 pi\u00f9 alta, quindi la query con valore di priorit\u00e0 superiore, che indica una priorit\u00e0 pi\u00f9 bassa, viene semplicemente sospesa e non verr\u00e0 eseguita affatto per quel tempo.<\/p>\n<p><\/p>\n<p>\u00c8 un'impostazione molto grezza e non \u00e8 adatta per i casi in cui il cluster ha un carico costante. Ma se hai query brevi e impulsive che sono importanti, mentre il cluster \u00e8 per lo pi\u00f9 inattivo, questa impostazione andr\u00e0 bene.<\/p>\n<p><\/p>\n<p>La seguente impostazione delle priorit\u00e0 si chiama <strong>priorit\u00e0 del thread OS<\/strong>. Imposta semplicemente per tutti i thread di esecuzione della query il valore nice per lo scheduler Linux. Funziona piuttosto male, ma comunque funziona. Se imposti il valore pi\u00f9 basso di nice \u2014 \u00e8 il pi\u00f9 alto in termini di grandezza, e quindi ha la priorit\u00e0 pi\u00f9 bassa \u2014 e per le query ad alta priorit\u00e0 impostare -19, la CPU consumer\u00e0 le query a bassa priorit\u00e0 circa quattro volte meno rispetto a quelle ad alta priorit\u00e0. <\/p>\n<p><\/p>\n<p>\u00c8 necessario impostare anche il tempo massimo di esecuzione della query&nbsp;\u2014 diciamo, cinque minuti. La velocit\u00e0 minima di esecuzione della query&nbsp;\u2014 questa \u00e8 la cosa migliore. Questa impostazione esiste da tempo e serve non solo per affermare che ClickHouse non rallenta, ma per forzarlo.<\/p>\n<p><\/p>\n<p>Immagina di configurare: se qualche query elabora meno di un milione di righe al&nbsp;secondo&nbsp;\u2014 non si pu\u00f2 fare. Questo danneggia il nostro buon nome, il nostro buon database. Diamo semplicemente a questo un divieto. In realt\u00e0 ci sono due impostazioni. Una si chiama <strong>min execution speed<\/strong> \u2014 righe al&nbsp;secondo, e l'altra si chiama timeout before checking min execution speed&nbsp;\u2014 di default quindici secondi. Quindi quindici secondi sono consentiti, ma poi, se \u00e8 lento, si lancia semplicemente un'eccezione \u2014 si interrompe la query.<\/p>\n<p><\/p>\n<p>\u00c8 necessario configurare anche le quote. In&nbsp;ClickHouse c'\u00e8 una funzionalit\u00e0 integrata di quote che calcola il consumo delle risorse. Ma, sfortunatamente, non riguarda le risorse fisiche come CPU, dischi, ma quelle logiche&nbsp;\u2014 il numero di query elaborate, righe e byte letti. E si pu\u00f2 impostare, ad esempio, un massimo di cento query in cinque minuti e mille query all'ora.<\/p>\n<p><\/p>\n<p>Perch\u00e9 \u00e8 importante? Perch\u00e9 parte delle query di analisi saranno eseguite manualmente direttamente dal cliente di&nbsp;ClickHouse. E andr\u00e0 tutto bene. Ma se nella tua azienda ci sono analisti esperti, scriveranno uno script, e nello script potrebbe esserci un errore. E questo errore porter\u00e0 a un ciclo infinito nell'esecuzione della query. Da questo bisogna proteggersi.<\/p>\n<p><\/p>\n<h2 id=\"anchorsmorgasbordanchormozhno-li-otdat-rezultaty-odnogo-zaprosa-desyati-klientam\"><noindex><a rel=\"nofollow\" name=\"smorgasbord\"><\/a><\/noindex>\u00c8 possibile fornire i risultati di una query a dieci clienti?<\/h2>\n<p><\/p>\n<blockquote><p>Abbiamo alcuni utenti che amano arrivare con query molto grandi nello stesso momento. La query \u00e8 grande, in linea di principio viene eseguita rapidamente, ma a causa del fatto che ci sono molte di queste query contemporaneamente, diventa molto dolorosa. \u00c8 possibile eseguire la stessa query, che arriva dieci volte di seguito, una volta sola e restituire i risultati a dieci clienti?<\/p><\/blockquote>\n<p>Il problema \u00e8 che non abbiamo i risultati della cache o della cache dei dati intermedi. C'\u00e8 la cache della pagina del sistema operativo, che consente di non leggere i dati dal disco ripetutamente, ma, sfortunatamente, i dati devono comunque essere decompressi, deserializzati e rielaborati. <\/p>\n<p><\/p>\n<p>Ci piacerebbe in qualche modo evitare ci\u00f2, sia cachando i dati intermedi, sia organizzando query simili in una sorta di coda e aggiungendo una cache dei risultati. Attualmente abbiamo in fase di sviluppo una pull request che aggiunge la cache delle query, ma solo per le sottoquery nella sezione in e join \u2014 quindi la soluzione non \u00e8 completa.<\/p>\n<p><\/p>\n<p>Tuttavia, abbiamo anche situazione simile. Un esempio canonico \u00e8 quando ci sono query con paginazione. C'\u00e8 un rapporto, ci sono diverse pagine, e c'\u00e8 una query limit 10. Poi la stessa cosa, ma limit 10,10. Poi ancora la pagina successiva. E ci si chiede, perch\u00e9 calcoliamo tutto questo ogni volta? Ma attualmente non ci sono soluzioni e non possiamo evitarlo.<\/p>\n<p><\/p>\n<p>C'\u00e8 una soluzione alternativa che viene installata come sidecar accanto a&nbsp;ClickHouse \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Vertamedia\/chproxy\">ClickHouse Proxy<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> In ClickHouse Proxy c'\u00e8 un limitatore di velocit\u00e0 integrato e una cache dei risultati. Ci sono state fatte molte impostazioni, perch\u00e9 era necessario risolvere un compito simile. Il Proxy consente di limitare le query, mettendole in coda, e di configurare per quanto tempo vive la cache delle query. Se le query sono davvero identiche, il Proxy le restituir\u00e0 molte volte, mentre andr\u00e0 in&nbsp;ClickHouse solo una volta.<\/p>\n<p><\/p>\n<p>Anche Nginx ha una cache nella versione gratuita, e questo funzioner\u00e0. Nginx ha addirittura impostazioni che, se le query arrivano contemporaneamente, rallenter\u00e0 le altre finch\u00e9 una non sar\u00e0 eseguita. Ma in ClickHouse Proxy la configurazione \u00e8 molto migliore. \u00c8 stato progettato specificamente per ClickHouse, per queste query, quindi \u00e8 pi\u00f9 adatto. Inoltre, \u00e8 facile da installare. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>Cosa fare con le operazioni asincrone e le viste materializzate?<\/h2>\n<p><\/p>\n<blockquote><p>C'\u00e8 un problema che le operazioni con il motore di sostituzione sono asincrone&nbsp;\u2014 prima i dati vengono scritti, poi si verifica la loro compressione. Se sotto la tabella vive una tabella materializzata con alcuni aggregati, i duplicati verranno registrati in essa. E se non c'\u00e8 qualche logica complessa, i dati saranno duplicati. Che cosa si pu\u00f2 fare a riguardo?<\/p>\n<p>C'\u00e8 una soluzione ovvia&nbsp;\u2014 implementare un trigger per una particolare classe di materializzazioni durante l'operazione asincrona di compressione. Ci sono delle \"proiettili d'argento\", piani per implementare funzionalit\u00e0 simili?<\/p><\/blockquote>\n<p>Vale la pena di approfondire come funziona la deduplica. Ci\u00f2 di cui parler\u00f2 ora non riguarda necessariamente la questione, ma \u00e8 sempre bene tenerlo a mente.<\/p>\n<p><\/p>\n<p>Quando si inserisce in una&nbsp;tabella replicata, c'\u00e8 una deduplicazione dei blocchi interamente inseriti. Se reinserisci lo stesso blocco, contenente lo stesso numero di righe nello&nbsp;stesso ordine, i dati verranno deduplicati. Riceverai \u201cOk\u201d in risposta all'insert, ma verr\u00e0 effettivamente scritta solo una serie di dati, e non sar\u00e0 duplicata.<\/p>\n<p><\/p>\n<p>Questo \u00e8 necessario per&nbsp;chiarezza. Se durante l'inserimento hai ricevuto \u201cOk\u201d, significa che i tuoi dati sono stati inseriti. Se hai ricevuto un errore da&nbsp;ClickHouse, significa che non sono stati inseriti, e l'inserimento deve essere ripetuto. Ma se durante l'inserimento la connessione \u00e8 stata interrotta, non sai se i dati sono stati inseriti o meno. L'unica opzione \u00e8 ripetere l'inserimento. Se i dati sono stati effettivamente inseriti e li hai reinseriti, c'\u00e8 una deduplicazione dei blocchi. Questa \u00e8 necessaria per evitare duplicati. <\/p>\n<p><\/p>\n<p>\u00c8 importante anche come funziona per&nbsp;le rappresentazioni materializzate. Se i dati sono stati deduplicati durante l'inserimento nella&nbsp;tabella principale, non andranno nemmeno nella rappresentazione materializzata.<\/p>\n<p><\/p>\n<p>Ora riguardo alla tua domanda. Hai una situazione pi\u00f9 complessa, perch\u00e9 stai registrando duplicati di singole righe. Cio\u00e8, non \u00e8 un'intera serie a essere duplicata, ma singole righe specifiche, e si sovrappongono in background. In effetti, i dati si sovrapporranno nella&nbsp;tabella principale, mentre nella rappresentazione materializzata andranno le righe non sovrapposte, e durante i merge non succeder\u00e0 nulla alle rappresentazioni materializzate. Perch\u00e9 la rappresentazione materializzata&nbsp;\u00e8 nient'altro che un trigger su&nbsp;insert. In altre operazioni, non accade nulla di ulteriore.<\/p>\n<p><\/p>\n<p>E non posso davvero darti buone notizie qui. \u00c8 necessario cercare una soluzione specifica per questo caso. Ad esempio, \u00e8 possibile fare un replacement anche nella rappresentazione materializzata, e forse il metodo di deduplicazione funzioner\u00e0 allo stesso modo. Ma sfortunatamente, non sempre. Se \u00e8 aggregante, non funzioner\u00e0. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Anche noi avevamo un po' di problematica nello&nbsp;costruire soluzioni. C'era un problema con le visualizzazioni pubblicitarie, e ci sono alcuni dati che possiamo mostrare in tempo reale: sono semplici visualizzazioni. Raramente si duplicano, ma se ci\u00f2 accade, alla fine li sovrapponiamo. E ci sono cose che non possono essere duplicate: click e tutta questa storia. Ma volevamo anche mostrarli praticamente subito.<\/p>\n<p><\/p>\n<p>Come sono state create le rappresentazioni materializzate? C'erano rappresentazioni in cui si scrive direttamente: si registra nei dati grezzi e si scrive nelle view. L\u00ec, a un certo punto i dati non sono molto corretti, si duplicano e cos\u00ec via. E c'\u00e8 una seconda parte della&nbsp;tabella, dove appaiono esattamente come le rappresentazioni materializzate, cio\u00e8 per struttura sono assolutamente identiche. Di tanto in tanto, ricontiamo i dati, risolviamo i dati senza duplicati, e scriviamo in quelle tabelle. <\/p>\n<p><\/p>\n<p>Abbiamo utilizzato l'API: in&nbsp;ClickHouse non funzionerebbe manualmente. E l'API guarda: quando ho la data dell'ultimo inserimento nella&nbsp;tabella, dove ci sono gi\u00e0 dati corretti garantiti, calcolati, e fa una richiesta a una tabella e all'altra. Da una seleziona fino a un certo limite di tempo, e dall'altra aggiunge ci\u00f2 che non \u00e8 ancora stato calcolato. E questo funziona, ma non con i mezzi di ClickHouse stesso.<\/p>\n<p><\/p>\n<p>Se hai qualche API&nbsp;\u2014 per analisti, per utenti&nbsp;\u2014 allora, in linea di principio, questo \u00e8 un'opzione. Puoi sempre ricontare, sempre ricalcolare. Puoi farlo una volta al giorno o a un altro momento. Scegli tu il range che non \u00e8 critico per te.<\/p>\n<p><\/p>\n<h2 id=\"anchordashboardanchorv-clickhouse-mnogo-logov-kak-ya-mogu-videt-vsyo-chto-proishodit-s-serverom-vnbspmomente\"><noindex><a rel=\"nofollow\" name=\"dashboard\"><\/a><\/noindex>In ClickHouse ci sono molti log. Come posso vedere tutto ci\u00f2 che accade con il server, in tempo reale?<\/h2>\n<p><\/p>\n<blockquote><p>In ClickHouse c'\u00e8 un numero molto elevato di log diversi, e questo numero continua a crescere. Nelle nuove versioni alcuni di essi sono persino attivati di default, nelle versioni precedenti devono essere attivati durante l'aggiornamento. Nonostante ci\u00f2, ci sono sempre di pi\u00f9. Vorrei alla fine vedere cosa sta succedendo ora con il mio server, magari su un dashboard riassuntivo. <\/p>\n<p>Non avete nella&nbsp;vostra squadra ClickHouse, o nelle squadre dei vostri amici, coloro che supportano un certo funzionalit\u00e0 di dashboard gi\u00e0 pronte, che mostrerebbero questi log in forma di prodotto gi\u00e0 pronto? Alla fine, guardare i log in&nbsp;ClickHouse \u00e8 interessante. Ma sarebbe molto bello se fosse gi\u00e0 in forma di dashboard. Mi farebbe piacere. <\/p><\/blockquote>\n<p>Ci sono cruscotti, anche se non standardizzati. Nella nostra azienda, circa 60 squadre utilizzano ClickHouse, e la cosa strana \u00e8 che molte di esse hanno cruscotti che hanno creato da sole, e sono un po' diversi. Alcune squadre utilizzano un'installazione interna di 'Yandex.Cloud'. L\u00ec ci sono alcuni report pronti, anche se non tutti i necessari. Altre squadre hanno le proprie soluzioni. <\/p>\n<p><\/p>\n<p>I miei colleghi di 'Metrics' hanno il loro cruscotto in Grafana, e io ho il mio sul loro stesso cluster. L\u00ec osservo metriche come il cache hit per la cache di hit. E ancora pi\u00f9 complicato \u00e8 che utilizziamo strumenti diversi. Ho creato il mio cruscotto con uno strumento molto vecchio chiamato Graphite-web. \u00c8 abbastanza brutto. E continuo ad usarlo, anche se Grafana sarebbe probabilmente pi\u00f9 comoda e bella. <\/p>\n<p><\/p>\n<p>Le basi dei cruscotti sono le stesse. Sono metriche di sistema per il cluster: CPU, memoria, disco, rete. Altre metriche includono il numero di richieste simultanee, il numero di merge simultanei, il numero di richieste al secondo, il numero massimo di parti per le tabelle MergeTree, il lag di replica, la dimensione della coda di replica, il numero di righe inserite al secondo, il numero di blocchi inseriti al secondo. Tutto ci\u00f2 che non proviene dai registri, ma dalle metriche.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobayev:<\/strong> Alexei, vorrei fare una piccola correzione. Esiste Grafana. Grafana ha una datasource, che \u00e8 ClickHouse. Quindi posso fare richieste direttamente a ClickHouse da Grafana. In ClickHouse c'\u00e8 una tabella con i registri, e questa \u00e8 la stessa per tutti. Vorrei quindi, in Grafana, fare riferimento a questa tabella dei registri e vedere le richieste che il mio server genera. Sarebbe fantastico avere un cruscotto simile.<\/p>\n<p><\/p>\n<p>L'ho assemblato io stesso. Ma mi sorge una domanda: se tutto fosse standardizzato e Grafana fosse utilizzata da tutti, perch\u00e9 in 'Yandex' non c'\u00e8 un cruscotto ufficiale del genere?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> In realt\u00e0, la datasource per ClickHouse \u00e8 attualmente supportata da Altinity. E voglio semplicemente dare una direzione, dove scavare e chi sollecitare. Si pu\u00f2 chiedere a loro, perch\u00e9 'Yandex' alla fine crea ClickHouse, non la storia intorno ad esso. Altinity \u00e8 l'azienda principale che attualmente promuove ClickHouse. Non lo abbandoneranno, ma lo supporteranno. Perch\u00e9 in sostanza, per caricare un cruscotto sul sito di Grafana, \u00e8 sufficiente registrarsi e caricarlo \u2013 non ci sono problemi particolari. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Negli ultimi anni, ClickHouse ha aggiunto molte funzionalit\u00e0 per il profiling delle richieste. Ci sono metriche per ogni richiesta riguardo all'uso delle risorse. E recentemente \u00e8 stato aggiunto anche un profiler di richieste a un livello ancora pi\u00f9 basso, per vedere dove ciascuna richiesta spende ogni millisecondo. Ma per usufruire di questa funzionalit\u00e0, devo aprire il client da console e digitare il comando che dimentico sempre. L'ho salvato da qualche parte e continuo a dimenticare dove. <\/p>\n<p><\/p>\n<p>Vorrei uno strumento in cui ci sia semplicemente scritto: ecco le vostre richieste pesanti, raggruppate per classe di richieste. Cliccando su una qualsiasi, mi direbbe che \u00e8 pesante per questo motivo. Attualmente non c'\u00e8 una soluzione simile. Ed \u00e8 davvero piuttosto strano che, quando le persone mi chiedono: 'Ci sono cruscotti pronti per Grafana?', io dico: 'Visitate il sito di Grafana, c'\u00e8 la comunit\u00e0 \u201cCruscotti\u201d, e l\u00ec ci sono un cruscotto di Dimka, un cruscotto di Kostyan. Che cosa siano non lo so, non li ho mai usati'.<\/p>\n<p><\/p>\n<h2 id=\"anchorzenanchorkak-vozdeystvovat-na-merdzhi-chtoby-server-ne-padal-vnbspoom\"><noindex><a rel=\"nofollow\" name=\"zen\"><\/a><\/noindex>Come impattare sui merge per non far crollare il server in OOM?<\/h2>\n<p><\/p>\n<blockquote><p>Ho una tabella con una sola partizione, che \u00e8 ReplacingMergeTree. Ho scritto dati in essa per quattro anni. Dovevo fare un alter e rimuovere alcuni dati.<\/p>\n<p>L'ho fatto, e durante l'elaborazione di questa richiesta utilizza tutta la memoria su tutti i server del cluster, e tutti i server del cluster sono crollati in OOM. Poi si sono ripresi tutti insieme, hanno iniziato a eseguire il merge dello stesso operazione su quel blocco di dati, e sono crollati di nuovo in OOM. Poi si sono ripresi di nuovo e sono crollati di nuovo. E questa situazione non si \u00e8 fermata.<\/p>\n<p>Poi si \u00e8 scoperto che era effettivamente un bug, che i ragazzi hanno fissato. \u00c8 davvero fantastico, grazie mille. Ma mi \u00e8 rimasta la sensazione. E ora, quando penso di dover fare un merge nella tabella, mi pongo la domanda: perch\u00e9 non posso in qualche modo influenzare questi merge? Ad esempio, limitarli in base alla quantit\u00e0 di memoria RAM necessaria, o in generale rispetto alla loro quantit\u00e0, che elaborer\u00e0 specificamente questa tabella.<\/p>\n<p>Ho una tabella chiamata \u00abMetriche\u00bb, per favore elabora in due flussi. Non creare dieci o cinque merge in parallelo, fallo in due. Penso che con due avrei abbastanza memoria, mentre per dieci potrebbe non bastare. Perch\u00e9 rimane la paura? Perch\u00e9 la tabella cresce, e un giorno mi trover\u00f2 nella situazione in cui non sar\u00e0 solo un bug, ma perch\u00e9 i dati cambieranno in una tale quantit\u00e0 che semplicemente non avr\u00f2 memoria sul server. E allora il server andr\u00e0 in OOM durante il merge. Posso annullare la mutazione, ma i merge non possono essere annullati.<\/p><\/blockquote>\n<p>Sai, durante i merge il server non andr\u00e0 in OOM, perch\u00e9 durante il merge viene utilizzata solo una piccola quantit\u00e0 di RAM per un intervallo di dati. Quindi andr\u00e0 tutto bene indipendentemente dal volume dei dati.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobayev:<\/strong> Va bene. C'\u00e8 il fatto che dopo aver effettuato il bug fix, ho scaricato la nuova versione, e su un'altra tabella, pi\u00f9 piccola, con molte partizioni, ho effettuato un'operazione simile. E durante il merge il server ha consumato circa 100 GB di RAM. Avevo 150 occupati, 100 consumati, e mi sono rimasti 50 GB, quindi non sono andato in OOM.<\/p>\n<p><\/p>\n<p>Cosa mi protegge attualmente dal non andare in OOM, se effettivamente consuma 100 GB di RAM? Cosa fare se all'improvviso la RAM durante i merge finisce?<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> C'\u00e8 un problema, il consumo di RAM durante i merge non \u00e8 limitato. E un secondo problema \u00e8 che, se un merge \u00e8 stato programmato, deve essere eseguito, perch\u00e9 \u00e8 registrato nel log di replica. Il log di replica contiene le azioni necessarie per portare la replica in uno stato coerente. Se non si effettuano le manovre manuali per ripristinare questo log di replica, il merge dovr\u00e0 essere eseguito in ogni caso.<\/p>\n<p><\/p>\n<p>Certo, non sarebbe male avere un limite sulla RAM, che \u00abper precauzione\u00bb protegge proprio dall'OOM. Questo non aiuter\u00e0 il merge a completarsi, inizier\u00e0 di nuovo, raggiunger\u00e0 una certa soglia, lancer\u00e0 un'eccezione, e poi ricomincer\u00e0 - non ne verr\u00e0 nulla di buono. Ma in linea di principio, introdurre questo limite sarebbe utile.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>Come si svilupper\u00e0 il driver Golang per ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>Il driver Golang scritto da Kirill Shvakov \u00e8 attualmente ufficialmente supportato dal team di ClickHouse. Esso <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">\u00e8 presente nel repository di ClickHouse<\/a><\/noindex>, ed \u00e8 ora grande e reale.<\/p>\n<p>Una piccola nota. Esiste un meraviglioso e amato sistema di archiviazione di forme normali di ordine infinito \u2014 Vertica. Hanno anche il loro driver Python ufficiale, supportato dagli sviluppatori di Vertica. \u00c8 successo diverse volte che le versioni del sistema di archiviazione e del driver si discostassero notevolmente, causando l'interruzione del funzionamento del driver in un certo momento. E un secondo punto. La supporto per questo driver ufficiale, mi sembra, \u00e8 gestito con il sistema \"nipplet\" \u2014 scrivi loro un issue, e rimane in sospeso per sempre.<\/p>\n<p>Ho due domande. Attualmente il driver Golang di Kirill \u00e8 quasi il modo predefinito per comunicare da Golang con ClickHouse. A meno che qualcuno non comunichi ancora tramite l'interfaccia http, perch\u00e9 gli piace di pi\u00f9. Come avverr\u00e0 lo sviluppo di questo driver? Sar\u00e0 sincronizzato con eventuali cambiamenti significativi nel sistema di archiviazione stesso? E qual \u00e8 la procedura per la revisione degli issue? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> La prima cosa \u00e8 come tutto \u00e8 organizzato burocraticamente. Questo punto non \u00e8 stato discusso, quindi non posso rispondere.<\/p>\n<p><\/p>\n<p>Per rispondere alla domanda sul problema, \u00e8 necessaria una breve storia sul driver. Ho lavorato in un'azienda con molti dati. Era un sistema pubblicitario con un'enorme quantit\u00e0 di eventi da memorizzare. A un certo punto \u00e8 arrivato ClickHouse. Abbiamo trasferito i dati l\u00ec, e per un po' tutto andava bene, poi ClickHouse \u00e8 andato in crash. A quel punto abbiamo deciso che non ci serviva. <\/p>\n<p><\/p>\n<p>Un anno dopo siamo tornati all'idea di utilizzare ClickHouse, e dovevamo in qualche modo scrivere i dati l\u00ec. La premessa era che l'hardware era molto debole, con poche risorse. Ma abbiamo sempre lavorato in questo modo, quindi abbiamo guardato verso il protocollo nativo.<\/p>\n<p><\/p>\n<p>Poich\u00e9 lavoravamo in Go, era chiaro che ci serviva un driver in Go. Ho lavorato a questo progetto praticamente a tempo pieno - era il mio compito lavorativo. Fino a un certo punto, l'abbiamo portato avanti, e sostanzialmente nessuno pensava che qualcun altro al di fuori di noi lo avrebbe usato. Poi \u00e8 arrivato CloudFlare con esattamente lo stesso problema, e per un certo periodo abbiamo lavorato bene insieme, poich\u00e9 avevano le stesse esigenze. E lo facevamo sia in ClickHouse che nel driver. <\/p>\n<p><\/p>\n<p>A un certo punto ho smesso di occuparmene, perch\u00e9 la mia attivit\u00e0 riguardo a ClickHouse e il mio lavoro sono cambiati un po'. Quindi i problemi non vengono chiusi. Di tanto in tanto, nel repository, alcune persone fanno commit perch\u00e9 hanno bisogno di qualcosa. Allora guardo le pull request e a volte modifico anche io qualcosa, ma questo succede raramente.<\/p>\n<p><\/p>\n<p>Vorrei tornare al driver. Qualche anno fa, quando tutto \u00e8 iniziato, ClickHouse era anche diverso e con altre possibilit\u00e0. Ora abbiamo una comprensione su come riprogettare il driver affinch\u00e9 funzioni bene. Se ci\u00f2 accade, la versione 2 sar\u00e0 comunque incompatibile a causa dei workaround accumulati. <\/p>\n<p><\/p>\n<p>Non so come organizzare questa cosa. Non ho molto tempo. Se alcune persone decideranno di sviluppare il driver, potr\u00f2 aiutarle e spiegare cosa fare. Ma la partecipazione attiva di \u00abYandex\u00bb nello sviluppo del progetto non \u00e8 stata discussa. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Attualmente non c'\u00e8 burocrazia riguardo a questi driver. L'unica cosa \u00e8 che sono stati ufficialmente riconosciuti, quindi questo driver \u00e8 considerato la soluzione ufficiale predefinita per Go. Ci sono altri driver, ma sono separati. <\/p>\n<p><\/p>\n<p>Non abbiamo alcuno sviluppo interno per questi driver. La domanda \u00e8 se possiamo assumere una persona separata, non specificamente per questo driver, ma per lo sviluppo di tutti i driver della community, oppure se possiamo trovare qualcuno all'esterno. <\/p>\n<p><\/p>\n<h2 id=\"anchorlazy-loadanchorvneshniy-slovar-ne-podnimaetsya-posle-perezagruzki-snbspvklyuchennoy-nastroykoy-lazy_load-chto-delat\"><noindex><a rel=\"nofollow\" name=\"lazy-load\"><\/a><\/noindex>Il dizionario esterno non si attiva dopo il riavvio con l'impostazione lazy_load attivata. Cosa fare?<\/h2>\n<p><\/p>\n<blockquote><p>Abbiamo attivato l'impostazione lazy_load, e dopo il riavvio del server, il dizionario non si attiva da solo. Si attiva solo dopo che un utente accede a questo dizionario. E alla prima richiesta restituisce un errore. \u00c8 possibile caricare automaticamente i dizionari tramite ClickHouse, o dobbiamo sempre controllarne la disponibilit\u00e0 per evitare che gli utenti ricevano errori?<\/p>\n<p>Potremmo avere una vecchia versione di ClickHouse, perci\u00f2 il dizionario non si caricava automaticamente. Pu\u00f2 essere?<\/p><\/blockquote>\n<p>Innanzitutto, i dizionari possono essere caricati forzatamente tramite una query. <strong>ricarica dizionari di sistema<\/strong>In secondo luogo, riguardo all'errore: se il dizionario \u00e8 gi\u00e0 stato caricato, le query funzioneranno con i dati gi\u00e0 caricati. Se il dizionario non \u00e8 stato ancora caricato, verr\u00e0 caricato al momento della query.<\/p>\n<p><\/p>\n<p>Per i dizionari pesanti, non \u00e8 molto comodo. Ad esempio, \u00e8 necessario caricare un milione di righe da MySQL. Qualcuno fa una semplice select, ma questa select attender\u00e0 quel milione di righe. Qui ci sono due soluzioni. La prima \u00e8 disattivare lazy_load. La seconda \u00e8, quando il server si avvia, prima di caricarlo, eseguire <strong>ricarica dizionario di sistema<\/strong> o semplicemente eseguire una query che utilizza il dizionario. Allora il dizionario sar\u00e0 caricato. Dobbiamo controllare la disponibilit\u00e0 dei dizionari con l'impostazione lazy_load attivata, perch\u00e9 ClickHouse non li carica automaticamente.<\/p>\n<p><\/p>\n<p>Per l'ultima domanda, la risposta \u00e8 che potrebbe trattarsi di una versione obsoleta o che occorre fare debugging. <\/p>\n<p><\/p>\n<h2 id=\"anchorreload-dictionariesanchorkak-byt-snbsptem-chto-system-reload-dictionaries-ne-podgruzhaet-ni-odin-iznbspmnozhestva-slovarey-esli-hotya-by-odin-iznbspnih-padaet-snbsposhibkoy\"><noindex><a rel=\"nofollow\" name=\"reload-dictionaries\"><\/a><\/noindex>Cosa fare se il system reload dictionaries non carica nessuno dei numerosi dizionari, se anche solo uno di essi presenta un errore?<\/h2>\n<p><\/p>\n<blockquote><p>C'\u00e8 anche una domanda riguardo a system reload dictionaries. Abbiamo due dizionari: uno non si carica, l'altro si carica. System reload dictionaries non carica alcun dizionario in questo caso, e dobbiamo caricare specificamente quello per nome usando system reload dictionary. \u00c8 anche questo legato alla versione di ClickHouse?<\/p><\/blockquote>\n<p>Voglio darvi una buona notizia. Questo comportamento \u00e8 cambiato. Quindi, se aggiornate ClickHouse, cambier\u00e0 anche questo. Se non vi soddisfa l'attuale comportamento <strong>ricarica dizionari di sistema<\/strong>, aggiorna e speriamo che migliori la situazione.<\/p>\n<p><\/p>\n<h2 id=\"anchorconnectionanchorest-li-sposob-konfigurirovat-rekvizity-vnbspkonfige-clickhouse-no-ne-svetit-ih-prinbsposhibkah\"><noindex><a rel=\"nofollow\" name=\"connection\"><\/a><\/noindex>Esiste un modo per configurare le credenziali nel file di configurazione di ClickHouse senza rivelarle in caso di errori?<\/h2>\n<p><\/p>\n<blockquote><p>La prossima domanda riguarda gli errori relativi al dizionario, in particolare alle credenziali. Abbiamo specificato le credenziali di connessione nel config di ClickHouse per il dizionario, e in caso di errore otteniamo queste credenziali e la password nella risposta. <\/p>\n<p>Abbiamo risolto quest'errore esternalizzando le credenziali nel file di configurazione del driver ODBC. C'\u00e8 un modo per configurare le credenziali nel config di ClickHouse, senza esporle in caso di errori?<\/p><\/blockquote>\n<p>La soluzione qui \u00e8 davvero indicare queste credenziali in odbc.ini, mentre nel ClickHouse specificare solo il nome del data source ODBC. Non ci sar\u00e0 nulla di simile per altre fonti di dizionario: n\u00e9 per il dizionario con MySQL, n\u00e9 per gli altri dovresti vedere la password in caso di messaggio di errore. Per ODBC controller\u00f2 anche \u2014 se c'\u00e8 qualcosa, bisogna semplicemente rimuoverlo.<\/p>\n<p><\/p>\n<h2 id=\"anchorzoom-backgroundsanchorbonus-fony-dlya-zuma-snbspposidelok\"><noindex><a rel=\"nofollow\" name=\"zoom-backgrounds\"><\/a><\/noindex>Bonus: sfondi per Zoom dagli incontri<\/h2>\n<p><\/p>\n<p>Cliccando sull'immagine, ai lettori pi\u00f9 perseveranti si apriranno fondi bonus legati alle riunioni. Spegniamo il fuoco insieme ai mascot della tecnologia Avito, discutiamo con i colleghi nella stanza del sysadmin o in un vecchio club informatico e teniamo un daily sotto il ponte con graffiti sullo sfondo.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse per utenti avanzati: domande e risposte\" src=\"\/wp-content\/uploads\/2020\/05\/38b2ea076283285d934913c395863eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/500678\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430&nbsp;\u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437&nbsp;\u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros. \u041e\u0431\u0441\u0443\u0436\u0434\u0430\u043b\u0438, \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438 \u043a\u0430\u043a\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0443&nbsp;\u043d\u0430\u0441 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442. \u041f\u043e&nbsp;\u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0432\u0441\u0442\u0440\u0435\u0447\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u0441&nbsp;\u043e\u0442\u0432\u0435\u0442\u0430\u043c\u0438 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432 \u043d\u0430&nbsp;\u043d\u0430\u0448\u0438 \u0438 \u0437\u0440\u0438\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u043f\u0440\u043e&nbsp;\u0431\u044d\u043a\u0430\u043f\u044b, \u0440\u0435\u0448\u0430\u0440\u0434\u0438\u043d\u0433 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0441\u043b\u043e\u0432\u0430\u0440\u0438, Golang-\u0434\u0440\u0430\u0439\u0432\u0435\u0440 \u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u0435\u0440\u0441\u0438\u0439 ClickHouse. \u041e\u043d\u0430 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80776,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80775","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47ClickHouse per utenti avanzati in domande e risposte | ProHoster","description":"Ad aprile, gli ingegneri di Avito si sono riuniti per un incontro online con il chief developer di ClickHouse, Aleksej Milovidov, e Kirill Shvakov, sviluppatore Golang dell'azienda Integros.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster","og:description":"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-08T11:42:47+00:00","article:modified_time":"2020-05-08T11:42:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80775","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:11:22","updated":"2022-09-28 05:48:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/80775","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=80775"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/80775\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/80776"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=80775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=80775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=80775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}