ugrás a tartalomhoz

Javascript aszinkron iteráció

janez · 2013. Júl. 1. (H), 14.10
Sziasztok,

egy olyan kérdésem lenne felétek, hogy NodeJS-ben szerintetek mikor van létjogosultsága egy feladatnak aszinkron feldolgozni, illetve mikor jobb a hagyományos szinkron megoldás?

Például adott egy for ciklus ami a példának okáért mondjuk sima összeadásokat végez egy tömbön. Ezt érdemes-e aszinkronra ki szervezni?

Mi az a határ amikor valamit szinkron vagy épp már aszinkron valósítanátok meg? A lekérdezés az adatbázis felé már egyértelműen aszinkron kategória, de az alatt hol lehet az egyensúly?
Ti hogyan vélekedtek erről?
 
1

Párhuzamosság

Poetro · 2013. Júl. 1. (H), 14.19
Ha valamit csak pontosan egy felhasználónak kell kiszolgálni, azt lehet szinkronban. Azaz az alkalmazásodat pontosan egy felhasználó fogja használni. Mondjuk írsz egy parancssoros adatfeldolgozót, ami fájlokat olvas be, vagy adatot tölt le a webről.

Ha több felhasználó használhatja párhuzamosan az alkalmazásodat, akkor legyen minden aszinkron, ami ezeket kiszolgálja (mondjuk az alkalmazás elindulása felépülhet szinkron kérésekből, de utána legyen minden aszinkron). Ez azért fontos, mivel a Node.js kód egy szálon fut, azaz ha egy felhasználónak a kérését szinkron szolgálod ki, addig nem tudsz más felhasználót kiszolgálni, annak bármilyen kérését feldolgozni amíg a szinkron esemény nem végzett.
2

Egyszerűbb úgy megfogalmazni,

Joó Ádám · 2013. Júl. 1. (H), 14.24
Egyszerűbb úgy megfogalmazni, hogy mindent érdemes aszinkron csinálni, ami várakoztatja a CPU-t. Felhasználókban nem nagyon van értelme gondolkodni, mert lévén nem preemptív, ígyse-úgyse lesz igazságosan ütemezve.
3

Igazságosan

Poetro · 2013. Júl. 1. (H), 14.30
lévén nem preemptív, ígyse-úgyse lesz igazságosan ütemezve

Hát amikor a Windows vagy az OSX valami háttérbeli indexelést csinál, azt se igazságosan teszi, mert nem oda ütemezi a CPU-t ahol nekem van rá szükségem.

off:
Már persze attól függ, mit tekintünk igazságosnak. Pl. ha veszek egy tábla csokit, és abból csak a gyerekek kapnak az igazságos? Csak mert én nem kaptam. Vagy ha mindenki kap egyenlő szeletet (de mondjuk én nem szeretem a csokit). Vagy mindenki a súlyának / korának / magasságának stb. megfelelő méretűt kap az igazságos?
7

Az igazságos szinte semmilyen

Joó Ádám · 2013. Júl. 1. (H), 15.37
Az igazságos szinte semmilyen meghatározása mellett nem az a rendszer, mert a leggyorsabb kényére-kedvére kisajátíthatja a CPU-t. Egy preemptív rendszer ad valamilyen igazságos elosztást. (Az indexelést például illene kisebb prioritással végezni, és a háttérbe szorítani, amikor felhasználóként cselekszel, de ettől még egyfajta filozófia szerint igazságos, ahogy csinálják.)
4

Köszönöm gyors

janez · 2013. Júl. 1. (H), 14.32
Köszönöm gyors válaszod.

Igen ezzel tisztában vagyok. Arra akartam kitérni, hogy minden részt érdemes-e aszinkronra kiszervezni, vagy van annyira rövid a szinkron kód futási ideje, hogy szinkronban oldjam meg.
Hozok is példát:

Adott egy rendelés beszúrása mongo-ba. A rendelés úgy épül fel, hogy tárolva vannak a rendelés tételei illetve a végösszeg. Az egyszerűsített séma:

{ items: [{ price: 0 , name: 'minta név'}], amount: 0 }
A feladat átfutni az items-en és a price-t összeadni az amount-ba a kollekcióba történő beszúrás előtt.
Azt tudom, hogy ha ezt for cikklusba szervezem blokkolok.
A kérdésem az, hogy ez egy nagyon rövid idő. Azt is tudom, hogy sok kérésnél összeadódhat.
Az ilyent is érdemes már aszinkronra kiszervezni?
Köszi.
5

Azt tudom, hogy ha ezt for

Poetro · 2013. Júl. 1. (H), 14.38
Azt tudom, hogy ha ezt for cikklusba szervezem blokkolok.
A kérdésem az, hogy ez egy nagyon rövid idő. Azt is tudom, hogy sok kérésnél összeadódhat.
Az ilyent is érdemes már aszinkronra kiszervezni?

És hogyan tudnád ezt úgy megoldani hogy nem blokkolsz? A ciklusnak előbb utóbb úgyis le kell futnia, és ezt nem igazán tudod nem blokkoló módon megtenni, mert szükséged van a számításhoz a CPU-ra. Ha pedig mondjuk feldarabolod kis részfeladatokra, és azokat nextTick-en hajtod mondjuk végre, akkor a kódod sokkál tovább fogja a CPU-t igénybe venni (akár többször annyi ideig is), mint eredetileg, úgyhogy nem igazán takarítáttál meg vele semmit, legfeljebb még X felhasználóval többet várakoztatsz (mivel azok sem jutnak CPU-hoz, csak jóval később).
6

Köszönöm. Erre voltam

janez · 2013. Júl. 1. (H), 14.48
Köszönöm.
Erre voltam kíváncsi. Hasonlóan vélekedem én is a kérdésről, de szükségem volt a megerősítésre.
8

A lekérdezés az adatbázis

Hidvégi Gábor · 2013. Júl. 1. (H), 16.00
A lekérdezés az adatbázis felé már egyértelműen aszinkron kategória
Miért?
10

CPU

Poetro · 2013. Júl. 1. (H), 16.45
Mert addig úgysem tudsz tovább haladni a kiszolgálással, amíg nem kapod meg az adatot, és addig a CPU csinálhat valami mást is, mint a te kérésedre vár (mondjuk kiszolgálhat egy másik felhasználót).
12

Aha

Hidvégi Gábor · 2013. Júl. 1. (H), 16.59
Világos, csak ezzel miért neked kell foglalkoznod, miért nem oldja meg az operációs vagy a futtatórendszer?

Vegyünk egy PHP példát (ezt ismerem), a dokumentációból másoltam:

if ($result = mysqli_query($link, "SELECT Name FROM City LIMIT 10")) {
  printf("Select returned %d rows.\n", mysqli_num_rows($result));

  /* free result set */
  mysqli_free_result($result);
}

Tehát, ha jól értem, akkor a CPU a fenti mysql kérés idejére eldobja a kapát, kaszát ("Mert addig úgysem tudsz tovább haladni a kiszolgálással"), és nem tud mást kiszolgálni ("amíg nem kapod meg az adatot, és addig a CPU csinálhat valami mást is")?

Szeretnék most már ennek a kérdéskörnek a végére járni.
14

Te vagy a futtató rendszer

Poetro · 2013. Júl. 1. (H), 17.13
Mert te vagy a futtató rendszer. A Node.js nagyon alacsony szintű hozzáférést ad. Nem ad neked webszervert, azt neked kell megírni. Nem ad sessionkezelést, azt neked kell megírni.

A Node.js-ben írt webszervered egy szálon fut. Azaz egyszerre egy felhasználó kiszolágálásával tud törődni. Van benne egy Event Loop, amibe beérkeznek az események, és a beérkezés sorrendjében feldolgozhatóak. Ha több felhasználóval akarsz foglalkozni, akkor addíg, amíg várakozol, beteszel egy elemet az EL-ba, majd visszatérsz. Ekkor átadódik a vezérlés a következő elemnek az EL-ban. Ha az történetesen egy kérés, akkor azt is elkezded feldolgozni. Ha azzal megvagy, akkor kivesz egy újabb eseményt stb. Ha az történetesen a te adatbázislekérdezésed válasza, akkor a callback függvényedben folytatódik az első kérés kiszolgálása.
Ha nem maradt több callback az event loopban, akkor a program végetért.
16

