Wie soll ich extrem große Mengen von Verkehrsdaten für den einfachen Abruf?

Question

für ein Verkehrsabrechnungssystem I große Mengen von Datensätzen über Internet-Pakete über unser Gateway-Router gesendet speichern müssen (mit Zeitstempel, Benutzer-ID, Ziel oder Quelle ip, Anzahl von Bytes, usw.).

hat diese Daten für einige Zeit gelagert werden soll, zumindest ein paar Tage. Einfache Wiederherstellung sollte auch möglich sein.

Was ist ein guter Weg, dies zu tun? Ich habe bereits einige Ideen:

• Erstellen Sie eine Datei für jeden Benutzer und Tag und jeden Datensatz anhängen.

  • . Vorteil: Es ist wahrscheinlich sehr schnell, und Daten ist einfach eine konsistente Datei Layout gegeben finden
  • Nachteil: Es ist nicht leicht möglich, beispielsweise zu sehen, alle UDP-Datenverkehr aller Nutzer.

• Verwenden Sie eine Datenbank

  • Vorteil: Es ist sehr einfach, bestimmte Daten mit der richtigen SQL-Abfrage zu finden.
  • Nachteil:. Ich bin sicher nicht, wenn es ein Datenbank-Engine, die effizient eine Tabelle mit möglicherweise umgehen können Hunderte von Millionen Datensätze

• Vielleicht ist es möglich, die beiden Ansätze zu kombinieren: Mit einer SQLite-Datenbank-Datei für jeden Benutzer.

  • Vorteil: Es wäre leicht, Informationen für einen Benutzer unter Verwendung von SQL-Abfragen auf seiner Datei zu erhalten.
  • Nachteil:. Gesamt Informationen erhalten würde immer noch schwierig sein,

Aber vielleicht jemand anderes hat eine sehr gute Idee?

Vielen Dank im Voraus.

Answer 1

Zuerst get The Data Warehouse Toolkit bevor Sie etwas tun.

Sie sind ein Data-Warehousing-Job, müssen Sie es wie ein Data-Warehousing-Job zu bewältigen. Sie müssen für diese Art der Sache auf den richtigen Design-Muster lesen.

[Anmerkung Data Warehouse bedeutet nicht verrückt groß oder teuer oder komplex. Es bedeutet, Star-Schema und intelligente Art und Weise große Datenmengen zu verarbeiten, die nie aktualisiert wird.]

1. SQL-Datenbanken sind langsam, aber das langsam ist gut für die flexible Abruf.

2. Das Dateisystem ist schnell. Es ist eine schreckliche Sache für die Aktualisierung, aber du bist nicht aktualisiert wird, sind Sie nur zu akkumulieren.

Ein typischer DW Ansatz dafür ist, dies zu tun.

1. Definieren Sie das "Stern-Schema" für Ihre Daten. Die meßbaren Daten und die Attribute ( „Dimensionen“) dieser Tatsachen. Ihr Fakt erscheinen # Bytes zu sein. Alles andere (Adresse, Zeitstempel, Benutzer-ID, etc.) ist eine Dimension dieser Tatsache.

2. Erstellen Sie die dreidimensionalen Daten in einer Master-Dimension-Datenbank. Es ist relativ klein (IP-Adressen, Benutzer, ein Datum Dimension, etc.) Jede Dimension hat alle Attribute, die Sie jemals wissen wollen könnten. Diese wächst, sind die Menschen immer Attribute Dimensionen hinzufügen.

3. Erstellen Sie eine „Last“ Prozess, der Ihre Protokolle nimmt, löst die Dimensionen (Zeiten, Adressen, Benutzer, etc.) und führt die Dimensionsschlüssel in den Maßnahmen (Anzahl der Bytes). Dies kann die Dimension aktualisieren, um einen neuen Benutzer oder eine neue Adresse hinzuzufügen. Im Allgemeinen Sie lesen Tatsache Reihen, tun Lookups und Schreiben Tatsache Zeilen, die alle die richtige haben FK die mit ihnen verbunden sind.

4. Speicher dieser Last Dateien auf dem Datenträger. Diese Dateien werden nicht aktualisiert. Sie reichern sich gerade. Verwenden Sie eine einfache Schreibweise, wie CSV, so dass Sie sie leicht Massenladen.

Wenn jemand will Analyse tun, was ihnen einen Data Mart zu bauen.

Für die IP-Adresse oder den ausgewählten Zeitrahmen oder was auch immer, erhalten alle relevanten Fakten, sowie die zugehörigen Hauptdimensionsdaten und Massenladen ein Datamart.

können Sie tun, um die alle SQL-Abfragen, die Sie auf diesem Markt wollen. Die meisten der Anfragen werden zufallen zu SELECT COUNT(*) und SELECT SUM(*) mit verschiedenen GROUP BY und HAVING und WHERE Klauseln.

Answer 2

ich glaube, die richtige Antwort hängt wirklich von der Definition eines „Datensatz“. Wie Sie in Ihrer Frage erwähnen sind Speichern Sie einzelne Sätze von Informationen für jeden Datensatz; Zeitstempel, Benutzer-ID, Ziel-IP, Quell-IP, die Anzahl von Bytes, etc ..

SQL Server ist durchaus in der Lage, diese Art von Datenspeichergabe mit Hunderten von Millionen von Datensätzen ohne wirkliche Schwierigkeiten. diese Art der Protokollierung gewährt wird einige gute Hardware benötigen, es zu handhaben, aber es sollte nicht zu komplex sein.

Jede andere Lösung meiner Meinung nach wird sehr schwer machen berichtet und von den Klängen der es, das ist eine wichtige Voraussetzung.

Answer 3

So können Sie in einem der Fälle, in denen Sie viel mehr Schreibaktivität als zu lesen, Sie möchten, dass Ihre schreibt man nicht blockieren, und Sie möchten Ihre liest „ziemlich schnell“ zu sein, aber nicht kritisch. Es ist ein typischer Anwendungsfall Business Intelligence.

Sie sollten wahrscheinlich eine Datenbank verwenden und speichern Sie Ihre Daten in als „denormalized“ Schema komplexe Joins und mehrere Einsätze für jeden Datensatz zu vermeiden. Denken Sie an Ihre Tabelle als eine große Protokolldatei.

In diesem Fall einige der „neuen und fancy“ NoSQL-Datenbanken sind wahrscheinlich das, was Sie suchen: Sie bieten entspannte ACID Einschränkungen, die Sie nicht schrecklich hier (bei Crash dagegen sollten Sie die letzte verlieren kann Linien Ihres log), aber sie führen viel besser für das Einsetzen, weil sie nicht bei jeder Transaktion sync Journale auf der Festplatte haben.