Hallo,

ich schreibe gerade an einem Bannertausch script, hierbei stellt sich mir das Problem der Datenbank optimierung! Das heißt ich möchte ja jeden view und klick speichern damit die angemeldeten user eine statistik bekommen können. Und das ja am besten noch für jede Stunde! Doch wenn man die daten so abspecihern würde bekämme man ja schnell millionen von datensätzen zusammen, bei einem solchen Netztwerk!

Jetzt meine frage gibt es schon tutorial oder artikel die sich mit diesem problem befassen oder habt ihr ideen wie die ungefähre strucktur in einem solchen netzwerk ausehen muss damit man nicht unmengen an daten hat und das laden ewig dauert!

Ich sag mal eine stunden auswertung der views und klicks ist nicht unbedingt erforderlich!

MFG

Also möglichkeit wäre, eine tabelle mit id des Banners und halt 24 zusätzliche Spalten für die 24 Stunden, oder willst du für jeden Tag immer rückblickend auch noch die einzelnen Stunde auswerten können?

-> Nein mach das nicht.

Ich würde eine Tabelle machen, bei dem jeder User geloggt wird:

id (integer) | id_banner (integer) | host (varchar) | views (integer) | time (datetime)

id -> unique / schlüssel
id_banner + host -> unique
id_banner -> index
time -> index

Dann würde ich bei jedem load überprüfen ob es datensätze gibt, welche älter als eine Stunde sind. Falls ja, diese mit einem Insert in eine generellere Tabelle übertragen. Da genau diese einzelnen Klicks so viele Daten verursachen.

Beispiel:
id_banner | hour (varchar -> yy:mm:dd hh) | klicks | views

So hast du eine Klicksperre (z.B. eine stunde, damit ein user nicht mehrmals auf den gleichen banner klicken kann...) und zudem das Volumen der Daten verringert.

danke für eure Antworten!

@madox

so in etwa habe ich mir das auch gedacht aber auch da kommen ja gigantische daten mengen heraus!

weil ich ja folgende unterscheidungen brauche:

- views klicks und pi pro stunde, tag, woche, monat, jahr
- Publisher website id wo der klick herkam
- Advertiser anzeige id

und das kann ja denn schnell große datenmengen ausmachen besonders da man ja jeden klick usw. pro stunde zurück verfolgen können soll.

Wie viele datensätze kann den eine mysql Tabelle im schnitt so beherbergen damit man normale querys noch in einer akzeptablen zeit erhält? (mal abgesehen von der hardware)


MFG

Also, ich habe es in etwa über eine Kombination von beiden Methoden gemacht...


@Borsti:

Nun, wenn Du es so machen möchtest, wie Joel Janser es Dir vorschlägt, solltest Du (nach Möglichkeit) besser mit Merge-Tabellen arbeiten (dies musst jedoch Du entscheiden). Sprich für den ersten Monat lässt Du die Log-Daten in Tabelle "log_2006_01" schreiben, und im nächsten Monat in "log_2006_02". Damit werden die Tabellen nicht zu all zu groß, und es ist unwahrscheinlicher, dass die Preformence später zu sehr in Keller geht. Um Platz zu sparen kannst Du dann auch die Tabellen aus dem abgeschlossenden Monat komprimieren. [1]
Um diese Tabellen zusammen fassen zu können, kann dann eine Merge-Tabelle angelegt werden.

Voraussetzungen für diese Methode sind:

• Alle Tabellen müssen die gleiche Definition aufweisen.
• Alle Tabellen müssen vom Typ MyISAM sein.
• Vor MySQL 4.1.1 müssen alle Tabellen in der gleichen Datenbank liegen, ab Version 4.1.1 gibt es diese Beschränkung nicht mehr.

Beispiel (SQL-Syntax):

Die Option INSERT METHOD kann drei Werte haben NO, FIRST und LAST.

• NO → Es ist kein Einfügen über die Merge-Tabelle erlaubt (Standard-Wert).
• FIRST → Daten werden immer in die erste angebende Tabelle geschrieben (siehe UNION).
• LAST → Daten werden immer in die letzte Angebende Tabelle geschrieben (siehe UNION).

Einige Beschränkungen weisen die Merge-Tabellen jedoch auf:

• REPLACE-Queries funktionieren nicht.
• AUTO_IMCREMENT-Spalten werden bei dem Einfügen über die Merge-Tabelle nicht aktualisiert.
• DROP TABLE log_2006 löscht nur die Merge-Tabelle.

MfG Sascha Ahlers

[1] Nach der Komprimierung sind keine schreibenden Zugriffe mehr möglich, dafür müsste die Tabelle erst wieder dekomprimiert werden. Auch müssen die zu komprimierenden Tabellen vorher aus der Merge-Tabelle herausgenommen werden, nach abgeschlossenden Komprimierung können diese dann wieder hinzugefügt werden.

Vielen dank!

Das ist ja echt eine geniale idee
Das kann man ja wunderbar dynamisch machen.
Und man hat dann ja wirklich alle daten schon in einzelne Segmente (Monat) aufgeteilt.

Das ganze könnte man ja auch ohne Merge Tabelle machen oder?
Trotzdem, kennst du vieleicht ein tutorial oder artikel der merge Tabellen ausführlich erklärt!

Also vielen, vielen dank der tip war das was ich gesucht habe. Da ist die nacht ja heute gerettet und kann zum programmieren genutzt werden.

MFG

Nein, ich kenne leider keine Tutorials oder Artikel zu dem Thema, da ich mich selber dort eher auf meine Beiden MySQL-Bücher verlasse oder der MySQL-Dokumentation.
Alles andere habe ich über die Jahre zuvor in erlernt, hauptsächlich dadurch, weil ich mich für Funktionsabläufe von Anwendungen interessiert habe.

Theoretisch kann man es auch ohne eine Merge-Tabelle machen, aber wenn man eine Übersicht über ein Jahr erstellen möchte, ist eine Merge-Tabelle außerordentlich hilfreich dabei.



MfG Sascha Ahlers

Schade auch, dann wird man wohl selber googlen dürfen.

Mann kann doch dann die abfrage per "JOIN" machen oder habe ich da jetzt einen denk fehler?



So bin dann erstmal in den federn!
Bis morgen!

Ich mein nicht. JOIN ist doch eher dafür gedacht um Tabellen untereinander zu verknüfen, um darauß einen kompletten Datensatz zu bilden. Ich denke aber nicht, dass es dafür geeignet ist mehrere Tabellen nach einzelnen Datensätzen abzufragen. Dazu müssten einzelne Abfragen erstellt werden, und über die Anwendung entsprechend zusammengefügt werden (, wenn keine Merge-Tabelle benutzt wird).



MfG Sascha Ahlers

Hi,

nach gründlicher recherche im inet muss ich die recht geben.

Werde dann wohl merge tabellen nutzen. Nach bisherigem lesen scheinen diese ja auch recht bequem zu erstellen und verwalten sein.

Also wenn es probleme gibt dann melde ich mich wieder ansonsten, danke euch allen für euere hilfe! Bin mir ein ganzes stück klarer über die strucktur geworden.

MFG