Maria Colgan setzt ihre einführende Serie zum Verhalten der In-Memory Features in 12.1.0.2 mit einem Artikel Getting started with Oracle Database In-Memory Part IV - Joins In The IM Column Store fort, in dem sie - man ahnt es vielleicht schon - das Verhalten von Joins zwischen In-Memory-Objekten erläutert. Im Beispiel wird ein Join zwischen einer Faktentabelle und einer Dimensionstabelle durchgespielt, der angesichts fehlender Indizes sinnvollerweise als Hash Join durchgeführt wird. Zur Optimierung dieser Operation wird beim Aufbau der Hash Tabelle auf der kleineren Datenmenge zusätzlich ein Bloom Filter (also ein Bit Vektor) angelegt, der als zusätzliches Prädikat an den Scan der zweiten Tabelle übergeben wird. Nach Anwendung der Prädikate der Where-Bedingung wird der Bloom-Filter überprüft und nur die ihm entsprechenden Sätze werden dann an die Hash-Prüfung im Join weitergegeben (dazu gibt's eine übersichtliche Grafik, der leichter zu folgen sein dürfte als den beiden vorangehenden Sätzen). Im Ausführungsplan erscheint der Filter - wie üblich - mit einem Namen :BF0000. Das Verfahren funktioniert auch bei paralleler Ausführung und kann die üblichen Optimierungen verwenden, die dem Optimizer bei Operationen zur Verfügung stehen, bei denen keine In-Memory-Objekte beteiligt sind - also z.B. die Veränderung der Join-Reihenfolge im Hash Join über die swap_join_inputs-Optimierung. Auch diese Erklärung deutet darauf hin, dass es den Oracle-Entwicklern tatsächlich gelungen ist, die In-Memory-Objekte tief in die Kern-Elemente des Systems einzubetten und so auf abenteuerliche Sonderfallbehandlungen verzichten zu können.
Keine Kommentare:
Kommentar veröffentlichen