Haage&Partner HAAGE&PARTNER

Sawmill Support


Optimierung der Datenbankgröße

Sawmill liest Logdaten und speichert diese in einer Datenbank. Die Reports werden auf den Daten der Datenbank erstellt. Die Datenbank enthält dabei alle Informationen der original Logdateien und zusätzlich viele “abgeleitete” Daten: abgeleitete Felder (z.B. das Land, das über die IP-Adresse aus den Logdaten ermittelt wurde), Kreuzreferenztabellen (für den schnelleren Reportaufbau) und Indices (für schneller gefilterte Reports). Bei großen Mengen an Logdaten kann dies zu sehr großen Datenbanken führen. In bestimmten Grenzen ist dies unabdingbar: um schnell Reports mit allen Filterkombinationen darstellen zu können, müssen alle Informationen in der Datenbank abgelegt sein - die Datenbank hat dann die Größe der eingelesenen Logdaten plus der abgeleiteten Informationen. In der Praxis wird die Datenbank bei Verwendung der Standardeinstellungen mit allen Details 2-4x so groß wie die unkomprimierten Logdaten.

Wenn der benötigte Speicherplatz kein Problem darstellt, dann kann die Datenbank mit den Standardeinstellungen betrieben werden. Wird der Speicherplatz aber knapp, dann gibt es eine Reihe von Maßnahmen, um die Datenbankgröße zu reduzieren. Diese können in zwei Kategorien unterteilt werden: Reduzierung auf Kosten der Performance bei der Reporterstellung oder durch Reduzierung der enthaltenen Informationen.



Kategorie 1: Reduzierung der Datenbankgröße auf Kosten der Performance

Diese Optimierungen verringern einige speicherintensive Caches und geschwindigkeitsoptimierende Strukturen der Datenbank. Das Entfernen und Vereinfachen dieser Strukturen begrenzt den benötigten Speicherplatz für die Datenbank, verlangsamt aber die Erstellung der Reports.

1.1 Entfernen von Indices | Indices verbessern die Performance bei der Suche nach bestimmten Werten in der Datenbank. Sie werden zur Filterung verwenden, beispielsweise wenn man bei Webseiten eine Seite auswählt und sich dann denn Verlauf nach Tagen anzeigen lässt. Mit dem Index wird der Report schneller angezeigt. Die Indices lassen sich für jedes Datenbankfeld abschalten (Config -> Database Fields). Die Datenbankgröße wird dann bei Neuaufbau reduziert, Reports werden aber langsamer angezeigt.

1.2 Entfernen von Kreuzreferenzgruppen (XRef) | Kreuzreferenzgruppen sind Strukturen für vorberechnete Top-Level-Reports. So hat beispielsweise der Report “Dateitypen” einen Kreuzreferenztabelle, durch die Reports sehr schnell laden (tatsächlich werden die Kreuzreferenzengruppen beim Einlesen der Logdaten erstellt und müssen nicht durch komplexe Abfragen erstellt werden). Die Kreuzreferenzgruppen können in Config -> Cross Reference Groups deaktiviert oder gelöscht werden. Das Deaktivieren oder Löschen von Kreuzreferenzgruppen reduziert die Datenbankgröße (nach dem Neuaufbau), verlangsamt aber die Top-Level-Reports, die die entsprechenden Felder der Gruppen verwenden.

1.3 Reduzieren der Kreuzreferenzgruppen | Wie im vorherigen Beitrag sind hier die Kreuzreferenzgruppen betroffen, doch werden diese nicht komplett entfernt, sondern nicht-hierarchisch angelegt. Dies wird unter Config -> Cross Reference Groups gruppenweise vorgenommen. Nicht-hierarchische XRef-Gruppen benötigen weniger Platz als hierarchische Gruppen, aber die Reportausgabe wird langsamer, besonders dann, wenn im Report Einträge verarbeitet werden, die sich nicht unten in der Hierarchie befinden, wie Verzeichnisse (in einem “Webseiten”-Report) oder Monate oder die Übersicht. Das Reduzieren der Kreuzreferenzgruppen reduziert die Datenbankgröße (nach einem Neuaufbau), verlangsamt aber einige Top-Level-Reports.

1.4 Dateisystem komprimieren | Einige Dateisysteme, wie NTFS (ab Windows NT), bieten ein Option zur Komprimierung. Die Komprimierung des Sawmill-Datenbankordners auf Dateisystemebene wird die Größe um 50% reduzieren, ohne die Vollständigkeit der Daten zu beeinträchtigen. Die Performance kann davon allerdings stark beeinträchtigt werden, so dass Sawmill um ein vielfaches langsamer wird. Daher sollte diese Option nur verwendet werden, wenn die Performance eine untergeordnete Rolle spielt.



Kategorie 2: Reduzierung der Datenbankgröße durch Reduzieren der enthaltenen Informationen

Diese Optimierungen entfernen Informationen aus der Datenbank. Da die Datenbankgröße proportional zur enthaltenen Informationsmenge ist, reduziert das Entfernen von Informationen direkt die Größe der Datenbank. Je nach Reduzierungsmethode sind jedoch einige Reports nicht verfügbar oder Details fehlen, die in der vollständigen Datenbank verfügbar wären.

