Mit Hilfe der BLU Technologie kann die Abfrageperformance in ganz erheblichen Maße gesteigert werden. Die Vorgehensweise ist, Zugriffe auf den Storage weitestgehend zu vermeiden und IO-Performance, RAM- und CPU-Nutzung durch verschiedene parallel arbeitende und sich ergänzende Funktionen zu optimieren. Speziell für BI-Systeme, die typischerweise abfragelastig sind, ist dies ein sehr großer Mehrwert, der ohne allzu hohe Hardware-Kosten erreicht werden kann. Zudem ist mit der Restriktion auf maximal 16 CPU-Kerne und maximal 128 GB RAM der Einsatz der Technik auch ohne eine Enterprise Lizenz möglich. Im Falle der noch aktuellen Version11.1 reicht eine Advanced Workgroup Edition, im Falle der aktuellsten Version 11.5 die Standard Edition aus. Allerdings bestehen BI-Systeme in der Regel nicht ausschließlich aus Datamarts. Das eigentliche Core Data Warehouse eines BI-Systems ist typischerweise:

• in dritter Normalform modelliert und
• weniger mit Abfrage- als eher mit insert/update/delete-Workload konfrontiert.

Und genau hier stoßen In-Memory Datenbanken im Allgemeinen an ihre Grenzen. Während sie für die Abfrageperformance bestens optimiert sind, sind schreibende Transaktionen typischerweise weniger performant als bei klassischen zeilenorientierten Datenbanken. Insbesondere dann, wenn in der where clause von updates oder deletes mehrere Bedingungen gesetzt sind, bricht die Performance gegenüber klassischen zeilenorientierten Datenbanken leider ein.
Diese Herausforderung führte zunächst dazu, dass IBM im August 2014 mit dem Fixpack 4 sogenannte Shadow Tables einführte. Das Grundkonzept dahinter ist, dass schreiblastige Aktivitäten auf klassische zeilenorientierte Tabellen angewendet werden. Wird die BLU Beschleunigung gebraucht, setzt man eine spaltenorientierte materialisierte View auf die zeilenorientierte Tabelle auf, die sogenannte Shadow Table. Alle Tabellen, die typischerweise in Abfragen mit der Shadow Table hinzu gejoined werden, müssen zur Nutzung der BLU Beschleunigung auch spaltenorientiert sein, ob mit oder ohne Shadow Table. Das Datenbankmanagementsystem erkennt dann an der Art der Anfrage, wann die spaltenorientierte bzw. die klassische zeilenorientierte Quelle genutzt wird. Um die materialisierte spaltenorientierte View zeitnah aktuell zu halten, kommt IBM Data Replication zum Einsatz. In der Praxis gibt es allerdings einige kleinere Restriktionen, beispielsweise werden bestimmte Zeitfunktionen oder auch Integritätsmechanismen (etwa restricted foreign keys) nicht
unterstützt. Sehr viel Schreiblast führt erhöht die Fehleranfällligkeit der Replikation, die immer wieder manuelle Eingriffe in den Prozess erfordert. Außerdem werden Backup/Recovery-Konzepte und der Umgang mit Logarchiven etwas komplexer in der Handhabung. In einem großen Data Warehouse Projekt bei einem DAX 30 Automobilkonzern, hatten wir die Chance, Db2 BLU mit dem Konzept der Shadow Tables im Beta-Stadium zu testen. Somit konnten wir über unseren Kunden Feedback an die Db2-Entwicklung der IBM zurückspiegeln. Das Konzept der Shadow Tables ist auch in der aktuellen Version der Db2 weiterhin enthalten. Die Weiterentwicklung geht aber eher in die Richtung, die Scheib-Transaktionen in BLU Tabellen stärker zu parallelisieren. Es wird letztlich versucht, ohne die Verwendung von Shadow Tables auszukommen. Dies funktioniert zwischenzeitlich auch zufriedenstellend.
Allerdings sind schreibende und verändernde Transaktionen in zeilenorientierten Tabellen immer noch schneller. Kann man sich bei der Bewirtschaftung eines ausgegliederten Datamarts noch mit Staging-Tabellen und Bulk Loads behelfen, sind BLU Tabellen, die quasi immer verfügbar sein sollen und auf die viele schreibende Transaktionen treffen, nach wie vor keine befriedigende Lösung.
Folgt man der Empfehlung der IBM zur optimalen Nutzung der Db2 mit maximaler Performance für alle Transaktionen, trennt man typischerweise die gesamte Installation in eine BLU Datenbank und eine klassische zeilenbasierte Datenbank, auch innerhalb einer Instanz. Das macht vor allem dahingehend Sinn, als dass zur optimalen Nutzung von BLU diverse Datenbankparameter speziell eingestellt werden sollten und diese Empfehlungen für klassische zeilenorientierte Ansätze eher weniger sinnvoll sind. So sollte etwa der Sortheap Speicher Parameter bei BLU Datenbanken sehr groß gewählt sein, die Page Size muss 32Bit sein etc. Bei gemischten Workloads kommt es daher zu Speicherengpässen und ggf. Performanceverlusten bei der Nutzung der zeilenorientierten Tabellen, wenn alle Vorgaben und Empfehlungen umgesetzt werden. Andersherum funktioniert die BLU Beschleunigung nicht hundertprozentig, wenn die Empfehlungen nicht umgesetzt werden. Dabei sind die Vorgaben, wie etwa die große Page Size, zwingende Voraussetzung. Eine korrespondierende Installation könnte so aussehen, dass Datamarts in einer BLU Datenbank liegen und der ganze Rest in einer zeilenorientierten Datenbank.
Der Nachteil an der Trennung der Datenbanken ist, dass man nun gezwungen ist, Daten zwischen den Datenbanken zu transferieren. Somit ist es dann durch Nutzung des Federation-Features möglich, Tabellen aus beiden Welten miteinander zu joinen. Tendenziell braucht eine solche getrennte Lösung mehr Ressourcen und erzeugt damit potenziell auch höhere Lizenzkosten. Daher entstand aus dem Kundenprojekt zusammen mit dem Automobilhersteller heraus ein Kompromiss-Ansatz. Dieser kommt mit nur einer Datenbank aus und erhält dennoch eine ausgewogene Performance, sowohl für Abfragen als auch für schreibende und verändernde Transaktionen. Dabei kommt das Data Warehouse mit seiner mehr als ein Terrabyte großen Datenbank sogar mit der „kleinen“ Db2-Lizenz aus. Dieser Lösungsansatz bei einem Großunternehmen, der unter erheblichen Kostendruck entstanden ist, eignet sich ganz hervorragend für mittelständigen Unternehmen. So kommen sie in den Genuss der BLU Beschleunigung, ohne ein allzu komplexes System aufsetzen und verwalten zu müssen und ohne eine Enterprise Lizenz der Db2 nutzen zu müssen.