En ket dolgot tudok, ami tan hasonlot tud. Az egyik a oracle parallel server, a masik meg a berkeley db, http://www.sleepycat.com/products/highavail.shtml, http://www.sleepycat.com/products/sidebyside.shtml.
udv,
A 7.3.4 verziójú PostgreSQL kézikönyvének 3.2. fejezetének címe: Creating a Database Cluster. Ilyesmire gondolsz? Többet sajnos nem tudok erről, csak láttam a doksiban.
Minden key-hez lenne egy adatbazis, ami azert a rekordert felelös.
Ha egy helyi szervernek szüksege van az adatra elöször megnezi a cache-ben, ha nincs meg, akkor meg a key alapjan edönti, hogy melyik adatbazisbol kell lekerdezni, es lekerdezi, majd cache-eli.
Ha valaki update-el egy rekordot, akkor a lock a halozat minden gepere tovabbküld egy cache-invalidaciot a rekordra.
A commit pedig beirja az adatot a megfelelö csomopontba.
Ez persze csak akkor jo, ha a lekerdezesek szama enyegesen alacsonyabb a bevitelekenel, de en ilyesmit szeretnek csinalni.
Igen, ilyesmire. Csak az nem tetszik, hogy a helyi szerverek mindent tarolnak. Olyan nincs, hogy az adatok el vannak osztva, es a helyi szerverek cache-elnek is.
MySQL-re létezik egy olyan megoldás, hogy van egy központi szerver és sok helyi.
A kliensek a helyi adatbázisokhoz kapcsolódnak.
A helyi adatbázisokban minden megvan, tehát select-ekkel semmi gond.
Insert/Update esetén pedig a helyi szerverek a központi szerverbe insertálnak/updateelnek és a központi szerver küldi tovább az SQL-utasítást a többi (helyi) szervernek.
Ez az egész akkor hatékony, ha a kliensek leginkább select-eket futtatnak és csak ritkán írkálják az adatbázist.
Ilyesmire gondoltál?
Épp arról beszélek, hogy miért érzem kétségesnek a dolog lehetőségét; ha én, mint kliens, módosítok egy bizonyos rekordot az egyik szerveren, az hogy jut el a többihez? Ugyanez a lock-olásra...
