{"id":79028,"date":"2020-04-23T19:43:19","date_gmt":"2020-04-23T17:43:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb"},"modified":"2020-04-23T19:43:19","modified_gmt":"2020-04-23T17:43:19","slug":"pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","title":{"rendered":"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Recentemente ho parlato di come utilizzare ricette standardizzate <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/tensor\/blog\/492694\/\">per aumentare le prestazioni delle query SQL \"di lettura\"<\/a><\/noindex> da un database PostgreSQL. Oggi parleremo di come <b>rendere pi\u00f9 efficace la scrittura<\/b> nel database senza usare alcun \"giro di vite\" nella configurazione, semplicemente organizzando correttamente i flussi di dati.<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/cbebbe0ed0e9a6590a4e8dd144f82f40.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>#1. \u0421\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435<\/h2>\n<p>\nArticolo su come e perch\u00e9 \u00e8 opportuno organizzare <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/483170\/\">la suddivisione applicativa \"in teoria\"<\/a><\/noindex> era gi\u00e0 presente, mentre qui discuteremo della pratica di alcuni approcci nel nostro <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/487380\/\">servizio di monitoraggio di centinaia di server PostgreSQL<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>\u00abFatti di tempi passati&#8230;\u00bb<\/h4>\n<p>\nInizialmente, come ogni MVP, il nostro progetto \u00e8 partito con un carico piuttosto ridotto: il monitoraggio avveniva soltanto per una decina di server particolarmente critici, tutte le tabelle erano relativamente compatte\u2026 Ma il tempo passava, gli host monitorati aumentavano, e dopo aver tentato un'altra volta di fare qualcosa con una delle <b>tabelle delle dimensioni di 1.5TB<\/b>, ci siamo resi conto che si poteva continuare a vivere in questo modo, ma era piuttosto scomodo.<\/p>\n<p>I tempi erano quasi leggendari, erano in uso diverse versioni di PostgreSQL 9.x, quindi tutta la suddivisione doveva essere effettuata \"manualmente\" \u2014 tramite <b>ereditariet\u00e0 delle tabelle e trigger<\/b> di instradamento dinamico. <code>EXECUTE<\/code>.<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/a480e75ccec73080aa2d0be1435d2a2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLa soluzione risultante si \u00e8 rivelata sufficientemente universale da poter essere applicata a tutte le tabelle:<\/p>\n<ul>\n<li>\u00c8 stata dichiarata una tabella genitore \"vuota\" che descriveva tutti <b>gli indici e trigger necessari<\/b>.<\/li>\n<li>La scrittura dal punto di vista del cliente veniva effettuata nella tabella \"radice\", mentre all'interno, utilizzando <b>il trigger di instradamento<\/b> <code>BEFORE INSERT<\/code> la registrazione veniva \u00abfisicamente\u00bb inserita nella sezione desiderata. Se non esisteva una sezione del genere - catturavamo l'eccezione e &#8230;<\/li>\n<li>\u2026 utilizzando <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/492464\/\"><code>CREATE TABLE ... (LIKE ... INCLUDING ...)<\/code><\/a><\/noindex> secondo il modello della tabella genitore veniva creata <b>una sezione con un vincolo sulla data necessaria<\/b>, in modo che durante l'estrazione dei dati la lettura avvenisse solo l\u00ec.<\/li>\n<\/ul>\n<p><\/p>\n<h4>PG10: primo tentativo<\/h4>\n<p>\nMa la suddivisione tramite ereditariet\u00e0 si \u00e8 dimostrata storicamente poco adattabile per lavorare con un flusso attivo di scrittura o un gran numero di sezioni figlie. Ad esempio, si pu\u00f2 ricordare che l'algoritmo per scegliere la sezione corretta aveva <b>complessit\u00e0 quadratica<\/b>, il che, con oltre 100 sezioni, sapete come funziona\u2026<\/p>\n<p>In PG10 questa situazione \u00e8 stata fortemente ottimizzata, implementando il supporto <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgresql\/10\/ddl-partitioning\">per la partizione nativa<\/a><\/noindex>. Pertanto, abbiamo subito provato ad applicarlo subito dopo la migrazione dello storage, ma\u2026<\/p>\n<p>Come si \u00e8 rivelato dopo aver esaminato il manuale, una tabella partizionata nativamente in questa versione:<\/p>\n<ul>\n<li>non supporta la descrizione degli indici<\/li>\n<li>non supporta trigger su di essa<\/li>\n<li>non pu\u00f2 essere essa stessa un \"discendente\" di nessuno<\/li>\n<li>non supporta <code>INSERT ... ON CONFLICT<\/code><\/li>\n<li>non \u00e8 in grado di generare automaticamente la sezione<\/li>\n<\/ul>\n<p>\nDopo aver preso una botta in testa dalle scelte sbagliate, abbiamo capito che senza modifiche all'applicazione non ci saremmo riusciti, e abbiamo rinviato ulteriori ricerche di sei mesi.<\/p>\n<h4>PG10: una seconda possibilit\u00e0<\/h4>\n<p>\nQuindi abbiamo iniziato a risolvere i problemi emersi uno alla volta:<\/p>\n<ol>\n<li>Poich\u00e9 i trigger e <code>ON CONFLICT<\/code> si rivelavano in alcune occasioni comunque necessari, per gestirli abbiamo creato una <b>tabella proxy<\/b>.<\/li>\n<li><b>Ci siamo liberati del \"routing\"<\/b> nei trigger, cio\u00e8 di <code>EXECUTE<\/code>.<\/li>\n<li>Abbiamo isolato una <b>tabella template con tutti gli indici<\/b>, affinch\u00e9 non fossero neppure presenti sulla tabella proxy.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/db3118798357575568489f6b575373b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nInfine, dopo tutto questo, abbiamo partizionato nativamente la tabella principale. La creazione di una nuova sezione \u00e8 rimasta ancora a carico dell'applicazione.<\/p>\n<h4>\"Tagliamo\" i dizionari<\/h4>\n<p>\nCome in qualsiasi sistema analitico, anche noi avevamo <b>\"fatti\" e \"dimensioni\"<\/b> (dizionari). Nel nostro caso, a questo scopo, fungevano, ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/5XKbFb-l5Do?t=2487\">il corpo del \"template\"<\/a><\/noindex> di query lente simili o il testo stesso della query.<\/p>\n<p>\"Fatti\" erano gi\u00e0 stati partizionati per giorni da tempo, quindi eliminavamo tranquillamente le sezioni obsolete, e non ci davano fastidio (eran solo log!). Ma con i dizionari \u00e8 successo un guaio\u2026<\/p>\n<p>Non si pu\u00f2 dire che ce ne fossero moltissimi, ma circa <b>per 100TB di \"fatti\" si otteneva un dizionario di 2,5TB<\/b>. Da una tabella cos\u00ec non si pu\u00f2 comodamente eliminare nulla, non la si pu\u00f2 comprimere in tempi adeguati, e anche la scrittura in essa stava diventando progressivamente pi\u00f9 lenta.<\/p>\n<p>Sembra un dizionario\u2026 in esso ogni registrazione dovrebbe essere rappresentata solo una volta\u2026 ed \u00e8 corretto, ma!.. Nessuno ci vieta di avere <b>un dizionario separato per ogni giorno<\/b>! S\u00ec, questo porta a una certa ridondanza, ma consente di:<\/p>\n<ul>\n<li><b>scrivere\/leggere pi\u00f9 velocemente<\/b> grazie a dimensioni minori della sezione<\/li>\n<li><b>consumare meno memoria<\/b> grazie a operare con indici pi\u00f9 compatti<\/li>\n<li><b>memorizzare meno dati<\/b> grazie alla possibilit\u00e0 di eliminare rapidamente i dati obsoleti<\/li>\n<\/ul>\n<p>\nA seguito di tutto questo complesso di misure <b>il carico della CPU \u00e8 diminuito di circa il 30%, mentre quello del disco di circa il 50%<\/b>:<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/fd3a219a304dc46173a7eb435502fe02.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nNel contempo, abbiamo continuato a scrivere nel database esattamente le stesse cose, ma con un carico minore.<\/p>\n<h2>#2. \u042d\u0432\u043e\u043b\u044e\u0446\u0438\u044f \u0438 \u0440\u0435\u0444\u0430\u043a\u0442\u043e\u0440\u0438\u043d\u0433 \u0411\u0414<\/h2>\n<p>\nQuindi, siamo arrivati al punto in cui abbiamo <b>una sezione dedicata per ogni giorno<\/b> con i dati. In effetti, <code>CHECK (dt = '2018-10-12'::date)<\/code> \u00e8 la chiave della partizione e la condizione per l'inserimento di un record in una sezione specifica.<\/p>\n<p>Poich\u00e9 tutti i report nel nostro servizio sono basati su una data specifica, anche gli indici risalenti ai \"tempi non partizionati\" sono tutti del tipo <i>(Server, <b>Data<\/b>, Modello di piano)<\/i>, <i>(Server, <b>Data<\/b>, Nodo di piano)<\/i>, <i>(<b>Data<\/b>, Classe di errore, Server)<\/i>,\u2026<\/p>\n<p>Ma ora in ogni sezione ci sono <u>le proprie istanze<\/u> di ciascun indice\u2026 E all'interno di ogni sezione <u>la data \u00e8 una costante<\/u>\u2026 Risulta che ora in ogni indice del genere <b>scriviamo banalmente una costante<\/b> come uno dei campi, il che aumenta sia il suo volume che i tempi di ricerca, ma non porta a nessun risultato. Ci siamo messi in difficolt\u00e0, ops...<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/c7644644b960c568c4adaeec57cfef2d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLa direzione per l'ottimizzazione \u00e8 chiara: basta <b>rimuovere il campo della data da tutti gli indici<\/b> nelle tabelle partizionate. Con i nostri volumi, il risparmio \u00e8 di circa <b>1TB\/settimana<\/b>!<\/p>\n<p>E ora notiamo che questo terabyte doveva anche essere registrato in qualche modo. Cio\u00e8, ora dobbiamo anche <b>caricare meno il disco<\/b>! In questa immagine si pu\u00f2 vedere chiaramente l'effetto ottenuto dalla pulizia effettuata, alla quale abbiamo dedicato una settimana:<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/f45e3b26337074a07751ea28961009bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>#3. \u00ab\u0420\u0430\u0437\u043c\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u00bb \u043f\u0438\u043a\u043e\u0432\u0443\u044e \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443<\/h2>\n<p>\nUna delle grandi problematiche dei sistemi sovraccarichi \u00e8 <b>la sincronizzazione eccessiva<\/b> di operazioni non necessarie. A volte \"perch\u00e9 non ci siamo accorti\", altre volte \"perch\u00e9 era pi\u00f9 semplice\", ma prima o poi bisogna liberarsene.<\/p>\n<p>Avviciniamo l'immagine precedente e vediamo che il disco ha <b>un carico che oscilla con un'ampiezza doppia<\/b> tra le misurazioni vicine, cosa che chiaramente statisticamente non dovrebbe succedere con tale numero di operazioni:<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/ac3f19213cba0f111864c6dbf9a73912.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOttenerlo \u00e8 piuttosto semplice. Avevamo gi\u00e0 monitorato <b>quasi 1000 server<\/b>, ognuno trattato da un flusso logico separato, e ogni flusso rilascia le informazioni accumulate per l'invio al database con una certa periodicit\u00e0, pi\u00f9 o meno cos\u00ec:<\/p>\n<pre><code class=\"javascript\">setInterval(sendToDB, interval)<\/code><\/pre>\n<p>\nIl problema risiede nel fatto che <b>tutti i flussi partono pi\u00f9 o meno nello stesso momento<\/b>, quindi i momenti di invio coincidono quasi sempre \"fino al punto\". Ops n. 2...<\/p>\n<p>Fortunatamente, questo \u00e8 abbastanza facile da sistemare, <b>aggiungendo una dispersione \u00abcasuale\u00bb<\/b> in tempo:<\/p>\n<pre><code class=\"javascript\">setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))<\/code><\/pre>\n<p><\/p>\n<h2>#4. \u041a\u044d\u0448\u0438\u0440\u0443\u0435\u043c, \u0447\u0442\u043e \u043d\u0443\u0436\u043d\u043e \u043c\u043e\u0436\u043d\u043e<\/h2>\n<p>\nIl terzo problema tradizionale del highload \u2014 <b>mancanza di caching<\/b> l\u00ec dove potrebbe <i>essere.<\/i> essere.<\/p>\n<p>Ad esempio, abbiamo reso possibile l'analisi in base ai nodi di piano (tutti questi <code>Seq Scan on users<\/code>), ma subito pensare che siano tutti uguali, \u00e8 stato dimenticato.<\/p>\n<p>No, certo, nel database non viene scritto nulla di nuovo, ci\u00f2 blocca il trigger con <code>INSERT ... ON CONFLICT DO NOTHING<\/code>. Ma questi dati comunque arrivano al database, e tocca comunque effettuare un <b>ulteriore lettura per controllare i conflitti.<\/b> Oops n. 3\u2026<\/p>\n<p>La differenza nel numero di record inviati al database prima\/dopo l'attivazione della cache \u00e8 evidente:<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/37fa7e64a674f03a79f2765a79ec8138.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE questo \u00e8 il conseguente calo del carico sullo storage:<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/b2c563b4b41755211e77768d80f8702f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Totale<\/h2>\n<p>\n\u00abTerabyte al giorno\u00bb sembra spaventoso. Se fai tutto nel modo giusto, sono solo <b>2^40 byte \/ 86400 secondi = ~12.5MB\/s<\/b>, che riuscivano anche i dischi IDE da tavolo. \ud83d\ude42<\/p>\n<p>E se vogliamo essere seri, anche con un \u2018picco\u2019 di carico dieci volte superiore durante il giorno, puoi tranquillamente rimanere nei limiti degli attuali SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Scrivendo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/6f3f8d4636ba50f3d5401bf4e456757f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/497008\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0442\u0438\u043f\u043e\u0432\u044b\u0445 \u0440\u0435\u0446\u0435\u043f\u0442\u043e\u0432 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c SQL-\u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u00ab\u043d\u0430 \u0447\u0442\u0435\u043d\u0438\u0435\u00bb \u0438\u0437 PostgreSQL-\u0431\u0430\u0437\u044b. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0436\u0435 \u0440\u0435\u0447\u044c \u043f\u043e\u0439\u0434\u0435\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0431\u043e\u043b\u0435\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0437\u0430\u043f\u0438\u0441\u044c \u0432 \u0411\u0414 \u0431\u0435\u0437 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u0430\u043a\u0438\u0445-\u043b\u0438\u0431\u043e \u00ab\u043a\u0440\u0443\u0442\u0438\u043b\u043e\u043a\u00bb \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0435 \u2014 \u043f\u0440\u043e\u0441\u0442\u043e \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u0430\u0432 \u043f\u043e\u0442\u043e\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445. #1. \u0421\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0421\u0442\u0430\u0442\u044c\u044f \u043f\u0440\u043e \u0442\u043e, \u043a\u0430\u043a \u0438 \u0437\u0430\u0447\u0435\u043c \u0441\u0442\u043e\u0438\u0442 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u044b\u0432\u0430\u0442\u044c \u043f\u0440\u0438\u043a\u043b\u0430\u0434\u043d\u043e\u0435 \u0441\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u00ab\u0432 \u0442\u0435\u043e\u0440\u0438\u0438\u00bb [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":79029,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-79028","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=\"\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0442\u0438\u043f\u043e\u0432\u044b\u0445 \u0440\u0435\u0446\u0435\u043f\u0442\u043e\u0432 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c SQL-\u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u00ab\u043d\u0430 \u0447\u0442\u0435\u043d\u0438\u0435\u00bb \u0438\u0437.\" \/>\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\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb\" \/>\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\udd47\u041f\u0438\u0448\u0435\u043c \u0432 PostgreSQL \u043d\u0430 \u0441\u0443\u0431\u0441\u0432\u0435\u0442\u043e\u0432\u043e\u0439: 1 host, 1 day, 1TB | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0442\u0438\u043f\u043e\u0432\u044b\u0445 \u0440\u0435\u0446\u0435\u043f\u0442\u043e\u0432 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c SQL-\u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u00ab\u043d\u0430 \u0447\u0442\u0435\u043d\u0438\u0435\u00bb \u0438\u0437.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb\" \/>\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-04-23T17:43:19+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-23T17:43:19+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\udd47Scriviamo in PostgreSQL a velocit\u00e0 subluminale: 1 host, 1 giorno, 1TB | ProHoster","description":"Recentemente ho parlato di come, utilizzando ricette standard, aumentare le prestazioni delle query SQL \u00abin lettura\u00bb.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","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\u041f\u0438\u0448\u0435\u043c \u0432 PostgreSQL \u043d\u0430 \u0441\u0443\u0431\u0441\u0432\u0435\u0442\u043e\u0432\u043e\u0439: 1 host, 1 day, 1TB | ProHoster","og:description":"\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0442\u0438\u043f\u043e\u0432\u044b\u0445 \u0440\u0435\u0446\u0435\u043f\u0442\u043e\u0432 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c SQL-\u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u00ab\u043d\u0430 \u0447\u0442\u0435\u043d\u0438\u0435\u00bb \u0438\u0437.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","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-04-23T17:43:19+00:00","article:modified_time":"2020-04-23T17:43:19+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"79028","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:46:34","updated":"2022-10-01 20:30:41","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\/79028","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=79028"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/79028\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/79029"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=79028"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=79028"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=79028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}