MySQL, Data Dictionary - avagy csinaljunk szotar alapu keresest 4.0 ala:D

Adatbázis: SQL, XML DB

Re,

adott egy mysql4.0 (nem, nem lehet frissiteni 5.0-ra), ezen kene egy dictionary lookup-ot csinalnom. WHERE xy LIKE '%abc%' nem jo, eszetlenul lassu. Van vagy X szazezer sor*5 tabla amit joinolni kell, s azokban kell keresni, mert hat a normalforma...
FULLTEXT kiesik, mert reszszavakra nem tud keresni, pl a 'cé' nem talalja meg az 'acél'-t.Namost akkor egyetlen mukodo megoldas (hogy kesobb is birja a terhelest, par heten belul megugrik a terheles es a rekordok is 10*-ni fognak, hala az elorejelzeseknek az illetekestol):

Csinaljak szotar alapu keresest.
Tehat minden letezo szot felbontok 2-3-4-...-n (n = strlen($szo)) elemu substringre, osszes variacioban permutacioban, devianciaban, absztinenciaban es elrakom, hogy melyik ID-kon talalhato meg. Majd a kereseskor a keresett stringet egyszeru WHERE expr = '$q' megoldassal lekerem, JOIN, orom. (Tudom, lesz vagy 6milliard sorom...) Frissitese adatbazis frissiteskor inkrementalisan, de az mar a konnyebb resze.

Kerdesek:
Csinalt mar valaki hasonlot?
Tippek?
Trukkok?
Javasolt prognyelv? nemtom PHP emberi idoben letolja-e vagy C-ben irjak hozza kis szosszenetet?

Koszi!

  • 1870 megtekintés

( andrej_ v | 2006. 03. 19., v – 02:11 )

Ufff. Ezek a keresések nagy adatbázis és forgalom esetén sajátgépre fognak kívánkozni. Sőt, igazából külön adatbázisszerver, ha akkor a mennyiség, mert a context switchekbe fog elhalni az egész.

A PHP jónak tűnik erre, de érdemes az _egész_ találot HTML-ben vagy legalább valami template-ben eltárolni, persze adott lifetime-al.

Valamiféle relevancia vizsgálat is kell és limitálni az első 100-200 találatra a dolgokat, mert valószínű, hogy abban meglesz. Ha mégsem, akkor a következő 200-ban nyomulni. Igen innentől lesz baromira komplex az egész. :)

Az index használatnál olvass utána a dolgoknak. http://dev.mysql.com/doc/refman/4.1/en/mysql-indexes.html

The index also can be used for LIKE comparisons if the argument to LIKE is a constant string that does not start with a wildcard character. For example, the following SELECT statements use indexes:

SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%';

Viszont szerintem ezt is nézd meg: http://dev.mysql.com/doc/refman/4.1/en/fulltext-search.html
A mysql-es fiúk azért dolgoztak a kérdésen, mert úgy látom ez eléggé használható lenne itt. Ez visszaadja a relevancia számot is.

( edaile | 2006. 03. 19., v – 09:42 )

A programozási nyelv teljesen mindegy, úgyis az adatbázis szervered lekérdezési sebessége fogja megszabni a futás idejét...
A szótár alapú keresést nem javaslom leprogramozni, mert a rekordok méretével exponenciálisan fog nőni az adatbázis mérete.

Újra kell tervezni a programot, ha használhatót akarsz.

Ami elől menekülnek, az után szaladnak.

( handler | 2006. 03. 19., v – 09:48 )

Tesztelni, tesztelni, tesztelni. Foleg valos adatmennyisegen. Keresd meg hol vannak a hatarok - egyebkent kiados vakarozas kovetkezik.

hehe, ezt csinalom 2 es 6 kozott:D amikor a legkisebb a terheles, ilyenkor nem feltuno.
a disznonagy tablaval tisztaban vagyok, de amig a rendszergizda meg 4.1-re sem hajlando frissiteni, mert lassabb mint a 4.0 addig meg egy nyomorek subquery-t sem tudok csinalni nemhogy batch-ben raereszteni a lekerdezeseket, hogy legalabb a halozati utazgatas * 22000 megsporolodjon...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( bocs | 2006. 03. 19., v – 12:47 )

én is pont ilyet csináltam, és az jött ki belőle, hogy elég jól működik az algoritmus.

egy idő után ugyanis a szókészlet majdnemhogy beáll stabilan, és a szótár nem növekszik, csak az előfordulási tábla.

Arra meg dátumbélyeget találtam ki, vagyis hogy a leindexelt szöveges cikknek is van utolsó módosítása, meg az újraindexelésre is van egy globális utolsó dátum, és csak a változásokat frissíti.
így egészen emberbaráti php/mysql sebességet adott