{"id":74737,"date":"2020-03-20T08:43:14","date_gmt":"2020-03-20T05:43:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa"},"modified":"2020-03-20T08:43:14","modified_gmt":"2020-03-20T05:43:14","slug":"optimizacziya-strok-v-clickhouse-doklad-yandeksa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","title":{"rendered":"Ottimizzazione delle stringhe in ClickHouse. Relazione di Yandex","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il database analitico ClickHouse gestisce una grande variet\u00e0 di stringhe, consumando risorse. Per velocizzare il funzionamento del sistema, vengono costantemente aggiunte nuove ottimizzazioni. Lo sviluppatore di ClickHouse, Nikolai Kochetov, parla del tipo di dato stringa, compreso il nuovo tipo LowCardinality, e spiega come ottimizzare il lavoro con le stringhe. <\/p>\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 Prima di tutto, vediamo come possiamo memorizzare le stringhe.
\n<\/a><\/noindex>
\n\"Ottimizzazione
\n
\nAbbiamo i tipi di dati stringa. Il tipo String \u00e8 adatto per impostazione predefinita e vale la pena utilizzarlo quasi sempre. Ha un sovraccarico minimo: 9 byte per ogni stringa. Se desideriamo che la dimensione delle stringhe sia fissa e nota in anticipo, \u00e8 meglio usare FixedString. In questo modo possiamo definire il numero di byte desiderato, rendendolo utile per dati come indirizzi IP o funzioni hash. <\/p>\n

\"Ottimizzazione
\n
\nCertamente, a volte qualcosa pu\u00f2 rallentare. Supponiamo di fare una query su una tabella. ClickHouse legge una quantit\u00e0 piuttosto elevata di dati, ad esempio a una velocit\u00e0 di 100 GB\/s, mentre il numero di stringhe elaborate \u00e8 basso. Abbiamo due tabelle che memorizzano dati quasi identici. Dalla seconda tabella, ClickHouse legge i dati a una velocit\u00e0 maggiore, ma il numero di stringhe lette al secondo \u00e8 tre volte inferiore. <\/p>\n

\"Ottimizzazione
\n
\nSe guardiamo alla dimensione dei dati compressi, risulta quasi uguale. In realt\u00e0, nelle tabelle sono memorizzati gli stessi dati: il primo miliardo di numeri \u2014 solo che nella prima colonna sono scritti come UInt64 e nella seconda come String. Per questo motivo, la seconda query impiega pi\u00f9 tempo a leggere i dati dal disco e a decomprimerli. <\/p>\n

\"Ottimizzazione
\n
\nEcco un altro esempio. Supponiamo che ci sia un insieme di stringhe noto in anticipo, limitato a una costante di 1000 o 10.000 e che non cambi praticamente mai. Per questo caso, ci sembrano adatte le Enum, in ClickHouse ne abbiamo due: Enum8 e Enum16. Grazie alla memorizzazione nelle Enum, possiamo elaborare rapidamente le query. <\/p>\n

In ClickHouse ci sono ottimizzazioni per GROUP BY, IN, DISTINCT e ottimizzazioni per certe funzioni, ad esempio per il confronto con una stringa costante. Ovviamente, i numeri nelle stringhe non vengono convertiti; al contrario, la stringa costante viene trasformata nel valore Enum. Dopo di ci\u00f2, tutto viene confrontato rapidamente. <\/p>\n

Ma ci sono anche degli svantaggi. Anche se conosciamo l'insieme esatto di stringhe, a volte deve essere ampliato. Se arriva una nuova stringa, dobbiamo effettuare un ALTER. <\/p>\n

\"Ottimizzazione
\n
\nL'ALTER per Enum in ClickHouse \u00e8 implementato in modo ottimale. Non riscriviamo i dati su disco, ma l'ALTER pu\u00f2 rallentare perch\u00e9 le strutture Enum sono memorizzate nello schema della tabella stessa. Pertanto, dobbiamo attendere le richieste di lettura dalla tabella, ad esempio. <\/p>\n

Sorge il problema: si pu\u00f2 fare meglio? Probabilmente s\u00ec. Si potrebbe salvare la struttura Enum non nello schema della tabella, ma in ZooKeeper. Tuttavia, potrebbero sorgere problemi legati alla sincronizzazione. Ad esempio, un replica ha ricevuto i dati, mentre un'altra no, e se quest'ultima ha un Enum obsoleto, qualcosa si romper\u00e0. (In ClickHouse abbiamo quasi completato le richieste ALTER non bloccanti. Quando saranno completamente pronte, non sar\u00e0 necessario attendere le richieste di lettura.)<\/p>\n

\"Ottimizzazione
\n
\nPer non doversi occupare dell'ALTER Enum, \u00e8 possibile utilizzare i dizionari esterni di ClickHouse. Ricordo che si tratta di una struttura dati key-value all'interno di ClickHouse, tramite la quale \u00e8 possibile ottenere dati da fonti esterne, ad esempio da tabelle MySQL. <\/p>\n

Nel dizionario ClickHouse memorizziamo molte stringhe diverse, mentre nella tabella abbiamo i loro identificatori sotto forma di numeri. Se dobbiamo ottenere una stringa, invochiamo la funzione dictGet e lavoriamo con essa. Dopodich\u00e9 non dobbiamo fare ALTER. Per aggiungere qualcosa a Enum, lo inseriamo nella stessa tabella MySQL. <\/p>\n

Ma qui sorgono altri problemi. Innanzitutto, la sintassi scomoda. Se vogliamo ottenere una stringa, dobbiamo invocare dictGet. In secondo luogo, la mancanza di alcune ottimizzazioni. Il confronto con una stringa costante per i dizionari non \u00e8 cos\u00ec veloce. <\/p>\n

Possono sorgere anche problemi con l'aggiornamento. Supponiamo di aver richiesto una stringa nel dizionario cache e questa non vi \u00e8 finita. Allora dobbiamo attendere il caricamento dei dati dalla fonte esterna. <\/p>\n

\"Ottimizzazione
\n
\nUn difetto comune di entrambi i metodi \u00e8 che memorizziamo tutte le chiavi in un unico posto e le sincronizziamo. Allora perch\u00e9 non memorizzare i dizionari localmente? Niente sincronizzazione, niente problemi. Possiamo memorizzare il dizionario localmente in un frammento su disco. Dunque, abbiamo fatto un Insert, registrato il dizionario. Se lavoriamo con i dati in memoria, possiamo registrare il dizionario o in un blocco di dati, o in un pezzo di colonna, o in qualche cache, per accelerare i calcoli.<\/p>\n

Codifica a dizionario delle stringhe <\/h3>\n

\nCos\u00ec siamo arrivati alla creazione di un nuovo tipo di dato in ClickHouse: LowCardinality. Questo \u00e8 un formato di memorizzazione dei dati: come vengono scritti su disco e come vengono letti, come sono rappresentati in memoria e lo schema del loro trattamento. <\/p>\n

\"Ottimizzazione
\n
\nNella slide ci sono due colonne. A destra le righe sono salvate in modo standard, nel tipo String. \u00c8 visibile che si tratta di alcuni modelli di telefoni cellulari. A sinistra c'\u00e8 una colonna identica, solo nel tipo LowCardinality. Essa consiste in un dizionario con molte righe diverse (righe dalla colonna di destra) e un elenco di posizioni (numeri di riga). <\/p>\n

Con queste due strutture \u00e8 possibile ricostruire la colonna originale. C'\u00e8 anche un indice inverso \u2014 una tabella hash che aiuta a trovare la posizione nel dizionario partendo dalla riga. Questa \u00e8 necessaria per accelerare alcune query. Per esempio, se vogliamo confrontare, cercare una riga nella nostra colonna o unirle tra loro. <\/p>\n

LowCardinality \u00e8 un tipo di dato parametrico. Pu\u00f2 essere un numero, o qualcosa che \u00e8 memorizzato come numero, oppure una stringa, o Nullable di essi. <\/p>\n

\"Ottimizzazione
\n
\nLa caratteristica di LowCardinality \u00e8 che pu\u00f2 essere salvata per alcune funzioni. Nella slide \u00e8 visibile un esempio di query. Nella prima riga ho creato una colonna di tipo LowCardinality da String, chiamandola S. Poi ho chiesto il suo nome \u2014 ClickHouse ha detto che \u00e8 LowCardinality da String. Tutto corretto.<\/p>\n

La terza riga \u00e8 quasi la stessa, solo che abbiamo chiamato la funzione length. In ClickHouse la funzione length restituisce il tipo di dato UInt64. Ma \u00e8 diventata LowCardinality da UInt64. Qual \u00e8 il senso?<\/p>\n

\"Ottimizzazione
\n
\nNel dizionario erano memorizzati i nomi dei telefoni cellulari, abbiamo applicato la funzione length. Ora abbiamo un dizionario analogo, composto solo da numeri \u2014 sono le lunghezze delle righe. La colonna con le posizioni non \u00e8 cambiata. Alla fine, abbiamo elaborato meno dati, risparmiando tempo nella query. <\/p>\n

Possono esserci anche altre ottimizzazioni, ad esempio l'aggiunta di una semplice cache. Durante il calcolo del valore della funzione si pu\u00f2 memorizzare e crearne uno simile, senza calcolarlo di nuovo. <\/p>\n

Pu\u00f2 anche essere ottimizzata la GROUP BY, poich\u00e9 la nostra colonna con il dizionario \u00e8 gi\u00e0 parzialmente aggregata \u2014 \u00e8 possibile calcolare pi\u00f9 rapidamente il valore delle funzioni hash e trovare approssimativamente il bucket in cui posizionare la nuova riga. Inoltre, si possono specializzare alcune funzioni aggregate, come uniq, poich\u00e9 in essa si pu\u00f2 inviare solo il dizionario, lasciando intatte le posizioni \u2014 in questo modo tutto funzioner\u00e0 pi\u00f9 rapidamente. Le prime due ottimizzazioni le abbiamo gi\u00e0 aggiunte in ClickHouse.<\/p>\n

\"Ottimizzazione
\n
\nE se creassimo una colonna con il nostro tipo di dati e ci inserissimo molte righe diverse e sbagliate? La nostra memoria non si riempirebbe? No, per questo in ClickHouse ci sono due impostazioni speciali. La prima \u00e8 low_cardinality_max_dictionary_size. Questo \u00e8 il massimo dimensione del dizionario che pu\u00f2 essere scritto su disco. L'inserimento avviene nel seguente modo: quando inseriamo dati, riceviamo un flusso di righe, da cui formiamo un grande dizionario condiviso. Se il dizionario diventa pi\u00f9 grande del valore dell'impostazione, scriviamo l'attuale dizionario su disco, mentre le altre righe vengono allocate da qualche parte \"di lato\", vicino agli indici. Alla fine, non ri-calcoleremo mai il grande dizionario e non avremo problemi di memoria. <\/p>\n

La seconda impostazione si chiama low_cardinality_use_single_dictionary_for_part. Immaginate che nella precedente configurazione, quando inserivamo dati, il nostro dizionario si sia riempito e lo abbiamo scritto su disco. C'\u00e8 da chiedersi, perch\u00e9 non formare ora un altro dizionario esattamente uguale? <\/p>\n

Quando si riempie, lo scriviamo di nuovo su disco e iniziamo a formare il terzo. Questa impostazione disabilita proprio questa possibilit\u00e0 per impostazione predefinita. <\/p>\n

In realt\u00e0, avere molti dizionari pu\u00f2 essere utile se vogliamo inserire un certo insieme di righe, ma accidentalmente abbiamo inserito \"spazzatura\". Diciamo, all'inizio abbiamo inserito righe sbagliate e poi abbiamo inserito quelle corrette. Allora il dizionario si divider\u00e0 in molti piccoli dizionari. Alcuni di essi conterranno \"spazzatura\", ma gli ultimi conterranno righe buone. E se leggiamo, ad esempio, solo l'ultima porzione, tutto funzioner\u00e0 rapidamente. <\/p>\n

\"Ottimizzazione
\n
\nPrima di parlare dei vantaggi di LowCardinality, voglio dire subito che \u00e8 improbabile che otteniamo una riduzione dei dati su disco (anche se pu\u00f2 succedere), poich\u00e9 ClickHouse comprime i dati. C'\u00e8 un'opzione predefinita: LZ4. \u00c8 anche possibile eseguire la compressione tramite ZSTD. Ma entrambi gli algoritmi implementano gi\u00e0 la compressione dizionario, quindi il nostro dizionario esterno ClickHouse non sar\u00e0 di grande aiuto. <\/p>\n

Per non essere solo teorico, ho preso alcuni dati dalla metrica \u2014 String, LowCardinality(String) ed Enum \u2014 e li ho salvati in diversi tipi di dati. Sono risultati tre colonne, ognuna contenente un miliardo di righe. Nella prima colonna, CodePage, ci sono solo 62 valori. E si vede che nel LowCardinality(String) sono stati compressi meglio. String \u00e8 un po' peggio, ma ci\u00f2 \u00e8 probabilmente dovuto al fatto che le stringhe sono corte, ne conserviamo le lunghezze, e occupano molto spazio, compressione scadente. <\/p>\n

Se prendiamo PhoneModel, ce ne sono 48 mila \u2014 gi\u00e0 di pi\u00f9, e le differenze tra String e LowCardinality(String) sono quasi inesistenti. Anche per l'URL abbiamo risparmiato solo 2 GB \u2014 penso che non valga la pena fare affidamento su questo. <\/p>\n

Valutazione della velocit\u00e0 di esecuzione<\/h3>\n

\n\"Ottimizzazione
\nCollegamento dalla diapositiva<\/a><\/noindex><\/b><\/p>\n

Ora valutiamo la velocit\u00e0 di esecuzione. Per farlo, ho utilizzato un dataset con la descrizione delle corse dei taxi a New York. Esso disponibile<\/a><\/noindex> si trova su GitHub. Contiene poco pi\u00f9 di un miliardo di corse. Sono riportati la posizione, l'ora di inizio e fine corsa, il metodo di pagamento, il numero di passeggeri e persino il tipo di taxi \u2014 verde, giallo e Uber. <\/p>\n

\"Ottimizzazione
\n
\nHo fatto la prima richiesta piuttosto semplice \u2014 ho chiesto dove si ordinano pi\u00f9 spesso i taxi. Per fare ci\u00f2, \u00e8 necessario prendere la posizione da cui sono stati ordinati, fare un GROUP BY su di essa e contare la funzione count. Ecco cosa restituisce ClickHouse. <\/p>\n

\"Ottimizzazione
\n
\nPer misurare la velocit\u00e0 di elaborazione della richiesta, ho creato tre tabelle con gli stessi dati, ma ho utilizzato tre diversi tipi di dati per la nostra posizione di partenza \u2014 String, LowCardinality ed Enum. LowCardinality ed Enum si sono rivelati cinque volte pi\u00f9 veloci di String. Enum \u00e8 pi\u00f9 veloce perch\u00e9 lavora con numeri. LowCardinality \u2014 perch\u00e9 \u00e8 stata implementata un'ottimizzazione per il GROUP BY. <\/p>\n

\"Ottimizzazione
\n
\nComplichiamo ulteriormente la richiesta \u2014 chiediamo dove si trova il parco pi\u00f9 popolare a New York. Ancora una volta, misureremo ci\u00f2 in base a dove si ordinano pi\u00f9 spesso i taxi, ma filtreremo solo quelle posizioni che contengono la parola \"parco\". Aggiungeremo anche la funzione like. <\/p>\n

\"Ottimizzazione
\n
\nControlliamo il tempo \u2014 vediamo che Enum ha improvvisamente iniziato a rallentare. Inoltre, funziona addirittura pi\u00f9 lentamente del tipo di dato standard String. Questo accade perch\u00e9 la funzione like non \u00e8 affatto ottimizzata per Enum. Dobbiamo convertire le nostre stringhe da Enum in stringhe normali \u2014 facciamo pi\u00f9 lavoro. LowCardinality(String) non \u00e8 ottimizzato per impostazione predefinita, ma qui like funziona su un dizionario, quindi la richiesta si accelera rispetto a String. <\/p>\n

Quando si lavora con Enum, c'\u00e8 un problema pi\u00f9 globale. Se vogliamo ottimizzarlo, dobbiamo farlo in ogni punto del codice. Supponiamo di aver scritto una nuova funzione: dobbiamo necessariamente pensare a un'ottimizzazione per Enum. In LowCardinality tutto \u00e8 ottimizzato di default.<\/p>\n

\"Ottimizzazione
\n
\nDiamo un'occhiata all'ultima query, pi\u00f9 artificiale. Calcoleremo semplicemente la funzione hash della nostra posizione. La funzione hash \u00e8 una richiesta piuttosto lenta, richiede tempo, quindi tutto rallenter\u00e0 di circa tre volte.<\/p>\n

\"Ottimizzazione
\n
\nLowCardinality funziona ancora pi\u00f9 velocemente, anche se qui non c'\u00e8 filtraggio. Questo accade perch\u00e9 le nostre funzioni operano solo sul dizionario. La funzione di calcolo dell'hash ha un argomento: pu\u00f2 elaborare meno dati e pu\u00f2 anche restituire LowCardinality. <\/p>\n

\"Ottimizzazione
\n
\nIl nostro piano globale \u00e8 raggiungere velocit\u00e0 di funzionamento non inferiori a quelle di String in tutti i casi e mantenere l'accelerazione. E, forse un giorno, sostituiremo String con LowCardinality, aggiornerai ClickHouse e tutto funzioner\u00e0 un po' pi\u00f9 velocemente.
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438. \u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a ClickHouse \u041d\u0438\u043a\u043e\u043b\u0430\u0439 \u041a\u043e\u0447\u0435\u0442\u043e\u0432 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442 \u043e \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043e \u043d\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435, LowCardinality, \u0438 \u043e\u0431\u044a\u044f\u0441\u043d\u044f\u0435\u0442, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0443\u0441\u043a\u043e\u0440\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043e \u0441\u0442\u0440\u043e\u043a\u0430\u043c\u0438. \u2014 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u0434\u0430\u0432\u0430\u0439\u0442\u0435 \u0440\u0430\u0437\u0431\u0435\u0440\u0435\u043c\u0441\u044f, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u0438. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u044b\u0435 \u0442\u0438\u043f\u044b \u0434\u0430\u043d\u043d\u044b\u0445. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":74738,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-74737","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ottimizzazione delle stringhe in ClickHouse. Relazione di Yandex | ProHoster","description":"Il database analitico ClickHouse elabora una moltitudine di stringhe diverse, consumando risorse. Per accelerare il funzionamento del sistema vengono costantemente aggiunte nuove ottimizzazioni.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","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\udd47\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0442\u0440\u043e\u043a \u0432 ClickHouse. \u0414\u043e\u043a\u043b\u0430\u0434 \u042f\u043d\u0434\u0435\u043a\u0441\u0430 | ProHoster","og:description":"\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","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-03-20T05:43:14+00:00","article:modified_time":"2020-03-20T05:43:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"74737","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 17:23:10","updated":"2022-09-27 14:48:44","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\/74737","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=74737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/74737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/74738"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=74737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=74737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=74737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}