Daily CheckIn

.vscode/settings.json

@@ -84,6 +84,7 @@
         "fmtutil",
         "gpasswd",
         "hcap",
+        "heapsort",
         "historicalperson",
         "ispublishedindb",
         "javax",

chapters/thesis/chapter03.tex

@@ -123,7 +123,7 @@ Die Abfragen werden ebenfalls untersucht und mit verschiedenen Methoden optimier
 SQL"=Anfragen umgestellt und die Ausführungszeiten überprüft. Ebenfalls werden die Abfragen durch Criteria API erzeugt
 und dessen Ausführungszeit ermittelt.
 
-Zusätzlich werden im SQL-Server Optimierungen vorgenommen, darunter zählen die Materialisierten Sichten, welche eine 
+Zusätzlich werden im SQL-Server Optimierungen vorgenommen, darunter zählen die \textit{Materialized View}, welche eine 
 erweiterte Sicht ist. Neben der Abfrage der Daten beinhalteten diese auch noch vorberechneten Daten der Abfrage, womit 
 diese viel schneller abgefragt werden können. Zusätzlich werden die cached queries überprüft ob diese eine Verbesserung 
 der Performance und der Abfragedauern verkürzen können.

chapters/thesis/chapter04.tex

@@ -132,10 +132,11 @@ zusammengesetzten Index von Bedeutung. Als Grundlage sollte hier mit der Spalte
 Einschränkung durchführt. Zusätzlich muss die Art des Index definiert werden, welche davon abhängig ist, mit welcher 
 Vergleichsoperation auf die Tabellenspalte zugegriffen wird.
 
-Um größere und aufwendige Abfragen zu optimieren, bietet der PostgreSQL noch die Möglichkeiten von Materialisierten 
+Um größere und aufwendige Abfragen zu optimieren, bietet der PostgreSQL noch die Möglichkeiten von 
-Sichten. Diese sind sehr ähnlich zu Sichten, speichern zusätzlich die Ergebnisse in einer tabellenähnlichen Form ab.
+\textit{Materialized View}. Diese sind sehr ähnlich zu Sichten, speichern zusätzlich die Ergebnisse in einer 
-Somit sind die Zugriff auf diese Daten häufig performanter als die eigentliche Abfrage. Die Performance wird durch
+tabellenähnlichen Form ab. Somit sind die Zugriff auf diese Daten häufig performanter als die eigentliche Abfrage. 
-die zusätzliche Aktualisierung des Datenbestand erkauft und muss daher abgewägt werden, was sinnvoller ist.
+Die Performance wird durch die zusätzliche Aktualisierung des Datenbestand erkauft und muss daher abgewägt werden, 
+was sinnvoller ist.
 
 \mytodos{das doch wieder raus? oder nur das mit create statistics drin lassen}
 

chapters/thesis/chapter05.tex

@@ -3,6 +3,8 @@
 \chapter{Performance-Untersuchung der Anwendung}
 \label{ch:performance-investigation-application}
 
+\mytodos{Sortierung nochmal überlegen, sinnvoller wäre doch anhand der Schichten aus Kapitel 2}
+
 Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance"=Verbesserungen untersucht und deren
 Vor"= und Nachteile herausgearbeitet.
 
@@ -64,7 +66,7 @@ gehalten werden sollten.
 
 Vor jedem weiteren Test-Lauf wurde die Domain beendet und komplett neugestartet, um mit einer frischen Instanz zu
 beginnen. Hierbei ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehört haben, unabhängig von den
-konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstellen der Materialisierten Sichten
+konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstellen der \textit{Materialized View}
 \textit{searchreference} und \textit{searchfulltext} erklärbar. Zusätzlich ist noch ein zyklischer Dienst
 \textit{SearchEntityService} vorhanden, der zum Start und alle sechs Stunden den Datenbestand für die Suche aufbereitet
 und entsprechend einige Abfragen an die Datenbank absetzt. Da weder die Sichten noch der Dienst für die Dokumentenliste
@@ -112,6 +114,8 @@ zu laden, und in die Java-Objekte umzuformen.
 \section{Umgestalten der Datenbanktabellen}
 \label{sec:performance-investigation-application:new-table}
 
+\mytodos{Sollte das nicht auch in die Evaluierung?}
+
 Hierfür wurde die aktuelle Datenstruktur untersucht um zu prüfen, ob eine Umgestaltung der Tabelle einen Verbesserung
 bringen würden. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell
 schon normalisiert, daher kann hier nichts weiter optimiert werden.
@@ -476,8 +480,8 @@ Geschwindigkeit optimiert.
 \section{Materialized Views}
 \label{sec:performance-investigation-application:materialized-views}
 
-Materialized Views sind Sichten in der Datenbank, die beim erstellen der Sicht den aktuellen Zustand ermitteln und
+\textit{Materialized Views} sind Sichten in der Datenbank, die beim erstellen der Sicht den aktuellen Zustand ermitteln 
-Zwischenspeichern. Somit wird beim Zugriff auf diese Sichten, nicht die hinterlegte Abfrage ausgeführt, sondern auf
+und Zwischenspeichern. Somit wird beim Zugriff auf diese Sichten, nicht die hinterlegte Abfrage ausgeführt, sondern auf
 die gespeicherten Daten zugegriffen. Dies ist gerade bei vielen Joins von Vorteil. Zusätzlich können auf solchen
 Sichten auch Indexe erstellt werden, um noch effektiver die Abfragen bearbeiten zu können.
 
@@ -485,12 +489,12 @@ Der größte Nachteil dieser Sichten ist, dass sie zyklisch oder bei Datenänder
 läuft der Datenbestand der Sicht und der zugrundeliegenden Abfrage auseinander. Da die Hauptarbeiten auf der Webseite
 die Abfrage der Daten ist, und nicht das editieren, kann dieser Nachteil bei entsprechender Optimierung ignoriert werden.
 
-In diesem Test wurde die aktuelle Implementierung aus dem Wedekind"=Projekt der Materialized View inklusive der Trigger 
+In diesem Test wurde die aktuelle Implementierung aus dem Wedekind"=Projekt der \textit{Materialized View} inklusive 
-und der \textit{SearchDocument}"=Klasse übernommen \citep{Dokument53:online}. Wie in \autoref{lst:sql-materialized-view} 
+der Trigger und der \textit{SearchDocument}"=Klasse übernommen \citep{Dokument53:online}. Wie in 
-zu sehen, wurden zur Standard"=Abfrage, die sonst zusätzlichen Abfragen als direkte Sub"=Selects mit integriert. Der 
+\autoref{lst:sql-materialized-view} zu sehen, wurden zur Standard"=Abfrage, die sonst zusätzlichen Abfragen als 
-Datenbestand dieser Sub"=Selects, wird im Json"=Format angegeben, damit bei den Koautoren und den Adressen mehrere 
+direkte Sub"=Selects mit integriert. Der Datenbestand dieser Sub"=Selects, wird im Json"=Format angegeben, damit bei 
-Datensätze in einer Zeile zurückgegeben werden können. Ohne diese Technik würde sich die Anzahl der Dokumente 
+den Koautoren und den Adressen mehrere Datensätze in einer Zeile zurückgegeben werden können. Ohne diese Technik würde 
-vervielfachen.
+sich die Anzahl der Dokumente vervielfachen.
 
 \begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view]
 CREATE MATERIALIZED VIEW searchdocument AS
@@ -624,9 +628,9 @@ vorhanden Elemente die die Liste der Dokumente anzeigt kopiert und auf die \text
     \label{tbl:measure-materialized-view}
 \end{table}
 
-Wie in \autoref{tbl:measure-materialized-view} zu sehen, bringt die Verwendung der Materialized View eine Verbesserung
+Wie in \autoref{tbl:measure-materialized-view} zu sehen, bringt die Verwendung der \textit{Materialized View} eine 
-in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zusätzlich fällt der
+Verbesserung in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zusätzlich fällt 
-Speicheranstieg weniger stark aus. Die Verbesserung der Aufrufzeiten lässt sich zusätzlich erklären, dass hier nun
+der Speicheranstieg weniger stark aus. Die Verbesserung der Aufrufzeiten lässt sich zusätzlich erklären, dass hier nun
 nur noch vier statt der 6 Abfragen an die Datenbank gestellt werden, da die Einzelabfragen für die Adressen der 
 Personen und der Koautoren komplett entfallen.
 
@@ -663,8 +667,8 @@ Nach dem Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-material
     \label{tbl:measure-materialized-view-ext}
 \end{table}
 
-Da bei der Materialized View das laden der Daten und das wandeln in die Java"=Objekte getrennt programmiert wurde,
+Da bei der \textit{Materialized View} das laden der Daten und das wandeln in die Java"=Objekte getrennt programmiert 
-können hier eigene Zeitmessungen für die zwei Schritte eingebaut werden. Hierfür wird die Zeit vor dem
+wurde, können hier eigene Zeitmessungen für die zwei Schritte eingebaut werden. Hierfür wird die Zeit vor dem
 \textit{map}"=Aufruf und der \textit{map}"=Aufruf gemessen. Für den ersten Aufruf, wurde ein \textit{SearchDocument}
 Objekt erzeugt und immer diese Objekt zurückgegeben. Damit wurde erst mal überprüft, wie lange das ermitteln der Daten
 und das durcharbeiten der Ergebnisse bestimmt. Hierbei lagen die Zeiten bei circa 1 ms für das reine Datenladen und 3 ms
@@ -762,8 +766,8 @@ Lösung auf eine kürzere Laufzeit und weniger Last am Server.
 \label{sec:performance-investigation-application:optimizing-query}
 
 Für die Optimierung der Abfrage werden diese zuerst mit \textit{explain}, wie in \autoref{lst:explain-diagnostic}
