{"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\/nl\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","title":{"rendered":"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Onlangs vertelde ik hoe je de prestaties van 'read' SQL-query's kunt verhogen <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/tensor\/blog\/492694\/\">uit PostgreSQL-databases. Vandaag gaat het over hoe<\/a><\/noindex> je het schrijven <b>in de database effici\u00ebnter kunt maken zonder enige 'draaiknoppen' in de configuratie - gewoon door de datastromen goed te organiseren.<\/b> Dit artikel gaat over hoe en waarom je het moet organiseren<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 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>\nvan toepasselijke partitionering 'in theorie'. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/483170\/\">Eerder was er al een artikel hierover, maar hier gaat het over de toepassing van enkele benaderingen binnen onze<\/a><\/noindex> monitoringdienst voor honderden PostgreSQL-servers. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/487380\/\">\u2018Dagen van weleer\u2026\u2019<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>\u00abVerleden dagen...\u00bb<\/h4>\n<p>\ntabellen van 1,5TB, <b>begrepen we dat het leven zo verdergaan mogelijk was, maar erg onhandig.<\/b>De tijden waren bijna mythisch, verschillende varianten van PostgreSQL 9.x waren relevant, dus moest al het partitioneren 'handmatig' worden gedaan - via<\/p>\n<p>tabelovererving en triggers. <b>Routing met dynamische<\/b> Het resultaat bleek voldoende universeel te zijn, zodat het op alle tabellen kon worden toegepast. <code>EXECUTE<\/code>.<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/a480e75ccec73080aa2d0be1435d2a2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEr werd een lege 'hoofd'-parenttabel gedeclareerd, waarop alle<\/p>\n<ul>\n<li>vereiste indexen en triggers werden beschreven. <b>Gegevens vanuit het perspectief van de klant werden ingevoerd in de 'wortel'-tabel, terwijl binnenin met behulp van<\/b>.<\/li>\n<li>de routing-trigger <b>BEFORE INSERT<\/b> <code>de gegevens 'fysiek' in het juiste segment werden ingevoegd. Als zo'n segment nog niet bestond, vingen we de uitzondering op en ...<\/code> de opname werd \u00abfysiek\u00bb in de juiste sectie geplaatst. Als deze er nog niet was \u2014 vingen we de uitzondering op en ...<\/li>\n<li>CREATE TABLE ... (LIKE ... INCLUDING ...) <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/492464\/\"><code>volgens het sjabloon van de parenttabel werd er een<\/code><\/a><\/noindex> segment aangemaakt met een beperking op de vereiste datum, <b>zodat tijdens het ophalen van gegevens het lezen alleen daarin plaatsvond.<\/b>PG10: de eerste poging.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Maar partitioneren via overerving was historisch gezien niet goed aangepast voor actief schrijfverkeer of een groot aantal kindsegmenten. Bijvoorbeeld, je kunt je herinneren dat het algoritme voor het kiezen van het juiste segment had<\/h4>\n<p>\nkwadratische complexiteit, <b>wat met 100+ segmenten, je begrijpt hoe dat werkt...<\/b>In PG10 is deze situatie sterk geoptimaliseerd, met de implementatie van ondersteuning voor<\/p>\n<p>native partitionering. <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgresql\/10\/ddl-partitioning\">native partitionering.<\/a><\/noindex>Dus hebben we het meteen geprobeerd toe te passen na de migratie van de opslag, maar...<\/p>\n<p>Zoals bleek na het doorlezen van de handleiding, ondersteunt de natively partitioned tabel in deze versie:<\/p>\n<ul>\n<li>geen indexbeschrijvingen<\/li>\n<li>ondersteunt geen triggers<\/li>\n<li>kan zelf niets zijn 'afkomstig van'<\/li>\n<li>ondersteunt niet <code>INSERT ... ON CONFLICT<\/code><\/li>\n<li>kan sectie niet automatisch genereren<\/li>\n<\/ul>\n<p>\nNa een flinke klap op ons hoofd met de hark, beseften we dat we niet zonder modificatie van de applicatie verder konden, en stelden we ons onderzoek zes maanden uit.<\/p>\n<h4>PG10: een tweede kans<\/h4>\n<p>\nDus we begonnen de opkomende problemen een voor een op te lossen:<\/p>\n<ol>\n<li>Aangezien triggers en <code>ON CONFLICT<\/code> toch ergens nodig waren, maakten we een tussentijdse <b>proxy-tabel<\/b>.<\/li>\n<li><b>We hebben de 'routering' in de triggers verwijderd - dat wil zeggen de<\/b> We hebben apart <code>EXECUTE<\/code>.<\/li>\n<li>een sjabloontabel met alle indexen gemaakt <b>, zodat ze zelfs niet op de proxy-tabel aanwezig waren.<\/b>Uiteindelijk, na dit alles, hebben we de hoofdtafel natively gepartitioneerd. Het aanmaken van een nieuwe sectie bleef voorlopig de verantwoordelijkheid van de applicatie.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/db3118798357575568489f6b575373b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nWe 'snijden' woordenlijsten<\/p>\n<h4>Zoals in elk analytisch systeem, hadden wij ook<\/h4>\n<p>\nfeiten en dimensies <b>(woordenlijsten). In ons geval fungeerden bijvoorbeeld<\/b> het lichaam van de 'sjabloon' <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/5XKbFb-l5Do?t=2487\">homogene langzame verzoeken of de tekst van de verzoek zelf.<\/a><\/noindex> We hadden de 'feiten' al lang op dagen gepartitioneerd, dus konden we verouderde secties rustig verwijderen, ze hebben ons niet gestoord (de logs!). Maar met de woordenlijsten liep het anders...<\/p>\n<p>Het is niet zo dat er heel veel waren, maar ongeveer<\/p>\n<p>op 100TB 'feiten' kreeg je een woordenlijst van 2.5TB. <b>Van zo'n tabel is het moeilijk om iets te verwijderen, niets kan je in een redelijke tijd comprimeren, en het schrijven daarin werd geleidelijk steeds langzamer.<\/b>Het lijkt een woordenlijst... elke opname moet precies \u00e9\u00e9n keer worden gepresenteerd... en dat is correct, maar!.. Niemand weerhoudt ons ervan<\/p>\n<p>om een aparte woordenlijst voor elke dag te hebben! <b>Ja, dat brengt bepaalde overbodigheid met zich mee, maar het maakt het mogelijk om:<\/b>sneller te schrijven\/lezen<\/p>\n<ul>\n<li><b>door de kleinere grootte van de sectie<\/b> minder geheugen te verbruiken<\/li>\n<li><b>door te werken met compactere indexen<\/b> minder gegevens op te slaan<\/li>\n<li><b>door de mogelijkheid om snel verouderde<\/b> Als resultaat van alles wat we hebben gedaan,<\/li>\n<\/ul>\n<p>\nis de CPU-belasting met ~30% verminderd, de schijfbelasting met ~50% <b>Bij dit alles hebben we nog steeds precies hetzelfde in de database geschreven, alleen met een lagere belasting.<\/b>:<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/fd3a219a304dc46173a7eb435502fe02.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTegelijkertijd hebben we exact hetzelfde in de database geschreven, maar met een lagere belasting.<\/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>\nDus, we waren gebleven bij het feit dat we <b>voor elke dag een sectie hebben<\/b> met gegevens. Eigenlijk, <code>CHECK (dt = '2018-10-12'::date)<\/code> \u2014 en dat is de sleutel voor partitionering en de voorwaarde voor opname van een record in een specifieke sectie.<\/p>\n<p>Aangezien alle rapporten in onze service worden gebouwd op basis van een specifieke datum, waren de indexen uit de \"niet-gepartitioneerde tijden\" ook allemaal van het type <i>(Server, <b>Datum<\/b>, Sjabloon plan)<\/i>, <i>(Server, <b>Datum<\/b>, Knoop plan)<\/i>, <i>(<b>Datum<\/b>, Foutklasse, Server)<\/i>,\u2026<\/p>\n<p>Maar nu hebben elke secties hun eigen <u>exemplaren<\/u> van elke dergelijke index... En binnen elke sectie <u>is de datum een constante<\/u>... Het blijkt dat we nu in elke dergelijke index <b>simpelweg de constante opnemen<\/b> als een van de velden, wat zowel het volume als de zoektijd vergroot, maar geen resultaat oplevert. We hebben onszelf op de vingers getikt, oeps...<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/c7644644b960c568c4adaeec57cfef2d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDe richting van optimalisatie is duidelijk - gewoon <b>verwijder het dataveld uit alle indexen<\/b> in gepartitioneerde tabellen. Bij onze volumes is de winst ongeveer <b>1TB\/week<\/b>!<\/p>\n<p>En laten we nu opmerken dat deze terabyte ook ergens moet worden opgeslagen. Dat wil zeggen, we moeten de <b>schijf nu minder belasten<\/b>! Op deze afbeelding is het effect van de uitgevoerde reiniging, waar we een week aan hebben besteed, goed te zien:<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 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>\nEen van de grote problemen van drukbelaste systemen is <b>overmatige synchronisatie<\/b> van bepaalde operaties die dat niet vereisen. Soms \"omdat we het niet opgemerkt hebben\", soms \"omdat het makkelijker was\", maar vroeg of laat moet je ervan af.<\/p>\n<p>We benaderen de vorige afbeelding - en zien dat de schijf ons <b>\"beweegt\" met een dubbele amplitudo belasting<\/b> tussen naburige metingen, wat statistisch gezien niet zou moeten zijn bij zo'n aantal bewerkingen:<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/ac3f19213cba0f111864c6dbf9a73912.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDit is vrij eenvoudig te bereiken. We hadden al bijna <b>1000 servers gemonitord,<\/b>elke wordt verwerkt door een aparte logische stroom, en elke stroom verplaatst de verzamelde informatie voor verzending naar de database met een bepaalde periodiciteit, ongeveer zo:<\/p>\n<pre><code class=\"javascript\">setInterval(sendToDB, interval)<\/code><\/pre>\n<p>\nHet probleem ligt precies in het feit dat <b>alle stromen ongeveer tegelijkertijd starten,<\/b>waardoor hun verzendmomenten bijna altijd \"samenvallen tot het punt\". Oeps nummer 2...<\/p>\n<p>Gelukkig kan dit vrij eenvoudig worden opgelost, <b>door een \"willekeurige\" tijdsverschuiving toe te voegen:<\/b> setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))<\/p>\n<pre><code class=\"javascript\">Het derde traditionele probleem van highload is<\/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>\nhet ontbreken van cache <b>waar dat<\/b> moet zijn. <i>zou kunnen<\/i> zijn.<\/p>\n<p>Bijvoorbeeld, we hebben de mogelijkheid gecre\u00eberd om analyses per knoop van het plan uit te voeren (al deze <code>Seq Scan op gebruikers<\/code>), maar meteen denken dat ze, in de massa, gelijk zijn \u2014 dat zijn ze vergeten.<\/p>\n<p>Nee, natuurlijk worden er geen gegevens opnieuw in de database geschreven, dat schakelt de trigger uit met <code>INSERT ... ON CONFLICT DO NOTHING<\/code>. Maar deze gegevens komen toch in de database terecht, en dat zorgt voor overbodige <b>leesoperaties voor het controleren van conflicten<\/b> die moeten plaatsvinden. Oeps nummer 3\u2026<\/p>\n<p>Het verschil in het aantal records dat naar de database wordt verzonden voor\/na het inschakelen van caching is duidelijk:<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/37fa7e64a674f03a79f2765a79ec8138.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn dit is \u2014 de bijbehorende afname van de belasting op de opslag:<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/b2c563b4b41755211e77768d80f8702f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Total<\/h2>\n<p>\n\u2018Terabyte-per-dag\u2019 klinkt alleen nogal angstaanjagend. Als je alles goed doet, is dat slechts <b>2^40 bytes \/ 86400 seconden = ~12.5MB\/s<\/b>, wat de desktop IDE-schijven zelfs konden bijhouden. \ud83d\ude42<\/p>\n<p>En als het serieus is, zelfs met een tienvoudige \u2018overbelasting\u2019 van de belasting gedurende de dag, kun je met gemak blijven binnen de mogelijkheden van moderne SSD's.<\/p>\n<p><img decoding=\"async\" alt=\"We schrijven in PostgreSQL onder lichtsnelheid: 1 host, 1 dag, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/6f3f8d4636ba50f3d5401bf4e456757f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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\udd47We schrijven in PostgreSQL op onderlicht: 1 host, 1 dag, 1TB | ProHoster","description":"Onlangs heb ik uitgelegd hoe je met behulp van standaard recepten de prestaties van \u2018read\u2019 SQL-query's kunt verhogen.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/79028","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=79028"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/79028\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/79029"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=79028"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=79028"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=79028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}