Az adatbázisok jelene és jövője – interjú Jim Starkey-val, a MySQL vezető szoftverfejlesztőjével
Az adatbázis-fejlesztés során milyen előnyöket nyújt a nyílt forráskód?
A nyílt forráskódnak három nagy előnye van. Az egyik az, hogy sok ezren ellenőrzik és tesztelik a kódot. A másik előny az, hogy ez a sok fejlesztő nem fog megelégedni azzal a hozzállással, hogy “állami megrendelésre jó lesz”. Minden sor kóddal kapcsolatban, amit írok, elképzelem, hogy milyen kérdéseket tehetnek fel a következő MySQL Falcon felhasználói konferencián.A harmadik előny pedig az, hogy a szoftverfejlesztők természetüknél fogva szeretnek a figyelem középpontjában állni, egyfajta “feltűnési viszketegségük van”. A nyílt forráskód ezen keresztül a legjobbat hozza ki belőlük.
Az adatbázis tervezése során hogyan tartod egyensúlyban a teljesítményt, a biztonságot és a könnyű használhatóságot?
A kérdést úgy kellene feltenni, hogy “hogyan egyensúlyozod a teljesítményt, a biztonságot, a könnyű használhatóságot és a szabványoknak való megfelelőséget…” – mivel a szabványoknak való megfelelőséggel együtt válik a feladat igazán komollyá, anélkül sokkal könnyebb a dolgunk.
Nézzük például az adattípusokat. Az SQL szabvány gyökerei lyukkártyákra nyúlnak vissza, rögzített méretű típusokkal, melyek rögzített méretű egészek, rögzített méretű karakterláncok, és változó karakterláncok rögzített határokkal. A legtöbb adatbázismotor az adatokat fix hosszúságú darabokban tárolja, így a felhasználónak választania kell a rugalmasság (olyan típusok, melyek elég nagyok a legrosszab esetek kezelésére) és a teljesítmény között. A Falcon az adatokat a tényleges érték alapján tárolja, nem pedig a deklarált típus alapján. Ez azt a teljesítménybeli terhet küszöböli ki, ami a mező túlspecifikáltsága esetén lép fel. Az “5” mint érték ugyanazt a helyet foglalja el, attól függetlenül, hogy hogyan deklaráltuk (például tiny integer, small integer, large integer stb.).
De micsoda nyűg az ide-oda leképzés a fix hosszúságú deklaráció és a változó hosszúságú storage között! Ha a szabvány lehetővé tenné, a felhasználó csak azt mondaná, hogy “Ez egy szám, oldd meg a feladatot!” A modern nyelvek és keretrendszerek méret nélküli karakterláncokkal rendelkeznek. Az adatbázisok miért nem?
Tehát én így részesítem előnyben a könnyű használhatóságot a teljesíménnyel szemben. Tegyük lehetővé a felhasználó számára, hogy a szoftver a megfelelő feladatot “okosan” lássa el.
A biztonság egy kimondottan nehéz ügy. Az SQL biztonsági modellje még azelőtt jött létre, hogy a mai adatbázisfejlesztők megszülettek. A modell még a régi időosztásos (time sharing) rendszerekre lett tervezve, ahol az emberek az adatbázisokat “buta” (hardcopy) terminálokon osztották meg. Manapság virtuálisan minden adatbázis hozzáférés alkalmazásszervereken keresztül történik. A szerver bejelentkezés nem képviseli az aktuális klienst, melyet úgyis csak egy-két lekérdezés erejéig “ismer”. Emellett a hozzáférés-ellenőrzés vagy a láthatóság sorok, nem pedig táblázatok szintjén kell, hogy legyen. Nem épp itt az ideje, hogy az adatbázis közösség felimerje ezt?
A relációs modell jól tartja magát. Ennek mi az oka?
Ennek számos oka van. Az egyik az, hogy a munka egysége elég nagy ahhoz, hogy megérje optimalizálni. A másik ok, hogy a relációs műveletek adatobjektumok készletein zajlanak, ami egy jó modell a távoli eléréshez. Végül is, ez egy olyan letisztult modell, ahol nincs szükség nagy tervezési agyafúrtságra.
Azután szerettem bele a relációs modellbe, hogy elolvastam Codd egy korai írását. Akkoriban az ARPAnet Datacomputer projekten dolgoztam (a Hálózat akkor 45 számítógépet hajtott, ami nagyon izgalmas volt).
Mindazonáltal, a relációs modell rendelkezik fejlődési lehetőséggel. A “téglalap alakú” táblázatokba nem sok adat fér. A pólók például más tulajdonságokkal rendelkeznek, mint a nadrágok, de mind a kettő ruházat. Néha csak a pólókat akarjuk látni, néha csak a nadrágokat, néha minden ruházati elemet. Ennek a kezelése relációs adatbázisban megkívánja, hogy “fejreálljunk”. A szemantikus adatmodell, ami kb. 1978-ban jött lére, a relációs modell apró, de elegáns kiterjesztése a típushierarchiák kezelésére. Elég meghökkentő, hogy ez még a mai napig sem valósult meg.
A beágyazott környezetek a méreten kívül támasztanak-e további igényeket az adatbázisokkal szemben? Például mi a helyzet a megbízhatósággal?
Szerintem mindannyian egyetértünk abban, hogy a kontextusváltások vagy a hálózati latenciák negatívan hatnak az alkalmazások teljesítményére. Másrészt a modern adatbázis-motorok meglehetősen mohók a memória és processzorok szempontjából, tehát nem sok értelme van annak, ha sok beágyazott adatbázis van jelen a rendszerben. Ahelyett, hogy beágyazzuk az adatbázis motort az alkalmazásba, nem jelent-e jobb megoldást az alkalmazás beágyazása az adatbázis szerverbe? Az architektúra kialakításának nagyon jó módját nyújtják azok az alkalmazások, melyek mindegyike nagyon gyors szálon belüli lekérdezést valósít meg egy elhatárolt futtatókörnyezetben (sandbox), az eredményeket pedig egyetlen adattömeg formájában ontják.
Szerintem futottunk már néhány kört ebben a témában. BLOB-okkal (binary large objects) kezdtünk, mivel méretükben korlátlanok voltak, de hamarosan minden mező korlátlan lesz, így a BLOB-ok eltűnnek majd. A relációs modell jó volt, mivel egyszerű, de szemantikai kiterjesztésre van szüksége, hogy életben maradjon, és tovább fejlődjön. Az SQL valamikor jó volt, mivel jól működött a hálózaton, de az SQL a hálózaton most a rendszer teljesítményének egy korlátozó tényezője. Annak érdekében, hogy megmentsük az SQL-t, a hálózat helyett az elhatárolt futtatókörnyezetre kell koncentrálnunk az adatbázisszerveren belül. Ezért egy másfajta gondolkodásmódot kell megtanulnunk az alkalmazások tervezésével és használatával kapcsolatban.
Létezik egy régi történet a nagyapa fejszéjéről, aminek a fejét kétszer, a nyelét háromszor cserélték ki. Szerintem errefelé tartanak a relációs adatbázisok is. Megváltoztatjuk majd az adatmodellt, az adattípusokat, az alkalmazás topológiáját, és a hálózati felületet, de még mindig relációs adatbázisokról beszélünk.