Egy adatbázis-építési probléma elemzése során felállítottam egy olyan modellt, ami talán gazdaságosság és hatékonyság szempontjából is működőképes lehetne. Az internetes információ és fájltömeg tárolására ugyanis olyan kiszolgálóhálózatot kellene létrehozni, mely hálózatban a tárolókapacitás elosztása és a belső/külső sávszélesség leterheltségének alacsony szinten tartása megoldható. Ez ugyanis felválthatná az olyan egy-központú kiszolgálórendszereket, amelyek egyedül végzik az összes adatszolgáltatással kapcsolatos teendőt, így általábna eléggé leterheltek. Hangsúlyoznám hogy ez a modell igazából csak a nagy fájltömegek kezelésére használt szervereknél lehet megoldás, a kisebbeknél már jelentősen romlik a gazdaságosság fokmérője. Főleg hogy maga a rendszer meglehetősen sok-komponensű, így kisebb rendszereknél már az alkalmazása is problémákba ütközhet.
Fontos hogy ez csak egy elméleti modell. Ebben a formájában valószínűleg nem is alkalmazható a gyakorlatban. Rengeteg probléma akad vele, amit próbálok orvosolni, egyenlőre nem túl nagy hatékonysággal. A hiányosságra jellemző, hogy például a szerverek fizikai karbantartásával nem is számoltam még, ami egy újabb komoly összeg lehet. Szóval szerintem elméleti alapnak megteszi, úgyhogy postolom, hátha valakinek megtetszik. No,akkor vágjunk bele.

Először vizsgáljuk meg az egyközpontú (single-core) tárhely/adatbázis rendszerét. Ebben az esetben egy fő kiszolgáló létezik, mely önmagában végzi el az összes, tárolt adattal kapcsolatos feladatot. Ezek, általánosan: a fájlok/információk + metaadatok tárolása, a tárolt fáljok indexelése, a külső fájl-kérelmek elbírálása (van-e a tárhelyen kért adat) és végül az adat kiszolgáltatása. Ez a struktúra egy olyan központot hoz létre, mely mindent egymagában csinál, ergo nagy számítási teljesítményű szerverek és a központból kiinduló jelentős sávszélesség szükségeltetnek a kielégítő működéséhez. A legkényesebb pont viszont a meghibásodás lehetősége: mivel ebben a struktúrában még kiegészítő szerverek sincsenek (legföljebb backup szinten), a kiszolgáló kiesése esetén az adatáramlás teljesen megszakad. A backup-szervereket azért nem tekintem itt a rendszer részének, mert a főkiszolgáló lekapcsolása esetén ezek nem helyettesíthetik dinamikusan annak munkáját, csupán az adatok visszanyerésére alkalmasak. Ez a módszer a jelenlegi általános gyakorlat, nézzük helyettesíthető -e hálózati megoldással.

Az alapvető network struktúra szerint nem egy, hanem több "központi" kiszolgálón (multi-core) gyűjtjük az adatokat, melyek egymással folyamatos szinkronizációban vannak. Minden adat fellelhető mindegyik kiszolgálón, ha valaki az egyik kiszolgálón frissíti az adatokat, azok a szinkronizáció lévén a többi kiszolgálón is frissülnek. Ebben a struktúrában a kiszolgálók ugyanolyan feladatokat végeznek mint az első pontban ábrázolt egy központi szerver. A különbség csupán annyi, hogy egy egység adatnak több klónja, pontos mása is megtalálható a többi szerveren. Itt egy fő-szerver kiesése már nem probléma, mivel az adatkérések a hálózat többi tagjához irányítódnak, melyek kezelni tudják azokat. Ennek a modellnek azonban több problémája is van.
Elsőként az erőforrásigényt kell kiemelnünk: több szerver teljes funkcionalitáson működő üzemeltetése drága. Kiemelten akkor, ha nem olyan mértékű az adatigénylés, amekkoránál már gazdaságosan üzemeltethető több kiszolgáló is. Ha az adatkérelmeket egy vagy két fő kiszolgáló is el tudja látni, ebben az esetben több fő kiszolgáló üzemeltetése csupán az adatvédelem szempontjából fölösleges.
Másodsorban a sávszélesség kérdése merül fel. Ha a kiszolgálóra nagy mennyiségű új vagy módosított adat kerül fel, azt dinamikusan szinkronizálja a többi kiszolgáló adatbázisával. Ez még egy viszonylag kis mértékű leterheltséget jelent. Ugyanakkor ha feltételezzük hogy minden fő ponton mondjuk tízezer egység adat tárolódik és naponta ehhez újabb száz egység új vagy módosított adat érkezik, a szervereknek folyamatosan kell pingelniük a többi kiszolgálót hogy nem módosítottak e valamelyik adaton. Beláthatjuk hogy tízezer egység adat szinkronizálási kérelme hálózatosan, (tehát elméletben ezt mindegyik kiszolgáló megteszi a többi irányába) még a valós adatszinkronizálási műveleteket levonva is, hatalmas mennyiségű hálózati forgalmat generál, ami szintén jelentős terhelést jelent. A rendszer tehát gyakorlati téren nehezen valósítható meg.
A modellem igyekszik kiküszöböli a fennti problémákat. A rendszer fenntartja a több központos elvet (itt az egyszerűség kedvvért vegyünk öt kiszolgálót), ugyanakkor erősen épül a hálózatok sajátosságaira is. Először is vegyünk példának 10000 egység adatot, melyet ennek a hálózatnak tárolnia kell. Eddigi példáimban minden kiszolgáló rendelkezett mind a 10000 egységgel, ha szükség volt rá, ha nem. A módosított verzióban mind az öt kiszolgáló az összes adatmenyiség arányos részét tárolja csupán. Ebben az esetben vegyünk 2000 egységet kiszolgálónként. Azonban a kiszolgálók feladata is módosul némiképpen az első ponthoz képest. Bár az adatok csak egy részét tárolják fizikailag, az összes adatról információkkal rendelkeznek. Itt válik szét számomra a fájlok (adatok) adatbázisa és az adatokról szóló információk (metadatok) adatbázisa. Míg a fájl-adatbázisnak a szerverek csupán egy részét tárolják, az információs adatbázis teljes, szinkronizált változata elérhető rajtuk. Miért jó is ez?
Az adat-elosztás egyrészt erőforrás-kímélőbb, hiszen minden szerver csak a saját fizikai adatait kezeli, nincsen felesleges backup-feadat, nem kell tekintettel lennie a maradék adatállományra. Továbbá, az adatszétosztás abból a szempontból is hasznos, hogy egy kiszolgáló kiesése esetén az adatok csupán egy része válik elérhetetlenné, a maradék zavartalanul elérhető a hálózat többi tagjától.
Továbbá hasznos a sávszélesség kímélése szempontjából is, méghozzá több téren. Elősorban azzal, hogy tekintve hogy egy adat csak egy helyen van fizikailag jelen, így a szinkronizálás ezen a szinten szükségtelen. Másrészt pedig az információ-adatbázis frissítése töredékét használja fel a sávszélességnek, mint amit a fáljok ellenőrzése jelentene. Továbbá mikor egy adatot frissítenek, elég ha csak a részes kiszolgáló küldi el ezt az információt a többi kiszolgáló információ-adatbázisába és nem azok bombázzák kérelmekkel egymást. Ha pedig egy A kiszolgálón található adatot B kiszolgáló felől akar valaki elérni, elég ha csak egy ellenőrző kérdést (megvan? igen/nem = 1 bit) küld el a többi felé, ami minimális sávszélességet igényel.
Itt tehát az adatkiszolgálás a következőképpen történik: külső kérelem befut valamelyik kiszolgálóhoz. Az előbb leellenőrzi hogy az adat létezik e a hálózatban (információ-adatbázis). Ha igen, saját adatbázisában keres. Ha az eredmény negatív, megpingeli a kiszolgálókat, ahonnan pozitív válasz érkezik, oda irányítja a kérelmet, mellyel utána már az a kiszolgáló fog foglalkozni. Így elkerülhető a csatornák bedugulása, az adat és információáramlás dinamikus marad.
Vegyük végül azt az esetet, amikor valamely kiszolgáló kiesik a rendszerből. Tárolási szempontból ekkor csak a saját adatállománya válik elérhetetlenné, miközben a többi kiszolgáló zavartalanul továbbíthatja az adatokat. Az adatkérő ebből annyit vehet észre hogyha a kért adat azon a szolgáltatón volt, az nem hozzáférhető; ha azonban az adatkérés csupán az adott szerveren keresztül történne az elosztott adatbázisban, automatikusan egy másik kiszolgálóhoz irányítódik.
Ugyanakkor még mindig nem jutottunk eredményre a kiszolgáló kiesése esetén bekövetkező részleges adatvesztés kiküszöbölése kapcsán. (Az alábbi ábrán a kiszolgálórendszert már kiegészítettem a belső logikájó kiegészítőrendszerrel.)

Belső logika. Az adatkérés megmarad a belső hálózat határain belül, hogy minden kiszolgálóhoz specifikusan mellékkiszolgálókat telepítünk, egyfajta backupot hozva létre, amely azonban szükség esetén dinamikusan hozzáférhető. Az erőforrások korlátozottsága miatt azonban a következő struktúrában működnek: Egy főkiszolgálóhoz tetszőleges menyiségű (nem kell túl sok) mellékkiszolgálót kapcsolunk a rendszerbe, azonban ezek alapesetben nem vesznek részt az adatszolgáltatásban; nincs aktív kapcsolatuk a többi főkiszolgálóval, amelyel sávszélesség takarítható meg. A mellékkiszolgálók feladata hogy tárhelyük tartalmát dinamikusan, belső rendszerben szinkronizálják a főkiszolgálójukkal. Ez a struktúra hasonlít a második pontban felvázolthoz, de jelentős különbségek is vannak köztük. A mellékkiszolgálók nem rendelkeznének saját információs adatbázissal, főkiszolgálójuk normális működése alatt csak adataik szinkronizálása lenne feladatuk. (dinamikus backup) Azonban a főkiszolgáló kiesésekor ezek a segédszerverek megnyitnák kapcsolataikat a működő főszerverek felé: bár a tartalmat közvetlenül felőlük nem lehetne elérni (hiszen nem rendelkeznek saját metaadatbázissal, így nem tudják elvégezni az adatkérési folyamtokat) ugyanakkor a többi kiszolgáló frissített adatbázisa alapján az adatok kiszolgálása továbbra is zavartalanul folyna (Itt probléma lehet még az adatok módosításának a kérdése, erre még nem sikerült megoldást találnom.) A mellékkiszolgálók tartalomszolgáltató szerepüket a főkiszolgáló működésének megkezdéséig folytatnák.

Külső logika. Sokkal inkább hálózati szisztémán alapul a második verzió, mely az adatmentés folyamatába bevonná az adatkérőket (felhasználókat) is. Ezt a struktúrát egyenlőre elég nehéz lenne megvalósítani. Az elmélet mindenesetre a következő: A fő kiszolgáló kiesése esetén egy hiányzó adatra történő hivatkozás, miután a kiszolgáló végigkérdezte a többi főkiszolgálót és negatív pingeket kapott, életbe léptetne egy olyan rendszert, mely az eddig adatkérelmezők ügyfélszámítógépei felé küldene hasonló pinget, mint amit a társai felé küldött. Mivel feltételezhetjük hogy egy felhasználónál nem a teljes adatmenyiség lelhető fel, csupán a töredéke, használatba vehetjük a bittorrent rendszerben használatos modellt, természetesen változtatásokkal (Itt a változtatásokon a teljességgel központosítatlan rendszer átalakítását hálózati-központosított rendszerré értem.). A bittorrent ugyanis kisebb részletekben közvetíti az információt, mely esetünkben megfelelhet a célnak. Ezt a tracker program rakja úgy össze, hogy a részinformációk alapján megpróbálja az egészet összerakni. Tehát ha P1 felhasználónál megvan az adat egyik fele, P2-nél pedig a másik, akkor a részadatokat a kiszolgáló a kérelmező gépe felé irányítja. Az adatok hozzáférhetőségét egy 0-tól 1-ig terjedő tetszőleges tizedesjegynyi pontosságú skálán lehetne meghatározni.

Látható hogy mindkét kiegészítő rendszernek vannak nehézségei (az a. struktúrának a mellékkiszolgálók fenntartásának megemelkedett hardware-költségei, míg a b. -nél a kétoldalú felhasználói kapcsolatok kialakítása), ugyanakkor ezek további fejlesztésekkel véleményem szerint kiküszöbölhetőek. Továbbá az adatbiztonság fokozása érdekében a két rendszer összekapcsolható, ennek költségei azonban jelenleg rendkívül magasak.
Figyelembe kell azonban vennünk, hogy ezek az elméletek mind egy esetleges hiba esetén állnak fennt: ha ilyen nem következik be, a harmadik pontban bemutatott tárolási struktúra mind adatbiztonság, mind hatékonyság szempontjából megfelelőnek tűnik.