Modul 10: In Memory Datenbanken Flashcards

Question 1

Q

Agenda

Answer

A

Motivationsübung
Gründe/Motivation für
In-Memory Datenbanken
Fortschritte bei der
Hardware Entwicklung
Partitionierung
Kompression
Tupel Rekonstruktion
Scan Performance
Auswirkungen von DML Statements
Re-Merge des Differential Buffers
Indizes
Aggregate
Logging und Recovery
Data Aging
Reorganisation

Question 2

Q

Was bedeutet der Begriff Dictionary Encoding im Column Store?

Answer

A

• Spalte wird in ein Dictionary und einen Attributvektor geteilt
• Dictionary speichert alle vorkommenden Werte genau einmal und versieht
sie mit einer ValueID
• Attributvektor speichert für jedes Element in der Spalte die entsprechende
ValueID
• Keine Zeilen mehr!

Question 3

Q

Was spricht für In Memory Datenbanken?

Unterpunkt: Was sind typische Applikationen in Unternehmen?

Answer

A

1. Transactional
o Transaktionale Applikationen
o User Interaktionen
o Maschinen
2. Analytics
o Reporting
o Planung
o Simulation
3. Event Processing
o Maschinen
o Sensoren
4. Text Analyse / Unstrukturierte Daten
o Web
o Social media
o Logfiles
o Support Systeme

Konsequenz:
Spezifische (Datenbank-) Applikationen in Unternehmen gehen unterschiedlich mit Datenerfassung, -speicherung und –verarbeitung
um und sind meist entweder für Transaktionen oder Analyse optimiert.

Question 4

Q

Gründe für IMDB

Gegenüberstellung OLTP vs. OLAP Systeme

Answer

A

OLTP:
- Hohe Anzahl meist einfacher Adhoc Transaktionen
- Viele parallele Nutzer
- Viele Schreib- und Lesezugriffe
- Rollenbasiert
- Kurze Transaktionen
- Kleine Ergebnismenge
OLAP:
- Weniger Transaktionen dafür komplexe Rechenoperationen
- Weniger parallele Nutzer
- Hauptsächlich Lesezugriffe meist für umfassende Berichte
- Für bestimmte Nutzer (Sales Account Executive, Executive Board)
- Lange Transaktionen
- Sehr grosse Ergebnismenge

Question 5

Q

Gründe für IMDB

Konsequenzen aus der Zusammenarbeit von OLTP und OLAP Systemen nach der Gegenüberstellung OLTP vs. OLAP Systemen

Answer

A

Hoher Synchronisations Aufwand zwischen Systemen, meist OLTP → OLAP
Zeitverzug, oft nicht die neusten Daten im OLAP System
Redundanzen
Inkonsistenzen
Unterschiedliche Datenschemas
Erhöhte Kosten durch Beschaffung und Betrieb
Hoher Aufwand für Aggregate
Günstigere Hardware mit grossem Hauptspeicher

Question 6

Q

Gründe für IMDB

Weshalb ausgerechnet ein Column Store?

Answer

A

Viele Spalten werden gar nicht genutzt (~50% aller Spalten)
Viele Spalten haben sehr niedrige Kardinalität (z.B. Land, Geschlecht, …)
Viele NULL / DEFAULT Werte
Niedrige statistische Verteilung der Dateninhalte unterstützen Kompression

Question 7

Q

Gründe für IMDB

Fazit

Answer

A

Sind OLTP und OLAP wirklich so unterschiedlich?
• Analyse über sehr viele Kundensysteme zeigt, dass Schreib- und Lesezugriffe sich nicht
signifikant unterscheiden
• Je nach Industrie sind die Schreibzugriffe sogar sehr gering (Bsp: Banking)

Wunsch der Kunden
• nach EINEM System
• ohne Redundanzen und Inkonsistenzen

Idee/Vision
• keine Aggregate
• keine Views
• alles wird zur Laufzeit errechnet
• alle Daten befinden sich im Hauptspeicher / Cache

Question 8

Q

Fortschritte bei der Hardware

Entwicklung

Answer

A

• Multi-Core Architektur mit bis zu 8
x 28 Core CPU per Blade
• Paralle Verarbeitung über Blades
hinweg
• Blade Server Preis schon unter
50.000€
• Bis zu 24 TB RAM pro Board
• Durchsatz > 100 GB/s (Skylake SP,
Xeon 8180M, 8-socket)
• Kosten / Performance Verhältnis
extrem stark fallend
• Kopierzeit von 5GB/s mit
Infiniband

