Die zweitschönste Nebensache der Welt

Nicht ganz so lange kann der Test auf Identität jeweils zweier aufeinanderfolgender Zeichenketten in einem Vektor aus 1 Million solcher Elemente dauern. Allerding nur auf dem Mainframe und mit "N-wise Reduce":

2≡/VEC

So harmlos dieser Ausdruck auch aussieht, er hat es in sich. Für den vorliegenden Fall langer Vektoren VEC mit relativ kurzen Zeichenketten (z.B. mit Länge 10) als Elemente habe ich nicht die Geduld gehabt ein Ergebnis abzuwarten. Denn selbst eine Schlewife, in deraufeinanderfolgende Vektorelemente vergleichen werden, wäre schon lange mit dem Thema durch gewesen. Erst rech natürlich die typische APL-Lösung ohne N-wise Reduce, selbst bei mehr als 1 Million zu vergleichender Objekte.

Später habe ich erfahren, das dieser Ausdruck mit den Daten wie hier beschrieben auf einem IBM Mainframe nach ca. 38 Stunden mit dem Ergebnis rausrückte. Für einen heutigen Großrechner eine halbe Ewigkeit.

Wer über viel Zeit und sehr gute Nerven verfügt, der hat die besten Voraussetzungen für Vista. Denn beides braucht man, wenn man von einem laufenden XP-System auf ein neues Vista-System migriert. Ärger ist vorprogammiert und viel Geduld gefordert.

Und was bringt das alles? Durchsichtige Fenster und angeblich mehr Sicherheit. Nach reichlich rumzickenden Installationen habe ich Zweifel, ob das die Mühe wert ist.

Im vorliegenden Fall bietet der neue Rechner nominell mehr als doppelte CPU-Leistung, 50% mehr an RAM und die doppelte Speicherkapazität. Mit Vista bestückt bringt das alles keinen offensichtlichen Geschwindigkeitsvorteil gegenüber dem Vergleichssystem unter XP. Eher im Gegenteil.

Angeblich soll Vista schneller starten als XP, nur merke ich im wirklichen Leben davon nichts. Die Zeit nach Neustart, die ich vergehen lassen muss, bis mir der Rechner wie gewohnt zur Verfügung steht, ich eher länger geworden. Mag sein, dass dies auch an den "Minianwendungen" liegt, die in die "Sidebar" geladen werden. Aber auch ohne diese kann von einem schnelleren Booten nicht die Rede sein.

Ich hatte von Anfang an ein gute Gefühl bei REPLACEX, eine der wichtigen Neuerungen des APL2 Service Level 11 vom November letzten Jahres. Im ICE von Hamburg nach Berlin hatte ich vor der GSE Herbsttagung 2007 Gelegenheit, REPLACEX ein wenig zu testen. Die Ergebnisse des Vergleichs mit REPLACEV, einer Funktion aus 1 UTILITY, mit verschieden langen Vektoren bzw. Teilvektoren waren überragend. Je länger die Zeichenkette, in der die Ersetzungen vorgenommen wurden, desto größer wurde der Unterschied zugunsten von REPLACEX.

REPLACEX funktionierte sogar noch, als REPLACEV mit WS FULL endgültig aufgeben musste. Dabei ist REPLACEV keine schlechte APL2-Variante für das Ersetzen der Vorkommen einer Zeichenkette durch eine beliebige andere.

Dies waren Versuche außerhalb jeglicher ernsthafter Anwendungen. Tatsächlich gehört das Ersetzen von Teilstrukturen durch Strukturen mit unterschiedlicher Dimension nicht zu den Stärken von APL, nicht nur in Sachen Performance. Das ist anders bei jeweils gleicher Größe. Der einfachste Fall, der im wirklichen Leben auch oft vorkommt, ist das Ersetzen von Dezimalpunkten durch Kommata und umgekehrt.

Mit dieser Frage hat sich sicher bereits jede Computerzeitschrift, die was auf sich hält, auseinandergesetzt. Da mir Vista bisher ziemlich egal war habe ich entsprechende Artikel auch konsequent ignoriert - bis auf einen. Nachdem ich nun Vista live "genießen" konnte, kann ich mit einigen Gerüchten über mögliche Vorteile aufräumen:

"Was wird dort also als Verbesserungen in Vista aufgeführt? Der Aero-Desktop? Interessiert mich nicht. Der verbesserte Explorer? Nett, aber brauche ich das?"

Der Aero-Desktop ist eher eine durchsichtige Spielerei. Glücklicherweise kann man ihn abschalten. Beim Explorer habe ich noch keine Verbesserung bemerkt. Das liegt wohl daran, dass die Handhabung erst einmal ungewohnt ist. Das irritiert bei der Navigation. Auf den ersten Blick sind das also keine Verbesserungen.

