Wir betreiben einen angepassten OpenX Ad Server auf einer MySQL Datenbank, die ca. 1 Million Klicks pro Tag. Wir müssen all diese Klickinformationen speichern und darauf basierende Statistiken anzeigen.
Im Moment werden alle Klickinformationen alle zwei Tage gesammelt und die spezifischen Klickinformationen werden gelöscht. Wir möchten unseren Affiliates jedoch eine neue Funktion zur Verfügung stellen, die es ihnen ermöglicht, eine dynamische Tracking-ID (TID) festzulegen und ihre darauf basierenden Klicks und Conversions nachzuverfolgen.
Das Problem ist also, dass unsere Klick-Tabelle um mindestens eine Million Einträge pro Tag erweitert wird. Wir müssen in der Lage sein, diese Tabelle zu durchsuchen und alle Klicks für einen Nutzer für einen bestimmten Zeitraum gruppiert anzuzeigen durch die TID, die ich oben erwähnt habe, oder durch die TID suchen.
Ich habe mir die MySQL-Partitionierung angeschaut und es scheint eine gute Lösung zu sein, aber ich bin mir nicht sicher, ob es auch in einer HUGE-Datenbank gut funktioniert (vielleicht Milliarden von Einträgen).
Was wäre Ihrer Meinung nach der richtige Ansatz für dieses Problem?
BEARBEITEN:
Ausgehend von Ihren Antworten denke ich jetzt an eine gemischte Lösung.
Wir haben bereits eine "LIVE" -Tabelle, aus der die Einträge gelöscht werden, wenn die Klicks zur Wartungszeit aggregiert werden, was in etwa so aussieht:
Tabelle: klickt
Zuschauer_ID | ... | Datum_Zeit | affiliate_id | ... | tid
(Ich habe die Spalten übersprungen, die an dieser Stelle unwichtig sind)
Zur Wartungszeit kann ich alles in eine andere monatliche Tabelle verschieben, die fast identisch aussieht. Sagen Sie Tabelle: clicks_2012_11 , die Indizes für Datum_Zeit , Affiliate-ID enthält und tid und wird von affiliate_id partitioniert.
Wenn ein Affiliate nun seine Statistiken der letzten zwei Monate sehen möchte, muss ich in die Tabelle: clicks_2012_10 und die Tabelle: clicks_2012_11 schauen (Ich werde den Zeitbereich auf maximal 2 Monate beschränken). Da ich die Tabellen durch affiliate_id partitioniert habe, werden nur die benötigten Partitionen aus den 2 Tabellen gesucht und ich kann jetzt alle TIDs auflisten, die in den letzten 2 Monaten irgendeine Aktivität hatten.
Was halten Sie von diesem Ansatz? Gibt es offensichtliche Probleme? Übertreibe ich Dinge ohne einen guten Grund?
Es gibt nichts, was großen (sogar "riesigen") Tabellen innewohnt, die MySQL zum Scheitern bringen. Große Tabellen sind meistens ein Problem in Bezug auf:
Sie müssen alle diese Punkte ansprechen.
Die Partitionierung ist hauptsächlich für die Verwaltung von Massendaten nützlich, wie das Löschen ganzer Partitionen. Es ist sicherlich keine bewährte Vorgehensweise, große Tabellen standardmäßig nur für eine Spalte zu partitionieren. Partitionierung wird immer aus einem bestimmten Grund eingeführt.
Tags und Links mysql partitioning openx