The buck stops here – NoSQL unter einem anderen Licht
Die bekannte Aussage „The buck stops here“, auf dem Schreibtisch im Weißen-Haus, lässt sich auch auf die unzähligen Schreibtische der IT-Architekten übertragen.
Quelle: Buck Stops Here sign on Truman’s Desk, studyourhistory.com/archives/596
Die Konzepte und Technologien des über 45 Jahre alten Mainframes erleben beinahe unerkannt eine Renaissance – der Mainframe ist nicht tot. Eine enorme Leistungsfähigkeit und Ausfallsicherheit zeichnet den Mainframe aus. Diese Eigenschaften sind gleichermaßen Sinnbild und angestrebtes Ziel jeder IT-Architektur.
Es gilt auch für die bekannten Unternehmen des Web X.0 Zeitalter, wie Suchmaschinen oder Marktplätze. Es stellt sich am Ende des Tages jedoch die Frage, warum NoSQL und nicht der Mainframe beinahe untrennbar mit diesen Unternehmen verknüpft ist. Bei genauer Betrachtung liegen die Gründe auf der Hand. Es sind nicht rechenintensive Operationen, es ist der Umfang an zu bearbeitenden Bestandinformationen die den Unterschied machen.
Der Preis der Verfügbarkeit
Wird nur der Mainframe betrachtet, hat sich die Anzahl der Mainframe MIPS in den letzten Jahren beinahe verdoppelt. Fast linear an die MIPS-Größe sind auch die Kosten gekoppelt.
Somit wird beim Mainframe quasi die Anzahl der möglichen Operationen bezahlt. In vielen Organisationen ist es zwar gleichen den fachlichen Operationen. Natürlich weicht die Erwartung oftmals von den tatsächlich erzielten Operationen ab. Die Wirtschaftlichkeit des Mainframes steht damit in direkter Verbindung mit dem Wissen über den Umfang an möglichen fachlichen Operationen. Bei den Web X.0 Unternehmen ist und war dieser Punkt eine Unbekannte. Womöglich ist es der entscheidende Grund, warum diese Unternehmen nicht auf den Mainframe gesetzt haben. Es galt für diese Unternehmen Alternativen zum Mainframe zu finden.
Gefunden wurden Alternativen, die unter dem Sammelbegriff “NoSQL” bezeichnet werden. Dabei sind nicht nur die „Kein SQL Datenbanken“ gemeint, sondern das komplette Ecosystem um diese Datenbanken herum. NoSQL ist somit die Antwort auf ein dynamisches und schnell änderndes Geschäftsumfeld. Aber wie kann NoSQL eine Antwort auf dieses Umfeld sein, wenn das Datenaufkommen und die benötigte Verfügbarkeit nicht geringer werden.
Die Säulen des Mainframe
Der Mainframe zeichnet sich durch drei wesentliche Eigenschaften aus.
- Die Skalierung. Beim Mainframe werden die Transaktionen mit einer scheinbar optimalen Verteilung auf die freien MIPS verteilt und parallelisiert.
- Der Durchsatz. Durch die Datenhaltung in VSAM-Dateien, besitzt der Mainframe einen optimalen I/O Durchsatz und effizienten Zugriff auf große Datenmengen.
- Die Ausfallsicherheit. Durch die Hardwarearchitektur ist die Ausfallsicherheit beim Mainframe gewahrt.
Insbesondere bei den Aspekten der Skalierung und der Durchsatz bedarf es bei zum Beispiel Java-Enterprise Anwendungen eines umfangreichen Erfahrungsschatz. Sind diese Möglichkeiten ausgereizt, gilt es an der Datenhaltung anzusetzen. Bei relationalen Datenbanken ist man früher oder später jedoch an den Grenzen der Machbarkeit angekommen. Ein reales Beispiel zeigt, mit welcher, beinahe fachlich einfachen Problemstellung man diesen Punkt erreicht. So scheitert man bereits beim Versuch, ein Versicherungsprodukt, mit tausenden Produktvarianten in Millionen abgeschlossenen Verträgen effizient und mit einer angemessenen Verfügbarkeit abzubilden. Die Antwortzeiten der Anfragen gehen, auch bei optimalen Indizes, in den nicht brauchbaren Bereich runter. Die Antwort auf dieses Problem sind NoSQL Datastores wie zum Beispiel Google Big-Table. Anhand der freien Implementierung, wie der von Apache HBASE, ist der nötige Vergleich zwischen Mainframe und den NOSQL-Konzepten leicht hergestellt.
NoSQL im Vergleich zum Mainframe
Im Ecosystem um HBASE finden sich unzählige andere Apache Hadoop-Projekte. Bezieht man diese in den Vergleich ein, werden die Beziehungen zum Mainframe direkt erkennbar. So basiert die Datenhaltung von Mahout auf dem Hadoop Dateisystem, kurz HDFS. HDFS ist ein verteiltes Dateisystem, welches durch die verteilte Auslegung resistent gegenüber Hardwarefehlern ist. Neben dieser Fehlertoleranz ist es explizit auf die Batchverarbeitung von Dateien bis zu mehreren Terabyte Dateigröße ausgelegt (dem sogenannten Streaming Data Access on Large Data Sets) [http://hadoop.apache.org/hdfs/docs/current/hdfs_design.html]. Gleiche Eigenschaften weisen Dateien im Mainframe-Umfeld auf.
Bei solch großen Dateien ist eine effiziente Zugriffsmethode zwingend. Diese ist im Mainframeumfeld zum Beispiel mit VSAM Dateien gegeben. Eine VSAM Datei muss jedoch nicht nur eine physische Datei repräsentieren. Diese logischen Eigenschaften entsprechen dem Konzept von Apache HBASE [http://hbase.apache.org/]. Die VSAM Katalog VVDS Schlüssel (VSAM Volume Data Set) sind ähnlich den RowKey des BigTable Datastore [ http://www.redbooks.ibm.com/abstracts/sg246105.html?Open]. Damit lassen sich leicht Alternativen für die Ausfallsicherheit und den Daten-Durchsatz (der Verfügbarkeit) im Umfeld der commodity Hardware finden.
Wie sieht es aber mit der Skalierung aus. Auch für die Skalierung findet sich auch angemessene Hilfen im NoSQL Umfeld. Anhand von Map-Reduce können komplexe Aufgaben, zum Beispiel auf Basis von HBase Daten, innerhalb kürzester Zeit verarbeitet werden [http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html]. Bei Map-Reduce werden die oft umfangreichen Berechnungen (Map-Operationen) möglichst parallel verarbeitet. Die Ergebnisse der Map-Operationen werden in diversen Zusammenführungen (Reduce-Operationen) zum endgültigen Ergebnis reduziert. [http://en.wikipedia.org/wiki/MapReduce]. Kennt man den Mainframe und Verarbeitungsstrategien unter zOS, lassen sich leicht parallelen erkennen.
Fazit
Es kann festgehalten werden, dass der Umstieg vom Mainframe zu commodity Hardware und Entwicklungsumgebung möglich ist. Aber nicht nur die technische Machbarkeit ist entscheidend. Entscheidend ist, dass das fachliche Know-How der bestehenden Belegschaft weiterhin genutzt werden kann. Es ist eine Frage der richtigen Migration, der Rentabilität und den strategischen Entscheidungen. Der Mainframe ist nicht tot, kann aber abgelöst werden.