Skip to content
Snippets Groups Projects
Commit 55ac7467 authored by Marcel Huber's avatar Marcel Huber
Browse files

changes by stefan

parent 279d8764
No related branches found
No related tags found
No related merge requests found
Show whitespace changes
Inline Side-by-side
KeyValueStore/README.md
+ 55
− 35
View file @ 55ac7467
# Übung 13: NoSQL ff. sowie Prüfungsvorbereitung
Dies ist eine spezielle Übung, denn die Vorlesung dieser Woche fällt
aus. Die Übung zu Key-Value Store entfällt. Dabei ist darauf
aus, welche die Key-Value Store-Übung ersetzt. Dabei ist darauf
hinzuwesien, dass das Thema Key-Value Stores einerseits in der Vorlesung
behandelt wurde, sowie andererseits in den [Übungen zu Dictionaries
(hstore) mit PostgreSQL](Datastructures/README.md).
......@@ -14,7 +14,7 @@ Diese Übung besteht aus folgenden, unterschiedlichen Teilen:
***Hinweise:***
Diese Übung ist eine reine Diskussion-, Denk- und Papier-Übung mit
Diese Übung ist eine Diskussion-, Denk- und Papier-Übung mit
zusätzlichen Informationen zu den NoSQL Stores MonetDB, MongoDB und
Neo4J.
......@@ -41,40 +41,58 @@ Als Vorbereitung wird voraussgesetzt, dass Sie die [Übung 12 "In-Memory
Column Store MonetDB"](ColumnStore/README.md) durchgearbeitet haben
sowie Zugang zu MonetDB mit geladener Datenbank Ds2 (DVD Store) haben.
Lesen Sie zudem mind. diese MonetDB-Doku.-Unterkapitel durch:
Lesen Sie zudem mindestens diese MonetDB-Unterkapitel durch:
- https://www.monetdb.org/Documentation/Manuals/MonetDB/Architecture
- https://www.monetdb.org/Documentation/Manuals/MonetDB/Architecture/Storagemodel
- https://www.monetdb.org/blog/monetdb-sql-transaction-management-scheme
Vergleichen Sie die Queries von MongoDB mit denselben in PostgreSQL,
welche dieselbe DVD-Datenbank "ds2" geladen hat.
Vergleichen Sie folgende Query von MongoDB mit derselben in PostgreSQL,
welche dieselbe DVD-Datenbank geladen "ds2" hat (in der Übung gibt es 34
weitere Queries):
Obschon Benchmarking schwierig ist, lassen sich folgende allgemeine
Aussagen machen:
MonetDB: sql\>`select avg(customerid) from cust_hist;`
- MonetDB ist schnell (schneller als z.B. PostgreSQL), wenn es um
sql:0.000 opt:18.483 run:32.425 clk:54.105 ms
PostgreSQL:
ds2=\#`explain analyze select avg(customerid) from cust_hist;`
...
Execution time: 807.310 ms
...
Zeit: 808.081 ms
Obschon solche einfachen Tests immer mit Vorsicht zu geniessen sind,
lassen sich folgende Aussagen machen:
- Der MonetDB-Server benötigt beispielsweise 54.105 ms (clk) während
PostgreSQL 807.310 ms (Execution time) benötigt für die obige
Aggregations-Query (ausgeführt auf einem 'alten' Laptop).
- MonetDB ist schnell bzw. schneller als z.B. PostgreSQL, wenn es um
Aggregationsfunktionen geht (GROUP BY, SUM/AVG) und wenn nur wenige
Ausgabe-Felder (Columns, Attributes) benötigt werden.
- PostgreSQL ist typischerweise bei der ersten Query-Durchführung (=
Kaltstart) oft langsamer und dann bei der wiederholten
Query-Durchführung schneller.
- Diese Unterschiede von Kalt- zu Warmstart sind bei MonetDB geringer;
dies besonders wenn die Daten im Memory Platz haben.
dies wenn die Daten im Memory Platz haben und besonders nach dem
allerersten Mal, wenn sie geladen sind.
### Aufgabe 1.2: Diskussion In-Memory Stores
MonetDB ist keine echte In-Memory Datenbank. MonetDB verwendet
"Memory-Mapped File Arrays". Wenn MonetDB eine memory-mapped Datei
verwendet, kann sie die Daten direkt im Speicher auf der Festplatte
abbilden (Array). Bei einer SQL-Query, wird sie auf eine mmap-Datei
abgebildet und dann vom Kernel des Betriebssystems in den Speicher
geladen. Wenn die Datensätze nicht mehr verwendet werden, wird ihr
Speicherplatz freigeben (virtuelle Speicherverwaltung).
MonetDB ist keine In-Memory Datenbank im eigentlichen Sinne. MonetDB
verwendet "Memory-Mapped File Arrays" bzw. memory-mapped Dateien. Wenn
MonetDB eine memory-mapped Datei verwendet, kann sie die Daten direkt im
Speicher auf der Festplatte abbilden (Array). Bei einer SQL-Query, wird
sie auf eine solche Datei abgebildet und dann vom Kernel des
Betriebssystems in den Speicher geladen. Wenn die Datensätze nicht mehr
verwendet werden, wird ihr Speicherplatz freigeben (virtuelle
Speicherverwaltung).
Memory/RAM-Zugriffe sind schneller als Disk-Zugriffe.
In-Memory-Datenbanken halten den gesamten Datensatz im Memory und
beantworten alle Anfragen daraus. Der Nachteil ist, dass die maximale
berechnen alle Anfragen daraus. Der Nachteil ist, dass die maximale
Grösse der Daten durch das verfügbare RAM begrenzt wird. Redis z.B. hat
verschiedene Möglichkeiten, die Daten dauerhaft auf Disk zu speichern.
Die Disk-Repräsentation kann dann verwendet werden, um den
......@@ -85,7 +103,7 @@ verwendet werden, um Anfragen direkt von der Festplatte zu beantworten.
Dies steht im Gegensatz zu RDBMS-Datenbanken wie PostgreSQL: RDBMS
halten immer den gesamten Datensatz einschliesslich der Indizes auf der
Festplatte in einem Format, das einen Random-Zugriff erlaubt. Queries
können direkt aus den Daten auf der Festplatte beantwortet werden. Die
können direkt aus den Daten auf der Festplatte berechnet werden. Die
Datenbank kann als Optimierung Caches oder Indizes in den Speicher
laden, aber das ist nicht unbedingt notwendig. Eine RDBMS kann mehr
Daten verarbeiten, als in den Arbeitsspeicher passen.
......@@ -119,8 +137,8 @@ Frage:
Frage:
- Diskutieren Sie die Vorteile von Column-Store gegebenüber Row-Stores
in mind. drei Sätzen?
- Diskutieren Sie die Vorteile von Column-Store gegenüber Row-Stores
in mindestens drei Sätzen?
## Aufgaben 2: MongoDB ff. - Sharding, Queries und Prüfungsfragen
......@@ -175,29 +193,30 @@ Stichworte zu den Antworten:
Bei (5), der Wahl eines Ranged Shard Keys, ist folgendes zu beachten:
Die Kardinalität eines Shard Key bestimmt die maximale Anzahl von
Partitionen, die der Balancer erzeugen kann. Ein guter Shard Key ist
einer mit hoher Kardinalität (Cardinality) und niedriger Häufigkeit
(Frequency). Dies erleichtert aber die horizontale Skalierung bzw.
Die Kardinalität eines Shard Keys bestimmt die maximale Anzahl von
Partitionen, die der MongoDB-Balancer erzeugen kann. Ein guter Shard Key
ist einer mit hoher Kardinalität (Cardinality) und niedriger Häufigkeit
(Frequency). Dies erleichtert die horizontale Skalierung bzw.
gleichmässige Verteilung der Daten. Man berücksichtige jeden dieser
Faktoren bei der Auswahl eines Splitterschlüssels. Wenn ein Datenmodell
ein Sharding auf einen Schlüssel mit niedriger Kardinalität erfordert,
kann man auch einen zusammengesetzten Index mit einem Feld mit höherer
Faktoren bei der Auswahl eines Shard Keys. Wenn ein Datenmodell ein
Sharding auf einen Schlüssel mit niedriger Kardinalität erfordert, kann
man auch einen zusammengesetzten Index mit einem Feld mit höherer
Kardinalität verwenden.
Die Häufigkeit des Splitterschlüssels gibt an, wie oft ein bestimmter
Wert in den Daten vorkommt. Gute Kandidaten sind Felder mit kleiner
Häufgkeit. Ein monoton aufsteigender Schlüsselwert - wie namentlich der
Idenfitikator (id) - ist zu vermeiden, denn damit würde nur der erste
Die Häufigkeit des Shard Keys gibt an, wie oft ein bestimmter Wert in
den Daten vorkommt. Gute Kandidaten sind Felder mit kleiner Häufgkeit.
Ein monoton aufsteigender Schlüsselwert - wie namentlich der
Identifikator (Id) - ist zu vermeiden, denn damit würde nur der erste
Shard/Partition verwendet, was die Verteilung verunmöglicht oder aber
ggf. zu aufwändigen Datenbank-internen Reorganisationen führt (vgl.
[choosing a shard
key](https://docs.mongodb.com/manual/core/sharding-shard-key/#choosing-a-shard-key)).
Zum Vergleich: Beim Hash-based Sharding genügt es, das Feld der
Collection anzugeben (z.B. Identifikator), der Hash wird dann vom System
berechnet. Man beachte auch die Ähnlichkeit eines hash-based Shard Keys
von MongoDB mit dem [Partition Key von Amazons
Zum Vergleich: Beim hash-based Sharding genügt es, das Feld der
Collection anzugeben (z.B. Identifikator). Der Hash wird dann vom System
berechnet. Mit dem Hash-based Sharding können auch monoton aufsteigende
Schlüsselwerte (Ids) verwendet werden. Man beachte die Ähnlichkeit eines
hash-based Shard Keys von MongoDB mit dem [Partition Key von Amazons
DynamoDB](https://aws.amazon.com/de/blogs/database/choosing-the-right-dynamodb-partition-key/)
(Quelle: AWS Database Blog zu "Choosing the Right DynamoDB Partition
Key").
......@@ -396,3 +415,4 @@ keywords:
- exam
title: 'Übung 13: NoSQL ff.'
---
KeyValueStore/README.solutions.md
+ 54
− 35
View file @ 55ac7467
# Übung 13: NoSQL ff. sowie Prüfungsvorbereitung
Dies ist eine spezielle Übung, denn die Vorlesung dieser Woche fällt
aus. Die Übung zu Key-Value Store entfällt. Dabei ist darauf
aus, welche die Key-Value Store-Übung ersetzt. Dabei ist darauf
hinzuwesien, dass das Thema Key-Value Stores einerseits in der Vorlesung
behandelt wurde, sowie andererseits in den [Übungen zu Dictionaries
(hstore) mit PostgreSQL](Datastructures/README.md).
......@@ -14,7 +14,7 @@ Diese Übung besteht aus folgenden, unterschiedlichen Teilen:
***Hinweise:***
Diese Übung ist eine reine Diskussion-, Denk- und Papier-Übung mit
Diese Übung ist eine Diskussion-, Denk- und Papier-Übung mit
zusätzlichen Informationen zu den NoSQL Stores MonetDB, MongoDB und
Neo4J.
......@@ -41,40 +41,58 @@ Als Vorbereitung wird voraussgesetzt, dass Sie die [Übung 12 "In-Memory
Column Store MonetDB"](ColumnStore/README.md) durchgearbeitet haben
sowie Zugang zu MonetDB mit geladener Datenbank Ds2 (DVD Store) haben.
Lesen Sie zudem mind. diese MonetDB-Doku.-Unterkapitel durch:
Lesen Sie zudem mindestens diese MonetDB-Unterkapitel durch:
- https://www.monetdb.org/Documentation/Manuals/MonetDB/Architecture
- https://www.monetdb.org/Documentation/Manuals/MonetDB/Architecture/Storagemodel
- https://www.monetdb.org/blog/monetdb-sql-transaction-management-scheme
Vergleichen Sie die Queries von MongoDB mit denselben in PostgreSQL,
welche dieselbe DVD-Datenbank "ds2" geladen hat.
Vergleichen Sie folgende Query von MongoDB mit derselben in PostgreSQL,
welche dieselbe DVD-Datenbank geladen "ds2" hat (in der Übung gibt es 34
weitere Queries):
Obschon Benchmarking schwierig ist, lassen sich folgende allgemeine
Aussagen machen:
MonetDB: sql\>`select avg(customerid) from cust_hist;`
- MonetDB ist schnell (schneller als z.B. PostgreSQL), wenn es um
sql:0.000 opt:18.483 run:32.425 clk:54.105 ms
PostgreSQL:
ds2=\#`explain analyze select avg(customerid) from cust_hist;`
...
Execution time: 807.310 ms
...
Zeit: 808.081 ms
Obschon solche einfachen Tests immer mit Vorsicht zu geniessen sind,
lassen sich folgende Aussagen machen:
- Der MonetDB-Server benötigt beispielsweise 54.105 ms (clk) während
PostgreSQL 807.310 ms (Execution time) benötigt für die obige
Aggregations-Query (ausgeführt auf einem 'alten' Laptop).
- MonetDB ist schnell bzw. schneller als z.B. PostgreSQL, wenn es um
Aggregationsfunktionen geht (GROUP BY, SUM/AVG) und wenn nur wenige
Ausgabe-Felder (Columns, Attributes) benötigt werden.
- PostgreSQL ist typischerweise bei der ersten Query-Durchführung (=
Kaltstart) oft langsamer und dann bei der wiederholten
Query-Durchführung schneller.
- Diese Unterschiede von Kalt- zu Warmstart sind bei MonetDB geringer;
dies besonders wenn die Daten im Memory Platz haben.
dies wenn die Daten im Memory Platz haben und besonders nach dem
allerersten Mal, wenn sie geladen sind.
### Aufgabe 1.2: Diskussion In-Memory Stores
MonetDB ist keine echte In-Memory Datenbank. MonetDB verwendet
"Memory-Mapped File Arrays". Wenn MonetDB eine memory-mapped Datei
verwendet, kann sie die Daten direkt im Speicher auf der Festplatte
abbilden (Array). Bei einer SQL-Query, wird sie auf eine mmap-Datei
abgebildet und dann vom Kernel des Betriebssystems in den Speicher
geladen. Wenn die Datensätze nicht mehr verwendet werden, wird ihr
Speicherplatz freigeben (virtuelle Speicherverwaltung).
MonetDB ist keine In-Memory Datenbank im eigentlichen Sinne. MonetDB
verwendet "Memory-Mapped File Arrays" bzw. memory-mapped Dateien. Wenn
MonetDB eine memory-mapped Datei verwendet, kann sie die Daten direkt im
Speicher auf der Festplatte abbilden (Array). Bei einer SQL-Query, wird
sie auf eine solche Datei abgebildet und dann vom Kernel des
Betriebssystems in den Speicher geladen. Wenn die Datensätze nicht mehr
verwendet werden, wird ihr Speicherplatz freigeben (virtuelle
Speicherverwaltung).
Memory/RAM-Zugriffe sind schneller als Disk-Zugriffe.
In-Memory-Datenbanken halten den gesamten Datensatz im Memory und
beantworten alle Anfragen daraus. Der Nachteil ist, dass die maximale
berechnen alle Anfragen daraus. Der Nachteil ist, dass die maximale
Grösse der Daten durch das verfügbare RAM begrenzt wird. Redis z.B. hat
verschiedene Möglichkeiten, die Daten dauerhaft auf Disk zu speichern.
Die Disk-Repräsentation kann dann verwendet werden, um den
......@@ -85,7 +103,7 @@ verwendet werden, um Anfragen direkt von der Festplatte zu beantworten.
Dies steht im Gegensatz zu RDBMS-Datenbanken wie PostgreSQL: RDBMS
halten immer den gesamten Datensatz einschliesslich der Indizes auf der
Festplatte in einem Format, das einen Random-Zugriff erlaubt. Queries
können direkt aus den Daten auf der Festplatte beantwortet werden. Die
können direkt aus den Daten auf der Festplatte berechnet werden. Die
Datenbank kann als Optimierung Caches oder Indizes in den Speicher
laden, aber das ist nicht unbedingt notwendig. Eine RDBMS kann mehr
Daten verarbeiten, als in den Arbeitsspeicher passen.
......@@ -119,8 +137,8 @@ Frage:
Frage:
- Diskutieren Sie die Vorteile von Column-Store gegebenüber Row-Stores
in mind. drei Sätzen?
- Diskutieren Sie die Vorteile von Column-Store gegenüber Row-Stores
in mindestens drei Sätzen?
## Aufgaben 2: MongoDB ff. - Sharding, Queries und Prüfungsfragen
......@@ -175,29 +193,30 @@ Stichworte zu den Antworten:
Bei (5), der Wahl eines Ranged Shard Keys, ist folgendes zu beachten:
Die Kardinalität eines Shard Key bestimmt die maximale Anzahl von
Partitionen, die der Balancer erzeugen kann. Ein guter Shard Key ist
einer mit hoher Kardinalität (Cardinality) und niedriger Häufigkeit
(Frequency). Dies erleichtert aber die horizontale Skalierung bzw.
Die Kardinalität eines Shard Keys bestimmt die maximale Anzahl von
Partitionen, die der MongoDB-Balancer erzeugen kann. Ein guter Shard Key
ist einer mit hoher Kardinalität (Cardinality) und niedriger Häufigkeit
(Frequency). Dies erleichtert die horizontale Skalierung bzw.
gleichmässige Verteilung der Daten. Man berücksichtige jeden dieser
Faktoren bei der Auswahl eines Splitterschlüssels. Wenn ein Datenmodell
ein Sharding auf einen Schlüssel mit niedriger Kardinalität erfordert,
kann man auch einen zusammengesetzten Index mit einem Feld mit höherer
Faktoren bei der Auswahl eines Shard Keys. Wenn ein Datenmodell ein
Sharding auf einen Schlüssel mit niedriger Kardinalität erfordert, kann
man auch einen zusammengesetzten Index mit einem Feld mit höherer
Kardinalität verwenden.
Die Häufigkeit des Splitterschlüssels gibt an, wie oft ein bestimmter
Wert in den Daten vorkommt. Gute Kandidaten sind Felder mit kleiner
Häufgkeit. Ein monoton aufsteigender Schlüsselwert - wie namentlich der
Idenfitikator (id) - ist zu vermeiden, denn damit würde nur der erste
Die Häufigkeit des Shard Keys gibt an, wie oft ein bestimmter Wert in
den Daten vorkommt. Gute Kandidaten sind Felder mit kleiner Häufgkeit.
Ein monoton aufsteigender Schlüsselwert - wie namentlich der
Identifikator (Id) - ist zu vermeiden, denn damit würde nur der erste
Shard/Partition verwendet, was die Verteilung verunmöglicht oder aber
ggf. zu aufwändigen Datenbank-internen Reorganisationen führt (vgl.
[choosing a shard
key](https://docs.mongodb.com/manual/core/sharding-shard-key/#choosing-a-shard-key)).
Zum Vergleich: Beim Hash-based Sharding genügt es, das Feld der
Collection anzugeben (z.B. Identifikator), der Hash wird dann vom System
berechnet. Man beachte auch die Ähnlichkeit eines hash-based Shard Keys
von MongoDB mit dem [Partition Key von Amazons
Zum Vergleich: Beim hash-based Sharding genügt es, das Feld der
Collection anzugeben (z.B. Identifikator). Der Hash wird dann vom System
berechnet. Mit dem Hash-based Sharding können auch monoton aufsteigende
Schlüsselwerte (Ids) verwendet werden. Man beachte die Ähnlichkeit eines
hash-based Shard Keys von MongoDB mit dem [Partition Key von Amazons
DynamoDB](https://aws.amazon.com/de/blogs/database/choosing-the-right-dynamodb-partition-key/)
(Quelle: AWS Database Blog zu "Choosing the Right DynamoDB Partition
Key").
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment