Óriási terhelésű közösségi oldal létrehozása
Sziasztok!
Egy olyan dologban szeretnem a segitsegeteket kerni, hogy szeretnek egy eleg nagy dolgot letrehozni, amit az egesz vilagon szeretnek elterjeszteni es fel szeretnek keszulni nagyon nagy terhelesre, azaz itt tobb szerver osszehangoltsaga lehet szukseges.
Egy mobil applikaciorol van szo, ami hasonlit a Facebook-ra.
Ertek a php-hez, mysql-hez, javascript-hez, de a szerveren hatterben zajlo folyamatok szamomra ismeretlenek, vagy reszleges tudasom van rola.
Magat amit szeretnek, nagyon egyszeruen meg tudom valositani. (Az app ennel persze lenyegesen bonyolultabb, de egy egyszeru peldat vegyunk a fobb funkciokkal)
Tehat peldaul:
Felhasznalo regisztral (php), adatbazisban tarolom (mysql), felhasznalo bejelentkezik (session_register), lekerdezi a tobbi felhasznalot, kiirja az adatait, uzenetet kuldhet neki.
Ez egy nagyon leegyszerusitett peldaja az appomnak, de az alap ennyi, tehat hogy most a felhasznalo adatairol van szo, vagy egy masik tabla adatairol az a dolog lenyeget tekintve lenyegtelen.
Mindent amit szeretnek megvalositom, vagyis megvalositottam, mert tobb hasonlo elvu weblapom volt mar.
A problema, hogy most olyat tervezek, ahol akar millios nagysagrendu aktiv felhasznalok vannak. (Hogy miert es hogyan, a tema szempontjabol erdektelen, legyunk optimistak es foglalkozzunk azzal, hogy ez hogyan valosithato meg.)
Es tudom a valaszokat is nagyjabol, php erre a celra nem jo, mysql-t felejtsem el, stb.
Egyebkent az approl annyit, hogy Unity-ben keszulne, (mivel nem csak errol szol az app) ezeket az informaciokat pedig ugy toltene be, hogy egy php fajlnak kuld adatokat, a visszakapott adatokat pedig a kliens (unity) dolgozza fel.
Nagyon sok lekerdezesre kell felkeszulni, mivel barmit is tesz a felhasznalo, adatbazisbol kinyert adatok jelennek meg, azokat modositjak, eleg interaktiv dologrol van szo.
Nem beszelve a felhasznalok egymas kozti uzenetvaltasnak, amihez ha tokeleteset szeretnenk, akkor a php+mysql tenyleg nem jo, ott esetleg node.js-re van szukseg.
Node.js-t meg sosem probaltam, de javascript, konnyen bele tudnek jonni szerintem. A kerdes, hogy akkor az egesz app azon keresztul kommunikalna, vagy csak a "chat" resz?
Plusz session-ban sincs tapasztalatom, csak amit a tarhelyem alapbol letrehoz, tehat nem en modositom es torlom, tehat session_register minden oldalon session_start es max ha kilepesre kattint akkor torli. Erre mondtam hogy a hatterben megbujo dolgokban nincs tapasztalatom. // megj.: ezen az oldalon mar olvastam, hogy session nem a legbiztonsagosabb, bar en ugy terveztem, hogy a session mellett a kliens tarolna egy tokent is, mely sessionban van tarolva, es a kliens mindig elkuldi, az pedig leellenorzi hogy stimmel-e. Itt az oldalon viszont azt olvastam, hogy kulon tablaban taroljam a bejelentkezett felhasznalok tokenjet, de ezt sem tartom esszeru megoldasnak, hiszen mi tortenne 1 millio bejelentkezett felhasznaloval? Minden egyes "oldalbetolteskor" lekerdezi hogy stimmel-e? Lehetetlen lenne.
A lenyeg tehat, hogy errol az alap php+mysql komborol at kene allnom valami jobb megoldasra, vagy azt ugy megoldani, hogy akar tobb millio felhasznalot is elviseljen, akar millios lekerdezeseket.
Erre a google cloud platformjat gondoltam, de fogalmam nincs, hogy ott ez hogyan oldhato meg. Elvileg a google automatikusan skalaz (egyebkent a skalazasrol sincs tul sok fogalmam), de nem tudom, hogyan. Letrehoztam mar egy szervert, amire feltettem egy php fajlt, de ezzel szerintem semmilyen problema nem oldodott meg, mert igy kapok egy linket, pl. Xyz1234.appspot.com/pelda.php.. de ha ezt nyitom meg az unity-vel, akkor a tobb millio felhasznalo is ezt nyitja meg, tehat a terheles ugyanugy nem oldodik meg..
Nem szeretnek lebeszelo kommenteket, sok mindenhez ertek, csak ezt a reszt nem latom at.. egy olyan hozzaerto komment kellene, aki nagyjabol segit atlatni az egeszet, es javasolni, hogy mire lenne szamomra a legkonnyebb atallni, vagy hogyan valosithato meg amit szeretnek.
Mindenkeppen szeretnem a projectet, ha kell kulso fejlesztot is megfizetnek a szerverek osszehangoltsagara (bar jobb lenne egyszerubb megoldas), ugyhogy szeretnem ha valaki tudna segiteni, hogy el tudjak indulni. / vagyis amit egy sima pl. ingyenes tarhelyen php-vel mysql-el megoldok, hogyan kell atalakitani, hogy tobb millio felhasznalonal is mukodjon.
Koszonom mindenkinek!
■ Egy olyan dologban szeretnem a segitsegeteket kerni, hogy szeretnek egy eleg nagy dolgot letrehozni, amit az egesz vilagon szeretnek elterjeszteni es fel szeretnek keszulni nagyon nagy terhelesre, azaz itt tobb szerver osszehangoltsaga lehet szukseges.
Egy mobil applikaciorol van szo, ami hasonlit a Facebook-ra.
Ertek a php-hez, mysql-hez, javascript-hez, de a szerveren hatterben zajlo folyamatok szamomra ismeretlenek, vagy reszleges tudasom van rola.
Magat amit szeretnek, nagyon egyszeruen meg tudom valositani. (Az app ennel persze lenyegesen bonyolultabb, de egy egyszeru peldat vegyunk a fobb funkciokkal)
Tehat peldaul:
Felhasznalo regisztral (php), adatbazisban tarolom (mysql), felhasznalo bejelentkezik (session_register), lekerdezi a tobbi felhasznalot, kiirja az adatait, uzenetet kuldhet neki.
Ez egy nagyon leegyszerusitett peldaja az appomnak, de az alap ennyi, tehat hogy most a felhasznalo adatairol van szo, vagy egy masik tabla adatairol az a dolog lenyeget tekintve lenyegtelen.
Mindent amit szeretnek megvalositom, vagyis megvalositottam, mert tobb hasonlo elvu weblapom volt mar.
A problema, hogy most olyat tervezek, ahol akar millios nagysagrendu aktiv felhasznalok vannak. (Hogy miert es hogyan, a tema szempontjabol erdektelen, legyunk optimistak es foglalkozzunk azzal, hogy ez hogyan valosithato meg.)
Es tudom a valaszokat is nagyjabol, php erre a celra nem jo, mysql-t felejtsem el, stb.
Egyebkent az approl annyit, hogy Unity-ben keszulne, (mivel nem csak errol szol az app) ezeket az informaciokat pedig ugy toltene be, hogy egy php fajlnak kuld adatokat, a visszakapott adatokat pedig a kliens (unity) dolgozza fel.
Nagyon sok lekerdezesre kell felkeszulni, mivel barmit is tesz a felhasznalo, adatbazisbol kinyert adatok jelennek meg, azokat modositjak, eleg interaktiv dologrol van szo.
Nem beszelve a felhasznalok egymas kozti uzenetvaltasnak, amihez ha tokeleteset szeretnenk, akkor a php+mysql tenyleg nem jo, ott esetleg node.js-re van szukseg.
Node.js-t meg sosem probaltam, de javascript, konnyen bele tudnek jonni szerintem. A kerdes, hogy akkor az egesz app azon keresztul kommunikalna, vagy csak a "chat" resz?
Plusz session-ban sincs tapasztalatom, csak amit a tarhelyem alapbol letrehoz, tehat nem en modositom es torlom, tehat session_register minden oldalon session_start es max ha kilepesre kattint akkor torli. Erre mondtam hogy a hatterben megbujo dolgokban nincs tapasztalatom. // megj.: ezen az oldalon mar olvastam, hogy session nem a legbiztonsagosabb, bar en ugy terveztem, hogy a session mellett a kliens tarolna egy tokent is, mely sessionban van tarolva, es a kliens mindig elkuldi, az pedig leellenorzi hogy stimmel-e. Itt az oldalon viszont azt olvastam, hogy kulon tablaban taroljam a bejelentkezett felhasznalok tokenjet, de ezt sem tartom esszeru megoldasnak, hiszen mi tortenne 1 millio bejelentkezett felhasznaloval? Minden egyes "oldalbetolteskor" lekerdezi hogy stimmel-e? Lehetetlen lenne.
A lenyeg tehat, hogy errol az alap php+mysql komborol at kene allnom valami jobb megoldasra, vagy azt ugy megoldani, hogy akar tobb millio felhasznalot is elviseljen, akar millios lekerdezeseket.
Erre a google cloud platformjat gondoltam, de fogalmam nincs, hogy ott ez hogyan oldhato meg. Elvileg a google automatikusan skalaz (egyebkent a skalazasrol sincs tul sok fogalmam), de nem tudom, hogyan. Letrehoztam mar egy szervert, amire feltettem egy php fajlt, de ezzel szerintem semmilyen problema nem oldodott meg, mert igy kapok egy linket, pl. Xyz1234.appspot.com/pelda.php.. de ha ezt nyitom meg az unity-vel, akkor a tobb millio felhasznalo is ezt nyitja meg, tehat a terheles ugyanugy nem oldodik meg..
Nem szeretnek lebeszelo kommenteket, sok mindenhez ertek, csak ezt a reszt nem latom at.. egy olyan hozzaerto komment kellene, aki nagyjabol segit atlatni az egeszet, es javasolni, hogy mire lenne szamomra a legkonnyebb atallni, vagy hogyan valosithato meg amit szeretnek.
Mindenkeppen szeretnem a projectet, ha kell kulso fejlesztot is megfizetnek a szerverek osszehangoltsagara (bar jobb lenne egyszerubb megoldas), ugyhogy szeretnem ha valaki tudna segiteni, hogy el tudjak indulni. / vagyis amit egy sima pl. ingyenes tarhelyen php-vel mysql-el megoldok, hogyan kell atalakitani, hogy tobb millio felhasznalonal is mukodjon.
Koszonom mindenkinek!
Kezdetnek elolvashatod
Rendben, elolvasom
Tudom, hogy ezzel kapcsolatban nagyon hiányos a tudásom, ezért is érdekelnének olyan megoldások, amivel azért el lehetne indulni.
Valóban tény, hogy ha lesz annyi felhasználóm, akkor annyi pénzem is, hogy újraírassam, de mivel ez egy teljesen új egyedülálló ötlet a világon, ezért előfordulhat, hogy tényleg hamar befut, és ebben az esetben azért egy normális appot szeretnék létrehozni. (Nézzük meg pl. a pokemon go-t, pillanatok alatt hogy elterjedt az újdonság miatt, plusz mert ugye a pokemon miatt ami régen nagy szám volt. Fagytak is a szerverek rendesen.)
Tisztában vagyok vele, hogy azért a pokemon go mögött nagy emberek állnak hatalmas tőkével, de én sem szeretnék olyan appot kiadni, ami a használhatatlanság miatt kudarcra lenne ítélve.
Lényegében végtelen egyszerű dologról van szó, adatbázisműveletek, csak úgy, hogy több millió usert is elviseljen.
Hajlandó vagyok beletanulni, ha valaki tudna segíteni, vagy aki a szerverek és az adatbázis terheléselosztását megoldaná, annak fizetni, de mindenképpen azért egy olyan appot szeretnék, ami nem rögtön az elején döglik be. Aztán persze ha azonnal sikert arat, azonnal meg lehet bízni valakiket a fejlesztésre, de legalább egy olyan rendszert szeretnék az elején is, ami pár százezer felhasználóval azért elbír.
Reklámra is szeretnék költeni még indulás előtt sokat, tehát azért egy működő appnak kellene lennie.
A google cloud platformja állítólag automatikusan skáláz stb. Azzal nem lehetne elindulni valahogy?
[szerk.]: elolvastam a cikket, igen, erről írtam is korábban, hogy ez is egy megoldás, hogy én tárolom a tokent. De nem elég, hogy minden műveletnél az adatbázisból kérdezek le/módosítok adatokat, előtte még ezt is kérdezzem le? 1 millió felhasználónál [ami nem is sok, 80.000 felhasználói létszámú oldalt már üzemeltettem és az csak Magyarországra szólt, nem a világra - persze hozzáteszem nem volt mindegyik aktív tag] ha például 100.000 van bejelentkezve egyszerre, akkor ha percenként végrehajt mindenki 1 műveletet, az legalább 200.000 lekérdezés/módosítás percenként. Plusz arról nem esik szó, hogy hogyan is tároljam. Nyílván valami random, de azt is ellenőrízni kell, hogy olyan nincs-e még.. esetleg lehetne idő+valami más alapján is generálni, így az egyezés lehetősége nem áll fent, de sok milliónál azért ennek is vannak korlátai, ha például valaki szándékosan átírja a kliens oldalon tárolt tokent, könnyen beletalálhat egy másik munkamenetbe. Erre esetleg dupla token?
És ez még csak a session, itt még tényleg az a nagy kérdés, hogy az adatbázis terhelését hogyan osszam el ennyi felhasználónál. Például több szerveren kell létrehoznom ugyanazt az adatbázist, és azokat szinkronban tartani? - De ezt sem teljesen értem, hiszen akkor minden műveletnél ugyanúgy terheli az összes másik szervereken lévő adatbázist.
Tehát ezt nem értem pontosan..
Tisztában vagyok vele, hogy nehéz fejszébe vágtam a fejem, de egyedülálló, befuthat, megéri. Még ha bele is kell tanulnom, vagy segítséget kérnem, fizetni érte. A kezemből pedig nem szeretném kiadni, így ilyen startup gyűjtögetős tőkék nem jöhetnek szóba.
Vagy magam szeretném megoldani, vagy olyan segítségével, aki a szerverhálózatot megoldja, nekem pedig az adatok küldésével, a szerveren a kapott információk alapján az adott lekérdezést/módosítást/létrehozást végrehajtásával) valamint a visszakapott adatokat feldolgozásával kell foglalkoznom csak.
Ezért gondoltam google cloud platformra, mert azt hittem az megoldja, de bonyolultabb mint ahogy elsőre elképzeltem. (Vagy csak nem látom át, mivel ilyen nagy rendszer fejlesztésében még nem volt tapasztalatom.)
Nézzük meg egyelőre chat nélkül, tehát nem kell azért olyan profi rendszer, hogy ha már egy felhasználó gépel akkor a másik felhasználó már lássa is, mert az app azért nem erről szól, nem egy facebook koppintás, egyelőre elég lenne ha az sql műveletek és lekérdezések működnének.
Tehát, hogy egy nagyon egyszerű példát írjak, mint pl. ez a weblabor. Meg tudom nézni a profilodat, írhatok az adatbázisba (pl. ez a fórum),megjeleníti, valamint egyéb blogokat cikkeket nézhetek meg. Az egyszerűség kedvéért képzeljük el, hogy ezt szeretném, meg is tudom írni php+mysql-el, de úgy szeretném, hogy több millió felhasználót is elbírjon.
Köszi.
Ha túltervezel egy rendszert,
Technológia terén egyáltalán nem ugyanaz egy nagy alkalmazás, mint egy kicsi, ez nagyon nagy tévedés. Kicsit bárhogyan össze lehet tákolni, aztán vertikálisan skálázni, a nagyhoz viszont nagyon komoly tervezés kell, hogy horizontálisan skálázni tudd, ha már egy gép nem elég neki. Csak néhány fogalom, aminek utána kéne nézni: scalability, statelessness, concurrency, ddd, rest, microservices, newsql, nosql, cloud computing, és még lehetne sorolni gondolom. Ezeknek a dolgoknak a nagy többsége olyan, hogy több könyvet írtak már róluk, hogy hogyan kellene csinálni őket, és a nagy többség még így sem érti, mert sok gyakorlati tapasztalat kell hozzá. Szóval hidd el, nem fogsz tudni ilyen oldalt írni.
A max, amit tehetsz, hogy megírod a kódot, ahogy szoktad, csak mysql helyett pgsql-re. Utánanézel, hogy hogyan kell bottleneck-eket találni php-ben és sql querykben, aztán optimalizálod a kódot. Utána meg ha nem elég neki a szerver, akkor veszel alá erősebb szervert, ameddig tudsz. Ha már a legerősebb szerver is kevés neki, akkor meg felbérelsz valakit, akinek megvan a szakértelme, hogy írja újra neked.
Azt meg sürgősen verd ki a fejedből, hogy a javascript kicsit is hasonlít a php-hez bármiben, vagy hogy ugyanúgy kell egy nodejs appot megírni, mint egy php appot, mert alapelvektől kezdve teljesen más a kettő. Chat-re rengeteg példa van egyébként, szóval ha csak annyi kell, az viszonylag egyszerűen megoldható.
Értelek.Google cloud
Google cloud platform jó irány?
Nagyon bonyolult lenne, ha ott esetleg csak néhány szerverrel indulnék pl. postgresql alapon ahogy írtad?
Valakitől már hallottam a Google Firebase rendszeréről.
Arról mi a véleményed?
(Azért vagyok egyébként ilyen, és azért is írtam, hogy már az indulás előtt nagy reklámot szeretnék neki, mert az újdonság lehet neki a médiában is akár a reklámhordozó. Ebből kifolyólag nem egy olyan dologról van szó, mint a facebook is elkezdte kicsiben és később nőtte ki magát, hanem egy pokemon go szintű dologról, ami hetek alatt tört világuralommá. Azaz egyszerűen fogalmazva: a dolog csak akkor működik, ha már az elején tömegek akarnak regisztrálni, de akkor nagyon. Erre megvannak a módszerek az app jellegéből adódóan, de erről nem beszélek, meg amúgy sem tartozik a tárgyhoz. Tehát itt az elején kell egy jól használható appot létrehozni, ha nyökögősen indulna, akkor nem jó. Garantálom, hogy ha 500 milliót be tudnék rá fektetni (app+reklámok) akkor az indulás után 1 hét múlva a világ leggazdagabb embere lennék. De nyílván a költségvetés ennél kevesebb :D de 1-2 milliót valószínű így is elköltenék reklámra, mert az életemet tenném rá, hogy működik. Plusz megfelelő módszerekkel bekerülni a médiába..)
Nodejs: persze nem mondtam, hogy 2 nap alatt teljesen érteni fogok hozzá, de ha az jó irány, akkor beletanulok.
Sok ilyen van, szerintem
Indulj kicsiben
Rengeteg olyan projektben részt vettem fejlesztőként, ami 100% hogy milliárdossá tette volna az ötletgazdát. Mindegyik ugyanazt a hibát követte el, hatalmas terhelésre készült, nagyot akart rögtön, sok featuret sok emberre. Ez nem olyan terület, hogy majd beletanulsz, tapasztalt rókák kellenek hozzá, és sok idő, ami megtépázza a lelkesedést és a pénztárcát. Ha sikerül is, és marad pénz marketingre, akkor is bukhat az egész. Lehet, hogy fasza, de senkit nem érdekel. Az egyes projektek más-más pontokon buktak be. Mindegyik remek ötlet volt, tényleg.
Nem lebeszélni akarlak, sőt. De változtass taktikát.
Prototipizálj. Építs kicsit, működőt. Targetálj kis célcsoportra, mérd hogy mennyire jön be az ötlet. Elemezz feedbacket, rilízelj gyakran. Tervezd eldobhatóra. Dobd el, ha nem működik, veszíts keveset.
Ha megvan a tényleges igény, amit számokkal alá tudsz támasztani, akkor lesz befektető és fejlesztő is. Hidd el, hetente kapok felkérést, hogy szálljak be az "új fészbuk" fejlesztésébe, ez most télleg a tuti ötlet, ez most más, milliomosok leszünk
+1
Én is ezt írtam. Egyébként a
Ja ugyanazt írjuk, csak el
A Facebook is egy összehákolt PHP cucc lehetett eleinte, bár nyilván nem láttam, de így képzelem :)
Hát ha ez igaz, akkor erősen
Elosztott rendszerek
Ha pedig költség hatékony megoldást keresel, ami nagyban is működik, akkor tanulj bele a felhő szolgáltatásokba: AWS, Azure, Google Cloud.
Már csak arra kell rájöjj, hogy juttatod el az alkalmazást több tucat szerverre úgy, hogy az alkalmazás közben fut, és nincs adatvesztés, valamint a felhasználó se veszi észre.
Már csak arra kell rájöjj,
Hát igen, "csak". :D
Felho szolgaltatasok
Engem is inkább ez a megoldás
Mivel tény és való, hogy ha saját magam akarom csinálni, akkor jópár évbe belekerülne mire kitanulom ezt a részt is rendesen, ezért olyan megoldás kellene, amivel elég nekem megírnom az appot, a php-t, az adatbázist kezelnem, a többit pedig elvégezné valami automatikus rendszer..
Ha van erre lehetőség, az érdekelne..
bamegakapa: értem, hogy miről beszélsz, de hidd el ez nem egy hirtelen ötlet, nem arról van szó, hogy hú kellene olyat csinálni mint a Facebook csak kicsit máshogy, ez egy teljesen más dolog, a terv körülbelül 10 éve van a fejemben, csak mostanra állt össze minden. Kicsiben nem tudom elkezdeni, mert a nagyobb cégek legyártanák nagyban ha meglátnák. Ezért kell olyan megoldás, amivel azért el lehet indulni (már akkor sok felhasználóval), aztán ha befut azonnal fejleszteni.
Ne érts félre, nem
Minden egyes projektnél ez volt az az érv, ami miatt nekiálltunk csillagrombolót építeni. Minden észérvet lesöpört.
Nem lebeszélni akarlak, személy szerint én sokat tanultam ezekből a projektekből és nem az én lóvém ment a levesbe, csak szóltam. Sok szerencsét ha belevágsz!
Szvsz. a nagyobb cégek nem
Ha több adatbázisra akarod szétosztani a terhelést, akkor a ddd, cqrs, aminek érdemes utánanézni. Ott külön van az írási meg az olvasási oldal, és az olvasási oldalra annyi adatbázist be tudsz tenni, amennyi szükséges. Szjani csinált php keretrendszert a témában, arra is érdemes ránézni, ha erőlteted ezt a php vonalat. link
Skálázódás
Arra érdemes odafigyelni, hogy szabadulj meg az "egygépes" és "kevésgépes" paradigmáktól a programozási módszereidben. Ha felhőben vagy clusterben programozol, ezek fognak arcon csapni: (random gondolatok ami kihullanak a fejemből, minden sorrend nélkül)
Mindazonáltal felhívnám a figyelmedet, hogy nulla tapasztalattal lehetetlen egy ilyen rendszert elsőre hibátlanul megtervezni, megépíteni. Fogsz hibázni, fogsz arcra esni, le fog állni a rendszered és el fogsz verni egy csomó pénzt az AWS vagy Google Cloud számládra mire rájössz hogy hogyan is kell ezeket hatékonyan csinálni. Éppen ezért azt javaslom neked, hogy kezdd kicsiben, fusson először 1-2 gépen egy DB-vel a cucc és figyelj arra, hogy bármikor a rendszer bármelyik komponense kidobható legyen. Nem kell rögtön telegyömöszölni az egész kódot mindenféle aszinkron hívásokkal, de ha eljön az idő, ne kelljen újraírni a fél rendszert. Éppen ezért a clean code elveket nagyon komolyan ajánlom alapos tanulmányozásra.
Ha konkrét kérdésed van, akkor természetesen állok / állunk rendelkezésedre.
Akkor válaszolok
bamegakapa:
Valóban, az is elég kicsiből lett nagy, ahogy nőtt a létszám, úgy a bevétel is és ezért nyílván folyamatosan volt idő fejleszteni. Sőt, az első mobil appjuk is egy sima html5 alapú app volt. Ebből indultam ki, mikor elkezdtem fejleszteni cordova segítségével az appot. Aztán rájöttem, hogy a 3D-s megjelenés webes javascripttel, babylonnal nem a legtökéletesebb megoldás lesz, utána álltam rá a unity-re.
Az én appom viszont tényleg nem kezdhet kicsiben, persze nem azt mondom, hogy azonnal 1 milliárd felhasználóval akarok számolni, mint a Facebook, de 1 millió az reális lenne, legalábbis úgy szeretnék elindulni, hogy annyival elbírjon. (ügyes marketinggel és feliratkozással kezdődik az egész még az app megjelenése előtt, így a megjelenéskor már nagy mennyiségű felhasználói létszám esedékes..) Annyi elég, aztán ha megvan az az 1 millió felhasználó, ahogy tervezem, akkor már nem kérdés, hogy nagyobb tőke is lesz fejlesztésre, aztán megbízok valakit aki újraírja az egészet.
Az appot tényleg leginkább a pokemon go-hoz tudnám hasonlítani, nem kicsiben kezdte, de pillanatok alatt elterjedt. Itt az ötlet a lényeg (meg persze a tőke a média stb..) A felhasználók létszámát is ahhoz tudnám hasonlítani. Persze tisztában vagyok vele, hogy ez nem csak úgy a szánkba hullik, de az app mivoltát tekintve és a stratégiát nem elképzelhetetlen. De nem is ez a lényeg, hanem a kivitelezés.
Szóval kezdjük újra, a Facebook-kal lehet egy kissé túloztam, nem 1 milliárd felhasználóról van szó és nem szerverparkokról 180.000-es számú szerverrel, hanem néhány szerverrel, amivel el tud birkózni az app 1 millió felhasználónál. A későbbiekről ne beszéljünk, azzal megbízok majd valakit, ha úgy van, abba évek kellenének, hogy beletanuljak, ebben igazatok van. Egyszerű megoldás érdekel az indulásra.
inf3rno:
Nem erőltetem a php vonalat, valószínű minden a kliens oldalon kerülne leprogramozásra, azaz a kliens csak változókat küldene és fogadna, amiket a kliens a kapott értékektől függően jelenít meg. Azaz nem végtelen hosszú php fájlokról van szó. (Bár kezdetben amikor tesztből php+mysql alapon html5 alapú appot készítettem, ott komplett tartalmakat töltött be ajax segítségével az app, de aztán hamar rá kellett jönnöm, hogy az App Store ugyanazzal a lendülettel utasítaná vissza ahogy beküldtem, mert nem díjazzák, ha a tartalmat én bármikor módosíthatom, mert így a játékból hirtelen egy pornó oldal is megjelenhetne a felhasználóknak.) Szóval minden a kliens oldalon dől el, a php / vagy valami más pedig csak maximum ellenőrzi, hogy tényleg van-e jogosultsága az adott tevékenység végrehajtásához, aztán egy sql művelet, majd pedig visszaadja az eredményt. Ezzel arra akarok célozni, hogy nem annyira fontos a php, mivel nem végtelen hosszúságú php fájlokról lenne szó, csak néhány ellenőrzés és sql művelet, így könnyű átállni egy másik, gyorsabban futtatható nyelvre.
Ezért is mondtam, hogy akár a node.js-től sem zárkózok el websocket-en.
Tudom, hogy kezdetleges a tudásom hatalmas rendszerek építéséhez (sőt, a hatalmas rendszerek kiépítése inkább közelít a 0-hoz), de mégis el szeretnék indulni valahogy.
Kellene aki tényleg ebben tudna nekem segíteni, esetleg egy olyan rendszer, ami a nehéz részét megoldja helyettem, csak indulásképpen. Nem százezer szervereket akarok mint a Facebook, csak nem kell kvantumfizikusnak lenni ahhoz, hogy 4-5 vagy 9-10 szervert összekössünk a világban.
Amit nem értek:
oké, tegyük fel utánajárok és beletanulok egy olyan rendszerbe, ahol az írásra és olvasásra külön adatbázist használok. Na már most, ha egy európai felhasználó akar kapcsolatot teremteni egy amerikai felhasználóval, akkor nyílván az adatbázisoknak egyeznie kell. Azaz, ha bárki ír egy adatbázisba (amire mondjuk használok 1 adatbázist), akkor az ugyanúgy frissül mind a pl. 10 a világ más részein található adatbázisban. Ha ez így van, akkor világos, hogy így a lekérdezésekkel viszont sokkal kevesebb terhelés jut 1-1 szerverre, de az írással ugyanúgy az összes szervert bombázom, nem? Főleg azt a fő szervert, amire az írásra szolgál. Minden felhasználó arra az 1 szerverre csatlakozik, ha írni akar az adatbázisba?
Bocsánat, tényleg a tudatlanságomért, de fogalmam sincs róla és szeretném átlátni az egészet, mert itt még a működési elvvel sem vagyok tisztában, nem hogy a megvalósítással. Ha a működési elvet értem, akkor jobban utána tudok járni.
Tehát annak örülnék, ha valaki segítene ezt elmagyarázni, valamint néhány lépés, hogy pl. a google cloud-ban ez miként valósítható meg. Egyszerűen, és ne 1 milliárd felhasználóra gondoljunk. Pl. 1 millió felhasználó, 100.000 online user, 100.000 sql lekérdezés vagy írás/perc.
Az adatbázis struktúráját persze úgy alakítottam ki, hogy tényleg a lekérdezések minimálisak legyenek, de ami kell az kell..
Hozzáteszem: aki tényleg komolyabban tudna segíteni, esetleg egy olyan rendszert létrehozni, ahol nekem csak a kliens oldallal kell foglalkoznom és azzal, amit a kliensem megnyit (itt gondolok a php (vagy más) részre), azaz pl. a google cloud-ban ki tudná alakítani az adatbázisok egymás közti kommunikációját, a szerver kapcsolatot, vagy segíteni benne, az is jelentkezhet.. nem várom el ingyen persze senkitől..
Nem kell nekem olyan rendszer, amit az elejétől a végéig én írok meg, szívesen igénybe veszek olyan rendszert, amiben egyszerűen meg tudom adni hogy mikor mi történjen az adatbázisban, mi jelenik meg a felhasználónak, a szerver bővítést a terheléselosztást pedig elvégzi helyettem. Ha létezik ilyen.. (Itt gondolok olyanra, hogy pl. google cloud platformon is aszerint fizetek, amennyit használom.) ((persze itt is a kiindulásra gondolok, nyílván egy hatalmas cég, mint pl. Facebook már nem engedhetné meg magának, hogy ilyet használjon. És ha az enyém is befutna, én is vehetnék fel embereket, hogy na akkor csináljátok újra.)) -- Itt egyébként a Google Firebase rendszerére gondoltam, melynek a működését nem tudom, csak hallottam róla, hogy talán abban lehetséges.
De akár gondolhatunk egy népszerű online játékra is, pl. farmerama.com, 54 millió felhasználóval. Azok hogyan oldják meg a szerver kérdést? (lehet inkább erre hasonlít az appom, mint a Facebookra. De leginkább pokemon go-ra.)
Nagyjából annyi a történet,
Köszönöm, kicsit
Az a baj, hogy elég realtime szerű.
Azaz egy példa, a felhasználó vásárolhat az egyenlegéből, az nem működhet, hogy vásárol, de az egyenlegéből pedig csak később kerül levonásra, hiszen az alatt az idő alatt a minusz egyenlegéből is tudna vásárolni.
A játék során pedig a lehetőségek függnek az egyes táblában lévő adatoktól, egyik pillanatban lehet, hogy még engedélyezett, 1 pillanat múlva pedig már lehet, hogy nem. És ha mégis végre tudná hajtani a műveletet mikor már nem szabadna, az katasztrofális lehet.
Ami könnyíthet a helyzeten, hogy pokemon go-hoz gps alapú, azaz a játékban a földrajzi hely szerint vannak tevékenységek. (mint pl. a pokestopok, egy magyar felhasználót nem fogja érdekelni az amerikában található pokestop, azzal nem kerül kapcsolatba). Így elképzelhető, hogy az európai az európai szerverre csatlakozzon, és az ott található adatbázissal foglalkozik csak, ami naprakész.
Ettől függetlenül a kapcsolatteremtésnek, user adatoknak viszont az egész világon azonosnak kéne lennie.. Mert mi van akkor, ha egy európai elutazik amerikába? Akkor az amerikai helyek információ szükségesek, de az user adatok meg az európai szerveren vannak? Vagy ha írni akar egymásnak 2 távol álló user?
Esetleg egy fő szerver, ami az user adatokért a bejelentkezésért és a kommunikációért felelős egymás között, aztán gps alapján meghatározni a helyzetét, a játék többi részét pedig az ottani adatbázisból töltené/írná?
Ha valami ilyesmi irányba gondolkodok az jó irány?
Realtime
Ami a Geobalancingot illeti, az eleg nehez kerdes, ezt meg a "nagyok" sem feltetlenul oldjak meg. Sok feladatra, ahol elengedhetetlen az "atomi" muvelet, ok is egy helyen taroljak az ilyen adatokat. Sztem ne akarj geobalancing DB-t epiteni, legalabbis ne elsore es semmikeppen ne PHP-ban. En most kiserletezem egy geobalanced projekttel, sztem ez eleg messze all attol amit jelenleg meg tudsz alkotni. Elsore legyen egy master DB-d es csinalj slaveket. Ahol fontos az idozites, ott olvass a masterbol, egyebkent meg a slavekbol.
Elsore legyen egy master DB-d
+1
Azaz egy példa, a felhasználó
Ez pont rossz példa, mert a bankoknál így működik. :D A bankoknak jobban megéri ha mínuszba mész, aztán fizetsz nekik kamatot utána. Nagy összegeknél persze már rendesen csekkolja az egyenleget az a rendszer is.
Par millio
Kérdés
Senkit nem érdekel...
Egy marketing stratégia nem
((Egy apró megjegyzés, bár nem tartozik a tárgyhoz: 12 évesen készítettem egy weboldalt (amit már korábban említettem 80.000-es maximális felhasználói létszámmal) 15 éves koromra 300e-400e Ft volt a profit/hó. És teljesen legális volt. Mennyit költöttem hirdetésre? Tehát olyan hirdetésre, ami pénzbe került. Ha jól emlékszem párszor a konkurencia honlapján emelt díjas sms-sel, körülbelül 3-4ezer Ft lehetett összesen. De még az Rtlklub egy reggeli műsorába is bekerült, úgy, hogy nem is tudtam róla, mások mondták, és egy vasamba sem került. Ki mondja meg a gyerekeknek, hogy mit mondhatnak és mit nem? :) Más dolog nyílván, nem az egész világon volt, hanem Magyarországon, de ha a marketingről akarnék beszélni, akkor nem itt tettem volna fel a kérdést.))
Szóval ne az ilyenen akadjunk fent, maradjunk a tárgynál.
Inf3rno: bírlak.. :D
egyébként tény és való, általában ha hétvégén is fizetek valahol kártyával, akkor is levonja az egyenlegemből, tehát függetlenül attól, hogy akkor könyvelik le, de jártam már úgy, hogy mintha semmi sem történt volna, ugyanúgy fizethettem vele még egyszer, aztán később ment minuszba..
Nade viccet félretéve, a játéknál maradva itt utólagosan nehézkes lenne követelnem a pénzt, ha az én hibámból engedtem minuszba menni a játékos egyenlegét. Szóval itt egy feltölthető játékos egyenlegről van szó.
De nézhetünk komolyabb példát is, a játékomban a játékosok is adhatnak el dolgokat másik játékosnak, amihez tényleg elengedhetetlen a valós idejű adatbázis, hogy ha a játékos csak 1 dolgot szeretne eladni, de azt majdnem egyidőben 2 játékos szeretné megvenni. Mivel még valós idejű adatbázis esetén is fennáll a veszélye, hogy egyidőben 2 tranzakció indul, így minden tranzakciót is egy külön táblában vezetnék, a tranzakció végeztével pedig ha minden sikeres jelölni, hogy sikeres, a megszakadt tranzakciókat pedig utólag felülvizsgálni, ha pedig van rá lehetőség akkor pedig helyben megszakítani és vissza az eredeti állapotot.
Szóval ezeknél tényleg nem ártana egy nagyon is valós idejű dolog, mivel elég interaktív dologról van szó, a tranzakciók elég gyakoriak, így amit írtam példát nem csak egy nagyon ritka fatális véletlenkor következhet csak be.
Load balance-ról egy picikét olvastam, abba az irányba kellene haladnom, amit janoszen írt?
Tanacs
Fajlokra detto, ha szep OOP van a rendszeredben, akkor egyszeru lesz kesobb ertelmes file tarolot tenni moge.
Szoval az egyszeruseg es valtoztathatosag a baratod, nem az elore megtervezett felhokarcolo architektura. Minel jobban megprobalsz elore megtervezni egy nagy rendszert, annal jobban bemanoverezed magad egy potencialis zsakutcaba.
azt javaslom neked hogy
Ne
Legyszives ne ragadd ki a kontextusbol amit irtam es ne keverd ide a Silexes topicot, nem veletlenul nem szoltam ott hozza.
Biztos?
Biztos
a legegyszerűbb rendszer nem
Jó lenne, ha nem offolnád
Azt hiszem már janoszen
Igazából itt nem végrehajtási
Illetve lehet azt csinálni, amit tudtommal a bankok is csinálnak, hogy a tranzakció végrehajtása előtt a terhelendő számlán atomikusan zárolni az összeget (csökkenteni a felhasználható keretet), majd a tranzakció végén azt véglegesíteni. Ha nem sikerült a tranzakció valamiért, akkor pedig törölni kell a zárolást. Lásd: long-running transaction.
Mindegyik megoldásban vannak buktatók. De egyetértek janoszen azon hozzászólásával (azzal is), hogy ezt a problémát nem egy elosztott rendszerben, világ körül replikált adatbázissal kell megvalósítani, mert csak újabb problémát hozunk a képletbe.
Bocsánat, hogy csak most
1. Való igaz, világ körült replikált adatbázisban úgy tranzakciót végrehajtani, hogy az lehet, hogy nem a legfrissebb adatokból dolgozik, azt tökéletesre megírni valóban őrült nagy mutatvány lenne. Persze ilyen esetekre használhatnám a master adatbázist, azaz minden tranzakciónál onnan kérdezem le / módosítom az adatokat. Ez lehetséges így? Vagy milyen más lehetőség van? :)
Ez azért is fontos, hogy a master-ből mindig tudjak lekérdezni, ha valós idejű adatokra van szükségem, mert pl. bejelentkezéskor az user-nek a legfőbb adatait valószínű a master-ből szeretnék lekérdezni, annak kiküszöbölésére, hogy ha hirtelen kilép és visszalép, ami alatt még a slave-k nem frissültek, akkor nehogy véletlenül nem friss adatokat kapjon, ami miatt a játékban lehet, hogy valami más jelenik meg.
2. A tranzakciókat igen, én is eleve úgy terveztem, hogy legelején eltárolja a tranzakciót egy tranzakciós ID-vel, utána levonja az egyenlegből az összeget, és végrehajtja amit szeretne. Ekkor eltárolom, hogy sikeres. Ha nem hajtható végre, akkor vissza az usernek a lóvé, megjelenik, hogy nem hajtható végre mert ..., ha pedig közben nagyobb hiba csúszik be és megszakad a kapcsolat, akkor utólag bármikor ellenőrizhető, hogy történt egy megszakadt tranzakció. Ez az elgondolás megfelelő, nem?
3. Mivel eddig kizárólag a webes programozással foglalkoztam, azok is egy kisebb rendszerű, php és mysql alapú, de a mysql-t is egyszerű phpmyadmin-nal értem el, így nagyon sok dologgal nem vagyok tisztában (mint például egy autóversenyző, aki pontosan tudja, hogyan drifteljen stb., de ahhoz már sokkal kevesebbet ért, hogy az autó motorja hogyan is működik pontosan), és tényleg inkább az egyszerűbb megoldások érdekelnének. (Aztán a jövőben mint már megbeszéltük, ha befut, újraíratom, aztán ennyi.)
Ezért írnék pár linket, amik elgondolkodtattak:
https://cloud.google.com/sql/docs/mysql/configure-ha
Ha jól értelmezem, itt néhány pipával és kattintással elérhető az, amit szeretnék? Mert itt ír master-ről meg slave-ről is a dokumentációban. Létrehozok szervereket több ponton, és mindegyiket beállítom, hogy replikálja oda? És nincs is vele más dolgom? Gondolom itt mindegyikhez kapok egy adatbázis címet, a kliensben meg elég megadnom, hogy hova csatlakozzon? Vagy azt is kitalálja a google, csak azt kell megadnom, hogy master-hez, vagy a legközelebbi slave-hez kapcsolódjon?
Ez elvileg egy mysql adatbázis.
https://cloud.google.com/datastore/
Ez szerintem hasonló elven működik, bár ez nosql adatbázis. Ami furcsa, hogy itt azt írja, automatikusan replikálja, és a lépések között sem találok olyat, hogy kipipáljam, tehát ez teljesen automatikus? Viszont ezt hogyan kell érteni? + Akkor hol adom meg, hogy éppen melyikhez kívánok csatlakozni?
Nagyjából ennyi most így ami eszembe jutott, ha ez tényleg működik így, anélkül, hogy mindenbe bele kellene tanulnom, akkor ezt választanám.. Lehet, hogy az ilyen előre megírt rendszerek nem olyan jók, mintha tényleg valaki saját maga írna egy komplett ilyen rendszert, de amire most képes lennék, annál viszont biztos vagyok benne, hogy ezek sokkal jobbak. :)) Aztán később bárhogy alakulhat, indulásképpen szerintem ez is megteszi.
Többen mondták, hogy fordítsd
Nézd meg mit bír a jelenlegi rendszered teljesítményben, esetleg több gépen, master-slave MySQL replikációval. Fogj pl egy JMetert, vagy hasonló eszközt, és küldd meg. Mai gépeken SSD-vel, jó sok rammal komoly terhelést kell bírjon. Az alapján ki tudod számolni ez elég-e, és kiderül hol van a szűk keresztmetszet. Én innen indulnék a helyedben. Ha kiderül, hogy messze van nagyon az elképzelésektől, akkor lehet tovább gondolkodni, pl cloud irányba. Addig csak időt, meg pénzt veszítesz egy csillagromboló építésével.
+1
korábbi oldalamon kicsiben
Tehát értem miről beszéltek, azt az oldalt én sem kezdtem volna felhőben. Viszont egy olyan oldalt, ahol a világon mindenhol marketingbe és reklámba szeretnék beletolni lóvét már indulás előtt, azt nem akarom elindítani egy szerveren.
És nem értem mi a baj a google cloud-al.. a datastore egy ideig ingyenes, utána 0.06 dollár 100.000 lekérdezés, számoljunk az elején 1 millióval/nap, akkor 1 nap, akkor 180 Ft/nap? Vagy 10 milliónál 1800? Egy szerver bérlése sem sokkal olcsóbb, másrészt ha már több százezer felhasználó produkálja ezt, akkor abból ennyi pénzem bőven lesz..
Vagy mi a gond ezzel?
Gond
Nem az infrastrukturális
Szerintem mérj egyet (lehetőleg azért ne egy i3-as laptopon 4g rammal, windowson), az sok kérdésed meg fogja válaszolni.
Jó, lehet, hogy teljesen
- A Google-nél azt írja, automatikus a skálázás. Persze lehet, hogy én értem félre, nekem kell megadnom mit hogy és utána automatikus? (Persze kezdjük ott, mi is az a skálázás..)
Nem értem, ahogy a legtöbb fogalmat sem amit ide leírtok, ugyanis az autóversenyzős példám erre a legjobb.. Még otthoni környezetben sem alakítottam ki saját szervert soha, amit készítettem az mind annyiból állt, hogy egy tárhelyen phpmyadmin-ban létrehoztam az adatbázisban a táblákat, stb., és miközben írtam a php-t mindig ftp-n keresztül feltöltöttem és ott is módosítottam, aztán néztem, mi történik. Szeretek úgy fejleszteni, hogy rögtön látom minden apró mozzanatot élesben.
Tehát ddr, cqr, geobalancing, mysql galera cluster, nginx load balancer, statikus kiszolgáló, ezekről mind fogalmam nincs. Létrehozok egy php fájlt, egy egyszerű sql kapcsolatot, egy egyszerű sql lekérdezést, megjelenítem. Ennyi.
Tehát azt mondjátok, hogy google-ban megcsinálni nem állnátok neki, mert túl bonyolult, nekem az tűnik a legegyszerűbbnek.
Azaz legjobb ha egy példával érzékeltetem, hogy én hogyan képzelem. Aztán ha mégsem így működik, akkor írjátok meg, hogy ezzel mi a baj.
Létrehozok google cloud-ban több szervert, európa, ázsia, stb. Simán kattintásokkal. Létrehozok egy elvileg automatikusan replikálodó skálázodó adatbázist, aminek a replikációit beállítom az európai, ázsiai, stb. szerverre. Szintén simán néhány kattintással. Mindegyik szerveren létrehozok egy php fájlt, mely képes egyszerűen csatlakozni az adatbázishoz (akár a replikálthoz akár a master-hez.) Az appomban beállítom a fő szerver php fájlját, amivel kapcsolódok a master adatbázishoz, bejelentkezik, majd pedig például host alapján megkapja, hogy melyik szervert fogja onnantól használni, azaz európait például. Utána minden php fájlnál az europaszerver.appspot.com/teszt.php fájlhoz fog kapcsolódni, mely az európai szerver slave adatbázisát fogja megnyitni. Ha fontos, akkor meg a master-hez kapcsolódok.
Laikusként így látom a dolgokat. Ha írok a master-be, akkor az automatikusan frissül a többiben is nem? Aztán elvileg más dolgom nincs vele. Szóljatok, ha nagyon rosszul látom a dolgokat, de én ezt így nagyon egyszerűnek látom, anélkül, hogy bármilyen fogalomhoz értenék, amit leírtatok. Nyílván nem véletlenül írjátok amiket írtok, tehát biztos, hogy profin úgy kellene, ahogy Ti mondjátok, de számomra ez így egyszerűnek tűnik, ha működik..
A tesztelésekre ott van az ingyenes keret, vagy a próbaverzióban ingyenesen adott 300$, amivel el lehet készíteni, működőképes appot csinálni..
Jelenleg nincs szerverem, egy olyan szervert használtam indulásképpen kb. hogyan is nézne ki, hogyan is működne, ahol magához a szerverhez nincs hozzáférésem, kizárólag total commanderben ftp-vel feltöltöm a php fájlokat, valamint egy phpmyadmin felület. Ezért is gondoltam a google cloud-ra, mert ha nodejs-t szeretnék, akkor azt ott meg tudnám oldani, míg ott, ami jelenleg van nekem, ott ilyenre nincs lehetőség.
Tanulas
- Parancssoros Linux
- nginx
- PHP-FPM
- MySQL master-slave replikaval
Nem azert hogy hasznald, hanem hogy egyaltalan ertsd hogy mitol mukodik.
Igen, a helyzet az hogy
Szóval ezért mondom, hogy egy ilyen rendszer felépítése teljesen önerőböl nagyon hosszadalmas folyamat lenne, mire ezt teljesen az alapoktól elsajátítom. Bár örülök neki, hogy még egyikőtök sem küldött el a tudjukhova és segíteni próbáltok.
Amit írtál most, oké valószínű néhány doksi+tutorial alapján megoldom, ha először dobok valamelyik gépre egy linuxot..
De mint látod, ebben nagyon nagyon kezdő vagyok. Ugyanakkor az oldalt, vagyis az appot, meg tudnám oldani kicsiben fullra (bár ha nodejs-t is szeretnék akkor abba is bele kell kicsit jönnöm, de sokkal egyszerűbben jönnék bele, mint ebbe, ahol szinte az alapoknál kezdhetem.) tehát php-ben fullra megírom, egyedül ez a dolog nagy dologra való átszerkesztése komolyabb..
És nem akarok évekig dolgozni ezen, mikor a fejemben megvan az egész, kicsiben a megvalósítás is, akkora ötlet amit szeretnék, hogy csoda, hogy még nincs ilyen és minél előbb lépni szeretnék.
Ha a google cloud-al gyorsan tudnék haladni úgy ahogy leírtam, akkor azt választanám, gyorsan minél előbb legyen egy használható verzió (de képes legyen sok felhasználót kiszolgálni a világ bármely tájáról) utána meg lehet gondolkozni, hogyan tovább.
Ezért ha lehet, a legegyszerűbb és leggyorsabb megoldás érdekel. Közben utánajárhatok annak amit mondasz, mert tudom, hogy jót akarsz, de ha a cloud-ban lehetséges úgy ahogy elmondtam, akkor írd meg, vagy írd meg hogy hülyeséget írtam, néhány kattintással nem fogja skálázni és kiszolgálni a világot. Tehát hogy hol bukik el amit mondtam. (És a költségektől most tekintsünk el.)
Szent gral
Az uzemeltetes NEM egy olyan tema ami folott nagyvonaluan el tudsz siklani fejlesztokent ha cloudban dolgozol. Meg kell ertened hogy mi az a webszerver, hogyan mukodik, mi az az adatbazis, az hogyan mukodik, stb. kulonben majd nezel nagyokat hogy miert nem mukodik, vagy miert nem azt csinalja amit szeretnel.
Az informatikaban nincs szent gral, nincs silver bullet. Vannak megoldasok, es azok altalaban 80%-ban azt tudjak amit Te szeretnel. Ha megertetted hogy mit csinalnak es ki tudod valasztani a megfelelot. De a maradek 20%-ot neked kell hozzakodolni es az nem fog menni ha lovesed nincs semmirol ami a temaval kapcsolatos.
Egyszer legalabb vegig kell kuzdeni egy setupot hogy ertsd hogy mire valok az egyes komponensek, mit csinalnak es hogyan kell debugolni oket. Meg kell ertened hogy mi a kulonbseg az erosen es gyengen konzisztens DB rendszerek kozott, es melyikre milyen megkotesek vonatkoznak, plane ami a replikaciot illeti.
Ennel vilagosabban nem tudom elmondani.
Semmi sem ilyen egyszerű:
Én továbbra is tartom a fenti tanácsot. Vagy ha annyira hiszel az ötletedben - és van rá pénzed is - bérelj fel pár profit, akik viszonylag gyorsan le tudnak szállítani egy prototípust.
Az entity írása kimondottan
Tehát értsem úgy, hogy ha létre is hozom ezt a google-on, akkor ott még mindenfélét kell írnom, hogy működjön is, automatikusan nem replikál stb.?
Nekem az lenne a jó megoldás, ha ezt elvégzi helyettem valami/valaki, nekem pedig csak az appal es például a php tartalmával és az adatbázis tartalmával kell foglalkoznom.
Maga a project még így is nagyon bonyolult és hosszadalmas, ha a szerverek elosztása stb. minden meglenne még akkor is hónapok munkája az app, tehát még azt sem volt egyszerű kidolgozni, hogy sima php+mysql alapon kicsiben hogyan hozható össze, rengeteg dolognak kellett összeállnia a fejemben.. ezért még ez is hosszadalmas, hát ha még az apache stb alapjaiba kéne beletanulnom.
Plusz az egész projectet biztos nem adnám át, plusz amennyi mindent szeretnék valami elképesztő összeget mondanának rá, ahhoz először lottót kéne nyernem.
Inkább csak a szerverek elosztását replikálását kellene megoldani, minden adattal pedig ami kell az apphlz azzal én dolgoznék.
Ez szerintetek így megoldható? Milyen árban?
De az elsőre kérdésemre is válaszoljon valaki, hogy egyáltalán nem lehetséges google cloud datastore-t használva anélkül létrehozni ilyet, hogy mindent nekem kelljen megírnom, vagy lehetséges, csak nem lesz a legoptimálisabb? Csak hogy végre tényleg tisztán lássan.
+1 google cloud spanner?
https://cloud.google.com/spanner/
Csak kíváncsiságból kérdezem, mert ennek az ára már tényleg sok a majdnem 300 Ft óránként.
A Datastore nem egy relációs
Olyan dolgokat feszegetsz ebben a topicban, amik bár szakmailag nagyon érdekesek, de erősen senior+ kategória. Ilyen kaliberű ember megfizetéséhez (pláne többhöz) pedig valóban mély zseb kell, ezt jól érzed. Ha jól beszélsz angolul és mered angolul menedzselni a projected, valamilyen freelancer oldalon lehet olcsóbb munkaerőt találni, mint itthon. De a minőség ott se olcsó.
A szálat és a kérdéseidet végignézve én semmiképp nem ajánlom neked a cloud irányt. Ha a PHP+MySQL-t ismered, akkor rakd össze, ahogy tudod. Esetleg annak a tervére fizess be valakinél, plusz pár alkalom konzultációra, reviewra. Pár gépből kihozható, amit szeretnél, és a PHP-t kiszolgáló gépek még csak nem is kell erőművek legyenek. A MySQL alá mondjuk azért nem árt átgondolni mit teszel. Ennél optimálisabbat szerintem nehéz javasolni. Gondold meg azt is, hogy a hardware költség az előre tervezhető. A fejlesztés nem igazán.
Értem. Vagyis
Pontokba szedem a kérdéseimet :)
1. Kicsit még a cloudnál maradva. Oké 1 rekordot másodpercenként csak egyszer módosíthatok. Lehet, hogy ennél gyakrabban nem is szükséges. Kivéve tranzakcióknál, ha egy usertől például 2-en vásárolnak egyszerre. De ha tényleg teljesen más mint a mysql, akkor tényleg lehet nem jó.. viszont korábban emellett a link mellett egy másik linket is küldtem a cloud-ról, ami viszont mysql alapú. Azzal mi van?
2. Tételezzük fel, mysql cloud. mi olyan nehéz abba, hogy felteszek egy php fájlt a szerverre, amit már megoldottam, létrehozok máshol is, és létrehozok néhány gombnyomással egy adatbázist, amiben beixelem, hogy máshova replikálja?
Nem fog működni?
Vagy nem lesz tökéletesen skálázódó stb.?
Tehát csak arra vagyok kíváncsi, ha én laikus fejemmel és csak azért is makacsságomból összenyomkodom azt a pár gombot, akkor mi történik? Vagy mi nem történik? Be tudom jelölni a backup-okat, mindent egy egyszerű grafikus felületen, anélkül, hogy értenék hozzá, hogy ezt hogyan kellene leprogramozni. Tehát ezzel mi a baj? Ahhoz, hogy megértsem valami egyszerű rövid tömör válasz kellene, mint pl. az, hogy a skálázást meg kell írnod, különben a google nem fog csinálni semmit, nem fog futni. Nem fogja replikálni, vagy 2 nap után elromlik ha nem kezelem, stb. Vagy olyan válasz, hogy működni fog, de több ezer usernél ugyanúgy rossz lesz, ha nem csinálsz vele semmit.
3. Tegyük fel ezt rábízom másra. Ha valakire csak a szerverek adatbázisának szinkronban tartását bízom rá, semmi mást, azaz a php-t az appot minden én írok, az is annyira baromi drága lenne? (Vagy azt teljes egészében hozzá kell építeni az én php fájljaimhoz, vagy hasonló, ami miatt nem tudná senki csak azt a részt elvállalni?)
4.
És az a pár gép, mondjuk 3-4-5 néhány kontinensen az nem lenne ugyanúgy drága? Ugyanúgy nem értek hozzá, ugyanúgy kell keresnem szervereket, tehát nem mindegy hogy az a szerver most a google szervere, vagy nem?
Mert amikor én a cloud irányába kezdtem el gondolkodni, akkor az volt a fejemben, hogy hú de jó, nem kell szervereket bérelnem hatalmas összegért, hanem pár gombnyomás és márs van egy, és annyit fizetek amennyit használom..
ui.: tényleg bocsánat az összes hülye kérdésemért, de eddig tényleg csak olyannal dolgoztam, ahol tényleg minden adott volt, a tárhely, phpmyadmin-ból a mysql, elkészítettem amit szeretnék és semmi mással nem volt dolgom.. amikor megnőtt a terhelés olyannyira, hogy az egész szervert a többi oldalt is belassította, béreltem egy saját szervert, amire át lett pakolva minden, azt is a rendszergazda csinálta, nekem csak max az adatbázishoz való kapcsolódást kellett átírnom a php-ben, aztán ennyi.. soha nem foglalkoztam a skálázódás stb. dolgokkal, azt se tudom mi az.. :D
2.
3. Ha felberelsz valakit erre, akkor olyan embert berelj fel, aki az eges setupot osszerakja es le is dokumentalja hogy hogyan kell normalisan uzemeltetni.
4. Mar leirtam neked hogy ne akarj tobb kontinensre skalazni. Olyan problemakkal fogsz szembesulni, amihez tapasztalt mernokoknek is honapok kellenek mire osszerakjak ugy hogy ne boruljon ossze.
Ami a fizetest illeti, nem, nem ugy van hogy annyit fizetsz amennyit hasznalsz. Rengetegszer van egy minimum eroforras amit le kell foglalnod ahhoz hogy ertelmesen mukodjon a rendszer. Amazonnal van csak reszletesebb tapasztalatom, de ott pl. az ELB berlese minimum havi ~20$, egy normalisabb EC2 instance ~60$-tol kezdodik. (A t instance-okat ne szamoljuk ide.)
Az ui-hez meg annyit, hogy lehet hogy ha felhoben akarsz dolgozni, akkor legalabb EGYSZER ossze kene rakni egy sajat setupot hogy lasd hogy mit csinal. A tudas hianya kifejezetten veszelyes tud lenni, mert itt nincs rendszergazda aki rad szoljon ha hulyeseget csinalsz.
Osszessegeben szerintem kicsit el kellene engedned azt a kepet amit alkottal a "felhorol", mert igy fennall a klasszikus "tele van a pohar es nem lehet bele tobbet tolteni" esete. Torolj ki mindent a fejedbol amit a felhorol kepzelsz es kezdj el utana olvasni hogy mi hogyan mukodik.
Hajaj fogom a fejemet..Nem
Nem tudom mi az az ELB és EC2.
De egy normális rendszernél a havi 60 dollár még annyira nem riaszt el..
Oké nem skálázok több kontinensre. De mi az a skálázás? :))
Nem tudok kicsiben kezdeni, tényleg.. nem akarok részletekbe menni az appról, de ez mindent vagy semmit dolog. Vagy rendesen csinálom, vagy neki sem szabad állni. Vagy az elején befut, vagy törölve. Vagyis 2-3 hónap alatt vagy befut, akkor pénz nem számít vagy nincs értelme. 2-3 hónap szerverköltséget meg elviselek, megéri a kockázat. Persze optimistán gondolkodok, működni fog és megéri, de nem tudom kicsiben elkezdeni.
Ezért kell olyan rendszer, hogy az egész világon el lehessen érni azt a ***** php-t és közös adatbázist..
Tényleg olyan nehéz ez? :/
Mit javasoltok?
Amit írtam, hogy csak és kizárólag arra a részre felbérelni valakit, az milyen árban mozoghat?
Freelancerrel én is találkoztam, de még megfogalmazni sem tudnám, hogy mit is akarok..
Meg egyáltalán nem értem az egészet, hogy mi olyan bonyolult abban, hogy több helyen vannak szerverek, ahova felteszem a php fájljaimat, meg itt-ott adatbázis, amik szinkronban vannak a fő adatbázissal.. nem értem, hogy ebbe mi a bonyolult.. :/
Persze értem, hogy egy hangyának nehéz elmagyarázni matematikai képleteket, már megpróbáltátok sokféleképpen, hogy megértsem, de próbáljuk meg magyarul, laikusan, ismeretlen szavak nélkül, hogy tulajdonképpen mit is akarok, mi az ami más egy kicsi rendszer és egy nagy rendszer szinkronba rakásához képest..
Jaj
1. hogyan mukodik a PHP?
Ugyan itt reszletesebben leirtam, de nezzuk a rovid valtozatot. Adott egy webszerver ami fogadja a kapcsolatokat a kliensektol. Legyen ez mondjuk egy nginx. Ez a webszerver a disken megkeresi, hogy melyik filet kell kiszolgalni. Vagy statikus file (pl kep, css file, stb), vagy pedig PHP file. Az elobbi esetben egyszeruen kiszolgalja a filet. Az utobbi esetben tovabb passzolja a kerest a PHP-nak.
nginx eseten PHP-FPM-et teszel moge, ami egy teljesen kulonallo program. A PHP-FPM indit alapbol mondjuk 5-10 folyamatot (egy parhuzamos lekerdezes kiszolgalasahoz 1 folyamat kell). Ezek a folyamatok akkor is eszik a memoriat ha eppen semmit nem csinalnak. Ha no a terheles, a PHP-FPM skalaz folfele, de csak egy bizonyos meretig. (Ezt be kell konfiguralni hogy mennyi.) Miert? Mert minden gepnek van egy rendelkezesre allo CPU es memoria korlatja, vagy fizikai vagy virtualis.
Es itt a problema, a PHP, NodeJS, stb. a jellegebol adodoan nem tud tulnoni "automatikusan" egy fizikai szerveren, vagyis amikor elered ezt a korlatot, tobb darabot kell belole inditani kulonbozo gepeken es ezt kezelned kell. (Mas nyelveknel, pl. Erlang, ez megoldott, de azok mas problemakkal kuzdenek.)
2. a PHP felhositese
Nos, felhositsunk. Ket megoldas letezik. Vagy valasztunk olyan szolgaltatot aki megoldja "helyettunk" az egesz egy szerver - tobb szerver kerdest, vagy mi magunk jatszunk vele. Az elobbi pl. a Heroku, ahol ezert cserebe az o altaluk megkivant strukturaban kell osszerakni az alkalmazast, nem lesz mashol futtathato. Az utobbi pl. az AWS, ahol neked kell megmondani hogy hany virtualis gepet akarsz, mi fusson rajta, stb.
Na most, ha olyan rendszert valasztasz mint az AWS, akkor flexibilisebb leszel, cserebe neked kell megoldani hogy a berelt virtualis gepekre keruljon nginx, PHP-FPM, stb. es azt is, hogy ha uj gep jon fol hogy kiszolgalja a novekvo terhelest, akkor arra a gepre mindez automatikusan tortenjen meg. (Sok-sok scripteles kerdese.)
Arra meg plane figyelni kell, hogy sem a Heroku, sem az AWS nem fog neked automatikusan, a te logikadnak megfeleloen PHP instance-okat inditani ha no a terheles. Ezt neked kell megoldanod, neked kell megmondani neki hogy hanyat inditson. Vagy legalabb bekonfiguralni a logikat.
3. Adatbazis
Vegyunk egy mezei MySQL-t. Beleirsz es azt varod, hogy ott van az adat. Na ez elosztott mukodesnel nincs igy. Beleirsz valamit, es a kovetkezo lekerdezesnel egy masik szerverrol olvasol (slaverol) es hopp, nincs ott az adat. A masterrol tudsz olvasni, de ha lehet, ezt szeretned elkerulni, hiszen a masterbol csak egy lehet. De cserebe legalabb az garantalt, hogy ha inditasz egy tranzakciot, akkor a tranzakcio egesze "egyszerre" megy vegbe.
A MySQL-lel egy baj van: arra talaltak ki hogy egy fusson belole. Utolag ugyan beleraktak a replikaciot, de sosem tudsz megszabadulni a mastertol, mindig lesz egy olyan node amibe irni kell es ha az megall, akkor vakarhatod a fejedet.
Sebaj, nezzunk valami mast. Pl. Google Datastore vagy Cassandra. Ezek jobban skalazodnak, tobb helyen lehet belejuk irni, de cserebe a CAP haromszog masik oldalan laknak, vagyis nincs konzisztencia igeret. Siman lehet hogy a cluster egyik fele tok mast lat mint a masik, majd egyszer szinkronba jon. Ja es persze "tablak" sincsenek ugy ahogy a MySQL-nel megszoktad, a legtobb NoSQL adatbazis sajat szemantikaval rendelkezik. Penzugyi tranzakciok tarolasara ezek tobbnyire teljesen alkalmatlanok.
4. Felhositsunk
Ha DB-t akarsz felhositeni, megint ugyanaz a problema: a MySQL nem tud tulnoni varazslatos modon egy gepen. Egyszeruen nem erre terveztek. A Cassandra igen, azt clusterezesre talaltak ki, de ezt neked kell megoldanod, nem fogja senki helyetted feltelepiteni es futtatni.
5. Valos ideju uzenetek
Ha valos ideju uzeneteket (pl. chatet) akarsz epiteni, belep egy plusz problema is. Tegyuk fel hogy NodeJS-t futtatsz. Sosem lehetsz biztos benne hogy a user melyik szerveren kot ki, tehat tovabbitani kell az uzeneteket a szerverek kozott. Igen am, de ahhoz hogy mindenki megkapja mindenki mas uzeneteit, tovabbitanod kell a szerverek kozott az uzeneteket. Ha pedig mindent mindenhova tovabbitasz, akkor nem nyertel semmit mert ott lesz a terheles.
6. Hulyeseget csinalsz
Folyamatosan azon ugralsz, hogy neked hogy fel kell keszulni arra hogy mekkora terheles lesz, es hogy egybol nagyban kell indulni. Hulyeseget csinalsz, es ezt itt mindenki mondja neked.
Feltetelezem nincs 50 millio forintod egy nagyobbacska marketing kampanyra, vagyis nem fog holnap akkora terheles zudulni a szerveredre hogy egynel tobb kelljen. Hidd el, LESZ IDOD atalakitani az infrastrukturadat fokozatosan.
Ha annyiszor szazezer forintom lenne ahanyszor a hozzad hasonlo szoveget hallottam, akkor most nem itt valaszolnek, hanem a sajat jachtomon a karibi tengerben pecaznek.
Ha meg tenyleg akkora siker a cucc es nem birja el az altalad osszerakhato 1-2 vas, akkor szolj es megfelelo uzletresz elleneben epitek neked automatikusan novekvo setupot.
Hm.. na ilyesmi kielégítő
Úgyhogy köszönöm szépen, hasznos kis írás.
Azt hiszem Te vagy az én emberem, holnap küldök egy emailt. :)
Mindenkinek köszönöm amit írt, szerintem nem feszegetem tovább a témát, az utolsó hozzászólás konkrétan mindent takar laikusoknak is, innentől pedig a döntés már a kezemben van.
Ha egyszer elindul az app, ajándék kredit jár mindenkinek. ;)