Die Worte "verdichten" und "komprimieren" sind an sich Homonyme.
Aus der Sicht des FLAM®-Konzepts gibt es da einen kleinen Unterschied.
Kompressoren, die ihre Wurzeln im PC-Umfeld haben, konzentrieren sich auf Redundanzen und deren Häufigkeiten.
FLAM® hat seine Wurzeln im Umfeld der konservativen IT und die arbeitet mit Daten, die vordefinierte Formate und Strukturen im Satzaufbau haben (» Geschichte), die sich an Zugriffstechniken (index-/sequentiell) und Programmiersprachen (z.B. COBOL, RPG) ausrichten.
Da gibt es zunächst ein Data Management System (DMS) - einen Katalog. Und in diesem Katalog stehen Informationen darüber, wie die Daten formatiert sind und wie man sie in logischen Einheiten (Sätzen) lesen/schreiben kann. Diese Informationen sind jedem zugänglich.
Im Mittelpunkt steht der Datensatz und der hat einen Aufbau, den der Entwickler zusammen mit dem Anwender erarbeitet.
Das hat zur Folge, dass jede Applikation diesen Satz-/Feldaufbau beachten muss und kann.
Der Satz-/Feldaufbau führt zu Strukturen, die einen Overhead produzieren. Man definiert Felder in einer Größe, die sich am wahrscheinlichen Maximum orientieren muss. Unter Umständen gibt es entwicklungstechnische Parameter, die zu beachten sind, so dass die Sätze/Felder zwangsläufig aufgebläht werden (Auffüllungen).
In FLAM® gibt es algorithmische Techniken, die genau auf diese Erscheinungen ausgerichtet sind: die strukturorientierte Komprimierung.
Es wird versucht, den Overhead in den Daten (wie Auffüllungen) oder die Inhalte, die mit dem Feldaufbau und deren Position korrelieren, "vertikal" zu verarbeiten, weil das zu einer höheren Effizienz bzgl. Komprimierung einerseits und dem Verbrauch an CPU-Zeit/Arbeitsspeicher andererseits führt.
Die kontextuelle (horizontale) und auf Häufigkeiten ausgerichtete Komprimierung geht andere Wege.
Man könnte sagen: FLAM® "verdichtet" das in den Daten, das bzgl. Redundanz und Häufigkeit an sich banal erkennbar ist. Die Ergebnisse daraus und den "Rest" an Daten komprimiert FLAM®.
Das ist unsere Philosophie. Und darauf basierend arbeitet FLAM® in autarken Einheiten, die - trotz Komprimierung - einen direkten Zugriff in die FLAMFILE® ermöglichen. Das gilt auch für die verschlüsselten Komprimate.
Mitbewerber komprimieren fast ausschließlich ganze Dateien "am Stück" oder unterbrechen ihre Algorithmen, wenn sie zufallsbedingt an technische Grenzen stoßen. Man muss große Mengen dekomprimieren, um an die Daten zu kommen, die Gegenstand der Verarbeitung/Suche/Selektion sein sollen.
Eine strukturorientierte Analyse, die auf solche autarken Einheiten (Matrizen/Segmente) beschränkt ist und dennoch "straight forward" - also in einem Schritt - arbeiten soll, ist schwieriger zu konzipieren, wenn auch hier ein außergewöhnlicher Komprimierungseffekt mit vertretbaren Ressourcen das Ziel ist. Es geht u.a. darum, ein ausgeklügeltes Anlaufverfahren zu entwickeln.
Obwohl andere Kompressoren nicht strukturorientiert arbeiten, sind sie dennoch nicht in der Lage, zügig "straight forward" vorzugehen. Die Daten werden doppelt oder sogar dreifach - ggf. mit temporären Zwischendateien - verarbeitet, um zu einem sehr guten Ergebnis zu kommen. Das kostet mehr an CPU-Zeit und Arbeits-/Zwischenspeicher sowie längere Laufzeiten.
Eine Backup-Restart-Option, wie sie Entwickler von File Transfer Produkten wünschen, ist für FLAM® gar kein Problem. Für ein integrierbares Zugriffssystem sind Lösungen mit FLAM® unproblematisch. Deshalb gibt es FLAM® auf IBM Mainframe unter z/OS als Subsystem. FLAM® arbeitet dabei wie ein I/O-Treiber des Herstellers.
limes®: leistung im grenzbereich des machbaren.
limes®: efficiency at the limit of possibility.
© 1985 - 2011 limes datentechnik® gmbh
