ugrás a tartalomhoz

Fájlba vs. MySQL adatbázisba írás

Anonymous · 2006. Szep. 7. (Cs), 23.01
A problémám a következő:

Folyamatosan, relative sok adatot kellene eltárolni / szolgáltatni. Egészen konkréten egy chat rendszerről lenne szó.

Úgy gondoltam, hogy két megoldás jöhet szóba.

Az első variáció: felhasználónként a szerveren létrehozok egy fájlt, majd a PHP abba beleteszi / abból kiolvassa azt a tömböt, ami a kívánt adatokat tartalmazza (felhasználó info / beszélgetések tartalma). A fájlt nem kell mindig létrehozni, csak egy alkalommal, amikor pedig a felhasználó kilép, akkor a beszélgetés tartalmát törli a rendszer.

A második variáció: ugyanezeket az adatokat MySQL adatbázisba teszem.

(A harmadik variáció, amit elvetettem: fájlban / adatbázisban tárolás.)

Mielőtt megköveznétek, hogy nem használom a Google-t, leírom, hogy sok fórumot végignéztem, kerestem Google-vel megoldást és teszteltem is élesben a szerveren, hogy melyik lenne a gyorsabb, de:

az a gond a teszttel, hogy ameddig a Windows-os gépen, localhost alatt nagy volt a különbség a sebességnél a MySQL javára (kb. kétszer olyan gyorsnak tűnt), addig a Debian szerver alatt nem tudtam eldönteni, hogy melyik a gyorsabb, mert hol a fájlba írás látszott fürgébbnek, hol a MySQL.

Tudom, hogy 10-20 usernél egyik megoldás sem okoz gondot, de tegyük fel, hogy egy szép napon jó sokan lesznek, és akkor már lényeges, hogy melyik megoldás a gyorsabb.

Mindenféle ötletet és javaslatot várnék.

PS.: a chat nem PHP alapú, a részletekbe meg inkább ne menjünk bele. A lényeg, hogy sok az adat és gyorsan jön (és gyorsan kell kiolvasni onnan, ahova tesszük). :)
 
1

szerintem MySQL

krey · 2006. Szep. 7. (Cs), 23.18
Egy ilyen összetett alkalmazáshoz én biztosan nem látnék neki fájlokkal. Az adatbáziskezelők nem véletlenül használtak széleskörben, gyors és összetett kéréseket tudnak végrehajtani. Ha te szövegfájlokban szeretnél adatokat tárolni, akkor meg kell oldanod, hogy abból épkézláb adatokat kapj, nő a fejlesztési idő, mert írnod kell egy scriptet, ami kezel egy adatbázist.
Nem tudom, hogy MySQL-ben könnyen meg lehet-e oldani pl. azt, hogy amikor egy kérés módosítja a tábla tartalmát, akkor lefusson egy script, de biztosan meg lehet és az viszont kézenfekvő lenne, mert egy démont kell futtatnod 2 helyett (mert gondolom MySQL-t mindenképp használsz).
Persze sajnos nem értek az ilyesmihez annyira, mint szeretnék...

üdv. krey
2

Adatbázis

Rici · 2006. Szep. 7. (Cs), 23.27
A lényeg, hogy sok az adat és gyorsan jön (és gyorsan kell kiolvasni onnan, ahova tesszük).

Adatbázis, erre a célra egyértelműen ez való.

Márcsak azért is, mert ha egy fájlhoz valamilyen okból több egyidőben futó szkript hozzáférni, akkor az könnyen galibákat okozhat.

Adatbázisnál ilyen gond nincs, persze nyilván akkor, ha a felhasználók egyes megszólalásai különböző rekordokba kerülnek.

Bár igazából egy chat szervernek, ahol nem kell a későbbi visszanézés lehetőségét biztosítani, véleményem szerint nem háttértároló alapú megoldással kéne dolgoznia, hanem lényegében mindig csak a cél klienseknek továbbítani a forrás klienstől jött üzeneteket.
3

memcached

Hodicska Gergely · 2006. Szep. 8. (P), 01.11
A fájlt nem kell mindig létrehozni, csak egy alkalommal, amikor pedig a felhasználó kilép, akkor a beszélgetés tartalmát törli a rendszer.

Ha nem fontos számodra, hogy a beszélgetések megmaradjanak, akkor érdemes lehet elgondolkoznod a memcached használatán, ez biztosan gyorsabb lesz, mint a fájl vagy DB.


Felhő
4

Mysql heap, vagy akár socket szerver

vbence · 2006. Szep. 8. (P), 13.02
Esetleg használhatsz HEAP tipusú táblát, ilyenkor csak a memóriában zajlik a dolog, a sebességgel nem lehet probléma. Takarékossági szempontból: nem kéne tárolnod az összes üzenetet a társalgás végéig, minden üzenet csak kézbesítésig maradna a szerveren, ha a címzett leszedte magának törlődhet az adatbázisból is.

Az ilyen interaktív alkalmazáshoz, mint egy cset mindenképpen valami AJAX megoldás dukál, de nézz utána a COMET modellnek is, ha teheted inkább azt használd.

Még frankóbb lenne a php socket kiterjesztését hazsnálni (persze ha a szolgáltató engedi). Ilyenkor gyakorlatilag írhatsz egy chat szervert, ami comet segítségével teljesen valósidőben működhet. A php oldalán pont erre van egy demó.
5

A MySQL HEAP lesz a megoldás...

Anonymous · 2006. Szep. 9. (Szo), 01.52
Köszönöm mindenkinek a válaszokat.

A memcached jobbnak tűnik, mert másra is használható, nem csak MySQL-re, azonban az időm kevés és a legegyszerűbb, valamint a leggyorsabb módon szeretném megoldani a dolgot, úgy hogy azt hiszem, hogy az a bizonyos "HEAP tipusú tábla" lesz a megoldás. A szolgáltató szerencsére nem gond, mert a szerver saját.

A részletekbe nem akartam nagyon belemenni, de ha már ott tartunk... :)
Az AJAX típusú megoldás volt a Java utáni első ötlet, még a legelején, azonban hosszú rágódás után mégis a Flash mellett döntöttem. Tudom, hogy a Java lett volna talán a legkézenfekvőbb, de ahhoz nem értek ( még... :) ).

A COMET modellt nem ismerem, de majd utánanézek. Köszi.

Takarékossági szempontból minden privát üzenet csak a kézbesítésig marad a szerveren, az adatforgalom pedig a lehető legminimálisabb lesz. A szobák tartalma viszont folyamatosan az adatbázisba kerül elmentésre, ahonnan egy script időnként kiírja egy sima text fájlba, a kiírt sorokat pedig törli a táblából.

Nobel-díjat nem kapok ezért a megoldásért, de a lényeg az, hogy működjön és lehetőleg csak kisebb mértékben legyen leterhelve a szerver.