{"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\/en\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","title":{"rendered":"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Recently, I discussed how to use standard recipes <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/tensor\/blog\/492694\/\">to improve the performance of SQL queries \u2018for reading\u2019<\/a><\/noindex> from a PostgreSQL database. Today, we will talk about how <b>to make data writes<\/b> to the database more efficient without using any 'knobs' in the config \u2014 simply by properly organizing data streams.<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 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>\nThis article discusses how and why it is worth organizing <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/483170\/\">application partitioning 'in theory'<\/a><\/noindex> has already been covered, here we will discuss the practical application of some approaches within our <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/487380\/\">monitoring service for hundreds of PostgreSQL servers<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>\"Long ago, in days gone by...\"<\/h4>\n<p>\nInitially, like any MVP, our project started under quite a small load \u2014 monitoring was only conducted for a handful of the most critical servers, all tables were relatively compact\u2026 But as time went on, the number of monitored hosts increased significantly, and when we tried once more to do something with one of the <b>tables sized at 1.5TB<\/b>, we realized that continuing like this was possible but rather inconvenient.<\/p>\n<p>The times were almost legendary, various versions of PostgreSQL 9.x were relevant, so all partitioning had to be done 'manually' \u2014 through <b>table inheritance and triggers<\/b> with dynamic <code>EXECUTE<\/code>.<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/a480e75ccec73080aa2d0be1435d2a2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nThe resulting solution turned out to be sufficiently universal that it could be translated across all tables:<\/p>\n<ul>\n<li>An empty 'header' parent table was declared, where all the <b>necessary indexes and triggers were described<\/b>.<\/li>\n<li>Client-side writes were made to the 'root' table, and internally, using the <b>routing trigger<\/b> <code>BEFORE INSERT<\/code> the entry was \"physically\" inserted into the required section. If it didn't exist yet, we caught the exception and...<\/li>\n<li>\u2026 using <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/492464\/\"><code>CREATE TABLE ... (LIKE ... INCLUDING ...)<\/code><\/a><\/noindex> a section was created based on the parent table's template <b>with a restriction on the required date<\/b>, so that during data retrieval, reading would only occur within that section.<\/li>\n<\/ul>\n<p><\/p>\n<h4>PG10: the first attempt<\/h4>\n<p>\nHowever, partitioning through inheritance was historically not very well suited for working with an active write stream or a large number of descendant sections. For example, it\u2019s worth recalling that the algorithm for choosing the appropriate section had <b>quadratic complexity<\/b>, which, with 100+ sections, you can imagine how it works\u2026<\/p>\n<p>In PG10, this situation was significantly optimized by implementing support for <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgresql\/10\/ddl-partitioning\">native partitioning<\/a><\/noindex>. Therefore, we immediately tried to apply it right after migrating the storage, but\u2026<\/p>\n<p>As it turned out after sifting through the manual, a natively partitioned table in this version:<\/p>\n<ul>\n<li>does not support index descriptions<\/li>\n<li>does not support triggers on it<\/li>\n<li>cannot be a 'descendant' of anything<\/li>\n<li>does not support <code>INSERT ... ON CONFLICT<\/code><\/li>\n<li>cannot generate partitions automatically<\/li>\n<\/ul>\n<p>\nAfter getting hit by the rake, we realized that there was no way to avoid modifying the application, and we postponed further research for six months.<\/p>\n<h4>PG10: a second chance<\/h4>\n<p>\nSo, we began to tackle the arising issues one by one:<\/p>\n<ol>\n<li>Since triggers and <code>ON CONFLICT<\/code> turned out to be necessary in some cases, we created an intermediate <b>proxy table<\/b>.<\/li>\n<li><b>We eliminated 'routing'<\/b> in the triggers \u2014 that is, from <code>EXECUTE<\/code>.<\/li>\n<li>We separated out <b>a template table with all the indexes<\/b>, so that they would not even be present in the proxy table.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/db3118798357575568489f6b575373b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nFinally, after all this, we natively partitioned the main table. Creating a new partition still remained the application's responsibility.<\/p>\n<h4>We are 'developing' dictionaries<\/h4>\n<p>\nAs in any analytical system, we also had <b>'facts' and 'dimensions'<\/b> (dictionaries). In our case, these included, for example, <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/5XKbFb-l5Do?t=2487\">the body of the 'template'<\/a><\/noindex> of uniform slow queries or the text of the query itself.<\/p>\n<p>'Facts' had been partitioned by days for a long time, so we could safely delete outdated partitions, and they did not bother us (after all, logs!). However, we ran into trouble with the dictionaries...<\/p>\n<p>It wouldn't be correct to say that there were very many, but for about <b>100TB of 'facts', there was a dictionary of 2.5TB<\/b>. You can't easily delete or compress anything from such a table in a reasonable time, and writing to it gradually became slower.<\/p>\n<p>It seems like a dictionary\u2026 each entry should be represented exactly once\u2026 and that's correct, but!.. No one prevents us from having <b>a separate dictionary for each day<\/b>! Yes, this brings some redundancy, but it allows us to:<\/p>\n<ul>\n<li><b>write\/read faster<\/b> due to the smaller size of the partition<\/li>\n<li><b>consume less memory<\/b> by working with more compact indexes<\/li>\n<li><b>store less data<\/b> thanks to the ability to quickly delete outdated<\/li>\n<\/ul>\n<p>\nAs a result of the entire set of measures <b>CPU load decreased by ~30%, and disk load by ~50%<\/b>:<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/fd3a219a304dc46173a7eb435502fe02.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nWe continued to write to the database the same way, just with less load.<\/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>\nSo, we concluded that we have <b>a section for each day<\/b> of data. In fact, <code>CHECK (dt = '2018-10-12'::date)<\/code> is the partitioning key and the condition for a record to fall into a specific section.<\/p>\n<p>Since all reports in our service are built based on a specific date, the indexes from the \"non-partitioned times\" were all of the type <i>(Server, <b>Date<\/b>, Plan Template)<\/i>, <i>(Server, <b>Date<\/b>, Plan Node)<\/i>, <i>(<b>Date<\/b>, Error Class, Server)<\/i>,\u2026<\/p>\n<p>But now each section hosts <u>its instances<\/u> of each such index\u2026 And within each section <u>the date is a constant<\/u>\u2026 It turns out that now we simply write the constant <b>as one of the fields in each such index, which increases both its size and the search time for it, but brings no result. We left ourselves a headache, oops\u2026<\/b> The direction for optimization is clear \u2014 just<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/c7644644b960c568c4adaeec57cfef2d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nremove the date field from all indexes <b>on partitioned tables. With our volumes, the gain is about<\/b> 1TB\/week <b>And now let\u2019s notice that this terabyte still had to be somehow written down. That is, we now also need to load the<\/b>!<\/p>\n<p>disk less <b>! This picture clearly shows the effect obtained from the cleanup we dedicated a week to:<\/b>One of the major problems of overloaded systems is<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 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>\nexcessive synchronization <b>of unnecessary operations. Sometimes \"because we didn\u2019t notice\", sometimes \"it was easier that way\", but sooner or later we have to get rid of it.<\/b> Zooming in on the previous picture - and we see that our disk<\/p>\n<p>\"loads\" with double amplitude <b>between adjacent readings, which definitely should not happen \"statistically\" with that many operations:<\/b> Achieving this is fairly simple. We had nearly<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/ac3f19213cba0f111864c6dbf9a73912.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n1000 servers <b>, each processed by a separate logical thread, and each thread dumps the accumulated information to send to the database at certain intervals, like this:<\/b>setInterval(sendToDB, interval)<\/p>\n<pre><code class=\"javascript\">The problem lies exactly in the fact that<\/code><\/pre>\n<p>\nall threads start at about the same time <b>, so their sending moments almost always coincide \"down to the point\". Oops \u21162\u2026<\/b>Fortunately, this can be fixed quite easily,<\/p>\n<p>by adding a \"random\" offset. <b>by adding a \"random\" offset<\/b> by time:<\/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>\nThe third traditional highload problem is <b>lack of cache<\/b> where it <i>could<\/i> be.<\/p>\n<p>For example, we made it possible to analyze by the nodes of the plan (all these <code>Seq Scan on users<\/code>), but to assume right away that they are all the same in bulk is a mistake.<\/p>\n<p>No, of course, nothing is written to the database again; the trigger prevents that with <code>INSERT ... ON CONFLICT DO NOTHING<\/code>. But still, this data reaches the database, and unnecessary <b>reads for conflict checking<\/b> have to be performed. Oops #3\u2026<\/p>\n<p>The difference in the number of records sent to the database before\/after enabling caching is obvious:<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/37fa7e64a674f03a79f2765a79ec8138.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAnd this is the accompanying drop in the load on the storage:<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 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\"Terabytes-per-day\" sounds scary. If you do everything correctly, it's just <b>2^40 bytes \/ 86400 seconds = ~12.5MB\/s<\/b>, which was manageable even for desktop IDE drives. \ud83d\ude42<\/p>\n<p>And seriously, even with a tenfold overload throughout the day, you can easily stay within the capabilities of modern SSDs.<\/p>\n<p><img decoding=\"async\" alt=\"Writing in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB\" src=\"\/wp-content\/uploads\/2020\/04\/6f3f8d4636ba50f3d5401bf4e456757f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Source: <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\/en\/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=\"en_US\" \/>\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\/en\/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 write in PostgreSQL at sub-light speed: 1 host, 1 day, 1TB | ProHoster","description":"Recently, I explained how to increase the performance of SQL \"read\" queries using standard recipes.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/pishem-v-postgresql-na-subsvetovoj-1-host-1-day-1tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/79028","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=79028"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/79028\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/79029"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=79028"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=79028"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=79028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}