dokumentation 12 seiten

Ringstats_Dokumentation.tex

@@ -337,7 +337,7 @@ Für dieses einfache Schreiben und Lesen bringt der Graph mehr Aufwand mit, als
 % \section{Bau der app bis zur Endpräsi}
 \newpage
 
-\section{Fazit}
+\subsection{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,
@@ -363,4 +363,113 @@ Genau dafür ist Redis gemacht.
 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 braucht.
+
+\newpage
+\section{Marktrecherche}
+In der Zwischenpräsentation haben wir uns für das Key-Value-Modell entschieden.
+In diesem Kapitel schauen wir uns den Markt für Key-Value-Datenbanken genauer an.
+Wir stellen sechs Kandidaten vor, darunter ArangoDB eine multimodale Datenbank,
+und führen anschließend eine Nutzwertanalyse durch.
+
+\subsection{Betrachtete Datenbanken}
+
+\subsubsection{Redis}
+Redis ist ein In-Memory Key-Value Store und unsere Wahl aus der Zwischenpräsentation.
+Alle Daten liegen im Arbeitsspeicher, wodurch Lese- und Schreibzugriffe im Bereich
+von Mikrosekunden liegen. Neben einfachen Strings bringt Redis Datentypen wie
+Hashes und Sets mit, auf denen unser Schlüsselaufbau aus
+Kapitel~2.2 direkt aufsetzt. Seit Version 8 steht Redis wieder unter einer Open-Source-Lizenz (AGPLv3)
+und kostet uns damit nichts.
+
+\subsubsection{Memcached}
+Memcached ist eine verteilte In-Memory-Cache Datenbank und in Sachen
+Geschwindigkeit vergleichbar mit Redis. Dafür ist der Funktionsumfang bewusst
+klein gehalten: Es gibt nur einfache Key-Value-Paare, keine Datentypen wie Sets
+oder Hashes, und keine Persistenz. Unser Schlüsselaufbau mit
+SETs für Ausrüstung und Regionen lässt sich also nicht direkt abbilden
+Memcached steht unter der BSD-Lizenz.
+
+\subsubsection{ArangoDB (multimodal)}
+ArangoDB ist eine multimodale Datenbank und vereint Dokumente, Graphen und
+Key-Value-Zugriffe in einem System mit der gemeinsamen Abfragesprache AQL.
+Damit hätten wir unsere drei Modellierungen aus Kapitel~2 theoretisch in einer
+einzigen Datenbank abbilden können. Der Nachteil ist der Langsame zugriff auf die Daten.
+Seit Version 3.12 steht ArangoDB unter der Business Source
+License. Für unser Uni-Projekt ist das kostenlos, für einen
+kommerziellen Betrieb gäbe es Einschränkungen.
+
+\subsubsection{Amazon DynamoDB}
+DynamoDB ist der verwaltete Key-Value- und Dokument-Store von AWS. Die Datenbank
+skaliert beliebig. Der große Haken ist das Preismodell:
+DynamoDB läuft nur in der AWS-Cloud und wird pro Anfrage und Speicher
+abgerechnet. Bei unseren dauerhaften Schreibzugriffen von bis zu 10 Anfragen
+pro Sekunde würden laufende Kosten entstehen, womit unser
+Muss-Kriterium \glqq keine Lizenzkosten\grqq{} verletzt ist. Zudem ist die
+Latenz deutlich höher durch den Netzwerkweg in die Cloud.
+
+\subsubsection{etcd}
+etcd ist ein Key-Value Store, der hauptsächlich zum Speichern von
+Einstellungen und Konfigurationen benutzt wird, zum Beispiel intern von
+Kubernetes, ist also nicht dafür gedacht, laufend Spielerdaten zu speichern wie bei uns.
+Die Lizenz ist Apache~2.0 und damit kostenlos.
+
+\subsubsection{Riak KV}
+Riak KV ist ein verteilter Key-Value Store.
+Seine Stärke liegt in der Ausfallsicherheit: Daten werden
+automatisch über mehrere Knoten repliziert, und der Cluster bleibt auch beim
+Ausfall einzelner Knoten verfügbar. Riak KV steht unter der Apache-2.0-Lizenz.
+
+\subsection{Nutzwertanalyse}
+Wir bewerten alle sechs Datenbanken mit den Auswahlkriterien und Gewichten. Jedes Kriterium wird pro Datenbank mit 0 bis 2 Punkten
+bewertet und mit dem Gewicht multipliziert.
+
+\begin{table}[h]
+\centering
+\small
+\begin{tabular}{l c c c c c c c}
+\hline
+\textbf{Kriterium (Gewicht)} & & \textbf{Redis} & \textbf{Memc.} & \textbf{Arango} & \textbf{Dynamo} & \textbf{etcd} & \textbf{Riak} \\ \hline
+Hohe Performanz & (5) & 2 & 2 & 1 & 1 & 1 & 1 \\
+Daten-Streaming & (3) & 2 & 0 & 0 & 2 & 1 & 0 \\
+Niedrige Latenz & (3) & 2 & 2 & 1 & 1 & 1 & 1 \\
+Skalierbarkeit & (1) & 1 & 1 & 1 & 2 & 0 & 2 \\
+Keine Lizenzkosten & (5) & 2 & 2 & 2 & 0 & 2 & 2 \\
+Indexing & (2) & 1 & 0 & 1 & 1 & 0 & 1 \\
+Vektorrechnungen & (1) & 1 & 0 & 1 & 0 & 0 & 0 \\
+Präferenz & (1) & 1 & 0 & 0 & 0 & 0 & 0 \\ \hline
+\textbf{Gewichtete Summe} & & \textbf{37} & \textbf{27} & \textbf{22} & \textbf{18} & \textbf{21} & \textbf{22} \\
+\hline
+\end{tabular}
+\caption{Nutzwertanalyse der sechs Key-Value-Datenbanken}
+\label{tab:nutzwertanalyse}
+\end{table}
+
+Redis liegtklar vorne, weil es als einziger Kandidat sowohl bei
+Performanz und Latenz als auch beim Daten-Streaming die volle Punktzahl erreicht.
+Memcached kommt bei der reinen Geschwindigkeit zwar mit, scheitert aber am
+Muss-Kriterium Daten-Streaming. DynamoDB  fällt aber wegen der laufenden Kosten am Muss-Kriterium \glqq keine Lizenzkosten\grqq{} durch.
+ArangoDB ist als multimodale
+Datenbank flexibel, aber nicht auf unser schreiblastiges Live-Szenario
+zugeschnitten, etcd ist für Konfigurationsdaten statt Anwendungsdaten gebaut,
+und bei Riak KV kommt zur fehlenden Streaming-Funktion die kaum noch aktive
+Entwicklung hinzu.
+
+\subsection{Datenbankauswahl}
+Aus den sechs betrachteten Datenbanken wählen wir drei aus, die wir umsetzen
+und miteinander vergleichen, jeweils eine pro Gruppenmitglied:
+
+\begin{itemize}
+    \item \textbf{Redis} (Justin Rost) --- der Sieger unserer Nutzwertanalyse
+    und unsere Wahl aus der Zwischenpräsentation, bisher aber noch nicht
+    umgesetzt. Redis dient im Vergleich als Referenz, an der sich die beiden
+    anderen Datenbanken messen müssen.
+    \item \textbf{Memcached} (Yasin Ergün) --- der direkteste Konkurrent, da
+    ebenfalls In-Memory und ähnlich schnell. Der Vergleich zeigt, welche
+    Redis-Funktionen wir tatsächlich brauchen und was uns bei einem reinen
+    Cache fehlen würde.
+    \item \textbf{ArangoDB} (Michelle Reichelt) --- die multimodale Datenbank
+    im Feld. Der Vergleich zeigt, was uns eine einzige Datenbank für alle drei
+    Modellierungen aus Kapitel~2 gebracht hätte und was sie an Performanz kostet.
+\end{itemize}
+
 \end{document}