"Da ist die verbesserte Performance beim Booten schon bemerkenswerter."

Davon habe ich nicht viel bemerkt. Die Verbesserungen gegenüber XP fallen - wenn überhaupt - nicht so deutlich aus wie ich erwartet hätte.

"Bleiben noch als für mich möglicherweise interessante Neuerungen die verbesserte Speicherverwaltung ("macht Bluescreens seltener"), ..."

Mein XP produzierte kaum Bluescreens, ich kann mich mal gerade an zwei oder drei Situationen erinnern.

Summa summarum halten sich die möglichen Vorteile wohl eher in Grenzen. Dafür bekommt man immerhin ein Ressourcen verschlingendes Monster.

Um aus einer Liste beliebiger Elemente alle unterschiedlichen zu ermitteln gibt es seit APL-Gedenken das Unique-Idiom: VauiotaVauistgleichiotarhovaucompressvau (ohne explizite Nennung der Klammern). Seit APL2 können damit auch z.B. aus einer Liste von Namen der jeweils zuerst auftretende extrahiert werden.

Nun gibt es zu diesem Idiom mindestens eine Alternative: Sortiere alle Elemente des Vektors, untersuche paarweise jeweils aufeinanderfolgende Elemente auf Ungleichheit und reduzierte mit dem Ergebnis die ursprüngliche Liste. Angewandt auf Listen von Zeichenkette hielt ich diese Schreibweise in Sachen Performance für konkurrenzfähig zu UNIQUE - allerdings nur auf dem PC.

Denn auf dem Mainframe wird UNIQUE als Idiom erkannt und als Ganzes ausgeführt. Klar, dass dies deutliche Vorteile gegenüber Alternativen ergibt, dafür gibt es die Idiomerkennung schließlich.

Soweit ich weiß, gibt es sie nicht auf der Workstation Plattform. Also habe ich mal UNIQUE gegen die beschriebene Alternative gemessen und war überrascht:

Eigentlich wollte ich nur einen Langläufer testen - eine SQL-Query in der drei Tabellen mit ca. 300.000 Zeilen und eine Tabelle mit mehr als 10.000 Zeilen gejoint werden. Anlass war meine Beobachtung, dass das Komprimieren großer Tabellen neben Speichergewinn auch eine bessere Performance bringen kann. Würde auch hier die Verdichtung der beteiligten Tabellen den Langläufer beschleunigen?

Ich testete ihn also in zwei Datenbanken, eine davon enthielt die Tabellen in komprimierter Form. Anfangs wies db2batch für die Query mehr als 200 Sekunden aus, mit teilweise signifikant besseren Werten für die Variante mit den Komprimanten. Aber eben nur teilweise.

Um vertrauenswürdigere Daten zu bekommen, ließ ich die Abfragen mehrfach mit anderen Abfragen in kontrollierter Form ablaufen. Ich rechnete also mit langem Warten auf die Ergebnisse. Doch, Überraschung, nach einigen Sekunden war alles vorbei.

Von "Multi-row Fetch" oder "Multi-row Insert" hatte ich bisher nichts gehört, bis mich David fragte mich heute morgen danach fragte. Ein APL2-Fan wünscht sich wohl, dass der AP127 diese DB2-Features nutzt. Recht hat er.

Seit der Version 8 bietet die Programmierschnittstelle der DB2 für z/OS die Möglichkeit, mit nur einem Fetch auf mehr als nur eine Zeile des Resultsets zuzugreifen. Eine sehr sinnvolle Erweiterung, die mit der Version 8.2 dann auch für andere DB2-Plattformen zur Verfügung gestellt wurde. Es liegt wohl nur an der Beschränkheit der Mainstream-Programmiersprachen, dass obwohl ein SQL-Select eine Menge von Tabellenzeilen als Ergebnis ergibt, aber auf Elemente dieser Menge nur einzeln zugegriffen werden kann - Zeile nach Zeile per Schleife.

Für APL mit seiner hervorragenden Fähigkeit, komplette Datenstrukturen verarbeiten zu können, stellt diese Einschränkung eher einen ärgerlichen Logikbruch dar. Nur gut, dass mit dem AP127 per Parameter für den Fetch mehrere Ergebniszeilen mit einer Anweisung zum APL2 übertragen werden können.

Und hier ist die Theorie zur Praxis:

DB2 Explain schätzt für das teuerste Test-Select auf die umdefinierte Tabelle in unkomprimierter bzw. komprimierter Form folgende den Aufwände:

	unkomprimiert	zeilenkomprimiert
Gesamtaufwand	111.757,9453125000 Timeron	49.764,9921875000 Timeron	45%
CPU-Aufwand	6.189.640.704 Anweisungen	7.847.347.712 Anweisungen	127%
Ein-/Ausgabeaufwand	107.542 E/As	44.191 E/As	41%
Aufwand der ersten Zeile	1.755,8646240234 Timeron	786,0233154297 Timeron	44%

