{"id":79039,"date":"2020-04-23T19:43:26","date_gmt":"2020-04-23T17:43:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql"},"modified":"2020-04-23T19:43:26","modified_gmt":"2020-04-23T17:43:26","slug":"ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Sp\u00f3rolunk n\u00e9h\u00e1ny fill\u00e9rt nagy mennyis\u00e9gek eset\u00e9n PostgreSQL-ben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Folytatva a t\u00e9m\u00e1t a nagy adatfolyamok r\u00f6gz\u00edt\u00e9s\u00e9r\u0151l, amelyet az el\u0151z\u0151 cikk\u00fcnk a szekcion\u00e1l\u00e1sr\u00f3l eml\u00edtett<\/a><\/noindex>, ebben a cikkben megvizsg\u00e1ljuk azokat a m\u00f3dszereket, amelyekkel cs\u00f6kkenthetj\u00fck a PostgreSQL-ben t\u00e1rolt<\/b> adatok 'fizikai' m\u00e9ret\u00e9t, \u00e9s ezek hat\u00e1s\u00e1t a szerver teljes\u00edtm\u00e9ny\u00e9re.<\/p>\n

A TOAST be\u00e1ll\u00edt\u00e1sokr\u00f3l \u00e9s az adatok igaz\u00edt\u00e1s\u00e1r\u00f3l lesz sz\u00f3. . '\u00c1tlagosan' ezek a m\u00f3dszerek nem fognak t\u00fal sok er\u0151forr\u00e1st megtakar\u00edtani, de \u2014 teljesen k\u00f3dm\u00f3dos\u00edt\u00e1s n\u00e9lk\u00fcl.<\/b>Azonban tapasztalataink ezen a t\u00e9ren meglehet\u0151sen eredm\u00e9nyesek voltak, mivel szinte b\u00e1rmely monitoroz\u00e1s t\u00e1rol\u00f3ja alapvet\u0151en<\/p>\n

\"Sp\u00f3rolunk
\nt\u00f6bbnyire append-only az \u00edrt adatok szempontj\u00e1b\u00f3l. \u00c9s ha \u00e9rdekli, hogyan tudja megtan\u00edtani az adatb\u00e1zist, hogy a lemezre \u00edrjon a helyett, hogy<\/b> 200MB\/s a fel\u00e9re \u2014 k\u00e9rem, olvassa tov\u00e1bb.<\/b> Kis titkok a nagy adatok vil\u00e1g\u00e1ban
\n<\/a><\/noindex><\/p>\n

A szolg\u00e1ltat\u00e1sunk profilja<\/h2>\n

\n, rendszeresen kap sz\u00f6veges csomagokat a napl\u00f3kb\u00f3l<\/a><\/noindex>Mivel a Sbis rendszere, amelynek adatb\u00e1zisait figyelj\u00fck, egy t\u00f6bbkomponens\u0171 term\u00e9k \u00f6sszetett adatstrukt\u00far\u00e1kkal, ez\u00e9rt a lek\u00e9rdez\u00e9sek<\/b>.<\/p>\n

a maxim\u00e1lis teljes\u00edtm\u00e9ny el\u00e9r\u00e9se \u00e9rdek\u00e9ben eg\u00e9szen j\u00f3l<\/a><\/noindex>'t\u00f6bb k\u00f6tet\u0171ek' bonyolult algoritmikus logik\u00e1val . \u00cdgy a k\u00e9r\u00e9s vagy a kapott v\u00e9grehajt\u00e1si terv egyes p\u00e9ld\u00e1nyainak m\u00e9rete a hozz\u00e1nk \u00e9rkez\u0151 napl\u00f3ban '\u00e1tlagosan' meglehet\u0151sen nagy.<\/b> N\u00e9zz\u00fck meg az egyik t\u00e1bl\u00e1zat strukt\u00far\u00e1j\u00e1t, ahov\u00e1 az 'nyers' adatokat \u00edrjuk \u2014 azaz az eredeti sz\u00f6veget a napl\u00f3bejegyz\u00e9sb\u0151l: CREATE TABLE rawdata_orig(\n pack -- PK\n uuid NOT NULL\n, recno -- PK\n smallint NOT NULL\n, dt -- a szekci\u00f3 kulcsa\n date\n, data -- a legfontosabb\n text\n, PRIMARY KEY(pack, recno)\n);<\/a><\/noindex>Tipikus ilyen t\u00e1bl\u00e1zat (m\u00e1r szekcion\u00e1lva, term\u00e9szetesen, \u00edgy ez egy szekci\u00f3s sablon), ahol a legfontosabb a sz\u00f6veg. N\u00e9ha meglehet\u0151sen terjedelmes.<\/p>\n

