feature: vor und nachteile

Ringstats_Dokumentation.tex

@@ -4,6 +4,7 @@
 \usepackage[T1]{fontenc}
 \usepackage{graphicx}
 \usepackage[colorlinks=true, linkcolor=black]{hyperref}
+\usepackage{todonotes}
 
 \title{Ringstats Dokumentation}
 \author{Justin Rost \\ 7208260
@@ -153,7 +154,7 @@ Anhand dieses Systems bilden wir die Schlüssel wie folgt ab:
 \texttt{HMAP} & {shield:\{id\}} & id, item\_effect\_id, item\_type\_id, weight, damage, defense \\
 \texttt{HMAP} & {talisman:\{id\}} & id, item\_effect\_id \\
 \\
-\texttt{HMAP} & {item:\{id\}} &  id, name, gear\_type, gear\_id, region\_id \\
+\texttt{HMAP} & {item:\{id\}} &  id, name, gear\_type, gear\_id \\
 \\
 \texttt{HMAP} & player:\{id\} & id, name, health, stamina, level, region\_id \\
 \texttt{SET} & {player:\{id\}:weapon} & item\_id \\
@@ -167,7 +168,6 @@ Anhand dieses Systems bilden wir die Schlüssel wie folgt ab:
 \\
 \texttt{HMAP} & enemy:\{id\} & id, name, health, level, damage \\
 \texttt{SET} & enemy:\{id\}:items & item\_id \\
-\texttt{SET} & enemy:\{id\}:item\_effects & item\_effect\_id \\
 \hline
 \end{tabular}
 \caption{Übersicht der Schlüsselstrukturen in Redis}
@@ -187,28 +187,152 @@ Anhand dieses Systems bilden wir die Schlüssel wie folgt ab:
 
 \subsection{Dokumentenorientierte Modellierung}
 % Wie sieht das in z. B. MongoDB aus? Zeigt hier ein fiktives JSON-Dokument, das einen Gegner oder Spieler mit all seinen verschachtelten Eigenschaften beschreibt.
+Dokumentenorientierte Datenbanken speichern alles, was zusammengehört, gebündelt in einem Dokument.
+Wir verwenden in diesem Kapitel MongoDB.
+
+\subsubsection*{Aufbau der Dokumente}
+Jede Entität wird zu einem Dokument und liegt in einer eigenen Collection. Der Player hält von seiner Ausrüstung nur die ids fest, denn Weapon, Armor, Shield und Talisman liegen in eigenen Dokumenten und werden von vielen Player gleich gebraucht. So stehen ihre Grundwerte nur an einer Stelle und nicht bei jedem Player erneut. Genauso bekommen Item und Region ein eigenes Dokument, und Region und Enemy zeigen nur über die ids auf ihre Item und Enemy.
+
+So sieht das Dokument eines Player aus:
+
+\begin{verbatim}
+player {
+  id: 1,
+  name: "Jonas",
+  health: 100,
+  stamina: 100,
+  level: 1,
+  region_id: 1,
+  weapon: [ 12 ],
+  shield: 30,
+  armor: [ 41, 42 ],
+  talisman: [ 7 ]
+}
+\end{verbatim}
+
+Die id beim Player ist dabei die id des Item. Das Item zeigt über gear\_id auf die eigentliche Weapon, die in einem eigenen Dokument liegt und ihren item\_type und item\_effect direkt mitbringt:
+
+\begin{verbatim}
+weapon {
+  id: 213,
+  item_type: { id: 1, name: "Dolch" },
+  item_effect: { id: 4, name: "Stärke", value: 5 },
+  weight: 2,
+  damage: 70
+}
+\end{verbatim}
+
+Und so ein Enemy, der seine Item als id behält:
+
+\begin{verbatim}
+enemy {
+  id: 1,
+  region_id: 1,
+  name: "Tree_Sentinel",
+  health: 30000,
+  level: 20,
+  damage: 70,
+  items: [ 5, 10 ]
+}
+\end{verbatim}
+
+Das Item liegt in einem eigenen Dokument und hält die Grundwerte fest:
+
+\begin{verbatim}
+item {
+  id: 12,
+  name: "Dolch",
+  gear_type: "weapon",
+  gear_id: 213
+}
+\end{verbatim}
+
+Und die Region zeigt über die ids auf ihre Item und Enemy:
+
+\begin{verbatim}
+region {
+  id: 1,
+  name: "Limgrave",
+  items: [ 12, 19, 248 ],
+  enemies: [ 1, 245 ]
+}
+\end{verbatim}
 \newpage
 
 \subsection{Graph-Datenbank-Modellierung}
+\todo{komplett pruefen ob wir das richtig verstanden haben}
 % Wie sieht das in z. B. Neo4j aus? Beschreibt (oder zeichnet), wie Knoten (Player, Region) und Kanten (has_equipped, is_in) die Beziehungen darstellen.
+Graph-Datenbanken legen den Fokus auf die Beziehungen zwischen den Objekten.
+Wir verwenden in diesem Kapitel Neo4j.
 
-% Wir müssen erst die datenmodellieren
-% Habe bereits ein Projekt, lass das nehmen zum vergleichen nachher
-% - Redis
-% - MonogoDb
-% - MariaDB
+\subsubsection*{Aufbau aus Knoten und Kanten}
+Jede Entität wird zu einem Knoten, der seine eigenen Werte direkt mitträgt. Die Verbindungen aus dem ER-Modell werden zu Kanten zwischen diesen Knoten. So lässt sich direkt verfolgen, welcher Player welche Weapon trägt oder welches Item ein Enemy fallen lässt.
+
+Die Knoten und ihre Werte bilden wir wie folgt ab:
+
+\begin{table}[h]
+\centering
+\begin{tabular}{l l}
+\hline
+\textbf{Knoten} & \textbf{Attribute} \\ \hline
+Player & id, name, health, stamina, level \\
+Weapon & id, weight, damage \\
+Armor & id, weight, defense \\
+Shield & id, weight, damage, defense \\
+Talisman & id \\
+Type & id, name \\
+item\_effect & id, name, value \\
+Item & id, name \\
+Region & id, name \\
+Enemy & id, name, health, level, damage \\
+\hline
+\end{tabular}
+\caption{Übersicht der Knoten in Neo4j}
+\end{table}
+
+Die Kanten verbinden die Knoten so, wie es schon das ER-Modell vorgibt:
+
+\begin{table}[h]
+\centering
+\begin{tabular}{l l l}
+\hline
+\textbf{Von} & \textbf{Kante} & \textbf{Nach} \\ \hline
+Player & has\_equipped & Weapon, Armor, Shield, Talisman \\
+Player & is\_in & Region \\
+Weapon, Armor, Shield & has & Type \\
+Weapon, Armor, Shield, Talisman & has & item\_effect \\
+Weapon, Armor, Shield, Talisman & is & Item \\
+Region & has & Item, Enemy \\
+Enemy & drops & Item \\
+\hline
+\end{tabular}
+\caption{Übersicht der Kanten in Neo4j}
+\end{table}
 \newpage
 
 \section{Vergleich der Datenmodellierung}
 \subsection{Vor- und Nachteile des Key-Value-Modells}
 % Vorteil: Extrem schnell für euer Live-Streaming (Lese-/Schreibzugriffe). Nachteil: Komplexe Abfragen (z.B. "Zeige mir alle Waffen mit Stärke > 20") sind schwierig.
+Ein klarer Vorteil ist, dass Redis extrem schnell ist. Genau das brauchen wir, weil wir die Daten des Player laufend schreiben und gleichzeitig im Spiel und im Browser wieder auslesen. Über die Keys kommen wir direkt an ein Objekt, ohne lange zu suchen.
+
+Ein klarer Nachteil ist, dass komplexe Abfragen schwierig sind. Wollen wir zum Beispiel alle Weapon mit einem bestimmten item\_effect finden, müssen wir das in der Anwendung selbst zusammenbauen, weil Redis dafür keine fertige Suche mitbringt.
 
 \subsection{Vor- und Nachteile des dokumentenorientierten Modells}
 % Vorteil: Alles zu einem Spieler ist in einem JSON-Dokument gebündelt. Nachteil: Redundanzen, wenn z.B. Spieldaten wie "Waffen-Typen" bei jedem Spieler gespeichert werden.
+Ein klarer Vorteil ist, dass das Modell extrem leserlich und einfach zu modellieren ist. Jedes Dokument ist für sich verständlich und man sieht direkt, welche Daten zu einem Objekt gehören.
+
+Ein klarer Nachteil ist bei uns, dass das meiste über ids referenziert wird und nur wenig wirklich verschachtelt ist. Zwar bringt eine Weapon ihren item\_type und item\_effect direkt mit, aber Player, Item, Region und Enemy zeigen größtenteils nur über ids aufeinander. Dadurch nutzen wir die eigentliche Stärke des Modells kaum und haben am Ende vor allem viele einzelne Dokumente, die sich gegenseitig referenzieren.
 
 \subsection{Vor- und Nachteile des Graph-Modells}
 % Vorteil: Genial, um Beziehungen abzufragen (z.B. Welcher Spieler trägt welches Item, das von welchem Boss droppt?). Nachteil: Für pures Live-Streaming von Koordinaten eher überdimensioniert.
 % Siehe Dokumenatation der Datenmodellierung
+Ein klarer Vorteil ist, dass sich Beziehungen sehr leicht abfragen lassen.
+Wir können zum Beispiel direkt verfolgen, welcher Player welche Weapon trägt oder welches Item ein Enemy fallen lässt,
+ohne die Verbindungen umständlich selbst zusammenzubauen.
+
+Ein klarer Nachteil ist, dass Neo4j für unseren Fall überdimensioniert ist.
+Bei uns geht es vor allem darum, die Daten des Player schnell zu schreiben und wieder auszulesen, und nicht darum, ständig tiefe Beziehungen abzufragen.
+Für dieses einfache Schreiben und Lesen bringt der Graph mehr Aufwand mit, als er uns am Ende Vorteil bringt.
 \newpage
 
 % \section{Bau der app bis zur Endpräsi}
@@ -217,5 +341,9 @@ Anhand dieses Systems bilden wir die Schlüssel wie folgt ab:
 \section{Fazit}
 % Mehr coole sachen die wir gelernt haben.
 % Warum wir uns fuer dieses Datenbankmodell entschieden haben.
+Wir haben die gleichen Daten aus unserem ER-Modell in drei Datenbanken abgebildet und dabei gesehen,
+wie verschieden das aussieht. In Redis haben wir alles über Keys und Hash Maps abgelegt und kommen so direkt an ein einzelnes Objekt. In MongoDB liegt jede Entität als Dokument in ihrer Collection, und die Weapon bringt ihren item\_type und item\_effect gleich mit. In Neo4j ist jede Entität ein Knoten und die Verbindungen aus dem ER-Modell werden zu Kanten, also zum Beispiel has\_equipped oder drops. So konnten wir gut vergleichen, was jedes Modell bei unseren Daten gut kann und was eher umständlich ist.
 
+Für Ringstats fällt unsere Wahl auf das Key-Value-Modell mit Redis.
+Der Grund ist einfach: Bei uns geht es vor allem darum, die Daten des Player laufend zu schreiben und sofort wieder auszulesen, im Spiel und im Browser. Genau dafür ist Redis gemacht. Über die Keys kommen wir direkt an ein Objekt und müssen nicht lange suchen. Die komplexen Abfragen, bei denen MongoDB oder Neo4j stark wären, brauchen wir kaum, und unsere Daten sind ohnehin nicht tief verschachtelt. Deshalb passt die schnelle und einfache Lösung am besten zu dem, was Ringstats im Kern macht.
 \end{document}