Sziasztok!
Tud-e' esetleg valaki jo modszereket arra, hogy mysql-ben (konkretan 5.0.27, gya'ri, fc4-re) hogyan lehet tablakat es indexeket hatekonyan tomoriteni? A tablakat feltolte's utan tisztan read-only modon hasznalnam, viszont fontos lenne a kis me'ret e's a gyorsasa'g is. Adott tehat egy tabla, benne ~1.8 millio rekord. Ezeknek ke't indexe van:
* egy sima id (primary key + auto increment, 1 es 1.8 millio kozott), valamint
* egy geometry::point osztalyon levo r-tree, ez egy sima mezei spatial index (utolag van letrehozva, feltolte's uta'n, `create index ...`-szel)
Egy rekord az 1 int + 1 point + 14*float, igy egy tabla ~170mega lesz. Az index pedig ~130mega, ebbol ~10mega az id indexe, a maradek az a spatial index. Erre a kovetkezotket probaltam ki:
* myisamchk tabla # hogy minden rendben van-e'
* myisampack tabla # tomorit: a 170mega's *.MYD-bol csinal 136 mega'sat, de az index megszunik letezni (a MYI file 130 mega'sbol ossszeesik kb. 1k-sra)
* myisamchk -rq tabla # aszondja a myisampack, hogy csinaljam ezt, megcsinalom, es visszakerul az index, ugyanugy 130mega's erdekes, hogy amig a create index kb. 4 percig futott, ez kb. 1 perc alatt lefut
* myisamchk tabla # csak a biztonstag kedveert, aszondja hogy fasza.
Kerdes, hogy ennel van-e valami effektivebb modszer, pl a myiamchk --sort-index es/vagy --sort-records jutott eszembe, de ez nekem valahogy nagyon nem akartak mukodni (rtfm alapjan kreten hibauzenetek jonnek, amit utana kismillio myisamchk-val lehet csak visszapofozni). Foleg az index tomorites lenne jo... osszesen ui. ~900 ilyen ta'bla't kellene ta'rolni...
A.
- 2150 megtekintés
Hozzászólások
Valaki?
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy offtopic-szerű a hozzászolásom, de erre a recordmennyiségre én már egy PostgreSQL-t javasolnék.
Amúgy
http://www.databasejournal.com/features/mysql/article.php/1382791
ez a cikk talán segít valamennyit.
- A hozzászóláshoz be kell jelentkezni
A sebesseggel nincs baj, baromi gyors (a szelekcio az a spatial index szerint megy az elsodleges szelekcio, azaz ke'rde's, hogy mely pontok esnek egy adott te'glalapba).
A pgsql-rol azt hallottam, hogy ez a spatial extension nevu dolog kicsit fe'lva'llro'l van benne implementalva, hianyosan es lassan. Persze lehet hogy ez nem igaz, de hogy egy db tud ilyesmit is optimalisan kezelni, hogy r-tree, kd-tree, altalaban geometriak az talan nem trivialis.
De persze ki tudja, ha a mostani szelekcio 0.01 sec helyett 0.05 sec lenne PG-ben, ellenben a tablak/indexek me'rete feleekkora lenne, az ma'r boven mege'rne', hogy azt hasznaljuk.
Ha erre (spatial extensions) van valami jo referencia'd, osszehasonlitasod (pg vs. my) azt megkoszonne'm ;)
A.
- A hozzászóláshoz be kell jelentkezni
ha ilyen speciális igényed van, és főleg ha csak read-only üzemmód kell, akkor lehet, hogy a flat-file adatbázis lenne a jó ötlet
vagyis spéci adattárolási formát kitalálni csak erre az 1 feladatra, és pure binary file-ba tenni az adatokat, amit egy c++ program beolvas és elvégzi a lekérdezést
nota bene ha a felhasználás módja olyan, akkor lehet szó akár arról is hogy az indexet nem tárolni, hanem on-the-fly a memóriában legenerálni
- A hozzászóláshoz be kell jelentkezni
vagyis spéci adattárolási formát kitalálni csak erre az 1 feladatra, és pure binary file-ba tenni az adatokat, amit egy c++ program beolvas és elvégzi a lekérdezést
igen, ilyet ma'r kellett csinalunk, csak akkor nem 1.8 millio, hanem ~500 millio rekord volt a tablaban (abba tenyleg beletort a MySQL bicskaja: 2 he'tig indexelt egy dual opteronon 8 giga rammal, majd utana 1 ora volt egy mezei range query)... csak elegge fapados lett, szoval ilyenek hogy php-wrapper, szoval azt a'lmunkban sem. Raadasul a MySQL erre a feladatra tenyleg baromi jo lenne, mert nagyon gyors, raadasul 1-2 esetben talan specialisabb query-k is lesznek (amit a sajat readonly verzioban nem implementalunk), join-ola's, stb, hogy azt ne php-bol kelljen kezzel csinalni (bar kb. ke't 50-100-200 soros result-ot kell varhatoan join-olni, de akkor is).
nota bene ha a felhasználás módja olyan, akkor lehet szó akár arról is hogy az indexet nem tárolni, hanem on-the-fly a memóriában legenerálni
ez sajnos meg lassu, ~4 perc. A 0.01 masodperces query-nek is megvan az a'ra ilymodon ;) meg persze a ta'rhely...:/
Szoval inkabb a kerdes, hogy lehet-e indexet tomoriteni es/vagy ez a --sort-index, --sort-records miert nem mukodik...
A.
- A hozzászóláshoz be kell jelentkezni