Da meinem persönlichen Eindruck zu Folge das WordPress-Plugin semmelstatz zu sehr aus dem Ruder läuft und nach drei Tagen und knapp über 300 Besuchern bereits 400kb in der Datenbank belegt hatte, habe ich es wieder abgeschaltet. Der „freundliche” Support erwies sich dabei auch nur als suboptimal zu Problemlösung.
Im Grunde ist es eigentlich schade, auf das Plugin zu verzichten, da die Statistiken aussagekräftig waren und vor allem die Integration in WordPress mir sehr gut gefallen hat. Was ich aber nicht mag ist die fehlende Kontrollmöglichkeit in Bezug auf den Speicherbedarf der Daten.
Meines Erachtens sollte ein Statistiktool eine Grundregeln im Umgang mit der Datenbank beachten, um schonend mit den Ressourcen umzugehen. Zunächst einmal gibt es nicht eine Tabelle für alles, sondern mindestens fünf: fortlaufende-daten, täglich, wöchentlich, monatlich und überlauf_daten.
In der Tabelle fortlaufende-daten werden die Daten wie bisher bei semmelstatz gespeichert. Am Ende eines Tages werden die kumulierten Daten (Visits, Hits und die Top 10 Listen) in die Tabelle täglich geschrieben. Nach einer Woche gibt es eine Zusammenfassung der täglichen Daten für die Tabelle wöchentlich und so weiter.
Für jede Tabelle lässt sich einstellen, wie lange die jeweiligen Daten gespeichert werden soll. Wird der Zeitraum überschritten, wird von hinten gelöscht. Da erfahrungsgemäß bei den fortlaufenden Daten am meisten Speicherbedarf anfällt, lässt sich für diese Tabelle noch explizit eine maximale Speichergröße festlegen. Wird diese überschritten, werden die Daten von hinten gelöscht und ein Zwischenergebnis für die Tagessstatistik in der Tabelle überlauf_daten gespeichert.
Ideal wäre noch eine Exportfunktion für die Tabellen, um die Daten als CSV speichern und mit anderen Tools wie zum Beispiel Crystal Reports auswerten zu können.
Ein Nachteil allerdings bleibt bestehen: Ein solches Plugin würde auch bei jedem Aufruf einer WordPress-Seite schreibend auf die Datenbank zugreifen. Bei hoher Besucherzahl wirkt sich das unter Umständen auf die Gesamtperformance aus. Nicht ohne Grund verwenden wohl auch deshalb viele Bloger lieber einen JavaScript-Counter eines externen Anbieters, was im Zweifelsfall immer die sicherer Wahl ist.
13 Kommentare
Also die Daten gehören schon in eine Tabelle. Die Daten in unterschiedlichen Tabellen zu speichern macht keinen Sinn. Da wiederspricht eigentlich den Regeln einer relationalen Datenbank.
Das ‚Problem‘ mit den großen Datenmengen ist eigentlich kein Problem. Das kann nur zu einem Problem werden wenn die Keys schlecht gewählt sind.
Wenn man nur einen bestimmten Zeitbereich, also die letzten 3 Monate oder so, haben will ist es ja eigentlich kein wirkliches Problem. Man köntne da über einen Cronjob (entweder direkt auf dem Server oder via WP-Cronm) ja einfach ein SQL Delete einbauen das alles ältere löscht. Da die Daten ja nur in einer Tabelle liegen ja eine denkbar einfache Sache.
Eben nicht. Die Daten gehören meiner Auffassung nach in unterschiedliche Tabellen. Der Sinn dabei ist, Daten nach ihrer Kumulierung bewusst extra zu speichern. Das von mir skizzierte Modell ist nicht frei erfunden, sondern wird in ähnlicher Form von Nortel Networks zu Speicherung von Anruferdaten im CallCenter verwendet. Mit der Datenbank habe ich mich ganze fünf Jahre beschäftigt auch mit ihrer Auswertung über Crystel Reports.
Was mir bei den Einstellungsoptionen der DB gefallen hat, war die Vorgabe einer maximalen Speicherdauer und eben die Möglichkeit, den Systemhunger gezielt bremsen zu können.
Bei semmelstatz wurde, wie ich erst durch eine Rückfrage erfahren habe, zumindest in der bis gestern aktuellen Version 2.2 die Datenbank nach dem Löschvorgang nicht optimiert. Da ich ja keine virtuellen oder dezidierten wie auch immer Server habe, versuche ich, so schonend wie möglich mit den mir zur Verfügung stehenden Ressourcen umzugehen.
Du kannst aber auch gerne mal das Plugin bei semmel bei dir installieren und schauen, welche Datenmenge es erzeugt.
Also die Speicherung in einer Gesamttabelle und dann zusätzlich in einer Tages, Wochen etc. Tabelle wiederspricht ganz klar der zweiten Normalform und erschwert auch viele Abfragen. Das man die Normalisierung einer Datenbank nciht bis zur letzten Form durchzieht in der Praxis ist klar, aber die Daten nach einem solchen Muster abzuspeichern macht keinen Sinn.
Berechnete Werte die sich aus anderen gespeicherten Werten ergeben ist keine Lösung.
Ich verstehe gar nicht wo das Problem für dich ist wenn alle Daten in einer Tabelle liegen? Suchvorgänge dauern da nicht länger, du kannst flexible Zeiträume auswerten.
Dann bzgl. Optimierung nach löschen. Du müsstest ja nach jedem Kopiervorgang, also wenn Daten aus der Tagestabelle rausfliegen ja auch die Tabelle optimieren, da bei einem Delete from where Tage = gestern ja auch der Schlüsselindex nicht neuaufgebaut wird. Dann hast du also zig zusätzliche Kopier und löschvorgänge nur um die Sachen dann in die richtigen Tabellen zu schieben. Das kann nicht der Weisheit letzter Schuss sein. Das man sowas so machen kann und das es sowas bei vielen Firmen gibt sagt nichts darüber aus ob es pfiffig ist. Es ist einfach nur reduntante Datenhaltung. Performance Gewinne und Platzersparnis gibt es da an keiner Stelle. Aber dafür jede Menge Gefahren.
Also, noch mal im Detail: Die zweite Normalform besagt, daß immer dann sich sich Inhalte in einer Spalte wiederholen, die Tabellen in mehrer Teiltabellen zerlegt werden müssen.
Mein Modell erschwert nicht die Abfrage, da ich für eine Tagesübersicht oder Wochenübersicht nicht alle Daten brauche, sondern nur die Summe. Diese steht dann in einer Zeile der jeweiligen Tabelle
Über die Aufteilung die zusätzliche Tabellen Woche und Monat kann man sicher noch mal nachdenken. Es würde vermutlich ausreichen, wenn man die Summe in die Tagestabelle schreibt und entsprechende auswertet. Somit gäbe es nur einen Optimierungsvorgang, wenn am Ende eines Tages die fortlaufende Tabelle von hinten abgeschnitten wird. Auf die Tabelle mit der Zwischenspeicherung lässt kann auch verzichtet werden, so daß aus meiner Sicht zwei Tabellen über bleiben. Diese halte ich aber unbedingt für notwendig.
Eine Redundanz der Daten sehe ich nicht, da die Felder in der Tabelle für die Tagesstatistik auch anders sind.
Berechnete Felder sind redundant. Werte werden nur gespeichert wenn sie nicht mehr neuberechnet werden können. Es wäre also für eine Archivfunktion ein angebrachtes Mittel das man nur zum ansehen noch die alten Summenwerte hat, wenn die Logbucheinträge selber schon gelöscht worden sind.
Aber so die Summen für die vorhandenen Zugriffe zu speichern macht keinen Sinn. Jedes Mal wenn ein neuer Zugriff auf die Seite geschieht müsste dieser ja einmal in die Logbuchtabelle geschrieben werden und dann müssten die Summentabelle aktualisiert werden. Schreibvorgänge kosten immer Zeit da auch die Indextabellen aktualisiert werden. Wenn das Script dann aus was für gründen auch immer dann mal nicht zuende läuft steht der Wert evtl. nur noch in der ersten Tabelle, die Summentabelle wurde aber nicht aktualisiert. Man kann sich jetzt darüber streiten ob das für einen Blogcounter jetzt sehr tragisch wäre, aber darum geht es ja nicht.
Also für Archivwerte vom vorletzten Monat ist dein Tabellensystem sicherlich okay, aber nciht für die aktuellen Werte.
Der erste Absatz trifft genau das, was ich meine. Nur zur Achivierung. Die alten Logbucheinträge sollten nach 24 Stunden gelöscht werden. Zum Beispiel interessieren mich nach 24 Stunden nicht mehr alle Suchbebriffe, sondern die Top-10. Die Summe wird erst nach 24 Stunden geschriben, also nicht bei jedem Zugriff.
Das Grundproblem, was wir bisher nur am Rande gestreift haben, bleibt folgends: Wie sinnvoll ist es tatsächlich, bei jedem Seitenaufruf schreibend auf die Datenbank zu zugreifen (so wie es semmelstatz macht)?
Okay, wenn man nach einem Tag schon archivieren will, dann könnte man es so machen. Ich weiß ja jetzt nicht was dein Webspace Angebot so hergibt an Speicherplatz, aber so 3 Monate würde ich schon mitprotokollieren. Wenn du Bedarf an mehr Speicherplatz hast kann ich dir gerne eine Datenbank geben die du mit nen paar MB mehr füllen kannst.
Das Problem mit den Schreibzugriffen kann man nicht wirklich lösen, es sei denn man will die Aufrufe zuerst in eine Textdatei schreiben und diese nur periodisch alle x Stunden einlesen. Dann kann man die ganze WordPress-Plugin Geschichte aber auch ganz sein lassen und nur das Apachelogfile nutzen das der Webserver im Normalfall einem ja schreibt.
Da ein einzelner Schreibzugriff aber nur minimal Zeit beansprucht, wir sind da ja im hundertstel Sekunden Bereich, muss man sich da meiner Meinung nach keine wirklichen Gedanken drüber machen. Wenn man jetzt eine richtig stark frequentierte Seite hat mit 100 Zugriffe pro Minute oder so, kann man sich einen dedizierten Server der 100 inserts locker nebenher schafft (die sind dann ja auch delayed im Normalfall und werden in einem Rutsch abgefertigt) eigentlich leisten. Die 60 Euro im Monat sollte man locker durch Werbung reinbekommen.
Ich persönlich würde aber eh immer auf die Apache Logs ausweichen, weil der ja eh alles mitprotokolliert. Der Zauber ist flugs eingelesen und man kann schicke Abfragen über die Datenbank laufen lassen.
Der Punkt war, wie einleitende im Artikel beschrieben, daß ich nach nur drei Tagen schon bei 400Kb Speicherverbrauch lag. Das war mir schon zu viel. Die Idee, die vorhandenen Logs auszulesen, wäre ein brauchbare Ansatz. Das müsste irgendwie auch als WordPress-Plugin gehen.
Was mich aber nach wie vor wurmt: Was wir hier führen, ist ein sachliche, ruhige Diskussion. Eine solche hatte ich mir auch mit dem Autor des Plugins erwartet. Aber es gibt halt Tage, an denen ist eine Entäuschung unvermeidbar.
Îch hab mir das Teil jetzt mal installiert. Da ich jedoch von diesem Rechner aus nicht an meinen MySQL drankomme, werde ich mir die Datenbank Struktur mal heute abend in Ruhe ansehen.
och, also so schlimm ist das bei mir nicht mit semmelstatz. ich hab etwa 50 Besucher/Tag und ich hab jetzt eine statistik von 45 tagen. die ist bei mir 1mb groß. kann ich mit leben. ist zwar groß, aber ich lösch alte daten auch öfter mal damit sie nicht noch größer wird.
aber ich hab mir auch schon gedacht, google analytics stattdessen zu verwenden. aber da gibts ja (noch) rechtliche probleme.
@LeSven: Ich bin mal auf deine Erfahrungen damit gespannt.
@Killercup: Laut Plugin hatte ich 800 bis 900 (wobei SiteMeter nur 350 gezählt hat) pro Tag. Das ist wohl einfach zu viel – für das Plugin, nicht für mich, denn ich würde mich über noch mehr Besucher freuen.
Ich habe hier ein kleines Plugin für Semmelstatz programmiert, das die Datenflut für die Logs etwas einschränkt. Damit bleiben in der Statistik nur eine festgelegte Anzahl an Tagen erhalten. Ältere Einträge werden automatisch gelöscht…
http://www.net-tec.biz/29,semmelstatz-delete-01/
Das hilft gegen zu grosse Datenbank-Tabellen. :-)
Grüße, Jens!
@Jens: Schon gefunden :-) Mich würde noch interessieren, auf welche Teile du von WP-Cron zugreifst, da ich nicht dass ganze Cron-Plugin installieren möchte.