feature: praesi
This commit is contained in:
Hikyu
parent
63c7bb0315
commit
aa3e89407e
@ -248,11 +248,13 @@ layoutClass: gap-10
|
||||
|
||||
# Key-Value mit Redis
|
||||
|
||||
Eine einfache und schnelle Lösung für unstrukturierte Daten.
|
||||
<div class="pt-8 text-lg space-y-4 opacity-80">
|
||||
|
||||
Keys sind Strings und identifizieren ein Objekt eindeutig.
|
||||
Keys sind Strings, eindeutig pro Objekt.
|
||||
|
||||
Aufbau: Name der Entität, Doppelpunkt, ID des Objekts.
|
||||
Aufbau: Entität : ID
|
||||
|
||||
</div>
|
||||
|
||||
::right::
|
||||
|
||||
@ -267,12 +269,6 @@ enemy:1
|
||||
|
||||
</div>
|
||||
|
||||
<div class="pt-6 opacity-80">
|
||||
|
||||
Die meisten Entitäten liegen als Hash Map. Listen und Mengen als SET.
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
- Keys sind Strings und identifizieren ein Objekt eindeutig
|
||||
- Aufbau: Name der Entität, Doppelpunkt, ID
|
||||
@ -289,19 +285,14 @@ layout: default
|
||||
|
||||
| Datentyp | Key-Struktur | Attribute |
|
||||
|----------|--------------|-----------|
|
||||
| HMAP | `weapon:{id}` | id, item_effect_id, item_type_id, weight, damage |
|
||||
| HMAP | `item:{id}` | id, name, gear_type, gear_id |
|
||||
| HMAP | `player:{id}` | id, name, health, stamina, level, region_id |
|
||||
| HMAP | `player:{id}` | id, name, health, level, region_id |
|
||||
| SET | `player:{id}:armor` | item_id |
|
||||
| STRING | `player:{id}:shield` | item_id |
|
||||
| HMAP | `region:{id}` | id, name |
|
||||
| SET | `region:{id}:enemies` | enemy_id |
|
||||
| HMAP | `enemy:{id}` | id, name, health, level, damage |
|
||||
| HMAP | `enemy:{id}` | id, name, health, damage |
|
||||
|
||||
</div>
|
||||
|
||||
<div class="pt-4 opacity-70 text-sm">
|
||||
Über den Key kommen wir direkt an ein Objekt, ohne lange zu suchen.
|
||||
Über den Key direkt ans Objekt.
|
||||
</div>
|
||||
|
||||
<!--
|
||||
@ -317,11 +308,15 @@ layoutClass: gap-10
|
||||
|
||||
# Dokument mit MongoDB
|
||||
|
||||
Alles was zusammengehört, liegt gebündelt in einem Dokument.
|
||||
<div class="pt-8 text-lg space-y-4 opacity-80">
|
||||
|
||||
Jede Entität wird zu einem Dokument in einer eigenen Collection.
|
||||
Zusammengehöriges in einem Dokument.
|
||||
|
||||
Der Player hält von seiner Ausrüstung nur die ids fest, denn Weapon und Co. liegen in eigenen Dokumenten.
|
||||
Jede Entität eine Collection.
|
||||
|
||||
Ausrüstung nur als ids.
|
||||
|
||||
</div>
|
||||
|
||||
::right::
|
||||
|
||||
@ -399,7 +394,7 @@ region {
|
||||
</div>
|
||||
|
||||
<div class="pt-6 opacity-70 text-sm">
|
||||
Weapon bringt item_type und item_effect direkt mit. Player, Item, Region und Enemy zeigen meist nur über ids.
|
||||
Weapon trägt item_type und item_effect direkt. Sonst meist nur ids.
|
||||
</div>
|
||||
|
||||
<!--
|
||||
@ -415,9 +410,13 @@ layoutClass: gap-10
|
||||
|
||||
# Graph mit Neo4j
|
||||
|
||||
Der Fokus liegt auf den Beziehungen zwischen den Objekten.
|
||||
<div class="pt-8 text-lg space-y-4 opacity-80">
|
||||
|
||||
Jede Entität wird zu einem Knoten, der seine Werte direkt mitträgt.
|
||||
Fokus auf den Beziehungen.
|
||||
|
||||
Jede Entität ein Knoten mit eigenen Werten.
|
||||
|
||||
</div>
|
||||
|
||||
::right::
|
||||
|
||||
@ -425,13 +424,9 @@ Jede Entität wird zu einem Knoten, der seine Werte direkt mitträgt.
|
||||
|
||||
| Knoten | Attribute |
|
||||
|--------|-----------|
|
||||
| Player | id, name, health, stamina, level |
|
||||
| Player | id, name, health, level |
|
||||
| Weapon | id, weight, damage |
|
||||
| Type | id, name |
|
||||
| item_effect | id, name, value |
|
||||
| Item | id, name |
|
||||
| Region | id, name |
|
||||
| Enemy | id, name, health, level, damage |
|
||||
| Enemy | id, name, health, damage |
|
||||
|
||||
</div>
|
||||
|
||||
@ -450,18 +445,15 @@ layout: default
|
||||
|
||||
| Von | Kante | Nach |
|
||||
|-----|-------|------|
|
||||
| Player | has_equipped | Weapon, Armor, Shield, Talisman |
|
||||
| Player | has_equipped | Weapon |
|
||||
| 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 |
|
||||
| Region | has | Enemy |
|
||||
| Enemy | drops | Item |
|
||||
|
||||
</div>
|
||||
|
||||
<div class="pt-6 opacity-70 text-sm">
|
||||
Die Kanten verbinden die Knoten so, wie es schon das ER-Modell vorgibt.
|
||||
Kanten wie im ER-Modell.
|
||||
</div>
|
||||
|
||||
<!--
|
||||
@ -480,12 +472,12 @@ layout: default
|
||||
|
||||
<div class="p-6 rounded-xl bg-green-500/10">
|
||||
<div class="font-bold text-green-500 pb-3">Vorteil</div>
|
||||
Redis ist extrem schnell. Über die Keys kommen wir direkt an ein Objekt. Genau das brauchen wir für die Live Daten des Players.
|
||||
Extrem schnell, direkter Zugriff über Key. Ideal für Live Daten.
|
||||
</div>
|
||||
|
||||
<div class="p-6 rounded-xl bg-red-500/10">
|
||||
<div class="font-bold text-red-500 pb-3">Nachteil</div>
|
||||
Komplexe Abfragen sind schwierig. Alle Weapon mit einem bestimmten item_effect müssen wir in der Anwendung selbst zusammenbauen.
|
||||
Komplexe Abfragen müssen wir selbst zusammenbauen.
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@ -506,12 +498,12 @@ layout: default
|
||||
|
||||
<div class="p-6 rounded-xl bg-green-500/10">
|
||||
<div class="font-bold text-green-500 pb-3">Vorteil</div>
|
||||
Sehr leserlich und einfach zu modellieren. Jedes Dokument ist für sich verständlich und man sieht direkt, welche Daten zusammengehören.
|
||||
Leserlich und einfach zu modellieren.
|
||||
</div>
|
||||
|
||||
<div class="p-6 rounded-xl bg-red-500/10">
|
||||
<div class="font-bold text-red-500 pb-3">Nachteil</div>
|
||||
Bei uns wird das meiste über ids referenziert und nur wenig verschachtelt. Wir nutzen die Stärke des Modells kaum.
|
||||
Bei uns meist nur ids. Stärke kaum genutzt.
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@ -532,12 +524,12 @@ layout: default
|
||||
|
||||
<div class="p-6 rounded-xl bg-green-500/10">
|
||||
<div class="font-bold text-green-500 pb-3">Vorteil</div>
|
||||
Beziehungen lassen sich sehr leicht abfragen. Welcher Player welche Weapon trägt oder welches Item ein Enemy fallen lässt, ohne Umwege.
|
||||
Beziehungen sehr leicht abfragbar, ohne Umwege.
|
||||
</div>
|
||||
|
||||
<div class="p-6 rounded-xl bg-red-500/10">
|
||||
<div class="font-bold text-red-500 pb-3">Nachteil</div>
|
||||
Neo4j ist für unseren Fall überdimensioniert. Wir schreiben und lesen vor allem schnell, statt ständig tiefe Beziehungen abzufragen.
|
||||
Für uns überdimensioniert. Wir brauchen vor allem Tempo.
|
||||
</div>
|
||||
|
||||
</div>
|
||||
@ -567,7 +559,7 @@ layout: default
|
||||
</div>
|
||||
|
||||
<div class="pt-8 opacity-70">
|
||||
Unsere Daten sind flach und ändern sich ständig. Tiefe Beziehungen brauchen wir kaum.
|
||||
Unsere Daten sind flach und ständig in Bewegung.
|
||||
</div>
|
||||
|
||||
<!--
|
||||
@ -582,41 +574,25 @@ layout: default
|
||||
|
||||
# Was uns wichtig ist
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 pt-6 text-sm">
|
||||
<div class="pt-10 text-lg">
|
||||
|
||||
<div>
|
||||
|
||||
| Kriterium | Muss | Gewicht |
|
||||
|-----------|:----:|:-------:|
|
||||
| Hohe Performanz | ja | 5 |
|
||||
| Keine Lizenzkosten | ja | 5 |
|
||||
| Daten-Streaming | ja | 3 |
|
||||
| Niedrige Latenz | ja | 3 |
|
||||
| Indexing | nein | 2 |
|
||||
|
||||
</div>
|
||||
|
||||
<div>
|
||||
|
||||
| | MariaDB | Redis | MongoDB |
|
||||
| | Redis | MongoDB | Neo4j |
|
||||
|---|:---:|:---:|:---:|
|
||||
| Performanz | 0 | 2 | 1 |
|
||||
| Streaming | 0 | 2 | 0 |
|
||||
| Latenz | 1 | 2 | 0 |
|
||||
| **Summe** | **11** | **30** | **15** |
|
||||
|
||||
</div>
|
||||
| Performanz | 2 | 1 | 1 |
|
||||
| Streaming | 2 | 0 | 0 |
|
||||
| Latenz | 2 | 0 | 1 |
|
||||
| **Summe** | **30** | **15** | **13** |
|
||||
|
||||
</div>
|
||||
|
||||
<div class="pt-6 opacity-70 text-sm">
|
||||
Latenzfrei und performant ist für uns Pflicht. In den Tests gewinnt Redis klar.
|
||||
Redis gewinnt klar.
|
||||
</div>
|
||||
|
||||
<!--
|
||||
- Kriterien aus dem Szenario gewichtet
|
||||
- Performanz und keine Lizenzkosten sind Pflicht
|
||||
- in den Tests gewinnt Redis klar: 30 vs 11 vs 15
|
||||
- in den Tests gewinnt Redis klar: 30 vs 15 vs 13
|
||||
-->
|
||||
|
||||
---
|
||||
@ -634,17 +610,17 @@ Wir wählen <span class="text-red-500 font-bold">Key-Value mit Redis</span>
|
||||
|
||||
<div class="p-5 rounded-xl bg-gray-400/10">
|
||||
<div class="font-semibold pb-2">Geschwindigkeit</div>
|
||||
Daten des Players live schreiben und genauso live zurücklesen.
|
||||
Live schreiben und lesen.
|
||||
</div>
|
||||
|
||||
<div class="p-5 rounded-xl bg-gray-400/10">
|
||||
<div class="font-semibold pb-2">Direkter Zugriff</div>
|
||||
Über die Keys sofort an ein Objekt, ohne lange Suche.
|
||||
Über den Key sofort ans Objekt.
|
||||
</div>
|
||||
|
||||
<div class="p-5 rounded-xl bg-gray-400/10">
|
||||
<div class="font-semibold pb-2">Passende Größe</div>
|
||||
Rund 100 Regionen, 500 Gegner, 3.300 Gegenstände. Keine tiefe Verschachtelung nötig.
|
||||
Flache Daten, keine tiefe Verschachtelung.
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user