SlideShare ist ein Scribd-Unternehmen logo
1 von 16
In-Memory Datenbanken

      Arno Schmidhauser
    Letzte Revision: Januar 2011
Neues technologisches Umfeld

• Bisher
   – Eine Datenbank konnte nur zu Bruchteilen im Memory
     gehalten werden ( << 50%).
   – Sparsamkeit beim Datentransfer zwischen Disk und Memory
     ist daher oberstes Prinzip.
   – I/O-Page als Grundeinheit der physischen Memory-
     Verwaltung (durch die DB, nicht durch das OS).

• Neu
   – Systemstabilität durch Hardware und Betriebssystem-
     Features massiv höher als früher. Recovery aufgrund von
     Systemausfällen nur noch selten notwendig.
   – Standard-Memory Ausstattung > 4GB kein Problem mehr.
Neues Prinzip

• Datenbank bei Start des DB-Servers vollständig in das
  Memory laden (z.B. Unix Memory Mapped Files).

 Das gesamte Buffer-Management entfällt, der Speicher
  wird als linearer Adressraum für Datensätze angesehen,
  alle Positionen gleich schnell adressierbar.

 Zugriff auf beliebiges Datenelement immer gleich schnell.
  Transfer von/zu Disk muss nicht mehr berüchsichtigt
  werden.
Mutationen

• ACID Regel ist immer noch ein zwingendes Prinzip!


 2. SQL-Befehl

                                          Workspace =
                 2b. Neue
                                       Gesamte Datenbank
                 Datenwerte



                              1. Startup =       3. Shutdown oder
          2a. Alte und neue                      Checkpoint =
                              Gesamte DB laden
          Datenwerte                             Ganze DB speichern


     Logfile                              DB-Storage
Neue Optimierungsmöglichkeiten

• Indexe werden bei Systemstart im Memory aufgebaut.
  Keine materialisierten Indexe mehr.

• Keine komplizierte Datensatz-Adressierung auf die Disk
  notwendig, da die Daten selber ja bereits im Memory sind.

• Indexe brauchen die Schlüsselwerte nicht noch einmal zu
  enthalten, da die Daten selber ja bereits im Memory sind.
    Zusätzliche Ersparnis von Memory gegenüber
     klassischen Datenbank.
    Neue Index-Strukturen: zum Beispiel T-Tree (Oracle)
     und Trie (IBM).
T-Tree Index (Oracle TimesTen)
T-Tree Index
• Über alles gesehen wesentlich weniger Code abzuarbeiten,
  da keine Diskzugriffe zu berücksichtigen sind.

• Wenig Platzbedarf für Index, da nur Pointer auf Daten
  nötig sind, und nicht die Datenwerte selbst.

• Binäre Verzweigung und kleine Anzahl Werte (Pointer) pro
  Knoten garantiert hohe CPU-Effizienz. Keine lineare Suche
  durch grosse IO/Pages hindurch.

• Anwendbar wie B-Tree: für Suche mit exakten Vergleiche
  und Range-Suche geeignet.

• Achtung: Peformance-Desaster bei zuwenig Memory !!
Trie-Index (IBM solidDB)


        t                         r



    e       o
                         e            a
            8
            9
d       a   10   a
                              d           t
1       4
2                             12
3                    s                    13




                         t

                         11
Trie-Index

• Das Auffinden von Schlüsselwerten ist sehr schnell,
  Zeitbedarf nur proportional zur Länge des Schlüsselwertes!

• Alle Werte mit demselben Präfix teilen sich die Knoten für
  dieses Präfix, z.B. "to" und "toast". Suche nach Werten mit
  demselben Präfix via Trie möglich, z.B. like – Prädikat.

• Auch Zahlen können mit einem Trie indexiert werden.

• Tries können sortiert aufgebaut werden, so dass dann eine
  preorder-Ausgabe ebenfalls sortiert ist.

• Demo unter http://blog.ivank.net/trie-in-as3.html
IMDB als "relationaler Cache"

• Oracle TimesTen und IBM solidDB können als schneller
  relationaler Cache verwendet werden:
Latenzzeit für Queries

