Adatmodellezés: a mesterséges kulcsok titkai

Mi az amitől minden valamire való adattárház szakértő óv minket? Mi az, amitől a jól képzett DBA-k rettegnek? Mi az adatbázis-klaszterek esküdt ellensége, a skálázhatóság mumusa, amelynek már évekkel ezelőtt el kellett volna tűnnie? Mi az, amit mégis a legtöbb adatbázisprogramozó tudatlansága vagy lustasága miatt mégis használ? Igen, ezek a szekvenciák.

Nevezhetjük bárhogyan. Oracleben sequence, postgresben serial, mysqlben auto_increment, accessben autonumber. A lényeg mindenhol ugyanaz, egy elemi, saját tranzakciós kontextussal rendelkező egyoszlopos tábláról beszélünk, amelyből mindig kiveszünk egy elemet, megnöveljük, majd visszaírjuk. Tipikusan a surrogate keyeknél használjuk őket, hogy a beszúrt soraink egyedileg azonosíthatóak legyenek. Ha azonban ilyen praktikus dolog, miért utáljuk ennyire mégis?

Gondoljuk el a következő szituációt, egy négy gépes klaszterben folyamatosan, több gépen, több szálon (praktikusan több processzor magon) írunk ugyanabba a táblába, ugyanazt a szekvenciát használva. Ilyenkor az implementációtól függően vagy valami két fázisú commit fog lefutni (LASSÚ!!!), vagy session-ként lesz előre allokálva szekvencia tartomány (innentől a szekvencia nem fog valós sorrendet megadni a táblában), amely tartományból ha kifutunk, megint csak jön a 2-phase commit (szintén nem gyors). Így vagy úgy, de a külön, teljes klaszterre, összes gépre, több szálra kiterjedő tranzakciókezelés miatt veszítünk a feldolgozási teljesítményből, miközben fogalmunk sem lesz, hogy mi volt a valódi beszúrási sorrend.

Ez még mindig oké a legtöbb esetben. Azonban gondoljunk bele, mi történik, ha egy cluster belső kommunikációja megsérül. Tegyük fel, van két gépünk összekötve. A kettő közötti kapcsolat lehal, mindkét gép azt fogja hinni, hogy a másik gép leállt, és csak ő az elérhető. Ha a kapcsolat újra visszaáll, vajon mi fog történni? Ez a network partitioning probléma egyike, miszerint a szétszakadt klaszter hogy detektálja a szétszakadást, hogy ismeri fel a különböző szigeteket, és hogyan kapcsolja őket össze. Vegyük észre, hogy a szekvenciáknál gond van ilyen esetekben, még hozzá nem is kicsi.

Akkor mit használjunk, ha korrektek akarunk lenni, és nagyobb környezetben is szeretnénk a kódunk megfelelően futtatni? Ha folytatni akarjuk a hagyományokat, akkor a legkézenfekvőbb megoldás a Digital (azóta Compaq, azóta HP) által jegyzett univerzális egyedi azonosító (UUID) technológia, amelyet azóta a Microsoft is meghonosított GUID néven. Ez az azonosító nem más, mint egy 128 bites szám, amiben benne van a létrehozás ideje, a létrehozó gép MAC address-e, valamint némi véletlenszám/szekvencia is. Ezzel garantálja, hogy két gép nem osztja ki ugyanazt az UUID-ot soha, illetve időrendileg rendezhetővé teszi a rekordokat, még extrém körülmények esetén is. Egyszerűvé válik a szétszakadt klaszter összeszinkronizálása, ésatöbbi, ésatöbbi.

Persze az UUID-nak és GUID-nak is van hibája, mégpedig, hogy csak másodperc alapú az idő felbontása. Ha akarunk tunningolni ezen, akkor itt a mi bevált receptünk, amit könnyű implementálni bármilyen adatbáziskezelőbe:

• 2000 óta eltelt másodpercek száma: 0-31  (32 bit)
• Milliszekundum a másodpercen belül: 32-48 (17 bit)
• Verzió: 49-51 (3 bit)
• Processz, session vagy thread azonosító: 52-67 (16 bit)
• Gép azonosító (IPv4, MAC v host): 68-115 (48 bit)
• Milliszekundumon belüli szekvencia: 116-127 (12 bit)

Mi úgy hívjuk, hogy time aware unique identifier (TAUID), ami szintén egy jó nagy szám (128 bit). Érdekessége, hogy milliszektundum szinten visszakövethető belőle a beszúrás dátuma, illetve kiolvasható a beszúró gép azonosítója - mindezt egyetlen elsődleges (surrogate) kulcsból. 

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.