[MySQL] FULLTEXT index update niet

[Nexz]

Hallo medetweakers!

Graag zou ik jullie hulp willen bij het volgende:

Ik heb de volgende tabel in MySQL staan:

ID	Titel	Inhoud
1	Testpost	Hiephoi test abc 1234567
2	Hallo	Wereld Blablabalbalblaba

ID: INT, auto_increment, Prikey
Titel: TEXT, FULLTEXT INDEX titel
Inhoud: TEXT, FULLTEXT INDEX inhoud

Hier voer ik de volgende query op uit:

SQL:

SELECT * FROM testtabel
WHERE (
    MATCH (
        inhoud
    )
    AGAINST (
        "test*"
    )
    OR MATCH (
        titel
    )
    AGAINST (
        "test*"
    )
)

Nu insert ik nieuwe posts in mijn tabel (via phpMyAdmin) en het lijkt wel alsof mijn index niet update! Ik heb toevallig wel mijn tabel geleegd, zou dit er iets mee te maken kunnen hebben?

Wat ik al geprobeerd heb:

• Indices weggooien en opnieuw aanmaken
• Indices andere namen geven
• In mijn SQL query MATCH(inhoud) AGAINST('Test') i.p.v. MATCH(inhoud) AGAINST ('Test*') gebruiken. (De wildcard weghalen).

Ik zit echt gigantisch vast, zie ik iets over het hoofd?!

Alvast bedankt!

[Gonadan]

Waaruit blijkt het dan dat hij niet geupdate wordt?

[Nexz]

Ik kijk naar de kardinaliteit ( blijft op 0 staan, Primary gaat wel omhoog) en ik krijg geen results.
Vergeten bij te vermelden, dit is niet de "echte" tabel, deze is wat simpeler i.v.m. mijn werkgever die zijn tabellen niet graag op "straat" ziet liggen .

Misschien ook nog handig om neer te zetten:
Apache/2.2.3 (Debian) PHP/5.2.0-8+etch15 mod_perl/2.0.2 Perl/v5.8.8
MySQL-client versie: 5.0.32
Serverversie: 5.0.32-Debian_7etch8-log

[ Voor 70% gewijzigd door Nexz op 08-06-2009 15:33 ]

[Gonadan]

Wat is de minimumlengte van de zoekopdracht? Kan je instellen namelijk.
Ook kan je Match met kommagescheiden de kolommen opgeven.

En de stopwords?s

[ Voor 7% gewijzigd door Gonadan op 08-06-2009 15:35 ]

[Nexz]

Bedankt voor de tip voor match , in ieder geval, minimum heb ik afaik niet ingesteld (leeg gelaten). Ik weet ook niet wat de standaard waarde hiervoor is?

[Gonadan]

http://dev.mysql.com/doc/...fulltext-fine-tuning.html

4 meestal, maar dat hangt uiteindelijk af van de belasting die de beheerder verwacht en wat het systeem aan kan.

[ Voor 47% gewijzigd door Gonadan op 08-06-2009 15:38 ]

[Nexz]

Door even door de pagina heen te lezen die je gestuurd heb, heb ik een REPAIR TABLE gedaan. Dit heeft gewerkt! Komt dit soms door het legen van de tabel?

[Voutloos]

Nexz schreef op maandag 08 juni 2009 @ 15:31:
Ik kijk naar de kardinaliteit ( blijft op 0 staan, Primary gaat wel omhoog) en ik krijg geen results.

Naar cardinaliteit kijken zegt niets, is weinig betrouwbaar getal.

De manier om te debuggen: Ze de primary key in de where clause en selecter de match...against uitkomst.

Nexz schreef op maandag 08 juni 2009 @ 15:41:
Door even door de pagina heen te lezen die je gestuurd heb, heb ik een REPAIR TABLE gedaan. Dit heeft gewerkt! Komt dit soms door het legen van de tabel?

Niet per se, maar bij MyISAM kan het gebeuren.

[ Voor 29% gewijzigd door Voutloos op 08-06-2009 15:41 ]

[Johnny]

Moet een tabel ook niet (standaard in MySQL) minimaal 3 rijen hebben voordat je er met FULLTEXT in kan zoeken?

[Nexz]

Het is erg belangrijk dat data in deze tabel goed bewaard blijft! Ik heb wel wat over verschillen over storage engines gelezen, maar heb er nooit voldoende aandacht aan geschonken (kennelijk ). Even kieken wat de betrouwbaarste SE is

@Johnny:
Er staan er nu 2 in en hij werkt perfect .

[ Voor 10% gewijzigd door Nexz op 08-06-2009 15:44 ]

[Gonadan]

Nexz schreef op maandag 08 juni 2009 @ 15:44:
Het is erg belangrijk dat data in deze tabel goed bewaard blijft! Ik heb wel wat over verschillen over storage engines gelezen, maar heb er nooit voldoende aandacht aan geschonken (kennelijk ). Even kieken wat de betrouwbaarste SE is

@Johnny:
Er staan er nu 2 in en hij werkt perfect .

Als je per sé FULLTEXT wilt gebruiken moet je wel met MyISAM aan de gang helaas.

[Nexz]

Hm. Jammer. Dan maar hopen dat er niks fout gaat . (En daily backups )

[cariolive23]

Waarom 2 aparte indexen wanneer je ook 1 gezamelijke index kunt aanmaken? Dat is sneller voor de database. Ik heb wel eens situaties gezien waarbij ook meerdere losse indexen aanwezig waren maar waarbij MySQL besloot om bij het zoeken maar geen index te gebruiken. Een simpele query kon vele minuten duren, EXPLAIN maakte duidelijk dat indexen niet werden gebruikt. Het aanmaken van een gecombineerde index loste het probleem op, queries waren bijna een factor 500 sneller.

Betrouwbaarheid in MySQL gaan niet goed samen, met MyISAM is die combinatie al helemaal niet te maken. Het feit dat MySQL over de functie REPAIR beschikt, zegt genoeg.... Heb veel te vaak te maken gehad met omvallende MySQL-databases, gek werd ik van. Het schijnt dat innoDB er geen/minder last van heeft, maar die heeft weer geen full text search. Kijk eens naar Sphinx of Lucene, kun je veel meer mee dan met de FTS van MySQL.

[Nexz]

Sphinx heb ik toevallig net nog wat over gelezen! Ik ga er zeker eens naar kijken. Daarnaast heb ik nog wat andere berekeningen naast de twee indices staan (afhankelijk van hun aparte relevantie scores)... Daarom wil ik ze graag apart houden .

[ Voor 24% gewijzigd door Nexz op 08-06-2009 15:55 ]

[Gonadan]

cariolive23 schreef op maandag 08 juni 2009 @ 15:51:
Waarom 2 aparte indexen wanneer je ook 1 gezamelijke index kunt aanmaken? Dat is sneller voor de database. Ik heb wel eens situaties gezien waarbij ook meerdere losse indexen aanwezig waren maar waarbij MySQL besloot om bij het zoeken maar geen index te gebruiken. Een simpele query kon vele minuten duren, EXPLAIN maakte duidelijk dat indexen niet werden gebruikt. Het aanmaken van een gecombineerde index loste het probleem op, queries waren bijna een factor 500 sneller.

Indices moet je over nadenken, niet zomaar aanmaken om dat het dan misschien beter zal werken.
Ze zijn normaal gesproken gewoon te beredeneren.
Een gecombineerde index heeft alleen zin als je die kolommen ook altijd gecombineerd in de clausules gebruikt, mocht je namelijk een keer de tweede kolom willen aanspreken dan werkt de gecombineerde index niet meer.