• Aufgrund der einfacheren Optimizer (meist nur ein bis
  zwei Indextypen und sequentieller Table Scan zur
  Auswahl), sowie massiv kleinerem Code, liegt die
  Latenzzeit für Queries und Änderungsoperationen
  typischerweise bei Mikrosekunden. Bei klassischen
  Datenbanken sind es meist Millisekunden.
Gemischter Betrieb mit IMDB

• DB-Hersteller bieten zunehmend einen gemischten Betrieb
  von disk-basierten und memory-basierten Teilen an.

• Beispiel solidDB
  create table T (…) store memory | store disk

• Aus dem Speichertyp der Tabelle werden alle übrigen
  Verhaltensweisen abgeleitet: Indextyp,
  Zugriffsoptimierung, Verhalten bei Startup, Checkpoint
  und Shutdown des DB-Servers.
Solid State Disk

• Datenbanken können aus den schnelleren Solid State
  Disks Gewinn ziehen, insbesondere auch für das Führen
  von Log-Files. Die Grundsatztechnologie geht aber von
  klassischen Datenbanksystemen aus:
   – mehrstufiger Zugriff Disk-Memory
   – IO/Pageing
   – Komplexe, zeitintensive Optimierungsstrategien

• Eine noch höhere Performance wird erreicht, wenn wenig-
  selektive Indexe gelöscht oder vermieden werden, damit
  vermehrt Full Table Scans vom DBMS ausgeführt werden.
Kennzahlen SSD
                                   MLC-NAND-Flash-
                                                             CompactFlash-Karte               Festplatte
                                      Laufwerk
                                         1,0″ bis 3,5″         per ATA-Adapter               1,0″ bis 3,5″
Größe                         bis 600 GB                 bis 128 GB               bis 3 TB
Preis pro GB (Stand Dez.
2011)                         ab ca. 0,96 €              ab ca. 1,02 €            ab ca. 0,05 €

Anschluss                     S-ATA, P-
                              ATA, mSATA, PCIe           S-ATA, P-ATA             S-ATA, P-ATA, SCSI, SAS
Lesen (kein RAID)             bis 509 MB/s               bis 100 MB/s             bis 150 MB/s
Schreiben (kein RAID)         bis 446 MB/s               bis 100 MB/s             bis 150 MB/s
Mittlere Zugriffszeit lesen   0,2 ms                     0,8 ms                   ab 3,5 ms
Mittlere Zugriffszeit schreiben 0,4 ms                   10…35 ms                 ab 3,5 ms
Verhalten beim PC-
Ausschalten                   problemlos                 problemlos               problemlos

Verhalten bei Stromausfall
                              ohne Stützkondensator
                              Datenverlust möglich       Datenverlust möglich     Datenverlust möglich
In Memory DMBS, Produkte

•   Oracle Times Ten
•   solidDB von IBM
•   HSQLDB
•   Apache Derby
•   XML-Datenbank BaseX

• Weitere siehe bei Column Stores
Zusammenfassung Ziele eines
          In-Memory-DBMS
• Eliminierung von Disk-IO für den laufenden Betrieb des DBMS
• Ausnutzung der virtuellen Memory-Verwaltung des Betriebs-
  systems

• Minimierung aller roten
  Bereiche in nebenstehendem
  Profilingdiagramm eines
  klassischen DBMS

• Voraussetzung: Ausreichend
  Platz für das gesamte DBMS
   im physikalischen Memory,
  inklusive temporären Platz für
  SQL-Abfragen.

Weitere ähnliche Inhalte

Was ist angesagt?

HDD & SSD Grundlagen
HDD & SSD GrundlagenHDD & SSD Grundlagen
HDD & SSD Grundlagenjcambass
 
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungBack to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungMongoDB
 
Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?
Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?
Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?Thomas Stensitzki
 
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuerWerner Fischer
 
Compact, Compress, De-DUplicate
Compact, Compress, De-DUplicateCompact, Compress, De-DUplicate
Compact, Compress, De-DUplicateUlrich Krause
 

Was ist angesagt? (6)

