ugrás a tartalomhoz

Mennyi adatot lehet tölteni egy kliens oldali tömbbe?

s_volenszki · 2008. Dec. 9. (K), 21.58
Sziasztok!

Van valakinek tapasztalata azzal kapcsolatban, hogy ha elkezdek AJAX-szal töltögetni egy tömböt kliens oldalon, akkor az nagyjából mekkora mennyiségű adattal bírkózik meg?

Tervezek egy alkalmazást, ami bizonyos feltételek szerint adatokat válogat egy olyan adattáblából, aminek a tartalma nem változik. Arra gondoltam, hogy az alkalmazás elindítása során AJAX-szal betöltögethetném az adatokat egy tömbbe, majd keresés esetén a kliens nem kommunikál a szerverrel, kizárólag a tömbben keres.

Nagyjából soronként 50-100 karakterről van szó. Szerintetek mennyit lehet ebből tömbösítnei úgy, hogy használható is maradjon?
‹ webshop form-ok ellenőrzése css property * value ›
 ■
1

HTML

Poetro · 2008. Dec. 9. (K), 23.40
Szerintem lehet hogy jobban jársz, ha egy HTML struktúrát írsz ki, és igény szerint alakítod JS tömbbé, valószínűleg a böngészők jobban elboldogulnak egy nagyobb HTML struktúra tárolásával mint a JS memória managere, ugyanakkor kicsit lassabb lesz a keresés inicializálása, mivel a HTML struktúrádat vissza kell alakítani tömbbé, bár egy jó kis DOM bejárással az se túlságosan lassú.
2

re

toxin · 2008. Dec. 10. (Sze), 09.33
figyelembe véve az anno András által leírtakat, ahol a liligo projektről: liligo.fr - ről volt szó, pl. a hotel tab-ról indítva egy keresést (paris) - majd ennek lefutása utána konzolban vizsgálva a következő két, asszociatív ill. normál, tömböt: Results._groupsStorage , Results.ActiveGroups._activeGroups, előbbi az összes, utóbbi a középen látható elemek modelljét,adatforrását tárolja - kb. 800-900 elemig marad használható ill. felhasználó által is elfogadható reagálókészségűnek ítélt (1s alatt) a rendszer, akár baloldalt a filterezést vagy középfent az elemek sorrendezését állítva (előbbi a Results._groupsStorage, utóbbi az előbbiből paraméterezve kimásolt elemek tömbjén : Results.ActiveGroups._activeGroups-on dolgozik)

üdv Csaba
3

Érdemes valamilyen köztes megoldásban gondolkoznom?

s_volenszki · 2008. Dec. 10. (Sze), 10.14
Mit gondoltok, érdemes valamilyen köztes megoldásban gondolkoznom? Létezik olyan kliens oldalon futó, böngészőbe ágyazott alkalmazás környezet (AS,JAVA), ami képes kliens oldalon szöveges fájl olvasására és írására, vagy hatákonyabb memóriakezelésre?

Nekem abból a kb. 50-100 karakteres sorból lehet akár 5000-10000 is...
4

Két irány

yaanno · 2008. Dec. 10. (Sze), 18.43
Az egyik irány hogy telepíttetsz az userrel valamit:

1. Használhatsz esetleg Google Gearst - hátránya hogy az usertől engedélyt kell kérni az eléréséhez
2. AIR, itt elég tág tered van, ha jól tudom van benne local storage (sqlite)
3. Silverlight, no ezt nem ismerem :)

Ha a "default" beépülőket választod:

1. Flash/AS - itt van egy limitje az adatméretnek
2. Esetleg megpróbálhatod az adatokat JSben tárolni és AS-el feldolgozni, itt ugye nehéz lesz a perzisztenciát megoldani, de az AS-hez van szép json library
5

Flash/AS

s_volenszki · 2008. Dec. 11. (Cs), 09.13
Szia!

Ez már ez én fejemben is megfordult. Első körben a beavatkozások nélküli beépülő modulokban gondolkodom, nem utolsó szempont a platform és böngésző függetlenés reális kereteken belül.

Milyen adatmérettel kell kalulálni Flash/AS esetében?

Kifejtem az alkalmazát egy kicsit bővebben:

Gyorskeresés táblázat adott oszlopára és találati sorhoz pozícionálás kliens oldalon.

Az betöltődésekor php mysql-ből lekérdez nagyjából 3000 rekordot (a jövőben leht akár ennek a duplája is). Ebből csinál egy html táblázatot egy divben, aminek fix magassága van és scrollozható. A táblázat egy sora nagyjából 4-5 cellából áll, cellánként kb. 20 karakter, tehát soronként 80-100.

A táblázat létrehozása mellett az adatokat átalakítom egy struktúra szerint és letárolom egy rejtett textarea-ban. A struktúra úgy alakul, hogy egy egység, a táblázat sora, egy sorszámlálóval ellátva.

Mikor user a táblázat fejlécében található szövemezőbe el kezd írni (onkeyup+setTimeout), egy js funkció elkezdi keresni a rejtett szövegmezőben az egyezőséget. Ha talál, értelem szerűen tudja a táblázat sorának számát és oda scrollozza a divet (állandó sormagasság = 20px; 568. sor = 568x20px)

Jelenleg kb. 1000 - 1500 sorig tökéletes a felhasználói élmény, az felett már sok minden befolyásolja. Nekem C2D Quadom van 4GB RAM-mal, nálam még a 2000 sor is jól működik, másik gépen már erősen homokórázik a böngésző.

Szóval ezt akarom optimalizálni...

És az ok amiért kliensen kell megoldanom: Nincs ideje operátornak megvárni, míg visszaérkezik a válasz a szerverről!

Elképzelhető, hogy legyen egy oyan flash alkalmazás az oldalban, ami gondoskodik az adatok tárolásáról, és a kereső sztring bevitelére visszaad egy sorszámot vagy flase-t?
6

DB Tuning

zila · 2008. Dec. 11. (Cs), 10.30
Hát én ezt nem tenném be kliensoldalra. Egy idő után biztosan hibához fog vezetni, ha a találati listád kinövi helyi tároló méretet (kivéve persze a helyi sqlite tárolást).

Inkább a db lekérdezést hangolnám úgy, hogy mindig baromi gyors legyen. Ha befér szerveroldalon memóriába akkor a találati listát tenném egy memóriában tartott táblába a kliensoldal ebben keresne, ez elég gyors tud lenni.

Az operátori kereséseket elemezném folyamatosan, így egy idő után kiderül, melyek a leggyakoribb keresések. Ha ez megvan akkor a leggyakoribb keresések listáját letolnám kliensbe azonnal a maradékot meg az optimalizált táblába raknám a db szerveren. Ezután már csak aktualizálni kell a leggyakoribb keresések listát, hogy ne romoljon a performancia :)

Arról nem is beszélve, hogy ha több operátor kapná ugyanazt a full találati listát azonos vagy rövid időn belül akkor a db nem futtatja le még egyszer a lekérdezés elemézést, execution plan készítését, hanem a már kész "lefordított" queryt felhasználja, akár a találati listát is megleli az ilyen-olyan cache-ben. (legalábbis oracle tud ilyeneket, mysql-t nem ismerem ilyen szempontból)
8

Igen, elfogadható a felvetésed.

s_volenszki · 2008. Dec. 11. (Cs), 12.06
A táblázat egy meghatározott oszlopra rendezve van ABC sorrendben. Az operátor beír három karakter, mire a rutin megkeresi az első sort, ahol egyezőség van és oda pozícionál.

Ebben a pillanatban az operátor a keletkezett listát látva döntést hoz, hogyan folytatja a karaktersorozatot.

Ezért az első három karakter az egy illeszkedési minta és oda pozícionálja a táblázatot ahol a minta illeszkedés kezdődik. Eredetileg a szövegmezőn volt egy setTimeout és ha abbahagyta a gépelést 1 másodpercre, akkor indult egy AJAX kérés (SELECT * FROM akarhonnan WHERE akarmi LIKE 'abc%') és az eredmény táblázatban visszatért a divbe.

Ha folytatta a gépelést, ugyan ez történt viszont ekkor már a kliensen tárolt adatokból dolgozik a kereső. Fontos, hogy az első három karakterrel megegyező összes rekord listázott maradjon, mert ha backspacel a szövegmezőben, akkor visszafelé tekeri a rutin a listát.

Biztos igazad van, én is gondoltam már hasonlókra, mint legtöbbet használt rekordok menjenek kliensre és csak akkor dolgoztassa a szevert, ha nincs kliensen a keresett adat, a baj az, hogy az első három karakterre illesztett rekordok száma 1500-3000.
7

Duplikálod az adatokat

zila · 2008. Dec. 11. (Cs), 10.46
Még annyit tennék hozzá, hogy a fent vázolt módszereddel ügyesen megduplázod az adatmennyiséget, mert egyszer berakod egy div-be html táblázatként, aztán elpakolod egy rejtett szövegmezőbe is, kereséskor esetleg még változóba is töltöd a rejtett szövegmezőből a cuccot js-sel - ez csak tipp, de ha így van akkor ezen a ponton már 3x tárolod ugyanazt... Ha mindenáron kell a teljes lista az operátornak amiben tud böngészni és szűrni is, akkor megpróbálhatod csak a html táblázatot letolni a kliensnek és js-sel keresgélnék a táblázatban, így csak egy példányban tárolod a cuccot.
9

Igen.

s_volenszki · 2008. Dec. 11. (Cs), 12.10
Valóban. Bár nem azonos struktúrában és nem azonos mennyiségben, de igen.

Konkrétan a html tábla áll sorszámból és még öt mezőből, az anyag amiben a sorok számát kerestetem, az pedig sorszámból és a táblázat első oszlopainak adataiból, tehát jelentős részét duplikálom.

A táblázatban keresgélés alatt egy amolyan "keressünk a DOM-ban" dologra gondolsz?
10

DOM

zila · 2008. Dec. 11. (Cs), 17.46
A táblázatban keresgélés alatt egy amolyan "keressünk a DOM-ban" dologra gondolsz?


Igen arra gondolok. De van egy ilyen kis jópofaság is: TrimQuery
11

Nagyon jó!

s_volenszki · 2008. Dec. 11. (Cs), 18.42
Beleszerettem!

A hétvégén bevizsgálom, milyen adatmennyiséggel bír el!

Hálás köszönet!

s_volenszki
12

Warning

yaanno · 2008. Dec. 12. (P), 20.58
Trimquery: tényleg csak szvsz, de az sql nem erre való, pláne nem javascripttel :)

Html generálás / duplikálás: lehet, hogy tévedek, de el tudom képzelni, hogy az első letöltődést nagyban segítheti, ha htmlt is küldesz, majd query-re vagy időzítve stb. küldöd a jsont. Ez sokkal reszponzívabbá teszi az alkalmazást, mint ha a json letöltésre, plusz még a dom építésre is várni kell és csak utána jelenik meg a tartalom. Egyik lehetőség, amit szoktak csinálni, hogy csak fragmenteket küldesz, vagyis pl. egy táblázat scrollozásakor az éppen "látható" adatokat küldöd, a többit nem.

Mellékszál: sqlt optimizálni mindig érdemes, ez nem helyettesíti a reszponzivitást :)

Mellékszál2: majd meggyőzöm toxint, hogy írjon már valamit ebben a témában, mert ő ennek nagy mestere lett meló közben :)
13

Mellékszál2 +1

Ustak · 2008. Dec. 13. (Szo), 15.58
Én is egy ilyen projektben vacilláltam az egyszerre sok vagy az apránként kevés átjövő és beépülő adat között, és bár működik, elég ismeretlen a téma... Szóval győzködni szeretném toxint :-)