DB-Struktur für eine Statistik mit >2Mio Einträgen

[charlie71]

Guten Tag allerseits,

ich bins mal wieder Bin mit meinem AdServer Projekt wieder ein gutes Stück weiter, nun stehe ich vor der Aufgabe eine MySQL Datenbank Struktur für die Werbemittelstatistik zu erstellen.

Voraussetzungen an die Statistik:
-> Tages, Monats und Jahres Statistik
-> Sortierung nach einzelnen Werbemitteln
-> Sortierung nach Klicks und Views

Struktur der Tabelle:
Tag | Werbemittel-ID | Klicks Heute | Views Heute | [...] | Klicks Jahr | Views Jahr

Für jeden Tag wird eine neue Zeile erstellt.

Habe mir folgende Möglichkeiten überlegt:
Eine Tabelle für die komplette Statistik und eine temporäre Tabelle. Beim Aufruf der Werbemittel wird erst in die Temporäre Tabelle geschrieben. In regelmäßigen Abständen übernimmt die komplette Statistik die Daten aus der temporären Tabelle und die temporäre wird geleert.

Würde gerne mal die Meinung einiger "Cracks" hören, bin noch nicht so erfahren in dem Thema und deswegen würde ich mir schon gerne mal eine Meinung einholen. Falls dieser Ansatz nicht so gut ist, wie würdet ihr das ganze regeln? Es geht halt um ein professionelles AdServer System mit dem mehrere Millionen Werbemittel pro Tag ausgeliefert werden sollen, da zählt jeder Funken Perfomance.

Gruß und Vielen Dank für eventuelle Lösungsansätze!

 

[Dunas]

Ich würde das eher in den Db-Bereich packen.

Wenn jemand deine Statistik aufruft, musst du bei deiner jetzigen Planung zwei Tabellen abfragen. Dabei hast du auch keinen gemeinsamen Index.
Ich sehe keinen Vorteil in der Aufteilung in eine feste und eine temporäre Tabelle.
Bei Schreibzugriffe ist die Tabellengröße egal. Es wird hinten was angehangen und die Indexe werden aktuallisiert.

Nagut da könnte ein kleiner Vorteil liegen, du verlegst das Kopieren, aus der temporären Tabelle in die feste Tabelle, in die Nachtstunden bzw. in eine Zeit mit geringerer Systembelastung. So bremmst das aktuallisieren der Indexe deinen Server nicht so extrem aus.

Mal schauen was die Anderen sagen.

EDIT:
Die Spalten Klicks_Jahr und Views_Jahr würde ich in eine andere Tabelle packen.
Da dürfte eine Tabelle für alle Benutzer deines Ad-Systems reichen. Da Klicks_Jahr und Views_Jahr sich ja nur einmal am Tag geupdatet und nur eine Summierung der Klicks bzw. Views für jedes Werbemittel ist.

EDIT 2:
Für Klicks_Monat und Views_Monat gillt das selbe
Ich hoffe das ist einigermaßen verständlich.

 

[dbwizard]

Struktur der Tabelle:
Tag | Werbemittel-ID | Klicks Heute | Views Heute | [...] | Klicks Jahr | Views Jahr

- Klicks Jahr / View Jahr sind ja aufsummierte Werte, die sich jeden Tag ändern. Würde ich im Prinzip gar nicht abspeichern.
- Im Prinzip benötigst du 2 Tabellen : Die Werbemittel, sowie die Transaktionstabelle für die Klick / Werbemittel pro Zeiteinheit

Habe mir folgende Möglichkeiten überlegt:
Eine Tabelle für die komplette Statistik und eine temporäre Tabelle. Beim Aufruf der Werbemittel wird erst in die Temporäre Tabelle geschrieben. In regelmäßigen Abständen übernimmt die komplette Statistik die Daten aus der temporären Tabelle und die temporäre wird geleert.

- Das ist nix. Warum beim Aufruf zuerst im temporäre Tabellen schreiben ? Das frisst Ressourcen und skalliert überhaupt nicht.

.... da zählt jeder Funken Perfomance.

- Wie wärs dann mit Oracle

Du konntest dir auch überlegen, das ganze in ein Star-Schema zu transformieren, das wäre eigentlich ideal für die Auswertungen, welche du fahren willst. Google mal nach Star-Schema (oder http://en.wikipedia.org/wiki/Star_schema ) und guck dir das mal an. Ich bin eigentlich ein Oracle - Mensch, mitthilfe einer geschickten Partitionierung der Transaktionstabelle sowie Analytics wäre das ein relativ einfacher Job und auch hochperformant, kenne halt MYSQL nicht so gut....