ugrás a tartalomhoz

Óriási terhelésű közösségi oldal létrehozása

vadrian0 · 2017. Ápr. 12. (Sze), 21.23
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!
 
1

Kezdetnek elolvashatod

inf · 2017. Ápr. 12. (Sze), 23.34
Kezdetnek elolvashatod Janoszen cikkét a session mentes weboldalakról, utána meg nézz utána a clustereknek. Ez így alapnak persze nem elég, de talán felnyitja a szemed, hogy itt még nem kevés tudás hiányzik ahhoz, hogy egy ilyen rendszert létrehozz, mint amit leírtál. Másik oldalról megközelítve, meg ha egyszer tényleg lesz ennyi felhasználód, akkor lesz elég pénzed is rá, hogy felbérelj valakit, aki megírja, esetleg újraírja a kódot, szóval nem muszáj értened hozzá.
2

Rendben, elolvasom

vadrian0 · 2017. Ápr. 13. (Cs), 00.54
Rendben, elolvasom utánajárok, de előtte még válaszolok.
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.
3

Ha túltervezel egy rendszert,

inf · 2017. Ápr. 13. (Cs), 00.56
Ha túltervezel egy rendszert, akkor az üzemeltetési költségek miatt idő előtt be fog csődölni, hacsak nem hajlandó vagy egy csomó pénzt beletenni, hogy veszteséggel üzemeljen, amíg profitábilis lesz. Szerintem bőven elég, ha postgresql, vagy hasonló szintű adatbázist teszel alá, ami a mysql-nél több terhelést elbír. Ha azt kinövi, az azt jelenti, hogy érdemes beruházni rá, mert jó az ötlet, és onnantól tudsz keresni befektetőket a projekthez, vagy megfinanszírozhatod magad is.

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ó.
4

Értelek.Google cloud

vadrian0 · 2017. Ápr. 13. (Cs), 01.23
Értelek.
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.
5

Sok ilyen van, szerintem

inf · 2017. Ápr. 13. (Cs), 04.32
Sok ilyen van, szerintem szinte mindegy, hogy melyiket használod, nagyjából arról szól, hogy leveszik a válladról az üzemeltetést. Herokut szeretik sokan, amiről én tudok, de már jó ideje ott van az amazon computing cloud is, és gondolom még egy rakás másik cég is. A fejlesztés idejére a docker és virtualbox, ami hasznos lehet, de azokba is sok idő, mire beletanul az ember. Nagyjából ezek az alapok, olvasgass, aztán majd idővel kialakul, hogy hova tovább.
6

Indulj kicsiben

bamegakapa · 2017. Ápr. 13. (Cs), 08.36
Bocs, lehet hogy tényleg pont a te ötleted a Szent Grál.

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
9

+1

janoszen · 2017. Ápr. 13. (Cs), 10.59
+1, ha bejon a projekt lesz penz megfizetni a szakembert aki ellapatolja amit el kell. Ha nem jon be, ugyis mindegy.
10

Én is ezt írtam. Egyébként a

inf · 2017. Ápr. 13. (Cs), 16.08
Én is ezt írtam. Egyébként a facebook sem egyik napról a másikra lett milliós látogatószámú, bőven volt idő normálisan újraírni az egészet, mire elfogyott alóla a gép.
14

Ja ugyanazt írjuk, csak el

bamegakapa · 2017. Ápr. 13. (Cs), 19.18
Ja ugyanazt írjuk, csak el akartam mesélni a személyes tapasztalatokat :)

A Facebook is egy összehákolt PHP cucc lehetett eleinte, bár nyilván nem láttam, de így képzelem :)
17

Hát ha ez igaz, akkor erősen

inf · 2017. Ápr. 13. (Cs), 20.19
Hát ha ez igaz, akkor erősen spagetti volt: link. És olyan 20-50 millió felhasználója volt 2007-ben, szóval addigra már újraírhatták. link Gondolom az alapokat változtathatták csak meg, hogy gyorsabb legyen, minden mást meg hagytak úgy ahogy van, hogy nehogy eltörjön. Legalábbis régebben hallottam olyasmit, hogy a php engine-be is belenyúltak, hogy gyorsabb legyen.
7

Elosztott rendszerek

Poetro · 2017. Ápr. 13. (Cs), 09.30
Manapság már otthoni környezetben​is viszonylag egyszerű egy elosztott rendszert létrehozni. Vagy virtuális gépeket használsz, vagy veszel olcsó kis gépeket, például Raspberry Piet, és azokat körös hálózatba. Vagy csak egy gépen több porton futtatod az alkalmazást, az adatbázis szervereket, az alkalmazás elé egy terhelés elosztót. Az, hogy miben írod az alkalmazást kezdetben teljesen lényegtelen. A lényeg hogy működjön.

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.
11

Már csak arra kell rájöjj,

inf · 2017. Ápr. 13. (Cs), 16.09
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.


Hát igen, "csak". :D
12

Felho szolgaltatasok

Poetro · 2017. Ápr. 13. (Cs), 16.51
A felho szolgaltatasoknak van ilyen tulajdonsaga, csak ismerni es hasznalni kell. Viszont ha magad akarod implementalni, az egy kicsit bonyolultabb lesz.
13

Engem is inkább ez a megoldás

vadrian0 · 2017. Ápr. 13. (Cs), 18.47
Engem is inkább ez a megoldás érdekelne, hogy a php vagy más nyelven írt rész, plusz az adatbázis terhelése el legyen osztva. (Azaz akár több adatbázis, több szerveren, szinkronban, stb.)
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.
15

Ne érts félre, nem

bamegakapa · 2017. Ápr. 13. (Cs), 19.29
Ne érts félre, nem kötözködés...

Kicsiben nem tudom elkezdeni, mert a nagyobb cégek legyártanák nagyban ha meglátnák.


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!
16

Szvsz. a nagyobb cégek nem

inf · 2017. Ápr. 13. (Cs), 20.12
Szvsz. a nagyobb cégek nem lenyúlni szokták legtöbbször, hanem felvásárolják az ilyen ötleteket. Amíg kicsi, addig nem kerül a látóterükbe, ha meg már elég nagy, akkor le tudod védetni, mert lesz rá pénzed. Azért van ellenpélda, lásd adidas kontra Oroszi László, de annak is látod milyen vége lett így 15 év után. Általában ha ilyen nagy ötletek befutnak, akkor meg már hiába másolják le, mert a második facebook, vagy második google már nem rúg labdába, lásd google+ vagy bing.

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
8

Skálázódás

janoszen · 2017. Ápr. 13. (Cs), 09.59
Tulajdonképpen nem jársz messze az igazságtól. A PHP kiváló válasz a skálázódás problémakörére, mert alapvetően egy no-share architektúrát valósít meg, azaz kis odafigyeléssel szinte korlátlan számú PHP node-ot futtathatsz.

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)

  • Felejtsd el az Apache-ot. Ha még nem tetted, itt az idő átállni nginx+PHP-FPM-re.
  • Keress egy tisztességes deployment rendszert. Mivel a kódod több gépen fog futni, erre komoly szükséged lesz. (Alternatív megoldásként futtasd a cuccaidat Dockerben és figyelj arra, hogy bármi ami a containerben van a következő frissítéskor elveszik.)
  • Nem lesz helyi filerendszered. Egy profilkép feltöltés nem annyi lesz, hogy levágod a lemezre es utána bősz vigyorral várod hogy azonnal működjön. Helyette foglalkoznod kell azzal, hogy kitold S3-ra vagy valamilyen CDN-be a user képét.
  • Nem lesz minden "azonnal". Rengeteg olyan folyamatod van ahol be kell építened várakozást, amig kifrissíted több szerverre. Vagyis jobb, ha a user interface-t reszelő kolléga minden AJAX lekéréshez beteszi szépen a várakozó pörgettyűt, különben meg fogtok lepődni.
  • Nem lesznek sessionjeid. Egy ekkora rendszernél sessionre, pláne lockoló sessionre építeni öngyilkosság.
  • Ha akkorára nő a rendszered (ehhez már a milliárdos nagyságrendben járunk), el kell gondolkodnod a geobalancing kérdésen. Minél messzebb vagy a szervertől, annál lassabb lesz az oldalad. Vagyis valahogy meg kell oldanod, hogy az adataid egy része legalább helyben legyen olvasásra és az írásokat elkülönítsd. (Azaz nem ugyanazt a DB kapcsolatot fogod használni olvasásra mint írásra.)
  • Barátkozz meg a queue-kkal. Na nem a Laravel- és Symfony féle bugyuta queue megoldásokkal, hanem a rendes, nagy, elosztott queue rendszerekkel. Rá kell jönnöd, hogy olyan queue nincs ami PONTOSAN egyszer dolgoz fel egy feladatot. Olyan van, ami maximum egyszer és olyan ami minimum egyszer dolgozza fel. Vagyis meg kell ismerkedned az idempotencia fogalmával.
  • Ha már, nyugodtan búcsúzz el a mamut frameworköktől. Symfony, Laravel, Zend, ezek mind-mind irdatlan mennyiségű kódsort hoznak magukkal és ezzel a kellő lassúságot is. Válassz egy mikroframeworköt és arra építs. Vagy írj sajátot ami tényleg csak azt csinálja amit feltétlenül kell. (Erre találsz inspirációt a félbehagyott Piccolo nevű projektemben.)
  • Készülj fel arra, hogy semmi nem lesz gyors. A PHP-s kész komponensek 99%-a nem erre a méretezésre van kitalálva. Kénytelen leszel végig küzdeni mindent, és ennek a főnököd nem biztos hogy örülni fog.
  • Mint már említettem, nem lesz egy DB-t és nem lesz egy DB szervered. Ne is álmodj arról, hogy csinálsz egy nyolc táblás joint vagy ORM-et használsz. Ezek a dolgok nem játszanak ha ekkora rendszert építesz. Szépen megírod az SQL queryket és felépíted belőle az objektumaidat. Ha ajánlhatom Uncle Bob EBI architektúráját.
  • Olyan nincs hogy valami automatikusan skáláz. Vannak platformok amik skáláznak valami alapján. De hogy ez a valami az micsoda, azt neked kell megmondani és sokszor nem áll rendelkezésre az amit szeretnél. Ráadásul nem lehet mindent automatikusan skálázni, pl. Amazonnál a MySQL / AuroraDB RDS instance-okat nem.


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.
18

Akkor válaszolok

vadrian0 · 2017. Ápr. 14. (P), 02.27
Akkor válaszolok mindenkinek.
bamegakapa:
A Facebook is egy összehákolt PHP cucc lehetett eleinte

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:
arra is érdemes ránézni, ha erőlteted ezt a php vonalat.

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:
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

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.)
19

Nagyjából annyi a történet,

inf · 2017. Ápr. 14. (P), 03.46
Nagyjából annyi a történet, hogy a kód eseményeket produkál, amiket egymás után mentesz egy event storage-be. Az adatbázisokat az event storage-ek alapján frissíted folyamatosan. Szóval az olvasási oldal nem teljesen naprakész. Az üzleti döntés, hogy mennyire kell szinkronban lennie az írással. Egy tipikus alkalmazásnál 1-2 perc eltérés nem feltétlen gond, chatnél is lehet 1-2 másodperc eltérés, realtime alkalmazás írásra meg nem hiszem, hogy alkalmas ez a megoldás, legalábbis nagyon fel kéne turbózni hozzá. Egy ilyen rendszer írásához azért komoly tervezés kell, legalább alap szinten érteni kell a ddd-hez, amihez nem árt néhány könyv elolvasása a témában, illetve legalább egy ilyen projekt. Én már elolvastam pár könyvet meg rengeteg cikket, most a gyakorló fázisban vagyok, úgyhogy nem tudok segíteni, meg nem is lenne rá időm, mert nekem is megvannak a saját hobbi projektjeim.
21

Köszönöm, kicsit

vadrian0 · 2017. Ápr. 14. (P), 12.52
Köszönöm, kicsit megvilágosodtam. :)
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?
22

Realtime

janoszen · 2017. Ápr. 14. (P), 15.12
Jo de lasd be hogy itt a realtime egyetlen egy muveletre kell csak: a vasarlas pillanatara. Minden masnal nem olyan fontos hogy van-e 20-40ms kesleltetes egy replika miatt.

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.
25

Elsore legyen egy master DB-d

inf · 2017. Ápr. 14. (P), 22.58
Elsore legyen egy master DB-d es csinalj slaveket. Ahol fontos az idozites, ott olvass a masterbol, egyebkent meg a slavekbol.


+1
24

Azaz egy példa, a felhasználó

inf · 2017. Ápr. 14. (P), 22.56
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.


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.
20

Par millio

janoszen · 2017. Ápr. 14. (P), 10.51
Par millio felhasznalot rohogve ki lehet szolgalni par szerverrol, csak esznel kell lenni. Master-slave vagy MySQL galera cluster a DB-re, nehany PHP frontend es nginx load balancernek / statikus kiszolgalonak. Kell hozza egy normalis deployment mechanizmus es gondoskodni kell a statikus fajlok elosztasarol. Ez nem olyan nagy kihivas, nem kell agyuval verebre loni.
23

Kérdés

Hidvégi Gábor · 2017. Ápr. 14. (P), 18.24
Megvan már a pénz a marketingre? Egy jónak számító 0,30%-os CTR-rel számolva mennyit kell pl. facebook hirdetésre szánni, hogy meglegyen az egymillió regisztrált felhasználó?
26

Senkit nem érdekel...

inf · 2017. Ápr. 14. (P), 22.59
Senkit nem érdekel...
27

Egy marketing stratégia nem

vadrian0 · 2017. Ápr. 15. (Szo), 00.55
Egy marketing stratégia nem csak annyiból áll, hogy 10 Ft egy kattintás, akkor kb. 50 Ft-ért kapok egy felhasználót, akkor 40 millió felhasználó 2 milliárd Ft-ba kerül. Ez egy kicsit túlságosan abszurd megközelítés lenne. Pokemon go is összeszedett 40 millió felhasználót, de őszintén szólva amikor hozzám eljutott, akkor az úgy történt, hogy egyetlen Niantic által feladott hirdetéssel sem találkoztam..
((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
Senkit nem érdekel...

mert a bankoknál így működik. :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?
28

Tanacs

janoszen · 2017. Ápr. 15. (Szo), 01.59
Ha elfogadsz tolem egy tanacsot: miutan mar jopar szep nagy rendszert epitettem, azt javaslom neked hogy elsore minel egyszerubben szerkeszd meg a rendszeredet. A bonyolult rendszereknek az a hatranya, hogy 99% biztos hogy nem ugy fog alakulni a terheles ahogy eltervezted. Szoval kezd egy masterrel es egy slave-el, kulonitsd el az idokritikus es nem idokritikus olvasasokat es kesobb raersz azzal szorakozni hogy hogy oldod meg.

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.
29

azt javaslom neked hogy

Hidvégi Gábor · 2017. Ápr. 15. (Szo), 10.18
azt javaslom neked hogy elsore minel egyszerubben szerkeszd meg a rendszeredet. A bonyolult rendszereknek az a hatranya, hogy 99% biztos hogy nem ugy fog alakulni a terheles ahogy eltervezted
Jó lenne, ha ezt Blaze-zel is megvitatnád. Pont ugyanezt írtam én is, de azt a választ kaptam rá, hogy ez (az egyszerűségre való törekvés, Occam borotvája) "nem döntési modell".
30

Ne

janoszen · 2017. Ápr. 15. (Szo), 12.55
Ennek a valasznak semmi koze az Occam borotvajahoz, hanem arrol van szo, hogy infrastruktura tervezeskor nem tudod elore megallapitani hogy hol fog fellepni a szuk keresztmetszet, igy elore eltervezni egy architekturat, amitol utana nem tudsz szabadulni, hiba.

Legyszives ne ragadd ki a kontextusbol amit irtam es ne keverd ide a Silexes topicot, nem veletlenul nem szoltam ott hozza.
32

Biztos?

Hidvégi Gábor · 2017. Ápr. 15. (Szo), 14.34
A sokaság szükségtelenül nem tételezendő
35

Biztos

janoszen · 2017. Ápr. 15. (Szo), 19.28
Biztos, mert itt szukseg lesz arra hogy bonyolitsa a rendszert, de nem mindegy hogy mikor es milyen adatok alapjan. Ez sokkal tobbet mond el annal mint sem hogy ne bonyolitsd amit nem kell, ne butitsd le a mondanivalomat ennyire.
31

a legegyszerűbb rendszer nem

MadBence · 2017. Ápr. 15. (Szo), 12.55
a legegyszerűbb rendszer nem feltétlenül a legjobb, de érdemes egy egyszerű rendszerrel indulni, és azt fokozatosan olyanra formálni, amilyenek az igények, és nem előre megtippelni az igényeket, majd aztán csodálkozni, hogy hoppá, rossz volt a tipp.
33

Jó lenne, ha nem offolnád

inf · 2017. Ápr. 15. (Szo), 18.19
Jó lenne, ha nem offolnád szét ezt a topicot is...
34

Azt hiszem már janoszen

inf · 2017. Ápr. 15. (Szo), 18.24
Azt hiszem már janoszen megválaszolta a kérdéseidet, ezek szerint a te tranzakciód nem olyan, mint a banki tranzakciók, hanem időkritikus.
36

Igazából itt nem végrehajtási

BlaZe · 2017. Ápr. 15. (Szo), 22.09
Igazából itt nem végrehajtási időbeli, hanem ordering probléma van. Ha 0ns lenne a replikáció, az ordering akkor se garantált. Erre lehet megoldás pl lockot rakni a tranzakcióban részt vevők accountjára. Ekkor garantált, hogy mindkét accounton csak ugyanaz az egy tranzakció hajtódhat végre. Ez viszont eredményezhet jó kis deadlockot, amit kezelni kell... Innentől a tranzakció végrehajtási ideje igen jelentősen megnőhet, de ez ebben a feladatban az eddig elhangzottak alapján nem tűnik kritikusnak (user kibírja, ha 1-2 sec alatt kap értesítést), illetve azért a végrehajtási idő limitálható is (ekkor a tranzakció nem sikerül, és hibát lát a user). Egy másik megoldás, hogy egyetlen service, egyetlen szálon hajtja végre a tranzakciókat egy queue-ból, az összes lokációból. Ez elsőre igen vadnak tűnhet, hiszen nem skálázódik. Viszont valójában egy jól megírt rendszer brutális tranzakció számra képes így, ezért nem is feltétlenül kell skálázni (ok, itt csak in-memory műveletek játszanak, php és sql pl szóba se jöhet). Ilyen rendszerek léteznek, de ez nagyon speciális tudást igényel, és ez a módszer inkább ott használatos, ahol valóban a végrehajtási idő a kritikus.

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.
37

Bocsánat, hogy csak most

vadrian0 · 2017. Ápr. 17. (H), 02.17
Bocsánat, hogy csak most válaszolok, csak az írásokból utánajártam/érdeklődtem a dolgoknak nagyjából, aztán próbáltam összerakni a fejemben, hogy mit is és hogyan is szeretném.

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.
38

Többen mondták, hogy fordítsd

BlaZe · 2017. Ápr. 17. (H), 14.33
Többen mondták, hogy fordítsd meg a dolgot. Kezdj azzal, amid van, indulj kicsiben. Amiről itt megy a beszélgetés, az egy komoly csapat ember munkája, és pár tapasztalt architekté, akik megtervezik.

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.
39

+1

janoszen · 2017. Ápr. 17. (H), 15.05
+1, de ezt elmondtam privat beszelgetesben is a kerdezonek: a mostani tudasommal, tapasztalatommal SEM allnek neki egybol cloudba pakolgatni a cuccot. Eloszor legyen mit futtatni, utana allnek neki rendszert epiteni hozza, es akkor sem egybol elosztott data store-al.
40

korábbi oldalamon kicsiben

vadrian0 · 2017. Ápr. 17. (H), 15.27
korábbi oldalamon kicsiben kezdtem, ingyenes tàrhelyen, aztán jött a domain, rendes tárhely, amikor meg eldurvultak a dolgok akkor saját szerver, nem volt gond, megérte. Bár ezt ki lehetett volna küszöbölni néhány dolog optimalizálásával, de akkor még gyerek voltam.
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?
41

Gond

janoszen · 2017. Ápr. 17. (H), 15.49
A gond ezzel az hogy kell egy lokalis fejlesztokornyezet. Ha rogton a Google Cloudban kezdesz el fejleszteni, akkor sosem fogod tudni a kododat normalisan helyben futtatni, tesztelni, stb. Es ez szivas.
42

Nem az infrastrukturális

BlaZe · 2017. Ápr. 17. (H), 15.58
Nem az infrastrukturális költség lesz a drága, hanem az infrastruktúra kiépítése, üzemeltetése, és a komplexitásból eredő hibák javítása. Minél bonyolultabb egy rendszer, ez annál inkább így van. Márpedig egy elosztott cloud rendszer akkor is bonyolultabb, mint egy pár gépből álló "célrendszer", ha a Google jó infrastruktúrát ad hozzá. Ahogy janoszen írta: attól, hogy cloud, nem fog magától skálázódni. Te skálázol, a cloud azt csak támogatja.

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.
43

Jó, lehet, hogy teljesen

vadrian0 · 2017. Ápr. 17. (H), 17.30
Jó, lehet, hogy teljesen félreértjük mást, Ti azt hiszitek magasabb a tudásom, és ezért hiszem azt, hogy nem értitek, amit én akarok mondani, holott lehet, hogy én tudom rosszul a dolgokat.

Te skálázol, a cloud azt csak támogatja

- 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.
44

Tanulas

janoszen · 2017. Ápr. 17. (H), 17.34
Figy, ha jot akarsz magadnak, legalabb EGYSZER rakd ossze a kovetkezoket:

- Parancssoros Linux
- nginx
- PHP-FPM
- MySQL master-slave replikaval

Nem azert hogy hasznald, hanem hogy egyaltalan ertsd hogy mitol mukodik.
45

Igen, a helyzet az hogy

vadrian0 · 2017. Ápr. 17. (H), 20.59
Igen, a helyzet az hogy linuxxal sem dolgoztam soha. A cordova + a plugonok miatt kezdtem először megbarátkozni a parancssorral is, de azt is tutorialok alapján.)

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.)
50

