{"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 in 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 capo sviluppatore di ClickHouse, Alexey Milovidov, e Kirill Shvakov, sviluppatore Golang dell'azienda Integros. Hanno discusso di come utilizziamo il sistema di gestione dei database e delle difficolt\u00e0 che incontriamo. <\/p>\n<p><\/p>\n<p>In seguito all'incontro, abbiamo raccolto un articolo con le risposte degli esperti alle nostre domande e a quelle del pubblico riguardanti i backup, il resharding dei dati, i dizionari esterni, il driver Golang e l'aggiornamento delle versioni di ClickHouse. Pu\u00f2 essere utile per gli sviluppatori che lavorano attivamente con il DBMS di Yandex e sono interessati al suo presente e futuro. Di default, le risposte di Alexey Milovidov, a meno che non sia indicato diversamente. <\/p>\n<p><\/p>\n<p>Attenzione, sotto ci sono molte informazioni. Speriamo che il contenuto con le domande ti aiuti a orientarti.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse per utenti avanzati in 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 costantemente 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\">Sar\u00e0 possibile organizzare un ritardo controllato delle repliche nei volumi?<\/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 resharding dei dati?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">In ClickHouse esiste un'utility chiamata clickhouse-copier. Puoi parlarne?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Avevate un progetto pilota chiamato resharding. Che fine ha fatto?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">\u00c8 possibile unire tutte le parti dei dati prima di spostarle su dischi pi\u00f9 lenti?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Come si pu\u00f2 migrare alle 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\">Il comando 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 di lettura?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">Cosa ottimizzare in ClickHouse affinch\u00e9 ci siano pi\u00f9 dati nella cache?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Come si pu\u00f2 configurare storage_configuration per l'archiviazione in RAM?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">Fino a quanti valori unici \u00e8 efficace Low Cardinality?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Quali sono le migliori pratiche per la ricerca testuale full-text in una tabella con cinque miliardi di righe?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Qual \u00e8 il modo migliore per gestire l'accesso a ClickHouse per un grande numero di utenti?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">\u00c8 possibile restituire i risultati di una query a dieci client?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">Come gestire 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 controllare i merge affinch\u00e9 il server non vada in OOM?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Come avverr\u00e0 lo sviluppo del driver Golang per ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">Il dizionario esterno non si attiva dopo il riavvio con l'impostazione lazy_load attiva. Cosa fare?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">Come affrontare il fatto che il system reload dictionaries non carica nessuno dei numerosi dizionari se anche solo uno di essi genera un errore?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">C'\u00e8 un modo per configurare le credenziali nel&nbsp;config di ClickHouse senza esporle in caso di errori?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Bonus: sfondi per Zoom con&nbsp;le riunioni<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Se non si desidera leggere il testo, \u00e8 possibile guardare la registrazione della riunione <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">sul&nbsp;nostro canale YouTube<\/a><\/noindex>. I timestamp sono nel&nbsp;primo commento sotto&nbsp;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 aggiornato costantemente, mentre i nostri dati&nbsp;non lo sono. Cosa fare al riguardo?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse viene aggiornato costantemente, ma i nostri dati, che sono stati elaborati con optimize final, non vengono aggiornati e sono archiviate in&nbsp;una copia di sicurezza. <\/p>\n<p>Supponiamo che ci sia stato un problema e che i dati siano stati persi. Abbiamo deciso di ripristinarli e ci siamo accorti che le vecchie partizioni, archiviate nei&nbsp;server di backup, sono molto diverse dalla versione di ClickHouse attualmente in uso. Cosa fare in questa situazione, \u00e8 possibile?<\/p><\/blockquote>\n<p>La situazione in cui hai ripristinato i dati da&nbsp;un backup in un formato vecchio, ma nella nuova versione non si collegano, non \u00e8 possibile. Ci assicuriamo che il formato dei dati in&nbsp;ClickHouse rimanga sempre retrocompatibile. Questo \u00e8 molto pi\u00f9 importante della compatibilit\u00e0 retroattiva delle funzionalit\u00e0, qualora il comportamento di una funzione raramente utilizzata sia cambiato. I dati archiviati su&nbsp;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 fare backup tenendo conto che abbiamo operazioni di optimize final, un'enorme base dati in terabyte e dati che vengono aggiornati, diciamo, negli ultimi tre giorni, senza ulteriori procedure? <\/p>\n<p>Possiamo scrivere la nostra soluzione personalizzata e in&nbsp;bash scrivere: raccogli questi backup in questo modo. Forse non c'\u00e8 bisogno di inventare nulla, e la bicicletta \u00e8 gi\u00e0 stata inventata? <\/p><\/blockquote>\n<p>Iniziamo parlando delle migliori pratiche. I miei colleghi consigliano sempre, quando si parla di backup, di menzionare il servizio \"Yandex.Cloud\", dove questo compito \u00e8 gi\u00e0 stato risolto. Quindi usatelo, se possibile. <\/p>\n<p><\/p>\n<p>Non esiste una soluzione completa e al cento per cento integrata in&nbsp;ClickHouse per i backup. Esistono alcune impostazioni che possono essere utilizzate. Per ottenere una soluzione completa, sar\u00e0 necessario lavorare manualmente un po' o creare avvolgimenti 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 del volume dei dati e delle dimensioni del cluster. Pi\u00f9 grande \u00e8 il cluster, pi\u00f9 complessa diventa la soluzione.<\/p>\n<p><\/p>\n<p>Se la tabella dei dati occupa solo pochi gigabyte, \u00e8 possibile eseguire il backup in questo modo: <\/p>\n<p><\/p>\n<ol>\n<li>Salvare la definizione delle tabelle, ovvero i metadati \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Eseguire 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 qualcosa di 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 spazio. Questo \u00e8 chiamato backup logico, non \u00e8 legato al formato dei dati di ClickHouse. Se \u00e8 presente, in caso estremo puoi prendere il backup e caricarlo in MySQL per il ripristino. <\/p>\n<p><\/p>\n<p>Per casi pi\u00f9 avanzati, ClickHouse integra la possibilit\u00e0 di creare snapshot delle partizioni nel file system locale. Questa funzionalit\u00e0 \u00e8 disponibile come query <strong>alter table freeze partition<\/strong>. Oppure semplicemente <strong>alter table freeze<\/strong> \u2014 questo \u00e8 uno snapshot dell'intera tabella. <\/p>\n<p><\/p>\n<p>Lo snapshot verr\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 dei casi non \u00e8 necessaria tale esigenza, ed \u00e8 sufficiente eseguire la query su ogni shard e 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 nello storage che utilizzi per i backup.<\/p>\n<p><\/p>\n<p>Ripristinare un tale backup \u00e8 piuttosto semplice. Prima di tutto, crei le tabelle secondo le definizioni delle tabelle disponibili. Poi copi gli snapshot delle partizioni salvate in Directory-Detached per le tabelle di dati e esegui la query <strong>attach partition<\/strong>. Questa soluzione \u00e8 del tutto appropriata per i volumi di dati pi\u00f9 seri. <\/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 notato dai colleghi di 'Yandex.Metrica'. Non la raccomanderei a tutti \u2014 leggi e decidi se \u00e8 adatta per te. <\/p>\n<p><\/p>\n<p>Prima di tutto, \u00e8 necessario creare alcuni server con grandi rack di archiviazione. Successivamente, su questi server si devono installare diversi server ClickHouse e configurarli in modo che funzionino come un'altra replica per gli stessi shard. Infine, utilizzare su questi server un file system o uno strumento che consenta di creare snapshot. Ci sono due opzioni. La prima opzione \u00e8 quella degli snapshot LVM, la seconda opzione \u00e8 ZFS su Linux. <\/p>\n<p><\/p>\n<p>Dopo di che, ogni giorno \u00e8 necessario creare uno snapshot, che occuper\u00e0 un certo spazio. Naturalmente, se i dati cambiano, nel tempo lo spazio occupato aumenter\u00e0. Questo snapshot pu\u00f2 essere ripristinato in qualsiasi momento, \u00e8 una soluzione singolare. Inoltre, \u00e8 necessario limitare queste repliche nella configurazione, affinch\u00e9 non 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>Sar\u00e0 possibile organizzare un ritardo controllato delle repliche nei volumi?<\/h2>\n<p><\/p>\n<blockquote><p>Quest'anno prevedete di implementare i rollup in ClickHouse. Sar\u00e0 possibile organizzare un ritardo controllato per le repliche? Vorremmo usarlo per proteggerci da scenari negativi con alterazioni e altre modifiche. <\/p>\n<p>\u00c8 possibile effettuare qualche rollback per gli alter? Ad esempio, in un rollup esistente, dire di applicare modifiche fino a un certo punto, e da quel momento smettere di applicare modifiche?<\/p>\n<p>Se nella nostra cluster arriva un comando che lo rompe, abbiamo una replica con un ritardo di un'ora, dove possiamo decidere di utilizzare proprio essa in questo momento, ma senza applicare le ultime dieci minuti di modifiche? <\/p><\/blockquote>\n<p>Iniziamo con il ritardo controllato delle repliche. C'\u00e8 stata una richiesta da parte degli utenti, e abbiamo creato un problema su GitHub con la richiesta: \u00abSe a qualcuno serve, metti un like, metti un cuoricino\u00bb. Nessuno ha messo un like, quindi il problema \u00e8 stato chiuso. Tuttavia, \u00e8 gi\u00e0 possibile ottenere questa funzionalit\u00e0 configurando ClickHouse. Anche se, solo a partire dalla versione 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse esegue continuamente la fusione dei dati in background - merge. Quando il merge \u00e8 completato, un certo insieme di pezzi di dati viene sostituito da un pezzo pi\u00f9 grande. I pezzi di dati precedenti rimangono comunque sul disco per un certo periodo di tempo.<\/p>\n<p><\/p>\n<p>In primo luogo, continuano a restare fino a quando ci sono query select che le utilizzano, per garantire un funzionamento non bloccante. Le query select possono tranquillamente leggere dai vecchi pezzi.<\/p>\n<p><\/p>\n<p>In secondo luogo, c'\u00e8 anche una soglia temporale: i vecchi pezzi di dati rimangono sul disco per otto minuti. Questi otto minuti possono essere configurati e trasformati anche in un giorno. Questo avr\u00e0 un costo in termini di spazio su disco: a seconda del flusso di dati, potrebbe accadere che negli ultimi giorni i dati non solo raddoppino, ma possano diventare cinque volte maggiori. Ma potrai, in caso di problemi seri, fermare il server ClickHouse e affrontare tutto.<\/p>\n<p><\/p>\n<p>Ora c'\u00e8 da chiedersi come questo protegga dagli alter. Qui bisogna guardare pi\u00f9 a fondo, perch\u00e9 nelle vecchie versioni di ClickHouse, l'alter funzionava in modo tale da cambiare direttamente i pezzi. C'\u00e8 un pezzo di dati con alcuni file, e noi facciamo, per esempio, <strong>alter drop column<\/strong>. Allora questa colonna viene fisicamente rimossa da tutti i pezzi.<\/p>\n<p><\/p>\n<p>Ma a partire dalla versione 20.3, il meccanismo degli alter \u00e8 stato completamente cambiato, e ora i pezzi di dati sono sempre immutabili. Non cambiano affatto: gli alter ora funzionano in modo simile ai merge. Invece di cambiare un pezzo in loco, creiamo uno nuovo. Nel nuovo pezzo, i file che non sono cambiati diventano hard link e, se abbiamo rimosso una colonna, semplicemente non sar\u00e0 presente nel nuovo pezzo. Il vecchio pezzo verr\u00e0 eliminato per impostazione predefinita dopo otto minuti e qui si possono regolare le impostazioni di cui sopra. <\/p>\n<p><\/p>\n<p>Lo stesso vale per gli alter di tipo mutazioni. Quando si fa <strong>alter delete<\/strong> o <strong>alter update<\/strong>, non modifica il blocco, ma ne crea uno nuovo. E 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 mezzi del file system. \u00c8 adatta Btrfs invece di ZFS su Linux LVM?<\/p><\/blockquote>\n<p>Se si fa <strong>attach partition<\/strong> partizioni con una struttura diversa, ClickHouse ti dir\u00e0 che non \u00e8 possibile. La soluzione \u00e8 la seguente. Prima di tutto, creare una tabella temporanea di tipo MergeTree con la vecchia struttura, attaccarvi i dati utilizzando attach, fare una query alter. Poi puoi o copiare o spostare questi dati e fare nuovamente attach, oppure usare la query <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Ora, la seconda domanda \u00e8: si pu\u00f2 utilizzare Btrfs? Per iniziare, se hai LVM, basta utilizzare gli snapshot di LVM, mentre il filesystem pu\u00f2 anche essere ext4, non ha importanza. Con Btrfs, tutto dipende dalla tua esperienza nel suo utilizzo. \u00c8 un filesystem maturo, ma ci sono comunque alcune perplessit\u00e0 riguardo a come si comporter\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 resharding dei dati?<\/h2>\n<p><\/p>\n<p>La questione del re-sharding \u00e8 complessa e poliedrica. Qui si pu\u00f2 rispondere con varie opzioni. Si pu\u00f2 dire da un lato che in ClickHouse non esiste una funzionalit\u00e0 integrata per il re-sharding. Ma temo che questa risposta non soddisfi nessuno. Dall'altra parte, si pu\u00f2 dire che in ClickHouse ci sono molti modi per eseguire il re-sharding dei dati. <\/p>\n<p><\/p>\n<p>Se lo spazio nel cluster sta finendo o non riesce a gestire il carico, aggiungi nuovi server. Ma questi server sono vuoti per impostazione predefinita, non contengono dati e non ci sono carichi in corso. Devi redistribuire i dati affinch\u00e9 siano uniformemente distribuiti nel nuovo cluster, ampliato nelle dimensioni.<\/p>\n<p><\/p>\n<p>Il primo modo per farlo \u00e8 copiare alcune partizioni sui nuovi server utilizzando una query. <strong>alter table fetch partition<\/strong>Ad esempio, se avevi partizioni mensili, prendi il primo mese del 2017 e copialo su un nuovo server, poi copia il terzo mese su un altro nuovo server. E cos\u00ec continui finch\u00e9 non diventa pi\u00f9 o meno uniforme.<\/p>\n<p><\/p>\n<p>Il trasferimento pu\u00f2 essere effettuato solo per quelle partizioni che non cambiano durante la scrittura. Per le partizioni recenti, sar\u00e0 necessario disabilitare la scrittura, poich\u00e9 il loro trasferimento non \u00e8 atomico. Altrimenti, otterrai duplicati o omissioni nei dati. Tuttavia, questo metodo \u00e8 pratico e funziona piuttosto efficacemente. Le partizioni compresse gi\u00e0 pronte vengono trasferite attraverso la rete, cio\u00e8 i dati non vengono decompressi n\u00e9 ricodificati.<\/p>\n<p><\/p>\n<p>Questo metodo ha uno svantaggio, che dipende dallo schema di sharding che avete implementato e dalla chiave di sharding utilizzata. Nel vostro esempio, per i casi con metriche, la chiave di sharding \u00e8 l'hash del percorso. Quando eseguite un select nella tabella distribuita, essa va immediatamente su tutti gli shard del cluster e recupera i dati da l\u00ec. <\/p>\n<p><\/p>\n<p>Questo significa che, in effetti, non ha importanza per voi quali dati si trovano su quale shard. L'importante \u00e8 che i dati di un determinato percorso si trovino su uno shard specifico, e in quale esattamente non \u00e8 fondamentale. In questo caso, il trasferimento delle partizioni pronte \u00e8 molto adatto, perch\u00e9 durante le richieste di select riceverete comunque dati completi, sia prima che dopo il reshading, poich\u00e9 lo schema non ha particolare rilevanza.<\/p>\n<p><\/p>\n<p>Tuttavia, ci possono essere casi pi\u00f9 complessi. Se, a livello di logica applicativa, vi basate su uno schema di sharding specifico, in modo che questo cliente sia localizzato su un certo shard e la richiesta possa essere inviata direttamente l\u00ec, anzich\u00e9 alla tabella distribuita. Oppure utilizzate una versione di ClickHouse abbastanza recente e avete abilitato l'impostazione <strong>optimize skip unused shards<\/strong>. In questo caso, durante la richiesta select, l'espressione nella sezione where verr\u00e0 analizzata e verr\u00e0 calcolato su quali shard \u00e8 necessario andare secondo lo schema di sharding. Questo funziona a condizione che i dati siano effettivamente distribuiti secondo tale schema di sharding. Se li avete trasferiti manualmente, la corrispondenza potrebbe cambiare.<\/p>\n<p><\/p>\n<p>Quindi, questo \u00e8 il primo metodo. E aspetto la tua risposta, se ti sembra adatto o dobbiamo andare avanti.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev, lead system administrator in Avito<\/strong>: Aleksej, il metodo a cui ti riferisci non si adatta bene quando \u00e8 necessario distribuire il carico anche sulla lettura. Possiamo prendere una partizione mensile e trasferire il mese precedente su un'altra nodo, ma quando arriver\u00e0 una richiesta per questi dati, caricheremo solo quella. E ci piacerebbe caricare l'intero cluster, poich\u00e9, altrimenti, per un certo periodo, tutto il carico di lettura sar\u00e0 gestito da due shard.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> La risposta qui \u00e8 strana \u2014 s\u00ec, \u00e8 male, ma potrebbe anche funzionare. Spiegher\u00f2 come. \u00c8 importante esaminare lo scenario di carico che si verifica con i vostri dati. Se si tratta di dati di monitoraggio, allora \u00e8 quasi certo che la stragrande maggioranza delle richieste riguardi 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 nuovi dati. E i nuovi dati saranno distribuiti su tutto il cluster. Pertanto, gi\u00e0 dopo cinque minuti, le query per gli ultimi cinque minuti caricheranno uniformemente il cluster, e dopo un giorno, le query per le ultime 24 ore caricheranno uniformemente il cluster. Tuttavia, le query per il mese precedente, purtroppo, 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 le richieste si riferiscono all'anno 2019, saranno per tutto il 2019 \u2014 su un intervallo di tempo ampio, non su una piccola gamma. E tali richieste potranno anche caricare uniformemente il cluster. Tuttavia, il tuo commento \u00e8 assolutamente corretto, \u00e8 una soluzione ad hoc che non distribuisce i dati in modo completamente uniforme.<\/p>\n<p><\/p>\n<p>Ho ancora alcuni punti da considerare per rispondere alla domanda. Uno di essi riguarda come inizialmente progettare uno schema di sharding in modo che ci sia meno dolore dal re-sharding. 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. Il primo \u00e8 l'accumulo di dati storici. Il secondo \u00e8 l'aumento del traffico. E il terzo \u00e8 l'incremento del numero di elementi monitorati. Emergeno nuovi microservizi e metriche che devono essere registrate. <\/p>\n<p><\/p>\n<p>\u00c8 possibile che la maggiore crescita sia proprio dovuta al terzo motivo: l'aumento nell'uso del monitoraggio. In questo caso, vale la pena esaminare il tipo di carico e quali sono le principali richieste di select. Le principali richieste di select, probabilmente, riguarderanno un certo sottoinsieme di metriche.<\/p>\n<p><\/p>\n<p>Ad esempio, l'uso della CPU su alcuni server da parte di un certo servizio. Risulta che esiste un certo sottoinsieme di chiavi, in base al quale recuperi questi dati. E la richiesta per questi dati, probabilmente, \u00e8 abbastanza semplice e viene eseguita in decine di millisecondi. Utilizzato per i servizi di monitoraggio, per i dashboard. Spero di averlo capito correttamente.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Il fatto \u00e8 che facciamo spesso riferimento ai dati storici, poich\u00e9 confrontiamo in tempo reale la situazione attuale con quella storica. \u00c8 fondamentale per noi avere un accesso rapido a un grande volume di dati, e ClickHouse gestisce egregiamente questo compito.<\/p>\n<p><\/p>\n<p>Hai assolutamente ragione, la maggior parte delle richieste di lettura che riceviamo si concentrano sull'ultima giornata, proprio come in qualsiasi sistema di monitoraggio. Tuttavia, anche per i dati storici il carico \u00e8 piuttosto elevato, principalmente a causa del sistema di allerta, che ogni trenta secondi interroga ClickHouse dicendo: \"Restituisci i dati delle ultime sei settimane. E ora costruisci una media mobile con questi dati, e confrontiamo il valore attuale con quello storico.\" <\/p>\n<p><\/p>\n<p>Vorrei dire che per queste richieste molto recenti abbiamo un piccolo tavolo dove conserviamo solo due giorni di dati, e le richieste principali vanno a questo tavolo. Nella grande tabella shardizzata inviamo solo le grandi richieste storiche.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Sfortunatamente, per il tuo scenario non \u00e8 molto applicabile, ma ti racconter\u00f2 di due schemi di shardizzazione complessi e inefficaci che non dovrebbero essere utilizzati ma che sono impiegati nei servizi dei miei amici. <\/p>\n<p><\/p>\n<p>C'\u00e8 un cluster principale con gli eventi di \"Yandex.Metrica\". Gli eventi sono visualizzazioni di pagina, clic e transizioni. La maggior parte delle richieste va a un sito web specifico. Apri il servizio \"Yandex.Metrica\", hai un sito \u2014 avito.ru, accedi al report e arrivano le richieste per il tuo sito.<\/p>\n<p><\/p>\n<p>Ma ci sono anche altre richieste \u2014 quelle analitiche e globali, effettuate dagli analisti interni. Preciso che gli analisti interni fanno richieste solo sui servizi di \"Yandex\". Tuttavia, anche i servizi di \"Yandex\" rappresentano una parte significativa di tutti i dati. Queste sono richieste non per singoli contatori, ma per una filtrazione pi\u00f9 ampia.<\/p>\n<p><\/p>\n<p>Come organizzare i dati in modo che funzioni efficacemente sia per un singolo contatore che per le richieste globali? La complessit\u00e0 risiede anche nel fatto che il numero di richieste in ClickHouse per il cluster \"Metriche\" \u00e8 di diverse migliaia al secondo. Peraltro, non \u00e8 in grado di gestire richieste non banali, ad esempio, diverse migliaia al secondo che un singolo server ClickHouse non riesce a sostenere.<\/p>\n<p><\/p>\n<p>La dimensione del cluster \u00e8 di seicento e qualcosa server. Se tiriamo semplicemente una tabella Distribuita su questo cluster e inviamo l\u00ec diverse migliaia di richieste, la situazione peggiorer\u00e0 rispetto all'invio di queste a un singolo server. D'altra parte, scartiamo immediatamente l'opzione in cui i dati sono distribuiti uniformemente e noi andiamo a raccogliere informazioni da tutti i server.<\/p>\n<p><\/p>\n<p>C'\u00e8 un'opzione diametralmente opposta. Immagina se sharding dei dati fosse fatto per sito web, in modo che la richiesta per un singolo sito vada a un singolo shard. Ora il cluster potrebbe gestire tranquillamente diecimila richieste al secondo, ma su uno shard, una singola richiesta potrebbe essere troppo lenta. Non scalerebbe pi\u00f9 in base alla capacit\u00e0. Soprattutto se si tratta del sito avito.ru. Non svelo un segreto dicendo che Avito \u00e8 uno dei siti pi\u00f9 visitati nel Runet. E trattarlo su un singolo shard sarebbe un'assurdit\u00e0.<\/p>\n<p><\/p>\n<p>Perci\u00f2, il schema di sharding \u00e8 strutturato in modo pi\u00f9 intelligente. L'intero cluster \u00e8 suddiviso in un certo numero di cluster che chiamiamo livelli. All'interno di ciascun cluster ci sono da una decina a diverse decine di shard. In totale ci sono trenta nove di questi cluster. <\/p>\n<p><\/p>\n<p>Come si scalano tutte queste cose? Il numero di cluster rimane invariato: come erano trentadue anni fa, cos\u00ec sono rimasti. Ma all'interno di ciascuno di essi stiamo gradualmente aumentando il numero di shard man mano che raccogliamo dati. E lo schema di sharding in generale \u00e8 tale che la suddivisione in questi cluster avviene per siti web, e per capire quale sito \u00e8 su quale cluster utilizziamo un database separato in MySQL. Un sito - su un cluster. E all'interno di esso, lo sharding avviene in base agli identificatori dei visitatori.<\/p>\n<p><\/p>\n<p>Durante la registrazione, suddividiamo gli utenti 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 con un resto della divisione per un altro numero. Questo significa che un visitatore potrebbe effettivamente trovarsi su pi\u00f9 server, e non possiamo fare affidamento su questo. \u00c8 fatto esclusivamente per garantire una migliore compressione dei dati. Quando riceviamo richieste, accediamo alla tabella Distributed, che guarda al cluster e contatta decine di server. \u00c8 uno schema piuttosto complicato.<\/p>\n<p><\/p>\n<p>Tuttavia, la mia storia sarebbe incompleta se non dicessi che abbiamo abbandonato questo schema. Nella nuova configurazione abbiamo cambiato tutto e abbiamo copiato tutti i dati utilizzando clickhouse-copier.<\/p>\n<p><\/p>\n<p>Nella nuova configurazione, tutti i siti sono divisi in due categorie: grandi e piccoli. Non so come sia stato definito il limite, ma in seguito si \u00e8 rivelato che i grandi siti vengono registrati su un unico cluster, con 120 shard e tre repliche per ciascuno, il che significa 360 server. E lo schema di sharding \u00e8 tale che ogni richiesta va a tutti gli shard contemporaneamente. Se ora apri qualsiasi pagina di report in 'Yandex.Metrica' per avito.ru, la richiesta verr\u00e0 inviata a 120 server. Ci sono pochi grandi siti nel Runet. E quindi le richieste non raggiungono le mille al secondo, ma meno di cento. Tutto questo viene tranquillamente elaborato dalla tabella Distributed, che ciascuno di essi gestisce con 120 server.<\/p>\n<p><\/p>\n<p>Il secondo cluster \u00e8 per i piccoli siti. Qui lo schema di sharding \u00e8 basato sull'identificatore del sito, e ogni richiesta va esattamente a un singolo 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 un'utility chiamata 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 completamente i dati secondo lo schema che indicherai. Ma lo svantaggio dell'utilit\u00e0 \u00e8 che non effettua re-sharding. Copia i dati da uno schema di cluster a un altro schema di cluster.<\/p>\n<p><\/p>\n<p>Questo significa che per il suo funzionamento hai bisogno di due cluster. Possono trovarsi sugli stessi server, tuttavia, i dati non verranno spostati in modo incrementale, ma saranno copiati. <\/p>\n<p><\/p>\n<p>Ad esempio, c'erano quattro server, ora sono otto. Crei una nuova tabella Distributed su tutti i server, nuove tabelle locali e avvii clickhouse-copier, specificando nel programma come deve lavorare, che deve leggere da l\u00ec, adottare il nuovo schema di sharding e spostare i dati di conseguenza. Avrai bisogno di uno spazio sui server vecchi che \u00e8 un'altra volta e mezzo rispetto a quello che hai ora, perch\u00e9 i vecchi dati devono rimanere l\u00ec e sopra di essi arriver\u00e0 una met\u00e0 di questi stessi dati. Se hai pensato in anticipo che i dati devono essere resharded e c'\u00e8 spazio, questa modalit\u00e0 funzioner\u00e0.<\/p>\n<p><\/p>\n<p>Com'\u00e8 strutturato internamente clickhouse-copier? Divide l'intero lavoro in un insieme di compiti per elaborare 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, riorganizzati, poi compressi di nuovo, scritti da qualche parte e riordinati. \u00c8 una soluzione pi\u00f9 complessa.<\/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. Che fine ha fatto?<\/h2>\n<p><\/p>\n<blockquote><p>Hai avuto un prototipo nel 2017 chiamato resharding. C'\u00e8 anche un'opzione in ClickHouse. Da quello che capisco, non ha avuto successo. Puoi spiegare perch\u00e9 \u00e8 andata cos\u00ec? Sembrava piuttosto rilevante.<\/p><\/blockquote>\n<p>Il problema \u00e8 che, quando \u00e8 necessario reshardeare i dati, \u00e8 richiesta una sincronizzazione complessa affinch\u00e9 ci\u00f2 avvenga in modo atomico. Quando abbiamo iniziato a esaminare come \u00e8 strutturata questa sincronizzazione, \u00e8 diventato chiaro che ci sono problemi fondamentali. E questi problemi fondamentali non sono solo teorici, ma iniziano subito a manifestarsi nella pratica con un'idea semplice: nulla funziona.<\/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 prima di spostarle su dischi pi\u00f9 lenti?<\/h2>\n<p><\/p>\n<blockquote><p>Domanda su TTL con l'opzione di spostamento su disco lento nel contesto delle fusioni. \u00c8 possibile, oltre che tramite cron, unire tutte le parti in una sola prima di spostarle sui dischi lenti?<\/p><\/blockquote>\n<p>La risposta alla domanda se \u00e8 possibile unire automaticamente tutti i pezzi in uno prima del loro trasferimento \u00e8 no. Non vedo la necessit\u00e0. Puoi anche non unire tutte le parti in una e semplicemente contare sul fatto che verranno trasferite automaticamente sui dischi lenti. <\/p>\n<p><\/p>\n<p>Abbiamo due criteri di regole per il trasferimento. Il primo \u00e8 in base al livello di riempimento. Se nel livello attuale di archiviazione c'\u00e8 meno di una certa percentuale di spazio libero, selezioniamo un blocco e lo trasferiamo su uno storage pi\u00f9 lento. Pi\u00f9 precisamente, non pi\u00f9 lento, ma il successivo\u2014come lo configurate.<\/p>\n<p><\/p>\n<p>Il secondo criterio \u00e8 basato sulla dimensione. Questo riguarda il trasferimento di grandi blocchi. \u00c8 possibile regolare la soglia per lo 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 si pu\u00f2 migrare alle nuove versioni di ClickHouse se non \u00e8 possibile verificare in anticipo la compatibilit\u00e0?<\/h2>\n<p><\/p>\n<blockquote><p>Questo tema viene discusso regolarmente <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">nel gruppo Telegram di ClickHouse<\/a><\/noindex> tenendo conto delle diverse versioni, eppure. Quanto \u00e8 sicuro aggiornarsi dalla versione 19.11 alla 19.16 e, ad esempio, dalla 19.16 alla 20.3? Qual \u00e8 il modo migliore per migrare a nuove versioni senza avere la possibilit\u00e0 di verificare in anticipo la compatibilit\u00e0 in un ambiente di test?<\/p><\/blockquote>\n<p>Ci sono alcune \"regole d'oro\". La prima \u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">leggere il changelog<\/a><\/noindex>. \u00c8 ampia, ma ci sono punti separati riguardo le modifiche non compatibili. Non bisogna considerare questi punti come un segnale di allerta. Di solito si tratta di piccole incompatibilit\u00e0 legate a qualche funzionalit\u00e0 marginale che, molto probabilmente, non utilizzate.<\/p>\n<p><\/p>\n<p>La seconda \u00e8: se non c'\u00e8 possibilit\u00e0 di verificare la compatibilit\u00e0 in un ambiente di test e desiderate aggiornare direttamente in produzione, la raccomandazione \u00e8 di non farlo. Prima create un ambiente di test e verificate. Se non avete un ambiente di test, allora probabilmente non siete una grande azienda, quindi potete copiare parte dei dati sul vostro laptop e assicurarvi che tutto funzioni correttamente. Potete persino alzare alcune repliche localmente sulla vostra macchina. Oppure potete avviare una nuova versione qualche luogo vicino e caricare l\u00ec parte dei dati\u2014vale a dire creare un ambiente di test improvvisato. <\/p>\n<p><\/p>\n<p>Un'altra regola \u00e8 di non aggiornarsi durante la settimana successiva all'uscita della versione a causa della cattura dei bug in produzione e dei successivi correttivi rapidi. Esaminiamo la numerazione delle versioni di ClickHouse per non confonderci. <\/p>\n<p><\/p>\n<p>C'\u00e8 una versione 20.3.4. Il numero 20&nbsp;indica l'anno di rilascio&nbsp;\u2014 2020. Da un punto di vista interno, questo non ha importanza, quindi non ci soffermeremo su questo. Proseguendo&nbsp;\u2014 20.3. Il secondo numero&nbsp;\u2014 in questo caso 3 \u2014 lo aumentiamo ogni volta che rilasciamo una nuova versione con qualche nuova funzionalit\u00e0. Se vogliamo aggiungere una nuova funzionalit\u00e0 in ClickHouse, dobbiamo aumentare questo numero. Quindi nella versione 20.4 ClickHouse funzioner\u00e0 ancora meglio. Il terzo numero&nbsp;\u2014 20.3.4. Qui&nbsp;4 rappresenta il numero di patch release, in cui non abbiamo aggiunto nuove funzionalit\u00e0, ma abbiamo risolto alcuni bug. E 4&nbsp;significa che lo abbiamo fatto quattro volte.<\/p>\n<p><\/p>\n<p>Non bisogna pensare che sia qualcosa di orribile. Di solito, un utente pu\u00f2 installare la versione pi\u00f9 recente, e funzioner\u00e0 senza&nbsp;alcun problema per un anno. Ma immaginate che in una funzione per la gestione dei bitmap, che \u00e8 stata aggiunta dai nostri amici cinesi, se vengono passati argomenti errati, il server si blocca. Dobbiamo correggerlo. Rilasceremo una nuova versione patch, e ClickHouse diventer\u00e0 pi\u00f9 stabile.<\/p>\n<p><\/p>\n<p>Se avete ClickHouse in produzione e viene rilasciata una nuova versione di ClickHouse con funzionalit\u00e0 aggiuntive \u2014 per esempio, 20.4.1 \u2014 non abbiate fretta di installarla in produzione nel primo giorno. A cosa serve davvero? Se non state ancora utilizzando ClickHouse, potete installarlo e, molto probabilmente, funzioner\u00e0 bene. Ma se ClickHouse \u00e8 gi\u00e0 stabile, seguite i patch e gli aggiornamenti&nbsp;\u2014 quali problemi stiamo risolvendo.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Vorrei aggiungere qualche informazione sulle&nbsp;ambienti di test. Tutti hanno molto paura degli ambienti di test e per qualche motivo pensano che, se avete un grande cluster ClickHouse, anche l'ambiente di test debba essere almeno della stessa dimensione o almeno dieci volte pi\u00f9 piccolo. Non \u00e8 affatto cos\u00ec.<\/p>\n<p><\/p>\n<p>Posso parlare per esperienza personale. Ho un progetto che utilizza ClickHouse. Il nostro ambiente di test per questo&nbsp;\u2014 \u00e8 una piccola macchina virtuale in Hetzner da venti euro, dove \u00e8 stato configurato tutto. Per fare ci\u00f2, abbiamo una completa automazione in Ansible, e quindi non c'\u00e8 differenza sostanziale, che sia sui server fisici o che si avvii semplicemente in macchine virtuali.<\/p>\n<p><\/p>\n<p>Cosa si pu\u00f2 fare? Sarebbe utile includere nella documentazione di ClickHouse un esempio su come distribuire un piccolo cluster in&nbsp;Docker, in&nbsp;LXC, o forse creare un playbook Ansible, perch\u00e9 le persone hanno distribuzioni diverse. Questo semplificherebbe molto. Quando riesci a distribuire un cluster in cinque minuti, \u00e8 molto pi\u00f9 facile cercare di capire come funziona. \u00c8 molto pi\u00f9 comodo, perch\u00e9 andare in produzione con una versione che non hai verificato&nbsp;\u00e8 un passo nella direzione sbagliata. A volte funziona, altre volte no. E quindi sperare in un successo&nbsp;\u00e8 sbagliato.<\/p>\n<p><\/p>\n<p><strong>Maksim Kotiakov, ingegnere backend senior di Avito:<\/strong> Aggiungo qualcosa sulle&nbsp;ambienti di test nella serie dei problemi delle grandi aziende. Abbiamo un cluster ClickHouse di accettazione completo, che \u00e8 una copia esatta delle schemi dati e delle configurazioni di quello in produzione. Questo cluster \u00e8 distribuito in contenitori abbastanza austeri con risorse minime. Scriviamo un certo percentuale di dati di produzione l\u00ec, fortunatamente abbiamo la possibilit\u00e0 di replicare il flusso in Kafka. Tutto \u00e8 sincronizzato e scalato&nbsp;\u2014 sia per capacit\u00e0 che per flusso, e, in teoria, a parit\u00e0 di condizioni dovrebbe comportarsi come in produzione. Tutto ci\u00f2 che \u00e8 potenzialmente esplosivo viene prima distribuito su questa piattaforma e riposa l\u00ec per alcuni giorni fino a quando non \u00e8 pronto. Ma chiaramente, questa soluzione \u00e8 costosa, pesante e comporta costi non nulli per il supporto. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Vi racconter\u00f2 cosa rappresenta l'ambiente di test dei nostri amici di&nbsp;\u00abYandex.Metrica\u00bb. Un cluster aveva pi\u00f9 di 600 server, un altro 360, e c'\u00e8 anche un terzo e vari altri cluster. L'ambiente di test per uno di essi&nbsp;\u00e8 semplicemente costituito da due shard con due repliche ciascuno. Perch\u00e9 due shard? Cos\u00ec non ce n'\u00e8 solo uno. E anche le repliche devono esserci. Solo un numero minimo che ci si pu\u00f2 permettere.<\/p>\n<p><\/p>\n<p>Questo ambiente di test consente di verificare il funzionamento delle query e se qualcosa non si \u00e8 rotto in modo considerevole. Tuttavia, spesso i problemi sorgono di natura completamente diversa, quando tutto funziona, ma ci sono dei piccoli cambiamenti nel carico.<\/p>\n<p><\/p>\n<p>Ecco un esempio. Abbiamo deciso di installare una nuova versione di ClickHouse. \u00c8 stata rilasciata nell'ambiente di test, sono stati eseguiti test automatizzati nella stessa \u00abYandex.Metrica\u00bb, che confrontano i dati tra la vecchia e la nuova versione, eseguendo l'intero processo. E naturalmente, i test verdi del nostro CI. Altrimenti non avremmo nemmeno proposto questa versione.<\/p>\n<p><\/p>\n<p>Tutto perfetto. Iniziamo a distribuire in produzione. Ricevo un messaggio che i grafici mostrano un aumento del carico di diversi fattori. Torniamo indietro con la versione. Guardando il grafico, vedo: il carico \u00e8 effettivamente aumentato di diversi fattori durante il rilascio, e si \u00e8 di nuovo ridotto una volta completata la distribuzione. Poi abbiamo iniziato a tornare indietro con la versione. E il carico \u00e8 aumentato allo stesso modo e poi \u00e8 sceso di nuovo. Quindi la conclusione \u00e8 che il carico \u00e8 aumentato in relazione al rilascio, non c'\u00e8 niente di sorprendente.<\/p>\n<p><\/p>\n<p>\u00c8 stato difficile convincere i colleghi a installare comunque la nuova versione. Dico: \u00abVa tutto bene, procedete. Incrociate le dita, tutto funzioner\u00e0. Attualmente il carico \u00e8 aumentato sui grafici, ma va tutto bene. Rimanete concentrati\u00bb. Insomma, abbiamo fatto cos\u00ec, e tutti \u2014 la versione \u00e8 stata distribuita in produzione. Ma quasi ad ogni rilascio 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>Il comando Kill query dovrebbe terminare le query, ma non lo fa. Perch\u00e9?<\/h2>\n<p><\/p>\n<blockquote><p>Un utente, un analista, \u00e8 venuto da me e ha creato una richiesta che ha bloccato il mio cluster ClickHouse. Un nodo o l'intero cluster, a seconda di quale replica o shard la richiesta \u00e8 arrivata. Vedo che tutte le risorse della CPU su quel server sono a terra, tutto rosso. Nel frattempo, ClickHouse risponde alle richieste. Cos\u00ec scrivo: \u00abFammi vedere, per favore, la lista dei processi, quale richiesta ha causato questo caos\u00bb.<\/p>\n<p>Trovo quella richiesta e gli mando un kill. E vedo che non succede nulla. Il mio server \u00e8 a terra, ClickHouse continua a darmi comandi e mostrare che il server \u00e8 vivo e tutto va bene. Ma ho una degradazione in tutte le richieste degli utenti, inizia a esserci una degradazione nella scrittura in ClickHouse e il mio kill query non funziona. Perch\u00e9? Pensavo che il kill query dovesse fermare le richieste, ma non accade.<\/p><\/blockquote>\n<p>Ora ci sar\u00e0 una risposta piuttosto strana. La questione \u00e8 che il kill query non ferma le richieste. <\/p>\n<p><\/p>\n<p>La query Kill imposta una piccola flag chiamata \u00abvoglio che questa query venga annullata\u00bb. Durante l'elaborazione di ciascun blocco, la query controlla questo flag. Se \u00e8 impostato, la query smette di funzionare. Quindi, nessuno annulla realmente la query; \u00e8 la query stessa che deve controllare e fermarsi. Questo dovrebbe funzionare in tutti i casi in cui la query \u00e8 in fase di elaborazione dei blocchi di dati. Elaborer\u00e0 il prossimo blocco di dati, verificher\u00e0 il flag e si fermer\u00e0.<\/p>\n<p><\/p>\n<p>Ci\u00f2 non funziona nei casi in cui la query \u00e8 bloccata in qualche operazione. Tuttavia, probabilmente non \u00e8 il tuo caso, perch\u00e9, secondo quanto dici, sta utilizzando molte risorse del server. Potrebbe non funzionare in caso di ordinamento esterno e in alcuni altri dettagli. Ma in generale, non dovrebbe essere cos\u00ec, \u00e8 un bug. L'unica cosa che posso consigliarti \u00e8 di 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 sotto carico in lettura?<\/h2>\n<p><\/p>\n<blockquote><p>C'\u00e8 una tabella in cui sono memorizzati gli aggregati per item \u2014 diversi contatori. Il numero di righe \u00e8 di circa cento milioni. \u00c8 possibile contare su un tempo di risposta prevedibile se si immettono 1K RPS per 1K item? <\/p><\/blockquote>\n<p>A giudicare dal contesto, si tratta di un carico di lettura, perch\u00e9 non ci sono problemi con la scrittura \u2014 si possono inserire mille, centomila o anche diverse milioni di righe. <\/p>\n<p><\/p>\n<p>Le query di lettura possono variare notevolmente. In select 1, ClickHouse pu\u00f2 eseguire decine di migliaia di query al secondo, quindi anche le query su una singola chiave richiederanno alcune risorse. E tali query puntuali saranno pi\u00f9 complesse rispetto a quelle di alcuni database key-value, perch\u00e9 per ciascuna lettura \u00e8 necessario leggere un blocco di dati per indice. L'indice non si riferisce a ciascun record, ma a ciascun intervallo. Quindi, sar\u00e0 necessario leggere l'intero intervallo \u2014 di default, 8192 righe. E dovr\u00e0 anche decomprimere un blocco di dati compresso da 64 Kb a 1 Mb. Di solito, tali query puntuali richiedono pochi millisecondi. Ma questa \u00e8 l'opzione pi\u00f9 semplice.<\/p>\n<p><\/p>\n<p>Proviamo a fare un semplice calcolo aritmetico. Se moltiplichiamo alcuni millisecondi per mille, otteniamo alcuni secondi. \u00c8 come se non si potessero gestire mille richieste al secondo, ma in realt\u00e0 \u00e8 possibile, perch\u00e9 abbiamo diversi core della CPU. Quindi, in linea di principio, ClickHouse pu\u00f2 gestire occasionalmente 1000 RPS, ma solo per richieste brevi e specifiche.<\/p>\n<p><\/p>\n<p>Se hai bisogno di scalare un cluster ClickHouse in base al numero di richieste semplici, ti consiglio la cosa pi\u00f9 semplice: aumentare il numero di repliche e inviare le richieste a una replica casuale. Se una replica pu\u00f2 gestire cinquecento richieste al secondo, il che \u00e8 del tutto realizzabile, tre repliche possono gestire millecinquecento.<\/p>\n<p><\/p>\n<p>A volte, certo, \u00e8 possibile configurare ClickHouse per massimizzare il numero di letture puntuali. Cosa serve per farlo? Prima di tutto, bisogna ridurre la granularit\u00e0 dell'indice. E quando la si riduce, non bisogna portarla a uno, ma calcolarla in modo che il numero di record nell'indice sia di diversi milioni o decine di milioni per server. Se la tabella ha 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 impostazioni per questo. <strong>min compress block size<\/strong>, <strong>max compress block size<\/strong>Si possono ridurre, riaggiornare i dati e cos\u00ec le richieste puntuali saranno pi\u00f9 veloci. Ma comunque ClickHouse non \u00e8 un database key-value. Un gran numero di piccole richieste \u00e8 un antipattern di carico.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Ti do un consiglio nel caso ci siano contatori normali. \u00c8 una situazione abbastanza standard quando in ClickHouse si tiene traccia di un contatore. Ho un utente, viene da un certo paese, c'\u00e8 anche un terzo campo e bisogna incrementare qualcosa. Prendi MySQL, crea una chiave unica: in MySQL \u00e8 una chiave duplicata, in PostgreSQL \u00e8 un conflitto, e aggiungi con un pi\u00f9. Questo funzioner\u00e0 molto meglio. <\/p>\n<p><\/p>\n<p>Quando hai pochi dati, non ha molto senso usare ClickHouse. Ci sono database normali e funzionano bene per questo. <\/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 si pu\u00f2 ottimizzare in ClickHouse per avere pi\u00f9 dati nella cache?<\/h2>\n<p><\/p>\n<blockquote><p>Immaginiamo una situazione: 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>In genere, la cache delle pagine del sistema operativo gestisce bene questo compito. Se aprite semplicemente il top, guardate l\u00e0 cached o free \u2014 \u00e8 scritto anche quanto \u00e8 stato memorizzato in cache \u2014 e si pu\u00f2 notare che tutta la memoria libera \u00e8 utilizzata per la cache. Questi dati, durante la lettura, non verranno letti dal disco, ma dalla RAM. Posso dire che la cache \u00e8 utilizzata in modo efficace, poich\u00e9 vengono memorizzati in cache solo i dati compressi.<\/p>\n<p><\/p>\n<p>Tuttavia, se desiderate accelerare ulteriormente alcune semplici query, c'\u00e8 la possibilit\u00e0 di attivare all'interno di ClickHouse la cache per i dati non compressi. Questo \u00e8 chiamato <strong>uncompressed cache<\/strong>. Nel file di configurazione config.xml impostate la dimensione della cache non compressa al valore desiderato \u2014 consiglio di non superare met\u00e0 della memoria RAM libera, poich\u00e9 il resto sar\u00e0 utilizzato per la cache delle pagine. <\/p>\n<p><\/p>\n<p>Inoltre, ci sono due impostazioni a livello di richiesta. La prima impostazione \u00e8 <strong>usa cache non compressa<\/strong> \u2014 abilita il suo utilizzo. Si consiglia di attivarla per tutte le query, tranne quelle pesanti che possono leggere tutti i dati e svuotare questa cache. La seconda impostazione riguarda qualcosa come il numero massimo di righe per l'utilizzo della cache. Limita automaticamente le grandi query affinch\u00e9 passino oltre la 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 l'archiviazione 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 storage dei dati<\/a><\/noindex>. Nella descrizione \u00e8 presente un esempio con SSD veloci. <\/p>\n<p>\u00c8 interessante come si possa configurare lo stesso con la memoria calda del volume. E un'altra domanda. Come funziona il select con tale organizzazione dei dati? Legger\u00e0 l'intero insieme o solo quello che si trova sul disco, e questi dati vengono compressi in memoria? E come funziona la sezione prewhere con tale organizzazione dei dati?<\/p><\/blockquote>\n<p>Questa impostazione influisce sulla memorizzazione dei blocchi di dati, e il loro formato non cambia affatto.<br \/>\nEsaminiamo pi\u00f9 in dettaglio. <\/p>\n<p><\/p>\n<p>\u00c8 possibile configurare la memorizzazione dei dati nella RAM. Tutto ci\u00f2 che \u00e8 configurabile per il disco \u00e8 il suo percorso. Si crea una partizione tmpfs, che \u00e8 montata in un certo percorso nel file system. Si indica questo percorso come il percorso per la memorizzazione dei dati per la partizione pi\u00f9 calda, dove iniziano ad arrivare e registrarsi i blocchi di dati, tutto funziona bene. <\/p>\n<p><\/p>\n<p>Tuttavia, non lo consiglio a causa della bassa affidabilit\u00e0, anche se, se hai almeno tre repliche in diversi data center, si pu\u00f2 fare. Se succede qualcosa, i dati saranno ripristinati. Immagina che il server venga spento e poi riacceso. La partizione \u00e8 stata rimontata, ma \u00e8 vuota. Il server ClickHouse, all'avvio, nota che questi pezzi mancano, anche se, secondo i metadati di ZooKeeper, dovrebbero essere presenti. Controlla su quali repliche ci sono, le richiede e le scarica. In questo modo i dati verranno ripristinati. <\/p>\n<p><\/p>\n<p>In questo senso, la memorizzazione dei dati in RAM non differisce totalmente dalla loro memorizzazione su disco, perch\u00e9 durante la scrittura dei dati su disco, anch'essi passano prima nel page cache e vengono registrati fisicamente in modo differito. Questo dipende dall'opzione di montaggio del file system. Ma per sicurezza, dir\u00f2 che ClickHouse non esegue fsync durante l'insert.<\/p>\n<p><\/p>\n<p>Inoltre, i dati in RAM sono memorizzati nello stesso formato che su disco. La query select seleziona esattamente i pezzi da leggere, e nei pezzi seleziona gli intervalli di dati necessari e li legge. E il prewhere funziona esattamente allo stesso modo, indipendentemente dal fatto che i dati siano in RAM o su 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 unici \u00e8 efficace Low Cardinality?<\/h2>\n<p><\/p>\n<p>Low Cardinality \u00e8 ingegnoso. Crea dizionari dei dati, ma questi sono locali. Innanzitutto, ci sono dizionari specifici per ogni pezzo, inoltre, anche all'interno di un singolo pezzo, possono differire per ogni intervallo. Quando il numero di valori unici raggiunge una soglia - credo sia un milione - il dizionario viene semplicemente accantonato e ne viene creato uno nuovo.<\/p>\n<p><\/p>\n<p>La risposta in generale \u00e8: per ogni intervallo locale - diciamo, per ogni giorno - fino a circa un milione di valori unici, Low Cardinality \u00e8 efficace. Dopo ci sar\u00e0 semplicemente un fallback, dove verranno utilizzati molti dizionari diversi, e non uno solo. Funzioner\u00e0 pi\u00f9 o meno come una colonna normale di tipo string, forse con un'efficienza leggermente inferiore, ma non ci sar\u00e0 una significativa degradazione 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 testuale full-text in una tabella con cinque miliardi di righe?<\/h2>\n<p><\/p>\n<p>Ci sono diverse opzioni di risposta. La prima \u00e8 dire che ClickHouse non \u00e8 un sistema per la ricerca full-text. Per questo ci sono sistemi speciali come ad esempio, <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 Elasticsearch a ClickHouse.<\/p>\n<p><\/p>\n<p>Perch\u00e9 succede questo? Lo spiegano dicendo che Elasticsearch smette di gestire il carico su alcuni volumi, a partire da quelli relativi alla costruzione degli indici. Gli indici diventano troppo ingombranti e, se si trasferiscono i dati in ClickHouse, si risulta con un'efficienza di archiviazione molte volte migliore. Inoltre, le query di ricerca spesso non erano quelle in cui si cercava una frase specifica in tutto il volume dei dati tenendo conto della morfologia, ma piuttosto altre. Ad esempio, trovare negli ultimi ore nei log qualche sotto-sequenza di byte.<\/p>\n<p><\/p>\n<p>In questo caso, in ClickHouse si crea un indice, il primo campo del quale sar\u00e0 la data con l'ora. E il maggiore filtro dei dati sar\u00e0 proprio in base all'intervallo di date. All'interno dell'intervallo di date selezionato, di solito si pu\u00f2 gi\u00e0 eseguire una ricerca full-text anche tramite il metodo brute force con like. L'operatore like in ClickHouse \u00e8 l'operatore like pi\u00f9 efficace che si possa trovare. Se ne trovi uno migliore, 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 in termini di CPU, ma anche di disco. Se, ad esempio, hai un terabyte di dati al giorno e cerchi una parola in 24 ore, dovrai scansionare un terabyte. Probabilmente \u00e8 su normali hard disk, e alla fine saranno caricati in modo tale che non si potr\u00e0 accedere a quel server via SSH.<\/p>\n<p><\/p>\n<p>In questo caso, sono pronto a proporre un altro piccolo trucco. \u00c8 del tipo sperimentale: potrebbe funzionare o meno. In ClickHouse ci sono indici full-text sotto forma di filtri di Bloom trigrammatici. I nostri colleghi dell'azienda Arenadata hanno gi\u00e0 testato questi indici e spesso funzionano esattamente come previsto.<\/p>\n<p><\/p>\n<p>Per utilizzarli correttamente, \u00e8 necessario comprendere bene come funzionano: cosa rappresenta un filtro di Bloom trigrammatico e come scegliere la sua dimensione. Posso dire che saranno utili per query su frasi rare, sotto-stringhe che si incontrano di rado nei dati. In questo caso, verranno selezionati sotto-insiemi dagli indici e verranno letti meno dati.<\/p>\n<p><\/p>\n<p>Recentemente, ClickHouse ha introdotto funzionalit\u00e0 ancora pi\u00f9 avanzate per la ricerca full-text. Queste includono, innanzitutto, la ricerca di molte sottostringhe in un'unica passata, comprese opzioni che considerano la lettera maiuscola, senza considerazione della lettera maiuscola, supporto per UTF-8 o solo per ASCII. Scegli il metodo pi\u00f9 efficace che ti serve. <\/p>\n<p><\/p>\n<p>\u00c8 ora possibile anche la ricerca di pi\u00f9 espressioni regolari in un'unica passata. Non \u00e8 necessario scrivere X like una sottostringa o X like un'altra sottostringa. Scrivi semplicemente, e tutto viene eseguito in modo altamente efficiente.<\/p>\n<p><\/p>\n<p>Inoltre, c'\u00e8 ora la ricerca approssimativa di espressioni regolari e la ricerca approssimativa di sottostringhe. Se qualcuno ha scritto una parola con un errore di battitura, verr\u00e0 cercata per la 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>Qual \u00e8 il modo migliore per gestire l'accesso a ClickHouse per un grande numero di utenti?<\/h2>\n<p><\/p>\n<blockquote><p>Parlaci di come organizzare meglio l'accesso per un gran numero di consumatori e analisti. Come formare una coda, prioritizzare le query max concurrent queries, e quali strumenti utilizzare?<\/p><\/blockquote>\n<p>Se il cluster \u00e8 sufficientemente grande, una buona soluzione sarebbe avviare altri due server, che diventino il punto d'ingresso per gli analisti. In altre parole, non permettere agli analisti di accedere a shard specifici del cluster, ma semplicemente creare due server vuoti, senza dati, e su di essi configurare i diritti di accesso. In questo modo, le impostazioni degli utenti per le query distribuite vengono trasferite ai server remoti. Ossia, configuri tutto su questi due server, e le impostazioni avranno effetto su tutto il cluster.<\/p>\n<p><\/p>\n<p>In linea di principio, questi server sono senza 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 l'aggregazione esterna o l'ordinamento esterno sono attivati.<\/p>\n<p><\/p>\n<p>\u00c8 importante esaminare le impostazioni relative a tutti i possibili limiti. Se ora accedo al cluster \"Yandex.Metrica\" come analista e faccio una query <strong>select count from hits<\/strong>, mi verr\u00e0 immediatamente restituita un'eccezione che indica che non posso eseguire la query. Il numero massimo di righe che mi \u00e8 consentito esaminare \u00e8 cento miliardi, mentre nel cluster ce ne sono cinquantatr\u00e9 trilioni in una sola tabella. Questo \u00e8 il primo limite. <\/p>\n<p><\/p>\n<p>Supponiamo che rimuova il limite sul numero di righe e ripeta la query. Allora vedr\u00f2 la seguente eccezione: la configurazione \u00e8 abilitata. <strong>force index by date<\/strong>. Non posso completare la richiesta se non ho specificato un intervallo di date. Non si pu\u00f2 contare sul fatto che gli analisti lo indichino manualmente. Un caso tipico \u00e8 scritto l'intervallo di date dove la data dell'evento \u00e8 tra la settimana. E poi pu\u00f2 darsi che non sia stata indicata correttamente la parentesi, e invece di and, \u00e8 uscito or \u2014 or URL corrisponde. Se non ci sono limitazioni, andr\u00e0 a scansionare la colonna URL e spender\u00e0 semplicemente un sacco di risorse.<\/p>\n<p><\/p>\n<p>Inoltre, in ClickHouse ci sono due impostazioni di priorit\u00e0. Sfortunatamente, sono molto primitive. Una si chiama semplicemente <strong>priorit\u00e0<\/strong>. Se la priorit\u00e0 \u2260 0, e vengono eseguite richieste con una certa priorit\u00e0, ma viene eseguita una richiesta con priorit\u00e0 che ha un valore inferiore, il che significa una priorit\u00e0 superiore, allora la richiesta con un valore di priorit\u00e0 maggiore, che indica una priorit\u00e0 inferiore, viene semplicemente sospesa e non funzioner\u00e0 affatto in quel momento.<\/p>\n<p><\/p>\n<p>Questa \u00e8 un'impostazione molto grossolana e non \u00e8 adatta per quei casi in cui nel cluster c'\u00e8 un carico costante. Ma se avete richieste brevi e impulsive che sono importanti, e per lo pi\u00f9 il cluster \u00e8 inattivo, tale impostazione pu\u00f2 funzionare.<\/p>\n<p><\/p>\n<p>La seguente impostazione delle priorit\u00e0 si chiama <strong>priorit\u00e0 del thread OS<\/strong>. Essa imposta semplicemente per tutti i thread di esecuzione della richiesta un valore nice per lo scheduler Linux. Funziona cos\u00ec cos\u00ec, ma comunque funziona. Se si imposta il valore nice minimo \u2014 che \u00e8 il pi\u00f9 grande in termini di valore, e quindi la priorit\u00e0 pi\u00f9 bassa \u2014 e per le richieste ad alta priorit\u00e0 si imposta -19, allora la CPU consumer\u00e0 le richieste a bassa priorit\u00e0 circa quattro volte meno rispetto alle richieste ad alta priorit\u00e0. <\/p>\n<p><\/p>\n<p>Bisogna anche impostare il tempo massimo di esecuzione della richiesta \u2014 diciamo cinque minuti. La velocit\u00e0 minima di esecuzione della richiesta \u2014 \u00e8 la cosa migliore. Questa impostazione esiste da tempo e serve non solo a dichiarare che ClickHouse non rallenta, ma per forzarlo.<\/p>\n<p><\/p>\n<p>Immagina, stai impostando: se una richiesta elabora meno di un milione di righe al secondo \u2014 questo non si pu\u00f2 fare. Questo scredita il nostro buon nome, il nostro buon database. Diciamo che lo vietiamo semplicemente. In effetti, ci sono due impostazioni. Una si chiama <strong>velocit\u00e0 minima di esecuzione<\/strong> \u2014 in&nbsp;righe al&nbsp;secondo, e il secondo si chiama timeout prima di controllare la velocit\u00e0 minima di esecuzione&nbsp;\u2014 di default quindici secondi. Cio\u00e8 si possono avere quindici secondi, e poi, se \u00e8 lento, semplicemente lanciare un'eccezione \u2014 interrompere la richiesta.<\/p>\n<p><\/p>\n<p>\u00c8 necessario anche configurare le quote. In&nbsp;ClickHouse c'\u00e8 una funzione integrata di quota che calcola il consumo delle risorse. Ma, sfortunatamente, non si riferisce alle risorse fisiche come CPU, dischi, ma a quelle logiche&nbsp;\u2014 il numero di richieste elaborate, righe e byte letti. E si pu\u00f2 configurare, ad esempio, un massimo di cento richieste in&nbsp;cinque minuti e mille richieste all'ora.<\/p>\n<p><\/p>\n<p>Perch\u00e9 \u00e8 importante? Perch\u00e9 parte delle richieste di analisi verranno eseguite manualmente direttamente dal&nbsp;client ClickHouse. E andr\u00e0 tutto bene. Ma se in&nbsp;azienda avete analisti avanzati, scriveranno uno script, e nello script potrebbe esserci un errore. E questo errore porter\u00e0 a&nbsp;un'esecuzione della richiesta in&nbsp;un ciclo infinito. Da&nbsp;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 restituire i risultati di una query a dieci client?<\/h2>\n<p><\/p>\n<blockquote><p>Abbiamo diversi utenti che amano arrivare con&nbsp;richieste molto grandi allo stesso momento. La richiesta \u00e8 grande, viene eseguita abbastanza rapidamente, ma poich\u00e9 ci sono molte di queste richieste contemporaneamente, diventa molto difficile. \u00c8 possibile eseguire la stessa richiesta, che \u00e8 arrivata dieci volte di seguito, solo una volta e restituire il suo risultato a dieci clienti?<\/p><\/blockquote>\n<p>Il problema \u00e8 che non abbiamo risultati di cache o cache di dati intermedi. C'\u00e8 il page cache del sistema operativo, che permette di non leggere i dati dal disco nuovamente, ma, sfortunatamente, i dati dovranno comunque essere decompressi, deserializzati e rielaborati. <\/p>\n<p><\/p>\n<p>Ci piacerebbe in qualche modo evitare questo, o memorizzando nella cache i dati intermedi, o organizza richieste simili in&nbsp;una certa coda e aggiungendo una cache dei risultati. Attualmente abbiamo in sviluppo una richiesta di pull che aggiunge una cache per le richieste, ma solo per sottorichieste nelle sezioni in e join \u2014 quindi la soluzione non \u00e8 completa.<\/p>\n<p><\/p>\n<p>Tuttavia, anche noi ci troviamo in questa situazione. Un esempio canonico sono le richieste con paginazione. C'\u00e8 un report che contiene diverse pagine e si effettua una richiesta limitata a 10. Poi la stessa cosa, ma con una richiesta limitata a 10,10. Poi ancora la pagina successiva. E ci si chiede, perch\u00e9 calcoliamo ogni volta tutto questo? Ma al momento non ci sono soluzioni, e non possiamo evitarlo.<\/p>\n<p><\/p>\n<p>Esiste una soluzione alternativa che si installa come sidecar accanto a 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 frequenza integrato e una cache dei risultati. Ci sono molte impostazioni, perch\u00e9 era necessario affrontare un problema simile. Il Proxy consente di limitare le richieste, mettendole in coda, e di configurare per quanto tempo rimane in vita la cache delle richieste. Se le richieste sono davvero identiche, il Proxy le restituir\u00e0 molte volte, mentre andr\u00e0 su ClickHouse solo una volta.<\/p>\n<p><\/p>\n<p>Anche Nginx ha una cache nella versione gratuita, e funziona anche questo. Nginx ha persino impostazioni che, se le richieste arrivano contemporaneamente, rallenter\u00e0 altre finch\u00e9 una non sar\u00e0 completata. Ma proprio in ClickHouse Proxy l'impostazione \u00e8 fatta molto meglio. \u00c8 stato progettato appositamente per ClickHouse, per queste richieste, quindi \u00e8 pi\u00f9 adatto. Inoltre, si installa facilmente. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>Come gestire 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 \u2014 prima vengono registrati i dati, poi avviene la loro compressione. Se sotto la tabella vive una tabella materializzata con alcuni aggregati, i duplicati verranno registrati l\u00ec. E se non c'\u00e8 una logica complessa, i dati saranno duplicati. Cosa si pu\u00f2 fare al riguardo?<\/p>\n<p>C'\u00e8 una soluzione ovvia \u2014 implementare un trigger su un certo tipo di materialized view durante l'operazione asincrona di compressione. Ci sono \"proiettili d'argento\" o piani per implementare funzionalit\u00e0 simili?<\/p><\/blockquote>\n<p>\u00c8 importante capire come funziona la deduplicazione. Ci\u00f2 di cui parlo ora non attiene alla questione, ma \u00e8 bene tenerne conto per ogni evenienza.<\/p>\n<p><\/p>\n<p>Quando si inserisce in una tabella replicata, viene eseguita la deduplicazione dei blocchi interamente inseriti. Se reinserisci lo stesso blocco, contenente lo stesso numero di righe nello stesso ordine, i dati saranno deduplicati. Riceverai 'Ok' in risposta all'inserimento, ma effettivamente verr\u00e0 registrato un solo pacco di dati e non sar\u00e0 duplicato.<\/p>\n<p><\/p>\n<p>Questo \u00e8 necessario per chiarezza. Se durante l'inserimento hai ricevuto 'Ok', significa che i tuoi dati sono stati inseriti. Se hai ricevuto un errore da 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 siano stati inseriti o meno. L'unica opzione \u00e8 ripetere di nuovo l'inserimento. Se i dati sono stati effettivamente inseriti e li reinserisci, c'\u00e8 una deduplicazione dei blocchi. Essa \u00e8 necessaria per evitare duplicati. <\/p>\n<p><\/p>\n<p>\u00c8 anche importante capire come funziona per le viste materializzate. Se i dati sono stati deduplicati durante l'inserimento nella tabella principale, non andranno neanche nella vista 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 viene duplicato l'intero pacco, ma singole righe specifiche, e queste si accorpano nello sfondo. Infatti, i dati si accorperanno nella tabella principale, mentre nella vista materializzata andranno quelli non accorpati, e durante i merge non succeder\u00e0 nulla con le viste materializzate. Perch\u00e9 la vista materializzata non \u00e8 altro che un trigger per l'inserimento. In altre operazioni non succede nulla di supplementare con essa.<\/p>\n<p><\/p>\n<p>E qui purtroppo non posso darti buone notizie. Dobbiamo solo cercare una soluzione specifica per questo caso. Per esempio, \u00e8 possibile fare anche il suo replacement nella vista materializzata, e il metodo di deduplicazione potrebbe funzionare 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 abbiamo avuto il nostro periodo di costruzione di ponte, un vero caos. C'era il problema che ci sono le visualizzazioni pubblicitarie e ci sono alcuni dati che possiamo mostrare in tempo reale - sono semplicemente visualizzazioni. Raramente si duplicano, ma se succede, le accorpiamo comunque. E ci sono cose che non possono essere duplicate - i click e tutta questa storia. Ma ci tenevamo a mostrarle praticamente subito.<\/p>\n<p><\/p>\n<p>Come sono stati realizzati le viste materializzate? Ci sono viste in cui si scrive direttamente \u2013 si registra nei dati grezzi e si scrive nelle viste. A un certo punto i dati l\u00ec non sono molto corretti, si duplicano e cos\u00ec via. E c'\u00e8 una seconda parte della tabella, dove appaiono esattamente come le viste materializzate, quindi strutturalmente sono assolutamente identiche. Ogni tanto ricalcoliamo i dati, contabilizziamo i dati senza duplicati e li scriviamo in quelle tabelle. <\/p>\n<p><\/p>\n<p>Abbiamo lavorato tramite API - farlo manualmente in ClickHouse non funziona. E l'API controlla: quando ho la data dell'ultima aggiunta nella tabella, dove ci sono gi\u00e0 dati corretti, calcolati, fa una richiesta a una tabella e a un'altra tabella. Dalla prima seleziona fino a una certa quantit\u00e0 di tempo, e dalla seconda prende ci\u00f2 che non \u00e8 ancora stato calcolato. E questo funziona, ma non con gli strumenti di ClickHouse stesso.<\/p>\n<p><\/p>\n<p>Se hai un'API - per analisti, per utenti - in principe, questa \u00e8 una possibilit\u00e0. Puoi sempre completare, sempre ricalcolare. Puoi farlo una volta al giorno o in un altro momento. Puoi scegliere da solo l'intervallo che non ti serve e non \u00e8 critico.<\/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 sta accadendo con il server in tempo reale?<\/h2>\n<p><\/p>\n<blockquote><p>In ClickHouse ci sono un numero molto elevato di log diversi, e questo numero \u00e8 in aumento. Nelle nuove versioni alcuni di essi sono persino abilitati per default, mentre nelle versioni pi\u00f9 vecchie devono essere attivati durante l'aggiornamento. Tuttavia, ce ne sono sempre di pi\u00f9. Vorrei vedere alla fine cosa sta accadendo ora con il mio server, magari su un dashboard riassuntivo. <\/p>\n<p>Hai qualcuno nel vostro team di ClickHouse, o nei team dei vostri amici, che supporta qualche funzionalit\u00e0 di dashboard pronte, che mostrano questi log in forma di prodotto gi\u00e0 pronto? Alla fine, guardare i log in ClickHouse \u00e8 fantastico. Ma sarebbe davvero fantastico se fosse gi\u00e0 preparato in forma di dashboard. Mi piacerebbe molto. <\/p><\/blockquote>\n<p>Ci sono dashboard, anche se non sono standardizzate. Nella nostra azienda, circa 60 team utilizzano ClickHouse, ed \u00e8 strano che molti di loro abbiano dashboard che hanno creato da soli, e sono leggermente diverse. Alcuni team utilizzano un'installazione interna di \"Yandex.Cloud\". Ci sono alcuni report pronti, anche se non tutti quelli necessari. Altri hanno i loro. <\/p>\n<p><\/p>\n<p>I miei colleghi della \"Metri\" hanno il loro dashboard in Grafana, e io ho il mio sul loro stesso cluster. L\u00ec controlla cose come il cache hit per il caching delle annotazioni. E la cosa ancora pi\u00f9 difficile \u00e8 che utilizziamo strumenti diversi. Ho creato il mio dashboard con uno strumento molto vecchio chiamato Graphite-web. Non \u00e8 affatto bello. E ancora lo utilizzo, anche se Grafana sarebbe probabilmente pi\u00f9 comoda e bella. <\/p>\n<p><\/p>\n<p>La cosa fondamentale nelle dashboard \u00e8 la stessa. Si tratta di metriche di sistema sul 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 partizioni delle tabelle MergeTree, il lag di replicazione, la dimensione della coda di replicazione, il numero di righe inserite al secondo, il numero di blocchi inseriti al secondo. Tutto ci\u00f2 non proviene dai log, ma dalle metriche.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Alexey, vorrei fare una piccola correzione. C'\u00e8 Grafana. Grafana ha un datasource, che \u00e8 ClickHouse. Quindi posso fare richieste direttamente a ClickHouse da Grafana. In ClickHouse c'\u00e8 una tabella con i log, \u00e8 la stessa per tutti. Voglio che in Grafana possa accedere a questa tabella dei log e vedere le richieste che il mio server genera. Sarebbe fantastico avere un dashboard del genere.<\/p>\n<p><\/p>\n<p>L'ho creato io stesso. Ma ho una domanda: se tutto \u00e8 standardizzato e Grafana \u00e8 utilizzata da tutti, perch\u00e9 in \"Yandex\" non c'\u00e8 un dashboard ufficiale del genere?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> In realt\u00e0, il datasource che si interfaccia con ClickHouse \u00e8 attualmente supportato da Altinity. Vorrei dare un'indicazione su dove approfondire e chi consultare. Si pu\u00f2 chiedere a loro, perch\u00e9 \"Yandex\" sviluppa ClickHouse, non la storia che ruota attorno ad esso. Altinity \u00e8 l'azienda principale che attualmente promuove ClickHouse. Non lo abbandoneranno, ma continueranno a supportarlo. In sostanza, per caricare un dashboard sul sito di Grafana, \u00e8 sufficiente registrarsi e caricarlo: non ci sono particolari problemi. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Negli ultimi dodici mesi sono state aggiunte molte funzionalit\u00e0 per il profiling delle query in ClickHouse. Ci sono metriche per ogni query relative all'utilizzo delle risorse. E di recente \u00e8 stato introdotto un profiler delle query a livello pi\u00f9 basso, per vedere dove una query consuma ogni millisecondo. Ma per utilizzare questa funzionalit\u00e0, devo aprire il client della console e digitare la query che dimentico sempre. L'ho salvata da qualche parte, ma continuo a dimenticare dove. <\/p>\n<p><\/p>\n<p>Vorrei che ci fosse uno strumento che mostrasse semplicemente: ecco le vostre query pesanti, suddivise per classi di query. Cliccando su una qualsiasi di esse, mi direbbero perch\u00e9 \u00e8 pesante. Attualmente non esiste una soluzione del genere. E risulta abbastanza strano che, quando le persone mi chiedono: \"Ci sono dashboard pronte per Grafana?\", io rispondo: \"Visitate il sito di Grafana, l\u00ec c'\u00e8 la sezione community 'Dashboard', e ci sono dashboard da Dimka e da Kostyan. Non so di cosa si tratti, non le ho mai usate.\"<\/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 intervenire nei merge affinch\u00e9 il server non cada in OOM?<\/h2>\n<p><\/p>\n<blockquote><p>Ho una tabella con una sola partizione, che utilizza ReplacingMergeTree. Ci scrivo dati da quattro anni. Dovrei fare un alter e rimuovere alcuni dati.<\/p>\n<p>L'ho fatto e, durante l'elaborazione di questa query, tutta la memoria sui server del cluster \u00e8 stata esaurita, e tutti i server sono andati in OOM. Poi sono tornati attivi, hanno iniziato a eseguire il merge di questa stessa operazione, di questo blocco di dati, e sono di nuovo andati in OOM. Poi sono tornati attivi e di nuovo sono andati in OOM. E questa situazione non \u00e8 mai cessata.<\/p>\n<p>Poi si \u00e8 scoperto che in&nbsp;realt\u00e0 si trattava di un bug che i ragazzi hanno risolto. \u00c8 fantastico, grazie mille. Tuttavia, \u00e8 rimasta una certa apprensione. E adesso, quando penso a&nbsp;fare una sorta di merge nella&nbsp;tabella, mi viene in mente un interrogativo: perch\u00e9 non posso in qualche modo influenzare questi merge? Ad esempio, limitando la quantit\u00e0 di memoria RAM necessaria, o in generale limitando il numero di merge da elaborare per questa tabella.<\/p>\n<p>Ho una tabella chiamata \"Metriche\", ti prego di elaborarla in&nbsp;due thread. Non dovresti creare dieci o cinque merge in parallelo, fallo in&nbsp;due. Penso che in&nbsp;due la mia memoria sia sufficiente, ma per elaborare dieci potrebbe non bastare. Perch\u00e9 rimane la paura? Perch\u00e9 la tabella cresce, e prima o poi mi trover\u00f2 nella situazione in cui, non per un bug, ma perch\u00e9 i dati cambieranno in tal modo, la memoria del server non sar\u00e0 sufficiente. E allora il server andr\u00e0 in OOM durante il merge. Posso annullare la mutazione, ma non i merge.<\/p><\/blockquote>\n<p>Sai, durante i merge il server non andr\u00e0 in OOM, perch\u00e9 durante il merge si utilizza 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 Kolobaev:<\/strong> Va bene. C'\u00e8 da dire che dopo aver effettuato la correzione del bug, ho scaricato la nuova versione e ho eseguito un'operazione simile su un'altra tabella, pi\u00f9 piccola, con molte partizioni. Durante il merge sul server sono stati consumati circa 100&nbsp;GB di RAM. Avevo 150&nbsp;GB occupati, 100&nbsp;GB utilizzati, e mi sono rimasti 50&nbsp;GB di spazio, quindi non sono andato in OOM.<\/p>\n<p><\/p>\n<p>Cosa mi protegge al momento dal finire in OOM, se effettivamente consuma 100&nbsp;GB di RAM? Cosa fare se all'improvviso la memoria RAM durante i merge finisce?<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> C'\u00e8 un problema in cui l'uso della memoria RAM non \u00e8 limitato solo ai merge. E il secondo problema \u00e8 che, se \u00e8 stato pianificato un merge, deve essere eseguito poich\u00e9 \u00e8 registrato nel log di replicazione. Il log di replicazione rappresenta le azioni necessarie per riportare la replica in uno stato coerente. Se non vengono eseguite le manipolazioni manuali che questo log di replicazione annullerebbe, il merge dovr\u00e0 essere eseguito, in un modo o nell'altro.<\/p>\n<p><\/p>\n<p>Certo, sarebbe utile avere un limite sulla RAM che protegge 'per ogni evenienza' contro l'OOM. Non aiuter\u00e0 a completare il merge, che inizier\u00e0 di nuovo, arriver\u00e0 a una certa soglia, generer\u00e0 un'eccezione e poi inizier\u00e0 di nuovo: non ne verrebbe nulla di buono. Ma in linea di principio, sarebbe utile introdurre questo limite.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>Come avverr\u00e0 lo sviluppo di un driver Golang per ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>Il driver Golang scritto da Kirill Shvakov \u00e8 ora ufficialmente supportato dal team di ClickHouse. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">In repository ClickHouse<\/a><\/noindex>, ora \u00e8 grande e reale.<\/p>\n<p>Una piccola nota. C'\u00e8 un meraviglioso e amatissimo archiviazione di forme normali di ordine infinito: \u00e8 Vertica. Hanno anche un loro driver python ufficiale, supportato dagli sviluppatori di Vertica. Diverse volte \u00e8 successo che le versioni dell'archiviazione e le versioni del driver si discostassero notevolmente, e il driver a un certo punto ha smesso di funzionare. E un secondo punto. Il supporto per questo driver ufficiale, mi sembra, viene fornito dal sistema \"nipple\": scrivi loro un problema, e rimane appeso 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 interfaccia http, perch\u00e9 gli piace cos\u00ec. Come avverr\u00e0 lo sviluppo di questo driver? Si sincronizzer\u00e0 con eventuali cambiamenti di rottura nell'archiviazione stessa? E qual \u00e8 l'ordine di esame dei problemi? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> Primo - come \u00e8 tutto organizzato burocraticamente. Questo punto non \u00e8 stato discusso, quindi non ho nulla da rispondere.<\/p>\n<p><\/p>\n<p>Per rispondere alla domanda riguardante il problema, \u00e8 necessaria una breve storia del driver. Ho lavorato in un'azienda con molti dati. Era una piattaforma pubblicitaria con un enorme numero di eventi che dovevano essere archiviati. E a un certo punto \u00e8 arrivato ClickHouse. Abbiamo caricato i dati l\u00ec, e inizialmente tutto andava bene, poi ClickHouse \u00e8 andato in crash. A quel tempo abbiamo deciso che non ci serviva. <\/p>\n<p><\/p>\n<p>Un anno dopo, siamo tornati all'idea di utilizzare ClickHouse e avevamo bisogno di un modo per scrivere i dati. La premessa era questa: l'hardware era molto debole e le risorse erano poche. Ma avevamo sempre lavorato in questo modo, quindi abbiamo considerato il protocollo nativo.<\/p>\n<p><\/p>\n<p>Poich\u00e9 lavoravamo in Go, era chiaro che avevamo bisogno di un driver in Go. L'ho sviluppato praticamente a tempo pieno: era il mio compito lavorativo. Fino a un certo punto siamo riusciti a completarlo, e sostanzialmente nessuno si aspettava che qualcun altro lo usasse. Poi \u00e8 arrivato CloudFlare con esattamente lo stesso problema, e per un periodo abbiamo lavorato molto bene insieme, poich\u00e9 avevano le stesse esigenze. Abbiamo fatto questo sia in ClickHouse stesso che nel driver. <\/p>\n<p><\/p>\n<p>A un certo punto, ho semplicemente smesso di occuparmene, perch\u00e9 la mia attivit\u00e0 riguardo ClickHouse e il lavoro \u00e8 cambiata un po'. Perci\u00f2 le questioni non vengono chiuse. Di tanto in tanto, nel repository fanno commit persone che hanno bisogno di qualcosa. Allora guardo le pull request e a volte addirittura correggo qualcosa da solo, ma succede raramente.<\/p>\n<p><\/p>\n<p>Vorrei tornare al driver. Alcuni anni fa, quando tutto questo \u00e8 cominciato, ClickHouse era diverso e aveva altre possibilit\u00e0. Ora abbiamo un'idea di come rifare il driver per migliorarlo. Se ci\u00f2 accadr\u00e0, la versione 2 sar\u00e0 comunque incompatibile a causa dei vari workaround accumulati. <\/p>\n<p><\/p>\n<p>Non so come organizzare la cosa. Personalmente non ho molto tempo. Se alcune persone possono migliorare il driver, posso aiutarli e spiegare cosa fare. Ma la partecipazione attiva di 'Yandex' nello sviluppo del progetto non \u00e8 stata ancora discussa. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> In realt\u00e0, al momento non c'\u00e8 alcuna burocrazia riguardo questi driver. L'unica cosa \u00e8 che sono stati trasferiti a un'organizzazione ufficiale, cio\u00e8 questo driver \u00e8 riconosciuto come la soluzione ufficiale di default per Go. Ci sono altri driver, ma vengono gestiti separatamente. <\/p>\n<p><\/p>\n<p>All'interno non abbiamo alcuno sviluppo per questi driver. La questione \u00e8 se riusciremo a assumere una persona specifica, non solo per questo driver, ma per lo sviluppo di tutti i driver della community, o se riusciremo a trovare qualcuno dall'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 carica 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 carica automaticamente. Viene caricato solo quando un utente accede a quel dizionario. E al primo accesso restituisce un errore. \u00c8 possibile caricare automaticamente i dizionari con i mezzi di ClickHouse, o dobbiamo sempre controllare la loro disponibilit\u00e0 noi stessi, affinch\u00e9 gli utenti non ricevano errori?<\/p>\n<p>Potrebbe essere che abbiamo una versione obsoleta di ClickHouse, quindi il dizionario non si \u00e8 caricato automaticamente. Pu\u00f2 essere?<\/p><\/blockquote>\n<p>In primo luogo, i dizionari possono essere caricati forzatamente tramite una query. <strong>system reload dictionaries<\/strong>. In secondo luogo, riguardo l'errore \u2014 se il dizionario \u00e8 gi\u00e0 stato caricato, le richieste funzioneranno con i dati che sono stati caricati. Se il dizionario non \u00e8 ancora stato caricato, verr\u00e0 caricato proprio al momento della richiesta.<\/p>\n<p><\/p>\n<p>Per dizionari pesanti questo non \u00e8 molto conveniente. Ad esempio, \u00e8 necessario estrarre un milione di righe da MySQL. Qualcuno fa una semplice selezione, ma questa selezione aspetter\u00e0 proprio quel milione di righe. Qui ci sono due soluzioni. La prima \u00e8 disattivare lazy_load. La seconda \u2014 quando il server si avvia, prima di caricarlo, eseguire <strong>system reload dictionary<\/strong> oppure semplicemente eseguire una richiesta che utilizza il dizionario. In questo modo il dizionario verr\u00e0 caricato. \u00c8 necessario controllare l'accessibilit\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 \u2014 o la versione \u00e8 obsoleta, o \u00e8 necessario fare del debug. <\/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>Come affrontare il fatto che il system reload dictionaries non carica nessuno dei numerosi dizionari se anche solo uno di essi genera un errore?<\/h2>\n<p><\/p>\n<blockquote><p>C'\u00e8 anche una domanda riguardo a system reload dictionaries. Abbiamo due dizionari \u2014 uno non si carica, l'altro si carica. System reload dictionaries in questo caso non carica alcun dizionario, e bisogna caricarne specificamente uno per nome usando system reload dictionary. Questo \u00e8 anche 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. Se non vi piace il comportamento attuale <strong>system reload dictionaries<\/strong>, aggiornati, e speriamo che la situazione migliori.<\/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>C'\u00e8 un modo per configurare le credenziali nel&nbsp;config di ClickHouse senza esporle in caso di errori?<\/h2>\n<p><\/p>\n<blockquote><p>La prossima domanda riguarda gli errori legati al dizionario, ovvero le credenziali. Abbiamo specificato le credenziali di connessione nel file di configurazione di ClickHouse per il dizionario, e in caso di errore otteniamo quelle credenziali e la password in risposta. <\/p>\n<p>Abbiamo risolto questo errore spostando le credenziali nel file di configurazione del driver ODBC. C'\u00e8 un modo per configurare le credenziali nel file di configurazione di ClickHouse senza esporre queste credenziali in caso di errori?<\/p><\/blockquote>\n<p>Qui la soluzione \u00e8 davvero \u2014 indicare queste credenziali in odbc.ini, e in ClickHouse specificare solo il ODBC Data Source Name. Per altre fonti di dizionari non ci sar\u00e0 nulla di simile \u2014 n\u00e9 per il dizionario con MySQL, n\u00e9 per le altre non dovreste vedere la password quando si verifica un errore. Per ODBC controller\u00f2 anch'io \u2014 se esiste, 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 con&nbsp;le riunioni<\/h2>\n<p><\/p>\n<p>Cliccando sull'immagine, i lettori pi\u00f9 tenaci potranno accedere a fondi bonus dedicati a riunioni. Spegniamo il fuoco insieme ai mascotte della tecnologia Avito, discutiamo con i colleghi nella stanza dell'amministratore di sistema o in un vecchio club di computer e facciamo il daily sotto il ponte davanti a un graffito.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse per utenti avanzati in 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.1.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.1.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 esperti in domande e risposte | ProHoster","description":"Ad aprile, gli ingegneri di Avito si sono riuniti per incontri online con il principale sviluppatore di ClickHouse, Aleksej Milovidov, e Kirill Shvakov, sviluppatore di 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}]}}