[MySQL + PHP] database verkleinen

[unconnected]

ik zit met een klein probleem. ik heb via een scriptje de rdf file van 'open directory' (dmoz) geimporteerd naar mijn mysql database. dit leverde me uiteindelijk 4 miljoen rows op zonder index ofzo.
hierop wilde ik nu gaan zoeken (fulltext search erop gezet) en een simpele query kost me 14sec (op een amd1000mhz). een beetje te lang voor waar ik het voor wil gaan gebruiken

nu bevat de database voor een bepaalde categorie meer dan 5 links en ik hoef er niet meer dan 5 te hebben. nu wil ik dus per category nog maar 5 links overhouden. tuurlijk kan ik mijn rdf-parser aanpassen zodat ie maximaal 5 links insert, maar dat duurt me dan weer een hele lange tijd om te inserten

tuurlijk kan ik ook een for-lusje schrijven die alle 'topics' inleest en max per topic 5 links in een nieuwe dbase wegschrijft... maar weet niemand een snellere / efficientere methode?

zo ziet de database er nu uit:

[Spider.007]

waarschijnlijk kun je het beste de database record voor record naar een andere db kopieren; met PHP kun je ervoor zorgen dat hij elke ressource meer (als er meer dan 5 zijn) niet kopieert

[unconnected]

Spider.007 schreef op 06 februari 2004 @ 21:38:
waarschijnlijk kun je het beste de database record voor record naar een andere db kopieren

ja en dan alle duplicates direct verwijderen uit de oude dbase zodat zoeken daarin sneller gaat. ik ben alleen bang dat ook dit mij 15sec / entrie gaat kosten. en dat wordt ondoenlijk met 4miljoen rows...

[Spider.007]

15sec / entrie.. wat een onzin, zoveel tijd kan het nooit kosten. Heb je al indices aangemaakt om de snelheid wat te verbeteren? Heb je onderstaande al geprobeerd?

code:

SELECT *
FROM `<tablename>`
PROCEDURE ANALYSE ( )

[unconnected]

Spider.007 schreef op 06 februari 2004 @ 21:58:
15sec / entrie

vanmiddag was het echt 13.xx sec en nu idd 4.52. het enige wat ik nog heb gedaan is optimize table (ik had wel verwacht dat mysql dat had gedaan na het toevoegen van die fulltextsearch)

procedure analyse() returned overigens een empty set.
5 sec is nu nog wel te doen maar eigenlijk moet gewoon de database kleiner. 5sec maal 4miljoen rows is nog steeds te veel

-= edit =-
toch niet. als je iets aan het begin van de dbase zoekt ben je snel klaar maar als ik mijn script run op iets van het midden van de database:

code:

starting link-search algoritm...
category Top/World/Italiano/Regionale/Europa/Italia/Sicilia/Provincia_di_Enna/Lo
calità/Barrafranca gave us 3 links (using limit: 3)
gevonden links:
 -> http://www.confraternitacrocifisso.it/
 -> http://www.comune.barrafranca.en.it/
 -> http://www.tenutacollotta.it/
1 number of queries took 14.31791 secondes

het enige wat ie nu doet is een

PHP:

SELECT ressource FROM content_links WHERE MATCH (topic) AGAINST ('Top/World/Italiano/Regionale/Europa/Italia/Sicilia/Provincia_di_Enna/Lo
calità/Barrafranca');

-= edit =-

[ Voor 46% gewijzigd door unconnected op 06-02-2004 22:34 ]

[Skaah]

Waarom doe je eigenlijk een fulltext en niet gewoon een match?

[cavey]

waarom ga je niet een database herontwerpen voor je films, netjes uit normaliseren

dan een script schrijven om de oude data gesplit en wel met wat nifty php regexp's in je nieuwe database te zetten?

kost je even een dagje kloten wellicht, maar daarna heb je een loeisnel systeem waarbij je dan "views" (lees, standaard sql queries met joins en andere meuk in MySQL) kan maken met whatever je zoekt?

Lijkt me stuk makkelijker dan nu een hele dag kloten om die fulltext search aan de praat te krijgen........

Als ik zo die record entries bekijk van je, kan je de boel al aardig opschonen door een tabel links te maken met een foreignkey naar een tabel movies...

waarbij je dan alle movies slechts 1 keer erin hebt staan...... en nja ach, je snapt het idee vast wel ...

Die tekst ziet er ook heerlijk uit om gewoon door wat regexps heen te sleuren. Kost je nauwelijks extra tijd, ja, goed, een heel dagje die database om laten zetten door je script. Maar dan ben je er ook mee klaar.

Daarna je RDF reader/importer herschrijven zodat die het aan je eigen database structuur aanpast.

Easy.

laatste opmerking: NORMALISEREN

[Skaah]

komakeef schreef op 07 februari 2004 @ 11:30:
waarom ga je niet een database herontwerpen voor je films, netjes uit normaliseren

dan een script schrijven om de oude data gesplit en wel met wat nifty php regexp's in je nieuwe database te zetten?

kost je even een dagje kloten wellicht, maar daarna heb je een loeisnel systeem waarbij je dan "views" (lees, standaard sql queries met joins en andere meuk in MySQL) kan maken met whatever je zoekt?

Lijkt me stuk makkelijker dan nu een hele dag kloten om die fulltext search aan de praat te krijgen........

Als ik zo die record entries bekijk van je, kan je de boel al aardig opschonen door een tabel links te maken met een foreignkey naar een tabel movies...

waarbij je dan alle movies slechts 1 keer erin hebt staan...... en nja ach, je snapt het idee vast wel ...

Die tekst ziet er ook heerlijk uit om gewoon door wat regexps heen te sleuren. Kost je nauwelijks extra tijd, ja, goed, een heel dagje die database om laten zetten door je script. Maar dan ben je er ook mee klaar.

Daarna je RDF reader/importer herschrijven zodat die het aan je eigen database structuur aanpast.

Easy.

laatste opmerking: NORMALISEREN

explode('/',$string); lijkt me voldoende.

[cavey]

shhhhhhhhhhhhhhhhhhhhhht

ik ben een liefhebber van regexps...... hoe meer ik door preg en ereg kan gooien hoe beter ;D

maar je moet natuurlijk wel nog wat leuke php-code schrijven in de vorm van (hopelijk) re-usable functies om de nieuwe database te vullen .....

maar het zal zoveel schelen in opzoeken...

index over je movie titels (nja, movie-id) ...... inner join op je links tabel en hops, je antwoorden staan er in een zucht en een steun ;D

[huk]
bij nader inzien....... string exploden is natuurlijk het makkelijkst Wel nog de juiste array-entry pakken dan......

[ Voor 13% gewijzigd door cavey op 07-02-2004 11:43 ]

[_Sunnyboy_]

Tsja als ik deze db zie dan heb ik ook erg het gevoel dat er hier gewoon genormaliseerd moet worden. Dan kunnen de full-text searches de deur uit en kunnen indexen hun werk doen.

Op zich is 4 miljoen records geen probleem voor een MySQl db hoor. Ik heb een db van 3miljoen records en m'n joined query hierop duurt toch wel 0.05 seconde

[unconnected]

oh. ff wat opheldering. het is geen database voor films ofzo
het moet aan de hand van een bepaalde category (alle categorien in dmoz: http://dmoz.org/) een paar links teruggeven. achter deze links zit dan weer tekst die ik wil gebruiken om de category te classificeren.

het enige wat ik zou kunnen doen (tenminste zo zie ik het) is de database opdelen naar bijv alle eerste 'topcategorieen'. maar dan krijg je weer een hele zwik losse tabellen... lijkt me niet zo handig.

[jochemd]

unconnected schreef op 07 februari 2004 @ 12:12:
oh. ff wat opheldering. het is geen database voor films ofzo
het moet aan de hand van een bepaalde category (alle categorien in dmoz: http://dmoz.org/) een paar links teruggeven. achter deze links zit dan weer tekst die ik wil gebruiken om de category te classificeren.

Is MySQL een verplichting? PostgreSQL heeft een GIST index type dat speciaal is geschreven om door DMOZ-data te zoeken. Ik zou me kunnen voorstellen dat dat iets efficienter is dan wat je zelf gaat schrijven.

[unconnected]

jochemd schreef op 07 februari 2004 @ 12:58:
[...]
Is MySQL een verplichting? PostgreSQL heeft een GIST index type dat speciaal is geschreven om door DMOZ-data te zoeken. Ik zou me kunnen voorstellen dat dat iets efficienter is dan wat je zelf gaat schrijven.

kijk dat klinkt leuk. zag alleen dat postgresql niet beschikbaar is voor windows maar der staat hier ook nog een linux-systeempje dus dat zou geen probleem zijn. ga ik ff uitzoeken

voor nu parse ik ook de rdf maar opnieuw en zet ik een limit op het aantal links per category dat ie toevoegd. als ik dan op de 2miljoen links zit gaat het misschien 2sec per query duren. nog lang maar acceptabel hoop ik.

[cavey]

alle informatie die je nodig hebt is toch bekend om de boel uit te normaliseren? Die hele DMOZ zal vast ook genormaliseerd zijn.........

alleen dan kom je er vrij snel doorheen. Tja, het kost wat conversie inspanningen, maar eenmaal zo'n mooi conversie scriptje gebakken en je queries gaan geheid sneller en je hebt er geen omkijken meer naar...... ipv de hele tijd te kludgen etc.