Einsatz von NoSQL in SOA-basierten ERP-Systemen

21.11.2012: Klassische SQL- und Client-/Server-Infrastruktur – ein Auslaufmodell?

Der Einsatz der Datenbanksprache SQL hat die Bearbeitung von Datenbeständen grundlegend verändert und sich über viele Jahre zum geltenden Standard entwickelt – bis heute. Mit stetig wachsenden Datenbeständen in heute nahezu jedem Unternehmen und uneinheitlichen Datenstrukturen stößt die Structured Query Language jedoch zunehmend an ihre Leistungsgrenzen. Zwar versuchen immer leistungsfähigere Hardwarekomponenten die abnehmende Abfragegeschwindigkeit zu kompensieren, doch das eigentliche strukturelle Problem in Zeiten der Massedatenverarbeitung lässt sich damit nicht lösen. Die Zukunft sieht Ditmar Tybussek, ERP-Entwicklungsleiter des Business Software Spezialisten Allgeier, in NoSQL (Not only SQL) und einer konsequent SOA-basierten Anwendungsarchitektur.

Wer kennt das nicht: Die Software mit all den wichtigen Unternehmensdaten wird gestartet: warten. Wir suchen eine Rechnung im System: warten - unerträgliche Sekunden lang. Die Lösung: schnellere Hardware muss her! Mehr Memory auf dem Arbeitsplatz, mehr Rechenleistung, schnelleres Netzwerk, schnellerer Switch und mehr Server, die die Last besser verteilen. Die Client-/Server-Architektur wurde einst aus diesem Grunde entwickelt, um die Last des Servers auf die Clients zu verlagern. Der Server verwaltet dann nur noch die Datenbankzugriffe, enthält aber nicht mehr die Anwendungslogik oder die Präsentationsebene (Multitier). Diese Maßnahmen bringen dann auch zunächst eine spürbare Verbesserung, so dass kurzfristig die Gesamtgeschwindigkeit des Systems steigt, bis dann noch mehr Daten im System vorhanden sind. Dann beginnt das Spiel von vorne. Dies geht nun so lange, bis die neue Hardware dies nicht mehr schafft. Nun wird virtualisiert, damit nicht mehr die Clients aufgerüstet werden müssen, sondern nur noch der/die Server. Wenn das nichts mehr hilft, dann werden die Daten gleich ins Memory geladen. Wieder ist etwas Zeit gewonnen, doch dann ist das Ende der Fahnenstange erreicht. Die Geschwindigkeit der Datenbearbeitung ist dann nicht mehr zu erhalten. Dabei sprechen wir hier nur von einfacher kaufmännischer ERP-Software und nicht über Business Intelligence Anwendungen, die bereits aus Performance-Gründen in ein extra Datawarehouse-System ausgelagert wurden.

Warum sind Zugriffe im ERP-System nicht so schnell im Internet möglich?

Jedes Produkt und jede Technologie unterliegt einem Lebenszyklus. Viele ERP-Anbieter haben bereits vor einigen Jahren die Grenzen der klassischen SQL- und Client-/Server-Technologie zum Anlass genommen, die Architektur ihrer Anwendungssysteme von Grund auf zu erneuern und den Anforderungen des Marktes anzupassen. Anwender fragen sich heute zurecht, warum etwa Milliarden Anwender gleichzeitig auf Milliarden von Internetseiten innerhalb von Sekundenbruchteilen zugreifen können, während man im ERP-System so langsame Zugriffszeiten hat, wo doch im Intranet nur ein paar Hundert Anwender aktiv sind? Warum ist das Internet 7/24/365 verfügbar, während die ERP-Software nachts gestoppt werden muss, um eine Sicherung zu machen? Die Antwort auf die Frage ist: schnell und unabhängig wird man nur durch NoSQL und eine im Kern SOA-basierte Anwendung.

Wo liegt also der besondere Vorteil von NoSQL gegenüber SQL und relationalen Datenbanken?

SQL ist und bleibt das beste Mittel, um strukturierte Dateien zu lesen und zu bearbeiten. Aber: was ist, wenn wir eine immer größere Masse von unstrukturierten Dateien haben? Datenbankspezialisten müssen etwa 40% ihrer Entwicklungszeit dafür aufwenden, Objekte in Tabellen zu pressen und diese mit Hilfe von sogenannten Joints wieder zeitaufwendig zu verknüpfen. Naheliegender wäre, die Objekte so zu speichern, wie sie sind. Die objektorientierte Entwicklung beispielsweise speichert die Objekte 1:1 und liest diese entsprechend.

Bei der Erfindung von SQL hat man nur an strukturierte Daten in Tabellen gedacht und nicht an Bitmap Index Dateien, die um das 1.000-fache schneller arbeiten. Dies erfordert jedoch NoSQL, was entscheidende Vorteile in der Zugriffsgeschwindigkeit und den Einsatzmöglichkeiten hat. Bei Massedatenverarbeitung und Suchstrategien etwa ist NoSQL nicht zu schlagen. Denn statt bei Abfragen mühselig eine Indexdatei nach bestimmten Werten zu durchsuchen, die mit zunehmender Datenmenge immer mehr Zeit in Anspruch nimmt, steht der gesamte Index in einem gesonderten, leicht adressierbaren Objekt, das bei häufiger Abfrage auch direkt in den Memory geladen werden kann. Festgelegte Tabellenschemata wie bei relationalen Datenbanken werden so nicht benötigt. So hat Allgeier etwa in seinem ERP-System cierp3 bereits bei der Entwicklung gleich eine zukunftsweisende Datenbankarchitektur im Kern zugrunde gelegt – NoSQL-Technik kombiniert mit In-Memory, was unterm Strich einen Geschwindigkeitszuwachs von etwa Faktor 1.000 gegenüber proprietären Datenbanksystemen leistet.

Client-/Server-Architektur für heutige Anforderungen nicht geeignet

Anpassungen in Client-/Server-basierten Anwendungen sind immer mit immensem Aufwand verbunden, die sich der IT-Dienstleister von den langjährigen Kunden gut bezahlen lässt. Nötige Änderungen müssen zunächst aufwändig programmiert, kompiliert, übertragen und aktiviert werden. Für komplexe Grafikanwendungen wie Bildverarbeitung oder Konstruktionszeichnungen mag dies noch vertretbar sein, keinesfalls aber für die geschäftskritische, kaufmännische Unternehmenssoftware, die immer neue Abläufe abbilden muss.

Für zukünftige Anwendungen stellt der Browser den idealen Universal-Client dar. Dabei wird ein Text-Stream vom Server an den Browser gesendet und der Browser setzt die sogenannten HTML-Tags in schöne bunte Anwendungen um, die allseits bekannte Browseroberfläche. Statt also mühevoll Programme zu erstellen, die die Oberflächen gestalten, wird die gesamte Sichtweise der Anwendung mit den Inhalten im Browser angezeigt. Andere Anwendungen sind damit nicht mehr erforderlich und jede so geschriebene Anwendung ist von überall aus verfügbar und wenn nötig auch auf einem Smartphone zu bedienen, unabhängig vom Ort oder IT-Infrastruktur. Das gesamte Programm gehorcht somit einer völlig anderen Logik. Statt eines Programms, das gestartet wird und eben so starr abläuft, sendet der Browser über einen Link, Buttons oder AJAX Event eine Anforderung an den Server, der einen Request wie einen unabhängigen Service betrachtet. Der Internet Information Server (IIS oder Apache) reicht die Link-Informationen durch und sendet die fertige HTML-Seite an den Browser. Gibt es eine Änderung in der Anwendung, muss der Browser nicht neu installiert und nicht neu gestartet werden. Der Browser zeigt einfach die neue Anwendung.

Alleine die Funktionen wie Multikulturalität, barrierefreie Bearbeitung, Zugriffssicherheit und nicht zuletzt extremes Customizing zwingt doch dazu, jede Seite individuell und dynamisch aufzubauen. Diese Eigenschaft erfüllen jedoch nur Metadaten, eine Codierung ist für diese Zwecke heute nicht mehr ausreichend.

Diese Webseite nutzt Cookies. Sie können die Voraussetzungen für die Speicherung bzw. den Zugang zu Cookies in Ihrem Browser festlegen.