ANWENDUNG24. April 2015

Digitalisierung: Banken haben ein Datenbankproblem

Wavebreak-Media-Ltd/bigstock.com
Wavebreak-Media-Ltd/bigstock.com

Banken bieten ihren Kunden verstärkt neue Leistungen im Internet an. Dazu gehören beispielsweise die Auswertung der Kontoumsätze und die Einbindung externer Internetbezahldienste. Die Web-Applikationen müssen dadurch mehr Anfragen und Nutzer verarbeiten können. Die Gefahr ist hoch, dass Institute damit technisch an ihre Grenzen stoßen. Die alleinige Verwendung herkömmlicher relationaler Datenbanken reicht nicht mehr aus. Sie sind häufig zu langsam. Der Ausweg sind moderne NoSQL-Datenbanken als Ergänzung.

von Detlef Romanowski, Bereichsleiter Software Factory, und Tobias Döbber, Senior IT-Consultant, der PPI AG

Die Autoren

 

Detlef Romanowski ist Bereichsleiter Software-Factory beim Software- und Be­ratungs­un­ter­nehmen PPI.

 

Tobias Döbber ist Senior IT-Consultant und Themen­ver­ant­wort­licher für An­for­derungs­management beim Software- und Beratungsunternehmen PPI.

Speziell Filialbanken investieren gerade viel in mehr Service aus dem Internet, um mit den Direktbanken mitzuhalten. Dort gehören beispielsweise PDF-Kontoauszüge längst zum Standard. Klassische Institute haben erst vor kurzem elektronische Postfächer für ihre Kunden eingerichtet. Darüber hinaus steigt das Angebot an Analysemöglichkeiten für den Endkunden. Kontoinhaber können damit ihre Umsätze detailliert auswerten und zum Beispiel ihre Ausgaben besser planen.

Die vielen neuen Online-Dienste führen allerdings dazu, dass sich mehr Kunden länger in den Internet-Filialen der Banken aufhalten und die Dienste nutzen. Die Folge: Die Web-Anwendungen und angeschlossen Datenbanken müssen mehr Informationen verarbeiten und trotzdem genauso schnell und verfügbar sein. Andernfalls wechseln die Kunden schnell zum nächsten Wettbewerber.

Von Amazon und Co. lernen

Für die Lösung des Problems lohnt ein Blick auf Internetgrößen wie Google und Amazon. Der E-Commerce-Riese betreibt beispielsweise neben einer einheitlichen Datensammlung auch deren fortlaufende Auswertung. Amazon wertet Käuferinformationen so exakt aus, um sie für neue Dienstleistungen sowie im Cross Selling und Vertriebssteuerung gezielt einzusetzen. Die Herausforderung steigender Performance-Anforderungen lösen die Internetkonzerne schon seit mehreren Jahren über moderne Not-onlySQL-(NoSQL-) Datenbanken. Sie arbeiten schneller, und die IT-Systeme bleiben auch bei großen Zugriffszahlen verfügbar.

Komplettumstellung auf NoSQL funktioniert nicht

Banken, die davon lernen wollen, kommen also um eine solche Frischzellenkur für die Informationsspeicherung nicht herum. Eine naheliegende Lösung ist, dass die Banken einfach alle ihre relationalen gegen NoSQL-Datenbanken tauschen. Doch das funktioniert so nicht. Beide Typen haben ihre Berechtigung. Wenn es beispielsweise darum geht, exakte Kontostände zu liefern, bleiben relationale Datenbanken das Maß aller Dinge. Sie gewährleisten durch hohe Anforderungen an ihre Transaktionen stets einen konsistenten Zustand der Datenbank, vernachlässigen dadurch jedoch die Geschwindigkeit und die Verfügbarkeit der Datenbank bei hoher Auslastung oder im Falle von verteilten Systemen. Performance-Defizite durch mehr Rechenleistung zu kompensieren, reicht in diesem Fall allerdings auch nicht.

Für jede Aufgabe die passende Datenbank

Entscheider und IT-Projektleiter können sich also nicht mehr nur auf einen Datenbank-Typ stützen. Besser ist, NoSQL-Lösungen als Ergänzung zum bestehenden relationalen Datenbank-Managementsystem (DBMS) einzusetzen – zum Beispiel immer dann, wenn es auf Performance und weniger auf Konsistenz ankommt. Ziel sollte sein, zu jeder Aufgabenstellung die passende Speicherart für die zu verarbeitenden Informationen zu identifizieren. Informationen über einzelne Sessions der Kunden können zum Beispiel in einem „Key Value Store“ gespeichert werden, Postfachdokumente in einem gesonderten „Document Store“. Beziehungen zu Kunden sowie deren Beziehungen untereinander werden wiederum in einer Graph Database abgelegt. Kritische Transaktionsdaten wie Kontoumsätze werden dagegen weiterhin in einem relationalen DBMS verwaltet.

PPI
PPI

Drei-Stufenverfahren für effiziente Datenbankauswahl

Was passiert nun, wenn ein Projektverantwortlicher erkennt, dass ein bestimmter Datenbank-Typ unter dem System nicht mehr ausreicht? Ein mögliches Szenario ist, dass die Zugriffszeiten im Frontend auf ein für die Kundenbeziehung schädliches Niveau steigen. In diesem Fall sind horizontal skalierbare, besser verfügbarere Lösungen erforderlich. Projektleiter und IT-Architekten sind gefordert, schnell zu entscheiden, welches Werkzeug das richtige ist. Der folgende dreistufige Prozess hilft bei der Auswahl:

Schritt 1: Den richtigen Datenbank-Typ finden

Der Auswahlprozess beginnt mit einer Grobeinschätzung, wofür die Datenbank eingesetzt wird. Mittels der Problembeschreibung und einem Entscheidungsbaum lässt sich der passende Datenbank-Typ eingrenzen. Hierbei geht es um Fragen, ob absolute Transaktionssicherheit gewährleistet sein muss, oder ob für die Analyse von großen Datenmengen eine verteilte Abarbeitung der benötigten Auswertungen erforderlich ist. Im letzteren Fall sollten Projektleiter und IT-Architekt prüfen, ob ein Big Data Framework nicht sogar besser geeignet ist.

 

Datenbankauswahl
PPI


Schritt 2: Die passende Ausrichtung bestimmen

Im zweiten Schritt werden die nicht-funktionalen Anforderungen der Datenbanktypen überprüft. Die Projektleiter und IT-Architekten müssen in dieser Phase unter anderem die benötigte Fehlertoleranz im Falle von verteilten Systemen, Datenkonsistenz, den Grad der Verfügbarkeit der Daten und die Kapazitätsverteilung klären, um sich den passenden Datenbanksystem zu nähern.

Schritt 3: Auswahl eines geeigneten Datenbank-Produkts

Nachdem die Schritte eins und zwei durchlaufen sind, lässt sich schnell ein passendes Datenbank-Produkt ableiten. Bekannte relationale Datenbanken sind zum Beispiel MySQL- und Oracle- und IBM-Lösungen. Cassandra ist ein gängiges Wide-Column-Store-Angebot und MongoDB ein Produkt für die Ablage von Dokumenten. Als Key Value Store eignet sich Redis. Je nach gewünschter Aufgabe und Ausrichtung gibt es allerdings zahlreiche weitere Anbieter.

Projektleiter und IT-Architekten können anhand des hier beschriebenen dreistufigen Auswahlverfahrens effizient entscheiden, ob für eine digitale Lösung eine NoSQL-Datenbank verwendet werden sollte und welches Datenbank-Produkt in Frage kommt. Bei der Auswahl der passenden Datenbank spielen allerdings nicht nur das Einsatzgebiet und die technischen Anforderungen eine Rolle. Projektmanagement-Aufgaben wie Risikomanagement, Ressourcenplanung, Knowledge- und Know-how-Management sind ebenso wichtig. Die Projektverantwortlichen sollten diese Kriterien in Form geeigneter Scoring-Methoden mit in ihren Entscheidungsprozess einfließen lassen.aj

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert