177 lines
14 KiB
TeX
177 lines
14 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!
|
|
|
|
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.
|
|
Für die automatische Ausführung kann der maximal verwendete Speicher über die Einstellung \textbf{autovacuum\_work\_mem} gesondert
|
|
eingestellt werden \citep{PostgresPro:Chap20.4:2023}.
|
|
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.
|
|
|
|
Des Weiteren können über das Modul \texttt{pg\_stat\_statements} Statistiken über die Aufrufe die an den Server gestellt wurden,
|
|
ermittelt werden \citep{PostgresF27:2023}. Hierbei kann ermittelt werden, welche der Anfragen am häufigsten gerufen werden und
|
|
welche die längsten Laufzeiten besitzen.
|
|
|
|
% MÜllerWehr2012
|
|
Die JPA wird als First-Level-Cache in Java-EE-Anwendung gehandhabt.
|
|
Hierbei nehmen die Objekte einen von 4 Zuständen ein \citep[57]{MüllerWehr2012}.
|
|
Im \textbf{Transient} sind die Objekt erzeugt, aber noch noch in den Cache überführt worden.
|
|
Wenn Sie in den Cache überführt wwerden, nehmen sie den Zustand \textbf{Verwaltet} ein.
|
|
Für das löschen eines Objektes gibt es den Zustand \textbf{Gelöscht}, wodurch auch das Objekt
|
|
aus der Datenbank entfernt wird.
|
|
Als letzten Zustand gibt es noch \textbf{Losgelöst}, hierbei wird das Objekt aus dem Cache
|
|
entfernt, aber nicht aus der Datenbank.
|
|
|
|
Eine Menge von Objekten wird als \textit{Persistenzkontext}. Solange die Objkte dem Persistenzkontext
|
|
zugeordnet sind, also den Zustand Verwaltet besitzen, werden diese auf Änderungen überwucht
|
|
um diese am Abschluss mit der Datenbank zu syncronisieren. In der Literatur nennt man das
|
|
\textit{Automatic Dirty Checking} \citep[61]{MüllerWehr2012}.
|
|
|
|
In den Java-EE-Anwendungen wird der Persistenzkontext für die Anfragen vom Application-Server
|
|
bereitgestellt. Hierfür werden Application-Server wie GlassFish\textbf{!!!URL!!!} genutzt,
|
|
um die Verwendung eines Pools von Datenbankverbindungen zu definieren \citep[68]{MüllerWehr2012}.
|
|
Hiermit kann die Anzahl der Verbindung geringer gehalten werden als die Anzahl der Benutzer die
|
|
an der Anwendung arbeiten.
|
|
Zusätzlich werden die Transaktionen über Stateful Session-Bean (SFSB) gehandbabt, die automatisch
|
|
vor dem Aufruf erzeugt und danach wieder gelöscht werden. Dies hat allerdings den Nachteil,
|
|
dass der Persistenzkontext sehr groß werden kann, wenn viele Entities in den Persistenzkontext
|
|
geladen werden. Da dies häufig zu Speicher- und damit Performan-Problemen \citep[79]{MüllerWehr2012}
|
|
führt, muss hier darauf geachtet werden, nicht mehr benötigte Entities aus dem Persistenzkontext
|
|
lösen, oder den Transaktionskontext aufzuteilen \citep[172]{MüllerWehr2012}.
|
|
|
|
Zusätzlich kann hier ebenfalls noch der \textit{Second Level Cache} (L2-Cache) aktiviert werden.
|
|
Dieser Cache steht jedem Persistenzkontext zur Verfügung und kann dadurch die Anzahl der
|
|
Datenbankzugriffe deutlich reduzieren, was bei langsamen Datenbank-Anbindungen zu hohen
|
|
Performance-Gewinnen führen kann \citep[171]{MüllerWehr2012}.
|
|
Engegen der Verwendung spricht, dass die Daten im Second Level Cache explizit über Änderungen
|
|
informiert werden müssen, sonst werden beim nächsten Laden wieder die alten Werte geliefert.
|
|
Ebenfalls benötigt so ein Cache einen höheren Bedarf an Arbeitsspeicher, in diesem dann die
|
|
Daten parallel zur Datenbank bereitgestellt werden.
|
|
Daher ist die Benutzung nur problemlos bei Entities, auf die meist lesend zugeriffen werden.
|
|
|
|
In der OpenJPA-Erweiterung für den Second Level Cache, wird in Objekt-Cache
|
|
(in OpenJPA als \textit{DataCache} bezeichnet) und Query-Cache unterschieden.
|
|
Über die Funktionen \texttt{find()} und \texttt{refresh()} oder einer Query werden die
|
|
geladenen Entities in den Cache gebracht. Davon ausgenommen sind \textit{Larg Result Sets}
|
|
(Abfragen die nicht alle Daten auf einmal laden), \texttt{Extent}-Technologien und Queries,
|
|
die einzelne Attribute von Entities zurückliefern, aber nicht das Entity selbst.
|
|
Hierbei kann genau gesteuert werden, welche Entity in den Cache abgelegt wird und
|
|
welche nicht. Ebenfalls kann auf Klassenbasis der zugehörige Cache definiert werden, um
|
|
eine bessere Last-Verteilung beim Zugriff zu ermöglichen \citep[314]{MüllerWehr2012}.
|
|
|
|
Im Query-Cache werden die Abfragen bzw. die Eigenschaften einer Abfragen und die
|
|
zurückgelieferten Ids der Entities gespeichert. Bei erneutem Aufruf dieser Abfrage
|
|
werden die referenzierten Objekte aus dem Objekt-Cache zurückgegeben. Bei veränderten
|
|
referenzierten Entities wird der Query-Cache nicht benutzt und die betroffenen Abfragen
|
|
werden unverzüglich aus dem Query-Cache entfernt \citep[316]{MüllerWehr2012}.
|
|
|
|
Um zu prüfen ob die Einstellungen sinnvoll gesetzt sind, gibt es eine Cache-Statistik.
|
|
Mit diesen kann überprüft werden, wieviel Lese- und Schreibzugriffe im Cache durchgeführt wurden,
|
|
Entsprechend dieser Auswertung sollten die Einstellungen angepasst werden \citep{IbmOpenJPACaching2023}.
|
|
|
|
% Konversationen (Aufteilung von Transaktion, Seite 172)
|
|
|
|
|
|
% 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.
|