Nagyobb szerverhálózat kiépítéséhez keresek fejlesztőt!
2017-05-08T15:03:12+02:00
2017-06-12T10:31:13+02:00
2022-07-21T12:51:52+02:00
  • Egy ideje nem láttam ezt a topicot. A prog.hu úgy van összerakva, hogy ha nekem válasolsz egy felírással, akkor kapom az értesítést, de ha csak megemlítesz a postban, olyankor nem :)

    A kérdésekre válaszolva:

    A nodejs szerintem semmivel sem jobb egy apache + php-nál, ha webes felületen script alapon maradnál (legalább az első verzióban). Php-hoz van több support, ha később bővítenéd a csapatot.

    A teljesítményt illetően elfiloztam rajta kicsit, és nagyjából a lényege, hogy legalább az ötlet validálásáig semmi baj vele, ha php-zol, és akármilyen lassú is. Ha üzletileg beválik a cucc, és bővítenéd majd a szerver parkot, úgyis mindent újra kell írni, mert fürtön teljesen más az architektúra (felejtsd is el az olyasmit, hogy "csak lecserélni nagyobb teljesítményre" - nincs olyan). Be fog jönni a képbe az is, mennyi szervert üzmeltetni, mennyi felhasználót kiszolgálni, mennyi pénz tud jönni belőle, és úgyis az lesz a vége, hogy meg lesz kurtítva a szerverek száma, és lassabban fog futni az alkalmazás. Akkor pedig felhasználói élményben maradsz ugyan ott, mint egy lassabb php-s modellel. Ha a felhasználóid nem tudják azt is elfogadni, és nem tudsz úgy is pénzt vasalni belőlük, valójában megbukott az üzleti elgondolás.

    Megnézted már a cloud szolgáltatóknál, hogy milyen teljesítményt kapsz és milyen áron? Ha csak egyetlen évig használod, már ugyan ott vagy, mint megvenni egy ugyanakkora teljesítményű gépet, berakni a szerver parkba, és ott fizetni a szerver helyet (hely + villany + net). Az első évben még ugyan annyi, a következő évben már a saját szerverrel jártál jobban. Ha nem csak egy hónapra akarsz kipróbálni valamit, hanem egészen biztos vagy benne, hogy hosszú távon azzal foglalkoznál, mindenképpen érdemes egy saját szervert összerakni. De ahogy érzed.

    És valami más:

    Ha a dolgok üzleti oldalához értesz jobban, miért akarsz te magad belemászni a programozási részbe? A legnagyobb probléma mindig azzal van, hogy hype-ot gyártani már tudnak a srácok, de pénzt vasalni, azt egyetlen fillért sem. Bőven vannak szabad-kósza kóderek, akikből foghatnál magad mellé, ha az elgondolásaid tényleg üzletileg is passzolni tudnak, és azt el tudod értelmesen magyarázni, hogy mi meg hogy meg miért. Utána már könnyebb lenne azonnal rámutatni, ha valamelyik elgondolás jogilag vagy informatikailag nem tud gyökeret verni a realitás talaján, és csak az idődet pocsékolod vele, vagy valamelyiket tényleg érdemes lesz megcsinálni, és nyugodtan lehetne első körben is nagyobbra skálázhatóra csinálni meg. Vagy talán másutt vannak ötletek, amihez semmi többet nem keresnek, mint valakit, aki az üzleti világban is elboldogul, és még ötletelni is feleslegesen akarsz. Amit jelenleg csinálsz, kb a leghatékonytalanabb dolog ahhoz képest, amit írsz magadról. Persze lehet, hogy csak félreértettem valamit.
    Mutasd a teljes hozzászólást!
  • (És zárójelesen: 6.-as általános iskolás gyerek voltam mikor készítettem. Jó persze nem rögtön jött a pénz, de mire középsuliba kerültem a havi 300 megvolt. Emelt díjas sms-ekből jött a pénz, legális játék, bár számlázás ugye apám nevén ment mivel gyerek voltam. De ő mindössze annyiban járult hozzá, hogy kimentem hozzá nyomtatni havonta egy számlát az sms szolgáltató cégnek, mert neki volt élő vállalkozása.)
    Szóval szerintem tényleg nem csak a befektetés a lényeg, hanem maga az ötlet és az előadás módja. Persze mivel ennél nagyobba kezdtem el gondolkozni, ezért most már költenék is reklámra. (Ott azt hiszem a konkurencia weboldalán hirdettem emelt díjas sms-el, összesen talán 5000 Ft-ot költhettem rá, most azért kicsit nagyobb volumenű tervek vannak. :))

    Cocoya3: ha szerinted jó kezdetben a mysql, akkor maradok annál, azt úgy is már nagyon jól ismerem. Viszont a nodejs-re szerinted érdemes lenne átállni? A gyakori kommunikáció miatt, plusz lehetséges hogy a userek tudnak majd egymással üzenetet váltani, ahhoz meg a php háát ha nem akarom szétbombázni a szervert lehet nem a legcélszerűbb megoldás.
    A több szervert egy cloud szolgáltatónál gondoltam, pl. Google cloud, kis felhasználónál minimális költsége van, soknál pedig ha bejön az ötlet akkor már pénz is lesz azt a terhelést kifizetni. Nem sokra, tehát tényleg csak pl. kontinensenként 1.
    Mutasd a teljes hozzászólást!
  • Ne érts félre nem szeretnék ezen lovagolni. Lehet, hogy érdemes lenne ennek egy külön topicot nyitni, mert én úgy látom, hogy sokan nincsenek tisztában azzal, hogy milyen költségei vannak ma egy projekt indításának és üzemeltetésének és milyen megtérülés társul hozzá. Úgy tűnik magamat is ide kell, hogy soroljam, mert legmerészebb álmaimban sem gondoltam volna, hogy ingyenes tárhelyen futó projekt 1 millio forint bevételt tud generalni. Illetve, ugyanez saját szerveren havi fél milliót.
    Mutasd a teljes hozzászólást!
  • Hát, ha szerinted jól mérted fel, mit hogyan kellene, és egyébként is magatoknak kell boldogulnotok az elején, csináld, ahogyan tervezted - ha mégis elhibáztad, legalább tanulsz belőle.

    A mongodb-t nem tudom, ki javasolta neked. Totálisan nem arra való, amivel próbálkoznál. A mysql sorsa pedig még nem eldöntött tény, az Oracle lehet lesz annyira kapzsi, hogy végleg kitiltja a világból a mysql mindegyik ingyenes verzióját, és az kb egy webes armageddon lesz, mert mindenki azt használja üzleti célra is, de addig részemről továbbra is a mysql-t ajánlanám. Ha le kell majd cserélni a mysql-t, arra az esetre a firebird-et vagy a pgsql-t ajánlanám, amiket ugyan nem néztem az utóbbi években, de szerintem azok közül kellene választani következőre.

    Ha kevés pénzetek van, első körben spórolhattok oprendszer licencen, meg hogy maradtok mindenől ingyenes szoftver verzión, meg úgyis csak egy szerverre lesz csak pénzetek, felesleges több szerverre számítanod. Keress valami olyan alaplapot, amibe bele tudsz gyömöszölni legalább 64 giga ramot, meg legalább 12-16 magos amd processzort (vagy 6-8 magos intelt). Egy kicsit segíthet a hatékonyságban a normális hardver. Kezdetben inkább egy erősebb szervered legyen, mint több gyengébb, mert kevésbé fogod vakarni a buksit, amikor nagyon furcsán alakul majd a terhelése az alkalmazás egyes részeinek.

    Jó szerencsét.
    Mutasd a teljes hozzászólást!
  • Nem sok, néhány millió. A fejlesztést inkább magunk, kivéve amihez tényleg szükség van valakire, reklámra többet, de azt is inkább ügyes taktikával olcsón. 
    A terv, hogy felfuttatja magát, ha nő a költség úgy a bevétel is.
    De ezt most csak zárójelesen jegyzem meg, ne erre térjünk ki, hanem inkább az előző írásomban a megvalósításra.
    Szerk: (Kerestem 0 Ft befektetéssel is ingyenes tárhelyen már 1 milliót egy közösségi oldallal, utána a terheltség miatt (valószínű a rossz optimalizálás miatt, még gyerek voltam) saját szerver befektetéssel viszont további havi félmilliót. Nem csupán a befektetés összegének nagysága dönti el, hanem az ötlet, valamint a reklám kivitelezése, mely lehet ingyenes is.) szóval térjünk rá a kivitelezésre ne ezen lovagoljunk:)
    Mutasd a teljes hozzászólást!
  • Hello,

    (Persze azért valamennyi van, marketingre is gondoltunk.)

    Ha nem titok elárulod, hogy mennyi pénzt szántok az egész projektre? Hasznos info lenne szerintem másoknak is. Illetve később, akár kiderülhet az is, hogy ez az összeg mire is volt elég.
    Mutasd a teljes hozzászólást!
  • Köszönöm a hosszú választ, akkor válaszolnék:
    Login szerver - örülök, hogy ez nem csak az én fejemből pattant ki, hanem a nagyok is így csinálják.
    Tranzakciók, globális adat szinkron idő - kicsit változtattam az elképzelésen, felvázoltam magamnak egy szerverhálózatot, amiben ezeket szépen el lehet osztani.
    "Webszerver, game szerver, MMO style." - MMO szerű, de nem úgy kell elképzelni, hogy minden játékosnak tudnia kell a másik felhasználó helyzetéről, nem mozgó harcokról van szó, tulajdonképpen egyszerű lekérdezések, sőt, a felhasználó helyzete se kerül folyamatosan elküldésre a szervernek, kizárólag ha valamire rákattint. (Sajnos a csalások elkerülése miatt persze az lenne a jó, ha azt is időközönként küldené a szervernek, de nem tudom, hogy ez hogyan oldható meg, hogy annyira ne terhelje a szervert.)
    "Fejlesztési logisztika" - üzleti és tanuló. Üzleti abból a szempontból, hogy ha befut akkor ez jó pénzt hozhat a konyhára, tanuló abból a szempontból, hogy ilyen nagy rendszert még nem csináltunk. Ugyanakkor itt jön a lényeg, minél előbb szeretnénk, amibe nem fér bele több éves tanulás, és mivel nem vagyunk Niantic, ezért tőke sem áll annyi rendelkezésre. (Persze azért valamennyi van, marketingre is gondoltunk.) Ezért szeretnénk egy olyan rendszert kiadni, ami a mi jelenlegi képességeinkkel megvalósítható, mégis azért működőképes, és ha befut a cucc (ami annyit jelent, hogy akkor már pénzünk is több van) akkor komplett megbízhatunk bárkit a fejlesztésre.

    Szóval igazad van, hogy felesleges addig a többin izzadni, mégis valami alap dologgal el szeretnénk indulni.

    A jelenlegi terv szerint úgy nézne ki, hogy lenne egy fő szerver, ami az user_id, email, szerver_id adatokat tárolja. Regisztrációkor kap egy helyileg közel szervert, ahol az összes user adatok vannak, a fő szerveren csak az van tárolva, hogy hova tartozik a user. Ezt az app megjegyzi, tehát ezt a fő szervert nem kellene terhelni, kivéve a regisztrációkor. Plusz ha egy user rákeres egy másik userre email cím alapján, akkor ettől a szervertől kellene lekérdezni, hogy hol van a user, de erre például lehetne másolatokat készíteni erről az adatbázisról, aminek nem fontos az azonnali szinkronja.
    Ezek alapján, ha esetleg tranzakció történik, akkor az amúgy is POI-kon történik, amik helytől függően több különböző szerveren vannak, így az adott tranzakciót elég elvégezni azon az egy szerveren. Megoldható. Ami problémás, ha a felhasználó adatai például az európai szerveren vannak, de elutazik amerikába és az amerikai szerveren vásárol, ott csatlakozik az amerikai szerverre, onnan visszaellenőrzi az európai szerveren az user adatokat, ott picit ez hosszabb folyamat, de ez ritka.
    Ehhez egyelőre php+mysql a terv, de lehetséges, hogy inkább nodejs-re van szükség, és a kliens websocket-en keresztül kommunikál a nodejs-el és az adatbázissal, de nem tudom, a szerver hány nyitott kapcsolatot képes elviselni. Nodejs-el még nem dolgoztam, de ha az jobb megoldásnak tűnik, beletanulhatok. Vélemény? És ha már váltok php-ről, a mysql maradhat, vagy az is inkább akkor mongodb például?

    Köszi mindenkinek!
    Mutasd a teljes hozzászólást!
  • Ha skálázható megoldást szeretnél, akkor a felhasználók azonosítására használj JWT-ét és legyél stateless.
    Mutasd a teljes hozzászólást!
  • Szia,

    Bevallom töredelmesen, nem olvastam el részletesen a teljes thread-et, mert a végére már belefáradtam a kissé kusza dolgokba, szóval címszavakban reagálnék pár gondolatra.

    Login szerver. Teljesen bejáratott dolog a gyakorlatban masszív rendszereknél is a központi login szerver. Az egy külön döntésed, hogy engedsz-e egy usert többször is belépni. Van példa olyasmire is (lásd diablo2 több cd key esete). Minor adatreplikát ha csinálsz a login szerverhez, lehet tehermentesítésed minden városban is akár. Adat átíráshoz használj write around cache policy-t. Ha egy user csak 1 példányban léphet be, akkor minor replikából is csak 1 lehet, és a központi login szervered sem login adatokat tárol, hanem csak a cache szervereket vezérli adat invalidáláshoz, de olyasmi csak nagyon nagy felhasználó számnál van.

    Tranzakciók. A tranzakció egy rendszerre globális eszköz. Akár 20 ezer szervered lehet, ha tranzakciót használsz, az mind a 20 ezer szervert is meg tudja akasztani, mert ott a felhasználók egyetlen logikai sorba fognak beállni, és egymásra várni. Nagy terhelésű rendszerben jellemzően nem használnak tranzakciót, illetve adatcsoport lock-ot ha használnak is, azt sosem közösen elérhető adatokra.

    Globális adat szinkron idő. Nemzetközi alkalmazásoknál el kellene fogadni, hogy 35 másodperc alatti globális szinkron időt nem írsz elő. A 10 másodperc alatti szinkron már egyébként is a gyakorlati képtelenség határa, és akkor 5-6 másodpercet láttam leírva - nonszensz. Már a 10 sec-et elérni, és a közelében maradni olyan extra szerver költséget fog jelenteni, hogy úgysem fogod akarni azt kifizetni. Ami feature nem tud elfogadni globális frissítésben mondjuk 50 másodpercet is, azt nem fejleszted ki. Mert rossz ötlet. Használj kerülő utat, vagy zónázz, vagy valami.

    Webszerver, game szerver, MMO style. Nem tiszta nekem, hogy webszervert akarsz fejleszteni, vagy valami MMO-szerű játékot, vagy egy kisebb csoportot játékot. Zavaros a topic abban a kérdésben. A webes alapú alkalmazások tipikusan lassúak. Azok úgy mennek, hogy a böngésző folyamatosan kérdezgeti a webszervert, és lévén véges a webszerverek terhelhetősége, nem kellene olyan túl gyakorira rakni az pedig várakozási időt is jelent. A bináris játék szerverek tudnak jobb reakció időt adni, de azok meg nem a nagy egész felhasználói táborban működnek, hanem "betöltenek" mondjuk 6-8 playert egy aktív közös játékba, és az egy adott dungeon példányon fut. Amikor valaki kilép, akkor frissülnek ki az adatok publikusba. Ahol több játékos lehet közös területen, ott nem fejlesztenek aktivitást igénylő feature-t. Azok csak dungeonökben lehetnek, ahol meg túl sok játékos nem lehet egyszerre.

    Fejlesztési logisztika. Vakarom a buksit azon, hogy a gyakorlatban hogyan fordult elő olyan helyzet, amiben vagy? Ha tanuló projected van, hogy értetted azt, hogy nem akarod megtanulni a részleteket? Ha meg üzleti projected van, hogy érted azt, hogy nem a pénzből indulsz ki? Szóval nem értem. A gyakorlatban el lehet indulni scriptes alapon, ami egy verzió 1, maximum 10k regisztrált felhasználóig, amiből talán online lesz egyszerre 15%, és az ő átlagos aktivitásuk 1% (ezek gyakorlati adatok). 1 szerver elég, berakod a tárhelyparkba, és jól van ott. Ha üzletileg nem tudsz pénzt kivasalni a felhasználóidból, akkor sza* az ötlet, kukába dobod. Ha tudsz belőlük pénzt vasalni, majd akkor nekiesel fejleszteni egy verzió 2-t, és azt sem elméleti alapon, hanem azzal kezded, hogy mennyi pénzt tudsz vasalni a felhasználóból, akinek milyen informatikai hátteret fognak igényelni az akciói, és a felhasználó számod addig fog tudni fokozódni, amíg a teljesítmény fokozás okozta hatékonyság veszteség még nulla fölött tudja tartani az üzleti matekot. A scriptes háttér egyébként hulladék hatékonytalan, a php pld 95%+ szerver craftot pocsékol, szóval kukás, de kicsi számnál az még elmegy, mert egyszerű. Majd verzio 2-re készülhetsz cgi-hez (binárisban fogod megírni a szerver oldali logikát), verzio 3-ra pedig custom bináris webszerverre (és relációs helyett is valószínűleg hálózatos adatbázisod lesz), de azok még nem az elején. A legelején annyi a lényeg, hogy 10ezer webes ötletből 9999 szimplán csak sza*, és sosem fog eljutni a verzió 2-ig sem. Vívd meg az első csatát, és majd jelezd, ha győzelem született. Fogalmam sincs, minek addig izzadni a többin?
    Mutasd a teljes hozzászólást!
  • Igen, én is most így gondoltam, de most nem igazán értem,

    Most akkor melyik? XD  Így gondoltad vagy nem érded?

    Nem igazán értem a kérdésed vagy a problémát, de megpróbálok válaszolni.

    azaz hogy a user adatai melyik régión vannak), azt csak a fő szerver lekérdezéséből tudom meg.. vagy rosszul gondolom?

    Nem. Jól gondolod.. azt hogy melyik régióhoz tartozik a júzer azt csak a fő szervertől tudod meg. Ez az ára annak, hogy egyben kezelhesd. Meg persze egy kis plusz idő és erőforrás bejelentkezéskor. Ezért írtam, hogy bejelentkezéskor így 2 kveri kell. Az első kérés a "fő" szervernek megy, hoyg megtudjuk a régiót.
    A második kérés meg a régió szerverének megy, hogy beléptesse email és jelszó alapján.

    Igaz, ha egyszer már belép a user akkor azt el tudom tárolni az app-ban, tehát a probléma akkor van, ha ez az infó nincs meg, akkor mindenképpen egy fő szervert kell megnyitnia minden usernek, vagy esetleg erre létezik más (egyszerű) megoldás, vagy kezdetnek ez is megteszi?

    Nem értem mi a gond.. El lehet, sőt írtad is hogy el tudod tárolni. Onnantól kezdve miért ne lenne meg? -am meg ha valami csoda folytán valahogy "elveszne" mégis (magic), akkor értelem szerűen és egyéb lehetőség híjján kilépteted, hisz nem fogod tudni, hogy melyik szerverrel kommunikál. Vissza logol és megint megvan.

    Egyébként, jobban belegondolva, még az sem feltétlen szükséges, hogy minden alkalommal a 2 lépcsős belogolás történjen meg, hisz el lehet tárolni pl egy hónapra (vagy valamennyire), az app-ban / a telefonon, hogy melyik régiót használja. és akkor havonta egyszer frissíted csak az infót a telón és 2 lépcsőben jelentkezteted be. Időlimit sem törvényszerű, de azért ajánlott, biztos ami biztos.
    Mutasd a teljes hozzászólást!
  • +1 ha a reg a fo szervert hasznalja, a loginhoz pedig slaveket csinal, valamint az userek keresese is a slavekbol tortenik, akkor hogyan lehetseges pl az europai fo szerverrol amerikaba "slavelni" az adatbazist google cloudnal? Mert a kezelofeluleten ilyen replikaciot csak azonos regioba engedi, legalabbis en ugy lattam..
    Mutasd a teljes hozzászólást!
  • Igen, én is most így gondoltam, de most nem igazán értem, tehát a login legyen helyi szerveren, viszont ha a régiazonosítót (azaz hogy a user adatai melyik régión vannak), azt csak a fő szerver lekérdezéséből tudom meg.. vagy rosszul gondolom?
    Igaz, ha egyszer már belép a user akkor azt el tudom tárolni az app-ban, tehát a probléma akkor van, ha ez az infó nincs meg, akkor mindenképpen egy fő szervert kell megnyitnia minden usernek, vagy esetleg erre létezik más (egyszerű) megoldás, vagy kezdetnek ez is megteszi?
    Akkor annak a szervernek meg valami hiper szuper jónak kell lennie. :)


    csak megjegyzés:
    Megértem mindenki aggodalmát, nem is akarok én elsőre tényleg olyan rendszert építeni ami aztán húde, a Facebook sem több ezer szerverrel nyitotta az első napját, de az app kiadását hosszabb ideig tartó marketing előzi meg, talán sikerül még a médiába is bejutni, szóval kezdetnek azért minden kontinensen (na nem az Antarktiszra gondolok) kellene 1 szerver. Na meg nem is együtt lenne kiadva mindenhol, azaz egy régióból lehetne következtetni a többire. Plusz már a marketing során is tudunk következtetni a várható felhasználói létszámra. Csak tiszta képet szeretnék, hogy a tervezésnél már ezekre fel legyünk készülve.
    De tény köszönöm a kommenteket, mert így most már a fejemben is jobban összeállt a kép, hogy hiszen tényleg el lehet osztani a usereket..
    Mutasd a teljes hozzászólást!
  • Igen az nagyon ritka, de ezt írtuk már.

    Tulajdonképp meg is válaszoltad az újabb kérdéseidet (jóformán) :)

    A reg mehet egy szerverre, de a login szerintem inkább legyen régiós, mégpedig azért, mert ha ujra kell logolni egy frissítés miatt (vagy akármi miatt), akkor egyszerre sokan akarnak majd visszamenni, azt meg nem fogja szeretni egy szerver. Bizonyára megcsinálná, de nekem nagyon nem tetszene egy 1-2 perces várólista, hogy belogoljak..

    Aztán a másik hasonló gond az idő.. pl itt európában kb este 6-8 ig van az az időszak mikor minden jóérzésü ember a nap fáradalmait kipihenendő, bejelentkezik a neki kívánatos alkalmatosságba (fészbuk, LoL, WoW, kutyafüle) Tehát ebben az időszakban is a bejelentkezésre viszonylag nagyobb terhelés érkezik.
    (máshol meg a másholnak megfelelő időszakban)
    Mivel mobil app-ról van szó, ezért bizonyára jóval kevesebb, mint egy asztali játék esetében, de azért érdemes lehet számításba venni.

    a 10.000 beloginolt felhasználó üti 10-szer azzal mire gondolsz?

    És persze az "akciók" (szerintem erre gondolt) is a régiónak megfelelő szerveren, de ezt már megtárgyaltuk.

    id, email (
    vagy nicknév, igazából tökmind1 szerintem, te tudod mennyire lehet gond ha a nickől lehet több is eltérő régiók esetén
    ), régióazonosító lehet egy "fő" szerón a bejelentkezés és minden más meg a megfelelő helyi szerveren.

    A bejelentkezéshez így 2db lekérdezés kell ugyan, de bejelentkezéskor édes mind1 még az a plusz 7-800 ms lehetne akár 3 mp is.. a bejelentkezésre várást sokkal jobban tűri a juzer mint a játék közbenit.

    A játékban már kevésbé, még akkor is ha "csak" egy pokemon go, azért az nem baj ha a lehető leggyorsabban válaszol.. Viszont nem egy real time cucc, szóval megfeszülni, megfeszíteni érte a szervereket/magatokat nem kell. Az 1 sec válaszidő szerintem beleférős.


    persze csak ha tényleg indokolja a júzerek száma..
    Mutasd a teljes hozzászólást!
  • Arra gondolok, hogy 10 000 user * 10 query * 500 ms nem lesz (valószínűleg) kiszolgálva a szerver által. De ez querytől is függ.

    A pokelabdás eventekhez meg nem relációs adatbázist használnék, hanem valami specifikusan erre kitalált dolgot. Mivel hasonlót (játékot) még nem csináltam, így nem tudok neked pontos útmutatást adni. 

    De pl ahhoz, hogy a felhasználók interakciót végezzenek egymással, használhatsz rabbitmq-t, hogy eloszd a bejövő eventeket különböző queuekba. Így csak azok a felhasználók kapnák meg akik az adott régióban vannak. 

    De amúgy a neten millió cucc van amit el lehet olvasni, de tényleg, ezeket ki kell próbálni, és a pontos, elvárt működés ismeretében lehet tanácsokat adni.

    Kiindulásnak pl: A Beginner's Guide to Scaling to 11 Million+ Users on Amazon's AWS - High Scalability -
    Mutasd a teljes hozzászólást!
  • Miert nem probalod ki egyszeruen hogy mennyit mennyit bir egy szerver, valamilyen terheles tesztelovel?

    A helyedben nem nem kezdenek bele elosztott rendszer fejlesztesebe amig nincs bevetel es nem latszik pontosan mire van szukseg. Alapbol egy penztemeto, de ha meg nem is tudod pontosan hogy mire van szukseg biztos hogy hasznalhatatlan lesz az eredmeny.

    Vegtelen skalazodas nem letezik.
    Mutasd a teljes hozzászólást!
  • Tehát a reg és a login működhet egy szerveren, ha utána az userek keresése már slave-ken megy?

    a 10.000 beloginolt felhasználó üti 10-szer azzal mire gondolsz?

    ---
    annyi még lemaradt az előbb, hogy a tranzakciók és hasonlóknál az userek általában helyileg közel lesznek, azaz tegyünk fel egy pokemonos példát, pokelabdat egy magyarországi nem fog várni egy amerikai pokestoptól. Tehát tulajdonképpen 2 user nagyon ritkán kerül kapcsolatba úgy egymással, hogy különböző szerveren vannak. Európainak nem kell tudnia az amerikában történtekről, maximum akkor kerül kapcsolatba, ha utazik, vagy levelet váltanak egymásnak, de ez is gondolom ritkább eset.
    Mutasd a teljes hozzászólást!
  • Ez mind attól függ, hogy hány felhasználód van, és hogy hogyan működik a rendszered. 

    Pl: Felhasználó azonosítás. Tegyük fel, hogy van 10 000 000 felhasználód, ezen egy email cím alapján a keresés, tart nemtom, 3 miliszekundumig megfelelő indexekkel?

    Tehát loginkor elég egy szerver, még a telefonom is ki tudná szolgálni. 

    10 000 beloginolt felhasználó üti az adatbázist másodpercenként 10szer? Na az már nem fog menni. Ez tervezési kérdés.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy igazatok van, és én akartam túlbonyolítani az egészet.

    Viszont igen, ezért is írtam, hogy a POI-k listája stb., megoldható külön szervereken, viszont a felhasználók adatbázisának valamennyire egyeznie kellene..
    Ne a nicknevet vegyük alapul, abból lehet több is, egy usernek ne kelljen találgatnia hogy melyik nem foglalt még, a nagyonb rendszerek email címes azonosítást végeznek, abból biztos nincsen 2, mint egy keresztnévből pl. Tehát az email címet vegyük alapul, egy email címmel egy felhasználó lehet csak, függetlenül, hogy hol helyezkedik el a világban.
    Ha ez az egyik szerveren létezik másikon nem, az nagy zűrt tudna kavarni. (Tegyük fel ha másik szerveren ugyanazzal akar regisztrálni..)
    Szóval ha mást nem is, de legalább a felhasználók kezelésének azonosnak kellene lennie, ha nem is minden adatnak, mert azok játék közben gyakran változhatnak, legalább a regisztrációhoz és a bejelentkezéshez szükséges adatoknak.

    Elképzelhető megoldás lenne a következő?:
    1. Az userek email címe egy fő adatbázisban van, mely tartalmazza még azt az adatot, hogy az user melyik szerverre van regisztrálva.
    Regisztrációkor ezt a fő adatbázist használja, helyileg közel kiválaszt egy szervert, melyet a fő adatbázisban eltárol, hogy melyiket. A helyileg közel szerveren kerül létrehozásra a felhasználó minden adata, úgy mint email jelszó és minden ami a user adata.
     Bejelentkezéskor a fő adatbázisból lekérdezésre kerül, hogy na mégis melyik szerveren pihen a user adatai, utána pedig azt használja a kliens, ott történik az email jelszó ellenőrzés, munkamenet létrehozás, és onnantól kezdve a POI-knál és mindenhez azt a szervert használja.
    Ebben az esetben a fő szerver csak regisztrációnál és bejelentkezésnél lenne terhelve, valamint akkor, ha egy európai user kapcsolatot akar teremteni egy másikkal, akkor a fő adatbázisból kérdezi le, hogy az a user hol található.
    Ez így szerintetek? Ezzel el van kerülve a duplauser, valamint így minden szerverre kevesebb terhelés jut, bár nem tudom, a fő szerver ezt mennyire bírná el.
    >> de akár a fő szerverből lehetnek slave-k is, azaz az tényleg kizárólag a regisztrációnál lenne használva, utána a bejelentkezés felhasználó keresés már működhet helyi szerveren. - de itt egy probléma, ami még nem teljesen világos számomra, bejelentkezéskor akkor is kell egy fő szerver, ami kiosztja, elvégre a kliens honnan tudná önmagától, hogy melyik szerverre kell csatlakoznia? Persze ezt az infót eltárolhatom az app-ban, de ha letörli új telefon, akkor nem fogja tudni, szóval akkor mindenképpen a fő szerverre kell csatlakozni.

    nem tudom mennyire ésszerű megoldás, jól látom-e a dolgokat, várom a véleményeteket:)
    Az biztos, hogy ezt jó alaposan meg kell tervezni, de ha már kiindulási alapnak ez az elmélet jó, akkor neki lehet állni részletesen kidolgozni.

    Az app jellegéből adódóan ez azért nem annyira realtime játék, hogy harcolnak egymás ellen és mindenkinek látszik a GPS pozíciója, azaz nincs szükség tényleg azonnali válaszidőre, lekérdezések akkor lesznek, ha az user rákattint valamire, és tényleg részletes adatokat vár, arra meg képes várni 1-2 másodpercet. Tehát elfogadható a kis késlekedés.
    Mutasd a teljes hozzászólást!
  • Szia!

    Próbáltál már LoL-ozni 700-800 ms-el?
    Még bot meccset se mennék annyival.. automatikusan alt + f4.

    Tréfát félretéve mindenben egyet kell, hogy értsek. Elenyésző a felhasználó, aki másik régióból akar játszani és az is csak rövid ideig fennálló szituáció. (mert lássuk be aki állandóra regel egy acc-ot eu-ból amerikába pl az magának csinálja a h.lyeséget.)

    Költözés esetére ott a transfer, ahogy írtad, nyaralásra meg hasonlókra 1 hétig, kettőig meg vagy bírja ki, hogy nem játszik (mégiscsak nyaral vagy üzleti úton van, ne a játékkal foglalkozzon XD) vagy bírja ki az 1 másodperces válaszidőt..

    Egy ilyen pokemon go féle cuccnál (ha jól emlékszem annak a mintájára készül valami) szerintem simán vállalható az 1 sec. (Főleg ha pár napról van szó csak)

    Nem beszélve arról, hogy az ilyen játékoknál a felhasználók 80%-a tuti, hogy multi account-ozik, ha másért nem, akkor azért hogy játszhasson akkor is, ha azt a szervert épp karbantartják. (Én is ezért készítettem egy másodikat anno a "szomszéd" szerverre).  Volt egy órám játszani de a szervert épp mókerolták..

    De az is könnyen lehet, hogy tudja valaki, hogy rendeszeresen utazik valahova 1-2 napokra és azért készít arra a másik szeróra is egy acc-ot.

    A LoL-nak kb 3ad akkora lehet a felhasználó tábora szerintem, mint a regisztráltak száma (nekem 6-8 accountom van felére nem emlékszem már).

    Szóvala  lényeg, hogy tényleg nem kell ennyire az a hókuszpókusz :)

    ha egyik regisztrálsz a másikon értelemszerüen nem is létezel.

    Ez viszont nem így van sajnos.. Legalábbis a LoL-ban. Ugyanazzal a névvel nem tudsz account-ot létrehozni a másik szerveren, mert foglalt. Kipróbáltam egy hash-el is (nicknévnek) annak idején és foglalt volt a másik szerveren mikor próbáltam létrehozni másodszor. ( Engem is érdekelt pár dolog, hogy csinálhatják:D )

    Valószínüleg mást nem, de a felhasználó neveket "egyben" kezelik / összevetik.
    Mutasd a teljes hozzászólást!
  • Szia,

    egy-két apró adalék a mostani nagy multiplayer játékok világából, ami után remélem már nem lesz kérdés kell-e ez a túlzó hókuszpókusz.
    HerosOfTheStorm, Smite, LeagueOfLegends, World of Tanks: minden régióban saját szerver, ha egyik regisztrálsz a másikon értelemszerüen nem is létezel.

    Ha belegondolsz: hány százalékát érinti a felhasználóknak ez az utazik és pont a másik régióban is játszani akar helyzet ? és ha onnan játszik, akkor mi lesz ? 100ms helyett lesz 7-800 millisec a válaszidő. na bumm... nem hiszem el hogy akkora probléma lenne.

    Amugy erre is kitalálták már a nagyok a megoldást:Account transfer-nek nevezik.
    Egyszerüen átrakod a felhasználó teljes cuccát egy másik régióba - ha már annyira kedvezni akarsz neki. (de ez inkább költözés esetén a fontos)
    Mutasd a teljes hozzászólást!
  • Gyors választ akartam adni, bocsánat. :)
    Szóval nézzünk egy alapvető felépítést, 1 millió aktív userrel számolva (tekintsünk el attól, hogy ennyi lesz-e, ez egy felvetés, amelyre fel szeretnék készülni, különben nem nyitottam volna témát.)

    2 adatbázist fognak használni, egyik az OSM térkép adatbázisa, az egész világ kb. 500 GB, ebből vektoros csempék lesznek előállítva, bejelentkezéskor lekéri a kb. körülötte lévő 50km-t amit a kliens eltárol, így itt újabb lekérdezés akkor lesz, ha ebből a körből kilép, ez azért ritka lesz. (Bár a térkép rész nem az én reszortom.)

    A másik adatbázis, amiben a felhasználók lesznek, a POI-k (melyeket módosítani tudnak, ezért sem az OSM adatbázisában szerepel) és azoknak adatai, a levelezés, stb.
    Ez az adatbázis kb. 50 táblából áll, 1 millió usernél: az userek tábla 1 millió rekord, 1 tábla kb. 1,5-3 millió rekord, 20-30 tábla 20e-100e rekord.
    Lekérdezések száma 1 userre tekintve: bejelentkezéskor, a következő lekérdezés ha egy POI-ra kattint, ott több lehetőség is van. Úgy gondolom, hogy 1 user átlagosan óránként 20-30 lekérdezést produkálhat, attól függ mit csinál, lehet, hogy 1 óra játék alatt mindössze 1-et, de lehet, hogy sokkal többet, a 20-30-at talán egy átlagos értéknek tekinthetjük.
    Tranzakciók átlag 1-10 millió új rekord/nap, plusz a levelezés (bár ez ritkább lesz) is lehet néhány millió.

    Tulajdonképpen a térkép lehet több helyen a világban, azokon a felhasználók úgysem változtatnak, így az megoldódhat így. A többit esetleg master-slave alapon is meg lehetne oldani, mert a tranzakciókat leszámítva semmi sem olyan fontos, hogy azonnal történjen időben, azaz minden lekérdezést végre tudnék hajtani a világon bárhol, kivéve ha egy tranzakció hajtódik végre, mert akkor a master-ből kéne olvasni. Google cloud mysql-nél találtam lehetőséget adatbázis replikálására, de csak ugyanabba a régióban lévő szerverre, mint ahol a master adatbázis is van..

    Esetleg egy másik felmerülő megoldás, hogy tegyük fel európa ázsia amerika. A térkép fent van mindhárom helyen, az európai user az európai adatbázisba regisztrál, a legtöbb művelet a POI-kal történik, és mivel az is hely szerint van, az is megoldható, hogy az európai POI-k az európai adatbázisban vannak, a felhasználó meg hely szerint a megfelelő adatbázisból kérdez le dolgokat. A probléma ott kezdődik, amikor egy európai user elutazik amerikába, akkor onnan is az európai szerverről tölti le az adatait? És mi van ha egy európai kapcsolatot akar teremteni egy amerikai userrel. Tudni kell, hogy annak az adatai hol találhatóak, erre mondjuk az villant be a fejembe, hogy ehhez plusz egy master slave adatbázis, ami nyílván tartja az összes usert és csak azt, hogy melyik szerveren találhatóak az adatai.
    Kicsit lehet hogy bonyolult amit most leírtam és lehet laikusan tekintek a témára, de ilyen nagy elosztott rendszert még tényleg nem hoztam létre, ezért is nyitottam a témát, hogy egy kis segítséget kapjak..

    "Miért is kell a több geolokáció ? ha 5-6 sec is lehet a válaszidő ?"
    Az 5-6 sec válaszidővel arra céloztam, hogy még mindig jobb, mint pokemon go esetében órákig nem tudtál csatlakozni a szerverre.. szóval itt nem csak az a kérdés, hogy tud-e a felhasználó várni 5-6 másodpercet, hanem hogy működjön, és inkább a működőképesség fontos a kezdetben, hiszen a pokego mögött nem amatőrök álltak, mégis leállt. Szóval ha működik, és befut, és csak annyi a baj, hogy lassú, akkor már lehet fejleszteni. 
    Itt a fontos az, hogy már az elindulásnál úgy legyen megtervezve, ha mégis tömegek regisztrálnak ne álljon meg azonnal, könnyen lehessen fejleszteni. Nyílván ez a program felépítésétől is függ, de ezért szeretném már a kezdetben néhány szerverre felépíteni az egészet, hogy utána könnyebben lehessen betenni még szervert, vagy módosítani.
    Tehát kezdetben bőven megelégednék azzal, ha minden kontinensen 1 szerver van, és a felhasználók kapcsolatba tudnak lépni egymással.
    Mutasd a teljes hozzászólást!
  • Szia,

    már bocs, de úgy tünik hogy elég laikusként vágsz bele az egészbe, pl: az hogy lehet hogy nem tudsz adatbázis méretet becsülni ?
    ezt azért egy kis analizis után meg kell tudni becsülni,
    mezők száma, várható sorok (tranzakciók száma) egy idő intervallum alatt, és mondjuk számítsd át egy évre.

    ha nem tudod hogy mekkora adatbázist akarsz akkor honnan tudod hogy több szerver kell ?
    ha a válaszidő 1-2-sec simán lehet, akkor egy high-end szerver (xeon 16c32t,3x2T winyo,128G ram), elég nagy adatbázist ki tud szolgálni tök egymagában, és akkor az bárhol lehet a világon.

    és persze akkor amit denzelii is írt, ha tényleg elosztott - több lokáción elhelyezett szerverekről lenne szó, akkor nincs olyan hogy te írsz egy "kliens" oldali részt és majd a DB réteg elintézi a több szerver kezelés, ilyen esetben a "kliens" ill. DB layernek durván kéz a kézben kell dolgoznia a userek kiszolgálásán az adott arhitekturát figyelembe véve, tehát ha particionált például egy tábla, akkor eleve a kliens oldal már ennek tudatában készül a lekérdezésre és annak eredményére.

    Másik:
    hogy lehet hogy a DB méretet nem tudod megbecsülni de az aktiv usert igen, ami szerintem nagyon mellé megy, mivel egy 1 milliós user bázisnál koránt sem 10% az aktiv user, sokkal sokkal kevesebb, és az aktiv user szám sem nyomkodja tized másodpercenként azt a bármilyen programot is.

    de ha mégis
    én akkor is egymás mellé raknék egy szerver teremben 2-3 high-end gépet
    ha már akkora terhelés lenne, és a szük keresztmetszet függvényében szétosztanám az adott réteget, web/db/api ami lassú.

    Egyébként honnan tudod hogy a DB lesz a szük keresztmetszet ?

    Miért is kell a több geolokáció ? ha 5-6 sec is lehet a válaszidő ?

    szóval sok sok kérdés merül fel

    amúgy szerintem te a google/facebook és egyéb oldalakat kicsit túl misztifikálod, ill félreértelmezed, azok sem szinkronizálnak egymással realtime, sőt minek is szinronizálnának, hiszen akkor ugyanaz az adat lenne mindenhol, pont forditva, durván szét van particionálva, pl: a te google mailbox-od az egyik europai node-on pihen, a rendszer tudja hogy hol, és a load balancer oda rak át, ill. onnan kérdez le.
    Mutasd a teljes hozzászólást!
  • Kinga:
    pontos adatbázis méretet nem tudok mondani, de akkor kicsit részletesebben az adatbázisról és tartalmáról:
    2 adatbázis:
    1. osm térkép adatbázis (az userek a világ minden tájáról ezt használják a térképhez, ugyanis az appnak ez is egy fontos eleme)
    2. A felhasználók, "poi"-k, adatbázisa. Ez körülbelül 50 táblából áll, kb. 10-30 mezővel, a tartalom nagyrészt igaz/hamis, vagy egy szó, vagy egy szám, ettől a levelek térnek el, ahol nagyobb tartalmat is írhatnak a felhasználók. Plusz a munkamenetek kezelése, mely nagyobb terhelést okozhat.

    2. elfogadható válaszidőnek én azt mondom 1-2 másodperc simán elfogadható, esetleg 5-6.

    Denzelii: köszönöm amit írtál, viszont valahogy mindenképpen neki szeretnék állni, ha nem is óriási terhelésre felkészülni, de tényleg pl. kezdetben 1 millió usert 1-2 szerverrel össze akarok hozni, ahhoz kellene segítség. Ha befut és nagyobb a tőke, lehet fejleszteni..
    Mutasd a teljes hozzászólást!
  • megoldja, hogy ami egy ingyenes tárhelyen php+mysql működik, és meg tudom csinálni, az működjön több millió felhasználónál a világ bármely pontján.

    hát a trükk ott van, hogy ez nem úgy megy, hogy csak a db komponenst kell így megírni, hanem az egész software/hardware archetektúrát igazítják hozzá. A facebook is, meg a többiek is.

    Én sok whatsapp-s publikciót olvasgattam, ők tök sok mindent leírtak:
    https://www.quora.com/What-is-WhatsApps-server-architecture
    How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second - High
    (meg lehet keresgetni még whatsapp témában, érdekes az 1M user per server socketes probléma is)

    Tudom nem linket kértél, meg ez nem is megoldás neked, de pont azt akarom ezzel megmutatni, hogy az az app (software architektúra) ami tök jó kis forgalomra 1 node-n, azt kb semmit nem ér több node-n, nagy forgalomnál. Mindig meg kell keresni a szűk keresztmetszetet, és azt a részt kell hozzáigazítani. És pont az a tök jó a sok whatsappos cikkekben, ahogy erről az útkeresésről írtak.

    Oké, neked nem kell ekkora skálázódás, de több node-ra, szerintem pont az egész cuccod újra kellene tervezni/írni, aminek igen egy része az adatbázis, meg az eltérő geolokáció. Ez még aztán nagyoknál sincs ingyen, hát még a kicsiknek.

    Így még továbbra is a tanulás olvasás, kipróbálást javasolnám, főleg ha tudsz projektbe társulni ahol van ilyen, közben meg keresed az embert/csapatot akiknek megvan ez a tudásuk.
    Mutasd a teljes hozzászólást!
  • Szia,

    két gyors kérdés mielőtt hosszabban írnék,

    1., milyen adatbázis mérettel kell számolni ?
    2., milyen az elfogadható válaszidő egy lekérdezésnél vagy tranzakciónál ?
    Mutasd a teljes hozzászólást!
  • Én ezeket néztem:
    Configuring an Instance for High Availability  |  Cloud SQL for MySQL  |  Google Cloud Platfor
    - itt kezdetben úgy néz ki, mintha néhány kattintással létrehozhatnék replikációt, bár ahogy próbáltam, csak úgy működik, ha ugyanazon a szerveren hozom létre ahol a master is van. (Az meg értelemszerűen nem a legjobb, az európai az európai szerverhez csatlakozzon, ne az amerikaihoz.. gondolom én legalábbis..)

    +1
    Datastore - NoSQL Schemaless Database  |  Google Cloud Platform
    Itt azt írja automatikusan replikálja, de ezt sem értem, akkor én hogyan állítom be, hogy az adott user a master-ből kérdezzen le egy bizonyos dolgot, vagy hogyan működik.

    De végezetül ezekre máshol azt a választ kaptam, hogy ezek igazából a szervert adják, a lehetőség van meg az adott dolgokra, de ettől függetlenül nekem kell beállítanom leprogramoznom mindent, hogy mi alapján működjön, és hogy nulla tapasztalattal lehetetlen egy ilyen rendszert elsőre jól megírni. Nem is próbálkoznék, mivel nincs ilyenben tapasztalatom. Nekem az lenne az egyszer megoldás, ha a jól bevált php + mysql adatbázisomat egyszerűen fel tudom tölteni valahova, aztán onnantól kezdve működik bármennyi usernél. Tisztában vagyok vele, hogy ilyen nincs, csak nagyjából közlöm mennyire értek ehhez a részhez.. nem ingyenes tárhelyet használok, de körülbelül úgy tudnám szemléltetni, hogy amit ingyenes tárhelyen meg lehet valósítani, azaz, hogy nincs hozzáférésed úgy a szerverhez mint egy saját szervernél, nagyjából annyira vagyok tisztában a szerverek működéséről, azaz semennyire. Ami ott működik, azt kellene átültetni úgy felhőbe, hogy több millió usernél is rendesen működjön.

    Kezdetben azt gondoltam néhány kattintás és van itt-ott szerverem és működik is a dolog, de
    gondolom bonyolultabb a dolog annál, hogy pl google cloud-ban létrehozok egy európai szervert, oda is felpakolgatom a php fájlokat, egy amerikait, oda is, lesz egy fő mondjuk ami a bejelentkezésre szolgál, és onnan pedig host alapján megadom az usernek, hogy melyiket használja. Ez így egyszerűnek tűnik, de hogy az adatbázisok replikálódjanak és mindig frissek legyenek, ez már számomra nem egyértelmű, hogy hogyan is működik. + fogalmam nincs a skálázásról stb.

    Tehát ezért is keresek inkább fejlesztőt, aki néhány szerveren ezt létre tudná nekem hozni, nekem meg elég azt megadni az app-ban, hogy melyik szerverhez vagy melyik adatbázishoz kapcsolódjon attól függően, hogy időben fontos adatokról van szó (pl. tranzakció) vagy nem.

    Esetleg a google spanner az, ami tényleg teljesen automatikus, bár működési elvét azt sem értem, plusz gondolom a teljes automatizált dolog miatt lényegesebben drágább is, 0.9$/node/h napi ~6.000 Ft kicsit sok. Persze több millió felhasználónál már megérné, ha befut az app, de kiindulásnál azért ennél olcsóbb megoldás érdekelne, mert a tesztelések is egy vagyon lenne így.

    köszönök minden linket stb., de mivel még soha nem építettem ilyen nagy rendszert, évekbe telne mire rendesen beletanulnék, ezért inkább fejlesztő kerestetik, aki nagyon leegyszerűsítve: megoldja, hogy ami egy ingyenes tárhelyen php+mysql működik, és meg tudom csinálni, az működjön több millió felhasználónál a világ bármely pontján.
    persze ez nyílván kevés ahhoz, hogy valaki megcsinálja ezt a rendszert, de ha valaki képes rá, elvállalná (ha csak részben is támogatást nyújt), akkor azzal meg tudjuk beszélni, hogy pontosan mire is van szükségem.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Keresek olyan fejlesztőt, aki a világ több pontján szerverekből álló folyamatosan szinkronizálandó adatbázis kapcsolatot létre tud hozni.
    Felhős megoldáson gondolkoztam, erre a google cloud irányába nézelődtem leginkább.
    Mivel a szerverekben és üzemeltetésben nincs nagy tapasztalatom, ezért leírom, nagyjából miről is szól a dolog.

    Egy mobil alkalmazásról van szó (unity), kicsiben a dolog végtelenül egyszerű, meg is valósítottam, az alkalmazás php fájlokkal kommunikál, a php pedig egy adatbázissal. Az userek tudnak regisztrálni, bejelentkezni, valamint rengeteg adatbázis művelet van, egy közösségi "oldalról" van szó. Ezek mind működnek kicsiben, csak nagyban szeretném. Levélküldésre is lehetőség lesz, az még kérdéses, hogy az olyasmi lesz mint itt például a prog.hu-n, vagy olyasmi, mint a facebook-on, mert előbbi esetében a php is megfelel a célra, utóbbi esetben node.js vagy hasonló dolgot tartanék optimálisabbnak. Azaz, hogy most a kommunikáció miként is zajlik, az is még átbeszélésre szorul, de a lényeg, hogy mindkettő úgyis az adatbázissal kommunikál, melyet úgy szeretnék megvalósítani, hogy több millió felhasználó esetén is működjön.

    Google cloud állítólag automatikusan tud skálázni, replikálni adatbázist, de annyira már tájékozódtam, hogy annyira mégse automatikus, ha nem mondom meg, hogy mit csináljon, akkor nem tudja, hogy mi alapján skálázzon automatikusan pl.. Ehhez a részhez nem értek.

    Fogalmam nincs, hogy a nagy terhelésű oldalak, mint pl. Facebook több tízezer szerverével hogyan oldja meg, én egyelőre csak például amerikában, európában, ázsiában, stb. 1-1 szervert szeretnék, mely igény szerint bővíthető.

    Master-slave-nek utánanéztem, ha jól tudom ez annyi, hogy van egy fő adatbázis, amibe ha történik változás, azt kis időközönként frissíti az összes többi adatbázisban, azaz elvileg elképzelhető az, hogy ha például amerikában van a master, akkor az európai 5-10 másodperccel késleltetett adatokat lát. Sajnos ez nem minden esetben jó nekem, ugyanis itt tranzakciók is végrehajtódnak az egyes felhasználók között, melynél elengedhetetlen, hogy ezek az adatok mindig frissek legyenek. Persze nem minden információ ennyire súlyos, esetleg azt lehetne megoldani, hogy ilyenkor mindig a master-ből olvasok? Vagy mások (pl. facebook), hogyan oldja meg, hogy az üzenetek mindenkihez azonnal eljutnak, pedig valószínű hogy egyik felhasználó sem ugyanazon a szerveren tartózkodik.

    Összességében fogalmam sincs a szerverek üzemeltetéséről, amit eddig életem során elkészítettem, az kicsiben történt, azaz béreltem egy tárhelyet, php fájljaimat feltöltöttem, phpmyadmin-ban létrehoztam az adatbázist, aztán ennyi. Olyannal nem volt dolgom, hogy magam állítsak össze és üzemeltessek egy szervert, főleg nem több szervert ami szinkronban van egymással. Szóval ez nekem homály, ezért is keresek olyan embert, aki át tudja látni, hogy mire is van szükségem, abban segítséget tud nyújtani, meg tudja valósítani. Nem ingyen természetesen.

    Nem akarok rögtön csillagrombolót építeni, nem arról van szó, hogy hú de jó ötletem van, ezért 20.000 szerverre van szükségem, mert senki nem így kezdte, de reklámok, korábban befuttatott oldalak miatt stb. egy minimális felhasználói létszámra fel akarok készülni a kezdetekben is, tehát kezdetben gondolkodhatunk 1 millióval, melyből ha 100.000 az online user, akkor az kb. percenként 20.000-200.000 adatbázis lekérdezés vagy módosítás/perc. Ennyit szeretnék ha elbírna az app kezdetben. A tervekben pedig az az 1 millió hamar sokszorozódhat, de addigra már lesz tőke újraíratni az egészet, ha befut. :) Kezdetben elég az előbb leírtakra felkészülni.

    Aki úgy gondolja segíteni tud a megvalósításban, van már tapasztalata ilyenben, az ne habozzon! :)
    Mutasd a teljes hozzászólást!
abcd