57 lines
5.1 KiB
Markdown
57 lines
5.1 KiB
Markdown
# SqLite Adatbázisok Szinkronizálása
|
|
|
|
Adatok kezelése során, amint egynél több kezelőnek, vagy egy kezelőnek több munkaállomásról kell elérni az adatokat, a helyben létrehozott adatbázis lesz a korlátozó tényező, felmerül a kérdés, hogyan lehet azt a korlátot átlépni. Az adatbázisban kezelt adatok jellegüket tekintve gyakorlatilag bármilyenek lehetnek, készletnyilvántartás, archívum dokumentumok vagy képek számára, számlázási vagy mérési adatok, üzenetek, stb., a lista szinte végtelen.
|
|
|
|
A továbbiakban egy nagyméretű adatokat (2-300 MB pdf dokumentum) is tároló rendszer tárolási metódusa fejlődésének lépései olvashatók, mysql adatbázison.
|
|
|
|
## Központi adatbázis
|
|
|
|
A probléma megoldásának kézenfekvő eszköze a helyben tárolt adatbázis áthelyezése központi kiszolgálóra. Ez addig jó megoldás, amíg pl. egy irodán belül kell több helyről elérni az adatokat, a sávszélesség gyors, egyszerű adatbázis kapcsolattal megvalósítható. Az adatbázis elérését nyilvánossá tenni nem szerencsés, így a helyi hálózaton kívülről már vpn felépítése szükséges, ami viszont már lassítja az elérést.
|
|
|
|
## Adatkapcsolati réteg
|
|
|
|
A vpn kiváltható egy adatkapcsolati réteg elhelyezésével az adatbázis fölé, pl. rest api kapcsolaton keresztüli eléréssel, a vpn kiépítése nem szükséges, de távolról ugyanúgy lassú lesz.
|
|
|
|
## Elosztott adatbázis
|
|
|
|
Több elérési pont hozható létre az adatbázis replikáció használatával, pl telephelyenként,. Ez adatbiztonság és rendelkezésre állás tekintetében is előnyös, viszont a nem belső hálózatról történő elérés ebben az esetben is vpn-en vagy rest api-n keresztül lehetséges.
|
|
|
|
A másik megoldás, hogy multi master replikáció kerül megvalósításra, így minden munkaállomás a saját helyben tárolt adatbázisába dolgozik, az adatok pedig a replikáció útján eljutnak mindenkihez. Ez a megoldás rengeteg beállítást igényel, ráadásul a munkaállomásokon futó szolgákat nehéz felügyelni.
|
|
|
|
## Hibrid megoldás
|
|
|
|
A fenti tapasztalatok felhasználásával készült egy megoldás, ami a helyben tárolt sqlite adatbázisokat rest api-n elérhető szerveren keresztül szinkronizálja.
|
|
|
|
### A probléma
|
|
|
|
Adatbázisok szinkronizálásánál az adattáblák elsődleges kulcsát úgy kell kezelni, hogy ne keletkezhessen ütközés. A mysql erre megoldást nyújt a konfigurációjában beállítható változók segítségével.
|
|
|
|
```
|
|
server-id = 1
|
|
auto-increment-offset = 1
|
|
auto-increment-increment = 10
|
|
```
|
|
|
|
A replikációban résztvevő adatbáziok mindegyikének egyedi azonosítója van a **server-id**, a másik két változó az auto_increment típusú mezők (az elsődleges kulcs ilyen, ha az adatbázis kezelőre bízzuk a kezelését) képzésének a szabályait írja le. Az **auto-increment-offset** az alapértéktől való eltolást határozza meg, az **auto-increment-increment** pedig az eltolt érték növelésének mértékét.
|
|
|
|
A fenti esetben egy üres táblában az elsődleges kulcsok rendre az 1, 11, 21, 31, 41 ... értékeket veszik fel.
|
|
|
|
A 2-es szerveren a fenti beállítások így néznének ki:
|
|
|
|
```
|
|
server-id = 2
|
|
auto-increment-offset = 2
|
|
auto-increment-increment = 10
|
|
```
|
|
|
|
Ebben az esetben az elsődleges kulcsok a 2, 12, 22, 32, 42 ... értékeket veszik fel.
|
|
Az **auto-increment-increment** azt is meghatározza, hogy hány szerver vehet részt a replikációban (mivel a fenti három változó egyike sem lehet 0, így ebben az esetben 9 adatbázis vehet részt a replikációban).
|
|
|
|
### A megoldás
|
|
|
|
A lokális adatbázisban keletkező elsődleges kulcsok képzését meg lehetne oldani a mysql replikációnál használt megoldással, de az további adminisztrációt eredményezne, minden résztvevő kliensnek egyedi sorszámmal kellene rendelkeznie, előre kellene tudni a résztvevő adatbázisok számát, és, ha az mégis kevésnek bizonyul, az összes adatbázison újra kellene konfigurálni az elsődleges kulcsokat és azok képzését is.
|
|
|
|
Inkább az a megoldás lett használva, hogy a helyi adatbázisokban keletkezett elsődleges kulcsok nem kerülnek szinkronizálásra, a rekordok azonosítása egy-egy uuid-val történik, az egymáshoz kapcsolt táblák is a uuid-k révén vannak összekötve. Annak az esélye, hogy egy már létező uuid újra előkerül, elhanyagolhatóan kicsi, gyakorlatikag egymástól függetlenül tundak a kliensek olyan azonosítókat generálni, amiből nem lesz két egyforma.
|
|
|
|
Kliens oldalon minden nem select típusú lekérdezés egy táblába íródik, amit rest api-n keresztül tölt fel a rendszer. A helyi adatbázisban lévő elsődleges kulcsot használja fel azonosításra és nyugtázásra is, ott minden feltöltött lekérdezés egy adattáblába íródik. A kliensek ezt az adattáblát kérdezik le a beírás sorrendjében, amit a kiszolgáló által létrehozott elsódleges kulcs segítségével követnek, és amelyik lekérdezést nem a kérdező töltötte fel, az végrehajtódik a lokális adatbázison is, így szinkronban tartva a klienseken tárolt adatbázisokat.
|