
\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.
