Egy kis esti adatbázis-kezelés

By JoeP 

Ha már a DAG-gal foglalkozunk, nem mehetünk el egy másik nagyívű változtatás mellett.

Az Exchange 2010-nek igen durván átírták az adatbázisok kezelését végző részét. Illetve magukat az adatbázisokat.

Kezdték ott, hogy megváltoztatták az adatbázisok sémáját. Korábban egy postafiók adatait több adatbázisból kellett összeszedegetni. (Nem, nem több edb-re kell gondolni. Az edb fájl az egy nagy bináris blob, amin belül további kis adatbázisok találhatók.) A sémaváltozás lényege, hogy immár egy postafiók összes adata egy belső adatbázisban található. Ezzel két dolgot értek el: egyrészt kinyírták a SIS-t, másrészt begyorsították az adatbázis-kezelést.
Tudni kell, hogy a SIS (Single Instance Storage) trónja már a 2007-es Exchange szervernél is erősen ingott. Arról van ugye szó, hogy ha küldök egy levelet 10 embernek, akkor a levelet az adatbázisban csak egy példányban tároljuk, ahová az egyes postafiókokból pointerek mutatnak. Exchange 2007 alatt ez már csak a csatolásokra volt igaz - a 2010-nél pedig még azokra sem.
Mit nyertünk vele? Sebességet. Az Exchange fejlesztői már korábban is határozottan jelezték, hogy a sebesség vs tárhely optimalizálás vitában a sebességre szavaznak.

Hogyan lesz ebbÅ‘l sebességnövekedés? Az Exchange 2010 öszes adatbázis-kezelésre vonatkozó átalakítás mögött egy elv húzódott: a sok apró adatművelet helyett kevés, nagyobb adatterületet mozgató műveletek legyenek. A magyarázat roppant egyszerű: a sok kis műveletnél a fej össze-vissza ugrál a lemezen, míg a kevés, nagy műveleteknél sorfolytonosan tudunk dolgozni. Arról nem is beszélve, hogy az IO műveleteket adminisztrálni kell: minél kevesebb van belÅ‘lük, annál gyorsabban megy az adatkezelés. Értelemszerűen, ha átalakítjuk a sémát úgy, hogy az összetartozó adatok egymás mellett legyenek, a page méretet 8 KB-ról 32 KB-ra növeljük… ezzel mind-mind gyorsítottunk.

Persze ha ez így van, akkor jogosan kérdezheted, hogy miért nem lépték ezt meg korábban? Nos, a nagy adatbázisdarabokat valahogy kezelni is kellett, mégpedig a memóriában. Mióta vannak nagy memóriaterületeink? A 64-bites váltás óta. Melyik az egyértelműen és szigorúan 64-bites verzió? A 2010-es.

Persze nem csak sebességnövekedésről van szó. Tavasszal olyan értékeket mondtak Redmondban, hogy fel sem írtam: biztos voltam benne, hogy az én angolom béna és félrehallottam. De azóta többször meg lett erősítve írásban is, szóval a számok valószínűleg igazak: egy szerveren 100 vagy 150 adatbázis lehet (remélhetőleg házon belül egyszer majd lefocizzák a végleges számot), egy adatbázisról 16 másolat létezhet és egy adatbázis maximális mérete 2 TB. Nyilván az ajánlott postafiókok mérete is 2-10 GB közé szór, illetve a Personal Archívé 30 GB.

Impozáns, nem?

Természetesen ehhez nem csak gyorsítani kellett az adatbázis-kezelésen, kellett hozzá más is. Például az, hogy az adatbázisok alá mehet nyugodtan az olcsó hardver. Azért egy SAN fajlagos adattárolási költségével kalkulálva ezek a méretek minden IT vezető pulzusát felgyorsítanák. És kellett még egy nagyon fontos dolog: az Online Maintenance felpiszkálása. Még a 2007-es termékben is az Online Maintenance úgy viselkedett, mint egy határozatlan szűzlány. Be kellett időzíteni, hogy mikor dolgozhat az egyes adatbázisokkal, de ha munka közben intenzív tevékenységet észlelt egy adatbázison (pl. backup), akkor szégyenlősen visszavonult. Hogy majd legközelebb. Az Exchange 2010-ben az Online Maintenance _folyamatos_ és határozott.

Sokat lehetne ezeken a számokon agyalni. Én csak egy aspektusra hívnám fel figyelmet. Azért ezek a számok elég nyomós érvek arra nézve, hogy az Exchange fejlesztők miért utálják a backup/restore folyamatokat. Belegondoltál már egy 2 TB-s adatbázis visszatöltési idejébe?

By JoeP október 27, 2009 at 20:50  Tags:   Posted in: exchange

Leave a Reply