[JLE]

Har läst på lite om hur man skall gå till väga för att göra fulltext sökningar i massor av data och då rekommenderas att man använder sig av en såkallad "common words" lista för att filtrera bort ointressanta ord. Är det någon som har en sådan för svenska?


För annat onödigt vetande så kan jag berätta hur glad jag blev när jag felsökte varför vissa förfrågningar mot MySQL tog 0.5-7 sec att göra och efter lusläsning av diverse optimiseringstips i böcker för MySQL så hittade jag felet:

mysql> SELECT id FROM feeds WHERE hash=-986428719 AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.html';
+--------+
| id   |
+--------+
| 201583 |
+--------+
1 row in set (0.67 sec)

mysql> SELECT id FROM feeds WHERE hash='-986428719' AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.htmll';
+--------+
| id   |
+--------+
| 201583 |
+--------+
1 row in set (0.00 sec)

Ser ni differansen i tid det tar att göra förfrågan?

Till detta hör att hash är varchar och att Python/MySQLdb som skapar queryn tror att det jag skickar in är integers så mysql måste göra en typomvanlding vilket tar tid.

[Weaver]

Tror inte det är common words du letar efter. Det du söker är stopwords, dvs ord som - och, det, att osv.

Här är en lista
http://snowball.tartarus.org/algorit...edish/stop.txt

[JLE]

Precis. Tack

[fors]

Originally posted by JLE@Sep 1 2007, 23:45
Har läst på lite om hur man skall gå till väga för att göra fulltext sökningar i massor av data och då rekommenderas att man använder sig av en såkallad "common words" lista för att filtrera bort ointressanta ord. Är det någon som har en sådan för svenska?


För annat onödigt vetande så kan jag berätta hur glad jag blev när jag felsökte varför vissa förfrågningar mot MySQL tog 0.5-7 sec att göra och efter lusläsning av diverse optimiseringstips i böcker för MySQL så hittade jag felet:

mysql> SELECT id FROM feeds WHERE hash=-986428719 AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.html';
+--------+
| id * * |
+--------+
| 201583 |
+--------+
1 row in set (0.67 sec)

mysql> SELECT id FROM feeds WHERE hash='-986428719' AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.htmll';
+--------+
| id * * |
+--------+
| 201583 |
+--------+
1 row in set (0.00 sec)

Ser ni differansen i tid det tar att göra förfrågan?

Till detta hör att hash är varchar och att Python/MySQLdb som skapar queryn tror att det jag skickar in är integers så mysql måste göra en typomvanlding vilket tar tid.

Att den andra frågan går fortare beror antagligen på Query-cachen.

Testa med att lägga till SQL_NO_CACHE så används inte query-cachen, utan varje sökning går verkligen in i databasen och söker. Antagligen kommer båda frågorna ta ungefär lika lång tid. Hur stor är tabellen förresten och använder du dina index korrekt?

SELECT SQL_NO_CACHE id FROM feeds WHERE hash=-986428719 AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.html';

Respektive

SELECT SQL_NO_CACHE id FROM feeds WHERE hash='-986428719' AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.htmll';

[WizKid]

Om hashvärdet är en int så verkar det smartare att spara det som en int istället för att spara det som en varchar.

[JLE]

Originally posted by fors@Sep 2 2007, 17:05

Att den andra frågan går fortare beror antagligen på Query-cachen.

Testa med att lägga till SQL_NO_CACHE så används inte query-cachen, utan varje sökning går verkligen in i databasen och söker. Antagligen kommer båda frågorna ta ungefär lika lång tid. Hur stor är tabellen förresten och använder du dina index korrekt?

mysql> SELECT SQL_NO_CACHE id FROM feeds WHERE hash='-986428719' AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.htmll';
Empty set (0.00 sec)

mysql> SELECT SQL_NO_CACHE id FROM feeds WHERE hash=-986428719 AND url='http://sdfsdsdf.fsdf.se/1187633754_vr_sk.htmll';
Empty set (0.23 sec)

Det _är_ typomvandlingen som tar tid.

[fors]

Ursprungligen postat av JLE

mysql SELECT SQL_NO_CACHE id FROM feeds WHERE hash=-986428719 AND url=http://sdfsdsdf.fsdf.se/1187633754_vr_sk.htmll;
Empty set (0.00 sec)
mysql SELECT SQL_NO_CACHE id FROM feeds WHERE hash=-986428719 AND url=http://sdfsdsdf.fsdf.se/1187633754_vr_sk.htmll;
Empty set (0.23 sec)
Det _är_ typomvandlingen som tar tid.

Okej. Det verkar väldigt konstigt att en typomvandling tar 0,23 sekunder. Det verkar snarare som att det är en bugg i MySQL! Det är jobbigt att felsöka när man skall felsöka där man inte borde felsöka. Jag testade lite snabbt själv (dock bara med ett fåtal rader i tabellen) och båda frågorna tog lika lång tid (0,00 sekunder).

[JLE]

Ursprungligen postat av fors

Okej. Det verkar väldigt konstigt att en typomvandling tar 0,23 sekunder. Det verkar snarare som att det är en bugg i MySQL! Det är jobbigt att felsöka när man skall felsöka där man inte borde felsöka. Jag testade lite snabbt själv (dock bara med ett fåtal rader i tabellen) och båda frågorna tog lika lång tid (0,00 sekunder).

Enligt boken "MySQL - The definitive guide to using, programming.. osv" så står det på sidan 309:

"Avoid overuse of MySQL's automatic type conversion. MySQl will perform automatic type conversion, but if you can avoid conversions, you may get better performance"

Står även att indexet kan helt uteslutas om mysql måste göra en typkonvertering.

[fors]

Originally posted by JLE@Sep 14 2007, 11:45

Enligt boken MySQL - The definitive guide to using, programming.. osv så står det på sidan 309:
Avoid overuse of MySQLs automatic type conversion. MySQl will perform automatic type conversion, but if you can avoid conversions, you may get better performance
Står även att indexet kan helt uteslutas om mysql måste göra en typkonvertering.

Nej, det är ju klart att man bör undvika typomvandlingar om man kan det. Men oavsett så borde inte en typomvandling ta så lång tid, tycker man ju. Fast det kanske är så att MySQL typomvandlar alla rader och inte själva inputen... I vilket fall som helst så är det ju en tämligen simpel operation att göra om ett tal till en sträng.

Oj, missade sista raden. Underlig att indexet inte används då. Då kanske MySQL inte typomvandlar själva indatan, utan det som finns i databasen.