HDD & SSD Grundlagen
HDD & SSD GrundlagenHDD & SSD Grundlagen
HDD & SSD Grundlagen
 
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungBack to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
 
Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?
Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?
Thomas' Tech Talk 4 - Lohnt sich ein Wechsel zu Exchange Server 2019?
 
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
20101011 roadshow-2010-ssds-grundlagen-know-how-und-konkrete-konfiguration-fuer
 
Compact, Compress, De-DUplicate
Compact, Compress, De-DUplicateCompact, Compress, De-DUplicate
Compact, Compress, De-DUplicate
 
Platz schaffen auf dem Domino - Compact, Compress, De-Duplicate - Ulrich Krau...
Platz schaffen auf dem Domino - Compact, Compress, De-Duplicate - Ulrich Krau...Platz schaffen auf dem Domino - Compact, Compress, De-Duplicate - Ulrich Krau...
Platz schaffen auf dem Domino - Compact, Compress, De-Duplicate - Ulrich Krau...
 

Andere mochten auch

Oracle Database Mobile Server Performance Tuning
Oracle Database Mobile Server Performance TuningOracle Database Mobile Server Performance Tuning
Oracle Database Mobile Server Performance Tuningphilipploer
 
2017 DB Trends for Powering Real-Time Systems of Engagement
2017 DB Trends for Powering Real-Time Systems of Engagement2017 DB Trends for Powering Real-Time Systems of Engagement
2017 DB Trends for Powering Real-Time Systems of EngagementAerospike, Inc.
 
In Memory Computing for Agile Business Intelligence
In Memory Computing for Agile Business IntelligenceIn Memory Computing for Agile Business Intelligence
In Memory Computing for Agile Business IntelligenceMarkus Alsleben, DBA
 
TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING
TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTINGTDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING
TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTINGOPITZ CONSULTING Deutschland
 
From distributed caches to in-memory data grids
From distributed caches to in-memory data gridsFrom distributed caches to in-memory data grids
From distributed caches to in-memory data gridsMax Alexejev
 
In Memory-Technologien im Vergleich - SQL Server Konferenz 2015
In Memory-Technologien im Vergleich - SQL Server Konferenz 2015In Memory-Technologien im Vergleich - SQL Server Konferenz 2015
In Memory-Technologien im Vergleich - SQL Server Konferenz 2015Marcel Franke
 
Mist gemessen? Java Performance und Memory Analyse
Mist gemessen? Java Performance und Memory Analyse Mist gemessen? Java Performance und Memory Analyse
Mist gemessen? Java Performance und Memory Analyse adesso AG
 

Andere mochten auch (9)

Oracle Database Mobile Server Performance Tuning
Oracle Database Mobile Server Performance TuningOracle Database Mobile Server Performance Tuning
Oracle Database Mobile Server Performance Tuning
 
2017 DB Trends for Powering Real-Time Systems of Engagement
2017 DB Trends for Powering Real-Time Systems of Engagement2017 DB Trends for Powering Real-Time Systems of Engagement
2017 DB Trends for Powering Real-Time Systems of Engagement
 
In Memory Computing for Agile Business Intelligence
In Memory Computing for Agile Business IntelligenceIn Memory Computing for Agile Business Intelligence
In Memory Computing for Agile Business Intelligence
 
TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING
TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTINGTDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING
TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING
 
From distributed caches to in-memory data grids
From distributed caches to in-memory data gridsFrom distributed caches to in-memory data grids
From distributed caches to in-memory data grids
 
Introduction to Aerospike
Introduction to AerospikeIntroduction to Aerospike
Introduction to Aerospike
 
In Memory-Technologien im Vergleich - SQL Server Konferenz 2015
In Memory-Technologien im Vergleich - SQL Server Konferenz 2015In Memory-Technologien im Vergleich - SQL Server Konferenz 2015
In Memory-Technologien im Vergleich - SQL Server Konferenz 2015
 
2011 01 06 09-30 alexej freund
2011 01 06 09-30 alexej freund2011 01 06 09-30 alexej freund
2011 01 06 09-30 alexej freund
 
Mist gemessen? Java Performance und Memory Analyse
Mist gemessen? Java Performance und Memory Analyse Mist gemessen? Java Performance und Memory Analyse
Mist gemessen? Java Performance und Memory Analyse
 

