Websocket - Node - MySQL
2015-06-22T09:54:24+02:00
2015-06-23T15:27:31+02:00
2022-07-19T03:57:48+02:00
  • mar ertem, koszonom 

    Nos igen, sot akar fajlban is lehet tarolni bar valoszinuleg az lenne a legrosszabb valasztas.  

    A masik pedig, hogy olyan modul is kell node-hoz ami kepes azt fajta nosql-es db-t hasznalni amit valasztok. Mongodb eseteben van modul.
    Valoszinuleg 2 db-t fogok hasznalni. Egy relacios muszaj lesz, de az egyszerubb dolgokhoz ami realtime-os, oda valoban jobb egy nosql-es db-t hasznalni teljesitmeny miatt. 
    Mutasd a teljes hozzászólást!
  • Szvsz Denzelii arra célzott, hogy az adatokat nem csak relációs adatbázis kezelőkben lehet tárolni, választhat vmilyen nosql-es megoldást is (pl. mongodb).
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Nekem az szúrta a szemem, hogy olyan mintha nem ismernéd a nagyságrend fogalmát (nyilván ismered, de akkor meg lusta vagy gondolkodni). Egyébként meg sok sikert a projekthez! Talán lesz belőle valami, csak éppen a számok lesznek "kicsit" mások benne. :)
    Mutasd a teljes hozzászólást!
  • Koszonom a hasznos hsz-odat! 

    Lenyegeben db kell, mert az adatokat tarolni szeretnem, hogy a kliens vissza tudja nezni az elkuldott adatokat a kesobbiek folyaman is miutan lekapcsolodott a szerverrol, majd kesobb vissza.

    Es igen sok meg a szurke zona, egyelore csak elmelkedek / tajekozodok. Ninccs eldontve meg semmi sem, ugy ahogy a megfelelo technologiak  sem.
    Mutasd a teljes hozzászólást!
  • 1: "a szent pillantban kene 1000 user felol erkezo adatokat menteni db-be"

    Hát nem tudom mekkora rendszert tervezel, meg úgy mi ez, de előbb mérj hasonló rendszereken, mert ez csak dobálózás.
    1 microsecben 1000 kérés, mindegyik kérés legyen 100 byte, ez 100Mbyte/sec - és ez még csak egy elvi adatmennyiség becslés. A kérések száma 1000millió másodpercenként.
    (Nálunk egy ügyviteli rendszerben 6000 aktív user használatával (van interfészen gépi bekérdezés is, de azt nem számít bele) másodpercenként kb 5 kérés esik be. Nyilván ez nem egy facebook. De pl a whatsapp -ban kb 750ezer kérés másodpercenként, ami több mint 3 nagyságrenddel kisebb mint a te rendszered (2014 decemberi adat)).

    2: Fordítva csinálod. Amíg nem tudod mit, mekkora számban és hogyan, addig nyilván nem tudsz hozzá elemet sem választani. Vagy hát lehet, de ez nem a jó tervezési út.

    Előbb tudd mit kell tudni, aztán keress hozzá megfelelő eszközt/technológiát.

    Csak gondolat ébresztőnek, ők se azonnal a whatsappx1000 kéréssel indítottak.
    http://www.slideshare.net/directi/building-a-scalable-architecture-f..

    3, 150 kapcsolat: amit beesik a kérés a webserverre (jah, hát az egy másik kérdés, hogy a kérések nem beesési sorrendben dolgozódnak fel), a webserver feldolgozza, majd meghívja a te feldolgozódat, az ügyez, majd kérsz a poolból egy db kapcsolatot, gyorsan letárolod, elengeded a poolt, összerakod a választ, és kiküldöd. Így már remélem megérted jobban, hogy 1000 user kapcsolatot miért lehet kiszolgálni 150 db kapcsolattal. Persze ez feladat és tervezés függő is, de nyilván nagy terhelésre készülsz, azaz nem akarod végig foglalni a db kapcsolatot, miközben pl a választ rakod össze.

    Mivel a feladatot nem ismerjük, de eddig semmi olyat nem mondtál, amihez mysql kell, az is kérdés hogy rdbms kell-e. 

    Sok itt még a szürke zóna.
    Mutasd a teljes hozzászólást!
  • Nem bizott ram senki semmit, sajat projekt es sajat magam fejlesztese miatt tajekozodok csak. Gondolom te se ugy kezdted, hogy rogton mindent tudtal, es neked se pottyant az oledbe a tudas. Bele kellett kezdj egy projektbe, ahhoz hogy tanulj, es hogy a vegen kimondhasd, hogy kesz eleted elso nagy terhelesu rendszere, nem?

    Irtam is, hogy irrelevans, de attol meg erdekelhet, hogy ebben az esetben mi tortenne a db-vel, vagy mit kezdene  ennyi inserttel. Es nem fer vegtelen sor sem egy tablaba, sem vegtelen szoveg egy mezobe, etc. 
    Mutasd a teljes hozzászólást!
  • Azt nem a socketes kapcsolodasra ertettem 
    Mutasd a teljes hozzászólást!
  • Ezzel ("egy idoben 1000 user insertel db-be") azt akartam mondani, hogy 1 mikroszekundumon belul (vagy meg kissebb ertek) tehat lenyegeben abban a szent pillantban kene 1000 user felol erkezo adatokat menteni db-be, mert mindenki pont akkor abban a szent pillanatban kuldott el egy adatot a server fele.

    Nehéz elképzelnem erre egy életszerű példát, meg azt is, hogy ilyesmit kellene fejlesztened (és hogy rád bízták a fejlesztést ennyi tapasztalattal). Biztosan komolyan gondoltad ezt a másodpercenkénti 1 milliárd(!) beszúrást? Azok a beszúrások sem 0 idő alatt hajtódnak ám végre, meg ugye nem fér végtelen rekord az adatbázisba stb.
    Mutasd a teljes hozzászólást!
  • Egyenlore != egyelore

    + "Az viszont biztos, hogy csak http-n keresztul tud kapcsolodni majd a kliens."
    vs "WebSocket is a protocol providing full-duplex communication channels over a single TCP connection"

    Mutasd a teljes hozzászólást!
  • 1, Igaz, az kimaradt (sajnos utaloag mar nem tudtam modositani ), bar a socket.io-rol egyertelmunek tunhet, hogy folyamatos kapcsolatrol van szo.

    2, Lehet rosszul fogalmaztam. Ezzel ("egy idoben 1000 user insertel db-be") azt akartam mondani, hogy 1 mikroszekundumon belul (vagy meg kissebb ertek) tehat lenyegeben abban a szent pillantban kene 1000 user felol erkezo adatokat menteni db-be, mert mindenki pont akkor abban a szent pillanatban kuldott el egy adatot a server fele. Ez lenyegeben akkor 1000 kapcsolat lenne a db-vel ha jol gondolom. MySQL pedig írja, hogy max 151 lehet amit persze feljebb lehet tornaszni.  Tudom, hogy ez eleg inrelevans, hogy 1000 kliens pont abban a szent pillanatban kuldjon adatot a server fele, de ez most csak elmelet.

    3, Ezeket meg en se tudom, elotte meg eleg sok szamitast kell vegezeni, es functionokat kitalalni pontositani a folyamatokat stb.. Erre meg sok ido ra fog menni. Egyenlore csak a rendszerek stabilitasa es terhelhetosege felol erdeklodok, hogy megfelelo rendszert es technikakat hasznaljak.
    Az viszont biztos, hogy csak http-n keresztul tud kapcsolodni majd a kliens.

    4, Igen ezekkel tisztaban vagyok en is, hogy jol kell felepiteni ami fontosabb mint a 150 kapcsolat, de ettol fuggetlenul az se hatrany ha a mysql-t feltornaszom magasabb számra. Jelenleg egy 16GB memorival rendelkezo felhoben telepitett Linux szerverrol van szo, aminek mereteit barmikor tudom novelni (CPU, HDD, RAM). A biztonsag pedig fontos, SSL lesz.

    Nem feltetlen kotodom a mysql adatbazishoz, de lenyegeben ez a legelterjettebb, legsikeresebb, legismertebb db. Talan meg a PostgreSQL is ismertebb, de a MySQL ugy tudom jobb tobb szempontbol is.
    De lehet letezik mas tarolo eszkoz ami jobb lenne a feladathoz. Egyenlore azonban MySQL-ben gondolkozok , azonban ha tudsz jobbat egy ilyen jellegu projekthez, szivesen meghallgatom. MySQL beallitasait nezve akar az is egy lehetseges szempont lehet, hogy 2 adatbazis lesz. 1 a fontosabb adatoknak ahol a biztonsag fontosabb, a masik pedig a kevesbe fontos adatoknak ahol viszont a high priority a sebesseg.

    Nem mondtam, hogy apache-t fogok hasznalni. A megfelelo konfiguralas alatt a nagyobb teherbirasra celoztam. A biztonsag az pedig meg egy kulon tema lesz. Azt pedig tudom, hogy sok ido a megfelelo beallitas, en se ugy gondoltam, hogy 1 nap alatt megvan a szerver. Egyenlore meg csak tajekozodok. Neztem mar par szervert, pl Nginx-et vagy Lighttpd-t ezek kozul a Lighthttpd nem tunik rossznak, de meg utana kell jarnom ezeken kivul milyen lehetosegek vannak, illetve nova76 emlitette az expertet is lehetseges  servernek. De mivel a folyamatok tobbsegeben real-time-rol lesz szo, igy keves olyan folyamat lesz ami nem igenyel folyamatos kapcsolodast, vagyis az ilyen jellegu terheles csekely lesz.

    Abban igazad van, hogy nem mindegyik bongeszo tamogatja a websocketet de a socket.io egy olyan modul ami elsodlegesen websocketen kommunikal, de ha ez a kapcsolat nem sikerul neki akkor alternativakent hasznal flasht, vagy xhr-pollingot ez pedig a bongeszotol is fugg mit hasznal.

    Chrome, Firefox, Safari - WebSockets
    IE, Opera - XHR-Polling
    Mutasd a teljes hozzászólást!
  • Meg mindig nem arultad el mire kellene. Ha chat akkor viszonylag egyszeruen megoldhato az emlitett timestamp-el. Ha egy business model (akar destruktiv) update-jei akkor sok sikert...

    De az mert baj, ha eseteleg elobb kap meg egy broadcastolt uzenetet a kliens, mint a csak neki szant vagy csoportnak szant uzenet?

    Nem csak ez a baj de a neki szant uzeneteket is kaphatja rossz sorrendben ami a fenti esetben eleg katasztrofalis lehet.

    De mivel unom, hogy kb 3x-ra irom le ugyanazt ezert a tovabbiakan sok sikert en leptem!
    Mutasd a teljes hozzászólást!
  • Tehat azt mondod, hogy az uzenetek (mondjuk egy chat eseteben) nem elkuldesi sorrendben erkeznek meg a klienseknek? Tehat elobb lefuthat egy broadcast mint egy emit.

    De az mert baj, ha eseteleg elobb kap meg egy broadcastolt uzenetet a kliens, mint a csak neki szant vagy csoportnak szant uzenet? Ha szukseges lenne ez akkor ahogy irtak az alatalad is linkelt oldalon egy timestampel megoldhato.

    Nem tudom, talan esetleg felmerulhet az is, hogy egy celzott uzenet ami csak azt az 1 klienst erinti joval kesobb erkezik meg a kliens fele ha rengeteg uzenet megy a server fele. Ha ez igy van akkor muszaj a db-t kerdezgetni.
    Mindenesetre nekem volt 1-2 eve egy node + socket.io chatem az remekul mokodott 100+ aktiv userel. Chaten belul pedig sok folyamat volt, (privat ,kozos, szobakba lepkedes, user list, admin funkciok (bannolas), ecetara ecetera) ... Ennyi kliensnel nem volt semmi problema az uzenetek megerkezesevel, viszont mondjuk ez ilyen 10 esetleg 100 ezernel nem tudom hogy valosul meg.
    Azt tudom hogy alapesetben behal azt hiszem ilyen 1300 koruli egyideju kapcsolodasnal (regebben teszteltem), de lattam kesz megoldasokat is ahol ezt a szamot 500 ezerre sot 1 milliora tornaszak fel.
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy igazán semmit se írtál le, és a tanácsokat se fogadod meg :) Nem baj, mindenki másképpen tanul.

    1, A nyitóban szó sincs arról, hogy esemény alapon a szerver küldene valamit a kliensnek, sima kérés-válasz forgatókönyvet írtá le.
    Később megjelent az igény, amit valami real time-al indokolsz, de hát ez alma-körte, se közük egymáshoz.
    A real time alkalmazások nagyon mások, és mások a tervezésük is!
    2, Írod hogy nagy terhelés, meg 150 meg 1000 kérés/kapolat egy időben. Megint nem jó, mert olyan hogy egy időben nincs. Olyan már lehet, hogy mondjuk 3 sec alatt kell 1000 kérést kiszolgálni. De ennyit ki lehet szolgálni 150 adatbázis kapcsolattal! Ne keverd a dolgokat.
    Ha van elvárt max, és átlagos terhelés, akkor az sokat segít. De az nem terhelés hogy egy időben 1000. Az már lehet, hogy másodpercenként 1000 kérés.
    3, Ne a szervert, mysql-t válaszd ki, hanem írd le, fogalmazd meg a problémákat. Ugyanúgy a terhelésnél is, ne légy pongyola. Mik a folyamatok, milyen gyakoriak, hogyan kell lefutniuk, mikor és kb mennyi válasz lehet, és azokat hogyan lehet visszaküldeni, mik a feltételek (pl, kell-e arra készülni, hogy csak http-n fog a kliens kapcsolódni... nem mindegy ez sem, mi nem tudunk erről semmit).
    4, Nagy terhelés? Nagy rendelkezésre állás? Akkor több node, terhelés megosztás, redundancia, adat repkilás, mentés. Sokkal fontosabb, mint hogy 150 kapcsolatot bír a mysql (bír többet is).
    Csak egy szerverben gondolkozol, az meg akkor kis terhelést jelent, és az üzembiztonság se lehet túl fontos.

    Ja, és még az se derül ki, miért kell neked mysql. No meg ha már mysql, mégis melyik tároló motorral? Kell a tranzakció biztonság vagy sebesség kell? Lehet nem is mysql kellene?

    Amúgy miért apache? Mi az hogy megfelelően konfigurálva? Szerintem csak ezzel heteket el lehet lenni. (és apache eszi kb a legtöbb erőforrást, hacsak nincs valami egyébb érv mellette, nem tűnik jó választásnak).

    A chat és a multiplayeres játék kb ugyanaz ebből a szempontból. Gmail az megy long poll-al is, nem csak sockettel lehet ezt elérni. Nyilván sockettel jobb, de ugye sok helyen a websocket nem jön át a tűzfalon.

    Hmm, és sok socketnél (1000 nyitott socket még nem sok) szerintem ez az architektúra nem lesz nyerő.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Ugy valoban nincs szukseg ra, arra szerintem eleg egy apache is megfeleloen konfiguralva. Bar nem tudom melyik jobb node + express modul vagy apache megfelelo szerver tuningal. Azonban egy real time-os projektnel socket kell. Abba most  nem megyek bele pontosan milyen funkciokhoz kell, de lenyegeben eleg sok function ezen alapulna. Socket.io.nal ha objectumban tarolom akkor disconnection-nel deletezem az obejctumbol az ID-t. De nem is  biztos, hogy szukseges tarolnom azt ideiglenesen.

    Egyebkent chaten kivul eleg sok mindenre lehet hasznalni. Nezz meg egy gmailt peldanak, vagy egy google docs-ot, de akar egy multiplayeres jateknal is lehet hasznalni.
    Mutasd a teljes hozzászólást!
  • Szerintem ez nem fog gondot okozni a socket-nek.

    De ha meg mindig ketelkedsz teszteld csak le es lass csodat eleg sok userrel mukodik ez az otlet: Creating a Node.js Server/Client with Socket.IO & MySQL
    Mutasd a teljes hozzászólást!
  • Én a projekted nem ismerem, de ha csak a szerver felé megy kérés és onnan válasz, akkor nincs szükség a socket.io-ra.  

    Nagy terhelésű oldal mondjuk az index.hu, ott például semmi szükség nincs rá. Ha egy cikkre rákattintasz, akkor bejön egy új oldal. A websocketes kapcsolat ezzel meg is szakadna, ha lenne. A chat esetén a socket.broadcast.emit utasítás az, amit nem tudnál helyettesíteni. Esetleg időzített ajax hívásokkal lehetne pótolni a kliensek felől. Azonban a chat kivételével nehezen tudnék olyan példát mondani ahol erre égető szükség lenne a weben.

    En szerintem pedig egy valtozoban tarolt objectumban tarolok bizonyos adatokat socketben majd ha megszunt a kapcsolat a klienssel torli az objektumban az adott kliens data-jat, pl.: egy ID-t.

    Az id-t önmagában akkor elégséges törölni ha van valami programkód, ami felszabadítja a lefoglalt memóriát. Mivel az általad készített kód nem fejeződik be, nem indul újra, erről, lehet, neked kell gondoskodnod.
    Mutasd a teljes hozzászólást!
  • Az otleted nagyon jol mukodik 1 felhasznalos kornyezetben. Probald meg implementalni a kulonbozo user-ektol, kulonbozo idoben erkezo uzeneteket kliens oldali szinkronizalasat, ra fogsz jonni, hogy mire gondoltam(pl, hogy a webscoket gyors de nem instant => race conditins).
    Mutasd a teljes hozzászólást!
  • "Egy kísérlet felér ezer szakértői véleménnyel".
    Próbáld ki.
    Mutasd a teljes hozzászólást!
  • Szerintem az az 1 oldal amit te annak hiszel lesz tobb szaz is foleg ha tartod az arrogans tempot es varod a sultgalambot a tahozasod melle.

     Nem akartam arrogans lenni vagy taho, ha annak tuntem elnezest kerek. es nem varom, folyamatos "searching/learning" fazisban vagyok amellett, hogy nyitottam a temat.



    Az amit az utolso hozzaszolasodban leirtal architectura pedig arra lesz jo, hogy tutira inkonzisztensen tartsd kliens/szerver allapotat.

    Ezt kifejtened bovebben? Ha mondjuk egy chatrol van szo, akkor eleg ha csak insertelek socketnel, majd insertalas utan nezek egy resultot es csak siker eseten broadcastolom az uzenetet a tobbi usernek. En ugy gondolom felesleges ugyanezt az uzenetet db-bol lekerdezni ha mar egyszer elkuldtek a socket fele es az sikeresen insertalta db-be.  Igy mert lenne ez inkonzisztens a kliens / szerver allapot szempontjabol??
    Mutasd a teljes hozzászólást!
  • De lenyegeben kell a socket.io a folyamatos kapcsolat miatt a szervertol. Nem csak chat eseteben lehet ez hasznalatos hanem pl.: egy esemenytortenes folyamatos figyelesenel. A real Time-on is ott van a hangsúly nem csupán a nagy terhelesen. -  Igaz ezt a temanyitasnal nem irtam le.

    En szerintem pedig egy valtozoban tarolt objectumban tarolok bizonyos adatokat socketben majd ha megszunt a kapcsolat a klienssel torli az objektumban az adott kliens data-jat, pl.: egy ID-t.
    Mutasd a teljes hozzászólást!
  • Szerintem az az 1 oldal amit te annak hiszel lesz tobb szaz is foleg ha tartod az arrogans tempot es varod a sultgalambot a tahozasod melle.
    Az amit az utolso hozzaszolasodban leirtal architectura pedig arra lesz jo, hogy tutira inkonzisztensen tartsd kliens/szerver allapotat.
    Mutasd a teljes hozzászólást!
  • Szerintem az tobb 100 oldal amit te említesz, boven jo lesz 1 oldalnak is.

    De nekem eleg az is ha csak a feltett kerdesekre kapok valaszt.
    MySQL -es kerdesemre pedig mar meg is talaltam a valaszt. Miszerint a default beallitas 151 keres eg idoben de ezt fel lehet tolni pl: 16 GB memnel ez 1000 is lehet. Ezzel mar tovabb is tudok lepni afele, hogy sockettel nem fogom kerdezgetni a db-t ha insert tortent, helyette csak insert lesz az adatokat pedig csak broadcastolom.  Insertalast pedig csomagonkent kuldom kesleltetve ha tul lepne a korlatot mondjuk..
    Mutasd a teljes hozzászólást!
  • A nagy terheltség miatt nincs szükséged a socket.io-ra. Az a folyamatos kapcsolat fenntartásához kellhet (pl:  chat). Alapesetben a node.js -ben készült http szerver (pl: express) lesz a kiszolgáló, mint mondjuk a PHP-nál az apache. A kapcsolat felépítése után letöltődik a tartalom és a kapcsolat megszakad. A memória kezelés nem tudom mennyire automatikus, de gondolom, ha létrehozol egy változót. akkor az megmarad, amíg le nem törlöd. PHP-s fejjel ez elég ijesztő, mivel nálunk ez nem jelenti azt hogy előtte (létrehozás előtt) és utána (törlés után) ugyanannyi memóriád van, hanem hogy mindig fogy, egészen addig amíg a kapcsolat végül befejeződik és az apache felszabadítja a memóriát és akkor kezdődhet elölről a folyamat egy másik szálon.
    Mutasd a teljes hozzászólást!
  • A téma valószínűleg azért került a társalgóba, mert sem nem állás téma (nem munkát végeztetnél fizettségért), sem nem tudástár (nem egy konkrét kérdést tettél fel). Helyette a téma úgy néz ki, most kezdted, és még azon a felismerésen sem vagy túl, hogy ezernyi mindenről kell nagyon sok100 oldalnyit végig olvasnod, ami sem nem 2 perc lesz, sem nem fogja senki újraírni azt a könyvtárnyi mennyiségű ismeret anyagot, amit az internet már régen leírt. Szóval az egyik modi csak legyintett egyet (mindennapos az eset), és átrakta.
    Mutasd a teljes hozzászólást!
  • Es hol marad a figyelmeztetes, hogy athelyeztek a temat?? 
    Mutasd a teljes hozzászólást!
  • Udv,

    Egy nagy terhelesu projekt megvalositasahoz keresem a legmegelelobb technikakat.

    Manapság ugy tudom a websocket a legmegfelelobb technika erre a celra.

    Erre en Node.JS + Socket.IO kombot hasznalnam. - Ezt korabban mar használtam, de csak uzenet tovabbitasra, adat tarolas db-be nem volt. Azt tudom, hogy a kapcsolati limit vegtelen es csak memoria fuggo, hogy mennyi kliens kapcsolódhat egyszerre a szerverhez.

    De mi van a MySQL-el?? Teszem azt pl.: egy idoben 1000 user insertel db-be, nem fagy ki ettol az adatbazis??

    Aztán insertelest, hogy celszeru megoldani, socket.io-ban insertalni vagy php + ajax ami mellett egyidejuleg a socketnek is elkuldeni a data-t?? (Logikusan socket.io-ban kene insertani szerintem, de egy mysql injectionnal mit kezd?!)

    Es ott van meg az is, hogy db-bol erdemes-e selectelni sockettel ha insertalas tortent, vagy eleg csak kapcsolodaskor egy select, a tobbi adat tovabbitasat pedig select nelkul broadcastolni insertalas utan??


    Node.JS + Socket.IO komboval meg 2 problemat fedeztem fel:

    Az egyik, hogy lekapcsolodik a szerverrol a kliens adott ido utan. Talan mintha IE -nel ez surubben fordulna elo mint mondjuk Chromenal. Az ido valtozo, valamikor par perc vagy par masodperc utan szunik meg a kapcsolat (ez a ritkabb kb. 100:1) de legtobb esetben tobb ora vagy 1 egesz nap kell hozza. Ez nem tudom mert van, de talan eg kapcsolat ujra epites jol johet ilyenkor.

    A masik problema pedig, hogy a socket szerver eleresi utvonalanak es portjanak tudataban barki kapcsolodhat hozza. Hisz a JS nem rejti el az utvonalat. Felesleges kapcsolatok pedig nem kellenek. Ezzel mit lehet kezdeni??

    Nem biztos, hogy ez a rendszer a legjobb megoldas a projekt megvalositasahoz.
    De ha esetleg tudnatok javasolni mas rendszereket / nyelveket / technikakat / otleteket nagy terhelesi rendszerek fejlesztesehez azt is szivesen meghallgatom. 
    Mutasd a teljes hozzászólást!
abcd