Performance bei ständigen INSERTs & UPDATEs

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

  • Performance bei ständigen INSERTs & UPDATEs

    Hallöchen.

    Ich würde gerne von einigen Leuten, die sich gut mit MySQL auskennen hören, wie sie folgendes Problem lösen würden:

    Ich schreibe Momentan ein Counter Projekt von PERL nach PHP um. Das ganze ist ab dato auch MySQL basiert. Man kann einen Counter auf seiner webseite einbinden. Dieser schreibt dann die Besucherzahlen in die Datenbank zu jedem Counter an jedem Tag. Sprich für jeden Tag wird ein neuer Eintrag in der DB erstellt. Zusätzlich ist eine Reloadsperre per IP integriert. Bei gut 2 Mio. Countern kann man sich vorstellen, was wohl für eine Last auf dem Server herrscht.

    Wie würdet ihr die Datenbank formen, damit das ganze ohne Probleme laufen würde.

    Nochmal die wichtigsten Punkte im Überblick:

    - Zu jedem Tag wird zu jedem Counter ein neuer Eintrag in der DB erstellt
    - Jeder Tag wird je nach Anzahl der User upgedatet (sprich, sollte ein User an diesem Tag eine bestimmte Seite aufrufen, wird der Counter um eins erhöht)
    - Eine Reloadsperre ist integriert, somit muss die DB immer erst durchsucht werden, ob dieser User in den letzten 2 Stunden schon auf der Seite war.
    - Man kann sich eine Statistik zu jedem Monat ausgeben lassen

    Mit MyISAM ist das ganze undenkbar. Mit INNO-DB schon wieder anders, jedoch ist das mit den Backups dann so eine Sache, da alles in einer Datei steht und das wollen wir absolut nicht.

    Wie löst man das ganze jetzt am besten und wie sollte man die Datenbank jetzt am besten aufbauen?
    Zuletzt geändert von Tiger_XT; 02.10.2006, 12:58.

  • #2
    warum nciht einfach in eine tabelle alles nacheinander schreiben. für jeden abruf ein eintrag mit datum, ip, seite, usw. die tabelle hat logischerweise keinen index.

    stündlich oder täglich liest du dir die werte aus und schreibst sie entsprechend in eine neue tabelle, aus der die statistiken erzeugt werden.
    INFO: Erst suchen, dann posten![color=red] | [/color]MANUAL(s): PHP | MySQL | HTML/JS/CSS[color=red] | [/color]NICE: GNOME Do | TESTS: Gästebuch[color=red] | [/color]IM: Jabber.org |


    Kommentar


    • #3
      Wie lief das denn mit Perl? Auch schon mit einer DB? Dann kannst du es erstmal 1 zu 1 übernehmen und dann schauen, wo es eng wird.

      Kommentar


      • #4
        Original geschrieben von Abraxax
        warum nciht einfach in eine tabelle alles nacheinander schreiben. für jeden abruf ein eintrag mit datum, ip, seite, usw. die tabelle hat logischerweise keinen index.

        stündlich oder täglich liest du dir die werte aus und schreibst sie entsprechend in eine neue tabelle, aus der die statistiken erzeugt werden.
        Meiner Meinung nach sollte man die Statistiken über separate Tabellen anfertigen, wie es Abraxax vorschlägt. Da aus diesen Tabellen lediglich gelesen wird, könnten sie auch vom Typ MyISAM sein und die Backups sind gesichert.

        Die aktuellen Daten würde ich dennoch nicht in einer Tabelle speichern. So wie es Abraxax vorschlägt, hätte ich dann ja für jeden Tag zig Einträge (pro Counter). Das würde auch mit der Reload-Geschichte Ärger geben, wenn man mal etwas genauer darüber nachdenkt.

        Wichtig ist jedoch dass du durch die Trennung für die aktuellen Tagesdaten eine andere Storage-Engine verwenden kannst. Das ist, denke ich, momentan ja noch dein größtes Problem.
        Vielleicht kannst du dann sogar eine Storage-Enginge verwenden, die die Daten nur im Speicher hält (Heap)?

        Kommentar

        Lädt...
        X