-dargestellt, untersuchen. Für die einfachere Diagnose, wird der erstellte Plan Mithilfe von pev2
+dargestellt, untersuchen. Für die einfachere Diagnose, wird der erstellte Plan mit Hilfe von 
-\citep{GitHubda51:online} visualisiert.
+\textit{Postgres Explain Visualizer 2} (\url{https://github.com/dalibo/pev2}) visualisiert.
 
 \begin{lstlisting}[language=SQL,caption={Explain für Diagnose},label=lst:explain-diagnostic]
 explain (analyze, verbose, buffers, summary, format json)
@@ -845,6 +849,40 @@ vorhanden.
     \label{fig:explain-visualize-with}
 \end{figure}
 
-Bei der Untersuchung der Abfrage zur Materialized View ist direkt herausgekommen, dass hier keine Optimierung mehr
+Bei der Untersuchung der Abfrage zur \textit{Materialized View} ist direkt herausgekommen, dass hier keine Optimierung 
-möglich ist, da durch die definierten Index bei den aktuell möglichen Sortierkriterien direkt ein \textit{Index Scan}
+mehr möglich ist, da durch die definierten Index bei den aktuell möglichen Sortierkriterien direkt ein 
-verwendet wird. Damit ist der schnellstmögliche Zugriff gegeben.
+\textit{Index Scan} verwendet wird. Dies ist durch eine Überprüfung der Abfragepläne beweisbar, für diesen Fall wird 
+die Abfrage aus \autoref{lst:explain-search-document} verwendet.
+
+\begin{lstlisting}[language=SQL,caption={xxxl},label=lst:explain-search-document]
+explain (analyze)
+select sd.id, documentid, datetype, startyear, startmonth, startday
+    , startdatestatus , endyear, endmonth, endday, enddatestatus
+    , author, coauthors, addressees, city, documentcategory
+    , ispublishedindb, createdat, modifiedat, validuntil
+from searchdocument sd 
+order by startyear desc, startmonth desc, startday desc
+limit 400;
+\end{lstlisting}
+
+Der dazugehörige Abfrageplan ist in \autoref{lst:explain-search-document-output} zu sehen, hierbei ist die erste 
+Ausgabe mit dem erstellten Index und vor der zweiten Ausgabe wurde der Index deaktiviert. Anhand der Ausgabe ist zu
+sehen, dass bei der Verwendung des Index weniger Operation notwendig sind und damit auch die teure Sortierung 
+eingespart werden konnte. Dies liegt daran, dass der Index entsprechend des Sortierkriterien definiert wurde Und
+somit es möglich ist, direkt in den Index die Elemente in der richtigen Reihenfolge zu ermitteln.
+Somit ist durch den Index der schnellstmögliche Zugriff gegeben.
+
+\begin{lstlisting}[basicstyle=\scriptsize,caption={aa},label=lst:explain-search-document-output]
+Limit  (cost=0.28..144.92 rows=400 width=948) (actual time=0.035..0.660 rows=400 loops=1)
+  ->  Index Scan Backward using idx_searchdocument_startdate on searchdocument sd (cost=0.28..1911.30 rows=5285 width=948) (actual time=0.033..0.593 rows=400 loops=1)
+Planning Time: 0.199 ms
+Execution Time: 0.732 ms
+
+Limit  (cost=747.69..748.69 rows=400 width=948) (actual time=2.128..2.146 rows=400 loops=1)
+  ->  Sort  (cost=747.69..760.90 rows=5285 width=948) (actual time=2.127..2.135 rows=400 loops=1)
+        Sort Key: startyear DESC, startmonth DESC, startday DESC
+        Sort Method: top-N heapsort  Memory: 703kB
+        ->  Seq Scan on searchdocument sd  (cost=0.00..492.85 rows=5285 width=948) (actual time=0.006..0.943 rows=5285 loops=1)
+Planning Time: 0.056 ms
+Execution Time: 2.164 ms
+\end{lstlisting}

chapters/thesis/chapter06.tex

@@ -9,33 +9,31 @@ der Effektivität mit beachtet.
 
 Es wurden die Konfigurationen der Caches von OpenJPA, JPA und EJB aktiviert und deren Auswirkung betrachtet. Bei den
 Caches, bei denen eine Größe angebbar ist, wurde zusätzlich mit der Anzahl variiert, um zu ermitteln in welchen Umfang
-sich diese auswirkt. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob es signifikante
+sich diese auswirkt. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob signifikante
-Unterschiede in der Performance und der Abarbeitung ergibt. Als weitere Punkt werden die Abfragen an die Datenbank
+Unterschiede in der Performance und der Abarbeitung erkennbar sind. Als weiteren Punkt werden die Abfragen an die 
-untersucht, um zu ermitteln ob diese durch Umstellung verbessert werden können. Als letzten werden die Materialisierten
+Datenbank untersucht, um zu ermitteln ob diese durch Umstellung verbessert werden können. Abschließend werden die 
-Sichten verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand die Abfragen
+\textit{Materialized View} verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand 
-beschleunigt werden können.
+die Abfragen beschleunigt werden können.
-
-\mytodos{Zusätzlich beschreiben welche Möglichkeiten man genau genutzt hat und warum bzw. warum nicht}
 
 \section{Nutzerumfrage}
 \label{sec:evaluation:user-survey}
 
-Zusätzlich war noch eine Befragung unter den Benutzer und den Entwicklern geplant. Da hierfür nur fünf Personen zur
+Zusätzlich war noch eine Befragung unter den Benutzer und den Entwicklern geplant. Auf Grund dessen, dass nur fünf 
-Verfügung stehen, ist dies nicht zielführend. Daher ist die sinnvolle Alternative ein rein technischer Ansatz, der
+Personen zur Verfügung stehen ist dies nicht zielführend. Daher ist die einzig sinnvolle Alternative, welche gewählt 
-gewählt wurde.
+wurde, ein rein technischer Ansatz.
 
 \section{Statische Webseiten}
 \label{sec:evaluation:static-website}
 
-Wenn man die Dokumentenliste als statische Webseiten ablegt, werden die Zugriffszeiten sehr kurz sein. Darüber hinaus
+Eine Umstellung der Dokumentenliste in statische Webseite, würde die Zugriffszeiten sehr verkürzen. Darüber hinaus
-funktionieren in statische Webseiten aber keine Suche oder eine Sortierung. Die Sortierung könnte durch das erstellen
+funktionieren in statischen Webseiten aber keine Suchen oder eine Sortierungen. Die Sortierung könnte durch das Erstellen
-von statischen Seite aller Möglichkeiten der Sortierung emuliert werden, diese würde den notwendigen Speicherbedarf der
+von statischen Seiten aller Möglichkeiten der Sortierung emuliert werden, diese würde den notwendigen Speicherbedarf der
 Webseite vervielfachen. Für die Suchanfragen ist dies nicht mehr möglich, da nicht alle Suchanfragen vorher definiert
 werden können.
 
 Die Umstellung der Suche auf Client"=Basis wäre noch eine Möglichkeit, dafür benötigen die Clients entsprechend
-Leistung und es muss eine Referenzdatei erstellt werden, die alle Informationen über die Dokumente beinhaltet, nach der
+Leistung und es muss eine Referenzdatei erstellt werden, die alle Informationen über die Dokumente beinhaltet, nach 
-gesucht werden kann.
+welcher gesucht werden kann.
 
 Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll.
 
@@ -43,23 +41,20 @@ Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll.
 \label{sec:evaluation:client-side-rendering}
 
 Als weitere Möglichkeit könnte man die Webseite so umbauen, dass die Daten erst im Nachgang über eine AJAX-Anfrage
-ermittelt und die Sortierung und Aufteilung im Client durchgeführt wird. Hierbei wird aber je nach Datenmenge ein
+ermittelt und die Sortierung und Aufteilung im Client durchgeführt wird. Hierbei wird allerdings je nach Datenmenge ein
-großer Speicher am Client benötigt und die Rechenleistung wird auf den Client verschoben.
+großer Speicher am Client benötigt und der Großteil der benötigten Rechenleistung zu dem Client verschoben.
 
 Dies wiederrum ist ein Vorteil für den Serverbetreiber, da durch die Verschiebung weniger Rechenleistung am Server
-benötigt wird. Gleichzeitig würde man damit wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
+benötigt wird. Gleichzeitig würde man wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
 die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.
 
-\section{Auswertung der Ergebnisse vor und nach der Optimierung}
+\section{Caching im OpenJPA}
-\label{sec:evaluation:result-optimization}
+\label{sec:evaluation:caching-jpa}
-
-\subsection{Caching im OpenJPA}
-\label{sec:evaluation:result-optimization:caching-jpa}
 
 Bei der Verwendung des OpenJPA"=Caches gibt es einige Verbesserungen in der Geschwindigkeit zu sehen. Die Höhe der 
 Optimierungen hängt stark von der gewählten Cache"=Größe und der aufgerufenen Webseiten ab. Solange die Anfragen sich
 auf die gleichen Objekte beziehen und diese alle im Cache hinterlegt werden können, fällt die Optimierung entsprechend
-hoch aus. Sobald bei den Anfragen aber häufig die zu ermittelnden Objekt sich unterscheiden und alte Objekte wieder
+hoch aus. Sobald bei den Anfragen aber häufig die zu ermittelnden Objekte sich unterscheiden und alte Objekte wieder
 aus dem Cache entfernt werden, fällt die Performance"=Verbesserung immer geringer aus. 
 
 Das Entfernen der Objekte kann zwar umgangen werden, indem die häufig abgefragten Objekte gepinnt werden, was aber
@@ -67,38 +62,37 @@ den Speicherbedarf noch weiter erhöht, da diese Objekte nicht in die Zählung d
 Was uns direkt zum größten Nachteil diese Caches kommen lässt, die notwendig Speichermenge die ständig zur Verfügung
 gestellt werden muss. Damit ist immer ein gewisser Grundbedarf notwendig, da sich der Speicher bis zum eingestellten
 Grenzwert aufbaut und dann nicht mehr entleeren wird. Gerade bei kleiner dimensionierten Servern stellt dies ein
-größeres Problem dar, da dann weniger Speicher für die anderen laufenden Programme, wie dem Datenbankmanagementsystem,
+größeres Problem dar, da nun weniger Speicher für die anderen laufenden Programme, wie dem Datenbankmanagementsystem,
 zur Verfügung steht. 
 
 Hierbei ist aber noch zu beachten, dass die Optimierung durch den Cache nicht die Laufzeit der Abfragen in der Datenbank
-enorm verringert hat, sondern die Laufzeit beim erstellen der Objekte im \textit{OpenJPA}"=Framework. Dies sieht man
+enorm verringert hat, sondern die Laufzeit beim Erstellen der Objekte im \textit{OpenJPA}"=Framework. Dies sieht man
 sehr gut schon bei der ersten Messung, wie in \autoref{tbl:measure-ojpa-active}. Hierbei werden die Laufzeit in der
-Datenbank im Schnitt um circa 5 ms reduziert, aber die komplette Webseite wird fast 100 ms schneller an den Client
+Datenbank im Schnitt um circa 5 ms reduziert, allerdings wird die komplette Webseite fast 100 ms schneller an den Client
-ausgeliefert. Dies ist nur dadurch erklärbar, dass das erstellen und mit den Datenwerte zu befüllen mehr Zeit kostet,
+ausgeliefert. Dies ist nur dadurch erklärbar, dass das Erstellen und mit den Datenwerte zu befüllen mehr Zeit kostet,
 als das Objekt aus dem Cache zu ermitteln und zurückzugeben.
 
 Daher ist die Verwendung des OpenJPA"=Cache nur in Verbindung mit einem größer dimensionierten Server gut verwendbar,
 wenn der Großteil der Objekte im Cache gehalten werden kann. Bei Bedarf sollten die häufig frequentierten Objekte
 explizit im Cache aufgenommen und angepinnt werden.
 
-\subsection{Cached Queries}
+\section{Cached Queries}
-\label{sec:evaluation:result-optimization:cached-queries}
+\label{sec:evaluation:cached-queries}
 
 Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dies ist dadurch erklärbar, dass
-für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. Da in diesem Fall in der Tabelle
+für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. In diesem Fall sind in der Tabelle
-auch noch nicht freigegebene und ungültige Datensätze gespeichert sind, müssen diese vor dem übertragen herausgefiltert
+noch nicht freigegebene und ungültige Datensätze gespeichert, daher müssen diese vor dem Übertragen herausgefiltert
 werden. Dies ist der Grund warum diese Anfragen in diesem Cache nicht gespeichert werden.
 
-Dadurch ist dieser Cache für eine Performance"=Verbesserung in unseren Fall nicht verwendbar.
+Dadurch ist dieser Cache für eine Performance"=Verbesserung in dem Fall der Dokumentenliste nicht anwendbar.
 
-\subsection{Caching mit Ehcache}
+\section{Caching mit Ehcache}
-\label{sec:evaluation:result-optimization:ehcache}
+\label{sec:evaluation:ehcache}
 
-\mytodos{fehlt noch}
 Mit dem Ehcache konnte eine Verbesserung in der Performance erzielt werden. Im Vergleich zum Cache von OpenJPA sind
 die Verbesserung sehr ähnlich. Die Standardwerte dieses Caches sind gut vordefiniert, es wird für den aktuellen Fall
 keine Anpassung benötigt um eine gute Performance zu bekommen. Hierbei ist natürlich das gleiche Problem wie in anderen
-Caches, dass beim erreichen der Grenzen, alte Objekte entfernt werden müssen.
+Caches, dass beim Erreichen der Grenzen, alte Objekte entfernt werden müssen.
 
 Nach aktueller Beobachtung scheint die Verwaltung im Ehcache effizienter gestaltet zu sein, als die des OpenJPA"=Caches.
 Im Falle des Ehcache ist die interne Verwaltung auf mehrere Caches aufgebaut, dies ist daran zu sehen, dass in der 
@@ -106,91 +100,91 @@ Standardkonfiguration jede Klasse ihren eigenen Cache besitzt. Diese können ein
 werden, um diese genau auf die jeweiligen Bedürfnisse der Objekte anzupassen.
 
 Im Falle der Verwendung des Caches, ist auch hier gut zu sehen, dass der Speicheranstieg bei der Verwendung des Caches
-sehr gering ist, was den Schluss zu lässt, dass der Cache nur zu einem kleinen 
+sehr gering ist, was den Schluss zulässt, dass der Cache nur zu einem kleinen \mytodos{hier fehlt was}
 
 Durch die effizienter Verwendung des Speichers, ist der Ehcache die bessere Alternative zum OpenJPA"=Cache. Dieser ist
 auch schon für kleinere Serverkonfigurationen gut verwendbar. Hierbei ist nur abzuwägen, mit welcher Größe der Cache
 bereitgestellt werden kann, was direkt am verfügbaren Arbeitsspeicher abhängt.
 
-\subsection{Caching in EJB}
+\section{Caching in EJB}
-\label{sec:evaluation:result-optimization:ejb}
+\label{sec:evaluation:ejb}
 
-Bei der Erweiterung des EJB konnte keine Verbesserung in der Performance festgestellt werden. Dies liegt daran, dass
+Bei der Erweiterung des EJB konnte keine Verbesserung in der Performance festgestellt werden. Der Grund hierfür ist, dass
-im EJB"=Cache die Provider beinhaltet, aber keine Daten"=Objekte. Dadurch kann der Cache das ermitteln der Objekte
+im EJB"=Cache die Provider beinhaltet, aber keine Daten"=Objekte. Dadurch kann der Cache das Ermitteln der Objekte
 nicht optimieren.
 
-Aufgrund dessen ist der EJB"=Cache nicht für eine Performance"=Verbesserung nutzbar.
+Auf Grund dessen ist der EJB"=Cache nicht für eine Performance"=Verbesserung nutzbar.
 
-\subsection{Abfragen mit JPQL und Criteria API}
+\section{Abfragen mit JPQL und Criteria API}
-\label{sec:evaluation:result-optimization:jpal-capi}
+\label{sec:evaluation:jpal-capi}
 
-Bei dem Vergleich zwischen den 2 Abfragemöglichkeiten der \ac{JPQL} und der Criteria API konnte in der Art der Abfragen
+Bei dem Vergleich zwischen den zwei Abfragemöglichkeiten der \ac{JPQL} und der Criteria API konnte in der Art der 
-kein Unterschied dargestellt werden. Die Abfragen der beiden Systeme sind auf der Datenbankseite komplett identisch.
+Abfragen kein Unterschied festgestellt werden. Die Abfragen der beiden Systeme sind auf Datenbankseite komplett 
-Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte keine Unterschied in der Art und
+identisch. Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte keine Unterschied in der 
-Geschwindigkeit festgestellt werden.
+Art und Geschwindigkeit festgestellt werden.
 
 Ebenfalls sind die Möglichkeiten über der Optimierung über Hints identisch. In beiden Fällen, haben die meisten Hints
-keine nennenswerten Einfluss auf die Laufzeit der Abfragen und Übertragung in die Java"=Objekte. Das sinnvolle setzen
+keine nennenswerten Einfluss auf die Laufzeit der Abfragen und Übertragung in die Java"=Objekte. Das sinnvolle Setzen
 von OptimizeResultCount, der FetchSize sowie der FetchBatchSize hilft dem Framework die Bearbeitung der Anfrage
 effizient abzuarbeiten, konnte aber in den gemessenen Laufzeiten nicht verifiziert werden.
 
-Anders ist dies mit dem Einstellungen für EagerFetchMode, welche definiert wie die Daten für abhängige Klasse ermittelt
+Anders verhält sich dies mit den Einstellungen für EagerFetchMode, welche definiert wie die Daten für abhängige Klasse 
-werden. Bei Umstellung auf \textit{parallel} konnte für die Ermittlung der Dokumente einiges an Performance gewonnen
+ermittelt werden. Bei Umstellung auf \textit{parallel} konnte für die Ermittlung der Dokumente einiges an Performance gewonnen
 werden. Das liegt daran, dass nun für die abhängigen Objekte, wie den Koautoren, nicht pro Dokument eine Anfrage an die
 Datenbank gestellt wird, sondern es werden alle Koautoren für die ermittelten Dokumente auf einmal ermittelt. Die
 Zuordnung der Koautoren zu dem Dokument wird dann nun im Framework und nicht mehr durch die Datenbank durchgeführt.
-Diese Abarbeitung spart viele einzelne Abfragen und somit auch den entsprechend Overhead im Framework.
+Diese Abarbeitung reduziert viele einzelne Abfragen und somit auch den entsprechend Overhead im Framework.
 
-Aufgrund dessen ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für
+Auf Grund dessen ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für
-jeweiligen Einsatzzweck besser beziehungsweise einfacher zu programmieren ist. Das setzen der richtigen Hints wiederrum
+jeweiligen Einsatzzweck besser beziehungsweise einfacher zu programmieren ist. Das Setzen der richtigen Hints wiederrum
-ist in beiden Fällen äußerst wichtig. Explizit der EagerFetchMode muss vorher darüber nachgedacht werden, wie viele
+ist in beiden Fällen äußerst wichtig. Explizit bei der EagerFetchMode muss vorher darüber nachgedacht werden, wie viele
 abhängige Objekttypen es zu dieser Klasse gibt, welche dazu geladen werden sollen und von welcher Anzahl an Objekte 
 ausgegangen werden kann. Gerade bei ein größeren Anzahl lohnt es sich den Hint auf \textit{parallel} zu setzen.
-Gleiches gilt den Hint SubclassFetchMode, dieser steuert dimensionierten Abfragen im falle von abgeleitet Klassen.
+Gleiches gilt dem Hint SubclassFetchMode, dieser steuert dimensionierte Abfragen im Falle von abgeleiteten Klassen.
 
-\subsection{Materialized View}
+\section{Materialized View}
-\label{sec:evaluation:result-optimization:materialized-view}
+\label{sec:evaluation:materialized-view}
 
-Die Idee der Materialisierten Sichten ist simple aber sehr effizient, gerade für einen Datenbestand der häufig gelesen
+Die Idee der \textit{Materialized View} ist simple aber sehr effizient, gerade für einen Datenbestand welcher häufig gelesen
 und selten verändert wird. Hierbei werden komplexe Abfragen einmalig ausgeführt und das Ergebnis intern 
 zwischengespeichert. Für alle weiteren Aufrufe, werden die Daten nun aus der Zwischenspeicher gelesen und dem Aufrufer
-zurückgegeben. Bei einer Änderung an den Quelldaten muss die Sicht aktualisiert werden, was der größte Nachteil der
+zurückgegeben. Der größte Nachteil der \textit{Materialized View} ist, das bei einer Änderung an den Quelldaten die
-Materialisierten Sichten ist. Dieser Nachteil kommt in einer Briefedition nicht zum tragen, da in dieser nach dem die 
+Sicht aktualisiert werden muss. Dieser Nachteil kommt in einer Briefedition nicht zum tragen, da in dieser nach dem die 
-Briefe einmalig eingepflegt wurde, noch selten Änderungen erfahren. Die Recherche über den Datenbestand die größte Zeit
+Briefe einmalig eingepflegt wurden, noch selten Änderungen erfahren. Die Recherche über den Datenbestand die größte Zeit
 gewidmet wird.
 
-Ein weiterer Nachteil der Materialisierten Sichten ist die doppelte Speicherung der Daten, da die Daten für die Sicht
+Ein weiterer Nachteil der \textit{Materialized View} ist die doppelte Speicherung der Daten, da die Daten für die Sicht
-wie bei einer Tabelle auf der Festplatte gespeichert sind. Dieser Nachteil ist in der DOkumentliste vernachlässigbar, 
+wie bei einer Tabelle auf der Festplatte gespeichert sind. Dieser Nachteil ist in der Dokumentliste vernachlässigbar, 
 da sich die Daten auf die Meta"=Daten der Dokumente, wie Namen, Datum und Autoren beschränkt. Der größte Datenbestand,
 die Faksimile, sind nicht in dieser Sicht enthalten und werden erst beim Anzeigen einer Kommunikation ermittelt.
 Zusätzlich ist zu beachten, dass bei der Verwendung eines Caches die Daten ebenfalls doppelt gehalten werden und in
 den meisten Fällen im Arbeitsspeicher gehalten werden.
 
-Eine zusätzliche Optimierung die durch die Materialisierte Sicht entstanden ist, ist die direkte integration der
+Eine weitere Optimierung, welche durch die \textit{Materialized View} entstanden ist, ist die direkte integration der
-Autoren, der Koautoren und der Adressen im \textit{Json}"=Format. Durch diesen aus dem Wedekind-Projekt übernommene Idee 
+Autoren, der Koautoren und der Adressen im \textit{Json}"=Format. Durch diese aus dem Wedekind-Projekt übernommene Idee 
 konnten schon viele zusätzliche Abfragen eingespart werden, da diese nicht mehr durch OpenJPA nach der Hauptabfragen 
 für jede Datenzeile einzeln durchgeführt wird. 
 
 Zusätzlich konnte dies nochmal beschleunigt werden, in dem das parsen der \textit{Json}"=Daten vom Server auf den Client 
 verlagert wurde. Hiermit konnte zum einen Last vom Server genommen werden und die gesamte Ausführungszeit nochmals
-optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch auf
+optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch bei
-schwächeren Clients in kurzer zeit zu erledigen.
+schwächeren Clients in kurzer Zeit durchzuführen. \mytodos{durchführbar?}
 
-Zusammenfassend ist zu sagen, dass die Materialisierten Sichten eine gute Wahl sind, um die Listendarstellungen
+Zusammenfassend ist zu sagen, dass die \textit{Materialized View} eine gute Wahl sind, um die Listendarstellungen
 zu optimieren. Mit dieser Technik können zum einen die Abfragezeiten optimiert werden, wodurch gleichzeit die 
 Ressourcennutzung verringert wird. Zum anderen wird die Ressourcennutzung des Servers noch weiter reduziert, wenn die 
 \textit{Json}"=Verarbeitung an den Client ausgelagert wird.
-Durch die doppelte Datenhalten muss bei jeder Abfrage geprüft werden, ob der Nutzung der Materialisierte Sicht sinnvoll
+Durch die doppelte Datenhalten muss bei jeder Abfrage geprüft werden, ob der Nutzung der \textit{Materialized View} sinnvoll
 ist oder direkt auf denormalisierte Daten umgestellt werden sollte, weil der zusätzliche benötigte Speicher größer als 
 die Quelle ist. 
 Im Gegensatz zu einer reinen Cache"=Lösung die die gleiche Optimierung besitzt, ist diese vorzuziehen, da in den 
 meisten Fällen der Festplattenspeicher kostengünstiger als der Arbeitsspeicher ist. Zusätzlich ist der Cache begrenzt
 und wirft alte Objekte aus dem Cache, wenn dieser voll ist und dadurch wird ein Zugriff auf so ein Objekt wieder 
-langsamer. Somit ist die Optimierung über die Materialisierten Sichten auf langezeit gesehen kostengünstiger und 
+langsamer. Somit ist die Optimierung über die \textit{Materialized View} auf langezeit gesehen kostengünstiger und 
 stabiler.
 
-\subsection{Optimierung der Abfrage}
+\section{Optimierung der Abfrage}
-\label{sec:evaluation:result-optimization:optimize-query}
+\label{sec:evaluation:optimize-query}
 
 Die Abfragen die durch die OpenJPA an die Datenbank abgesetzt werden, sind meist durch ihre Einfachheit gut optimiert.
 Nur durch Sortierung oder Bedingungen können die Abfragen langsam werden. Diese können durch entsprechende Indexe 
@@ -200,11 +194,18 @@ werden. Die Hauptabfrage der Dokumentenliste ist eine mit mehreren Joins, und di
 Der Abfrageplan der Hauptabfrage wurde visuell untersucht und zeigt, dass das Hauptproblem die nicht eingeschränkte
 Datenmenge der Haupttabelle \textit{document} ist. Dadurch werden zum einen die anderen Tabellen komplett dazu geladen
 und es werden trotz direkter Primary Key Bedingungen keine Zugriffe über die Index durchgeführt. Für den PostgreSQL
-ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem Tabellenscan entspricht, zu arbeiten.
+ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem kompletten Durchlaufen der Tabelle 
+entspricht, zu arbeiten.
 
 Um dies zu optimieren, wurde über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen 
 ermittelt, dieser mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnten die 
-Zeilenanzahl enorm verringert werden, wodurch einige der Verknüpfungen auf Indexzugriffe umgestellt wurden.
+Zeilenanzahl während der Verarbeitung enorm verringert werden, wodurch einige der Verknüpfungen auf Indexzugriffe 
-Durch die Umstellung konnte die Abfragezeit mehr als das dreifache reduziert wurde.
+umgestellt wurden. Durch die Umstellung konnte die Abfragezeit um mehr als das dreifache reduziert wurde.
 
-\mytodos{hier weiter...}
+Mit dieser Art der Umstellung können Abfragen optimiert werden, die fürs Paging verwendet werden und die Abfrage aus
+mehrere Tabellen besteht. Das wichtigste hierbei ist, dass die Bedingungen und die Sortierkriterien auf der 
+Haupttabelle arbeiten. Wenn dem nicht so ist, müssen Joins in die \textit{Common Table Expression} mit aufgenommen 
+werden und damit funktioniert die Reduzierung der Datensätze nicht mehr. Bei der Selektion einer Tabelle hat diese Art 
+der Optimierung keine Auswirkung, hier hilft nur das geschickte setzen von Indexen auf die Tabelle, welche die
+Bedingungen und die Sortierkriterien beinhalten. Dies wurde mit der Untersuchung der Abfrage auf die 
+\textit{Materialized View} bestätigt.

chapters/thesis/chapter07.tex

@@ -5,5 +5,45 @@
 
 \mytodos{hier eine kurze Zusammenfassung über 2-3 Seiten}
 
+\iffalse
 % umstellung auf matview sinnvoll bei verwendung von joins
 % bei joins von 1:n ist die Wandlung über json sinnvoll, aber parsen erst am client
+
+!!! Hier nochmal die Nutzerumfrage mit einbringen 
+
+- Einführung in die Ergebnisse
+- Darstellung der Kernergebnisse
+- Analyse und Interpretation
+- Einordnung in den Forschungskontext
+- Zusammenfassung und Übergang zur Diskussion
+
+Du beginnst mit einer präzisen Beschreibung deiner Untersuchung, um ein klares Verständnis der Grundlagen zu schaffen, 
+und hebst spezifische Daten sowie Analysemethoden hervor (1).
+
+Anschließend präsentierst du die Kernergebnisse deiner Forschung klar und strukturiert, fokussierst dabei auf 
+relevante Entdeckungen, die direkt zur Beantwortung deiner Forschungsfrage beitragen (2).
+
+Eine tiefgehende Analyse folgt, in der du die Daten nicht nur beschreibst, sondern auch im Kontext der theoretischen 
+Grundlagen interpretierst und untersuchst, wie sie deine Hypothesen unterstützen oder herausfordern (3).
+
+Die Ergebnisse setzt du dann in den breiteren akademischen und praktischen Forschungskontext und diskutierst ihren 
+Beitrag zu bestehenden Theorien sowie die sich eröffnenden neuen Perspektiven (4).
+
+Abschließend fasst du die wichtigsten Erkenntnisse zusammen und schaffst einen nahtlosen Übergang zur Diskussion, 
+indem du betonst, wie deine Ergebnisse die ursprünglichen Fragestellungen untersucht haben und welche Folgen sich für 
+weiterführende Forschungen ergeben könnten (5).
+\fi
+
+Das Ziel dieser Bachelorarbeit war es, durch die Untersuchung der Schichten am Beispiel des Wedekind"=Projektes 
+Optimierungsmöglichkeiten zu finden. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand
+dieser die Optimierungen implementiert, untersucht und jeweils mit dem Ausgangspunkt verglichen.
+Hierzu wurde der Aufbau der Software in seine unterschiedlichen Schichten zerlegt und diese einzeln Untersucht. 
+Für jede Schicht wurde 
+Bei den Schichten
+wurde, zu diesen zählen 
+die Enterprise Java Beans, die Java Persistance API, die OpenJPA, 
+
+
+Für dieses Ziel wurde sich auf die Dokumentenliste beschränkt und diese jeweils
+für die unterschiedllichen Optimierungen angepasst.
+Es wurde 

frontbackmatter/AbstractDE.tex

@@ -20,3 +20,13 @@
         \end{center}
 
 \end{otherlanguage}
+
+% Aufbau, und sollte max 1 A4 Seite sein!!
+% - Einstieg in das Thema
+% - Problemlage, Fragestellung, Methodik
+% - Wichtigste Ergebnisse
+% - Einordnung in Forschungsrahmen
+% - Ausblick und Bedeutung
+
+% beginnen mit:
+% Das Ziel dieser Bachelorarbeit ist ...