Különbségek

A kiválasztott változat és az aktuális verzió közötti különbségek a következők.

--- it:postgres_user_group:cikkek:miert_ir_az_adatbazis_hogyha_olvas [2023/04/20 23:21] – [Ellenőrzőösszegek] rblst
+++ it:postgres_user_group:cikkek:miert_ir_az_adatbazis_hogyha_olvas [2023/04/20 23:53] (aktuális) – [Konklúzió] rblst
@@ Sor 1: / Sor 1: @@
 ====== Miért ír az adatbázis, hogyha csak olvasunk belőle? ======
-Első olvasatra talán ellentmondásosnak tűnik a cím, de amint e rövid írásból kiderül, a PostgreSQL lekérdezés esetén elkerülhetetlenül ír is az adatbázisba. A kiírt adatmennyiség lehet elenyésző, de lehet igen jelentős is. Nézzünk meg néhány példát.
+Első ránézésre talán ellentmondásosnak tűnik a cím, de amint e rövid írásból remélhetőleg kiderül, a lekérdezések során a PostgreSQL elkerülhetetlenül ír is az adatbázisba. A kiírt adatmennyiség általában elenyésző, de lehet igen jelentős is. Nézzünk meg néhány példát.
 ===== Klienseket kiszolgáló folyamatok =====
@@ Sor 12: / Sor 12: @@
 A klienseket kiszolgáló folyamatok (client backends) az általuk végzett olvasások végeztével statisztikát küldenek a ''statistics collector'' háttérfolyamatnak, amely összegyűjti, összegzi és tárolja azokat. A statisztikák a ''pg_stat_*'' katalógusokból kérdezhetők le. Ilyen statisztika például egy tábla teljes végigolvasásainak száma (''pg_stat_all_tables.seq_scan''), vagy index mentén történő olvasásainak száma (''pg_stat_all_tables.idx_scan'').
-Tehát a statisztikagyűjtés mindenképpen generál írási művelet, még akkor is, ha csak olvasunk az adatbázisból.
+Tehát a statisztikagyűjtés mindenképpen generál írási művelet, még akkor is, ha csak olvasunk az adatbázisból. Ezt ugyan ki lehet kapcsolni, de nem érdemes, mert a statisztikák hiánya nagyban korlátozná a PostgreSQL képességeit.
 ===== Hint bitek =====
 Az adatbázistáblák minden sorához tárolja a rendszer, hogy melyik tranzakció hozta létre, és melyik módosította az adott sort. Minden egyes sorhoz tárolódnak továbbá ún. hint bitek, amelyek azt jelzik, hogy az adott sort létrehozó vagy módosító tranzakció lezárult-e már committal vagy aborttal. Ez az információ ahhoz szükséges, hogy gyorsan lehessen ellenőrizni, hogy a létrejött vagy módosult sorok láthatók-e más tranzakciók számára.
-Ha egy táblát módosító tranzakció véget ér, ez a tény bekerül az ún. commit logba. A hint bitek által tárolt információk is a commit logból származnak. A commit logból olvasás viszont extra művelet, ezért az adatbázis az adatblokkokban is tárolja ezeket az információkat, hogy ezáltal a láthatósági ellenőrzést gyorsabban el tudja végezni.
+Ha egy tranzakció véget ér, a tranzakció státusza (commit vagy abort) bekerül az ún. commit logba. A hint bitek által tárolt információk is a commit logból származnak. A commit logból olvasás viszont extra művelet, ezért az adatbázis az adatblokkokban is tárolja ezeket az információkat, hogy ezáltal a láthatósági ellenőrzést gyorsabban tudja elvégezni.
-A hint bitek frissítése úgy történik, hogy egy módosított adatblokkokból történő első olvasás során a commit logban lévő információ beíródik az olvasott sorok hint bitjeibe is.
+A hint bitek frissítése úgy történik, hogy egy módosított adatblokkokból történő első olvasás során a commit logban lévő információ beíródik a blokkból olvasott sorok hint bitjeibe is.
 Tehát ezúttal is azzal szembesülünk, hogy noha csak olvasunk az adatbázisból, mégis ír a szerver az adatfájlokba. Igaz, csak néhány bitet, de ezáltal módosulnak az érintett adatblokkok.
@@ Sor 26: / Sor 26: @@
 Az esetleges adatkorrupció korai detektálása érdekében érdemes bekapcsolni azt a funkciót, hogy a PostgreSQL számítson ellenőrzőösszeget az egyes adatblokkokra (data checksums). A data checksums opció bekapcsolása viszont azzal is jár, hogy amikor egy checkpoint művelet után egy adatblokk először módosul, akkor beíródik a blokk teljes tartalma a WAL-ba (Write-Ahead Log, avagy tranzakciós napló, amely minden módosítást rögzít).
-Ez a naplózás megtörténik akkor is, ha csak a hint bitek változtak meg a blokkban, vagyis időközben véget ért a blokkot módosító tranzakció, hiszen a bitek megváltozása miatt is változik a blokk ellenőrző-összege.
+Ez a naplózás megtörténik akkor is, ha csak a hint bitek változtak meg a blokkban, hiszen a bitek megváltozása miatt is változik a blokk ellenőrzőösszege. Ez tehát azt jelenti, hogy minden olyan blokk első olvasása, amely a legutolsó checkpoint óta változott, WAL-fájlba írást fog eredményezni.
-Ez tehát azt jelenti, hogy minden olyan blokk első olvasása, amely a legutolsó checkpoint óta változott, WAL-ba írást fog eredményezni. Ez különösen adattárházakból történő lekérdezés esetén jelenthet komolyabb extra I/O-terhelést, hiszen noha csak olvassuk az adatbázist, a legutolsó betöltés óta most olvassuk el először a módosult blokkokat, ami tekintélyes számú írási műveletet eredményezhet.
+Különösen adattárházakból történő lekérdezés esetén jelenthet komolyabb extra I/O-terhelést ez a működés, hiszen noha csak olvassuk az adatbázist, a legutolsó betöltés óta most olvassuk el először a módosult blokkokat, ami tekintélyes számú írási műveletet eredményezhet.
+===== Konklúzió =====
+Remélem, a fenti példákkal sikerült rámutatni arra, hogy a PostgreSQL egy összetett rendszer, és a címben feltett kérdés nem is mindig érdektelen. Szívesen látunk kommentben további példákat arra, amikor az adatbázis ír is, pedig csak olvasunk belőle.