Speichern von Datenpaketen in einer Datenbank

https://stackoverflow.com/questions/692509

22-08-2019
|

Frage

Problembeschreibung: In meiner Anwendung muß ich den Inhalt von Datenpaketen mit einem bestimmten Format präsentieren. Ein Beispiel:

Ein Beispiel: Jegliche gepackten binäre Daten, zum Beispiel: 4 Byte-Header, 4 Byte (Typ-Codes mit vordefinierten Bedeutungen), dann Quelladresse, Zieladresse und so weiter

Bisher habe ich Implementierungen zu Hause gekocht, die die Daten in einer Binärdatei (feste Satzlänge erlaubt schnelles Nachschlagen) gespeichert, aber mit der Zeit bin ich merkte ich bin eine Art von einer Datenbank zu erfinden. Zum Beispiel, ich bin mein eigenes effizientes binäres Speicherformat für sehr große Datendateien zu implementieren. Ich bin meine eigene Indizierung Umsetzung auch Suchanfragen auf einigen Feldern schnell laufen. Ich denke, eine echte DB (auch die einfache SQLite) dieses Material transparent einfach machen kann.

Frage 1: sind DBs nützlich für solche Daten zu speichern, und wie es getan werden sollte? Beachten Sie, dass es keine 1-zu-viele, viele-zu-viele-Mappings hier und andere fortschrittliche Dinge, es ist nur eine einfache Folge von Paketen mit einer gewissen inneren Struktur I dem Benutzer angezeigt werden soll und lassen Sie ihn mit (dh Suche interagieren von einem bestimmten Feld).

Frage 2: Nehmen wir nun an den Benutzer selbst das Format seiner Pakete angeben können, das heißt in einer Konfigurationsdatei: die Länge jedes Feld, dessen Typ, was ihre Werte bedeuten (im Falle von eine Aufzählung) und so weiter. Wie erweitere ich eine DB-backed-Implementierung für das? Sollte der Benutzer DB-Schemata definieren? Sollte die Konfigurationsdatei in diese Schemata automatisch übersetzt? ORM?

Frage # 3: Noch weiter fortgeschritten ... Nun werden die Datenpakete annehmen können in Länge und Inhalt werden variiert. Das heißt, für Typ # 2 Pakete, gibt es einige Feld, für Typ # 3, einige andere Felder, und so weiter. Aber ich würde immer noch wie mein app es zu handhaben und zeigt alles schön und auch die Benutzer die Formate in Konfigurationsdateien angeben. Wie wird es gemacht?

Vielen Dank im Voraus.

Lösung

Frage 1: sind DBs nützlich für solche Daten zu speichern, und wie sie getan werden?

Sicherlich eine Datenbank ist für diese Anwendung geeignet. Sie könnten Ihren eigenen Spezial-Datenspeicher, implementieren und vielleicht wäre es effizienter für Ihre spezifische Anwendung sein, weil Sie es für diese Spezialisierung gestalten können. Eine relationale Datenbank ist für allgemeine Zwecke, aber Sie können durch die Verwendung einer Datenbank Wochen oder Monate Entwicklungszeit zu vermeiden.

, antwortete ich eine andere Frage früher heute über das Thema, wie erweiterbare Typen zu handhaben, wobei jeder neuer Untertyp seinen eigenen eindeutigen Satz von Attributen hat.

" Produkttabelle , viele Arten von Produkten, hat jedes Produkt viele Parameter . "

Für Ihre Anwendung, würde ich die Concrete Table Inheritance Design.

Frage 2: Nehmen wir nun an den Benutzer selbst kann das Format seiner angeben Pakete, das heißt in einer Konfigurationsdatei: die Länge eines jeden Feldes, dessen Typ, was bedeutet ihre Werte (im Falle eines Aufzählung) und so weiter. Wie mache ich erweitern, um eine DB-backed-Implementierung für diese?

Ich nehme an, die Anzahl der Pakettypen relativ wenige ist, und dann viele Pakete mit so ziemlich der gleichen Struktur eingefügt. So sollten Sie die Datenbank der Fähigkeit verwenden, um Metadaten zu verwalten. Ich würde eine zusätzliche Tabelle für jede neue Pakettypen definieren.

Ich würde auch die Pakete speichert „explodiert“, so dass jedes Feld des Pakets wird in einer separaten Datenbank-Spalte gespeichert. Auf diese Weise können Sie Index jede Spalte einzeln, um eine effiziente Suche zu unterstützen.

Sie können auch Einschränkungen definieren, so dass einige Felder müssen ausgefüllt werden (NOT NULL) oder deren Werte von Lookup-Tabellen beschränkt. Auch die Datenbank der Nutzung von Fähigkeiten Metadaten zu verwenden konsistente Struktur zu erzwingen, wo es wünschenswert ist.

