Anbieter zum Thema
Eine Kenntnis der verschiedenen Datenwerte ermöglicht eine mindestens 10-mal stärkere Komprimierung als bei zeilenorientierten Datenbanken. Benötigt eine herkömmliche relationale Datenbank 100 Gigabyte Speicherplatz, nimmt die eigens entwickelte Relex-Datenbank nur zehn Gigabyte Speicherplatz ein.
Relex‘ innere Architektur besteht aus mehreren Threads, wodurch diverse zeitintensive Arbeitsvorgänge parallel laufen können. Je mehr Threads parallel laufen, desto schneller werden die Daten wie Auswertungsmöglichkeiten der Suchanfragen, Ladezeiten oder Kalkulationen verarbeitet.
In-Memory-Technologie
Die In-Memory-Technik erlaubt dank der starken Komprimierung, die Daten im Arbeitsspeicher abzulegen. Suchanfragen der Datenbank werden im RAM bearbeitet. Das vermeidet zeitintensives Hin- und Herschieben der Daten zwischen ERP und Festplatte, was erneut zu Leistungserhöhung führt und Zeit spart, weil der gesamte Lese-Schreib-Prozess entfällt. In-Memory-Computing mithilfe von Relex ist fähig, Informationen für 50 Millionen SKUs (Stock Keeping Units, Bestandseinheiten/Artikelnummern) in zwei Stunden zu verarbeiten. Prognosen können theoretisch für mehrere Jahre vorgenommen werden, aber durch ein sich ständig änderndes Sortiment ist es sinnvoll, nur bis zu einem halben Jahr im Voraus zu planen.
Zum Beispiel können Disponenten Möglichkeiten für kommende Kampagnen durch das Durchspielen von Hypothesen für alle möglichen Permutationen analysieren. Historische Daten des Kampagnenprodukts oder, falls es diese nicht gibt, Daten von vergleichbaren Produkten, ermöglichen Prognosen für jede Filiale, jeden Ort, jeden Rabatt, saisonale Kombination und weitere Variationen. Die in Sekundenschnelle generierten Ergebnisse gewähren Einblicke in Bereiche wie den während Kampagnen erzielten Profit oder die laufende Umsatzsteigerung. So lassen sich potenzielle Engpässe und Bedarfsspitzen rechtzeitig kennzeichnen, sodass Unternehmen reagieren können.
Die SCM-Software von Relex besitzt eine integrierte, speziell angefertigte Datenbank. Das ist bisher unüblich. Datenbank und Anwendung gelten meist als getrennte Lösungen, die oft von unterschiedlichen Anbietern stammen. Die Datenbank dient als Server, an die die Anwendungssoftware gekoppelt wird. Das verkompliziert jedoch die Kommunikation zwischen Anwendung und Datenbank und führt zu Anwendungsgrenzen von Client-Server-Modellen. Um die benötigten Antworten zu erhalten, müssen präzise Anfragen gestellt werden. Die Antwort besteht oft in kurzen Zusammenfassungen einer begrenzten Anzahl von Dateien oder nur Kopien dieser – eine direkte Kommunikation ist nicht ohne weiteres möglich.
SQL-Erweiterungen
Die meisten Datenbankserver erlauben eine Umgehung der Beschränkung der SQL-Sprache über Erweiterungen. Diese sind häufig in anbieterspezifischer Sprache geschrieben, sodass eigentlich von der Anwendung verarbeitete Daten nun über die Datenbank laufen. Damit findet die Verarbeitung näher an der Datenquelle statt und das Hin- und Herschieben von Daten zwischen Datenbank und Anwendung wird minimiert. Aber es gibt Einschränkungen: Die nutzerspezifische Sprache ist kein adäquates Pendant zur vollwertigen Programmiersprache und schränkt Datenzugriffsmuster ein.
Relex erlaubt einen direkten Zugriff auf die Datenbank und das Arbeiten mit ihr. Das vermeidet das Hin- und Herschicken von Daten und verbessert zusätzlich die Performance. Datenbank und Anwendung sind eine einzelne, nahtlos ineinander übergehende Software. Darum laufen Prozesse auf niedrigem Kapazitätslevel und häufige Anfragen werden bei der Datenspeicherung direkt einkalkuliert.
Eine individuelle Anpassung macht Aufbau und Entwicklung der Software anspruchsvoll und zeitintensiv, dafür bietet die Lösung eine überdurchschnittlich hohe Leistung:
- Ca. fünf Milliarden Prognosen pro Stunde.
- Ca. eine Milliarde Transaktionen pro Stunde hochladen
- Eine Million Produkte in 1 Sekunde nach Lieferbarkeit sortieren
- Berechnung von 50 Mio. SKUs in zwei Stunden
Dieser Beitrag erschien zuerst auf unserem Partnerportal BigData-Insider. Weitere Informationen zum Thema finden Sie in unsere Grundlagenbeitrag „Big Data in der Intralogistik“
(ID:44459464)