A felsoroltak a programozó

Hidvégi Gábor · 2013. Júl. 1. (H), 17.35
A felsoroltak a programozó szempontjából milyen előnyökkel járnak a hagyományos, soros nyelvekhez képest?
19

stabilitás, memória igény, sebesség

Poetro · 2013. Júl. 1. (H), 18.22
A rendszert vezérlő kód egyszerűbb, kisebb memóriaigényű, ezálatal valószínűleg stabilabb. A programozó által írt kód sajnos emiatt összetettebb lesz, de több dologhoz fér hozzá, sokkal közbetlenebben, rugalmasabban. Azaz a programod ugyan összetettebb lesz, de sokkal nagyobb szabadságot is kapsz a megvalósítás terén. Ha valaki szereti, hogy a kezét fogják, és segítik minden lépését, annak nem igazán való a Node.js.
Mivel sokkal nagyobb a programozó szabadsága, mint más interpretált nyelvekben, ezért lehetséges nagyobb optimalizációt elérni (viszont emiatt nagyobb a felelősség a programozón). Az alkalmazások a kicsiny mag miatt kevesebb memóriát fogyasztanak (egy egyszerűbb alkalmazás nem fogyasz többet 10-20 MB-nál).
Node.js-hez elérhető rengeteg modul, és egyszerű hozzá C++ felületű kiegészítőt kapcsolni a sebességkritikus részekhez.
22

Akkor eléggé szembemegy a

Hidvégi Gábor · 2013. Júl. 1. (H), 19.20
Akkor eléggé szembemegy a trendekkel, hisz az absztrakció van mindenek felett, lásd jquery. A deejay által valamelyik nap beküldött linkek egyikén láttam egy kommentet, ahol a csajszi azt írta, hogy hála Istennek a jquery miatt, nélküle nem tudna alkotni semmit.

Gyakorlatilag mindent az eseménykezelőn keresztül vezérelsz, azaz aszinkron programozol. Ez milyen előnyökkel jár a programozó számára?
24

Ez milyen előnyökkel jár a

Joó Ádám · 2013. Júl. 1. (H), 19.28
Ez milyen előnyökkel jár a programozó számára?


Nem keltik fel háromkor, hogy összedőlt az oldal a forgalom alatt.
29

Ennyi?

Hidvégi Gábor · 2013. Júl. 1. (H), 19.50
Ennyi?
30

Ja.

Joó Ádám · 2013. Júl. 1. (H), 20.15
Ja.
31

Pályafutásod alatt téged

Hidvégi Gábor · 2013. Júl. 2. (K), 07.34
Pályafutásod alatt téged hányszor ébresztettek hasonló okok miatt reggel háromkor?
34

Én nem is használok már

Joó Ádám · 2013. Júl. 2. (K), 13.52
Én nem is használok már Node.js-t :) Nem éri meg a hozzáadott komplexitás a programozásban.
35

Ezen rugózok már itt mióta...

Hidvégi Gábor · 2013. Júl. 2. (K), 14.03
Ezen rugózok már itt mióta...
38

És mióta mondjuk, hogy ez egy

Joó Ádám · 2013. Júl. 2. (K), 17.44
És mióta mondjuk, hogy ez egy eszköz bizonyos problémákra :)
36

vert.x?

Poetro · 2013. Júl. 2. (K), 15.18
39

Mivel győznél meg róla?

Joó Ádám · 2013. Júl. 2. (K), 17.46
Mivel győznél meg róla?
40

Nem akarlak meggyőzni

Poetro · 2013. Júl. 2. (K), 20.21
  • JVM
  • JavaScript
  • Ruby
  • Python
  • Groovy
  • Java
  • VMWare
26

jQuery

Poetro · 2013. Júl. 1. (H), 19.40
Én már egy jó ideje kerülöm a jQuery-t, mert lassú, nehezen debuggolható, hatalmas, és nem ad a kezedbe semilyen szemléletet. Én inkább a kisebb rendszereket szeretem, vagy azokat, amik legalább szemléletet adnak, hogy hogyan is kellene alkalmazást fejleszteni.
28

Én is csak egyszer

Hidvégi Gábor · 2013. Júl. 1. (H), 19.44
Én is csak egyszer használtam, aztán, amikor legutóbb szükség volt animációra, eldöntöttem, hogy nem fogok egy (tömörítve) 80k-s kódot használni csak azért, hogy egy divet áttegyek egyik helyről a másikba. Sokáig misztikumnak tartottam az animációkat, de így utánaolvastam, és rájöttem, mennyire primitív az egész, és egy kilobájtból megoldottam, amire szükség volt.
32

Én lustaságból használom,

inf3rno · 2013. Júl. 2. (K), 09.55
Én lustaságból használom, gyorsabban megvagyok így, mintha kézzel megírnám...
17

Szeretnék most már ennek a

Joó Ádám · 2013. Júl. 1. (H), 17.55
Szeretnék most már ennek a kérdéskörnek a végére járni.


Akkor tisztázzuk egyszer és mindenkorra:

Többszálú architektúrán az ütemezést a rendszer végzi, ezért minden szál annyi időt kap, amennyit osztanak neki, bízhatsz a szekvenciában, mert az I/O hívások idejére a szál alszik, cserébe sok szál esetén a statikusan foglalt stackek alatt elfogy a memória.

Egyszálú architektúrán nem okoz gondot a stack helyigénye, cserébe az ütemezést kézzel végzed, és megszűnik a szekvencia, mert az I/O hívások előbb visszatérnek minthogy eredményük volna.

Előnyök-hátrányok, ki-ki mérlegeljen.

Megoldás: a stacket dinamikusan foglaló rendszer kifejlesztése.

Bonthatjuk a sört?
18

A PHP is egy szálon fut, de

Hidvégi Gábor · 2013. Júl. 1. (H), 18.05
A PHP is egy szálon fut, de ilyen ütemezési feladatokkal még nem kellett foglalkoznom.
20

Apache

Poetro · 2013. Júl. 1. (H), 18.23
Mert ott a HTTP szerver elintézi neked a szálakat. Node.js-ben te írod a HTTP szervert.
21

Dehogy fut.

Joó Ádám · 2013. Júl. 1. (H), 19.04
Dehogy fut.
23

Szalad.

Hidvégi Gábor · 2013. Júl. 1. (H), 19.20
Szalad.
25

A PHP alkalmazás is több

Joó Ádám · 2013. Júl. 1. (H), 19.29
A PHP alkalmazás is több szálon fut, csak az OS ütemezi őket.

(Kocog.)
27

Lassan járj, tovább érsz : )

Hidvégi Gábor · 2013. Júl. 1. (H), 19.40
Lassan járj, tovább érsz : )
9

Aszinkronitás

Hidvégi Gábor · 2013. Júl. 1. (H), 16.14
Az egymástól független dolgokat lehet és érdemes párhuzamosítani, például, ha az egyik adatcsoportot az egyik szerverről olvasod be, a másikat a másikról. Ha a két kérés kiszolgálása közben legalább egy hardverelem közös (processzor, memória, háttértár stb.), már nem egyértelmű a nyereség, cserébe a kódod töredezett lesz, nehezebb lesz a hibakeresés, és a projektben minden új programozót meg kell tanítani a programozási stílusodra.

MadBence épp nemrég jelentetett meg egy hosszabb cikket az aszinkron programozásról, ha elolvasod a konklúziót, láthatod, hogy még nincs jó megoldás a felmerülő problémákra. Emiatt az ilyen aszinkron programozási rendszerek, pl. a Node.js játékszernek jók, de valós életbeli projektek kivitelezésére egyelőre alkalmatlanok.
11

Valós életbeli

Poetro · 2013. Júl. 1. (H), 16.51
Akkor azok, akik használják éles környezetben (LinkedIn, Wallmart, Microsoft, Voxer, Rdio stb) játékszerként használják? Nem. Ezek éles projektek, amik pénzt termelnek.
13

Nézted azokat a linkeket?

Hidvégi Gábor · 2013. Júl. 1. (H), 17.10
Nézted azokat a linkeket? Kiválasztottam hármat véletlenszerűen: pushme.to, peek.ly, ngspinners.com. Hát, nem túl komolyak.

Microsoft - Uses node.js internally
Walmart - nincs is rajta a listán
Linkedin, Voxer - mobilalkalmazásokat szolgálnak ki

Semmi konkrétat nem tudunk meg ebből a listából, azt sem tudjuk, mikor frissült. Ez alapján eldönteni, hogy mennyire használják valójában, nem lehetséges.

De úgy is lehetne fordítani, hogy van itt száz cég, aki használja, de van egymillió, aki meg nem.
15

Hát, nem túl komolyak. Te

Poetro · 2013. Júl. 1. (H), 17.22
Hát, nem túl komolyak.

Te csak komoly alkalmazásokat / weboldalakat szoktál fejleszteni?
azt sem tudjuk, mikor frissült

History
mobilalkalmazásokat szolgálnak ki

És szerinted ez az adott cégnek nem létfontosságú?
Walmart - nincs is rajta a listán

Why Walmart is using Node.js

Attól még, hogy egy API nem úgy működik, mint a PHP, vagy bármi más nem feltétlen rossz. Más szemléletet igényel, ez tény, de máshogy is működik. Próbáltál már Haskellben, Erlangban, Goban, Pytonban alkalmazást fejleszteni? Mind más szemléletet igényel.
33

Emiatt az ilyen aszinkron

inf3rno · 2013. Júl. 2. (K), 10.02
Emiatt az ilyen aszinkron programozási rendszerek, pl. a Node.js játékszernek jók, de valós életbeli projektek kivitelezésére egyelőre alkalmatlanok.


Ezt erősen kétségbe vonom. Vannak jó megoldások aszinkron programozás terén, pl ezt: https://github.com/caolan/async érdemes nézegetni. Ezen kívül még van egy rakat, köztük olyan is, ami nyelvi elemekként definiál dolgokat (ahogy nézem ez utóbbiak már nem elterjedtek, mert kényelmetlen a telepítésük). Egyszerűen utána kéne olvasni... (Ez inkább 1-2 éve volt vita tárgya nodejs terén, mostanra szerintem már lecsengett...)

Thread-eket szintén implementálta valaki nodejs-hez. A socket.io-val egyszerűen lehet chat alkalmazásokat írni, vagy bármi olyat, ami folyamatos kapcsolatot igényel. Ezen kívül láttam már olyat is, hogy drivert írtak valamilyen beviteli eszközhöz nodejs-ben. Körülbelül egy év alatt többet fejlődött nodejs, mint a php 10 év alatt, köszönhetően annak, hogy alacsonyabb szintről indul. Elég jól eltalálták, hogy mi az, amire szükség van, és mi az, amit jobb, ha a közösség valósít meg úgy, ahogy neki tetszik. Ahol nagyobb a szabadság, ott általában megjelennek a kreatív emberek, és alkotnak...

szerk:
Közben elolvastam "MadBence" cikkét is, tetszik, nagyon átfogó. Én nem úgy fogalmaznék, hogy nincs igazán jó megoldás, hanem inkább úgy, hogy mindegyik bemutatott megoldása használható aszinkron kérésekhez, és mindenki választhat a saját szájíze szerint... Általában nodejs-ben ha van egy problémád, akkor az az szokott lenni, hogy melyik létező megvalósítást válaszd, nem pedig az, hogy hogy érdemes implementálnod a megoldást...
37

Én is hasonló kép vélekedek

janez · 2013. Júl. 2. (K), 17.12
Én is hasonló kép vélekedek a NodeJS-ről.

Én pl. azért választottam projektem alapjául, mert adatbázisként elve mongodb-t használok és a JSON formátum miatt eléggé kényelmes JS-ből használni.
Továbbá a Push-os értesítéseket websocket-en keresztül eléggé könnyen meglehetett valósítani. A template-eim egyaránt működnek szerver és kliens oldalon is.
(ECT) Ezért a fő layout-on kívül szinte minden mást már a böngészőben képezek le.

De ami még nagyon megfogott a NodeJS-ben az npm. Tetszik a csomag kezelője, de a közösségi plugin-ek minősége sok gondot tud okoz. Erre valami minősítési rendszert kidolgozhatnának.
41

Hát nekem az a minősítési

inf3rno · 2013. Júl. 3. (Sze), 09.43
Hát nekem az a minősítési rendszerem, hogy megnézem az api-ját, megnézem a kódját, megnézem az issue listát, és ha mindegyik rendben van, akkor használom. Én úgy vettem észre, hogy sok kicsi modult érdemes egyberakni, mert úgy nagyobb a valószínűsége, hogy jó a kód minősége, mintha egy baromi nagyot használsz, amiben lehet, hogy elnagyolnak bizonyos részleteket. Ettől függetlenül, ha jól csinálják ez utóbbi is működhet. Pl a symfony2 kódja nagyon jól kidolgozott, 50 soros osztályok vannak benne, szóval arról kód alapján elhinném, hogy működőképes, és kevés benne a hiba. Jelenleg mondjuk SLIM-et használok, mert tényleg csak arra kell a szerver, hogy adatot szolgáltassak. A nodejs-nél azt hiszem express, express resource lenne helyette.

A postgresql-hez meg elvileg lehet feltenni javascriptet is procedurális nyelvnek, szóval relációs adatbázissal is megoldható, hogy csak js-t használjon az ember. :-) Adatbázist is a munka jellegéhez kell választani. Ha jól emlékszem a mongo olyan, hogy a vátozásoknál egyedi azonosítót tesz be. Az pl nagyon tetszik, history szempontjából marha jó megoldás... Dokumentumok tárolására jó a mongo, ahol viszont minden mindennel összefügg, ott jobb egy relációs vagy gráf adatbázis. Tényleg mindennek megvan a maga helye, komolyabb projekteknél akár többféle adatbázist is lehet egyszerre használni, mert elég jól ki tudják egészíteni egymást.
42

Köszi a tippet. Már én is

janez · 2013. Júl. 3. (Sze), 12.24
Köszi a tippet.
Már én is elkezdtem gyűjtögetni a kritériumokat. Én már az utolsó módosítás idejét is nézem. :)

Sokszor jutottam oda sajnos, hogy volt egy nagyon várt funkcionalitás, de erősen hiányos volt és ki kellett egészítenem a kódot. De azt tapasztalom, hogy ha még kérek is pull request-et, nagyon eltudják hagyni a kisebb projekteket az emberek és van, hogy fél éve mire egy pull request-em érvényesül.
Ez az egy gondom van a kis kódbázissal, de amúgy én is ezt a megoldást kedvelem.
Ami viszont bosszantó tud lenni azok az elfedő nyelvek. CoffeScript és társai. Erősen unszimpatikusak az ilyen "ruby similar" nyelvek. A typeScriptel még kibékülnék (tudom, kinek a pap, kinek a paplan), de ezek sokszor megnehezítik a hiba keresést.

Nekem is van API rész az oldalban ami külön instance-on fut.
Arra jelenleg most restify-t használok. Szeretem a változatosságot, a hagyományos kiszolgálásra meg természetesen express-t. A restify-t express kompatibilis így nem nagyon kellett tanulni és hála az égnek eléggé jó a dokumentációja.

Igen. A mongodb-t nagyon szeretem, hála az égnek a mennyiség jelen van a komplexitás felett, így viszonylag egyszerű sémám van. Szeretem még az id-ket,mert tartalmaz időbélyeget, illetve könnyen kérhető egy ID tetszőleges célra.
Illetve GridFS-t használok még ami a Mongo-t érinti, ott tárolom a képeket. Ami meglepően gyors és NodeJS alatt tudom "streamelni" is közvetlen mongo-ból.
Nem tudom mennyire függ a mérettől, de eddig alig tapasztalok overhead-et a natív fs-hez képest. Illetve a mongo klaszterezésével és backup-jával az állományaim is biztosítottak.
43

Én már az utolsó módosítás

inf3rno · 2013. Júl. 3. (Sze), 13.51
Én már az utolsó módosítás idejét is nézem. :)


Ja azt szoktam én is, meg hogy az issue listából mennyi a megoldott, stb...

CoffeScript és társai. Erősen unszimpatikusak az ilyen "ruby similar" nyelvek. A typeScriptel még kibékülnék (tudom, kinek a pap, kinek a paplan), de ezek sokszor megnehezítik a hiba keresést.


Azt hiszem vannak már ezekhez is debuggerek, de én a javascriptet szeretem... A TypeScript azért lenne jó, mert js kompatibilis visszafele, a coffeescripttől meg feláll a szőr a hátamon... Mindkettőt megnéztem, meg megtanultam olvasni, de valahogy egyikben sem szívesen fejlesztenék, amíg nem az a hivatalos js szabvány...

Arra jelenleg most restify-t használok. Szeretem a változatosságot, a hagyományos kiszolgálásra meg természetesen express-t. A restify-t express kompatibilis így nem nagyon kellett tanulni és hála az égnek eléggé jó a dokumentációja.


A restify-ra azt írták, amikor legutóbb néztem (fél-egy éve), hogy fele olyan gyors, mint az express az express resource-al, azért írtam fel magamnak inkább ezeket... Egyébként mindkettő ugyanazt tudja...

Illetve GridFS-t használok még ami a Mongo-t érinti, ott tárolom a képeket. Ami meglepően gyors és NodeJS alatt tudom "streamelni" is közvetlen mongo-ból.
Nem tudom mennyire függ a mérettől, de eddig alig tapasztalok overhead-et a natív fs-hez képest. Illetve a mongo klaszterezésével és backup-jával az állományaim is biztosítottak.


Na ez tök jó, nem tudtam, hogy mongoban is lehet fájlokat tárolni. Fájl tárolásra tipikusan a key-value adatbázisok a legjobbak, mint pl riak vagy redis... Ezek baromi gyorsak... Hmm ahogy nézem inkább kis fájloknál jók, 50mb-nál nagyobbakra nem ajánlják. Azt is írják, hogy a mongo 2gb adatbázis méretnél összeomlik. :-) Egyik sem tökéletes ilyen célra...
44

100Gb

Poetro · 2013. Júl. 3. (Sze), 14.04
Mi 100Gb feletti méretű Mongo adatbázissal dolgoztunk. Elrontottunk valamit, hogy nem omlott össze?
46

Passz, én nem használtam még,

inf3rno · 2013. Júl. 3. (Sze), 15.28
Passz, én nem használtam még, csak rákerestem, hogy large files mongodb, aztán ezt dobta. http://stackoverflow.com/questions/12894542/mongodb-gridfs-file-sizes-huge-for-relatively-small-file lehet én nem olvastam el valamit elég figyelmesen, csak átfutottam rajta. Ha tényleg ennyire jó fájl tárolásra is, akkor érdemes használni.
45

Hmm ahogy nézem inkább kis

janez · 2013. Júl. 3. (Sze), 14.40
Hmm ahogy nézem inkább kis fájloknál jók, 50mb-nál nagyobbakra nem ajánlják.

Nem tudom mennyire van jelentősége, mert un. "chunk"-okban tárolja az adatokat. Ezért is tudom kiválóan stream-elni nodejs-ből.
Két kollekció van. Az egyikben a fájl adatok, md5 sum, content-type, fájlnév, meta adatok stb... A másikban meg a fájlhoz tartozó chunk-ok. Ezeknek az átlag mérete 4Kb körüli ha az emlékeim nem csalnak. De talán beállítható.

Azt is írják, hogy a mongo 2gb adatbázis méretnél összeomlik. :-) Egyik sem tökéletes ilyen célra...

Az egyik verzióban tényleg volt valami gond, de csak a 32 bites változattal. Engem meg nem érint. :)

Viszont jó, hogy könnyen tudok a fájlok mellé plusz "meta" adatot tárolni. Pl.: Milyen változat, melyik felhasználóé, stb...
Ezen téren is eléggé kényelmes.

Infó: Mongo GridFS