Danach wäre der Aufwand für die Ausführung des analysierten Selects für die verdichtete erheblich niedriger. Auf den ersten Blick passt das nicht so richtig zur Praxis, die bestenfalls einen Gleichstand ergab.

Bei näherem Hinsehen wird klar, dass der Gesamtaufwand nahezu komplett durch den geschätzten I/O bestimmt wird. Eine Verringerung des I/O bewirkt fast 10-mal stärker eine Reduzierung des Gesamtaufwandes als eine entsprechende Verminderung der CPU-Anweisungen. Das begründet große Performance-Vorteile für Zugriffe auf stark komprimierbare Tabellen.

Für unkomprimierte Tabellen, die komplett in den Buffer passen, entfällt der Aufwand für I/O. Dagegen entsteht für den Zugriff auf das (ebenfalls komplett im RAM abgelegte) komprimierte Analogon ein zusätzlicher CPU-Aufwand durch Dekomprimierung, der nun ungebremst zu einer entsprechenden Erhöhung des Gesamtaufwandes führt.

Die Theorie zeigt also, dass sich in besagter Praxis die Select-Anweisungen hauptsächlich aus dem Buffer bedient haben müssen.

Übrigens: der Aufwand für E/A entspricht hier der Größe der jeweiligen Tabelle in Anzahl 4K-Pages (npages).

Man kann eben nicht alles haben.

Die gleichen Performance-Vergleiche, die ich für die Original-Tabelle und ihr komprimiertes Abbild durchgeführt habe, habe ich auf die beiden umdefinierten Tabellen angewandt. Ich konnte keinen signifikanten Unterschied feststellen, egal in welcher Reihenfolge ich sie abgespielt habe.

Wenn überhaupt eine leichte Differenz zu erahnen ist, dann zuungunsten der komprimierten Variante. Mag sein, dass in beiden Fällen die Selects sich im Wesentlichen aus dem Buffer bedienen, also kaum teuren I/O produzieren. Für die Ergebniszeilen der komprimierten Tabelle kommen zusätzlich noch die CPU-Zyklen für die Dekomprimierung hinzu.

Das mag den - wenn überhaupt - kleinen, nicht signifikanten Unterschied erklären.

Überraschend und auch nicht überraschend.

Gemeint ist hier der Zugriff auf zeilenkomprimierte DB2 9 Tabellen. Denn das Selektieren von Daten bedeutet eben nicht nur Lesen von Bits und Bytes von Platte oder aus dem Datenbank-Buffer, sondern auch noch das rechenintensive Dekomprimieren der extrahierten Daten. Letzteres belastet den Prozessor mit Mehrarbeit.

Andererseits sinkt durch den geringere Größe der komprimierten Daten der Aufwand für I/O. Darüberhinaus kann aufwändiger I/O durch den wesentlich schnelleren Griff in den Buffer ersetzt werden, denn durch die Komprimierung kann dieser größere Teile der Tabelle im RAM vorhalten.

Es ist also ein Geben und Nehmen. Allgemein wird keine konkrete Vorhersage zu der Auswirkung der Zeilenkomprimierung einer Tabelle auf die Performance eines Zugriffs möglich sein. Bisherige Erfahrungen gehen davon aus, dass sich die Bearbeitungszeit für SQL-Statements nicht verschlechtert, und wenn Unterschiede festzustellen sind, dann zugunsten der komprimierten Variante.

Ich habe also erwartet, dass sich für meinen Test die Performance möglicherweise geringfügig verbessert. Dieser besteht ausschließlich aus Select-Statements, die einen unter Verwendung von Indexspalten, die anderen erfordern einen Scan der Tabelle.

Eigentlich sollte ich mich nicht durch Oracle's Marketinggetue provozieren lassen. Performance als das Thema der Oracle 11g, erstmals schneller als spezialisierte Dateisysteme? Beeindruckend?

Sicher nicht, solange Oracle mit seinem Vergleich mehr Fragen aufwirft als Antworten gibt. Gegen welches Filesystem wurde gemessen? Woher kamen die Daten aus der Datenbank? Von einem Raw Device oder gar aus dem Cache? Letzteres wäre schon fast Betrug.

Trotzdem: Es ist ja bekannt, dass Oracle Marketing schon oft mehr versprochen hat, als Oracle Software halten konnte.

Also: Abwarten und auf die Details zu den versprochenen Performance-Verbesserungen abwarten. Und dann gibt es ja noch TPC.

Das Gleiche gilt für die Aussagen zur verbesserten Kompression in der 11g.

Und wie sieht es mit insgesamt 482 neuen Features aus? Beeindruckend? "Mit wie vielen kann man wirklich was anfangen?" fragte Bernd.

Also: Abwarten und auf die Liste der Neuerungen warten.

Eine Neuerung scheint aber zu fehlen: Die konsequente Integration von XML so, wie es DB2 9 vermag. Es sieht also so aus, dass die armen, unschuldigen XML-Dokumente weiterhin vor der Speicherung in eine Oracle-Datenbank zerrissen und zerfetzt werden.

Während ich mich gestern abend, kurz vor Mitternacht, noch mit Pivot-Tabellen (nein, nicht mit Excel) beschäftigte, poppte mein Feed-Reader mit der Meldung "Oracle releases 11g database beta" noch. Überraschung! Verursacher ist ein Beitrag in "The Register" von gestern, 20.35 GMT.

Danach verbessert Oracle mit der 11g seine Kompressionstechnik. Man darf gespannt darauf sein, was genau dahinter steckt, und wie die Oracle-Kompression nun im Vergleich zu der von DB2 9 ausfällt.

Im IDG-Testbericht zur DB2 9 vermerkte der Redakteur zum Thema "Kompression":

"All the same, if I had to pick one feature that puts DB2 ahead of any of the other databases, this would definitely be the one, because it's going to be far more useful to the largest portion of the client base. I would imagine that Oracle and Microsoft are both scrambling to be the next to bring this to market."

Schafft also Oracle den Anschluß noch vor Microsoft?

... hat IBM nach eigenen Aussagen in die Entwicklung von DB2 9 gesteckt. In Sachen Performance scheint sich diese Investition gelohnt zu haben, zumindest aus Sicht des Marketings. Danach hält DB2 9 nun eine dreifache Benchmark-Krone:

"A key measure of the impact that these new technologies are having is the “big three” industry benchmark records (TPC-C, TPC-H and SAP SD) – collectively known as the Database performance triple crown."
...
"IBM today announced that with the introduction of DB2 9 it has set new record marks in each and has now won the “triple crown” of database performance for an unprecedented third time."

Für die TPC-Ergebnisse schlage man ebendort nach.

Das TPC-H-Ergebnis für DB2 9 scheint noch nicht veröffentlicht zu sein. Mal sehen, wann das erscheint.

Das TPC-C-Ergebnis kenne ich schon seit einigen Monaten. Auf den ersten Blick sieht es recht beeindruckend und eindeutig aus. Wenn man allerdings berücksichtigt, dass die Benchmarks auf jeweils unterschiedlicher Hardware gefahren wurden, relativiert sich der eine oder andere deutliche Vorsprung in Sachen reiner Performance.

Man sieht aber auf jeden Fall, dass DB2 9 in Sachen TPC-C besser performt als Oracle 10g.

Gerade im Vergleich mit Oracle wäre ein IDS-Benchmark spannend.

DB2 9 bietet viele Verbesserungen gegenüber den Vorversionen und auch gegenüber konkurrierenden DBMS, vor allem in Sachen Performance und TCO. Diese Neuerungen werden ausführlich in einem Bloor Research "White Paper" von Philip Howard beschrieben.

Immer wieder dieser PH. Dass er nicht nur Gutes über DB2 9 schreibt, sondern auch schon mal über Oracle Elaborate (warum bloss) zeigt sein Artikel "Oracle rebuilds Warehouse".

Doch zurück zu DB2 9 mit einigen Kernaussagen aus dem White Paper:

... ist ein weitreichendes und komplexes Unterfangen. Deshalb habe ich bisher tunlichst nur handverlesene Teilbereiche betrachtet.

Man suche z.B. einige Funktionen aus, die eine Datenbank bieten sollte, und vergleiche die Qualität der Unterstützung für ausgesuchte Datenbanken. So geschehen in "Die zweitbeste Datenbank der Welt". Man sollte auch die verglichenen Funktionen nennen, was ich dort offensichtlich nicht getan habe.

Das hole ich hier nach, nicht vollständig und auch nicht in der Reihenfolge des Vergleichs: Partitionierung, XML-Unterstützung, "Self Tuning" und Komprimierung.

Es müssen ja nicht nur Funktionen oder Features sein, es können auch Lizenzbedingungen sein. Das ist oft nicht weniger interessant, wie "Freie Datenbanken von unfreien Anbietern" zeigt.

Aber alles beleuchtet nur einen kleinen Ausschnitt. Ich denke, man kann ... wo ich das gerade schreibe, kommt auf meinem Rechner der RSS zu einem CW-Artikel zu einem DB-Benchmark-Tools herein. So ein Zufall.

Bernd hat den zweiten Vergleich getrackbackt. Dort wünschte sich ein Kommentator einen Vergleich der "Performance und Leistungsfähigkeit". Das ist nun ein schwierigeres Unterfangen, dem ich auch hier nicht nachkommen werde.

Doch einige Bemerkungen zu diesem Thema möchte ich hier loswerden: