Aktueller Forschungsstand - OpenJPA fertiggestellt und weitere URLs hinzugefügt

chapters/expose/chapter01.tex

@@ -53,8 +53,6 @@ Hierbei ist auch ein Vergleich mit anderen Technologien angedacht.
 % 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
@@ -72,6 +70,8 @@ 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.
@@ -85,9 +85,11 @@ angegeben Werte für die Plankosten zu verstehen. Hinzu kommt noch, dass man den
 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.
 
-\citep[60]{MüllerWehr2012}
-
+% 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.
@@ -117,13 +119,36 @@ 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.
+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
 

expose-ref.bib

@@ -29,6 +29,25 @@
   urldate = {2023-09-24}
 },
 
+@online{IbmOpenJPACaching2023,
+  year = 2023,
+  url = {https://www.ibm.com/docs/de/was/8.5.5?topic=applications-configuring-openjpa-caching-improve-performance},
+  urldate = {2023-09-24}
+},
+
+@online{PostgresPro:Chap20.4:2023,
+  year = 2023,
+  comment={http://web.archive.org/web/20230530113045/https://postgrespro.com/docs/postgresql/14/runtime-config-resource},
+  url = {https://postgrespro.com/docs/postgresql/14/runtime-config-resource},
+  urldate = {2023-12-27}
+},
+
+@online{PostgresF27:2023,
+  year = 2023,
+  url = {https://www.postgresql.org/docs/8.4/pgstatstatements.html},
+  urldate = {2023-12-27}
+}
+
 % File: 978-1-4842-3546-1.pdf
 @BOOK{Sharan2018,
 	AUTHOR = {Sharan, Kishori},