gute datenbankstruktur für großen suchindex

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • gute datenbankstruktur für großen suchindex

    hallo

    ich habe eine kleine frage bzgl. einer datenbankstruktur. ich möchte gerne eine kleine "suchmaschine" mit suchindex bauen. das ganze soll eine Produkt- bzw. Preisvergleichsuchmaschine werden. Maximal werden es denke ich 2 Mio Produkte werden. dazu verwende ich php und mysql. als datenbankstruktur habe ich mir folgendes zusammengebastelt:

    Keywordtabelle: keyword_id | keyword
    Indextabelle: keyword_id | produkt_id
    Produkttabelle: produkt_id | description | img_url | etc.

    wenn jetzt einer eine suchanfrage startet, mit z.b dem keyword "fernseher", dann wird fernser in der Keywordtabelle gesucht und die keyword_id ausgelsen. Danach liest er die produkt_id`s aus der Indextabelle, bei denen die keyword_id gleich der davor ausgelesenen ist. hat er nun die produkt_id´s, kann er in der produkttabelle die nötigen infos, wie beschreibung, bildurl etc. auslesen.
    der vorteil an dieser struktur ist, dass die indextabelle nur aus integern besteht und somit relativ flott durchsucht werden kann. der nachteil, sie bekommt sehr viele datensätze.
    wenn ich zb. 2 Mio produkte habe und ich im schnitt pro produkt 100 keywords zuordne, dann hat die indextabelle 2mio * 100 keywords = 200.000.000 datensätze. ok es sind nur integer und daher relativ schnell zu durchsuchen, aber packt sowas die mysql db?
    das ganze läuft momentan noch auf nem Celeron 2.400 MHz mit 512 MB speicher.

    nun die frage an die, die mit solchen großen datenmengen schon erfahrungen gesammelt haben. von der db struktur machen das ja auch die großen suchmaschienen soweit ich weiss. nur ich kann mir nicht vorstellen, dass der index mit 200 Mio datensätze noch schnell funktioniert. braucht man da einfach mehr rechenpower, oder wie könnte ich das ganze von der performance noch verbessern. habe mal irgendwo gehört, dass man die indextabelle auch eventuell aus der datenbank in ein file auslagern kann, da das schneller zu durchsuchen ist. bein leider kein informatiker
    hat irgendjemand tips oder sowas schon mal selber gemacht? kennt ihr irgendwelche links zu weiteren infos speziell zu diesem thema. ich könnte das ganze natürlich ausprobieren, aber das würde sehr lange dauern, bis man dann den ganze index voll hat. würde es gerne daher schon vorher wissen, wie ich das am besten zusammenbaue.

    schon mal vielen dank für eure antworten.

    gruss
    Zuletzt geändert von schorschseo; 18.03.2012, 09:52.

  • #2
    Re: gute datenbankstruktur für großen suchindex


    hello,

    ich glaub nicht, dass du mit nem normalen pc glücklich werden wirst.
    da muss meiner meinung nach schon ein wenig mehr db-power her...

    k.

    Kommentar


    • #3
      habe mal irgendwo gehört, dass man die indextabelle auch eventuell aus der datenbank in ein file auslagern kann, da das schneller zu durchsuchen ist.
      Das glaube ich nicht, Tim.

      Kommentar


      • #4
        ich glaub nicht, dass du mit nem normalen pc glücklich werden wirst.
        da muss meiner meinung nach schon ein wenig mehr db-power her...
        und was bräuchte man dann deiner meinung nach. ob ich jetzt ein oder 2 server habe spielt dann auch keine rolle. oder denkest du hier eher an ein paar sun workstations.
        es gibt aber auch kleine suchmaschinen bzw. produktsumas mit ca. 1-2mio produkte. die laufen soweit ich weiss auch nicht auf einem speziellen serversystem.

        mir geht es hier aber eher um die programmiertechnische optimierung und nicht um hardwareoptimierung.

        gruss
        Zuletzt geändert von schorschseo; 18.03.2012, 09:54.

        Kommentar


        • #5
          mir geht es hier aber eher um die programmiertechnische optimierung und nicht um hardwareoptimierung.
          wenn du programmtechnische optimierung willst, dann musst du ein vernünftiges datenbankmodell entwickeln und umsetzen. redundanz vermeiden und unnütze anfragen, die dir zu viele unnütze spalten liefern. die db selbst, tut schon ihr bestes um mit der datengröße fertig zu werden, sie hat da so ihre möglichkeiten mit hash- und indextabels, caching, usw. dafür gibt es doch leute, die sich ein lebenlang darüber den kopf zerbrechen.
          bei dieser datenmenge, solltest du auf datensicherheit einen großen wert legen, falls sich mysql doch mal verabschiedet, solltest du regelmäßige sicherungen anlegen.

          meine meinung: probier es aus, wenn es doch zu langsam läuft, kannst du dir immer noch nen anderen rechner kaufen.
          ich geh zum lachen in den keller

          Kommentar


          • #6
            Mir ist noch nicht ganz klar, wofür die Indextabelle gut sein soll.
            Ich würde vermutlich in der Produkttabelle die KeywordID mit reinhängen und dann ist es ein Lesezugriff und eine Datei weniger.

            kuempi

            Kommentar


            • #7
              @kuempivonstein
              das nennt sich koppeltabelle und sollte nur aus fremdschlüsseln bestehen. was machst du denn, wenn du einem gerät mehrere keywörter zuordnen willst, oder einem keywort mehrere geräte? dann bräuchstest du entweder den kompletten datensatz doppelt, außer die änderung bei keywort bzw. produkt_id oder so ne kleine koppeltabelle, wo die id vom gerät drin steht und die verschiedenen keywörter:

              bsp.
              id.fernseher5-id.keywort_HALLO;
              id.fernseher5-id.keywort_DU;
              id.fernseher5-id.keywort_DA;

              oder
              id.fernseher2-id.keywort_HALLO;
              id.radio5-id.keywort_HALLO;
              id.fernseher5-id.keywort_HALLO;

              macht das wirklich schneller/effektiver und verhindert unnötig viel redundanz.

              und wieder was gelernt!

              @schorschseo
              dein datenbankmodell sieht schon mal gut aus, wenn es so bleibt
              ich geh zum lachen in den keller

              Kommentar


              • #8
                Original geschrieben von KamiKatze
                @kuempivonstein
                das nennt sich koppeltabelle und sollte nur aus fremdschlüsseln bestehen. was machst du denn, wenn du einem gerät mehrere keywörter zuordnen willst, oder einem keywort mehrere geräte? dann bräuchstest du entweder den kompletten datensatz doppelt, außer die änderung bei keywort bzw. produkt_id oder so ne kleine koppeltabelle, wo die id vom gerät drin steht und die verschiedenen keywörter:

                bsp.
                id.fernseher5-id.keywort_HALLO;
                id.fernseher5-id.keywort_DU;
                id.fernseher5-id.keywort_DA;

                oder
                id.fernseher2-id.keywort_HALLO;
                id.radio5-id.keywort_HALLO;
                id.fernseher5-id.keywort_HALLO;

                macht das wirklich schneller/effektiver und verhindert unnötig viel redundanz.

                und wieder was gelernt!

                @schorschseo
                dein datenbankmodell sieht schon mal gut aus, wenn es so bleibt
                koppeltabelle?
                sagt mir nix.
                anyway...
                ich hab mal nen beispiel, eventuell können wir daran die sache ausdiskutieren?

                also erst mal die drei files so wie ich es verstanden hatte:

                KWTAB
                --------
                KW-ID KW
                100 Fernseher
                200 Waschmaschine
                300 Maultrommel


                IDTAB
                -------
                KW-ID P-ID
                100 4711
                100 4712
                200 0815
                300 666
                300 69


                PRTAB
                -------
                P-ID Text URL ETC.
                4711 Ferseher 58cm http.... usw
                4712 Fernseher 60 usw usw

                und ich könnte mir nun vorstellen auf die IDTAB zu verzichten und statt dessen die PRTAB gleich so zu bauen:


                PRTAB
                -------
                K-ID P-ID Text URL ETC.
                100 4711 Ferseher 58cm http.... usw
                100 4712 Fernseher 60 usw usw

                grussle
                kuempi

                Kommentar


                • #9
                  sorry, hab nicht zeit so regelmäßig reinzuschauen.
                  also ich ändere deine vorgegebenen tabellen mal von den inhalten etwas ab. ich habe es so verstanden, dass in der keyworttabelle schlagwörter stehen, die auch auf mehrere produkte zutreffen können.

                  KWTAB
                  --------
                  KW-ID KW
                  100 Fernseher
                  200 Waschmaschine
                  300 Maultrommel

                  PRTAB
                  -------
                  P-ID
                  4711 grün
                  4712 16 zoll
                  4713 3 jahre service

                  IDTAB
                  -------
                  KW-ID P-ID
                  100 4711
                  100 4712
                  200 4713
                  300 4711
                  300 4713

                  wenn du jetzt die suche nach schlagwörtern startest, suchst du dir die id für "grün" raus und suchst dir in der koppeltabelle die geräte mit dieser eigenschaft. hier wäre jetzt die maultrommel und der fernseher grün. so kannst du jedem produkt edliche verschiedene schlagwörter hinzufügen und andersrum ebenfalls. würdest du die produkte direkt bei den schlagwörtern reinschreiben, wäre es sehr unübersichtlich, schwer zu verändern, zu löschen, usw. würden in den einzelnen tabellen noch mehr spalten drin stehen, würde sich die wiederholung gleicher inhalte stark steigern. deswegen diese koppeltabelle. es ist jetzt auch viel einfacher aus grün, hellgrün zu machen, ohne alle geräte durchgehen zu müssen, ...
                  das lässt sich natürlich nicht sehr oft so einfach anwenden, hat aber viele vorteile.
                  ist nur noch die frage, ob schorschseo genau das meinte.
                  ich geh zum lachen in den keller

                  Kommentar


                  • #10
                    Original geschrieben von KamiKatze
                    sorry, hab nicht zeit so regelmäßig reinzuschauen.
                    ......
                    <schnipp>
                    .....
                    ist nur noch die frage, ob schorschseo genau das meinte.
                    kein problem, bin ja auch nicht 24/7 hier.
                    aus dieser sichtweise gebe ich dir recht.

                    ist eben immer wichtig vorher gut zu designen.
                    im nachinein ne tabelle/anwendung zu modifizieren ist selten gut.

                    tschödele

                    k.

                    Kommentar


                    • #11
                      immer wieder gern!

                      man ließt sich.
                      ich geh zum lachen in den keller

                      Kommentar


                      • #12
                        erstmal vielen dank für eure beiträge. sorry habs irgendwie verplant die letzte zeit vorbei zu schauen.

                        also bisher läuft es ganz gut. habe schon ca. 250.000 produkte, was eine Index-Tabelle von momentan genau 2.112.553 datensätze ergibt die suche geht noch relativ flott. mal sehen was passiert, wenn ich mal bei 2 mio produkten angekommen bin.
                        was momentan nur etwas ausbremst ist die suche mit mehreren keywords. man erhält dadurch mehrere arrays, also pro keyword ein array, in denen die einzlenen produkt_ids enthalten sind. jetzt will man natürlich die produkte, auf die am meisten keywords treffen, zuerst anzeigen.
                        ich bilde also die schnittmenge aus den arrays mit array_intersect() das geht dann glaub ich schon etwas in die performance. mal sehen ob sich dafür noch eine schneller lösung finden lässt. also wenn irgendwer was besseres weiss. ich bin immer offen für neue ratschläge
                        ich werde denk ich nochmal später berichten, wenn ichs nicht vergesse. momentan befindet sich das teil so zu sagen noch in der beta phase. mal sehen was sich die nächste zeit so tut.

                        grüsse

                        Kommentar


                        • #13
                          klar:

                          machs sql-seitig.

                          group by sollte dir da helfen.
                          order by count() müsste weiter helfen.

                          Kommentar

                          Lädt...
                          X