{"id":370,"date":"2008-04-03T08:23:40","date_gmt":"2008-04-03T07:23:40","guid":{"rendered":"http:\/\/soci.hu\/blog\/?p=370"},"modified":"2008-04-04T10:11:43","modified_gmt":"2008-04-04T09:11:43","slug":"sql-server-2008-ujdonsagok-30-adatlapok-tomoritett-tarolasa","status":"publish","type":"post","link":"https:\/\/soci.hu\/blog\/index.php\/2008\/04\/03\/sql-server-2008-ujdonsagok-30-adatlapok-tomoritett-tarolasa\/","title":{"rendered":"SQL Server 2008 \u00fajdons\u00e1gok 30. – Adatlapok t\u00f6m\u00f6r\u00edtett t\u00e1rol\u00e1sa I."},"content":{"rendered":"

A 2008-ban az egyik leghangs\u00falyosabban fejlesztett scenario az adatt\u00e1rh\u00e1zak \u00e9p\u00edt\u00e9se \u00e9s kezel\u00e9se.
\nGondoljunk csak az insert minim\u00e1l loggingol\u00f3sra fejleszt\u00e9s\u00e9re, a sz\u00f3 lesz majd a star joinok bitmap filter alap\u00fa optimaliz\u00e1l\u00e1s\u00e1r\u00f3l (egy k\u00e9s\u0151bbi bejegyz\u00e9sben), a particion\u00e1lt adatok p\u00e1rhuzamos feldolgoz\u00e1s\u00e1r\u00f3l, az indexelt n\u00e9zetek, amelyek t\u00e1bl\u00e1i \u00e1llhatnak particion\u00e1lt l\u00e1bakon, a merge utas\u00edt\u00e1s, ami gyors adat\u00e1tlap\u00e1tol\u00e1st tesz lehet\u0151v\u00e9, Change Data Capture, stb. Er\u0151sen Data Warehouse szag\u00faak a f\u00edcs\u00f6r\u00f6k, nemde?
\nNo, ezen a vonalon dombor\u00edt a t\u00f6m\u00f6r\u00edt\u00e9s is. Az SQL 2005 SP2<\/a> m\u00e1r bevezette a vardecimal t\u00f6m\u00f6r\u00edtett t\u00e1rol\u00e1s\u00e1t, amely nem fix hossz\u00fas\u00e1gon t\u00e1rolja ezeket a sz\u00e1mokat, csak olyan hosszan, amennyi az adott p\u00e9ld\u00e1ny t\u00e9nyleges t\u00e1rol\u00e1s\u00e1hoz kell. P\u00e9ld\u00e1ul a 2.23 kevesebb helyet k\u00e9r, mint a 2234234.23 vagy a 3.345353535345. V\u00e1ltoz\u00f3 hossz\u00fas\u00e1ggal \u00e1br\u00e1zolj\u00e1k teh\u00e1t az egy\u00e9bk\u00e9nt fix hossz\u00fas\u00e1g\u00fa decimal adatot, ezzel helyet sp\u00f3rolnak meg. Gondolom nem kell mondanom, mi\u00e9rt pont ezt a t\u00edpust rakt\u00e1k be az SP2-be, az\u00e9rt, mert a p\u00e9nzmennyis\u00e9geket ebben szoktuk t\u00e1rolni (nem kettes, hanem 10-es sz\u00e1mrendszer alap\u00fa, ez\u00e9rt v\u00e9ges tizedes t\u00f6rteket pontosan tud \u00e1br\u00e1zolni, szembem mondjuk a real-lel, ami 2-es sz\u00e1mrendszer alap\u00fa).
\nAz SQL Server 2008 nyilv\u00e1n ezen a vonalon ment tov\u00e1bb, \u00e9s m\u00e1r nem csak a decimalt, hanem a t\u00f6bbi fix hossz\u00fas\u00e1g\u00fa sz\u00e1mot is tudja v\u00e1ltoz\u00f3 hosszal, azaz t\u00f6m\u00f6r\u00edtve t\u00e1rolni.
\nMiel\u0151tt azoban megbesz\u00e9ln\u00e9nk az \u00f6sszes t\u00f6m\u00f6r\u00edt\u00e9se m\u00f3dszert, n\u00e9zz\u00fck, mi\u00e9rt is j\u00f3 ez nek\u00fcnk? A compression els\u0151dleges c\u00e9lja a nagy t\u00e1bl\u00e1k adatainak t\u00f6m\u00f6r\u00edt\u00e9se, egyszer\u0171en a HDD-k jobb kihaszn\u00e1l\u00e1sa \u00e9rdek\u00e9ben. Azonban mivel \u00edgy kevesebb IO m\u0171velettel j\u00e1rnak a lek\u00e9rdez\u00e9sek, a v\u00e9g\u00e9n m\u00e9g lehet – de nem biztos – hogy gyorsabbak lesznek a lek\u00e9rdez\u00e9sek. Az adatm\u00f3dos\u00edt\u00e1sok nyilv\u00e1n lassulnak. Ez\u00e9rt els\u0151sorban k\u00f6zel csak olvashat\u00f3 adatokra \u00e9rdemes haszn\u00e1lni. Nincs dr\u00e1ma a m\u00f3dos\u00edt\u00e1sn\u00e1l, de p\u00e1r 10%-kal lassabb lehet. A backup gyorsul, hisz kevesebb adatot kell kim\u00e1solni. A backup is tud t\u00f6m\u00f6r\u00edteni 2008-ban, a kett\u0151 egym\u00e1st\u00f3l f\u00fcggetlen, \u00e9s haszn\u00e1lhat\u00f3 egy\u00fctt.
\nMivel t\u00f6m\u00f6rebbek az adatlapok, jobban kihaszn\u00e1lhat\u00f3 a g\u00e9p mem\u00f3ri\u00e1ja cache c\u00e9lj\u00e1ra, azaz egy 2x t\u00f6m\u00f6r\u00edt\u00e9s hasonl\u00f3 hat\u00e1s\u00fa, mintha dupla annyi ramunk lenne cache c\u00e9lj\u00e1ra. Az\u00e9rt ez sem elhanyagoland\u00f3 adat.
\nLehet t\u00f6m\u00f6r\u00edteni adatot, indexet \u00e9s ak\u00e1r egy t\u00e1bla vagy index bizonyos part\u00edci\u00f3it is. Ez ut\u00f3bbi nagyon j\u00f3, mert \u00edgy az arch\u00edv adatokat lehet t\u00f6m\u00f6r\u00edtve t\u00e1rolni r\u00e9gebbi part\u00edci\u00f3kban, m\u00edg az \u00e9ppen t\u00f6lt\u00f6tt adatokat t\u00f6m\u00f6r\u00edt\u00e9s n\u00e9lk\u00fcl, hogy ne lassuljanak a DML m\u0171veletek.
\nHogyan t\u00f6m\u00f6r\u00edt az SQL Server 2008? Az\u00e9rt azt l\u00e1tni kell, hogy nem lehet egy zipet vagy egy rart berakni a szerverbe, mert b\u00e1r az val\u00f3sz\u00edn\u0171leg nagyobb t\u00f6m\u00f6r\u00edt\u00e9si ar\u00e1nyt \u00e9rne el, de sokkal lassabb lenne t\u0151le a szerver. Olyan t\u00f6m\u00f6r\u00edt\u00e9s kellett, ami el\u00e9g sokat t\u00f6m\u00f6r\u00edt, de nem t\u00fal nagy k\u00f6lts\u00e9ggel. Biztos sokf\u00e9le m\u00f3dszert implement\u00e1ltak \u00e9s teszteltek, \u00e9rdekes feladat lehetett.<\/p>\n

Egyf\u00e9le technik\u00e1r\u00f3l b\u00e1r besz\u00e9ltem, a fix adatok v\u00e1ltoz\u00f3 hossz\u00fas\u00e1g\u00fa enk\u00f3dol\u00e1s\u00e1r\u00f3l. Ez m\u0171k\u00f6dik a sz\u00e1mokra \u00e9s a char, nchar t\u00edpusra. K\u00edv\u00fclr\u0151l persze ez nem l\u00e1tszik, az int tov\u00e1bbra is 4 bytenak l\u00e1tszik, annak ellen\u00e9re, hogy bel\u00fcl lehet, hogy csak 1.5 byte. Row compression n\u00e9ven \u00e9rhet\u0151 el ez a t\u00f6m\u00f6r\u00edt\u00e9s.<\/p>\n

F\u0151leg sz\u00f6veges adatok eset\u00e9n azonban ez a m\u00f3dszer nem tudna nyeres\u00e9get adni, maximum ostob\u00e1n megszerkesztett hossz\u00fa char, nchar oszlopokn\u00e1l, de van annyi esz\u00fcnk, hogy v\u00e1ltoz\u00f3 hossz\u00fas\u00e1g\u00fa adatokat Nvarchar \u00e9s t\u00e1rsaiban t\u00e1rolunk. M\u00e1s m\u00f3dszer kell a t\u00f6m\u00f6r\u00edt\u00e9sre, ez pedig a redundancia cs\u00f6kkent\u00e9s\u00e9vel m\u0171k\u00f6dik. Az els\u0151 m\u00f3dszer az adatok els\u0151 r\u00e9sz\u00e9ben lev\u0151 redundanci\u00e1t \u0171zi el. Pl. az \u00c1la<\/strong>d\u00e1r \u00e9s az \u00c1la<\/strong>mizsna szavakban az \u00c1la karaktereket csak egyszer \u00edrj\u00e1k le a lap fejl\u00e9c\u00e9ben modjuk 1-es index-szel, \u00e9s a mez\u0151kben csak 1d\u00e1r \u00e9s 1mizsna lesz. Ez a column-prefix t\u00f6m\u00f6r\u00edt\u00e9s. Ami izgalmas ebben, hogy a m\u00f3dszer adatt\u00edpust\u00f3l f\u00fcggetlen\u00fcl m\u0171k\u00f6dik, ha pont egy integer els\u0151 3 byte-ja azonos egy varchar sz\u00f6veg els\u0151 3 karakter\u00e9t reprezent\u00e1l\u00f3 byte-tal, akkor \u00f6sszevonj\u00e1k \u0151ket.
\nUpdate: kiss\u00e9 leegyszer\u0171s\u00edtettem itt a k\u00e9pet, de a meg\u00e9rt\u00e9shez ez el\u00e9g. Aki pontosan szeretn\u00e9 l\u00e1tni hogy m\u0171k\u00f6dik ez, itt<\/a> n\u00e9zzen sz\u00e9t.
\nA m\u00e1sik m\u00f3dszer sz\u00f3t\u00e1r alap\u00fa, azaz ha az alma sz\u00f3 egy lapon 15 sorban is szerepel b\u00e1rmely oszlopban, akkor csak egyszer t\u00e1rolj\u00e1k le, \u00e9s a sorokba mutat\u00f3kat raknak az adatsz\u00f3t\u00e1r adott bejegyz\u00e9s\u00e9re. Val\u00f3j\u00e1ban a kett\u0151 egy\u00fctt m\u0171k\u00f6dik, el\u0151sz\u00f6r a k\u00f6z\u00f6s prefixeket emelik ki, majd megn\u00e9zik a marad\u00e9kot (el\u0151z\u0151 p\u00e9ld\u00e1ban d\u00e1r, mizsna), \u00e9s ha az is t\u00f6bbsz\u00f6r szerepel, akkor a sz\u00f3t\u00e1raz\u00f3s m\u00f3dszerrel t\u00f6m\u00f6r\u00edtik.
\nPersze ezek nem csak sz\u00f6veges, hanem bin\u00e1ris adatokra is mennek, csak \u00edgy k\u00f6nnyebb volt szeml\u00e9ltetni a folyamatot. Update: pontosabban \u00e9s r\u00e9szletesebben itt<\/a>.
\nMelyiket haszn\u00e1ljam? A row compressionnek jelent\u0151sen kisebb a k\u00f6lts\u00e9ge, ez\u00e9rt a gyakrabban lek\u00e9rdezett vagy m\u00f3dos\u00edtott adatokhoz ez megfelel\u0151bb. Cser\u00e9be nem tud annyira t\u00f6m\u00f6r\u00edteni.
\nA gyakran haszn\u00e1lt indexeket val\u00f3sz\u00edn\u0171leg nem \u00e9rdemes t\u00f6m\u00f6r\u00edteni, csak azokat, amelyek nagyok, de ritk\u00e1n haszn\u00e1latosak.
\nKis t\u00e1bl\u00e1kra k\u00e1r baszakodni b\u00e1rmelyik m\u00f3dszerrel is, csak izz\u00edtjuk vele feleslegesen a procit.
\nIndex seek-eken nem sokat jav\u00edt a t\u00f6m\u00f6r\u00edt\u00e9s, mert egy-egy sor miatt 6-8 lapot is ki kell csomagolni, ami felesleges macera. Range seek-ekre vagy index scan-ekre m\u00e1r meg\u00e9ri.
\nA sys.dm_db_index_operational_stats n\u00e9zet megmutatja, melyik index mennyire \u00e9s milyen m\u00f3don van kihaszn\u00e1lva (\u00f3, ha ez meg lett volna m\u00e1r az SQL 2000-ben!)?
\nA nagy adatokra, mint varchar(max) \u00e9s t\u00e1rsai NEM m\u0171k\u00f6dik a t\u00f6m\u00f6r\u00edt\u00e9s, hisz az el\u0151bb le\u00edrt m\u00f3dszerek nyilv\u00e1nval\u00f3an nem mennek nagy adatokra, ezeket ink\u00e1bb a hagyom\u00e1nyos stream alap\u00fa t\u00f6m\u00f6r\u00edt\u00e9sekkel lehet \u00f6sszepakolni. Mit lehet tenni, ha ezeket is t\u00f6m\u00f6r\u00edteni akarjuk?
\n1. Az alkalmaz\u00e1s maga t\u00f6m\u00f6r\u00edt. A mai vil\u00e1gban ez m\u00e1r nem nagy dolog.
\n2. T\u00f6m\u00f6r\u00edt\u0151 CLR UDF-et \u00edrunk, azzal t\u00f6m\u00f6r\u00edt\u00fcnk a t\u00e1rol\u00e1s el\u0151tt, mondjuk egy sp-ben.
\n3. Olyan UDT-t \u00edrunk, ami t\u00f6m\u00f6r\u00edtve t\u00e1rol. A m\u00e9retlimit felold\u00e1sa miatt<\/a> ez most m\u00e1r lehets\u00e9ges.
\n4. FILESTREAM<\/a> oszlopot haszn\u00e1lunk t\u00f6m\u00f6r\u00edtett NTFS k\u00f6nyvt\u00e1rban. Ez nem t\u00f6m\u00f6r\u00edt olyan agressz\u00edven, de el\u00e9g gyors.<\/p>\n

Ok, r\u00e1j\u00f6tt\u00fcnk, hogy lehet, hogy kell nek\u00fcnk a t\u00f6m\u00f6r\u00edt\u00e9s. Miel\u0151tt bezipeln\u00e9nk az univerzumot \u00e9rdemes kicsit m\u00e9ricsk\u00e9lni, mit v\u00e1rhatunk el t\u0151le, hisz az adatainkt\u00f3l nagyban f\u00fcgg, mekkor lesz a nyeres\u00e9g, ha egy\u00e1ltal\u00e1n lesz? El\u0151sz\u00f6r is, a t\u00e1bla indul\u00f3 m\u00e9ret\u00e9t az sp_spaceused spvel lehet megkapni.
\nEzt\u00e1n az sp_estimate_data_compression_savings t\u00e1rolt elj\u00e1r\u00e1ssal ki lehet pr\u00f3b\u00e1ltatni, hogy egy adott t\u00e1bla vagy index egy adott part\u00edci\u00f3j\u00e1n a row vagy page compression mennyit hozna a konyh\u00e1ra. Az sp persze nem \u00e1ll neki a 80 Exab\u00e1jtos t\u00e1bl\u00e1t bet\u00f6m\u00f6r\u00edteni, hanem mintav\u00e9telez\u00e9ssel csin\u00e1l egy kis minta t\u00e1bl\u00e1t a tempdbben, \u00e9s azt csomagolgatja, majd ennek eredm\u00e9ny\u00e9t vet\u00edti vissza az eredeti t\u00e1bl\u00e1ra.
\nM\u00e9ricsk\u00e9lj\u00fcnk kicsit! (Majd egy hamarosan k\u00f6vetkez\u0151 r\u00e9szben, mert elpukkant a laptopban a viny\u00f3, \u00edgy nincs k\u00e9zn\u00e9l szerverem).<\/p>\n","protected":false},"excerpt":{"rendered":"

A 2008-ban az egyik leghangs\u00falyosabban fejlesztett scenario az adatt\u00e1rh\u00e1zak \u00e9p\u00edt\u00e9se \u00e9s kezel\u00e9se. Gondoljunk csak az insert minim\u00e1l loggingol\u00f3sra fejleszt\u00e9s\u00e9re, a sz\u00f3 lesz…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,4,30,58],"tags":[],"class_list":["post-370","post","type-post","status-publish","format-standard","hentry","category-adatbazisok","category-szakmai-elet","category-sql-server","category-sql-server-2008"],"_links":{"self":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/370","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=370"}],"version-history":[{"count":0,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/370\/revisions"}],"wp:attachment":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=370"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=370"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}