116 lines
9.2 KiB
TeX
116 lines
9.2 KiB
TeX
|
|
\chapter{Expose}
|
|
\label{ch:intro}
|
|
|
|
\section{Ausgangslage}
|
|
Die Editions- und Forschungsstelle Frank Wedekind (EFFW) wurde 1987 in der Hochschule Darmstadt gegründet. Ihr Intention
|
|
ist es, den lange vernachlässigten Autor der europäischen Moderne in die öffentliche Aufmerksamkeit zu bringen. Die
|
|
Publikation der >>Kritischen Studienausgabe der Werke Frank Wedekinds. Darmstädter Ausgabe<< im Verlag Jürgen Häuser
|
|
wurde 1994 direkt nach der Erschließung der Wedekind-Nachlässe in Aurau, Lenzburg und München begonnnen und im Jahre
|
|
2013 abgeschlossen (8 Bände in 15 Teilbänden, jetzt in Wallstein Verlag). Die EFFW wurde im Sommer 2015 an die
|
|
Johannes Gutenberg-Universitt Mainz umgezogen.
|
|
|
|
Da Frank Wedekind heute zu einem der bahnbrechendenen Autoren der literarischen Moderne zählt, aber bisher sehr
|
|
wenig erforscht wurde, soll sich diese nun Ändern. Die nationalen und internalen Korrespondenzen von und an Wedekind
|
|
zeigen eine starke Vernetzung in der europäischen Avantgard. Dies zeigt das die Wssenschaft um die Korresponedenzen
|
|
von Wedekind eine immer größere Rolle spielen. Aktuell sind lediglich 710 der 3200 bekannten korrespondenzstücke
|
|
veröffentlich worden.
|
|
|
|
Um diese zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online-Volltextdatenk<< \citep{EffwFrankWedekind},
|
|
welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der Johannes Gutenberg-Universität Mainz, der
|
|
Hochschule Darmstadt und der Fernuni Hagen umgesetzt wird und durch die Deutsch Forschungsgemeinschaft (Bonn)
|
|
gefördert wird.
|
|
|
|
Hierbei werden sämtliche bislang bekanten Korrespondenz in die Online-Edition überführt. Diese Korrespondenz
|
|
beinhaltet substantiell das literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880 und 1918,
|
|
indem das überlieferte Material zum einen transkribiert editiert und editionswissenschaftlich kommentiert wird.
|
|
Und zusätzlich durch Kommentar die den historischen Kontexten inhaltlich erschließen.
|
|
|
|
Hierfür entstand das Pilotprojekt der Online-Volltextdatenbank für Briefe von und an Frank Wedekind, welches 2015
|
|
als Beta-Version freigeschalten wurde. Diese Projekt kann aktuell unter http://briefedition.wedekind.h-da.de eingesehen
|
|
werden.
|
|
|
|
Die benutzerfreundliche Erfassung und Annotation der Briefe, ist eines der Hauptziele der konzeptionierten technischen
|
|
Architektur. Die ist der Grund, warum die Präsentation-, Recherche- und Erstellungsebene vollständig webbasiert umgesetzt
|
|
wurde. Die Briefe selbst, werden im etablierten TEI-Format gespeichert. Dies muss von den Editoren und Editorienen nichst
|
|
selbst eingegeben werden, sondern kann über einen entstandenn WYSIWYG-Editor direkt eingegebenw werden, welcher es bei
|
|
der Speicherung in das TEI-Format wandelt. Ebenfalls wurde hierbei auf eine modulare und unabhängige Architektur geachtet,
|
|
wodurch die Komponenten im Nachgang auch von anderen Briefeditionen genutzt werden können.
|
|
|
|
\section{Ziel}
|
|
% Anm: in dem Abschnitt vermischen Sie Ziele und Vorgehen
|
|
Die aktuelle Umsetzung beinhaltet die bisher definierte Anforderungen komplett. Darunter fallen die Recherchemöglichkeiten,
|
|
sowie auch die EIngabe und die Verarbeitung der Briefe. Ein größeres Problem hierbei ist die Performance der Oberfläche.
|
|
Durch die langen Abfragedauern des Datenbestandes leidet die aktzeptanz der Anwendung.
|
|
|
|
Das Ziel der Arbeit ist es, die Abfragedauern zu verringern, wodurch die Performance der Oberfläche signifikant verbessert
|
|
wird. Anhand der Quellen müssen hierfür die Abfragen ermittelt und bewertet werden. Die Abfragen mit den höchsten
|
|
Zeitbedarf werden dann analysiert und optimiert.
|
|
|
|
Hierbei ist auch ein Vergleich mit anderen Technologien angedacht.
|
|
|
|
\section{Aktueller Forschungsstand}
|
|
% Anm: (dazu schreiben Sie gar nichts!) Genau das ist Ihre Aufgabe im Rahmen des Reading Courses die aktuelle Literatur - sei es in der Forschung, in Lehrbüchern, in
|
|
% Systemliteratur etc. zum Thema Performance-Optimierung zu recherchieren, zu analysieren und den State of the Art zu beschreiben!
|
|
|
|
% Aktell 3546-1.pdf Page 404
|
|
|
|
Die Speicherveraltung des PostgreSQL-Server muss für Produktivsysteme angepasst werden \citep[34-38]{Eisentraut2013}.
|
|
Hierunter fallen die \textbf{shared\_buffers} die bei
|
|
ca. 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen sollte, mit dieser wird das häufige schreiben des Buffers durch Änderung
|
|
von Daten und Indexen auf die Festplatte reduziert.
|
|
Die Einstellung \textbf{temp\_buffers} die definiert wie groß der Speicher für temporäre Tabellen pro Verbindung maximal werden darf, sollte
|
|
ebenfalls überprüft werden, da ein zu kleiner Wert bei großen temporären Tabellen zu einem signifikanten Leistungseinbruch führt, wenn
|
|
die Tabellen nicht im Hauptspeichern sondern in einer Datei beareitet werden.
|
|
Der \textbf{work\_mem} definiert die Obergrenze des zur Verfügung gestellt Hauptspeichers pro Datenbankoperation wie effizientes Sortieren,
|
|
Verknüpfen oder Filtern. Auch wird im Falle eines zu klein
|
|
gewählten Speichers auf temporäre Dateien auf der Festplatte ausgewichen, was ebenfalls zu signifikaten Leistungsinbrüchen führt.
|
|
Die \textbf{maintenance\_work\_mem} wird bei Verwaltungsoperation wie Änderung und Erzeugung von Datenbankobjekten als Obergrenze definiert.
|
|
Aber auch für die Wartungsaufgaben \textbf{Vacuum}, die fragmentierte Tabellen aufräumt und somit die performance hebt. Welche Regelmässig
|
|
durchgeführt werden sollte.
|
|
|
|
Die Wartung des Datenbanksystemes ist eine der wichtigen Aufgaben und sollte regelmässig durchgeführt werden, damit die Performance des
|
|
Systems durch die Änderung des Datenbestandes nicht einbricht \citep[75]{Eisentraut2013}. Hierfür gibt es den \textbf{VACUUM}-Befehl, der
|
|
entweder per Hand oder automatisch durch das Datenbanksystem ausgeführt werden soll.
|
|
Neben dem aufräumen durch \textbf{VACUUM} sollten auch die Planerstatistiken mit \textbf{ANALYZE} \citep[83]{Eisentraut2013} aktuell
|
|
gehalten werden. Damit die Anfragen durch den Planer richtig optimiert werden können.
|
|
Für beide Wartungsaufgaben gibt es den Autovacuum-Dienst. Dieser sollte aktiv und richtig konfiguriert sein.
|
|
|
|
Mit dem Tool \textbf{pgFouine} \citep[155]{Eisentraut2013} können die Logs des PostgreeSQL Server im Nachgang analysiert werden und auf
|
|
Probleme hin untersucht werden. Hiermit kann sehr einfach die häufigsten bzw. langsamsten Anfragen ermittelt werden.
|
|
|
|
Für weitere Optimierungen müssen dann die Anfragen einzeln überprüft werden. Hierfür ist es sinnvoll die Ausführungspläne der Abfrage
|
|
zu analysieren \citep[252]{Eisentraut2013}. Hierbei ist es wichtig die verschiedenen Plantypen und ihre Kosten zu kennen, sowie die
|
|
angegeben Werte für die Plankosten zu verstehen. Hinzu kommt noch, dass man den tatsächlich ausgeführten Plan mit dem ursprünglichen
|
|
Plan vergleichen sollte \citep[254]{Eisentraut2013}. Eine er wichtigsten Aussage hierbei ist, ob die Zeilenschätzung akkurat war.
|
|
Größere Abweichung weißen häufig auf veraltete Statistiken hin.
|
|
|
|
|
|
\citep[60]{MüllerWehr2012}
|
|
|
|
% Zum ende noch, warum wird das gemacht? => Weil Datenbank-Definition immer unterschiedlich sind, und die Optimierung an den entsprechenden
|
|
% Datenbestand angepasst werden muss
|
|
|
|
\section{Vorgehen bei der Umsetzung}
|
|
% Anm: eine mögliche Vorgehensweise. Bei der Beschreibung der Vorgehensweise beziehen Sie sich dann natürlich auf den oben beschrieben Stand in Forschung und Technik
|
|
Zuerst werden alle Abfragen ermittelt und deren Performance in Abhängigkeit der Häufigkeit der Aufrufe und Datenmengen
|
|
bestimmt. In der Auflistung werden dann die 5-7 Anfragen bestimmt, bei dennen die größten Performance-Optimierungen möglich
|
|
ist. Diese Abfragen werden dann genauer untersucht. Hierbei werden verschiedene Blickwinkel betrachtet um die Performance
|
|
zu optimieren.
|
|
|
|
Darunter fallen zum einen die Cache-Algorithmen der JDBC-Engine, sowie auch die Einstellungen am Datenbanksystem. Hierbei
|
|
ist noch ein besonderes Augenmerk auf die vorhandene Serverkonstellation mit zu beachteten, da diese enormen Einfluss auf
|
|
die Einstellungen bewirkt. Ebenso werden die Aufrufe im ganzen überprüft und untersucht um zu prüfen ob die Anfragen sich
|
|
gegenseitig durch Transaktionen oder Locks sperren. Hierfür wird ebenfalls die interne Protokolierung der Aufruf aktiviert
|
|
und dessen Ausgabe untersucht und analysiert.
|
|
|
|
Danach werden die Abfrage selbst untersucht und auf Optimierungen überprüft. Hierbei wird als erstes der Aufruf
|
|
der Abfrage betrachtet. Dann wird die Abfrage selbst genauer untersucht. Dabei wird beachtet ob die Anfragen selbst viel
|
|
Zeit für die Bearbeitung benötigen oder auf Ressourcen warten. Zum anderen wid geprüft ob durch gezielte Umstellung oder
|
|
Einfügen von Zwischenergebnissen schnellere Abfragen möglich sind, Wie es in der Abhandlung "Optimizing Iceberg
|
|
Queries with Complex Joins" \cite{10.1145/3035918.3064053} gezeigt wird. Zum Schluss werden noch die Afragekriterien
|
|
und die vorhanden, beziehungsweise genutzen, Indizierungen überprüft.
|
|
|
|
Als letztes wird noch die Art des Aufrufes betrachtet. Hierbei wird die Art und Weise der Aufrufe genauer betrachtet. Ob
|
|
zum Beispiel eine vorhandene Anfrage mehrfach verwendet wird und diese besser auf 2 ähnliche Abfrage aufgeteilt werden
|
|
kann. Oder ob an den Stellen ein Paging eingebaut werden kann, um die Datenmengen zu reduzieren.
|