Daily CheckIn

.vscode/settings.json

@@ -2,6 +2,7 @@
     "cSpell.language": "de-de,en",
     "cSpell.words": [
         "autovacuum",
+        "denormalisierte",
         "Denormalisierung",
         "editionswissenschaftlich",
         "EFFW",

chapters/thesis/chapter05.tex

@@ -485,13 +485,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.
 
-\mytodos{hier nochmal die referenz auf wedekind-repo einbauen}
-
 In diesem Test wurde die aktuelle Implementierung aus dem Wedekind"=Projekt der Materialized View inklusive der Trigger 
-und der \textit{SearchDocument}"=Klasse übernommen. Wie in \autoref{lst:sql-materialized-view} zu sehen, wurden zur 
-Standard"=Abfrage, die sonst zusätzlichen Abfragen als direkte Sub"=Selects mit integriert. Der Datenbestand dieser 
-Sub"=Selects, wird im Json"=Format angegeben, damit bei den Koautoren und den Adressen mehrere Datensätze in einer 
-Zeile zurückgegeben werden können. Ohne diese Technik würde sich die Anzahl der Dokumente vervielfachen.
+und der \textit{SearchDocument}"=Klasse übernommen \citep{Dokument53:online}. Wie in \autoref{lst:sql-materialized-view} 
+zu sehen, wurden zur Standard"=Abfrage, die sonst zusätzlichen Abfragen als direkte Sub"=Selects mit integriert. Der 
+Datenbestand dieser Sub"=Selects, wird im Json"=Format angegeben, damit bei den Koautoren und den Adressen mehrere 
+Datensätze in einer Zeile zurückgegeben werden können. Ohne diese Technik würde sich die Anzahl der Dokumente 
+vervielfachen.
 
 \begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view]
 CREATE MATERIALIZED VIEW searchdocument AS
@@ -682,17 +681,17 @@ Laufzeit der Datenbankanfrage minimal verkürzt, aber die \textit{map}"=Funktion
 Das aktivieren der Cache"=Optionen wie in \autoref{sec:performance-investigation-application:caching-openjpa} oder in
 \autoref{sec:performance-investigation-application:cached-query} dargestellt, haben keine Auswirkung auf die Performance.
 Dies ist dadurch erklärbar, da keine Objekte durch das OpenJPA"=Framework erstellt werden, sondern erst in der
-\textit{map}"=Funktion des eigenen Codes.
+\textit{map}"=Funktion des eigenen Codes und daher wird der Cache nicht genutzt.
 
-Wie schon ermittelt, benötigt das erstellen der Objekte den Großteil der Zeit für die Datenermittlung. Daher wurde die
-bereitgestellt Klasse betrachtet und die wie mit Herrn Tobias Holstein ausgemacht, der JsonParser nochmal genauer
-untersucht. Im ersten Schritt wird die Parse"=Funktion entfernt und die Seite nochmals aufgerufen. Durch diese 
-Umstellung fällt die Laufzeit der Datenermittlung auf circa 4 ms ab. Nun muss noch geprüft werden, welche Zeit nun der 
-Client zum parsen der \textit{Json}"=Daten benötigt. Hierfür werden die Daten in einem versteckten 
-\textbf{span}"=Element hinterlegt, wie es im \autoref{lst:jsf-datatable-json} zu sehen ist. Die hinterlegte 
-\textit{CSS}"=Klasse ist zum auffinden der Elemente für den späteren Javascript. Das \textbf{ajax}"=Element im Beispiel 
-ist notwendig, damit bei einem Seitenwechsel die gleiche Interpreter"=Funktion für die \textit{Json}"=Daten aufgerufen 
-wird, wie beim laden der Webseite.
+Wie schon ermittelt, benötigt das erstellen der Objekte den Großteil der Zeit für die Datenermittlung. Aufgrund dessen
+wurde die übernommen \textit{SearchDocument}"=Klasse nochmal genauer betrachtet. Beim erstellen, werden  die
+\textit{Json}"=Daten direkt in Java"=Objekte gewandelt. Im ersten Schritt wird die Parse"=Funktion entfernt und die 
+Seite nochmals aufgerufen. Durch diese Umstellung fällt die Laufzeit der Datenermittlung auf circa 4 ms ab. Nun muss 
+noch geprüft werden, welche Zeit nun der Client zum parsen der \textit{Json}"=Daten benötigt. Hierfür werden die 
+Daten in einem versteckten \textbf{span}"=Element hinterlegt, wie es im \autoref{lst:jsf-datatable-json} zu sehen ist. 
+Die hinterlegte \textit{CSS}"=Klasse ist zum auffinden der Elemente für den späteren Javascript. Das 
+\textbf{ajax}"=Element im Beispiel ist notwendig, damit bei einem Seitenwechsel die gleiche Interpreter"=Funktion für 
+die \textit{Json}"=Daten aufgerufen wird, wie beim laden der Webseite.
 
 \begin{lstlisting}[language=xml,caption={DataTable mit Json},label=lst:jsf-datatable-json]
 <p:ajax event="page" oncomplete="convertJsonData()"/>

chapters/thesis/chapter06.tex

@@ -151,21 +151,60 @@ Gleiches gilt den Hint SubclassFetchMode, dieser steuert dimensionierten Abfrage
 \subsection{Materialized View}
 \label{sec:evaluation:result-optimization:materialized-view}
 
-\mytodos{hier weiter machen}
-Mit der Verwendung der Materialisierten Sichten können
 Die Idee der Materialisierten Sichten ist simple aber sehr effizient, gerade für einen Datenbestand der häufig gelesen
 und selten verändert wird. Hierbei werden komplexe Abfragen einmalig ausgeführt und das Ergebnis intern 
-zwischengespeichert wird. Für alle weiteren Aufrufe, werden die Daten nun aus der Sicherung gelesen. Technisch gesehen 
-könnte dies auch selbständig implementiert werden, in dem zyklisch oder ereignisgesteuert das Ergebnis der Abfrage in 
-eine Tabelle gespeichert wird.
+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
+Materialisierten Sichten ist. 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
+gewidmet wird.
 
-Der Vorteil der Materialisierten Sichten ist, dass es einfach zu implementieren ist, eine geringere Fehleranfälligkeit 
-aufweist und , da alles über die reine Sichtdefinition erstellt wird. Ebenfalls 
+Ein weiterer Nachteil der Materialisierten Sichten 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, 
+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.
 
-% verweisen auf doppelte Speicherung, ist zwar im cache das gleich, aber abzuwägen an welcher Stelle "mehr" zur 
-% verfügung steht bzw. welcher Part günstiger in der Bereitstellung ist
+Eine zusätzliche Optimierung die durch die Materialisierte Sicht 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 
+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
+schwächeren Clients in kurzer zeit zu erledigen.
+
+Zusammenfassend ist zu sagen, dass die Materialisierten Sichten 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
+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 
+stabiler.
 
 \subsection{Optimierung der Abfrage}
 \label{sec:evaluation:result-optimization:optimize-query}
 
-\mytodos{fehlt noch}
+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 
+gelöst werden. Bei größeren Abfragen mit mehreren Joins kann durch geschicktes umstellen die Performance verbessert 
+werden. Die Hauptabfrage der Dokumentenliste ist eine mit mehreren Joins, und diese wurde explizit untersucht.
+
+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.
+
+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.
+Durch die Umstellung konnte die Abfragezeit mehr als das dreifache reduziert wurde.
+
+\mytodos{hier weiter...}

chapters/thesis/chapter07.tex

@@ -4,3 +4,6 @@
 \label{ch:summary_and_outlook}
 
 \mytodos{hier eine kurze Zusammenfassung über 2-3 Seiten}
+
+% umstellung auf matview sinnvoll bei verwendung von joins
+% bei joins von 1:n ist die Wandlung über json sinnvoll, aber parsen erst am client

expose-ref.bib

@@ -90,6 +90,15 @@
   urldate = {2024-09-20}
 },
 
+@online{Dokument53:online,
+  author = {},
+  title = {Dokumentenliste mit Native Query und Materialized View (b1f4c93d) · Commits · Wedekind / briefdb 2.0 · GitLab},
+  url = {https://code.dbis-pro1.fernuni-hagen.de/wedekind/briefdb-2.0/-/commit/b1f4c93d49ba31bf4da49845f47b5656e23aa76e},
+  month = {},
+  year = {},
+  urldate = {2024-09-21}
+},
+
 @online{AspNetCore:2024:MVC,
   year = 2024,
   url = {https://learn.microsoft.com/de-de/aspnet/core/fundamentals/middleware/?view=aspnetcore-8.0},

marco-galster-config.tex

@@ -19,7 +19,7 @@
 \newcommand{\myId}{8335710\xspace}
 \newcommand{\myProf}{Prof. Dr. Uta St\"orl\xspace}
 \newcommand{\referent}{Referentin\xspace}% Referentin/Referent, depending on the gender of your prof
-\newcommand{\mySupervisor}{Sebastian Bruchhaus, Tobias Holstein\xspace}
+\newcommand{\mySupervisor}{Tobias Holstein\xspace}
 \newcommand{\supervisor}{Betreuer\xspace}% Betreuerin/Betreuer, depending on the gender of your supervisor
 \newcommand{\myFaculty}{Fakult\"at f\"ur Mathematik und Informatik\xspace}
 \newcommand{\myUni}{FernUniversit\"at in Hagen\xspace}