In-Memory Performance

Gerade habe ich noch mal überprüft, dass es Fälle gibt, in denen ich Artikel aus dem Oracle Scratchpad von Jonathan Lewis hier nicht verlinke. Das geschieht aber selten und gewöhnlich nur aus Gründen der Trägheit. Allerdings ist in der Tat nicht jeder Artikel von gleicher Bedeutung, manchmal sind die Themen auch relativ abgelegen und betreffen seltene Ausnahmefälle. Der aktuelle Artikel In-memory DB jedoch befasst sich mit einer recht grundsätzlichen Frage: wieso ist eine (column-store) In-Memory Datenbank effektiver als eine traditionelle (row-store) Datenbank, deren Daten sich komplett im Buffer Cache befinden?

Die Antwort erläutert zunächst das Verfahren beim traditionellen Tablescan einer komplett im Cache verfügbaren Tabelle: dabei muss für jeden einzelnen Block eine recht komplizierte Schrittfolge durchgeführt werden:

Oracle has to acquire the “cache buffers chains” latch, pin the block, drop the latch, and scan the block testing each row, then acquire the latch, unpin the block, and drop the latch.  Scanning the block requires a walk through the row directory and, for each row pointer, jumping to the correct location in the block for the row, stepping along the row one column at a time to get to the correct row, and then checking the column  value.

Im Fall des In-Memory Scans ist das Vorgehen ein grundsätzlich anderes:

1. Für jede einzelne Spalte wird eine eigene In-Memory-Repräsentation erstellt, so dass das relevante Datenvolumen, auf das zugegriffen werden muss, unter Umständen massiv reduziert werden kann.
2. Diese In-Memory-Repräsentation kann das im Speicher vorzuhaltende Datenvolumen durch Komprimierung/Deduplizierung noch einmal deutlich reduzieren. Diese Komprimierung ist ein grundsätzlicher Vorteil der column stores.
3. Die In-Memory-Repräsentation wird in einzelne Chunks unterteilt, zu denen jeweils die low und high value Angaben bekannt sind, was es ermöglichen kann, komplette Chunks zu überspringen.
4. Durch SIMD-Operationen (Single Instruction,  Multiple Data) kann der Zugriff im einzelnen Chunk weiter optimiert werden.

Für den Zugriff auf wenige Spalten ist das In-Memory-Verfahren in der Regel sehr effektiv - aber wenn sehr viele Spalten benötigt werden, kann dieser Vorteil gegenüber dem row-store verschwinden. Dabei gilt:

• Using the In-memory Database, you can identify the rows you want very quickly but it’s relatively slow to reconstruct them.
• Using a fully cached traditional row-store, it’s relatively slow to identify the rows you want, but once you’ve found them you spend no time reconstructing them.

Über diese grundsätzliche Analyse hinaus liefert der Artikel auch noch eine größere Anzahl von Links auf weitere Untersuchungen zum In-Memory-Thema - unter anderem auf Maria Colgans Artikelserie, aber auch auf andere relevante Beiträge.