Betrouwbaarheid in MySQL gaan niet goed samen, met MyISAM is die combinatie al helemaal niet te maken. Het feit dat MySQL over de functie REPAIR beschikt, zegt genoeg.... Heb veel te vaak te maken gehad met omvallende MySQL-databases, gek werd ik van. Het schijnt dat innoDB er geen/minder last van heeft, maar die heeft weer geen full text search. Kijk eens naar Sphinx of Lucene, kun je veel meer mee dan met de FTS van MySQL.

Zo vreselijk als jij het doet voorkomen is het gelukkig zeker niet, MySQL is betrouwbaar genoeg om te gebruiken voor kritieke applicaties.
Echter heb ik inderdaad wel flink meer vertrouwen in InnoDB dan MyISAM.

[cariolive23]

Een gecombineerde index heeft alleen zin als je die kolommen ook altijd gecombineerd in de clausules gebruikt, mocht je namelijk een keer de tweede kolom willen aanspreken dan werkt de gecombineerde index niet meer.

Is dat zo? Dat is dan weer iets bijzonders van MySQL, in PostgreSQL heb je daar in elk geval geen last van. Een gecombineerde index is ook bruikbaar wanneer je slechts een deel uit deze index nodig hebt. Het is wel van belang om even te kijken naar de omvang van de index, een hele grote index waar je maar een heel klein beetje data uit nodig hebt, kun je vaak beter een aparte kleine index voor aanmaken.

Wat je ook doet, ga met EXPLAIN achterhalen of de indexen wel bruikbaar zijn voor jouw queries. Met MySQL is het nog steeds behelpen, kom het nog regelmatig tegen. Wellicht dat 5.1 er al weer beter mee omgaat, nog steeds niet mee gewerkt.

[Gonadan]

cariolive23 schreef op maandag 08 juni 2009 @ 16:32:
Is dat zo? Dat is dan weer iets bijzonders van MySQL, in PostgreSQL heb je daar in elk geval geen last van. Een gecombineerde index is ook bruikbaar wanneer je slechts een deel uit deze index nodig hebt. Het is wel van belang om even te kijken naar de omvang van de index, een hele grote index waar je maar een heel klein beetje data uit nodig hebt, kun je vaak beter een aparte kleine index voor aanmaken.

Ik vraag mij af of het specifiek voor MySQL is.
Voor zover ik weet werkt een gecombineerde index alleen als je vanaf de eerste kolom dezelfde kolommen gebruikt.
Ofwel: een index gecombineerd uit A, B en C werkt voor: A en A,B en A,B,C maar niet voor B of C of B,C.

Wat je ook doet, ga met EXPLAIN achterhalen of de indexen wel bruikbaar zijn voor jouw queries. Met MySQL is het nog steeds behelpen, kom het nog regelmatig tegen. Wellicht dat 5.1 er al weer beter mee omgaat, nog steeds niet mee gewerkt.

Dat sowieso, altijd controleren.

[Voutloos]

Gonadan schreef op maandag 08 juni 2009 @ 16:35:
Ofwel: een index gecombineerd uit A, B en C werkt voor: A en A,B en A,B,C maar niet voor B of C of B,C.

Klopt, voor de gemiddelde index. FULLTEXT indices kennen echter enkele limitaties, dus kwestie van de manual lezen. Als je meer dan (orde van grootte) 100.000 rows verwacht, kan je het lezen van de manual achterwege laten, FULLTEXT is dan een no-go.

[cariolive23]

Ofwel: een index gecombineerd uit A, B en C werkt voor: A en A,B en A,B,C maar niet voor B of C of B,C.

Nou, in PostgreSQL werkt deze index óók voor B of C of B,C.

Een FTS-index werkt in PostgreSQL totaal anders, is ondermeer afhankelijk van het gekozen index-type. GiST en GIN werken totaal anders en hebben ieder hun eigen sterke kanten.

Ps. Het raakt offtopic...

[ Voor 3% gewijzigd door cariolive23 op 08-06-2009 16:49 ]