2.1 Optimieren der Größe der Datenbankfelder | Die meisten Felder in der Sawmill-Datenbank sind Integer-Werte. Integer haben die Größen 8, 16, 32 und 64 Bit. Je mehr Bits ein Feld hat, desto mehr Speicherplatz wird in der Datenbank benötigt und je höher können die Werte im Feld sein. Die Größe kann unter Config -> Database Fields pro Datenbankfeld eingestellt werden. Standardmäßig verwendet Sawmill auf 32-Bit-Betriebssystemen 32-Bit-Integerwerte und auf 64-Bit-Systemen 64-Bit-Integerwerte. Dies ist besonders auf 64-Bit-System oft übertrieben, denn ein Feld wie “Dateitypen”, das normalerweise weniger als 100 Werte enthält, wären 8 Bit völlig ausreichend. Das Reduzieren des Dateityp-Feldes von 64 auf 8 Bit ist eine Reduzierung des Datenbankplatzes um den Faktor 8, ohne Kosten. 8 Bit können 256 Werte speichern, 16 Bit rund 65.000, 32 Bit bis rund 4 Millionen und 64 Bit hhhhh. Wenn Sie die Anzahl der Werte für jedes Feld bestimmen können (die Anzahl der Reihen in einem Report bietet eine gute Grundlage für die Abschätzung) dann können Sie die Felder verkleinern. Das Gleiche können Sie für nummerische Felder wie “Events”, “Hits” oder “Pageviews” durchgeführt werden, aber hier muss das Feld groß genug für den Summenwert sein (aus Sicherheitsgründen sollten Sie bei Werten über 1 Million 64 Bit verwenden).

2.2 Reduzierung der Logdateien | Wenn Sie beim Einlesen die Hälfte der Einträge entfernen, wird die Datenbank nur noch rund halb so groß sein. Wenn also die Logquelle überflüssige Informationen enthalten, wie beispielsweise einen Zeitraum, der nicht benötigt wird oder Logdateien von einem Server, der nicht relevant ist, dann entfernen Sie diese Dateien und reduzieren Sie so die Datenbankgröße.

2.3 Logdaten ausfiiltern | Diese Methode entfernt bestimmte Ereignisse von der Datenbank, indem Logzeilen beim Einlesen verworfen werden. Wenn beispielsweise ein Webserverlog eine Million Zeilen enthält und 700.000 davon “non-page” Zeilen, wie Bilder oder Scripte sind. Wenn man sich nur für die Pageviews interessieren, dann kann man mit einem entsprechenden Logfilter die überflüssigen Logzeilen verwerfen. Die Beispieldatenbank hätte dann nur noch 300.000 Einträge und wäre 70% kleiner als die komplette Datenbank. Allgemein kann jede Ereigniskategorie, die im Report nicht benötigt wird, ausgefiltert werden, um Speicherplatz zu sparen.

2.4 Datenbankfelder entfernen | Eine Datenbank enthält viele Felder, beispielsweise für ein Proxy-Log Source-IP, Datum/Zeit, URL, MIME-Typ und Dutzende andere. Wenn es ein Feld gibt, dessen Inhalt nicht von Interesse ist, dann sollte man es aus der Datenbank entfernen, indem man es unter Config -> Database Fields (nach einem Neuaufbau) löscht und somit die Datenbankgröße reduziert. Um festzulegen, welche Felder entfernt werden können, kann man mit der “Zusammenfassung” [Single-page Summary] beginnen und sich die Reportelemente oder Spalten ansehen, die nicht benötigt werden und diese Felder entfernen.

2.5 Datenbankdaten entfernen | Das Vorgehen ist ähnlich dem Reduzieren der Logdateien, erfolgt aber im Nachhinein. Mit der Option “Remove Database Data” in Admin -> Scheduler können Daten aus der Datenbank entfernt werden, normalerweise solche älter als ein bestimmtes Datum. Beispielsweise kann beim nächtlichen Datenbankupdate die aktuellen Logdaten eingelesen und gleichzeitig der älteste Tag aus der Datenbank entfernt werden, wodurch die Datenbank praktisch eine feste Größe hat. Ein wichtiger Hinweis an dieser Stelle: Beim Entfernen von Datenbankdaten wird temporär eine Kopie der Haupttabelle der Datenbank erstellt, bevor die Datenbankgröße reduziert wird. Man muss daher sicherstellen, dass ausreichend Speicherplatz auf dem Datenträger vorhanden ist.



Informationen

Versionen: Lite, Professional, Enterprise

Plattformen: Windows, Macintosh, Linux, FreeBSD, Solaris u.a.

Unterstützte Logformate: über 900

Sprachen: mehrsprachig (DE, EN u.a.)

Preise: ab 210 EUR (inkl. MwSt.)

Preise für Vollversionen

Informationen zu Upgrades & Optionen



Exklusiv bei H&P

Die aktuellen deutschen Versionen und deutschsprachigen Support erhalten Sie exklusiv nur bei H&P. » mehr