SQL unterstützt bereits einen Standard, deklarative Sprache für Felder mit Datentypen spezifizieren, Einschränkungen usw. Warum eine andere Sprache entwickeln, die Sie dann übersetzen müssen, um SQL?

Frage 3: Noch mehr erweitert ... Jetzt nehme die Datenpakete sein können unterschiedliche Länge und Inhalt.

Felder, die in einem bestimmten Pakettyp optional sind, soll NULL in der entsprechenden Spalte ermöglichen.

Andere Tipps

Eine einfache Regel ist dies: Wenn Sie die Daten abfragen wollen, dann sollte es innerhalb der DB ein diskretes Feld innerhalb einer Tabelle sein. Wenn nicht, können Sie die BLOB speichern und mit ihm getan werden.

Das heißt, wenn Sie „Metadaten“ aus einem BLOB ableiten wollen, und Index, der, dann sind Sie auch das leicht tun können.

Wenn Sie Ihre Datentypen sind deckungsgleich mit dem, was die Datenbank unterstützen kann (oder genau umgerechnet werden kann), kann es eine gewissen Wert sein wird, um die BLOB in seine Bestandteilen explodiert, die gut in der DB Spalten zugeordnet werden.

Das Problem mit der Definition von „Tabellen on the fly“ (was leicht getan werden könnte) ist nicht so sehr die Definition der Tabelle, aber die Potentialänderung des Tisches. Tabellen, die (das heißt eine Säule oder fallen gelassen, etc.) neigen dazu, unbrauchbar für die Dauer der Änderung geändert werden. Kein Problem für 100 Zeilen. Ein echtes Problem für Millionen von Zeilen.

Wenn die Datendefinitionen sind ziemlich statisch, dann eine Abbildungseinrichtung zu schaffen, die Ihre Benutzer beschreiben die BLOB läßt, und dann verwenden Sie diese Definition sowohl eine kompatible Tabelle erstellen und die BLOBs in geeigneter Weise beim Import konvertieren.

Wie für die „verschiedenen Reihen unterschiedlicher Typen“, können Sie immer noch, dass die Daten in zu einer einzigen Tabelle stopfen. Einige Reihen haben „ungenutzt“ Spalten im Vergleich zu anderen, wird jede Zeile von Typ identifiziert. Wenn Sie viele Zeilendefinitionen und viel Varianz haben, können Sie eine Menge verschwendeten Platz bekommen dies zu tun. Dann können Sie eine Tabelle mit für jeden Zeilentyp zu gehen, und eine Master-Tabelle, die die Zeilentypen und Verweise auf die tatsächlichen Zeilen in den aktuellen Tabellen hält. Sie würden diese Master-Tabelle nur brauchen, wenn Sie über die Beziehungen der ursprünglichen Datenpakete umeinander kümmern (dann können Sie sie in Empfang, um zu speichern, sagen, usw.).

Wirklich, es läuft alles auf, wie viele Daten nach unten Sie haben, wie viel Sie erwarten, wie viel Arbeit Sie vs tun wollen, wie viel Sie bereits getan haben, etc.

Eine weitere Option, die Sie möchten, können prüfen, ist Berkeley DB oder einer seiner Klone. BDB ist ziemlich niedriges Niveau, gibt es keine SQL. Es ist so ziemlich eine wirklich klein, sehr schnell Datei-Backed-Hash-Tabelle. Es ist schon immer, und ist in vielen Orten eingesetzt, wo Geschwindigkeit und Einfachheit im Vordergrund steht. Sie müssen einige Funktionen auf hinzuzufügen, zu tun, was Sie versuchen, wenn auch zu erreichen.

Trotz der Tatsache, dass man festgestellt, dass es keine 1-viele-Beziehungen gibt es:)

Ich würde empfehlen, zwei Tabellen für die Paketspeicher zu schaffen. Ein speichern „Header“ oder „Skalar“ Informationen, die das Paket gemeinsam sind, und - während sie definieren, welche Daten vorhanden ist - ist nicht so die tatsächlichen Daten in dem Paket gespeichert.

Ihre zweite Tabelle würde speichert die Daten für jedes Paket, wobei jede Feldwertekombination eine Zeile in dieser Tabelle repräsentiert. die folgenden zwei Tabellen Zum Beispiel:

create table packet
(
    packet_id int identity(1, 1) primary key,
    destination varchar(50),
    sender varchar(50),
    packet_type_id int not null
)

create table packet_field
(
    packet_field_id int identity(1, 1) primary key,
    packet_id int not null references packet (packet_id),
    field_id int not null,
    data varbinary(500)
)

Offensichtlich sind diese beiden Tabellen machen Annahmen über die Art und Größe der zu speichernden Daten und sind nicht erschöpfend, was sie zu speichern benötigen. Allerdings wird diese grundlegende Struktur für erlaubt dynamisch definierten Paketformate und ist ein Schema, das leicht indiziert ist (zum Beispiel eines Index für packet_id+field_id in packet_field Zugabe wäre ein Kinderspiel).

