webForumDet fria alternativet

Stora recordsets, MySQL och AJAX

PHPur PHP

10 svar · 940 visningar · startad av prplxr

prplxrMedlem sedan juni 2012582 inlägg
#1

Hejsan, svejsan!

Jag sitter och ska fixa en funktion som listar, låt säga 10 poster mha AJAX under en inputbox beroende på vad man skrivit som en datalist.

Detta är egentligen ingen svår grej, men kruxet är att tabellen som innehåller de ord som ska föreslås är... gigantisk... Vi talar om miljoner rader. Jag ser framför mig hur servern gråter. Jag vill inte ha någon färdig lösning på detta, det är inget roligt, men jag skulle vilja bolla lite tankar och idéer med någon eller några.

Vilken approach bör jag välja? Vilka tekniska problem och begränsningar bör jag ha i åtanke? Osv, osv...

Tack för förhud! :e

onkelborgMedlem sedan juli 2003555 inlägg
#2

Är det något i stil med auto complete du tänker på med andra ord?

Jag tänker att du ska ha ett bra index till att börja med, och det ska inte vara ett hashat index utan snarare något trädbaserat, då kan du lätt göra sökningar på strängar som börjar med någonting valfritt. Ganska enkelt och okomplicerat.

prplxrMedlem sedan juni 2012582 inlägg
#3

Ja, precis, auto complete men med flera alternativ hela tiden. Den enklaste lösningen i min värld är ju bara att skicka ett anrop via AJAX vid onKeyUp() på inputfältet, men jag har gjort en sådanhär lösning tidigare med Like och %. Det slutade i katastrof. :P

onkelborgMedlem sedan juli 2003555 inlägg
#4

Hade du vettiga index då? Sen kan det vara en bra idé att inte skicka en request direkt på keyup utan köra en timeout som kan resetas ifall ytterligare någon tangent trycks ner inom en snar framtid

prplxrMedlem sedan juni 2012582 inlägg
#5

Det hade jag visserligen inte, får kika på det samt det här med att köra setTimeout()! Tack för tipsen! :-)
Mer att tänka på?

onkelborgMedlem sedan juli 2003555 inlägg
#6

Index, index, index. Utan ett vettigt index så kommer det aldrig gå. Med ett vettigt index så kommer det gå galant. Skillnaden är att med inget index/fel index så kommer din sökning behöva gå igenom samtliga rader i tabellen, men med rätt index så kommer den leta sig ner i ett träd med början i roten, och ta rätt väg hela tiden, och kommer enbart titta på det som stämmer, det som inte stämmer struntar den fullkomligt i.

danjelMedlem sedan juni 200443 inlägg
#7

Tänk efter om du gör LIKE sökningar

använder inte index:

SELECT * FROM tbl_name WHERE col LIKE '%sökefter%';

använder index:

SELECT * FROM tbl_name WHERE col LIKE 'sökefter%';

Kolla även på full text index som är rätt schysst

http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

prplxrMedlem sedan juni 2012582 inlägg
#8

Jag använder redan full text index på den allra största tabellen jag har och det fungerar bra med MATCH AGAINST. Tittar på en sådan lösning här också.

danjelMedlem sedan juni 200443 inlägg
#9

Ah ok full text index , då tror jag du är inne på rätt spår redan : )

Andra alternativ, beroende på hur din data ser ut, kan vara att replikera ut data till en annan tabell eller databas som är mer "sökvänlig". Alltså om du t.ex kör joins eller liknande nu så kan det gå att aggregera data från original tabellen/tabellerrna med ett schedulerat jobb till en ny tabell/tabeller .
Man kan även sätta fler index på den /de nya tabellerna utan att skrivningar/uppdateringar blir sega med detta angreppssätt.
Om detta är applicerbart i just detta fall..

prplxrMedlem sedan juni 2012582 inlägg
#10

Det låter helt klart intressant! Hur skulle något sådant gå till? Har du någon bra länk till någon artikel i MySQL-manualen?

danjelMedlem sedan juni 200443 inlägg
#11

Denna visar hur man kan köra scheduled events
http://www.sitepoint.com/how-to-create-mysql-events/

Är väl att föredra framför vanliga php cron jobb antar jag.
Men samtidigt, om du kan lösa detta med enbart index eller fulltext varianten så är det ju kanske overkill

Känns spontant som att detta kan bli en resurskrävande operation , dvs autocomplete mot så mycket data. Kanske värt att låta den ajax requesten gå mot en annan DB server, det borde gå att göra så att schedulerade jobbet skriver till en annan server.

Kanske även s.k replikering kan vara användbart , har ingen koll rikttigt på det men värt att undersöka kanske
http://dev.mysql.com/doc/refman/5.0/en/replication.html

129 ms totalt · 3 externa anrop · v20260731065814-full.29ac60f6
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
126 ms — hämta tråd, inlägg och bilagor (db)