Ähnlich wie in memory datenbanken

Oracle Advanced Compression - Erfahrungen aus dem praktischen Einsatz
Oracle  Advanced Compression - Erfahrungen aus dem praktischen EinsatzOracle  Advanced Compression - Erfahrungen aus dem praktischen Einsatz
Oracle Advanced Compression - Erfahrungen aus dem praktischen EinsatzPeter Ramm
 
Performance-Analyse von Oracle-Datenbanken mit Panorama
Performance-Analyse von Oracle-Datenbanken mit PanoramaPerformance-Analyse von Oracle-Datenbanken mit Panorama
Performance-Analyse von Oracle-Datenbanken mit PanoramaPeter Ramm
 
Sql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint AdministratorenSql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint AdministratorenCommunardo GmbH
 
Sql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point AdminsSql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point AdminsSharepointUGDD
 
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...AWS Germany
 
Exchange Server 2019 MetaCache Database und BigFunnel
Exchange Server 2019 MetaCache Database und BigFunnelExchange Server 2019 MetaCache Database und BigFunnel
Exchange Server 2019 MetaCache Database und BigFunnelThomas Stensitzki
 
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatengeKarin Patenge
 
20111006 roadshow-io-performance
20111006 roadshow-io-performance20111006 roadshow-io-performance
20111006 roadshow-io-performanceWerner Fischer
 
Data Mining und OLAP
Data Mining und OLAPData Mining und OLAP
Data Mining und OLAPmurat9393
 
Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)
Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)
Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)data://disrupted®
 
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...OPITZ CONSULTING Deutschland
 
Oracle-DB: Active Session History: into the deep
Oracle-DB: Active Session History: into the deepOracle-DB: Active Session History: into the deep
Oracle-DB: Active Session History: into the deepPeter Ramm
 
SQL Server Transaction Log Deep Dive Session - PASS Hamburg
SQL Server Transaction Log Deep Dive Session - PASS HamburgSQL Server Transaction Log Deep Dive Session - PASS Hamburg
SQL Server Transaction Log Deep Dive Session - PASS HamburgSascha Lorenz
 
Nosql Hintergründe und Anwendungen
Nosql Hintergründe und AnwendungenNosql Hintergründe und Anwendungen
Nosql Hintergründe und AnwendungenAndy Whole
 
Internet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQLInternet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQLFromDual GmbH
 
mongoDB im Einsatz - Grundlagen
mongoDB im Einsatz - GrundlagenmongoDB im Einsatz - Grundlagen
mongoDB im Einsatz - Grundlageninovex GmbH
 

Ähnlich wie in memory datenbanken (20)

Oracle Advanced Compression - Erfahrungen aus dem praktischen Einsatz
Oracle  Advanced Compression - Erfahrungen aus dem praktischen EinsatzOracle  Advanced Compression - Erfahrungen aus dem praktischen Einsatz
Oracle Advanced Compression - Erfahrungen aus dem praktischen Einsatz
 
Performance-Analyse von Oracle-Datenbanken mit Panorama
Performance-Analyse von Oracle-Datenbanken mit PanoramaPerformance-Analyse von Oracle-Datenbanken mit Panorama
Performance-Analyse von Oracle-Datenbanken mit Panorama
 
Amazon Redshift
Amazon RedshiftAmazon Redshift
Amazon Redshift
 
Sql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint AdministratorenSql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint Administratoren
 
Sql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point AdminsSql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point Admins
 
Boston webcast nv_me_2016-09
Boston webcast nv_me_2016-09Boston webcast nv_me_2016-09
Boston webcast nv_me_2016-09
 
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
 
Column Stores
Column StoresColumn Stores
Column Stores
 
Exchange Server 2019 MetaCache Database und BigFunnel
Exchange Server 2019 MetaCache Database und BigFunnelExchange Server 2019 MetaCache Database und BigFunnel
Exchange Server 2019 MetaCache Database und BigFunnel
 
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
 
20111006 roadshow-io-performance
20111006 roadshow-io-performance20111006 roadshow-io-performance
20111006 roadshow-io-performance
 
Data Mining und OLAP
Data Mining und OLAPData Mining und OLAP
Data Mining und OLAP
 
Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)
Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)
Die IBM 3592 Speicherlösung: Ein Vorgeschmack auf die Zukunft (Anne Ingenhaag)
 
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
 
CPU Update Juni 2017
CPU Update Juni 2017CPU Update Juni 2017
CPU Update Juni 2017
 
Oracle-DB: Active Session History: into the deep
Oracle-DB: Active Session History: into the deepOracle-DB: Active Session History: into the deep
Oracle-DB: Active Session History: into the deep
 
SQL Server Transaction Log Deep Dive Session - PASS Hamburg
SQL Server Transaction Log Deep Dive Session - PASS HamburgSQL Server Transaction Log Deep Dive Session - PASS Hamburg
SQL Server Transaction Log Deep Dive Session - PASS Hamburg
 
Nosql Hintergründe und Anwendungen
Nosql Hintergründe und AnwendungenNosql Hintergründe und Anwendungen
Nosql Hintergründe und Anwendungen
 
Internet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQLInternet Briefing 2011: NoSQL with MySQL
Internet Briefing 2011: NoSQL with MySQL
 
mongoDB im Einsatz - Grundlagen
mongoDB im Einsatz - GrundlagenmongoDB im Einsatz - Grundlagen
mongoDB im Einsatz - Grundlagen
 

in memory datenbanken

  • 1. In-Memory Datenbanken Arno Schmidhauser Letzte Revision: Januar 2011
  • 2. Neues technologisches Umfeld • Bisher – Eine Datenbank konnte nur zu Bruchteilen im Memory gehalten werden ( << 50%). – Sparsamkeit beim Datentransfer zwischen Disk und Memory ist daher oberstes Prinzip. – I/O-Page als Grundeinheit der physischen Memory- Verwaltung (durch die DB, nicht durch das OS). • Neu – Systemstabilität durch Hardware und Betriebssystem- Features massiv höher als früher. Recovery aufgrund von Systemausfällen nur noch selten notwendig. – Standard-Memory Ausstattung > 4GB kein Problem mehr.
  • 3. Neues Prinzip • Datenbank bei Start des DB-Servers vollständig in das Memory laden (z.B. Unix Memory Mapped Files).  Das gesamte Buffer-Management entfällt, der Speicher wird als linearer Adressraum für Datensätze angesehen, alle Positionen gleich schnell adressierbar.  Zugriff auf beliebiges Datenelement immer gleich schnell. Transfer von/zu Disk muss nicht mehr berüchsichtigt werden.
  • 4. Mutationen • ACID Regel ist immer noch ein zwingendes Prinzip! 2. SQL-Befehl Workspace = 2b. Neue Gesamte Datenbank Datenwerte 1. Startup = 3. Shutdown oder 2a. Alte und neue Checkpoint = Gesamte DB laden Datenwerte Ganze DB speichern Logfile DB-Storage
  • 5. Neue Optimierungsmöglichkeiten • Indexe werden bei Systemstart im Memory aufgebaut. Keine materialisierten Indexe mehr. • Keine komplizierte Datensatz-Adressierung auf die Disk notwendig, da die Daten selber ja bereits im Memory sind. • Indexe brauchen die Schlüsselwerte nicht noch einmal zu enthalten, da die Daten selber ja bereits im Memory sind.  Zusätzliche Ersparnis von Memory gegenüber klassischen Datenbank.  Neue Index-Strukturen: zum Beispiel T-Tree (Oracle) und Trie (IBM).
  • 7. T-Tree Index • Über alles gesehen wesentlich weniger Code abzuarbeiten, da keine Diskzugriffe zu berücksichtigen sind. • Wenig Platzbedarf für Index, da nur Pointer auf Daten nötig sind, und nicht die Datenwerte selbst. • Binäre Verzweigung und kleine Anzahl Werte (Pointer) pro Knoten garantiert hohe CPU-Effizienz. Keine lineare Suche durch grosse IO/Pages hindurch. • Anwendbar wie B-Tree: für Suche mit exakten Vergleiche und Range-Suche geeignet. • Achtung: Peformance-Desaster bei zuwenig Memory !!
  • 8. Trie-Index (IBM solidDB) t r e o e a 8 9 d a 10 a d t 1 4 2 12 3 s 13 t 11
  • 9. Trie-Index • Das Auffinden von Schlüsselwerten ist sehr schnell, Zeitbedarf nur proportional zur Länge des Schlüsselwertes! • Alle Werte mit demselben Präfix teilen sich die Knoten für dieses Präfix, z.B. "to" und "toast". Suche nach Werten mit demselben Präfix via Trie möglich, z.B. like – Prädikat. • Auch Zahlen können mit einem Trie indexiert werden. • Tries können sortiert aufgebaut werden, so dass dann eine preorder-Ausgabe ebenfalls sortiert ist. • Demo unter http://blog.ivank.net/trie-in-as3.html
  • 10. IMDB als "relationaler Cache" • Oracle TimesTen und IBM solidDB können als schneller relationaler Cache verwendet werden:
  • 11. Latenzzeit für Queries • Aufgrund der einfacheren Optimizer (meist nur ein bis zwei Indextypen und sequentieller Table Scan zur Auswahl), sowie massiv kleinerem Code, liegt die Latenzzeit für Queries und Änderungsoperationen typischerweise bei Mikrosekunden. Bei klassischen Datenbanken sind es meist Millisekunden.
  • 12. Gemischter Betrieb mit IMDB • DB-Hersteller bieten zunehmend einen gemischten Betrieb von disk-basierten und memory-basierten Teilen an. • Beispiel solidDB create table T (…) store memory | store disk • Aus dem Speichertyp der Tabelle werden alle übrigen Verhaltensweisen abgeleitet: Indextyp, Zugriffsoptimierung, Verhalten bei Startup, Checkpoint und Shutdown des DB-Servers.
  • 13. Solid State Disk • Datenbanken können aus den schnelleren Solid State Disks Gewinn ziehen, insbesondere auch für das Führen von Log-Files. Die Grundsatztechnologie geht aber von klassischen Datenbanksystemen aus: – mehrstufiger Zugriff Disk-Memory – IO/Pageing – Komplexe, zeitintensive Optimierungsstrategien • Eine noch höhere Performance wird erreicht, wenn wenig- selektive Indexe gelöscht oder vermieden werden, damit vermehrt Full Table Scans vom DBMS ausgeführt werden.
  • 14. Kennzahlen SSD MLC-NAND-Flash- CompactFlash-Karte Festplatte Laufwerk 1,0″ bis 3,5″ per ATA-Adapter 1,0″ bis 3,5″ Größe bis 600 GB bis 128 GB bis 3 TB Preis pro GB (Stand Dez. 2011) ab ca. 0,96 € ab ca. 1,02 € ab ca. 0,05 € Anschluss S-ATA, P- ATA, mSATA, PCIe S-ATA, P-ATA S-ATA, P-ATA, SCSI, SAS Lesen (kein RAID) bis 509 MB/s bis 100 MB/s bis 150 MB/s Schreiben (kein RAID) bis 446 MB/s bis 100 MB/s bis 150 MB/s Mittlere Zugriffszeit lesen 0,2 ms 0,8 ms ab 3,5 ms Mittlere Zugriffszeit schreiben 0,4 ms 10…35 ms ab 3,5 ms Verhalten beim PC- Ausschalten problemlos problemlos problemlos Verhalten bei Stromausfall ohne Stützkondensator Datenverlust möglich Datenverlust möglich Datenverlust möglich
  • 15. In Memory DMBS, Produkte • Oracle Times Ten • solidDB von IBM • HSQLDB • Apache Derby • XML-Datenbank BaseX • Weitere siehe bei Column Stores
  • 16. Zusammenfassung Ziele eines In-Memory-DBMS • Eliminierung von Disk-IO für den laufenden Betrieb des DBMS • Ausnutzung der virtuellen Memory-Verwaltung des Betriebs- systems • Minimierung aller roten Bereiche in nebenstehendem Profilingdiagramm eines klassischen DBMS • Voraussetzung: Ausreichend Platz für das gesamte DBMS im physikalischen Memory, inklusive temporären Platz für SQL-Abfragen.