Datenbank mit über 10Mio. Einträgen MySQLServer und DB Optimieren? BITTE HELFT MIR.

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

  • Datenbank mit über 10Mio. Einträgen MySQLServer und DB Optimieren? BITTE HELFT MIR.

    Hey ihr Lieben

    ich bin hier im Moment am

    Bei mir spinnt seit dem Server-Umzug meine Datenbank und dadurch läuft mysql die ganze zeit mit 100% durch. Nun bin ich zurzeit wieder mal dabei alles zu Optimieren. Nur bin ich bei meiner Gästebuchdatenbank langsam am Ende. Vielleicht könnt Ihr mir da ja noch ein paar Tips geben. Ich komme sonst hier echt nicht mehr mit dem Optimieren weiter.

    Also mal zur Erklärung:

    Meine Tabellenstruktur vom Gästebuch sieht so aus:

    id = mediumint(8) NOT NULL auto_increment und hier liegt auch der PRIMARY Key drauf
    fromuser = varchar(255) NOT NULL
    touser = varchar(255) NOT NULL Liegt ein INDEX drauf.
    massage = mediumtext NOT NULL
    unread tinyint(1) NOT NULL Standart = 0 Liegt auch ein INDEX drauf
    intime int(11) NOT NULL Standart = 0
    rekoment mediumtext NOT NULL
    privat int(1) NOT NULL Standart = 0


    Ob die Tabellenstruktur jetzt für so eine riesen Datenbank wirklich die beste Auswahl ist, weiß ich nicht so genau, aber auf dem anderen Server lief es ja damit Super.

    Nur hat diese Datenbank im Moment 5,5 Mio Einträge und wächst natürlich ständig weiter und kommt damit wohl langsam an seine Grenzen und die Select abfragen werden immer und immer langsamer. Darum wollte ich da jetzt auch noch mal ein wenig was dran ändern. Nur hab ich noch keine Idee, wo man hier am besten Optimieren kann.

    Eine der häufigsten Abfragen auf meiner Seite ist, ob man neue GB Einträge hat. Das bremst aber jetzt langsam den Server so übel, dass ich da unbedingt was ändern muss.

    Darum hab ich auch so 2 oder 3 Fragen

    Beim Abfragen der neuen GB Einträge benutze ich folgenden Code:
    PHP-Code:
    $resultcountergb mysql_query("SELECT unread FROM `spop_gbook` where touser='".$comu."' AND `unread` = '0'");
    $resultgb mysql_num_rows($resultcountergb); 
    Diese Abfrage bremst aber den ganzen Server so übel, dass ich mich jetzt frage, was ist eigentlich schneller und nimmt den Server nicht ganz so viel Performance?

    SELECT count(unread) oder mysql_num_rows (Ich hab schon 1000 Beiträge im Netz gelesen, aber mich interessiert hier einfach mal eure Erfahrung und Meinung dazu)? Und habe ich für diese Selectabfrage die INDEX auf meine Spalten richtig gesetzt? Und könnte ich das vielleicht mit einer order by desc Klausel noch ein bisschen beschleunigen? Also order by id desc passt hier glaube ich nicht, da er ja schon 1 Mio neue eintrage bis zum aufrufen haben kann. Und order by unread finde ich auch blödsin, da er ja nur 0 und 1 bei unread drin zu stehen hat und damit ja nicht wirklich ordnen müsste. Also order by touser könnte ich mir z.B. ganz gut vorstellen, nur weiß ich nicht ob das wirklich was bringen würde? Und als letzte Frage zu diesem Problem, im phpMyAdmin gibt es unter jeder Tabelle immer die Funktion: Tabellenstruktur analysieren... Kann ich dieser Funktion bei einer ständig wachsenden Tabelle auch vertrauen und damit meine Datenbank vielleicht noch mal ein bisschen Optimieren? Ich bin mir da nicht so sicher, da er ja in der Tabelle nach den kleinsten und den größten Eintrag sucht und diesen dann als Optimal anbietet. Doch kann sich doch an dem max. im laufe der Zeit auch was ändern. Sollte man dann da doch lieber ein bisschen großzügiger verteilen, oder?


    So, das zum Optimieren meiner GB Datenbank, doch was würde das bringen, wenn man nicht auch die richtigen Einstellungen auf dem Server hat?

    Darum hier mal ein paar Daten zu meinem Server und auch hier wieder die Große Frage, wo könnte ich nochmal ein wenig was an geschwindigkeit raus holen?

    Also mein Server hat folgende Hardware:
    2 x Intel Xeon - E5504 = 2 x 4 x 2,0 GHz
    8GB DDR3 Ram
    2 x 1.000 GB SATA II
    PHP Version: 5.2.6-1+lenny9
    MySQL Version: 5.0.51a

    Mehr ist ja jetzt zum Optimieren vom Server nicht nötig, oder?

    So und hier mal meine Einstellungen:

    Meine Apache2.conf:
    Code:
    Timeout 150
    KeepAlive On
    MaxKeepAliveRequests 10
    KeepAliveTimeout 2
    
    <IfModule mpm_prefork_module>
    StartServers 5
    MinSpareServers 30
    MaxSpareServers 50
    MaxClients 256
    MaxRequestsPerChild 4000
    </IfModule>
    
    <IfModule mpm_worker_module>
    StartServers 5
    MaxClients 256
    MinSpareThreads 30
    MaxSpareThreads 75
    ThreadsPerChild 50
    MaxRequestsPerChild 4000
    </IfModule>
    
    HostnameLookups Off
    Meine my.conf:
    Code:
    key_buffer = 128M
    net_buffer_length = 8K
    
    sort_buffer_size = 128K
    myisam_sort_buffer_size = 30M
    read_buffer_size = 64K
    read_rnd_buffer_size = 64K
    join_buffer_size = 4M
    
    query_cache_size = 64M
    thread_cache = 128
    thread_concurrency = 4
    table_cache = 2048
    max_allowed_packet = 10M
    
    max_connections = 1500
    low_priority_updates = 1
    #long_query_time = 2
    
    connect_timeout = 30
    wait_timeout = 1800
    
    thread_stack = 128K
    thread_cache_size = 8
    #thread_concurrency = 10
    #
    # * Query Cache Configuration
    #
    query_cache_limit = 1M
    An der php.ini hab ich eigentlich nichts geändert. Vielleicht hat aber auch hier der eine oder andere einen vorschlag, was man an der php.ini noch machen sollte, um den Server noch ein wenig zu beschleunigen?

    - Ich bin für jeden Tip und jede Antwort wirklich sehr sehr dankbar und bedanke mich schon mal, dass du dir die Zeit genommen hast, meine Frage zu lesen.

    - Liebe Grüße,
    Sniky
    Zuletzt geändert von wahsaga; 11.10.2010, 15:02. Grund: Beitrag wieder hergestellt, um Threadverlauf nachvollziehbar zu halten

  • #2
    auf den ersten Blick: touser ist VarChar?

    SELECT count(unread) oder mysql_num_rows (Ich hab schon 1000 Beiträge im Netz gelesen, aber mich interessiert hier einfach mal eure Erfahrung und Meinung dazu)?
    wenn du schon so viel darüber gelesen hast, was ist daran nicht zu verstehen, dass bei der numrows-Variante erstmal alle Zeilen im Speicher landen, obwohl du sie nicht brauchst?
    ...
    ein limit 1 könnte in jedem Fall nicht schaden.
    Zuletzt geändert von TobiaZ; 11.10.2010, 13:36.

    Kommentar


    • #3
      Hmm...
      Erstmal würde ich den where Teil tauschen.

      Code:
      SELECT unread 
        FROM `spop_gbook` 
        WHERE `unread` = '0' AND touser='".$comu."'
      Ob das so der Bringer ist, naja...


      Code:
      EXPLAIN SELECT unread 
        FROM `spop_gbook` 
        WHERE `unread` = '0' AND touser='".$comu."'
      Müsste dir die Schwachstelle zeigen können


      fromuser = varchar(255) NOT NULL
      touser = varchar(255) NOT NULL Liegt ein INDEX drauf.
      Diese User stehen sicherlich in einer n:m Relation.
      Sollten also in eine "User" Tabelle ausgelagert werden.
      Dadurch werden die betreffenden Spalten in der "Messages" Tabelle numerisch.
      Siehe: Die 5 Normal Formen
      Wir werden alle sterben

      Kommentar


      • #4
        Erstmal vielen Dank für eure schnellen Antworten

        Zitat von combie Beitrag anzeigen
        Hmm...
        Erstmal würde ich den where Teil tauschen.

        Code:
        SELECT unread 
        FROM `spop_gbook` 
        WHERE `unread` = '0' AND touser='".$comu."'
        Ob das so der Bringer ist, naja...
        Ok, werde ich auf jeden Fall schon mal machen, werde ich ja sehen ob es was bringt

        Zitat von combie Beitrag anzeigen
        Code:
        EXPLAIN SELECT unread 
        FROM `spop_gbook` 
        WHERE `unread` = '0' AND touser='".$comu."'
        Müsste dir die Schwachstelle zeigen können
        Bringt mit die Folgende Ausgabe:

        id select_type table type possible_keys key key_len ref rows Extra
        1 SIMPLE spop_gbook index_merge touser,unread unread,touser 1,257 NULL 300 Using intersect(unread,touser); Using where; Using...



        Zitat von combie Beitrag anzeigen
        Diese User stehen sicherlich in einer n:m Relation.
        Sollten also in eine "User" Tabelle ausgelagert werden.
        Dadurch werden die betreffenden Spalten in der "Messages" Tabelle numerisch.
        Siehe: Die 5 Normal Formen
        Also das verstehe ich jetzt nicht ganz, n:m?

        Ich hab das jetzt mal so verstanden, dass ich in den feldern fromuser und touser lieber mit id´s arbeiten sollte? Aber wäre das dann nicht noch eine abfrage mehr, um erstmal herauszufinden wer hinter dieser ID überhaupt steckt?

        Ich hab ja schon eine Usertabelle mit ID, aber ich bin mir jetzt nicht so sicher, wie ich das ändern sollte? dann müsste ich die 5,5Mio einträge ja komplett ändern und überall erstmal die ID setzen lassen und dann die Spalten ändern, oder?


        @TobiaZ


        auf den ersten Blick: touser ist VarChar?

        kannst du mir das vielleicht auch kurz erklären, warum du das auf VarChar ändern würdest?

        Vielen Dank für euren Antworten.

        Liebe Grüße,
        Sniky
        Zuletzt geändert von wahsaga; 11.10.2010, 15:03. Grund: Beitrag wiederhergestellt

        Kommentar


        • #5
          kannst du mir das vielleicht auch kurz erklären, warum du das auf VarChar ändern würdest?
          Es IST bereits Varchar! (ist doch deine eigene Strucktur ) Ich würde es natürlich nicht als Varchar sehn wollen, sondern lediglich die ID als INT speichen...

          Kommentar


          • #6
            Also das verstehe ich jetzt nicht ganz, n:m?
            Dann solltest du dir die Zeit nehmen und diesen beiden Links folgen.
            und natürlich das dortige aufmerksam lesen
            Die 5 Normal Formen
            A Visual Explanation of SQL Joins
            Wir werden alle sterben

            Kommentar


            • #7
              Zitat von TobiaZ Beitrag anzeigen
              Es IST bereits Varchar! (ist doch deine eigene Strucktur ) Ich würde es natürlich nicht als Varchar sehn wollen, sondern lediglich die ID als INT speichen...
              ja das hatte ja @combie glaube ich auch so gemeint. aber dazu hatte ich ja auch schon was gefragt.

              Aber wäre das dann nicht noch eine abfrage mehr, um erstmal herauszufinden wer hinter dieser ID überhaupt steckt?

              Ich hab ja schon eine Usertabelle mit ID, aber ich bin mir jetzt nicht so sicher, wie ich das ändern sollte? dann müsste ich die 5,5Mio einträge ja komplett ändern und überall erstmal die ID setzen lassen und dann die Spalten ändern, oder?


              Ich lese ja die GB´s auch wieder aus und da müsste ich ja dann auch nochmal auf die DB der User zugreifen... Das wollte ich ja eigentlich vermeiden, darum stehen ja auch in diesen Feld die Usernamen und nicht die ID´s

              Ich kann mir schon vorstellen, dass es mit intfeldern sicherlich eine schnellere Antwort bei der anzahl von DB einträgen gehen würde, doch wird diese Datenbank den ganzen Tag ausgelesen, geupdatet und reingeschrieben und auch daten gelöscht und ich glaube da wäre es dann wieder langsamer wenn ich erst überprüfen müsste, wer die ID xx hat, oder?

              Vielen Dank

              Liebe Grüße,
              Sniky
              Zuletzt geändert von wahsaga; 11.10.2010, 15:04. Grund: Beitrag wiederhergestellt

              Kommentar


              • #8
                und ich glaube da wäre es dann wieder langsamer wenn ich erst überprüfen müsste, wer die ID xx hat, oder?
                Relationale Datenbanken heißen Relationale Datenbanken, weil diese Datenbanken in Relationen "denken". Sie sind darauf spezialisiert genau diese Beziehungen zu verwalten und bei Abfragen zu nutzen.
                Wir werden alle sterben

                Kommentar


                • #9
                  Wäre, müsste, kann mir vostellen, ich glaube ...
                  Aus all dem spricht eine ziemlich große Unkenntnis vom sinnvollen Umgang mit relationalen Datenbanken.
                  Deshalb würde ich vorschlagen, du suchst dir erst mal ein Tutorial/Buch zu der Thematik, und arbeitest das durch.
                  I don't believe in rebirth. Actually, I never did in my whole lives.

                  Kommentar


                  • #10
                    Zitat von wahsaga Beitrag anzeigen
                    Aus all dem spricht eine ziemlich große Unkenntnis vom sinnvollen Umgang mit relationalen Datenbanken.
                    Deshalb würde ich vorschlagen, du suchst dir erst mal ein Tutorial/Buch zu der Thematik, und arbeitest das durch.


                    Tolle Antwort...

                    ich kauf mir ein Buch und höre dann ab sofort auf im Forum zu fragen... Geht ja jetzt auch viel schneller ein 500Seiten großes Buch zu lesen.

                    Hast aber recht, werde ich jetzt machen... Der Beitrag kann dann wieder geschlossen werden.

                    vg, Sniky

                    Kommentar


                    • #11
                      Zitat von Sniky Beitrag anzeigen
                      Tolle Antwort...
                      Ja, ist sie!

                      Ich kann nicht, und will auch gar nicht, mit "jedem" einen kostenlosen Grundlagenkurs durchziehen. Und leider wirst du mich nicht verstehen, wenn du die Grundlagen nicht beherrscht.

                      Oder anders rum:
                      Und wenn es dir zu viel ist ein "500 Seiten Buch" zu lesen, naja, dann könnte programmieren das falsche Hobby für dich sein.
                      Wir werden alle sterben

                      Kommentar


                      • #12
                        @Sniky

                        Bitte NICHT deine Threads löschen! Verwarn!

                        Peter
                        Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
                        Meine Seite

                        Kommentar


                        • #13
                          Zitat von Sniky Beitrag anzeigen
                          Hast aber recht, werde ich jetzt machen... Der Beitrag kann dann wieder geschlossen werden.
                          und dann brauchst du auch gar nicht wieder kommen. wer hier threads entstellt und sich auch noch aufregt, dass ihm keiner hilft, der hat so einiges nicht kapiert. adios.
                          [FONT="Helvetica"]twitter.com/unset[/FONT]

                          Shitstorm Podcast – Wöchentliches Auskotzen

                          Kommentar

                          Lädt...
                          X