Meddelande

Minska
No announcement yet.

Stora recordsets, MySQL och AJAX

Minska
X
 
  • Filter
  • Klockan
  • Show
Clear All
new posts

  • Stora recordsets, MySQL och AJAX

    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!
    Avundas aldrig någon det sken av lycka han har för du känner inte hans hemliga sorger.

  • #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.

    Kommentera


    • #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.
      Avundas aldrig någon det sken av lycka han har för du känner inte hans hemliga sorger.

      Kommentera


      • #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

        Kommentera


        • #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å?
          Avundas aldrig någon det sken av lycka han har för du känner inte hans hemliga sorger.

          Kommentera


          • #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.

            Kommentera


            • #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/...xt-search.html

              Kommentera


              • #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å.
                Avundas aldrig någon det sken av lycka han har för du känner inte hans hemliga sorger.

                Kommentera


                • #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..

                  Kommentera


                  • #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?
                    Avundas aldrig någon det sken av lycka han har för du känner inte hans hemliga sorger.

                    Kommentera


                    • #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

                      Kommentera

                      Working...
                      X