Szent gral

janoszen · 2017. Ápr. 18. (K), 00.11
Az a baj, hogy Te ugy gondolsz a Google Cloudra, illetve minden cloudra mint egy silver bullet, egy olyan eszkoz ami mindent megold helyetted ami skalazassal kapcsolatos es neked semmivel nem kell foglalkozni. Ez nagyon nincs igy, es ha ezen a vonalon indulsz el, nagyon csunyan arcra fogsz esni.

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.
46

Semmi sem ilyen egyszerű:

BlaZe · 2017. Ápr. 17. (H), 22.04
Semmi sem ilyen egyszerű: Avoiding datastore contention, Sharding counters. Ha lenne egy technológia, ami minden igényt kielégítene, és még egyszerű is lenne, nem lenne értelme mást használni. A Datastore a leírása alapján egy olvasásra optimalizált elosztott adatbázis, ahol a HA szinkron replikációval van megoldva, vagyis egy entity írása kimondottan lassú. Idézet a doksijából:
There is a write throughput limit of about one transaction per second within a single entity group. This limitation exists because Cloud Datastore performs masterless, synchronous replication of each entity group over a wide geographic area to provide high reliability and fault tolerance.


É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.
47

Az entity írása kimondottan

vadrian0 · 2017. Ápr. 17. (H), 22.35
Az entity írása kimondottan lassú, azzal mire célzol? (Bocsi nem tudom miről van szó nem làtom át.)

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.
48

A Datastore nem egy relációs

BlaZe · 2017. Ápr. 17. (H), 22.55
A Datastore nem egy relációs adatbáziskezelő, mint pl a MySQL. Teljesen más alapokon működik. Az entity olyasmi, mint MySQL-ben a record. A fenti nem azt jelenti, hogy 1 entity / másodperc sebességgel tudod írni az adatbázisodat, hanem hogy ugyanazt az entityt csak kb másodpercenként tudod módosítani. Tehát ha van egy usered, akkor annak a usernek az adatait csak másodpercenként egyszer tudod módosítani. Valahogy így.

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.
49

Értem. Vagyis

vadrian0 · 2017. Ápr. 18. (K), 00.06
Értem. Vagyis nagyjából.
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.
Pár gépből kihozható, amit szeretnél,

É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
51

2.

janoszen · 2017. Ápr. 18. (K), 00.17
2. Igen, az Amazon pl. kinal ilyet. Osszekattingathatod maradnak a replikacios setupot, master-slave konstrukcioban, sot meg napi backupot is csinalnak. Cserebe a PHP-s setupot neked kell osszeraknod elotte, es a DB sem lesz olcso es skalazni sem fog, azt neked kell igenyelned. Olyan MySQL-t nem fogsz kapni ami automatikusan skalazodik, mert a MySQL termeszetebol adodoan ez nem nagyon lehetseges.

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.
52

Hajaj fogom a fejemet..Nem

vadrian0 · 2017. Ápr. 18. (K), 01.01
Hajaj fogom a fejemet..

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..
53

Jaj

janoszen · 2017. Ápr. 18. (K), 11.58
*sohaj* latom nem uszom meg. Szoval akkor tartsunk egy kis gyorstalpalot arrol hogy hogyan is mukodik ez a cloudos ize.

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.
54

Hm.. na ilyesmi kielégítő

vadrian0 · 2017. Ápr. 19. (Sze), 00.38
Hm.. na ilyesmi kielégítő válaszra vártam, ez így már tényleg érthető.
Ú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. ;)