in memory datenbanken
Als PPTX, PDF herunterladen0 gefällt mir1,097 aufrufe
In-Memory-Datenbanken ermöglichen es, die gesamte Datenbank im Hauptspeicher zu halten, was zu schnelleren Zugriffen und der Eliminierung von Disk-I/O führt. Durch neue Indexierungsstrukturen wie T-Tree und Trie wird die Effizienz beim Datenzugriff signifikant erhöht. Diese Technologien erfordern jedoch ausreichend physikalischen Speicher, um eine optimale Leistung zu gewährleisten.
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).
- 6. T-Tree Index (Oracle TimesTen)
- 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.