Question 9

Q

Blade Server

Answer

A

Blades nutzen eigene Platine mit Mikroprozessor, Arbeisspeicher und
Plattenspeicher
• Zusätzlicher Plattenspeicher kann über SAN oder NAS angedockt werden
• Lüftung nicht zentral sondern über Rückwand

Question 10

Q

Infiniband

Answer

A

• Bidirektionaler serielles Bus System
• Latenzarme Datenübertragung (< 2µs)
• Kann Hauptspeicher mehrerer Cores
miteinander verknüpfen
• Übertragung bis 2,5 GB/s

ermöglicht verteilten Hauptspeicher Zugriff
und Tabellen können somit über
Knoten verteilt werden

Question 11

Q

Partitionierung von Tabellen

Answer

A

• Parallele Ausnutzung mehrerer Core CPUs, die auf ein Shared Memory
zugreifen, erhöht Verarbeitungsgeschwindigkeit signifikant (→ Blade Server)
• Partitionierung legt Methode fest nach der die Daten verteilt werden und
unabhängige und distinkte Teile
• Kenntnis der Anfrage ist notwendig

Question 12

Q

Partitionierungsarten

Answer

A

Vertikale Partitionierung
• Aufteilung der Tabelle entlang einer Spalte in Attributgruppen
• Verbindung über Primärschlüssel

Bereichspartitionierung
• Auftrennung der Tupel in Bereiche z.B.
o In 5 Bereiche nach Kontinent
o In 200 Bereiche nach Land
o In 5 Bereiche nach Geburtstag: < 1925 < 1950 < 1975 < 2000 < 2025

Hash Partitionierung
• Wähle ein Attribut als Hash Kriterium
• Lege Anzahl bits fest für Partitionierung (Bsp: 3 bits für 8
Partitionen)
• Verteile die Daten gleichmäßig

Applikations Partitionierung
• Wähle Kriterien aus der Applikation zur Verteilung
• Beispiele:
• Bestellzeitraum
• Versionen eines Artikels
• ....

Question 13

Q

Datenkompression im Kontext von In Memory Datenbanken und Column Stores

Answer

A

• Für Attributvektoren
o Prefix Verschlüsselung
o Run Length Verschlüsselung
o Cluster Verschlüsselung
o Sparse Verschlüsselung
o Indirekte Verschlüsselung
• Für Dictionary
o Delta Kompression
o Sortierte Arrays

Question 14

Q

Prefix Komprimierung

Answer

A

Ersparnis wenn eine Spalte mit einer langen Reihe desselben Wertes beginnt
oder
• ein bestimmter Wert kommt sehr häufig vor und die anderen Werte seltener
• Wert wird nur einmal gespeichert inkl. der Anzahl der Vorkommen
• Voraussetzung: Tabelle sortiert nach Spalte
• Direkter oder nur indirekter Zugriff möglich? → Direkt!

Question 15

Q

Run Length Komprimierung

Answer

A

Ersetze Sequenz desselben Wertes mit einer einzelnen Instanz des Wertes
und
o Der Anzahl des Auftretens
o Der Startposition
• Direkter oder nur indirekter Zugriff möglich? → Direkt

Question 16

Q

Cluster Komprimierung

Answer

A

Attributvektor wird aufgeteilt in N Blöcke gleicher Größe (z.B. 512 Byte)
• Wenn das Cluster immer nur einen Wert enthält, erscheint der Wert nur
einmal
• Wenn das Cluster unterschiedliche Werte enthält, werden diese 1:1 dort
abgelgt
• Ein Bitvektor zeigt an, ob Fall 1 oder Fall 2
• Direkter oder nur indirekter Zugriff möglich? → Indirekt, nur über Bitvektor
möglich!

Question 17

Q

Verstreute (Sparse) Komprimierung

Answer

A

• Attributvektor wird nach häufigstem Wert durchsucht
• Ein Bitvektor zeigt an an welcher Stelle der Wert entfernt wurde
• Direkter oder nur indirekter Zugriff möglich? → Indirekt, nur über Bitvektor
möglich!

Question 18

Q

Indirekte Komprimierung

Answer

A

AV ist partitioniert in N Blöcke der Größe S (z.B. 512)
• Wenn der Block viele verschiedene Einträge enthält → keine Aktion
• Wenn Block wenige unterschiedliche Einträge enthält → Block wird mit
Dictionary Encoding komprimiert
• Direkter oder nur indirekter Zugriff möglich? → Direkt!

Question 19

Q

Delta Komprimierung

Answer

A

Für Dictionary Tabelle
• Macht Sinn bei Sortierung
• Blockweise Komprimierung

Question 20

Q

Fazit aus der Beschreibung der verschiedenen Komprimierungsarten

Answer

A

• Unterschiede zwischen Attributvektor und Dictionary Komprimierung
• Direkt oder nur indirekter Zugriff möglich
• Meist sortierte Spalten nötig, Tabellen können nur nach einer Spalte sortiert
werden

Question 21

Q

INSERT im Column Store

Answer

A

• INSERT INTO Weltbevoelkerung
VALUES („Bernd“, „Schulze“, m, „GER“, „Niedertupfingen“, 08.08.1988)
• Spaltenweises Einfügen
• Jeweiliges Prüfen ob Wert im Dictionary vorhanden ist oder nicht

Ist der Wert im Dictionary vorhanden -> Wert im Attributvektoraufnehmen

Ist der Wert im Dictionary nicht vorhanden -> Wert in Dictionary einfügen und entsprechenden Wert im Attributvektor einfügen

Question 22

Q

UPDATE im Column Store

Answer

A

• UPDATE = DELETE + INSERT
• 3 Arten von Updates
o Unverschlüsselt
o Verschlüsselt mit unsortiertem Dictionary
o Verschlüsselt mit sortiertem Dictionary  häufigster Fall

Question 23

Q

DELETE im Column Store

Answer

A

Lösche Eintrag im Attributvektor
• Sortiere AV neu
• Falls nicht letzter Eintrag im
Dictionary: evtl. Dictionary neu
aufbauen

Question 24

Q

Ursachen Reorganisation im

Column Store

Answer

A

Gründe für Reorganisation des Dictionary oder des Attributvektors
• Einfügen/Ändern neuer Werte ins Dictionary
→ Reorg Dictionary → Reorg Attributvektor
• Breite des Dictionary verlängert sich
→ Komplettumbau Dictionary → Reorg Attributvektor
• Löschen einer Zeile (ohne Dictionary Auswirkung)
→ Zusammenschieben des Attributvektors
• Einfügen einer Zeile (ohne Dictionary Auswirkung)
→ Auseinanderziehen des Attributvektors

Question 25

Q

Vermeidung Reorg im Column Store

Answer

A

Reorganisation des Dictionary und des Attributvektors sehr
aufwändig!
• Vermeidungsansatz 1
o Datensätze nie löschen
o Gültigkeit mit Zeitstempel kenntlich machen
• Vorteil
o Integrierte Historie
o Automatisches Logging
o Einfache Snapshots
o Keine Reorgs mehr
• Nachteil
o Anstieg Speicherbedarf

Question 26

Q

Vermeidung Reorg im Column Store 1: Zeitstempel

Answer

A

• Einführung einer extra Spalte „Gueltig_ab“ (oder „Gueltig_bis“)
• INSERT / UPDATE hat keinen Effekt auf alte Tupel
• SELECT Operationen müssen immer das letzte Tupel ausfindig machen
→ kann mit Bitvektor entschärft werden

Question 27

Q

Vermeidung Reorg im Column Store 2: Bereiche ?

Answer

A

Vermeidungsansatz 2

o Einführung eines separaten Bereichs, der alle Änderungen beinhaltet → Delta- / Differential Buffer
o Lesen zuerst aus DiffBuff, wenn nicht vorhanden dann aus Hauptspeicher
o Schreiben nur in DiffBuff

• Vorteil
o Inserts schnell, da kein Reorg oder Re-Sort

• Nachteil
o Differential Buffer braucht zusätzlichen Speicher
o Range SELECT über DiffBuff und Hauptspeicher aufwändiger und damit langsamer
o Zusätzlicher Gültigkeitsvektor notwendig
o Regelmäßiger Re-Merge von DiffBuff und Hauptspeicher nötig

Question 28

Q

Was bedeutet es den Differential Buffer mit dem Hauptspeicher zu verschmelzen?

Welchen Grund hat die Verschmelzung?

Answer

A

Alle Schreiboperationen (INSERT, UPDATE, DELETE) werden immer
zunächst im Differential Buffer eingetragen
• Veränderte Werte im Hauptspeicher werden mit Gültigkeitsvektor
ungültig geflagged
• Es werden immer nur die „gültigen“ Datensätze auf Differential Buffer
und Hauptspeicher gelesen
• Problem: Lesen auf Differential Buffer und Hauptspeicher verlangsamt
Performance
• Abhilfe: regelmäßiges Zurückschreiben des Differential Buffers in den
Hauptspeicher, sowohl Dictionary als auch Attributvektor

Question 29

Q

Verschmelzung des Differential Buffers mit Anleitung

Answer

A

Vorüberlegungen:

Bevor damit begonnen werden kann einen Differentialbuffer mit dem Hauptspeicher zu verschmelzen ist es notwendig, über einen Differentialbuffer zu verfügen den man Mergen kann.

Mit anderen Worten heißt das, man benötigt Änderungen in der der Datenbank zugrunde liegenden Relationen.

Sind Änderungen vorhanden kann der Mergeprozess wie folgt durchgeführt werden.

Schritt 1: Gültigkeitscheck

alle ungültigen Records landen im History File

Schritt 2: Dictionary kombinieren

Der Inhalt der beiden Dictionnaires wird lexografisch korrekt miteinander kombiniert.

Schritt 3: Mapping von altem Diffbuff + HSP Dictionary auf das neue Dictionary

Es wird eine Mapping Tabelle die beschreibt in wiefern der Kombinationsprozess aus Schritt 2 die einzelnen Tupel in der Relationsstruktur vertikal verschoben hat.

Schritt 4: Aktualisierung des Attributvektors

Mithilfe des Mapping aus Schritt 3 kann nun der entprechende Attributvektor aktualisiert werden

5.Schritt: Differential Buffer auflösen und neue HSP Attributvektor und Dictionary aufbauen

Kombination der gerade aktualisierten Attributvektoren aus Schritt 4.

Question 30

Q

Dictionary Indexierung eine Einführung:

Was ist der Hintergrund zur Dictionary Indexierung.

Was ist ein Delta Index?

Answer

A

• Delta ist klein, braucht aber schnelle Performance bei INSERT
• Wie finde ich schnell den Wert zu einer Value ID im Dictionary? Oder
umgekehrt?
• Nutze B+ Bäume
o Value ID = Knoten
o Werte = Verweis auf sortiertes Dictionary

Question 31

Q

Wie wird die Dictionary Indexierung umgesetzt?

Answer

A

Schritt 1: Sortieren des Attributvektors in festgelegter lex. Reihenfolge von Dictionary

Schritt 2: Run Length Encoding des sortierten Attributvektors aus Schritt 1

Question 32

Q

Verlauf einer typischen Attributleseprozesses aus Attributvektor

Answer

A

Finde gesuchtes Attribut in Dictionary
Finde die Row Id des Attributs
Finde den Offset in IO
Hole Offset des nächsten Wertes
Suche in diesem Intervall Offset 2 - Offset 1
Hole Rowids

Question 33

Q

Aggregate

Answer

A

• Aggregate arbeiten auf Datenmengen und nicht auf einzelnen Records
• Mit HAVING kann die Datenmenge noch einmal eingeschränkt werden
Typische Aggregat Funktionen: COUNT, SUM, AVG, MAX, MIN,
MEDIAN, …

Question 34

Q

Aggregat Cache

Answer

A

• In RDBMS werden Aggregate auf unterschiedliche Weise vorgehalten
o OLAP: Materialisierte Views
o OLTP: Applikation hält interne Tabellen oder Wertebereiche vor
• Nachteile
o Applikationslogik wird komplizierter
o Verlangsamung bei Schreiboperationen
o Erzeugung von Redundanzen
o Unflexible Analyse, da bei neuen Abfragen erst die Aggregat Tabellen angepasst werden müssen
• Ziel
o Vermeide vordefinierte materialisierte Aggregate und Summen Tabellen
o Ausführung von OLTP und OLAP Abfragen in einem System
o Komplexitätsreduktion
o Flexible Realtime Analyse

• Idee
o Lege Aggregat Ergebnisse in den Hauptspeicher
o Errechne neue Aggregate, die durch Änderungen entstehen, zur Laufzeit und lege sie um Differential
Buffer ab
o Für jedes SELECT xxx FROM yyy GROUP BY zzz HAVING wird ein eigener Eintrag erstellt
o Aggregat Erstellung wird verzögert bis zum Delta Merge
o Aggregate nach INSERTs werden durch Laufzeit Aggregation im DiffBuff aufgefangen
o Aggregate nach UPDATE und DELETE werden durch Bitvektoren im Hauptspeicher und DIffBuff
kenntlich gemacht und neu berechnet

Question 35

Q

Aggregat Cache Auflösung

Answer

A

• Ziel
o Limitiere Cache Wachstum
o Halte Maintenance niedrig
• Kostenbasierte Ansätze
o Anzahl Tupel
o Anzahl Berechnungen
o Ergebnismenge
o Anzahl Invalidierungen des Hauptspeichers

Question 36

Q

Logging und Recovery

Was ist der Hintergrund von Recovery?

Wie ist Recovery definiert?

Welche Varianten von Recovery gibt es?

Answer

A

Hintergrund
• Ausfallsicherheit
• Notwendigkeit bei Rechnerausfall auf letzten „commited“ Zustand
zugreifen zu können

• Definition: Recovery ist der Prozess ein System nach dessen Ausfall auf
den letzten Stand vor Absturz zurück zu bringen
• Ziel dabei ist möglichst kurze Recoveryzeit ohne Datenverlust

• Varianten:
o Logfile auf Backup Medium Schreiben
o Replication des(r) kompletten Server(s) auf replizierte Datenbank

Question 37

Q

Logging

Aus welchen Verfahren setzt sich Logging zusammen?

Answer

A

Snapshots werden periodisch
geschrieben
• Logfiles für Updates werden
zwischen den Snapshots
geschrieben
• Dictionary Änderungen werden
separiert geschrieben

Question 38

Q

Logging

Wie sind die Verfahren im einzelnen definiert?

Answer

A

• Snapshots schreibt die Primärdaten periodisch auf persistenten Speicher
und werden meist nach Merge Prozess erstellt
• Im Logging werden Update/Delete/Insert Statements mit Parametern in
komprimierter Form im Logfile abgelegt
• Im Dictionary Log werden alle Dictionary Änderungen in komprimierter
Form abgelegt

Question 39

Q

Dictionary Logging

Wie findet Dictionary Logging im Detail statt?

Welche Logs werden während des Dictionary Logging erstellt?

Welche Vorteile hat das Dictionary Logging?

Answer

A

• Schreibe Dictionary Änderungsdaten entkoppelt von Transaktionen
• ValueID Vektor und Dictionary Daten können separat recovered werden
• Logfile Größe kleiner
• 3 unterschiedliche Logs:
o Dictionary Logs (d) für komplettes Dictionary (Tabellen ID, Spaltenindex, Value ID)
o Value Logs (v) für Value Vektor (Transaktions ID, Tabellen ID, Zeilen ID, Value ID Vektor)
o Transaction Logs (t) halten Transaktions ID, die nach jedem Flush erhöht wird

Hat Vorteile bei
• Langen Daten, die mehrfach eingetragen werden
• Anzahl distinct values ist niedrig

Question 40

Q

Recovery

Wie findet die Recovery einer Datenbank statt, gehen Sie insbesondere auf den mit dem Recovery Prozess verbundenen Auslesen der Inhaltsdaten ein?

Answer

A

Lese Metadaten aus letztem Snapshot und Transaktions ID der letzten
Transaktion aus dem Snapshot
Lese Inhaltsdaten in parallelisierter Form
a) Hauptspeicherdaten vom Snapshot
b) Dictionary vom Differential Buffer durch Einspielen der Dictionary Logfiles
c) Einlesen der Value ID Vektoren aus dem Differential Buffer

Question 41

Q

Data Aging

Was ist der Unterschied zwischen Data Aging und Data Archiving?

In Bezug auf die Motivation, Methode, dem Umgang mit Daten die hinter den Verfahren steckt, sowie auf den Zeitpunkt seit dem die Verfahren eine Rolle spielen.

Answer

A

Data Aging      vs  Data Archiving
Motivation
Data Aging: 
Performance und Datenvolumen
Optimierung
Data Archiving:
Legale und Compliance Anforderung

Methode 
Data Aging: 
Datenschema bleibt gleich 
Data Archiving:
Transformation in Archivformat

Umgang mit Daten
Data Aging:
„Alte“ Daten bleiben erhalten und direkt
zugreifbar (Applikationstransparent)

Data Archiving:
Archivierte Daten werden explizit
wieder eingespielt. Nicht sichtbar für
Standard Abfragen

Seit Wann
Data Aging: 
Neue Herausforderung 
Data Archiving:
Schon immer

Question 42

Q

Data Aging

Was ist Data Aging und warum benötigt man es?

Answer

A

Relevante Daten (Hot Data) sollten nicht behandelt werden wie irrelevante
Daten (Cold Data)

Grund:
• Daten „veralten“ immer schneller
• Datenmenge steigt rapide an (Bsp. IOT, …)
• Kosten für Hauptspeicher für Speicherung irrelevanter Daten viel zu hoch
• Performance - insbes. bei JOINs und Aggregaten (Potenzierung!)
o Buffer
o Pagelist
o Indizes

Question 43

Q

Wie lässt sich Data Aging umsetzen? Hat die Umsetzungidee Probleme ? Wenn Ja, wie lassen sich einige der Probleme lösen?

Answer

A

Idee:
• Identifiziere Hot Data als all die Daten, auf die zugegriffen wird und verankere sie
im Hauptspeicher
• Identifiziere Daten, die nicht mehr verwendet werden als Cold Data
• Verlagere Cold Data auf Sekundärspeicher bzw. Flash
• Applikation darf keine Abhängigkeit zu Datenalter und Speicherort haben
Problem:
• Vorab nicht immer klar wie sich alte und neue Daten unterscheiden
Lösung:
• Analyse der typischen SQL Abfragen und Datentreffer zur Laufzeit
• Erstellung Nutzungsstatistiken
• Festlegen von dynamischen Aging Regeln
• Horizontale (Projektion) und vertikale (Selektion) Datentrennung

Question 44

Q

Fazit zum Data Aging Verfahren

Answer

A

Zusammenfassung:
• Reduktion der Daten im Hauptspeicher auf Hot Data
• Identifikation der Daten durch Analyse der Applikation (Queries +
Statistiken)
• Verlagerung der Cold Data auf günstigeren Sekundärspeicher (z.B. Flash)
• Applikation selbst kennt keine Unterscheidung von Hot und Cold Data!
• Vorteil: bessere Performance und günstigere Kosten
• Nachteil: zusätzliche Intelligenz im DBMS

Question 45

Q

Datenbank Reorganisation

Was wird unter DB Reorg verstanden?

Was sind die Ursachen eines DB Reorg?

Answer

A

Häufiges Problem in DBMS
• DB Schema und Daten Layout ändern sich während des Betriebs
Ursachen
• Neue DB Version mit neuen Master Tabellen
• Anpassungen der Tabellen und Indizes wegen Performance Verbesserungen
• Schema Anpassung durch Applikationsänderung

Question 46

Q

Datenbank Reorganisation beim Rowstore

Answer

A

Row Store
• Datensätze liegen fast immer Seite an Seite auf DB Page
• Änderungen am Schema bspw. ALTER TABLE Add
bewirken komplette Neuverteilung der Datensätze auf die
einzelnen Seiten
• Während der Reorganisation ist die komplette Tabelle gesperrt!
• Je nach Tabelle muss u.U. die komplette Datenbank herunter gefahren
werden
• Schon kleine Änderungen wie bspw. Verlängerung eines Feldes können
extreme Auswirkungen haben

Question 47

Q

Wie können die Probleme, die bei der Datenbank Reorganisation des Row Stores auftreten gelöst werden?

Hat die Lösung Nachteile?

Answer

A

Mögliche Lösung für Row Store
• Es wird eine neue Tabelle angelegt, die nur die neuen bzw.
veränderten Datentypen enthält
• Über die ursprüngliche Tabelle sowie wird eine View gelegt
➔Nachteile:
• Ggfs. schlechtere Performance wegen verteilten Daten
• Overhead für Verwaltung
• Komplexität steigt

Question 48

Q

Datenbank Reorganisation beim Column Store

Answer

A

Column Store
• Jede einzelne Spalte wird völlig unabhängig von den Nachbarspalten
abgelegt!
• Hinzufügen oder Verlängern von Spalten, Ändern des Datentyps problemlos
möglich, da eigener Speicherbereich
• Kein Tabellenlock!
• Nur das DDIC muss kurze Zeit gesperrt werden

Brainscape's Knowledge GenomeTM

Modul 10: In Memory Datenbanken Flashcards

Brainscape's Knowledge Genome^TM