SQLITE kérdés

[archee]

A következö query-k baromi lassúak, tehát valószínü nem hasznának indexet:”SELECT id,hashname,wintime,time,difficulty FROM replays WHERE vehi=? AND level=? ORDER BY time DESC””DELETE FROM replays WHERE level=? AND vehi=? AND time<!–?”A táblát így csinálom:    hsdb.query(“CREATE TABLE IF NOT EXISTS replays (hashname INT NOT NULL, time INT NOT NULL, wintime INT NOT NULL, data BLOB NOT NULL, level INT NOT NULL, vehi INT NOT NULL, watched INT NOT NULL, id INT NOT NULL, version INT NOT NULL, difficulty INT NOT NULL, PRIMARY KEY (id))”);    hsdb.query(“CREATE INDEX IF NOT EXISTS ind0 ON replays (vehi , level, time)”);    hsdb.query(“CREATE INDEX IF NOT EXISTS ind3 ON replays (vehi , level)”);    hsdb.query(“CREATE INDEX IF NOT EXISTS ind1 ON replays (hashname)”);    hsdb.query(“CREATE INDEX IF NOT EXISTS ind2 ON replays (id)”);Mire pár 100 sort kiad a a SELECT, eltelik kb 1 másodperc, a vinyó pedig seekel.Mit csinálok rosszul? A doksija szerint meg kéne találnija önként az indexeket. Vagy talán indexxel is lehet ilyen lassú valami?

[YADA]

Lehet lazan. Foleg ha eleg nagy az adatbazis.
De en minimum a time mezot kulon (is) indexelnem onalloan. Talan a masik kettot is. Mindenesetre kiserletezni mindig erdemes, meglepo tud lenni az eredmeny, minden db motor maskepp mukodik, mast elemez, mast optimalizal.

Esetleg erdemes kiprobalni valami NOSQL alapu megoldast. Manapsag a Mongodb eleg nepszeru, egyszeru es rohadtul gyors amig eleg memoria all rendelkezesere. Ha elfogy a ram akkor is kozelit a leggyorsabb SQL implementaciok sebessegehez, de meg picit (nehany szazalek) akkor is gyorsabb egyes tesztek szerint.

[archee]

Az adatbázis 1giga, és 384MB van a szervernek összesen, amire nem is akarok költeni. A time mezö külön indexelése szerintem nem jó semmire. Most azt találtam ki, hogy külön tábllát csinálok, amiben a blob és az id van, hiszen csak nagyon ritkán van szükség a blobra. A fent említett query nem kéri le a blobot. Mindössze 30MB a blobok nélkül, és az be cachelödhetne, így gyorsan tudnám a listát generálni. Remélhetöle egy lapon belül csak egy tábla fordulna elö. Ha esetleg összefragmentálná a két táblát úgy, hogy közös lapok lennének, akkor külön adatbázisba (külön fileba) rakatom öket.

[Travis]

Lehet, hogy az a baj, hogy több indexet használsz. Az SQL megpróbálja megbecsülni, hogy melyik index adja a leggyorsabb eredményt, csakhogy ez is időbe kerül. Próbáld ki az ANALYZE parancsot, abból kapsz valami statisztika szerűséget, annak segítségével kitalálhatod, melyik index a legjobb, a többit meg töröld.

Ha pedig másik lekérdezésekhez kellenek ezek az indexek, akkor a + segítségével kikapcsolhatod az indexhasználatot egy mezőre.

[archee]

A probléma megoldódott azzal, hogy a táblából két táblát csináltam, ahogy fentebb írtam. De nem lehet valahogy megmondani ezeknek, hogy egy column-ot külön táblaként kezeljen, mert ritkán kell?

[Travis]

A View hasonló. Egy összetett lekérdezést tudsz egy virtuális táblaként kezelni.

[YADA]

Ketlem hogy az sqlite van olyan inteligens hogy a view definiciokat kulon optimalizalja. Nekem eddig nem az jott le vele kapcsolatban hogy agyon lenne optimalizalva. Egyszeru mint a faek, es egyszeru feladatoknal gyors.

Viszont az az 1GB adatbazis mennyi ido alatt jott letre es mi varhato a jovoben? Mert sqlite alatt nem egyszer volt mar szerencsem elerni a 2GB alomhatart, ami igencsak kellemetlen kovetkezmenyekkel jart. Ha belathato idon belul megtortenik, akkor meg most ideje lenne elgondolkodni barmi mas megoldason. (android alatt is lazan sikerult tullepnem a hatart) 2GB eleresekor filepointer tulcsordulas tortenik, ami laza adat felulirashoz vezet, kellemes adatvesztest okozva. Ez proci es oprendszertol fuggetlen jelenseg (64bit cpu, ext2-3-4/ntfs alatt is megtortenik).

[archee]

Milyen sqlite verzióval történt az ígyjárás? sqlite3? Mindenhol azt olvasom, hogy 50GB vel is jól müködik.

Az adatbázisom 1 év alatt nött 1GB re, és a 2GB még biztos elérhetö lesz. Mindenki replay-je visszanézhetö. Az iPhonos verzióé gyorsabban nö, mert egyszerübben csináltam meg a a replay tárolást, és orsszabb tömörítöt használtam. (Mert ARM GCC vel fagytak a jók). Ha tényleg van ilyen para, akkor lehet, átállok a mongoDB re. Ehhez pedig 64 bites linuxot kell installálnom, és a kódot 64bit compatibilisre kell átvarázsolni.

[YADA]

Ha doksi azt mondja hogy ujabb verziok kezelik a 2G+ meretet, akkor jo. De menj biztosra, teszteld. Engem annyira nem izgatott a dolog, plane a verziofuggese, amugy sem voltam oda sqlite-ert (csak teszteltem egy hordozhato kodot, korabbi filesystem szegmentalodast es lassulast probaltam vele megkerulni), inkabb modszert valtottam.

[Author]

Posts