Ytelse med store LIKE sammenlikninger i MySQL

[Blodhemn]

Alle respekterte nettsteder må ha en søkefunskjon. Å lage en enkel en som søker gjennom database oppføringer med LIKE er ikke akkurat det vanskeligste.

 

Men LIKE er litt begrensende, jeg vil gjerne at det skal gå ann å søke på flere ord i samme søk.

 

Løsningen min er å dele opp søke-strengen med explode. Arrayet jeg får fra explode rydder jeg opp i slik at jeg fjerner ord kortere en 3 tegn.

 

Jeg bruker to foreach til å konstruere SQL-spørringen, en foreach for hvilke felter som skal søkes i og en for hvilke ord som skal søkes etter.

 

Problemet er da at dette kan bli en veldig stygg spørring til slutt.

 

Under er en liten smakebit på en spørring som ble laget ved å søke i 3 felter; nyhet, ingress og overskrift.

 

Søkestrengen er : "interdum web server gruppa dette"

 

 

SELECT * FROM nyheter WHERE nyhet LIKE '%interdum%' OR ingress LIKE '%interdum%' OR overskrift LIKE '%interdum%' OR nyhet LIKE '%web%' OR ingress LIKE '%web%' OR overskrift LIKE '%web%' OR nyhet LIKE '%server%' OR ingress LIKE '%server%' OR overskrift LIKE '%server%' OR nyhet LIKE '%gruppa%' OR ingress LIKE '%gruppa%' OR overskrift LIKE '%gruppa%' OR nyhet LIKE '%dette%' OR ingress LIKE '%dette%' OR overskrift LIKE '%dette%'

 

Det er jo åpenbart at jeg må programmere inn restriksjoner på antall ord i søkestrengen, men det jeg egentlig lurer på er hvor mange rader i tabellen kan det være og hvor stygg kan select-spørringen være før databasen kneler?

 

Og kanskje et enda bedre spørsmål: finnes det noen bedre måter å lage søkefunskjon på?

[Beisfjord]

Når det gjelder tidspunktet for når databasen kneler så kommer det ann på veldig mange faktorer. Spørringen behøver ikke å ha noen ting å si for nettopp nette. Faktorer som spiller inn er sånt som antall samtidige brukerer, ram, ledig disk plass, cpu kraft, hvilke database som brukes, hva som er index'ert, osv.. Som du ser, ganske umulig å svare på om man ikke kjenner databasespesifikasjonene og hvor stor belastning det er på denne.

 

Et tips er jo å droppe første % i hver LIKE, Altså ikke "%etEllerAnnet%", men "etEllerAnnet%". Problemet med å ha % først er at da må man uansett søke gjennom hele tabellen, mens med % kun på slutten så kan man bruke index'er til å søke seg fram til de som måtte begynne på "etElerAnnet" og dermed forbedre ytelsen betraktelig. Går selvsagt litt på bekostning av søkeresultatet, men det er jo noe man må vurdere om man tåler.

 

Edit: Vil også anbefale deg å ta enn titt på full tekst søk i MySQL.

Endret 11. juli 2004 av Psi_^

[Blodhemn]

Jeg kan fortelle deg at min athlon 1800 xp med 512ram ikke har noen problemer med den spørringen. Og nettsiden vil neppe se mer enn 4-6 online brukere samtidig. Så jeg tror det skal gå fint. Den vil heller ikke se mer enn 500 rader maksimalt.

 

Når det gjelder indexering så har jeg forstått det slik at om man indexerer for mange felter så vil den ekstra ytelsen dette medfører falle bort. Og jeg vil faktisk måtte indexere nesten alle feltene i en vanlig tabell med denne søkemotoren. Er ikke helt klar på indexering.

 

Lagde en enkel søkemotor med fulltext search. Fordelen her er jo at man kan rangere resultater etter de med mest relevans. Men må si jeg ble litt bekymret når jeg leste comments i mysql manualen.

[Ueland]

hvorfor ikke bare bruke "WHERE tekst LIKE '%ord1%ord2%ord3%'" ?

blir fort litt lettere

[Blodhemn]

Lol.. uffda

 

Ikke vits å finne opp hjulet på nytt, nei..

 

Men den virker ikke like bra. Ikke i det hele tatt for å være helt ærlig

Endret 11. juli 2004 av Blodhemn

[Rescudo]

hvorfor ikke bare bruke "WHERE tekst LIKE '%ord1%ord2%ord3%'" ?

blir fort litt lettere

Den betinger jo at innlegget inneholder både ord1, ord2 og ord3, mens den første spørringen gjør at nyheten ikke trenger å inneholde mer enn et av ordene. Enda en ting - den der gjør jo at søkeordene må komme i samme rekkefølge!!

[Beisfjord]

Jeg kan fortelle deg at min athlon 1800 xp med 512ram ikke har noen problemer med den spørringen. Og nettsiden vil neppe se mer enn 4-6 online brukere samtidig. Så jeg tror det skal gå fint. Den vil heller ikke se mer enn 500 rader maksimalt.

 

Når det gjelder indexering så har jeg forstått det slik at om man indexerer for mange felter så vil den ekstra ytelsen dette medfører falle bort. Og jeg vil faktisk måtte indexere nesten alle feltene i en vanlig tabell med denne søkemotoren. Er ikke helt klar på indexering.

 

Lagde en enkel søkemotor med fulltext search. Fordelen her er jo at man kan rangere resultater etter de med mest relevans. Men må si jeg ble litt bekymret når jeg leste comments i mysql manualen.

Med den mengden data, brukere og maskinvare er det absolutt ikke noe problem uansett hvor grisete spørringer du måtte få lyst til å lage. Med det antall rader kan du også droppe index'er da du bør kunne holde hele databasen i minnet og å søke 500rader tar stort sett svært få disk oppslag for å hente inn i minnet.

 

Når databasen blir så stor at du ikke klarer å holde alle tabellene i minnet på en gang så blir index'er nødvendig. Uten indexer så må man søke gjennom hele tabellene uansett hvordan spørring man kjører. Dette innebærer at man må laste hele tabellen inn i minnet, og hvis tabellen inneholder flere millioner rader så kan det fort ta timevis å kjøre spørringer uten indexer. Med noen velplasserte indexer kan dette reduseres til sekunder

[Blodhemn]

hvorfor ikke bare bruke "WHERE tekst LIKE '%ord1%ord2%ord3%'" ?

blir fort litt lettere

Den betinger jo at innlegget inneholder både ord1, ord2 og ord3, mens den første spørringen gjør at nyheten ikke trenger å inneholde mer enn et av ordene. Enda en ting - den der gjør jo at søkeordene må komme i samme rekkefølge!!

Og da kan man like godt bare søke LIKE %ord1 ord2 ord3%

[Blodhemn]

Jeg kan fortelle deg at min athlon 1800 xp med 512ram ikke har noen problemer med den spørringen. Og nettsiden vil neppe se mer enn 4-6 online brukere samtidig. Så jeg tror det skal gå fint. Den vil heller ikke se mer enn 500 rader maksimalt.

 

Når det gjelder indexering så har jeg forstått det slik at om man indexerer for mange felter så vil den ekstra ytelsen dette medfører falle bort. Og jeg vil faktisk måtte indexere nesten alle feltene i en vanlig tabell med denne søkemotoren.  Er ikke helt klar på indexering.

 

Lagde en enkel søkemotor med fulltext search. Fordelen her er jo at man kan rangere resultater etter de med mest relevans. Men må si jeg ble litt bekymret når jeg leste comments i mysql manualen.

Med den mengden data, brukere og maskinvare er det absolutt ikke noe problem uansett hvor grisete spørringer du måtte få lyst til å lage. Med det antall rader kan du også droppe index'er da du bør kunne holde hele databasen i minnet og å søke 500rader tar stort sett svært få disk oppslag for å hente inn i minnet.

 

Når databasen blir så stor at du ikke klarer å holde alle tabellene i minnet på en gang så blir index'er nødvendig. Uten indexer så må man søke gjennom hele tabellene uansett hvordan spørring man kjører. Dette innebærer at man må laste hele tabellen inn i minnet, og hvis tabellen inneholder flere millioner rader så kan det fort ta timevis å kjøre spørringer uten indexer. Med noen velplasserte indexer kan dette reduseres til sekunder

Takk for den oppklaringen på indexer.

 

Dette er jo ikke noe stort prosjekt og den endelige nettsiden vil ligge på maskinvare som er enda sterkere enn min testserver.

 

Er ganske fornøyd med den nåværende løsningen som er MATCH basert på fulltext search.

 

Takk for hjelpen