Ausarbeitung - Lehrgebiet Datenbanksysteme für neue Anwendungen

FernUniversität in Hagen
Seminar 01912
im Sommersemester 2005
„Datenströme und kontinuierliche Anfragen:
Einführung"
Thema 1
Motivation für Stromverarbeitung: Analyse von
Netzwerkverkehr
Referent: Torben Schrader
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Inhaltsverzeichnis
Inhaltsverzeichnis.............................................................................................................................2
Abbildungsverzeichnis .....................................................................................................................2
Einleitung stromorientierte Datenverarbeitung................................................................................3
Aufgaben ......................................................................................................................................3
Anwendungsbereiche ...................................................................................................................3
Exkurs: Netzwerkspezifische Begriffe.........................................................................................4
Exemplarische Problemstellung aus dem Bereich Netzwerkanalyse...........................................4
Konventionelles DBMS vs. DSMS..................................................................................................5
Gemeinsamkeiten .........................................................................................................................5
Unterschiede.................................................................................................................................6
Vor-/ Nachteile von DSMS ..........................................................................................................7
Beispielanwendungen.......................................................................................................................8
Beispielanwendung Tribeca .........................................................................................................8
Beispielanwendung Gigascope ....................................................................................................9
Abfragesprachen.............................................................................................................................10
Abfragesprache allgemein:.........................................................................................................10
Abfragesprache - Tribeca ...........................................................................................................10
Abfragesprache Gigascope.........................................................................................................12
Architekturen..................................................................................................................................14
Architektur von Tribeca .............................................................................................................14
Architektur von Gigascope.........................................................................................................14
Testverfahren..............................................................................................................................16
Zusammenfassung......................................................................................................................17
Quellenverzeichnis .....................................................................................................................17
Glossar............................................................................................................................................18
Anhang ...........................................................................................................................................19
Abbildungsverzeichnis
Abb. 1: Netzwerkumgebung mit Rechenzentrum und entfernten Standort......................................4
Abb. 2: Unterschiede in der klassischen und strombasierten Datenverarbeitung...............................5
Abb. 3: Unterschiede DBMS - DSMS..............................................................................................6
Abb. 4: Beispielabfrage in Tribeca.................................................................................................11
Abb. 5: Darstellung der Abfragekomponenten in Gigascope.........................................................12
2
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Einleitung stromorientierte Datenverarbeitung
Aufgaben
Die stromorientierte Datenverarbeitung stellt eine relativ neue Alternative für die Verarbeitung
sehr großer Mengen von Daten mit speziellen Charakteristiken dar.
Sie sollen konventionelle Datenverarbeitungen sinnvoll ergänzen oder in Teilen ablösen, um neue
Abfragemöglichkeiten zu eröffnen, bestehende Abfragen zu beschleunigen oder diese flexibler
und robuster zu gestalten.
Dabei ist es eine besondere Herausforderung für die neuen Datenverarbeitungssysteme, sich den
stark ändernden Eigenschaften der verarbeiteten Datenströme anzupassen und darauf adäquat zu
reagieren, so dass für den Endanwender weiterhin ein akzeptabel reagierendes Programm zur
Verfügung steht.
Diese Ausarbeitung soll darstellen, wofür diese Systeme eingesetzt werden, wie sie speziell im
Netzwerkbereich genutzt werden können und welchen Nutzen diese Entwicklungen haben.
Dieses erfolgt anhand zweier Systeme, die im Netzwerkbereich eingesetzt werden, und deren
Besonderheiten hier vorgestellt werden. Zweimal erfolgen kurze Exkurse um Begriffe aus der
Netzwerktechnik und aus den zugrundeliegenden Datenstrommanagementsystemen (zukünftig
nur noch DSMS abgekürzt, konventionelle Datenbanksysteme werden mit DBMS abgekürzt) zu
definieren, so dass die zugrundeliegende Literatur verständlicher wird.
Anwendungsbereiche
Stromorientierte Datenverarbeitungen werden überall dort eingesetzt, wo ein großes
Datenvolumen mit oftmals hoher und gleichzeitig stark schwankender Frequenz bei einem
Empfänger eintrifft. Diese Datenströme werden zeitnah mit ihrem Eintreffen beim Empfänger
ausgewertet, um sich einen Überblick über die aktuelle Situation zu verschaffen. Beispielhafte
Anwendungsszenarien ergeben sich dabei in einem weitgefächerten Bereich:
•
•
•
•
•
•
•
•
•
Finanzdienstleistungen (Börsenticker)
Straßenverkehr (Verkehrsüberwachung)
Einzel - / Großhandel (Absatzdaten - Warenwirtschaftssysteme [Stichwort RFID1])
IT-Dienstleistungen / Telekommunikationsdienstleistungen (Web-Server Statistiken /
Call-Center Statistiken)
Medizintechnik (Überwachung von Körperfunktionen z.B. bei Operationen)
Militär (Aktuelle Lagedarstellungen auf dem Gefechtsfeld)
Naturschutz (Verhaltensforschung bei Tieren, z.B. Bewegungsradius von Zugvögeln)
Wetterdienst: Tornadowarnsystem
Netzwerktechnik
In der EDV kann man in verschiedensten Bereichen Informationen über das
Kommunikationsverhalten in einem Netzwerk nutzen. Dieses umfasst die Kapazitätsplanung
neuer Netzwerke, die Überwachung der Netzwerkfunktionalität oder die Einbruchserkennung
innerhalb des Teilgebietes der Netzwerksicherheit.
1
RFID Radio Frequency Identification: Chipbasierte Technologie mit der beispielsweise Warenbewegungen drahtlos
verfolgt werden können. Der Chip beinhaltet z.B. Identifikationsmerkmale wie Produktcode oder Seriennummer
3
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Exkurs: Netzwerkspezifische Begriffe
TCP/IP : TCP/IP ermöglicht den Versand von Datenpaketen über Routergrenzen hinweg (d.h.
Adressierung an Empfänger außerhalb des eigenen Netzes). Jedes IP Paket kann auf einem
beliebigen Weg zum Ziel gelangen, es muss nicht immer derselbe Weg für alle Daten einer
Kommunikation verwendet werden. Aus einem TCP/IP Paket können nicht nur Sender und
Empfänger sondern auch die Art der übertragenen Daten bestimmt werden.
ATM (Asynchronous Transfer Mode): ATM ist ein Netzwerkprotokoll in dem alle Daten einer
Kommunikationsverbindung über denselben Weg vom Empfänger zum Ziel gelangen. Daten
werden über die VCI-Markierung (VCI=Virtual Circuit Identifier) unterschieden, damit sie den
richtigen Weg im Netzwerk benutzen. Für weitere Details s. auch Glossar.
Netflow / SNMP: Protokolle für das Netzwerkmanagement. S. auch Glossar.
Exemplarische Problemstellung aus dem Bereich Netzwerkanalyse
entfernter Standort
Rechenzentrum
Sniffer
transportabel
Sniffer
transportabel
WAN
Provider
Provider
Syslog/SNMP
Server
Syslog/SNMP
Collector
Netzwerk-Management /
Netflow Server
Abb. 1 : Netzwerkumgebung mit Rechenzentrum und entfernten Standort
Die folgenden Beispiele sollen einen "realistischen" Überblick über Fragestellungen geben, die
mittels eines DSMS analysiert werden könnten.
In Abb. 1 wird die den Beispielen zugrunde liegende Netzwerkstruktur beschrieben, wobei es
sich bei der WAN-Leitung2 zwischen den beiden roten Provider-Routern um eine wenig
performante 10MBit Leitung handelt, während im LAN3 durchgängig 100MBit verwendet wird.
Aus Gründen der Übersichtlichkeit wurde nur ein entfernter Standort in die Zeichnung
aufgenommen, obwohl ein Rechenzentrum mehr Standorte versorgen könnte. In den folgenden
drei Beispielen werden exemplarische Fragestellungen aus dem Bereich des
Netzwerkmanagements aufgezeigt, die in dieser Arbeit verwendet werden.
1. In der skizzierten Umgebung tritt ein Problem auf, welches darauf hindeutet, dass
Datenpakete zwischen dem entfernten Standort und dem Rechenzentrum verloren gehen.
Deshalb ist die Auslastung der WAN-Verbindung zu prüfen, um festzustellen, ob diese
Strecke überlastet ist und infolgedessen Pakete von einem Router verworfen werden.
2. Die im entfernten Standort abgegangenen Daten sollen bei der Ankunft im Rechenzentrum
mit den Ursprungsdaten (Ursprungspaketen) verglichen werden, um sicherzustellen, dass alle
Pakete korrekt und unverfälscht angekommen sind.
2
3
WAN - Wide Area Network, s. Glossar.
LAN Local Area Network, s. Glossar.
4
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
3. In der weiteren Fehleranalyse wird eine Überlast der Netzwerkverbindung zu einem Server
festgestellt. Der Administrator soll die Toptalker zu diesem Server ermitteln. Als Toptalker
werden diejenigen Geräte bezeichnet, die den größten Anteil an der Kommunikation
ausmachen.
Die Messszenarien beinhalten unterschiedliche Schwierigkeiten, die die Analyse der Daten
kompliziert gestalten. (Für weitere Beispiele s. [2])
Konventionelles DBMS vs. DSMS
In Abb. 2 sind die wesentlichen Charakteristiken beider Systeme dargestellt.
Abb. 2: Unterschiede in der klassischen und strombasierten Datenverarbeitung4
Bei beiden Systemen ist das Endergebnis gleich, es wird jeweils eine Anfrage ausgeführt. Der
Zwischenschritt des Datenspeicherns entfällt in der strombasierten Verarbeitung und eine
Anfrage wird direkt auf den Datenströmen ausgeführt.
Gemeinsamkeiten
Die allgemeinen Eigenschaften von DBMS, wie sie in [3], Kapitel 1.2. dargestellt sind, bilden die
Grundlage für die folgende Auflistung der Gemeinsamkeiten der beiden Systeme.
• Flexibilität : DSMS sollen ebenso wie DBMS die Abhängigkeit zwischen Daten und
Programm aufheben. Dadurch wird vermieden, dass sämtliche handgeschriebenen
Programme, die IPv4 Daten verarbeiten, angepasst werden müssen, wenn flächendeckend
auf IPv6 umgestellt würde.
• Anfrageverarbeitung: Alle Anfragen, die über einen oder mehrere Datenströme erfolgen,
können auch durch eine Folge von SQL-Abfragen auf einem zwischengespeicherten
Datenpool ausgeführt werden (vgl. [6], S.4). Das Ergebnis ist identisch.
• Benutzerschnittstellen: Unterschiedlichste Benutzergruppen mit unterschiedlichen
Fähigkeiten im Umgang mit IT Systemen sollten die Möglichkeit erhalten die Datenbank
zu nutzen und dafür eine geeignete Schnittstelle bereitgestellt bekommen.
• Schnellere Anwendungsentwicklung: Die Fehlersuche ist ein schwerwiegender Faktor bei
der Entwicklung neuer Software. Insofern ist es nützlich, zuverlässige und bewährte
Bausteine für neue Software zu benutzen, um die Entwicklung zu beschleunigen. Dafür
bieten sich Datenbanksysteme an.
4
Entnommen aus [1], S. 740
5
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Unterschiede
Die nachfolgende Tabelle stellt die Unterschiede zwischen den beiden Systemen dar:
Kennzeichen
konventionelle Systeme
strombasierte Systeme
Dateneingang
Große, aber endliche Anzahl von
Potentiell unendliche Anzahl an
Datensätzen in Form von zumeist
Daten, die nicht kontinuierlich,
vorbearbeiteten Tupeln
sondern stoßweise eintreffen
(normalisierte Form der Daten).
können. Die Ankunftszeit im
Ankunftszeit der Daten im System System ist eine charakteristische
ist meistens nicht von Belang.
Eigenschaft für die Daten.
Datenspeicherung
Daten sollen peristent gespeichert Unbearbeitete Eingabedaten können
werden. ACID5 Anforderung
aufgrund der Unendlichkeit des
bedeutet zusätzlichen Aufwand für Datenstroms nicht dauerhaft
eine sichere und konsistente
gespeichert werden. Allenfalls
Datenspeicherung.
können Ausschnitte oder
zusammengefasste Ergebnisse
gespeichert werden.
Datensätze
Einzelne Datensätze werden in
Verlust von einzelnen Eingabedaten
normalisierter Form gespeichert.
ist akzeptabel, solange dadurch in
Jeder Datensatz ist wichtig und
der Gesamtheit die Ergebnisse nicht
schützenswert, z.B.
verfälscht werden.
Buchhaltungssystem
Zeitbezug der
Auswertungen erfolgen einmalig
Abfragen erfolgen kontinuierlich
Abfrageergebnisse
jeweils über einen bestimmtes
und sollten jeweils den aktuellen
Zeitfenster. Oftmals ist es
Zustand darstellen ("Echtzeit"). Im
akzeptabel, Abfragen im
Netzwerkbereich z.B. könnte die
Stapelbetrieb auszuführen. AdAuslastung eines WAN Interfaces
Hoc-Abfragen sollten hingegen
mit Datenverkehr vom Standort X
zügig ausgeführt werden können.
dauerhaft überwacht werden (s. S. 4
Beispiel 1)
Abfrageplan
Optimierung der Einzelabfrage vor Keine kurzfristige Optimierung, da
jeder Ausführung aufgrund von
die Abfragen kontinuierlich sicher
Regeln und zusätzlichen
arbeiten müssen.
Informationen, wie Zugriffspfaden
und statistischen Daten über die
Datenbasis.
Modifikation /
Notwendig und selbstverständlich. Nicht notwendig. Eingabedaten
Löschen von Daten
werden an den Datenbestand
angehängt, aber nicht dauerhaft
abgespeichert oder nachträglich
geändert.
Abb. 3: Unterschiede DBMS - DSMS
Diese ergeben sich aus den unterschiedlichen Charakteristika, den unterschiedlichen
Anforderungen an die Systeme und deren verschiedenen Einsatzgebieten.
Grundlage der Tabelle ist [7], S. 16f.
5
ACID:Atomicity, Consitency, Isolation, Durability - Anforderungen an eine konventionelle DB, s. z.B. [3]
6
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Vor-/ Nachteile von DSMS
Bevorzugte Abfragen für DSMS
DSMS haben ausgesprochen bevorzugte Abfragen. Alle Abfragen, die ausschließlich Operatoren
nutzen, die Ergebnisse in nur einem Durchlauf über die Daten erzeugen, sind optimal für DSMS.
Besonders schwierig hingegen sind Abfragen, die Operatoren enthalten, welche mehrere Läufe
über die Eingabedatenmenge erfordern.
Konventionelle Realisierungsmöglichkeiten
Für die Analyse des in Beispiel 1 (s.S. 4) beschriebenen Problems soll für ein Intervall X
aufgezeichnet werden, wie viele Pakete und wie viele Daten (Bytes) am WAN-Router eintreffen.
Danach soll ausgewertet werden, ob in einer bestimmten Periode des Überwachungszeitraumes
eine Überlast der WAN-Leitung aufgetreten sein könnte. Gemessen wird am Routerinterface, das
zum LAN zeigt.
Eine konventionelle Abfrage (fiktiv) könnte folgendermaßen aussehen:
Select SUM (Packet.length) from Inputtable GROUP BY time_in_Sec
Gegenüber dem Standard SQL muss hier bereits eine Funktion definiert sein, welche es erlaubt,
einen mitgespeicherten Zeitstempel zu verarbeiten, derart, dass die einzelnen Tupel in einSekunden-Intervallen eindeutig unterscheidbar sind.
Hierbei besteht das Problem, die mitgeschnittenen Netzwerkpakete in eine konventionelle
Datenbank zu überführen. Das de-facto Standardprogramm Etherreal unterstützt den Datenexport
in eine relationale Datenbank nicht. Allerdings existieren im Internet einige Bibliotheken6 die
dieses Problem lösen können oder man weicht auf kommerzielle Software aus, die dieses
unterstützt7.
Obwohl in keiner Sekunde des analysierten Intervalls im Mittel eine Datenüberlast auftrat, könnte
diese immer noch für Sekundenbruchteile aufgetreten sein. Ein Datenstrom aus dem LAN kann
die Aufnahmekapazität der WAN-Leitung und den Puffer des WAN-Routers sehr schnell füllen.
Die Abfrage wurde bewußt unklar gestellt, weil die Lösung hieraus entweder eine nahezu
Echtzeit-Präsentation der Daten wäre oder die Abfrage umformuliert werden müßte, damit der
Füllzustand des Routerspeichers (und nicht die Auslastung des WAN-Interfaces) kontinuierlich
überwacht wird. Die eigentliche Frage ist, ob der Routerspeicher in einem beliebigen Zeitpunkt
innerhalb des Überwachungsintervalls seine Kapazität überschreitet, weil die aktuelle Auslastung
plus die zufließende Datenmenge größer als die abfließende Datenmenge ist. Dieses zu
beantworten erfordert, dass:
der Sensor, der die Pakete empfängt, diese mindestens so schnell verarbeiten kann,
wie es erforderlich ist, um eine Überlastsituation am Router zu erzeugen.
Zeitstempel der Pakete zuverlässig gesetzt werden und einfach verarbeitet werden
können
Dieses Beispiel soll bewusst zur Diskussion anregen, wie viel "Echtzeit" für eine Anfrage
benötigt wird. In diesem Fall hätten andere Analysemöglichkeiten offen gestanden, die mit
weitaus weniger Datenvolumen zielgerichtet die gewünschte Information geliefert hätten
(verworfene Pakete im Intervall X am Router-Interface auswerten).
6
Stichwort DBI - DataBase Interface, eine Perl Bibliothek die eine Schnittstelle zu MySQL anbietet. Von mir bisher
allerdings noch nicht getestet.
7
Beispielsweise ntop mit angepasster Datenbank für SQL Abfrage www.ntop.org
7
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Gründe für die Realisierung mit DSMS
Aufgrund der unter "Konventionelles DBMS vs. DSMS" beschrieben Charakteristiken von
Datenströmen und den Unterschieden in den Systemen haben DSMS einige Vorteile, die es
ihnen ermöglichen sollten, effizienter mit den eintreffenden Daten umzugehen.
Diese Effizienzvorteile ermöglichen es ihnen, die Ergebnisse ihrer Abfragen zuverlässiger und
aktueller darzustellen, als es konventionelle Systeme machen könnten. Zuverlässiger sind diese
Systeme insofern, als sie weniger Eingabedaten aufgrund eigener Überlastung verwerfen müssen
(s. auch S. 16 "Ergebnisse"). Die Ergebnisse der Abfragen bei DSMS können dabei mit weniger
Hardwareaufwand erzielt werden, als dieses bei einem vergleichbaren konventionellen System
nötig wäre, weil die Systeme besonders für ihren Einsatzzweck optimiert sind. Eine effektive
Netzwerkanalyse ist mit handgeschriebenen Programmen in der Praxis zwar auch möglich, damit
verzichtet man aber auf die beschriebenen Vorteile von Datenbanksystemen. Gekaufte
Spezialprogramme umgehen zwar das Entwicklungsproblem, sind aber oftmals unflexibel oder
decken nicht das komplette Einsatzspektrum ab.
Zusätzliche Aufwände bei DSMS
Bei stromorientierten Datenbanken ergeben sich zusätzliche oder andere Probleme, die in
konventionellen Systemen nicht auftreten. Beispielsweise ist es notwendig, den
Eingabedatenstrom vorzuverarbeiten. Im Gegensatz zu konventionellen DBMS, in denen
Datensätze strukturiert abgespeichert werden, kommen bei DSMS als Eingabe immer neue
Datensätze, die neu formatiert werden und danach an die bestehenden Daten angehängt werden
müssen. Es gibt praktisch keine Optimierungsmöglichkeiten (Verweise auf Feldanfang /
Feldlänge / Feldinhalt), da die Eingabedaten nicht für die Weiterverarbeitung in
Datenbanksystemen vorgesehen sind.
Für viele Abfragen ist es zusätzlich notwendig, mehrere Datenströme miteinander zu
synchronisieren. In Beispiel 2 (s.S. 4) ist dieses der Fall. Dort müssen zwei Mitschnitte von
Netzwerkverkehr miteinander abgeglichen werden. Deshalb ist es notwendig, die Datenströme
miteinander zu synchronisieren. Dieses kann durch Sequenznummern oder Zeitstempel, die in
den Datenstrom eingefügt werden, erfolgen, sofern dieser keine eigenen Marken mitbringt.
Beispielanwendungen
Beispielanwendung Tribeca
Entstehung
Tribeca wurde bei Bell LAB Networks um1997 entwickelt.
Tribeca wurde mit dem Ziel entwickelt, handgeschriebene und handoptimierte NetzwerkanalyseTools durch eine standardisierte Weiterverarbeitungsmöglichkeit überflüssig zu machen.
Konventionelle Datenbanksysteme hatten damals weder eine ausreichende Geschwindigkeit noch
wurde ihnen von Seiten der Netzwerkanalytiker Vertrauen entgegengebracht.
Zielsetzungen / Anforderungen
Tribeca sollte eine "reine" stromverarbeitende Datenbank sein. Es war nicht das Ziel der
Entwicklung, kontinuierliche Anfragen über relationale Eingabetabellen oder relationale Tabellen
als Ausgaben zu produzieren. Als Grund hierfür ist die reine Optimierung der
Anfrageverarbeitung für Datenströme anzusehen. Wäre diese Komponente nicht hochgradig
8
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
performant gestaltet worden, so hätte sie nicht gegen die handoptimierten, für sequentielle
Dateien angepassten C-Programme konkurrieren können.
Tribeca sollte ausreichend performant gestaltet werden, um Daten von einem OC3-Anschluss
(155MBit/s) als Eingangsdatenstrom zu analysieren. Es wurde auf alle Funktionen verzichtet, die
nicht zwingend benötigt werden. Dieses sind z.B. der wahlfreie Zugriff auf Daten,
Transaktionskontrollen oder der Einsatz von konventionellen Indizes.
Beispielanwendung Gigascope
Entstehung
Ende 2002 wurde Gigascope, ähnlich wie Tribeca, bei AT&T Networks entwickelt, weil immer
mehr Endanwender (=Netzwerkadministratoren) selbstgeschriebene Programme für die
Netzwerkanalyse einsetzten.
Tribeca entspricht in der Leistungsfähigkeit nicht den Anforderungen, die AT&T durch einen
Backbonebereich mit OC48-Datenleitungen (ca. 2.45 GB/s) stellt.
Gigascope wird auch in mehreren Installationen bei AT&T-Kunden eingesetzt und überwacht
dort z.B. Gigabit-Ethernetanschlüsse.
Zielsetzungen / Anforderungen
Gigascope sollte in hochperformanten Netzwerken handoptimierte Programme ablösen.
Ein breites Einsatzspektrum innerhalb des Netzwerksegments, von der Fehleranalyse, über
Einbruchserkennung bis Performance-Überwachung oder auch freie Aufgabenstellungen sollen
unterstützt werden. Dafür ist es erforderlich, dass Gigascope eine einfache, zuverlässige und
schnelle Abfragesprache, die von den Netzwerktechnikern akzeptiert wird, bereitstellt.
Gigascope soll auch in Gigabit-Ethernetumgebungen den kompletten Netzwerkverkehr erfassen
können, um detaillierte Analysen auf höheren Datenschichten (im OSI-Modell) zu ermöglichen.
Dieses können Tools wie Netflow und SNMP nur unzureichend leisten, da sie nur
zusammengefasste Daten liefern.
Exkurs Definitionen / Begriffe Gigascope
Ordered-Attributes: Ordnungsattribute in einem Datenstrom, erlauben es Datensätze nur so lange
im Speicher zu halten, wie noch mit deren Verwendung gerechnet werden muss. In Anlehnung an
die Begriffe bei Tribeca möchte ich dieses als "variables Fenster" bezeichnen, welches
frühestmöglich ein Zwischenergebnis ausgibt. Dadurch kann es gelingen, einen blockierenden
Operator in einen Stromoperator umzuwandeln.
Blocking-Operator (Stateful-Operator): (vgl. [7] Kap. 4.5) Ein blockierender Operator ist ein
Operator, der erst dann ein Ergebnis liefert, wenn er alle Datensätze, die er verarbeiten soll,
einmal gesehen hat. Ein Beispiel hierfür wäre der SUMME (SUM) Operator.
Non-Blocking-Operator: Ein nicht blockierender Operator kann sofort mit dem Eintreffen eines
Datensatzes diesen verarbeiten und eine Ausgabe erzeugen. Nicht blockierende Operatoren sind
für DSMS wünschenswert.
9
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Query-Node (LFTA /HFTA8) : Der Programmteil, der die eigentliche Abfrage ausführt. LFTAs
akzeptieren als Eingabe nur einen nicht vorbearbeiteten Eingabestrom (Protocol). LFTAs sind in
Bezug auf Speicher und CPU stark eingeschränkt, da sie zum Beispiel innerhalb einer
Netzwerkkarte implementiert werden können. LFTAs sind für die Vorverarbeitung und einfache
Abfragen verantwortlich. HFTAs können komplexe Abfragen ausführen und akzeptieren nur
vorbehandelte Datenströme (Stream) als Eingabeformat. Sowohl HFTAs als auch LFTAs
erzeugen als Ausgabe einen Stream.
Abfragesprachen
Abfragesprache allgemein:
Abfragesprachen sind eine Schnittstelle des Datenbanksystems zum Anwender. Eine hohe
Stabilität und komfortable Gestaltung sind insofern für die Akzeptanz bei den Anwendern
unerlässlich.
Deskriptive Abfragesprachen erweitern die prozeduralen insofern, als ihnen nicht mitgeteilt
werden muss, wie die Abfrage ausgeführt werden soll, sondern nur was abgefragt werden soll.
Dieser zusätzliche Abstraktionsgrad macht die Abfragen wesentlich robuster, da der Benutzer
weniger Fehler bei der Abfrageerstellung machen kann.
Bei deskriptiven Abfragesprachen werden verschiedene Umformungen automatisch
vorgenommen, um die Geschwindigkeit der Abfrage zu optimieren. Dieses umfasst das
Umformen der Abfrage in eine standardisierte Form (Relationenalgebra) mit anschliessender
logischer Optimierung. Dabei werden Operationen die das Datenvolumen beschränken möglichst
frühzeitig im Abfrageplan ausgeführt. Konventionelle DBMS können Optimierungen auf der
physikalischen Ebene durchführen, z.B. durch geeignete Auswahl der Implementationen von
verschiedenen Operatoren und durch eine geschickte Ausnutzung von Zugriffspfaden. Die
Abfragesprachen von DSMS sind in der Auswahl verschiedener Implementationen für einen
Operator beschränkt, da diese nicht so zahlreich verfügbar sind. Ebenso können keine
Zugriffspfade ausgenutzt werden, da diese nicht existieren.
Abfragesprache - Tribeca
Tribeca nutzt eine prozedurale Abfragesprache und stellt lediglich einen eingeschränkten Satz an
Operatoren zur Verfügung. Der Endanwender kann deshalb keine Abfragen erstellen, die den
Optimierungszielen der Datenbank entgegenwirken. Der Funktionsumfang ist allerdings über die
DDL und das Extensible Type System erweiterbar. Tribeca ist eine reine stromorientierte
Datenbank, so dass die Operatoren komplett auf die Charakteristiken bei Datenströmen optimiert
werden konnten. Dieses sichert die semantische Konsistenz der Abfrage. Es ist nicht notwendig,
wiederholt von relationaler Form nach Datenstrom und zurück zu konvertieren, wenn man
verschachtelte Abfragen benutzt.
Einfache Operatoren in Tribeca umfassen die Selektion, Projektion und Aggregation.
Alle drei Operatoren nutzen einen Eingabedatenstrom und produzieren als Ergebnis entweder
einen Ausgabestrom oder einen Ausgabewert. Diese Operatoren sind in der Implementierung als
unkritisch einzustufen, da sie die Speichergrenzen nicht überschreiten.
Eine zweite Gruppe von Operatoren (Multiplex / Demultiplex) erzeugt aus mehreren
Eingabedatenströmen einen Ausgabedatenstrom oder aus mehreren Ausgabedatenströmen einen
Eingabedatenstrom. Der Demultiplex-Operator gilt insofern als kritisch, als er es ermöglicht,
8
FTA = Filtering, Transformation, and Aggregation
10
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Abfragen zu erzeugen, die den verfügbaren Hauptspeicher überschreiten. Dadurch würden hohe
I/O-Kosten produziert werden. Dieses Problem ist allerdings abhängig von der Anzahl der zu
erzeugenden Ausgabedatenströme und tritt nur bei einer großen Anzahl von
Ausgabedatenströmen auf. Dieses kann passieren, wenn ein Datenstrom in einzelne Ströme für
feste Zeitintervalle aufgeteilt wird.
Für dieses Problem wurde als Alternative die Fenstertechnik entwickelt.
Bei der Fenstertechnik arbeiten Operatoren nur auf einen zeitlich begrenzten Teil des
Eingabedatenstroms. Es gibt feste (fixed Windows) oder gleitende (sliding Windows) Fenster.
Die Beschränkung des Eingabedatenstroms in Datenströme fester Länge verringert den
Hauptspeicherbedarf zur Ausführung der Abfrage, so dass diese innerhalb der gegebenen
Restriktionen (ohne I/O Zugriffe) ausgeführt werden kann.
Ein Beispiel, in dem alle drei Gruppen von Operatoren genutzt werden, ist in Abbildung 4
dargestellt. Dabei sollen aus einem ATM Datenstrom alle IP Pakete analysiert werden, die nicht
zu einer bestimmten Verbindung (VCI=42) gehören. Im ersten Schritt soll die Anzahl der ICMP
Pakete in dem gefilterten Datenstrom festgestellt werden, im zweiten Schritt soll die
durchschnittliche Länge von IP Paketen innerhalb eines 5ms. Intervalls festgestellt werden.
Tape
Atm Trace
File
res1
File
Res2
Abb. 4: Beispielabfrage in Tribeca9
Umsetzung des obigen Beispiels in Tribeca:
//Quelle und Ziel definieren
source stream s1 is {tape sample1 AtmTrace}
result stream r1 is {file res1}
result stream r2 is {file res2}
//VCI 42 aus dem Datenstrom herausfiltern
stream_qual {{NOT s1.vci.eq 42}} p1
//Datenstrom in n-Datenströme für n-VCIs aufteilen
stream_demux {p1.atm.vci} p2
//IP Pakete Zellenübergreifend zusammensetzen
stream_proj {{p2.assemble ip}} p3
//Zusammenführen der einzelnen IP Pakete in einen Datenstrom der
//an zwei weitere Abfragen weitergeleitet wird
stream_mux p3 p4
//Auf ICMP Pakete filtern
stream_qual {{p4.ip type.eq ICMP}} p5
//Gesamtanzahl aller ICMP Pakete speichern
9
Entnommen aus [4].
11
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
stream_agg{p5.count} r1
//Festes Fenster von 5ms Länge definieren
stream window w1 on p4
defined by {p4.ts.interval 0.005} is fixed
//Zusammenfassen der durchschnittlichen Paketlänge in einem 5ms
//Intervall
stream_agg{w1.count w1.length.mean} r2
Abfragesprache Gigascope
Im Gegensatz zu Tribeca wird bei Gigascope eine deklarative, an SQL angelehnte
Abfragesprache verwendet. Auch Gigascope verzichtet auf die Vermischung von Relationen und
Datenströmen und ist eine reine stromorientierte Datenbank. Gigascope schränkt den
Funktionsumfang von SQL ein, beispielsweise wird nur ein JOIN-Operator für zwei Datenströme
bereitgestellt. Gleichzeitig erweitert es SQL aber auch um Operatoren die für Datenströme
sinnvoll sind.
Gigascope unterstützt die klassischen Operatoren, wie Selektion, Projektion, Aggregation und
Join. Zusätzlich implementiert Gigascope einen veränderten Union Operator "MERGE".
Merge verschmilzt mehrere Eingabedatenströme miteinander, ohne die Ordnungseigenschaft der
einzelnen Eingabedatenströme zu verlieren.
Für eine GSQL Abfrage ist es notwendig, dass der zu verarbeitende Datenstrom vorab in seiner
Syntax definiert wurde :
PROTOCOL IPv4(IP) {
uint hdr_length;
uint service_type;
uint total_length;
...
komplexe Abfrage
}
Nutzungsmöglichkeiten
der Abfragen
Vorverarbeitung /
Abfrage
Anwendung
LFTA
HFTA
Eingangsdatenströme
HFTA
LFTA
gefilterter
Datenstrom
HFTA
DB
Vorverarbeitung /
Abfrage
komplexe Abfrage
Abb.5: Darstellung der Abfragekomponenten in Gigascope, angelehnt an [6] S.15
Darauf aufbauend kann danach eine Abfrage erfolgen. Sie besteht aus zwei Teilen:
Der Definition des Abfragenamens, über den diese Abfrage später ansprechbar ist, und der
eigentlichen Abfrage.
Als (s auch S. 4, Beispiel 3) dient eine Standard SQL Abfrage über die obersten 20% der
Netzwerknutzer, die am meisten Datenverkehr verursachen. Diese soll dabei nur einen Einblick
geben, wie Abfragen in GSQL in etwa aussehen könnten. Diese Abfrage konnte von mir nicht in
12
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
GSQL, sondern nur ummodelliert in MS-Access10 ausgeführt werden. Grundlage für die Abfrage
sind [5] und [2], in letzter Quelle wurde diese Anfrage in CQL formuliert. Adressiert werden soll
hiermit auch das Problem, dass auf einen eigentlich blockierenden Operator (SUM) von anderen
Abfragen später im Abfragegraphen zugegriffen wird.
DEFINE {query name IPDurchsatz}
Select SourceIP, sum(totalLength) as Durchsatz, tb from eth0.TCP
Group by time/60 as tb;
DEFINE {query name topTalker;}
SELECT *
FROM IPDurchsatz
WHERE ((((Select Count(*) From IPDurchsatz as IP_durchsatz_1
Where IP_durchsatz_1.durchsatz < IP_durchsatz.durchsatz)) >=
(SELECT 0.80*Count(*) FROM IPDurchsatz)));
Der zweite Teil der Abfrage ließe sich, wenn ein TOP11 Prädikat in GSQL12 verfügbar wäre,
wesentlich einfacher und benutzerfreundlicher formulieren:
SELECT TOP 20 PERCENT *
FROM IP_durchsatz
ORDER BY IP_durchsatz.Durchsatz DESC;
Der SUM Operator ist eigentlich blockierend und in dieser Konstellation blockiert er auch die
anschliessende Abfrage topTalker. Dieses Problem wird als schwieriger eingestuft, als wenn der
blockierende Operator an der Wurzel des Abfragegraphen steht (vgl. [7] Kap. 4.5). Hier wird es
aufgelöst durch die Gruppierung in Intervalle mittels der time/60 (erzeugt ein-Minuten Intervalle)
Funktion. Der Stream-Manager hat jetzt die Möglichkeit zu entscheiden, ob die erste Abfrage
direkt an der Quelle des Datenstroms, in der LFTA, ausgeführt werden kann (s. Abb. 5) oder ob
diese zu umfangreich ist und später, in einer HFTA, ausgeführt werden muss (vgl. [6] S.52).
Gigascope stellt zusätzlich den Mechanismus der geordneten Attribute bereit, der einen eigentlich
blockierenden Operator, wie z.B. JOIN, in einen Stromoperator umwandelt.
Beispiel:
Join-Abfrage über zwei Datenströme A, B mit dem Attribut ts (timestamp), wobei das Ergebnis
des Joins das karthesische Produkt der zusammengehörigen Tupel im jeweiligen Fenster ist.
Auflistung des Attributes ts in den Datenströmen mit den zugeordneten Werten
ts
1
2
3
4
5
6
A
1
1
3
4
5
6
B
0
2
3
3
5
6
7
8
7
Dabei werden die ersten Ergebnistupel ({Ats3;B.ts3},{A.ts3;B.ts4}) sofort an die
Ausgabeschnittstelle gegeben, wenn in den Datenströmen A und B jeweils ein höherer Wert für
das Attribut ts eintrifft. Dieser passt nicht mehr in das JOIN-Fenster und kann die Ergebnismenge
des JOIN somit nicht mehr verändern. Dieses JOIN setzt voraus, dass die Datenströme geordnet
10
Dieses war die einzige Software, die mir zur Verfügung stand. Das bedeutet, dass die "Group by time/60"Funktion ebenfalls nicht getestet worden ist, sondern nur das erwartete Verhalten nach [5] beschrieben wird.
11
Alternativ LIMIT (MySQL) oder RANK OVER (Oracle)
12
Ich kann es nicht komplett ausschließen, das dieses Prädikat existiert, auch wenn ich in keiner Quelle darauf einen
Hinweis finden konnte.
13
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
in Bezug auf das JOIN-Attribut vorliegen und dass ein Fenster definiert ist, in dem das JOIN
ausgeführt werden kann. Dieses JOIN ist beschränkt auf zwei Eingabedatenströme, kann aber
innerhalb eines definierten Fensters auch einen nicht Equi-JOIN unterstützen (z.B. A.ts-1 <= B.ts
AND B.ts < A.ts+1). Deshalb ist davon auszugehen, dass die Implementierung des JOIN
Operators nicht ausschliesslich auf Hash-Tabellen beruhen kann.
Architekturen
Unter dem Kapitel Architektur wird beschrieben, welche Maßnahmen konkret angewandt
wurden, um die definierten Ziele zu erreichen.
Architektur von Tribeca
Maßnahmen zur Optimierung der Eingabekapazität
Ziel ist es, die Performanz des Systems durch Verzicht auf IO-Operationen zu erhöhen.
Sollte Tribeca aufgrund eines zu hohen Eingangsdatenvolumens überlastet werden, dann werden
Datensätze verworfen, anstatt dass auf langsamere Speichermedien zugegriffen wird.
Tribeca verzichtet auf die Implementierung eines Dateisystems, weil konventionelle
Dateisysteme von der Funktionalität ausreichend und für sequentielle Zugriffe optimiert sind.
Zwischenergebnisse von Abfragen werden in der Größe minimiert. Damit wird verhindert, dass
diese temporär ausgelagert werden müssen, weil kein Hauptspeicher mehr verfügbar ist.
Beim internen Kopieren von Daten werden diese, soweit möglich, nur als Zeiger übergeben, um
Hauptspeicher zu sparen.
Der Hauptspeicher kann flexibel zwischen den Strömen aufgeteilt werden, insbesondere da bei
den meisten Operatoren (z.B. Aggregation) abschätzbar ist, dass die Eingabe deutlich größer ist
als die Ausgabe. Alle Ströme werden im Speicher doppelt gepuffert, so dass gleichzeitig die
Verarbeitung und ein Lesen / Schreiben vorgenommen werden kann.
Umsetzung der Abfragen
Abfragen werden prozedural eingegeben und durch das System in C-Code umgewandelt. Im
Gegensatz zu dem deklarativen GSQL von Gigascope ist hier der Weg zur Abfrage vorgegeben,
so dass keine Umformungen vom System erfolgen müssen.
Erweiterbarkeit des Systems um eigene Operatoren
Durch das Extensible Type System und die Data-Description-Language werden Anwender in die
Lage versetzt eigene Operatoren zu entwickeln. Das System achtet dabei darauf, dass der
Anwender darauf hingewiesen wird, wenn er Operatoren entwickelt, die das Gesamtsystem
ausbremsen würden.
Architektur von Gigascope
Gigascope ist, wie Tribeca, als reine stromverarbeitende Datenbank ausgelegt.
Es ist modular in die Bestandteile Registry, Stream-Manager und Query-Node (LFTA / HFTA)
aufgeteilt. Die Registry und der Stream-Manager bilden dabei das Gerüst, in welches die QueryNodes eingebettet werden, die den eigentlichen Datenempfang und die Datenverarbeitung
14
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
ausführen. Die Registry speichert eine Beschreibung der Daten (Schema), die eine Query-Node
bearbeitet oder zur Verfügung stellt. Der Stream-Manager ist die zentrale Steuerstelle, welche die
einzelnen Datenströme zwischen den verschiedenen Query-Nodes steuert. Er entscheidet, an
welcher Stelle eine Abfrage verarbeitet wird.
HFTAs können komplexere Operationen vornehmen, während die LFTAs hauptsächlich das
Eingangsdatenvolumen reduzieren sollen (s. auch Abb. 5).
Maßnahmen zur Optimierung der Eingabekapazität
Optimierte Größen bei Gigascope
Genauso wie bei Tribeca wurden auch bei Gigascope die I/O-Kosten als der bestimmende Faktor
der Performanz erkannt. I/O-Zugriffe können durch frühzeitige und konsequente Datenreduktion
vermieden werden, wenn das Datenvolumen anschließend komplett im Hauptspeicher verarbeitet
werden kann. Diese Reduktion erfolgt hauptsächlich durch die LFTAs.
Gleichzeitig müssen Zwischenergebnisse ebenfalls minimiert werden, damit sie nicht temporär
ausgelagert werden müssen und somit I/O-Zugriffe auslösen.
Der Einsatz einer deklarativen anstelle einer prozeduralen Abfragesprache kann den Anwender
beim Entwurf neuer Abfragen unterstützen. Der deklarative Ansatz ermöglicht es dem System,
eine optimale Anfragegestaltung vorzunehmen. Das Ziel ist bei Gigascope nicht den Anwender
von komplexen Abfragen abzuhalten, indem es ihm die kritischen Operatoren vorenthält, sondern
die Abfragen möglichst zu optimieren. Allerdings ist auch Gigascope im Sprachumfang im
Vergleich zum konventionellen SQL eingeschränkt (z.B. kein JOIN über mehr als zwei
Eingabedatenströme)
Der Einsatz von "Ordering-Updates" hält die Fenstergröße konstant, auch wenn es aufgrund
unterschiedlich frequenter Eingabedatenströme zu Blockaden kommen könnte. Durch die bei
Bedarf vom System eingefügten Ordnungsmarken verringert sich das Risiko, dass ein Operator
blockiert und deshalb der Hauptspeicher überlastet wird. Dieses wurde am Beispiel des JOIN
Operators gezeigt, der mit Hilfe der "ordering Attributes" entblockiert wird.
Der Stream-Manager sorgt dafür, dass mehrere Auswertungen (Abfragen), die auf dieselbe
Datenbasis zugreifen, gleichzeitig den Datenstrom nutzen können. Der Stream-Manager weiß,
welche Abfrage als Ausgangsbasis für komplexere Abfragen dienen kann. Dieses ist notwendig,
weil es unmöglich ist, den Datenstrom "zurückzuspulen" um die nächste Abfragen
durchzuführen.
Umsetzung der Abfragen
Die Abfragen werden in C / C++ implementiert. Die auf niedrigerer Schicht arbeitenden LFTAs,
also die näher an der Netzwerkschicht arbeitenden Abfragen, sind in C implementiert. Diese zu
verändern, bedeutet einen Neustart des LFTAs. Abfragen auf höherer Schicht, die HFTAs, sind
flexibler in der Ausführung und lassen sich während der Laufzeit verändern.
Erweiterbarkeit des Systems um eigene Operatoren
Eigene Operatoren können direkt als GSQL-Kommando in eine Abfrage übernommen werden.
Diese müssen beim DSMS-System registriert werden und sind danach wie bestehende
Operatoren einsetzbar. Die Optimierungen für diese selbst geschriebenen Operatoren müssen
15
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
allerdings selber vorgenommen werden. Anderenfalls besteht die Gefahr, dass diese Operatoren
das gesamte System abbremsen.
Testverfahren
"Harte" Problemfälle
Das entscheidende Kriterium für DSMS ist, mit welcher Eingabedatenrate sie kooperieren
können, ohne Datensätze zu verlieren, und nicht, in welcher Zeit sie Abfrageergebnisse liefern
können (vgl. [5], S.650).
Abfragen, die über eine reine nicht blockierende Selektion oder Projektion hinausgehen,
erfordern einen hohen Rechenaufwand und stellen entsprechend hohe Ansprüche an CPU und
Hauptspeicherausstattung des Systems. Ebenso ist es aufwendiger, Daten in den höheren OSISchichten eines Paketes zu analysieren, weil das Auffinden der entsprechenden Felder
aufwendiger ist und die höheren Protokolle zumeist komplexer sind.
Versuchsaufbauten
Tribeca und Gigascope wurden jeweils im Vergleich getestet gegen konventionelle
Versuchsaufbauten.
Gigascope sollte aus einem IP-Datenstrom den Anteil der Pakete bestimmen die auf Port 80
arbeiten und tatsächlich HTTP verwenden.
Die Analyse dieser Daten erfordert es, sehr tief in das Datenpaket zu sehen und dort nach einem
eindeutigen Kennzeichen (Zeichenkette) für das HTTP Protokoll zu suchen. Es übersteigt die
Möglichkeiten der Analyse auf der Ebene der Netzwerkkarte (LFTA).
Tribeca hatte die Aufgabe, auf einem gespeicherten Datenstrom von 10 Gigabyte Größe
verschiedene Tests auszuführen. Diese umfaßten unterschiedliche Datentypen (ATM und Frame
Relay) und ein weites Spektrum der verfügbaren Operatoren in Tribeca, um z.B. einen ATM
Datenstrom in die einzelnen Kommunikationsbeziehungen zu unterteilen.
Die Messgrößen, die bei Tribeca getestet wurden, beschränkten sich nicht allein auf die
Eingabemenge an Daten, die pro Sekunde bearbeitet werden konnte, sondern umfasste ebenfalls
die CPU-Last, die die Abfragen erzeugten.
Ergebnisse
Gigascope konnte gegenüber einer herkömmlichen Analyse mit gespeicherten Mitschnitten aus
dem Netzwerk und anschliessender Auswertung annähernd die dreifache Eingabekapazität (ca.
610MBit/s) verarbeiten, ohne dass die Anzahl der verlorenen Pakete über eine definierte Grenze
von 2% anstieg. In einer produktiven Installation wird Gigascope zur Analyse zweier GigabitEthernet-Leitungen eingesetzt, auf denen in Spitzenzeiten bis zu 1,2 Mio. Pakete pro Sekunde
verarbeitet werden müssen.
Tribecca konnte zeigen, dass es gegenüber einem spezialisierten C-Programm lediglich 5%
langsamer war. Die CPU-Auslastung war bei Tribeca ca. 5% höher als bei dem als Vergleich
genutzten Unix-Kopierprogramm "dd".
Interessanterweise kann man teilweise eine Ähnlichkeit in der Entwicklung dieser beiden
Systeme zur Entwicklung von Load-Balancern erkennen, die ebenfalls die Aufgabe haben, IP
Pakete bis in die OSI-Ebene 7 zu analysieren. Die Leistung von frühen Load-Balancern (z.B.
Cisco Local-Director um 1997), die einen Durchsatz von ca. 80Mb/s verarbeiten konnten, konnte
16
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
sich bis 2003 mehr als verzehnfachen (z.B. Cisco Content Switching Module CSM13). Ein CSM
kann mehrere Gigabit-Ethernetanschlüsse und insgesamt bis zu 1,2 Mio. Pakete pro Sekunde
verarbeiten. Dieses entspricht in der reinen Paketanalyse annähernd der Leistung von Gigascope,
ohne jeweils die weiterführenden Abfragen zu betrachten.
Zusammenfassung
Bei beiden vorgestellten Systemen wird eine kontinuierliche Auswertung der Ergebnisse und ein
kontinuierlicher Datenempfang dadurch sichergestellt, dass man die Systeme in der
Funktionalität, wie sie ein konventionelles DBMS bietet, einschränkt. Dieser Verzicht auf
einzelne Operatoren oder Funktionalitäten eines DBMS hilft sicherlich
Geschwindigkeitsprobleme einzudämmen, aber diese Lösung schränkt das Einsatzgebiet
gleichzeitig wieder ein.
Beide Systeme haben einen Schwerpunkt darauf gesetzt, die Flut der zu verarbeitenden Daten zu
minimieren, welches die eigentliche Ursache des gesamten Problems angreift.
Insgesamt stellt ein angepasstes DSMS-System mehr Möglichkeiten in der Verwendung bereit
als ein selbstgeschriebenes handoptimiertes Programm.
Abgesehen von einigen Operatoren, die durch geschickte Implementierungen Auswertungen in
einem Durchgang erzielen können (z.B: Symmetric-Hash-Join statt Nested-Loop), bieten die
meisten hier vorgestellten Optimierungen allerdings "nur" Verbesserungen um einen konstanten
Faktor. Das Datenvolumen wächst nach den meisten Schätzungen dagegen innerhalb der
nächsten Jahre exponentiell. Ob die hier eingeführten Lösungen alleine ausreichen, den stetig
steigenden Datenfluten Herr zu werden, halte ich deshalb für sehr fraglich.
Desweiteren denke ich, dass es interessant wäre zu untersuchen, ob das Konzept, alle Datensätze
auswerten zu wollen, umsetzbar ist. Bereits bei der "einfachen" Analyse der Pakete auf reguläre
Ausdrücke, wie sie ähnlich von spezialisierten Load Balancern ausgeführt wird, könnte es zu
Engpässen kommen. Die Leistungsfähigkeit der Load-Balancer stieg in den letzten Jahren nur
linear an.
Im Umkehrschluss beurteile ich persönlich deshalb die Leistungsfähigkeit der Abfragen in den
vorgestellten Systemen sehr positiv.
Quellenverzeichnis
[1] G. Saake, A.Heuer, K-U Sattler: "Datenbanken:Implementierungstechniken";2. Auflage,
MITP, Bonn 2005
[2] http://www-db.stanford.edu/stream/sqr/netmon.html: "Stream Query Repository: Network Traffic
Management", Stand 20.05.05
[3] M. Schneider: "Implementierungskonzepte für Datenbanksysteme"; Skript zur Vorlesung 1664,
Fernuniversität Hagen WS2004/2005
[4] M.Sullivan, A.Heybey:"Tribeca: A System für Managing Large Databases of Network Traffic" in
Proceedings of the Usenix Annual Annual Technical Conference, New Orleans 1998
[5] C.Cranor, V.Shkapenyuk:"Gigascope: A Stream Database for Network Applications";
[6] N.Koudas and D.Srivastava:"Data Stream Query Processing";AT&T Labs Research Whitepaper
[7] B. Babcock, S. Babu, M. Datar, R. Motwani, and J. Widom.: "Models and issues in data stream
systems"; Principles of Database Systems, 2002.
13
vgl. Datenblätter des Cisco Local Director und Cisco Content Switching Module www.cisco.com
17
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Glossar
ATM (Asynchronous Transfer Mode): ATM ist ein Netzwerkprotokoll welches oftmals von
Telefongesellschaften und Internet Service Providern für die Verbindung von großen Standorten
verwendet wird (Einsatz im Backbone). ATM versendet Pakete fester Länge (Zellen) über
dynamisch schaltbare Kanäle (Virtual-Circuit = VC). Innerhalb eines Kanals bekommen alle
Zellen eine Markierung (VCI=Virtual Circuit Identifier), welche es den paketvermittelnden
Geräten erlaubt, den Weg der Zellen zu bestimmen.
Extensible Type System: Komponente bei Tribeca, die die Definition von Datentypen und
Operatoren ermöglicht. Dieses erhöht die Flexibilität des Systems. Als Beispiel hierfür sind für
unterschiedliche Protokollebenen (L2 / L3: Ethernet Frame / IP Packet) eigene Datenformate
vordefiniert.
Data-Description-Language (DDL): Die DDL erlaubt Manipulationen der zugrundeliegenden
Metadaten. Die DDL stellt einen gekapselten Zugriff auf den Eingabedatenstrom bereit. Sie
erlaubt z.B. Namen für Felder zu vergeben, so dass ein Feld nicht über eine Nummer
angesprochen werden muss.
Local Area Network (LAN): Räumlich begrenztes, performantes Netzwerk. LANs sind zumeist
auf ein Gebäude begrenzt.
Wide Area Network (WAN): Weitverkehrsnetzwerk zur Verbindung mehrer Partner die
räumlich weit voneinander entfernt sind. Die Verbindungsgeschwindigkeiten liegen weit unter
dem was in einem LAN standard ist.
Netflow: Netflow ist ein proprietäres Protokoll der Firma Cisco, welches zusammengefaßte
Daten über Verbindungen enthält. Netflow reduziert das zu analysierende Datenaufkommen an
der Quelle (dem Router, der diese Pakete verarbeitet) signifikant und ermöglicht damit schnellere
Auswertungen die zumeist wieder mit proprietären Anwendungsprogrammen wie NetFlowTracker o.ä. erfolgen.
SNMP (Simple-Network-Management-Protocol): SNMP dient der standardisierten Abfrage
und Überwachung von Netzwerkkomponenten. Per SNMP sind Informationen über den Zustand
einzelner Geräte abfragbar (z.B. Speicherauslastung / CPU-Auslastung / Interface-Auslastung)
TCP/IP : TCP/IP ist das derzeitig meistverbreitete Netzwerkprotokoll. Es ermöglicht den
Versand von Datenpaketen über Routergrenzen hinweg (d.h. Adressierung an Empfänger
außerhalb des eigenen Netzes). In besonderem Maße kennzeichnend für ein IP Paket (s.
Abbildung 1 im Anhang) sind die Felder Quell-und Zieladresse mit denen Absender und
Empfänger beschrieben werden. Ebenso wichtig sind die Felder Quell- und Zielport, mit denen
die verwendete Applikation gekennzeichnet wird. Ein Datenstrom ist aufgrund von speziellen
Anfangs- und Endezeichen klar erkennbar.
18
Torben Schrader, Thema 1: Motivation für Stromverarbeitung: Analyse von Netzwerkverkehr
Anhang
TCP/IP Paketmitschnitt
Abb1. zeigt den Ausdruck von einer mitgeschnittenen TCP/IP Kommunikation. Im mittleren
Rahmen werden die einzelnen Felder eines TCP/IP Pakets dargestellt.
19