Performante Unternehmensplanung

Teile und herrsche - mit In-Memory

Anstatt hochgerüsteter Datenbanken benötigen Planungs­anwendungen skalierbare In-Memory-Lösungen auf der Anwendungsseite. Ein neuer Ansatz ist ­gefragt.

Papiermännchen, Bildquelle: Thinkstock/Tetra images

Teile und herrsche - mit In-Memory

In-Memory-Computing wird gerne als „der Königsweg“ für die aktuellen Performanceherausforderungen im Zusammenhang mit Big-Data-Analysen gehandelt. Neue Datenbanktechnologien wie beispielsweise SAP Hana befeuern diese Gedanken und bestärken CIOs in ihren Erwartungen. Für analytisch ausgelegte Systeme – die hauptsächlich lesenden Zugriff benötigen – mögen sich die Erwartungen auch größtenteils erfüllen. Bei Planungsanwendungen, die vor allem schreibende Zugriffe auf die Datenbank verarbeiten müssen, wird der Königsweg jedoch schnell zur Buckelpiste. Denn viele gleichzeitig schreibende Anwender können sich auf einem zentralen In-Memory-Datenbankserver leicht gegenseitig blockieren: Die von den parallelen Eingaben ausgelösten Berechnungen konkurrieren bei einer In-Memory-Datenbank miteinander und blockieren schlimmstenfalls den gesamten Server. Ein Umstand, der gerade für die konzernweite Planung in verteilten Teams ein unkalkulierbares Risiko darstellt. Notwendig kann daher ein radikaler Gegenentwurf werden: nämlich eine skalierbare In-Memory-Funktion auf der Anwenderseite.

Zentralisierte Kalkulation

Um eine performante Unternehmensplanung auch für mehr als 1.000 gleichzeitig schreibende Benutzer zu gewährleisten, muss das Durchrechnen der Daten für jeden einzelnen Anwender beschleunigt werden. Der erste Schritt besteht darin, die Verteilung der Aufgaben auf die beteiligten Systemkomponenten zu überdenken. Bei In-Memory-Datenbanken ist der Datenbankserver nicht nur für die Bereitstellung der Daten zuständig, sondern er führt auch die nach Dateneingaben erforderlichen Rechenschritte (z.B. Verteilungen) aus. Diese Form der zentralisierten Kalkulationen in der Datenbank wird schnell zum Flaschenhals für die gesamte Planungsanwendung.

Für die Skalierbarkeit einer Planungsanwendung ­wäre es besser, wenn sich die Datenbank auf ihr Handwerk beschränkt und lediglich die zentrale Speicherung der Daten übernehmen würde. Die Durchführung von Berechnungen gehört hingegen zur Aufgabe der Planungsanwendung. Um den angestrebten Performancegewinn auch bei großen Anwenderzahlen zu erzielen, werden die Kalkulationen nach dem Prinzip „Teile und herrsche“ auf einzelne Planungssitzungen (z.B. die Planung für Deckungsbeiträge der Vertriebsregion Nordost) verteilt. Wie dies praktisch aussehen kann, zeigt das Konzept der „In-Memory-Berichtsstapel“: Ein Berichtsstapel enthält den individuellen Ausschnitt an Daten, der für die Bearbeitung einer konkreten Planungsaufgabe durch einen Anwender benötigt wird. Der Aufbau der Daten im Berichtsstapel orientiert sich dabei an den Planungsmasken der Anwendung. So kann der Stapel beispielsweise auch zusätzliche berechnete Werte (etwa Abweichungswerte) enthalten.

Separate Planungssitzungen

Berichtsstapel werden nicht auf dem Datenbankserver, sondern im Arbeitsspeicher (In-Memory) des Rechners angelegt, auf dem die jeweilige Planungssitzung läuft. Also entweder im Full-Client-Betrieb auf den einzelnen Anwenderrechnern oder im Thin-Client-Betrieb im Arbeitsspeichers des Web- oder Application-Servers. So kann temporär eine Vielzahl von Berichtsstapeln in einer Planungsanwendung koexistieren. Jeder Berichtsstapel kapselt den für die aktuelle Planungsaufgabe relevanten Datenbestand eines Anwenders so lange, bis dieser seine Planungssitzung beendet.

Die infolge der Eingabe von Plandaten durchzuführenden Berechnungen (z.B. Aggregationen) erfolgen innerhalb des In-Memory-Berichtsstapels. Durch die Verteilung der Kalkulationen in die separaten Planungssitzungen steigt die Rechengeschwindigkeit für jeden Nutzer. Neben dem Performancegewinn hat diese Methode den Vorteil, dass Werte nur noch gebündelt als inhaltlich konsistenter Datenbestand in die Datenbank geschrieben werden. Unvollständige Zwischenstände in der Datenbank, die von Dritten fehlinterpretiert werden, gehören der Vergangenheit an.

Im Unterschied zu In-Memory-Datenbanken können solche Berichtsstapel auch Planungsanwendungen beflügeln: Sie beschleunigen das Durchrechnen von Datenbeständen und ermöglichen einen reibungslosen und skalierbaren Multiuser-Betrieb.

 

In-Memory-­Anwendungsszenario

Der Mitarbeiter Franz Müller ist für die Planung der Deckungsbeiträge in der Vertriebsregion Nordost zuständig. Abgestimmt auf diese Planungsaufgabe ist sein In-Memory-Berichtsstapel definiert durch …

  •   die Kennzahlen des Deckungsbeitragsschemas in den Berichtszeilen,
  •   den erweiterten Aufriss in den Berichtsspalten bestehend aus Ist-Daten des Vorjahres, dem Forecast des aktuelles Jahres, dem Plan für das Folgejahr in der Variante Standard,
  •   berechnete Abweichungen absolut/prozentual,
  •   die Daten für alle in seinem Fall relevanten Kombinationen der Dimensionen Kunden und Vertriebsmitarbeiter der Vertriebs­region Nordost,
  •   alle Produkte inklusive zugehöriger Verdichtungsstufe.

Sobald Franz Müller seine Planungsmaske öffnet, werden alle für den Berichtsstapel benötigen Daten einmal gebündelt aus der Datenbank in den Arbeitsspeicher geladen und dort sofort aufbereitet. Seine Eingaben werden zunächst im Berichtsstapel abgelegt und davon ausgelöste Berechnungen direkt ausgeführt. Erst wenn Müller seine Sitzung beendet, ist die Datenbank wieder beteiligt. Dann werden die finalen Plandaten aus dem In-Memory-Berichtsstapel en bloc in die Datenbank zurückgeschrieben.

Quelle: Thinking Networks AG

 

Bildquelle: Thinkstock/Tetra images

©2019Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok