{"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 righe in ClickHouse. Relazione di Yandex","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il database analitico ClickHouse elabora molte diverse stringhe, consumando risorse. Per accelerare le prestazioni del sistema, vengono costantemente aggiunte nuove ottimizzazioni. Lo sviluppatore di ClickHouse, Nikolai Ko\u010detov, parla del tipo di dato stringa, incluso un nuovo tipo, LowCardinality, e spiega come migliorare l'efficienza nella gestione delle stringhe. <\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 Prima di tutto, capiremo come possiamo memorizzare le stringhe.
\n<\/a><\/noindex>
\n\"Ottimizzazione
\n
\nAbbiamo i tipi di dati stringa. String \u00e8 una scelta predefinita molto adatta e dovrebbe essere utilizzata quasi sempre. Ha un piccolo Overhead \u2014 9 byte per ogni stringa. Se vogliamo che la dimensione delle stringhe sia fissa e nota in anticipo, \u00e8 meglio utilizzare FixedString. In questo modo possiamo specificare il numero desiderato di byte, rendendolo comodo per dati come indirizzi IP o funzioni hash. <\/p>\n

\"Ottimizzazione
\n
\nCerto, a volte ci sono dei rallentamenti. Supponiamo che tu stia effettuando una richiesta su una tabella. ClickHouse legge una quantit\u00e0 piuttosto elevata di dati, diciamo a una velocit\u00e0 di 100 GB\/s, mentre il numero di stringhe elaborate \u00e8 ridotto. Abbiamo due tabelle che memorizzano dati quasi identici. ClickHouse legge i dati dalla seconda tabella a una velocit\u00e0 maggiore, ma il numero di stringhe lette al secondo \u00e8 tre volte inferiore. <\/p>\n

\"Ottimizzazione
\n
\nSe guardiamo la dimensione dei dati compressi, essa risulta praticamente equivalente. In realt\u00e0, nelle tabelle sono registrati gli stessi dati: il primo miliardo di numeri \u2014 solo che nella prima colonna sono scritti come UInt64, mentre nella seconda come String. A causa di questo, 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 cambi praticamente mai. In questo caso, il tipo di dato Enum \u00e8 adatto; in ClickHouse ce ne sono due: Enum8 ed Enum16. Grazie allo storage in Enum, siamo in grado di elaborare rapidamente le query. <\/p>\n

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

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

\"Ottimizzazione
\n
\nALTER per Enum in ClickHouse \u00e8 implementato in modo ottimale. Non riscriviamo i dati su disco, ma gli ALTER potrebbero rallentare a causa del fatto che le strutture Enum sono memorizzate nello schema della tabella stessa. Pertanto, dobbiamo attendere le query di lettura dalla tabella, per esempio. <\/p>\n

Sorge il quesito: si pu\u00f2 fare meglio? Probabilmente s\u00ec. Si potrebbe mantenere la struttura Enum non nello schema della tabella, ma in ZooKeeper. Tuttavia, potrebbero sorgere problemi di sincronizzazione. Ad esempio, una replica ha ricevuto i dati, l'altra no, e se ha un Enum obsoleto, qualcosa potrebbe rompersi. (In ClickHouse abbiamo quasi completato le query ALTER non bloccanti. Una volta terminate completamente, non sar\u00e0 necessario attendere le query di lettura.)<\/p>\n

\"Ottimizzazione
\n
\nPer evitare di occuparsi di ALTER Enum, si possono utilizzare dizionari esterni ClickHouse. Ricordo che si tratta di una struttura di 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 diverse stringhe, mentre nella tabella sono memorizzati i loro identificatori come numeri. Se abbiamo bisogno di ottenere una stringa, chiamiamo la funzione dictGet e lavoriamo con essa. Dopo di ci\u00f2, non dovremmo effettuare ALTER. Per aggiungere qualcosa a Enum, lo inseriamo nella stessa tabella MySQL. <\/p>\n

Tuttavia, sorgono altri problemi. Prima di tutto, la sintassi scomoda. Se vogliamo ottenere una stringa, dobbiamo chiamare dictGet. In secondo luogo, manca alcune ottimizzazioni. Non \u00e8 altrettanto veloce effettuare il confronto con una stringa costante per i dizionari. <\/p>\n

Possono esserci anche problemi con l'aggiornamento. Supponiamo di aver richiesto una stringa nella cache-dizionario e che non sia finita nella cache. Dobbiamo quindi aspettare che i dati vengano caricati da una 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. Perch\u00e9 non memorizzare i dizionari localmente? Niente sincronizzazione, niente problemi. Possiamo memorizzare il dizionario localmente in un pezzo su disco. Quindi abbiamo effettuato un Insert, registrando il dizionario. Se lavoriamo con 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 lessicale delle stringhe <\/h3>\n

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

\"Ottimizzazione
\n
\nNella slide ci sono due colonne. A destra, le stringhe sono memorizzate in modo standard, nel tipo String. Si pu\u00f2 vedere che si tratta di modelli di telefoni cellulari. A sinistra c'\u00e8 esattamente la stessa colonna, ma nel tipo LowCardinality. Essa consiste in un dizionario con molte stringhe diverse (stringhe dalla colonna a destra) e un elenco di posizioni (numeri di riga). <\/p>\n

Con queste due strutture \u00e8 possibile ricostruire la colonna originale. Esiste anche un indice inverso, una tabella hash, che aiuta a trovare la posizione nel dizionario in base alla stringa. \u00c8 necessaria per accelerare alcune query. Ad esempio, se vogliamo confrontare o cercare una stringa nella nostra colonna o unirle tra loro. <\/p>\n

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

\"Ottimizzazione
\n
\nLa caratteristica di LowCardinality \u00e8 che pu\u00f2 essere mantenuta per alcune funzioni. Nella diapositiva \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: ClickHouse ha risposto che si tratta di LowCardinality di String. Tutto corretto.<\/p>\n

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

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

Possono esserci anche altre ottimizzazioni, ad esempio l'aggiunta di una semplice cache. Quando si calcola il valore di una funzione, \u00e8 possibile memorizzarne uno e crearne uno identico, senza doverlo ricalcolare. <\/p>\n

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

\"Ottimizzazione
\n
\nE se creassimo una colonna con il nostro tipo di dati e inserissimo al suo interno molte righe diverse e problematiche? La nostra memoria si riempir\u00e0? No, per questo ClickHouse ha 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 comune. Se il dizionario diventa pi\u00f9 grande del valore della configurazione, scriviamo l'attuale dizionario su disco, mentre le altre righe le mettiamo da qualche parte \"a lato\", vicino agli indici. Di conseguenza, non ricomputeremo mai un grande dizionario e non avremo problemi di memoria. <\/p>\n

La seconda impostazione si chiama low_cardinality_use_single_dictionary_for_part. Immagina che, nello schema precedente, quando abbiamo inserito i dati, il nostro dizionario fosse diventato pieno e lo abbiamo scritto su disco. Si pone quindi la domanda: perch\u00e9 non generare un altro dizionario identico? <\/p>\n

Quando si riempir\u00e0, lo scriveremo di nuovo su disco e cominceremo a generare 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 abbiamo accidentalmente inserito \"spazzatura\". Diciamo, prima abbiamo inserito righe sbagliate e poi quelle corrette. In questo caso, il dizionario si divider\u00e0 in tanti piccoli dizionari. Alcuni di essi conterranno \"spazzatura\", ma gli ultimi avranno righe corrette. E se leggiamo, per esempio, solo l'ultimo granulo, tutto funzioner\u00e0 comunque rapidamente. <\/p>\n

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

Per non essere poco credibile, 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, con un miliardo di righe registrate. Nella prima colonna, CodePage, ci sono solo 62 valori. E si vede che in LowCardinality(String) li abbiamo compressi meglio. String \u00e8 un po' peggiore, ma probabilmente \u00e8 dovuto al fatto che le stringhe sono corte; teniamo traccia delle loro lunghezze e occupano molto spazio, quindi si comprimono male. <\/p>\n

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

Valutazione della velocit\u00e0 operativa<\/h3>\n

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

Ora valutiamo la velocit\u00e0 operativa. Per valutarla, ho usato un dataset con la descrizione dei viaggi in taxi a New York. Esso \u00e8 disponibile<\/a><\/noindex> su GitHub. Ci sono poco pi\u00f9 di un miliardo di corse. Sono rappresentati la posizione, l'orario di inizio e di 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 iniziato con una richiesta piuttosto semplice \u2014 ho chiesto dove vengono ordinati pi\u00f9 frequentemente i taxi. Per fare questo, bisogna prendere la posizione da cui sono stati ordinati, fare un GROUP BY su di essa e contare il risultato. ClickHouse restituisce qualcosa. <\/p>\n

\"Ottimizzazione
\n
\nPer misurare la velocit\u00e0 di elaborazione della richiesta, ho creato tre tabelle con gli stessi dati, ma ho usato 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 rispetto a String. Enum \u00e8 pi\u00f9 veloce perch\u00e9 lavora con numeri. LowCardinality \u2014 perch\u00e9 \u00e8 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. Anche in questo caso, misureremo dove vengono ordinati pi\u00f9 frequentemente i taxi, ma filtreremo solo le posizioni che contengono la parola \u00abparco\u00bb. Aggiungeremo anche la funzione like. <\/p>\n

\"Ottimizzazione
\n
\nGuardiamo il tempo e vediamo che Enum ha improvvisamente iniziato a rallentare. Inoltre, funziona ancora pi\u00f9 lentamente rispetto al tipo di dati standard String. Questo accade perch\u00e9 la funzione like non \u00e8 affatto ottimizzata per Enum. Dobbiamo convertire le nostre stringhe da Enum in normali stringhe, il che comporta un lavoro aggiuntivo. LowCardinality(String) non \u00e8 ottimizzato per impostazione predefinita, ma in quel caso like funziona su un dizionario, quindi la query 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: \u00e8 necessario pensare a un'ottimizzazione per Enum. Mentre in LowCardinality \u00e8 tutto ottimizzato per impostazione predefinita.<\/p>\n

\"Ottimizzazione
\n
\nAnalizziamo l'ultima query, pi\u00f9 artificiale. Contiamo semplicemente la funzione hash della nostra posizione. La funzione hash \u00e8 una query piuttosto lenta, richiede tempo per essere calcolata, quindi tutto rallenter\u00e0 di circa tre volte.<\/p>\n

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

\"Ottimizzazione
\n
\nIl nostro obiettivo globale \u00e8 raggiungere una velocit\u00e0 di funzionamento pari o superiore a quella di String in tutti i casi, mantenendo i miglioramenti. E, forse, un giorno sostituiremo String con LowCardinality, aggiornerete 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. Presentazione di Yandex | ProHoster","description":"Il sistema di database analitico ClickHouse gestisce una variet\u00e0 di stringhe, consumando risorse. Per velocizzare il funzionamento del sistema, vengono continuamente 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}]}}