{"id":74953,"date":"2020-03-22T08:42:22","date_gmt":"2020-03-22T05:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy"},"modified":"2020-03-22T08:42:22","modified_gmt":"2020-03-22T05:42:22","slug":"dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: korraldame s\u00fcnkroniseerimisi ja importimist oskuslikult","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kui keerukalt t\u00f6\u00f6tleda suuri andmekogusid (erinevad ETL-protsessid<\/a><\/noindex>: impordid, konverteerimised ja s\u00fcnkroonimised v\u00e4lise allikaga) tekib sageli vajadus ajaliselt \"m\u00e4luda\" ja korraga kiiresti t\u00f6\u00f6delda<\/b> m\u00f5nda suurust.<\/p>\n

Selline t\u00fc\u00fcpiline \u00fclesanne k\u00f5lab tavaliselt nii: \"Siin on raamatupidamine eksportinud kliendipangast<\/a><\/noindex> viimased laekunud maksed, tuleb need kiiresti veebilehele laadida ja siduda kontodega\"<\/i><\/p>\n

Kuid kui selle \"millegi\" maht hakkab m\u00f5\u00f5tma sadade megabaidiga ja teenus peab samal ajal t\u00f6\u00f6tama andmebaasiga re\u017eiimis 24×7, siis tekib palju k\u00f5rvalm\u00f5jusid, mis rikuvad teie elu.
\n\"DBA:
\nNende vastu v\u00f5itlemiseks PostgreSQL-is (ja mitte ainult seal) saab kasutada teatavaid optsioone optimeerimiseks, mis v\u00f5imaldavad k\u00f5ike t\u00f6\u00f6tleda kiiremini ja v\u00e4iksema ressursikulu.
\n<\/a><\/noindex><\/p>\n

1. Kuhu laadida?<\/h2>\n

\nEsmalt laske meil m\u00f5ista, kuhu me saame laadida andmed, mida soovime \"t\u00f6\u00f6deldaks\".<\/p>\n

1.1. Ajutised tabelid (TEMPORARY TABLE)<\/h3>\n

\nP\u00f5him\u00f5tteliselt on ajutised tabelid PostgreSQL-is samasugused tabelid nagu k\u00f5ik teised. Seet\u00f5ttu ei ole vale uskumine, et \"seal hoitakse k\u00f5ike ainult m\u00e4lus ja see v\u00f5ib otsa saada\"<\/b><\/i>. Kuid on ka mitmeid olulisi erinevusi.<\/p>\n

Igal DB \u00fchendusel on oma \"nimetamise ruum\"<\/h4>\n

\nKui kaks \u00fchendust \u00fcritavad samal ajal k\u00e4ivitada CREATE TABLE x<\/code>, siis keegi saab kindlasti andmebaasi objektide ainulaadsuse viga.<\/b> Aga kui m\u00f5lemad \u00fcritavad k\u00e4ivitada<\/p>\n

, siis m\u00f5lemad teevad seda normaalselt ja iga\u00fcks saab CREATE AJUTINE<\/b> TABEL x<\/code>oma eksemplari tabelist. Ja neil ei ole \u00fcksteisega midagi \u00fchist.<\/b> \"Eneseh\u00e4vitamine\" sulgemisel<\/p>\n

\u00dchenduse sulgemisel kustutatakse k\u00f5ik ajutised tabelid automaatselt, seega pole \"k\u00e4si\" teostada<\/h4>\n

\nDROP TABLE x mingit m\u00f5tet, v\u00e4lja arvatud...<\/code> Kui t\u00f6\u00f6tate<\/p>\n

pgbouncer'i tehingure\u017eiimis , siis andmebaas arvab endiselt, et see \u00fchendus on endiselt aktiivne, ja selles eksisteerib see ajutine tabel endiselt.<\/b>Seega toob p\u00fc\u00fce seda uuesti luua, juba teise \u00fchenduse kaudu pgbouncerile, kaasa vea. Kuid seda saab v\u00e4ltida, kasutades<\/p>\n

Kuid parem on seda ikkagi mitte teha, sest siis v\u00f5ite \"ootamatult\" avastada seal \"eelmistest omanikest\" j\u00e4\u00e4ne andmed. Selle asemel on palju parem lugeda juhendit ja n\u00e4ha, et tabeli loomisel on v\u00f5imalus juurde kirjutada LOO TEMPORARY TABLE KUI EI OLE<\/b> x<\/code>.<\/p>\n

T\u00f5epoolest, parem on seda mitte teha, kuna siis v\u00f5ib \"\u00fcht\u00e4kki\" avastada seal endiselt olemasolevaid andmeid \"eelmiselt omanikult\". Selle asemel on palju parem lugeda manuaali ja n\u00e4ha, et tabeli loomisel on v\u00f5imalus t\u00e4iendavaid andmeid sisestada. REKISTERIMISES DROP<\/b><\/code> \u2014 see, when the transaction is completed, the table will be automatically deleted.<\/p>\n

Non-replication<\/h4>\n

\nDue to being assigned to a specific connection only, temporary tables are not replicated. However, this eliminates the need for double data writing<\/b> in heap + WAL, hence INSERT\/UPDATE\/DELETE into it is significantly faster.<\/p>\n

But since a temporary table is still \"almost a regular\" table, it can't be created on a replica either. At least, not yet, although the corresponding patch has been around for a long time.<\/p>\n

1.2. Unlogged tables (UNLOGGED TABLE)<\/h3>\n

\nBut what if, for example, you have some bulky ETL process that can't be implemented within a single transaction, and you indeed , siis andmebaas arvab endiselt, et see \u00fchendus on endiselt aktiivne, ja selles eksisteerib see ajutine tabel endiselt.<\/b>?..<\/p>\n

Or the data stream is so large that the bandwidth of a single connection<\/b> to the DB (read, one process on the CPU)?..<\/p>\n

Or part of the operations go asynchronously<\/b> in different connections?..<\/p>\n

In this case, there is only one option \u2014 temporarily create a non-temporary table<\/b>. A pun, indeed. That is:<\/p>\n