Eml\u00e9kezz\u00fcnk, hogy a PostgreSQL-ben egy bejegyz\u00e9s 'fizikai' m\u00e9rete nem lehet t\u00f6bb egy adatoldaln\u00e1l, de a 'logikai' m\u00e9ret \u2014 eg\u00e9szen m\u00e1s dolog. A terjedelmes \u00e9rt\u00e9k ('varchar\/text\/bytea') mez\u0151be \u00edr\u00e1s\u00e1hoz a<\/p>\n

TOAST technol\u00f3gi\u00e1t haszn\u00e1ljuk.<\/code><\/pre>\n
\nTipikus ilyen t\u00e1bl\u00e1zat (m\u00e1r szekcion\u00e1lt, term\u00e9szetesen, ez\u00e9rt ez egy szekci\u00f3s sablon), ahol a legfontosabb a sz\u00f6veg. N\u00e9ha elegend\u0151 egy terjedelmesebb.<\/p>\n
Eml\u00e9kezz\u00fcnk arra, hogy a PG \u201efizikai\u201d m\u00e9rete egy rekordnak nem foglalhat el t\u00f6bbet egy adatoldaln\u00e1l, de a \u201elogikai\u201d m\u00e9ret eg\u00e9szen m\u00e1s dolog. Ahhoz, hogy egy mez\u0151be terjedelmes \u00e9rt\u00e9ket \u00edrjunk (varchar\/text\/bytea), a k\u00f6vetkez\u0151t haszn\u00e1ljuk TOAST technol\u00f3gia<\/a><\/noindex>:<\/p>\n
A PostgreSQL fix\u00e1lt m\u00e9ret\u0171 oldalt (\u00e1ltal\u00e1ban 8 KB) haszn\u00e1l, \u00e9s nem engedi meg, hogy a tuple-ok t\u00f6bb oldalt foglaljanak el. Ez\u00e9rt k\u00f6zvetlen\u00fcl nem lehet nagyon nagy mez\u0151\u00e9rt\u00e9keket t\u00e1rolni. Ennek a korl\u00e1tnak a lek\u00fczd\u00e9se \u00e9rdek\u00e9ben a nagy mez\u0151\u00e9rt\u00e9keket t\u00f6m\u00f6r\u00edtik \u00e9s\/vagy t\u00f6bb fizikai sorra osztj\u00e1k. Ez a felhaszn\u00e1l\u00f3 sz\u00e1m\u00e1ra l\u00e1thatatlanul t\u00f6rt\u00e9nik, \u00e9s a szerver k\u00f3d nagy r\u00e9sz\u00e9re csek\u00e9ly hat\u00e1ssal van. Ezt a m\u00f3dszert TOAST-nak nevezz\u00fck\u2026<\/p><\/blockquote>\n
\nVal\u00f3j\u00e1ban, minden \u201epotenci\u00e1lisan nagy\u201d mez\u0151vel rendelkez\u0151 t\u00e1bl\u00e1hoz automatikusan egy p\u00e1rhuzamos t\u00e1bla k\u00e9sz\u00fcl \u201eszeletel\u00e9ssel\u201d<\/a><\/noindex> minden \u201enagy\u201d rekord 2KB-ra bontva:<\/p>\n
TOAST(\n  chunk_id\n    integer\n, chunk_seq\n    integer\n, chunk_data\n    bytea\n, PRIMARY KEY(chunk_id, chunk_seq)\n);<\/code><\/pre>\n
\nTeh\u00e1t, ha be kell \u00edrnunk egy sort \u201enagy\u201d \u00e9rt\u00e9kkel data<\/code>, akkor a t\u00e9nyleges bejegyz\u00e9s nemcsak a f\u0151 t\u00e1bl\u00e1ba \u00e9s annak PK-j\u00e1ba, hanem a TOAST-ba \u00e9s annak PK-j\u00e1ba is megt\u00f6rt\u00e9nik. A TOAST-hat\u00e1s cs\u00f6kkent\u00e9se<\/b>.<\/p>\n
De a legt\u00f6bb rekordunk val\u00f3j\u00e1ban nem olyan nagy,<\/h4>\n
\n8KB-ba kellene f\u00e9rnie \u2014 hogyan takar\u00edthatunk meg ennyit?..<\/b> Itt j\u00f6n a seg\u00edts\u00e9g\u00fcnkre a t\u00e1bl\u00e1zat oszlop\u00e1nak<\/p>\n
STORAGE attrib\u00fatuma:<\/code><\/a><\/noindex> EXTENDED<\/p>\n
\n