Alle Ihre Anwendung ist dann verantwortlich für das Paket ausgepackt und es in Ihrer DB in diesem Schema zu speichern, dann Umpacken (falls erforderlich).

Natürlich von diesem Punkt werden Sie Tabellen benötigen, die das tatsächliche Format des Pakets speichern. So etwas wie ...

create table packet_type
(
    packet_type_id int identity(1, 1) primary key,
    name varchar(200) not null
)

create table packet_type_field
(
    field_id int identity(1, 1) primary key,
    packet_type_id int not null references packet_type (packet_type_id)
    field_offset int not null,
    name varchar(200) not null
)

Auch hier offensichtlich vereinfacht, aber es zeigt die Grundidee. Sie würden für jedes Paket Format einen einzelnen Datensatz in Ihrem packet_type Tisch haben, und eine Zeile in der packet_type_field für jedes Feld in einem bestimmten Paket. Dies sollten Sie die meisten Informationen, die Sie müssen in der Lage sein, einen beliebigen Brocken von binären Daten in das zuvor genannte Paketspeicherschema zu verarbeiten.

Drei Methoden in den Sinn kommen.

sFlow und IPFlow kann eine begrenzte Anzahl an Paketinhalt übertragen. Dies kann direkt in verschiedene Datenbanken protokolliert werden.

Eine weitere gezielte Methode wäre ein Schreib eine sehr einfache Schnauben Regel wie Quell- oder Zieladresse. Dann haben Schnauben Erfassung der Nutzlast der Pakete. Auf diese Weise würden Sie erhalten nur die tatsächlichen Daten, die Sie benötigen. Zum Beispiel könnten Sie einfach die Felder der Daten innerhalb des Pakets greifen. z.B. Kennwort etc.

ngrep kann auch selektiv Daten direkt an den Draht greifen.

Natürlich jeder dieser könnte eine Anzapfung erfordern oder Sitzung auf einem Port überwachen, wenn Sie nicht die Einnahme tun auf dem Server / Workstation selbst.

Obwohl ich kein großer Fan dieser Implementierung bin, haben wir einige Software, die dies im Wesentlichen für einige Anruflisten der Fall ist. Im Wesentlichen ist hier, was sie tun:

Eine Tabelle mit Spaltendefinitionen - nennt es tblColumnDefs. Diese Tabelle enthält Spalten wie „Name“, „Typ“, „Länge“ und „Beschreibung“
Eine Instanz Master-Tabelle (tblPacketNames). Im Wesentlichen nur „PacketTypeID“, „PacketName“ und „Beschreibung“ für jeden Pakettyp Sie definieren
Eine Instanz Definitionstabelle (für Sie, dies wäre tblPacketColumns). Diese Tabelle sammelt die vordefinierten Spalten zusammen, um die Datenstruktur zu bilden, die Sie speichern. Zum Beispiel könnte es „PacketTypeID“, „Spaltennummer“, „ColumnID“ halten. In Datenbank-Normalisierung-sprechen, ist dies eine many-to-many-Tabelle, da es sich um die Spalten zu den Paketen zuordnet, die sie verwenden.
In einer zweiten Datenbank (wegen der dynamischen SQL / Injektion Auswirkungen dieses Schrittes) werden Tabellen erstellt dynamisch die aktuellen Daten zu halten. Zum Beispiel, wenn Sie (in Schritten 2/3) ein Pakettyp namens „PING“ definiert haben, haben Sie vielleicht eine Tabelle „PING“ in Ihrer Datenbank mit dem Namen, dass die Daten zu halten. Sie würden verwenden tblPacketColumns, verbunden mit tblColumnDefs, um herauszufinden, welche Feldtypen zu erstellen und wie groß sie sein sollten. Sie enden mit einer Sammlung von Tabellen auf, die die Pakettypdefinitionen aus Schritt 3 mit den Spalten aus Schritt 1 entsprechen.

Hinweis: Ich glaube nicht, insbesondere wie die SQL-Injektion Auswirkungen von Schritt 4. Erstellen von Tabellen dynamisch an einigen Folgen führen kann, wenn die Sicherheit nicht richtig und die Eingabe von beliebigen Benutzer eingegebenen Felder in Ihrer Anwendung ausgelegt ist, die verfügbar zu nicht vertrauenswürdigen Anrufern ist nicht richtig, vor allem, wenn diese Anwendung eine Schnittstelle gereinigt (dh das Internet).

diese verwenden, können Sie Indizes erstellen, wie Sie wollen, wenn die Tabellen erstellt werden (vielleicht haben Sie eine Spalte in Schritt haben 1, wo Sie bestimmte Spalten als „Indizierbare“ Flag und Indizes auf ihnen erstellt, wenn die Tabellen erstellt werden .

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow