Fejlesztés elosztott rendszerre - mire figyeljek?
2011-07-19T14:23:19+02:00
2011-07-21T23:22:54+02:00
2022-07-19T05:22:13+02:00
  • Ha jól értem, akkor lennének nyelvesített adatbázisaid, nyelvesített adatbázisonként webalkalmazások, valamint egy közös adatbázis, amit mindegyik alkalmazás használ.
    A célod az, hogy a közös adatbázis adatait minden nyelvi környezetben elérd, valamint ha bármelyikben módosítod, akkor a többiben látszódjanak a változások.

    Földrajzi elhelyezkedés szerinti data centerekről beszélsz, amely magával vonja azt, hogy a 4. adatbázist replikálgatni kell a világban (multi master módon méghozzá) a data centerek között.
    Kérdés, hogy ez mekkora költséggel oldható meg, illetve hogyan viszonyul egy egy data centeres megoldáshoz.

    Sztem maradjunk egy data centernél (gondolm nem a google-t akarod kiütni):

    Az alkalmazást úgy készítsd el, hogy a webes felület valamint a business logic, alkalamzás logika lazán kapcsolódjon egymáshoz. Ugyanígy az adatelérés. A webalkalmazás implementációja során a lehető legkevesebb session adat kezelésére törekedj. Ha így teszel, akkor könnyen mondhatod azt, hogy a webfelületet NLB clusterbe szervezed (ha szükség van rá, induláskor nem javaslom). Az alkalmazás logikát szintén NLB-be tudod tenni. Legdurvább esetben majd az NLB-be pakolt web hívja az NLB-zett alkalmazáslogikát. Persze ennek előfeltétele az, amit írtam, hogy ne kezeld az állapotot inprocess.
    A nem változó adatokat cache-eld be (nyelv, ország, város, stb.), az adatbázisból ezeket ne töltsd be minden lekéréskor.

    Az adatbázist én nem úgy osztanám el, ahogy írtad, hanem az un. Shard megoldást választanám.
    A dolog lényege az, hogy az adatokat horizontálisan particionálnám (soronként). Azaz az egyik DB szerver (cluster) tartalmazná a felhasználókat mondjuk a-k-ig, a másik pl. l-p-ig, majd q-z-ig. Persze ugyanígy néznének ki pl. a tranzakciók, a hozzászólások, stb. Ugyanígy particionálnám a fórum bejegyzéseket (kategória szerint), a híreket (témakör szerint), stb.
    A dolog előnye az, hogy egy okos hash függvénnyel mindig a megfelelő adatbázis szervert dolgoztatod csak (a kpocza (k kezdőbetűvel) felhasználó az 1. szerveren lakik). Illetve ami még lényegesebb, hogy ha olyan adatcsomagra van szükséged, amelynek egyes részei a n adatbázis között eloszva vannak jelen (azaz mindegyik DB egy kis részét tartalmazza a teljes adatcsomagnak), akkor a lekérdezést az n adatbázis felé egyszerre, párhuzamosan elküldheted, majd az eredményt az alkalmazáslogikában összesítheted. Matematikailag 1/n idő alatt lefut, persze valójában nem...
    Az adatbázis JOIN műveleteket próbáld leszorítani (pl. ha egy felhasználói profilt töltesz be, akkor az ország esetében nem joinold be az ország táblát, hanem csak a hivatkozó id-t töltsd be, az ország display neve úgyis cache-ben van az előzőek szerint).
    Ha már itt tartunk, akkor mondanom sem kell a megfelelő indexelés fontosságát.

    Használhaszt valamiféle distributed caching megoldást (pl. memcached), vagy ha tetszik akkor noSQL-t.

    Fogalmam sincs, hogy milyen világmegváltó ötletet találtál ki, de az az architektúra, amit leírtam (foszlányokat közöltem belőle) csak nagyon nagy számú felhasználó esetében célravezető. Kölönben csak nyűg, a pénzbeli költségekről nem is beszélve.

    At least: Ha nem akarod folyamatosan újraírni az alkalmazásodat a felhasználószám növekedésével, akkor a tervezéskor többrétegű architekturális modellben gondolkodsz, valamint figyelembe veszed a fent említett lazán csatoltsági elveket.
    Mutasd a teljes hozzászólást!
  • Köszönöm a javaslatokat! Őszintén szólva nem ismerem ezeket az eljárásokat, ezért is jó, hogy megemlítetted, mert így tudom mit kell keresnem, minek érdemes utánaolvasnom bővebben.

    Nem feltétlenül a 4. adatbázis lesz a szűk keresztmetszet, viszont bizonyos adatokat lokalizációtól függetlenül szeretnék közössé tenni. Tehát hogy elérhető legyen minden szerveren.

    Ilyen lehet a userek adata, de lehet még pl hírek, fejlesztői fórum stb.
    Nomeg elviekben netes fizetés is lesz, így a tranzakciókat is egy helyen lenne jó tárolni. (legalábbis szerintem)

    Hogy milyen nagy lesz ez jó kérdés. Reményem szerint több ezer regisztrált felhasználó lesz. (de ha nagyon beindul akkor a százezres felhasználó szám sem kizárt)
    Mutasd a teljes hozzászólást!
  • Ha ezt előbb tudom mindenkinek azt mondtam volna, hogy enyém az index vagy az origó
    Mutasd a teljes hozzászólást!
  • A kérdés leginkább az, hogy mennyire nagy?


    Hát igen, ez szokta a csajokat leginkább érdekelni
    Mutasd a teljes hozzászólást!
  • A kérdés leginkább az, hogy mennyire nagy?

    Úgy látom első körben a negyedik adatbázis szempontjából fogod meg, hogy az lesz szerinted a szűk keresztmetszet. Ha ezt tényleg így látod, akkor van elég sok lehetőséged. Például ha inkább read-intenzív lesz az az adatbázis (alapvetően nekem ennyi alapján mind a 4 annak tűnik, persze jó kérdés igazából hogy van) bármilyen RDBMS-el használhatsz master-slave szervereket (írás a masteren, olvasás bármelyiken történhet), de akár egy second level cache is segíthet egy réteggel feljebb, vagy ott vannak az elosztott adatbázismegoldások (mongodb, cassandra, stb), de ezek igazából mind más esetben jók. Aztán még vannak olyan relációs adatbáziskezelők, amik egyéb elosztott működésre (particionálás, stb) is képesek.

    Viszont én leginkább azt a kérdést tenném fel, hogy miért pont a negyedik adatbázisod lesz a szűk keresztmetszet? Egyáltalán miért vagy benne biztos, hogy az adatbázis lesz az?
    Mutasd a teljes hozzászólást!
  • Mivel elég egyedi projektről van szó, nem találtam olyan cms-t ami megfelelne az igényeimnek.
    Lényegében a felhasználó kezelésen túl minden egyedi lesz, amit a jelenlegi cms-ek nem tudnak. (de ha tudsz ajánlani valamit, megvizsgálom a témát)

    Tehát saját fejlesztés lesz, persze biztos vagyok benne, hogy később is kell majd szögelni rajta, sőt akár teljesen újraírni, de akkor azt már úgy is valami csapatban fogjuk tenni.
    Jelenleg egyedül csinálom az egészet, az ötlet is saját, ezért azt akarnám elkerülni, hogy indulás után 2 hónappal kelljen jelentős módosításokat csinálni a forráskódban/adatbázisban.
    Mutasd a teljes hozzászólást!
  • Én a helyedben először megcsinálnám először valamilyen CMS-ben, aztán ha tényleg bejön, akkor állnék neki komolyabban...
    Mutasd a teljes hozzászólást!
  • Ebben a témában én is szívesen meghallgatom pár itteni szaki véleményét, bár azért a google is ad pár jónak tűnő találatot a témában...
    Mutasd a teljes hozzászólást!
  • Sziasztok,

    Egy nagy webes projektbe vágom a fejszémet, és mivel ilyet még nem csináltam, megkérdeznélek Titeket a témában.

    A weboldal céljáról és témájától most tekintsünk el a lényeg azon van, hogy ha bejön az ötlet, elég sok látogató lesz rajta.
    Ezért már az elején úgy szeretném megtervezni az oldalt, hogy lehetőség legyen szétosztani a rendszert több szerver között.

    Mire gondolok:
    Elvileg nemzetközi lesz az oldal, tehát szükség lehet majd (persze látogatószám függvényében) pl amerikai, európai stb szerverekre.
    Az oldal alapja PHP és MySQL lesz, mivel ebben dolgozok egy jóideje.

    A kérdésem az lenne, hogy mire érdemes odafigyelni egy ilyen oldalnál?
    Hogyan valósíthatom meg azt, hogy pl XY user be tudjon lépni ugyanazokkal az adatokkal az amerikai és európai szerverre is?

    Csakhogy jobban kifejtsem, a példa kedvéért 3 nyelvű lesz az oldal (a valóságban remélhetőleg ettől sokkal több lesz), mindegyik területnek 1-1 adatbázisa lenne.
    1. angol
    2. magyar
    3. német
    A 4. adatbázis a közös adatokat (user, beállítások stb) tárolná.

    Mindegyik nyelvnek külön adatbázisa lesz, mivel nyelvspecifikusan vannak az adatok elkülönítve.
    Terveimben egy külön adatbázissal számoltam a felhasználók adatainak eltárolására, és minden olyan adat tárolására, ami nem nyelv specifikus. (user beállítások stb)
    Első körben ezt a 4. adatbázist szeretném valahogy elosztani, mivel a nyelvek között nem lesz átjárás.

    Remélem érthető a problémám és a dilemám. Nem feltétlenül konkrét megoldást kérnék, hanem inkább irányvonalakat, hogy hogyan is érdemes elindulni egy ilyen projektnél, mire figyeljek akár php oldalon, akár adatbázis vonalon.

    Ha valami nem érthető, nyugodtan kérdezzetek!
    Mutasd a teljes hozzászólást!
abcd