Datenbankarchitektur für Millionen neuer Zeilen pro Tag

Question

Ich muss einen speziell entwickelten Webanalysedienst für eine große Anzahl von Websites implementieren. Die wichtigsten Einrichtungen sind hier:

• Webseite
• Besucher

Jeder einzigartige Besucher eine einzelne Zeile haben in der Datenbank mit Informationen wie Zielseite, Tageszeit, Betriebssystem, Browser, Referrer haben , IP, usw.

ich brauche aggregierte Abfragen dieser Datenbank wie ‚COUNT alle Besucher, die Windows als Betriebssystem und kam von Bing.com haben‘ zu tun

Ich habe Hunderte von Websites zu verfolgen und die Anzahl der Besucher für diese Websites reichen von ein paar hundert pro Tag bis zu wenigen Millionen pro Tag. Insgesamt erwarte ich, dass diese Datenbank um etwa eine Million Zeilen pro Tag wächst.

Meine Fragen sind:

1) Ist MySQL eine gute Datenbank für diesen Zweck?

2) Was könnte eine gute Architektur sein? Ich denke daran, für jede Website eine neue Tabelle zu erstellen. Oder starten Sie vielleicht mit einer einzigen Tabelle und erstellen Sie dann eine neue Tabelle (täglich), wenn die Anzahl der Zeilen in einer vorhandenen Tabelle 1 Million überschreitet (ist meine Annahme richtig). Meine einzige Sorge ist, dass, wenn eine Tabelle zu groß wird, die SQL-Abfragen dramatisch langsam werden können. Also, was ist die maximale Anzahl von Zeilen, die ich pro Tabelle speichern sollte? Darüber hinaus gibt es eine Begrenzung für die Anzahl der Tabellen, die MySQL verarbeiten kann.

3) Ist es ratsam, Aggregatabfragen über Millionen von Zeilen durchzuführen? Ich bin bereit, ein paar Sekunden zu warten, um Ergebnisse für solche Abfragen zu erhalten. Ist es eine gute Vorgehensweise oder gibt es eine andere Möglichkeit, Aggregatabfragen durchzuführen?

Auf den Punkt gebracht, Ich versuche, ein Design eine groß angelegte Data-Warehouse Art von Einrichtung, die schwer schreiben wird. Wenn Sie über veröffentlichte Fallstudien oder Berichte Bescheid wissen, wird das großartig!

Answer 1

Einige Vorschläge in einer Datenbank agnostic Mode.

Das einfachste Argument ist die Unterscheidung zwischen leseintensiven und schreibintensiven Tabellen. Wahrscheinlich ist es eine gute Idee, zwei tägliche/wöchentliche Schemata und ein historisches Schema zu erstellen. Die Partitionierung kann entsprechend durchgeführt werden. Man kann sich einen Stapeljob vorstellen, um das Verlaufsschema mit Daten aus dem täglichen/wöchentlichen Schema zu aktualisieren. Im Verlaufsschema können Sie wiederum separate Datentabellen pro Website erstellen (basierend auf dem Datenvolumen).

Wenn alles, was Sie interessiert sind, ist in der Aggregation Statistik allein (die kann nicht wahr sein). Es ist eine gute Idee, eine Übersichtstabellen (monatlich, täglich) zu haben, in denen die Zusammenfassung gespeichert wird wie die Gesamtzahl der Besucher, Besucher wiederholen usw .; und diese Übersichtstabellen müssen am Ende des Tages aktualisiert werden. Dies ermöglicht die sofortige Berechnung von Stats, die darauf warten, dass die History-Datenbank aktualisiert wird.

Answer 2

Wenn Sie größere Datenmengen sprechen, sehen Sie sich MySQL partitioning an. Für diese Tabellen würde eine Partition nach Daten/Zeit sicherlich zur Performance beitragen. Es gibt einen anständigen Artikel über Partitionierung here.

Blick auf die Schaffung von zwei separaten Datenbanken: eine für alle Rohdaten für die Schreibvorgänge mit minimaler Indizierung; eine Sekunde für die Berichterstattung mit den aggregierten Werten; entweder mit einem Batch-Prozess, um die Berichtsdatenbank aus der Rohdaten-Datenbank zu aktualisieren, oder mit Replikation, um dies für Sie zu tun.

EDIT

Wenn Sie mit Ihrer Aggregation Berichten wirklich klug sein wollen, erstellen Sie eine Reihe von Aggregationstabellen ("heute", "Woche to date", "Monat to date", "von Jahr"). Aggregieren von Rohdaten zu "heute" entweder täglich oder in "Echtzeit"; aggregieren von "Tag zu Tag" bis "Woche zu Tag" auf einer nächtlichen Basis; von "Woche to date" auf "Monat to date" auf einer wöchentlichen Basis usw. Wenn Ausführen von Abfragen, join (UNION) die entsprechenden Tabellen für das Datum Bereiche, die Sie interessieren.

EDIT # 2

Anstatt eine Tabelle pro Client, arbeiten wir mit einem Datenbankschema pro Client. Abhängig von der Größe des Clients haben wir möglicherweise mehrere Schemas in einer einzelnen Datenbankinstanz oder eine dedizierte Datenbankinstanz pro Client. Wir verwenden separate Schemas für die Rohdatenerfassung und für die Aggregation/Berichterstellung für jeden Client. Wir betreiben mehrere Datenbankserver und beschränken jeden Server auf eine einzige Datenbankinstanz. Aus Stabilitätsgründen werden Datenbanken über mehrere Server hinweg repliziert und für eine bessere Leistung ausgeglichen.

Answer 3

Sie sollten wirklich Ihren Weg vorwärts testen simuliert Umgebungen so nah wie möglich an die Live-Umgebung, mit "echten gefälschten" Daten (korrektes Format & Länge). Benchmark-Abfragen und Varianten von Tabellenstrukturen. Da Sie MySQL zu kennen scheinen, beginnen Sie dort. Es sollte nicht so lange dauern, ein paar Skripte einzurichten, die Ihre Datenbank mit Abfragen bombardieren. Die Untersuchung der Ergebnisse der Ihre Datenbank mit Ihre Art von Daten helfen Sie erkennen, wo die Engpässe auftreten.

keine Lösung, sondern hoffentlich etwas Hilfe auf dem Weg, viel Glück :)

Answer 4

Sie auf jeden Fall in Betracht ziehen sollten, die Daten von Website über Datenbanken oder Schemata aufgeteilt - das ist nicht nur macht es viel einfacher zu sichern, fallen usw. ein einzelne Site/Client, sondern auch ein großer Teil der Aufwand beseitigt, sicherzustellen, keine Kunden bedeutet es auch einfacher es Codierung usw. alle anderen Kundendaten durch einen Unfall oder schlecht sehen kann, ist Entscheidungen über partitionaing zu machen, die über databae Tabellenebene Partitionierung für Zeit oder Client usw.

auch sagten Sie, dass das Datenvolumen 1 Million Zeilen pro Tag (das ist nicht besonders schwer und erfordert keine große Grunzen Macht loggt/Geschäft, noch in der Tat zu berichten (obwohl, wenn Sie um Mitternacht 500 Berichte generierten würden Sie blockieren können). Wie auch immer, du hast auch gesagt, dass manche Seiten täglich 1 Millionen Besucher haben, also ist es vielleicht zu konservativ?

Schließlich haben Sie nicht gesagt, wenn Sie Echtzeit-Berichterstattung a la chartbeat/opentracker etc. oder zyklische Aktualisierung wie Google Analytics wollen - dies wird einen großen Einfluss auf, was Ihr Speichermodell vom ersten Tag an haben.

M