DE112008002820T5

DE112008002820T5 - Gemeinsame Kompression

Info

Publication number: DE112008002820T5
Application number: DE112008002820T
Authority: DE
Inventors: Krishnamurthy Palo Alto Viswanathan; Ram Palo Alto Swaminathan; Mustafa Palo Alto Uysal
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2007-10-31
Filing date: 2008-10-30
Publication date: 2010-12-09
Also published as: US20090112900A1; WO2009059060A2; CN101842785A; WO2009059060A3

Abstract

Verfahren zur gemeinsamen Kompression, Folgendes umfassend:
Empfangen (41) einer Sammlung von Dateien (61–66), wobei individuelle Exemplare der Dateien (61–66) eine Menge geordneter Datenelemente (56–58) umfassen und wobei individuelle Exemplare der Datenelemente (56–58) verschiedene Werte in verschiedenen Exemplaren der Dateien (61–66) haben, wobei jedoch die Menge geordneter Datenelemente (56–58) über die Dateien (61–66) hinweg gemeinsam ist;
Aufteilen (44) der Datenelemente (56–58) in einen identifizierten Satz von Töpfen, basierend auf Statistiken für die Werte der Datenelemente (56–58) quer durch die Dateisammlung (61–66); und
Komprimieren (47) einer empfangene Datei (131), basierend auf den Töpfen der Datenelemente (56–58).

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft Systeme, Verfahren und Techniken zur Kompression von Dateien und sie ist beispielsweise bei der Aufgabenstellung einer Kompression mehrerer ähnlicher Dateien anwendbar.
HINTERGRUND
Es wird die Aufgabenstellung der verlustfreien Kompression einer Gruppe von Dateien betrachtet, die einander ähnlich sind. Diese Aufgabenstellung ergibt sich für gewöhnlich durch sehr große Datenmengen, die in Dokumentenarchiven, Bildbibliotheken, festplattenbasierten Backupvorrichtungen und Fotosammlungen gesammelt werden. Die meisten herkömmlichen Kompressionstechniken behandeln jede Datei als eine getrennte Einheit und sie nutzen die Redundanz innerhalb einer Datei, um den Platz zu verringern, der zum Speichern der Datei erforderlich ist. Dieser Ansatz lässt jedoch die Redundanz über Dateigrenzen hinweg unberücksichtigt.
Die Aufgabenstellung der Kompression einer Datei relativ zu einer anderen durch das Codieren der Veränderungen, die die eine in die andere überführen, hat in der Literatur zur Datenkompression große Aufmerksamkeit erfahren. Diese Aufgabenstellung wird auch als differenzielle Kompression bezeichnet. Für die Anwendung oder Erweiterung dieser Technik auf die Kompression einer großen Menge von Dateien ist jedoch nicht bekannt, dass dies im Stand der Technik vorgeschlagen wurde und eine solche Erweiterung ist nicht trivial. Wahrscheinlich wegen dieser Schwierigkeiten haben die herkömmlichen Techniken zur Kompression mehrerer ähnlicher Dateien andere Ansätze verfolgt.
Beispielsweise basiert ein solcher Ansatz auf String-Matching. Die meisten der Lösungen, die in diese Kategorie fallen (beispielsweise M. Factor und D. Sheinwald, „Compression in the presence of shared dara", Information Sciences, 135: 29–41, 2001) können als eine Variante einer Vorgehensweise angesehen werden, die alle zu komprimierenden Dateien in einer gigantischen Zeichenkette aneinander hängt und diese Zeichenkette unter Verwendung der LZ77 Kompression komprimiert. Der Umfang der mit solchen Techniken erreichten Kompression ist typischerweise dürftig, wenn die Puffergröße festgelegt ist; andererseits wird die Technik, wenn die Puffergröße nicht festgelegt ist, im Allgemeinen komplex in der Berechnung und sie läuft in Probleme, die mit Speicherüberläufen verbunden sind.
Ein weiterer Ansatz, der im Allgemeinen als „Chunking” bezeichnet wird, zergliedert Dateien in Abschnitte variabler Länge, und er komprimiert, indem er eine einzige Instanz jedes Abschnitts zusammen mit einem Hasheintrag (Codewort), das zum Nachschlagen des Abschnitts verwendet wird, speichert (beispielsweise K. Eshghi, M. Lillibridge, L. Wilcock, G. Belrose, und R. Hawkes, "Jumbo Store: Providing efficient incremental upload and versioning for a utility rendering service", Proceedings of the 5th USENIX Conference an File and Storage Technologies (FAST'07), Seiten 123–138, San Jose, Kalifornien, Februar 2007). Dieser Ansatz ist typischerweise schneller als das String-Matching. Falls häufig neue Abschnitte auftreten, können jedoch häufige Festplattenzugriffe erforderlich sein. Darüber hinaus wird die durch solche Ansätze erreichte Kompressionsrate, selbst für einfache Modelle der Dateiähnlichkeit, wahrscheinlich nicht optimal sein.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung befasst sich mit dieser Aufgabenstellung, indem sie, unter anderen Ansätzen, über Dateigrenzen hinweg gemeinsame Datenelemente in einen identifizierten Satz von Töpfen aufteilt, und dies basierend auf Statistiken für die Werte der Datenelemente quer durch die Dateien der Sammlung, wobei eine ankommende Datei basierend auf den identifizierten Töpfen der Datenelemente komprimiert wird.
In einer Eigenschaft bezieht sich die Erfindung somit auf die gemeinsame Kompression, bei der eine Sammlung von Dateien empfangen wird, wobei individuelle Exemplare der Dateien eine Menge geordneter Datenelemente (beispielsweise Bitpositionen) umfassen und wobei individuelle Exemplare der Datenelemente verschiedene Werte in verschiedenen Exemplaren der Dateien haben, wobei jedoch die Menge geordneter Datenelemente quer durch die Dateien gemeinsam ist. Die Datenelemente werden in einen identifizierten Satz von Töpfen aufgeteilt, basierend auf Statistiken für die Werte der Datenelemente quer durch die Dateien der Sammlung, und eine empfangene Datei wird, basierend auf den Töpfen der Datenelemente, komprimiert.
Aufgrund des vorangehenden Konzepts ist es oftmals möglich, eine vollständige Sammlung ähnlicher Dateien effizient zu komprimieren. In bestimmten typischen Ausführungsformen werden die Töpfe dazu verwendet, eine Quelldateischätzung zu erstellen, die dann dazu verwendet wird, die einzelnen Dateien differenziell zu komprimieren. Andere Ausführungsformen erzeugen Ströme von Datenwerten, basierend auf der Aufteilung der Töpfe, und sie komprimieren dann diese Ströme getrennt, ohne den Zwischenschritt einer Quelldateischätzung.
In einer weiteren Eigenschaft bezieht sich die Erfindung auf die gemeinsame Kompression, bei der eine Sammlung von Dateien empfangen wird, wobei individuelle Exemplare der Dateien einen Satz geordneter Datenelemente umfassen und wobei individuelle Exemplare der Datenelemente verschiedene Werte in verschiedenen Exemplaren der Dateien haben, wobei jedoch der Satz geordneter Datenelemente über die Dateien hinweg gemeinsam ist. Es wird eine Quelldateischätzung erstellt, basierend auf Statistiken für die Werte der Datenelemente über die Sammlung von Dateien hinweg und eine empfangene Datei wird relativ zur Quelldateischätzung komprimiert.
Die vorangehende Zusammenfassung ist lediglich dafür vorgesehen, eine kurze Beschreibung bestimmter Eigenschaften der Erfindung zu geben. Ein vollständigeres Verständnis der Erfindung erhält man mit Bezug auf die Ansprüche und die nachfolgende detaillierte Beschreibung der bevorzugten Ausführungsformen in Verbindung mit der beigefügten Zeichnung.
KURZE BESCHREIBUNG DER ZEICHNUNG
In der nachfolgenden Offenbarung wird die Erfindung mit Bezug auf die beigefügte Zeichnung beschrieben. Es versteht sich jedoch, dass die Figuren lediglich bestimmte typische und/oder exemplarische Ausführungsformen und Eigenschaften der vorliegenden Erfindung darstellen und dass sie in keiner Weise den Anwendungsbereich der Erfindung einschränken sollen. Nachfolgend steht eine kurze Beschreibung jeder der beigefügten Figuren.
1 ist ein Blockdiagramm, das das Konzept mehrerer ähnlicher Dateien veranschaulicht, die von einer einzigen Quelldatei abgeleitet wurden.
2 ist ein Flussdiagramm, das einen allgemeinen Ansatz für die Kompression von Dateien gemäß bestimmter bevorzugter Ausführungsformen der Erfindung veranschaulicht.
3 veranschaulicht eine Sammlung von Dateien, die einen gemeinsamen Satz von Datenelementen enthalten.
4 ist ein Flussdiagramm, das eine Übersicht eines Kompressionsverfahrens veranschaulicht, das eine Quelldateischätzung verwendet.
5 ist ein Blockdiagramm, das ein System zur Kompression und Dekompression von Dateien veranschaulicht, das auf einer Quelldateischätzung basiert.
6 ist ein Flussdiagramm, das ein Verfahren zum Erstellen einer Quelldateischätzung veranschaulicht.
7 veranschaulicht einen De-Bruijn-Graphen für Folgen von zwei-bit Zeichenfolgen-Kontexten.
8 ist ein Flussdiagramm, das einen ersten Ansatz zur Kompression einer Datei ohne das Erstellen einer Quelldateischätzung veranschaulicht.
9 veranschaulicht das Aufteilen einer ursprünglichen Datei in Datenströme für eine getrennte Kompression.
10 ist ein Flussdiagramm, das einen zweiten Ansatz zur Kompression einer Datei ohne das Erstellen einer Quelldateischätzung veranschaulicht.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM(EN)
Die vorliegende Erfindung betrifft, neben anderen Dingen, Techniken zur Unterstützung der Kompression mehrerer ähnlicher Dateien. In vielen Fällen können, wie in 1 dargestellt, die zu komprimierenden Dateien 11–14 so aufgefasst werden, dass sie als Modifikationen oder Ableitungen irgendeiner zugrundeliegenden Quelldatei 15 erzeugt sind. Dies bedeutet, dass ausgehend von einer Quelldatei 15 jede der individuellen Dateien 11–14 erzeugt werden kann, indem geeignete Veränderungen an der Quelldatei 15 vorgenommen werden, wobei diese Veränderungen im Allgemeinen für die verschiedenen Dateien 11–14 sowohl qualitativ als auch quantitativ verschieden sind.
Tatsächlich ist eine solche Konzeptualisierung oftmals möglich, selbst dort, wo einige oder alle der Dateien 11–14 nicht aus einer gemeinsamen Quelldatei 15 abgeleitet wurden, vorausgesetzt, die Dateien 11–14 sind zueinander hinreichend ähnlich. Eine solche Ähnlichkeit kann beispielsweise auftreten, wenn die Dateien 11–14 auf ähnliche Weise erzeugt wurden, beispielsweise wenn mehrere verschiedene Fotografien des Eiffelturms, von denen jede als Bitmapbild repräsentiert ist, von in etwa demselben Standpunkt, jedoch unter Verwendung verschiedener Kameras und/oder Kameraeinstellungen und/oder unter etwas verschiedenen Beleuchtungsbedingungen aufgenommen wurden.
Wie nachfolgend noch genauer besprochen wird, versuchen bestimmte Ausführungsformen der Erfindung explizit eine Quelldateischätzung zu erstellen und anschließend eine oder mehrere Dateien relativ zu dieser Quelldatei zu komprimieren. Andere Ausführungsformen setzen keine solche Konstruktion ein. In jedem Fall komprimieren die bevorzugten Ausführungsformen der Erfindung Dateien, indem sie gemeinsame Datenelemente (wie etwa Bitpositionen) über eine Sammlung von Dateien hinweg aufteilen und diese Partitionen, entweder direkt oder indirekt, verwenden, um Dateidaten in einer Weise so zu organisieren und/oder zu verarbeiten, dass die Kompression unterstützt wird.
2 ist ein Flussdiagramm, das einen Vorgang 40 zur Kompression von Dateien gemäß bestimmter bevorzugter Ausführungsformen der Erfindung veranschaulicht. Jede der Phasen im Vorgang 40 wird vorzugsweise in vorgegebener Weise ausgeführt, so dass der gesamte Vorgang 40 von einem Computerprozessor durchgeführt werden kann, der maschinenlesbare Verarbeitungsschritte ausführt, oder auf einem der anderen in diesem Dokument beschriebenen Wege.
Zu Anfang wird in Phase 41 eine Sammlung von Dateien (die beispielsweise m verschiedene Dateien umfasst) eingegeben. Vorzugsweise ist für diese Dateien bekannt, dass sie zueinander ähnlich sind, entweder durch die Weise, in der sie zusammengetragen wurden (beispielsweise verschiedene Versionen eines in Bearbeitung befindlichen Dokuments), oder weil sie aus einer größeren Dateisammlung nach Ähnlichkeit ausgesucht wurden.
In Phase 42 werden alle eventuell gewünschten Vorverarbeitungen ausgeführt, mit dem bevorzugten Ziel sicherzustellen, dass der Satz Datenelemente in jeder Datei dem Satz Datenelemente in jeder der anderen Dateien entspricht. Es ist zu bemerken, dass in einigen Fällen keine solche Vorverarbeitung ausgeführt wird (beispielsweise wenn alle Dateien hochstrukturiert sind, mit einem gemeinsamen Satz an Feldern, die in exakt derselben Reihenfolge angeordnet sind). In einem speziellen solchen Beispiel sind die empfangenen Dateien die Microsoft Windows^TM Registries für alle Personal Computer (PCs) im Computernetzwerk einer Organisation. Hier kann nicht nur angenommen werden, dass die Felder identisch sind, sonder auch, dass die Datenwerte innerhalb dieser Felder im Allgemeinen erhebliche Ähnlichkeiten haben werden, insbesondere dann, wenn die Organisation für alle ihre Computer, oder für eine große Anzahl von ihnen, gemeinsame Einstellungen festgelegt hat.
In anderen Fällen wird ein gewisser Umfang an Vorverarbeitung wünschenswert sein. Im vielleicht allgemeinsten Fall sind die Datenelemente beispielsweise einfach die Bitpositionen innerhalb der Dateien (beispielsweise sequenziell angeordnet und von 1 bis n nummeriert). In diesem Fall können alle Dateien, die eine Länge von weniger als n Bit haben, mit Nullen aufgefüllt werden, so dass alle Dateien im Satz dieselbe Länge haben (das heißt eine Länge von n Bit). In bestimmten Ausführungsformen wird ein solches Auffüllen einheitlich auf den Anfang oder das Ende jeder Datei angewendet, die anfänglich kürzer als n Bit ist. In anderen Ausführungsformen wird ein solches Auffüllen jedoch in der Mitte von Dateien angewendet, beispielsweise dort, wo die Dateien eine natürliche Segmentierung haben (beispielsweise Seiten in einer PDF- oder PowerPoint-Dokumentendatei), oder wenn sie als Teil der Vorverarbeitung segmentiert werden (beispielsweise basierend auf identifizierten Ähnlichkeitsmarkern); in diesen Fällen kann das Auffüllen beispielsweise dort angewendet werden, wo es geeignet ist, die Längen der einzelnen Segmente anzugleichen.
Falls für eine Datei eine Vorverarbeitung ausgeführt wurde, werden die Details einer solchen Verarbeitung vorzugsweise in Verbindung mit der Datei zur nachfolgenden Umkehrung bei der Dekompression gespeichert.
In jedem Fall kann die sich ergebende Sammlung von Dateien vorzugsweise wie in 3 dargestellt abgebildet werden, wobei jede Zeile einer anderen Datei entspricht (beispielsweise den Dateien 61–66) und jede Spalte einem anderen Datenelement entspricht (beispielsweise den Datenelementen 56–58). Dies bedeutet, dass jede Datei vorzugsweise denselben Satz von Datenelementen hat, die in exakt derselben Reihenfolge angeordnet sind, auch wenn die Werte für diese Datenelemente sich typischerweise über die Dateien hinweg etwas unterscheiden. Noch bevorzugter hat keine der Dateien irgendein Datenelement, das (an derselben Position) nicht auch in jeder der anderen Dateien auftritt, so dass jeder Wert innerhalb der Dateisammlung eindeutig angegeben werden kann, indem eine Datei-Kennzeichnung und eine Datenelement-Kennzeichnung verwendet werden.
Obwohl in 3 nur eine Handvoll Dateien und Datenelemente dargestellt sind, geschieht dies nur zum Zwecke der vereinfachten Veranschaulichung; in der Praxis treten oftmals Zig, Hunderte oder sogar mehr Dateien und Hunderte, Tausende, Zehntausende oder sogar mehr Datenelemente auf. Jede Datei kann, obwohl sie als eine eindimensionale Folge von Datenelementen dargestellt ist, stattdessen ebenfalls, in Abhängigkeit von der Art der Dateien, gegebenenfalls besser als ein zweidimensionales oder sogar höherdimensionales Array von Datenelementen dargestellt werden. Dieses Dokument bezieht sich auf jedes Datenelement als mit einem „Wert” behaftet, der, beispielsweise und in Abhängigkeit von der Art des Datenelements, ein Binärwert (bei dem die Datenelemente verschiedenen Bitpositionen entsprechen), ein Integer, eine reelle Zahl, ein Vektor von Unterwerten oder jede andere Art von Wert sein kann.
Zurück mit Bezug auf 2 werden in Phase 44 die Datenelemente in Töpfe aufgeteilt, basierend auf Statistiken der Datenelementwerte über die Dateisammlung hinweg. In einer Ausführungsform beispielsweise, in der jedes Datenelement einer einzelnen Bitposition entspricht, wird basierend auf dem Bruchteil von Dateien, die an dieser Bitposition einen speziellen Wert haben (beispielsweise den Wert „1”), jede solche Bitposition einem Topf zugewiesen. Unter der Annahme, dass es acht Töpfe gibt, wird in diesem Beispiel genauer eine Bitposition dem ersten Topf zugewiesen, wenn der Bruchteil der Dateien mit einem Wert „1” an dieser Bitposition weniger als 0,125 ist, dem zweiten Topf zugewiesen, wenn der Bruchteil größer oder gleich 0,125 aber kleiner als 0,25 ist, dem dritten Topf zugewiesen, wenn der Bruchteil größer oder gleich 0,25 aber kleiner als 0,375 ist und so weiter. Es ist zu bemerken, dass in dieser Ausführungsform über die Dateien hinweg (beispielsweise quer durch alle Dateien) eine einzige statistische Metrik (beispielsweise ein repräsentativer Wert, wie etwa der Mittelwert oder der Median) verwendet wird, um ein Datenelement einem Topf zuzuweisen, und diese einzige statistische Metrik basiert allein auf dem Wert dieses Datenelements selbst quer durch die Dateien hindurch (ohne Bezug auf die Werte irgendwelcher anderen Datenelemente).
In anderen Ausführungsformen sind die Zuweisungen kontextabhängig, beispielsweise mit einer Zuweisung eines bestimmten Datenelements, die auf den Werten in der Nähe liegender Datenelemente wie auch auf den Werten des bestimmten Datenelements selbst basiert. Beispielsweise in einer bestimmten solchen Ausführungsform wird der Satz von Bitpositionen {1, 2, ..., n} wie folgt in Töpfe aufgeteilt. Für jede Bitposition 1 ≤ j ≤ n und für jede k-Bit Zeichenfolge c ∊ {0,1}^k wird eine Bestimmung von n_j(c) durchgeführt, dem Bruchteil von Dateien, bei denen „1” in der Bitposition j auftritt, wenn deren Kontext, in dieser Ausführungsform die k vorangehenden Bit, gleich c ist. Die Menge {1, 2, ..., n} von Bitpositionen wird dann in höchstens l Töpfe B₁, B₂, ..., B_l derart aufgeteilt, dass für alle 1 ≤ j₁ ≠ j₂ ≤ n, j₁ und j₂ nur dann in denselben Topf fallen, wenn für alle c ∊ {0, 1}^k gilt:
wobei 1 ein Eingabeintegerwert ist, der eine maximale Anzahl von Töpfen festlegt (beispielsweise zwischen 2 und 32), und T vorzugsweise gleich
ist, wobei A eine reelle Eingabezahl ist, die in etwa der maximalen Clusterbreite entspricht (beispielsweise im ungefähren Bereich von 2–3). Hierzu ist zu bemerken, dass der vorliegende Ansatz als eine Form des kontextabhängigen Clustering von Datenelementen verstanden werden kann. In der vorliegenden Ausführungsform müssen alle Bruchteile n_j(c) für beliebige zwei Bitpositionen und über alle Kontexte c innerhalb eines festgelegten maximalem Abstands liegen. Falls dies nicht gilt, werden in bestimmten Implementierungen der vorliegenden Ausführungsform ein oder mehrere Parameter angepasst (beispielsweise durch Verringerung von k), bis diese Bedingung erfüllt ist. Es ist auch zu bemerken, dass in weiteren Ausführungsformen andere kontextabhängige Clusterungskriterien verwendet werden, wie etwa die Zuweisung eines geringeren Gewichts für Kontexte, die statistisch weniger signifikant sind.
Die vorhergehenden Ausführungsformen verwenden eine einzige statistische Metrik bei der Zuweisung von Datenelementen (die quer durch die Dateien auftreten) zu bestimmten Töpfen. In anderen Ausführungsformen werden jedoch eine Kombination solcher Metriken und/oder beliebige andere gewünschte Metriken für die Durchführung solcher Zuweisungen verwendet.
In jedem Fall sind nach Abschluss dieser Phase 44 die Datenelemente in Töpfe aufgeteilt. So gilt beispielsweise mit Bezug auf 3, dass die Datenelemente 56 und 57 (von denen jedes einen Wert in jeder der Dateien 61–66 hat) einem Topf zugewiesen werden und das Datenelement 58 (das ebenfalls einen Wert in jeder der Dateien 61–66 hat) einem anderen Topf zugewiesen wird. In den bevorzugten Ausführungsformen wird jedes Datenelement einem der Töpfe zugewiesen, vorzugsweise basierend auf irgendeinem Clusterungskriterium. Es ist zu bemerken, dass, obwohl bestimmte Partitionen in diesem Dokument als „Töpfe” bezeichnet werden, diese Bezeichnung nicht einschränkend sein soll; tatsächlich gilt, wie weiter unten detaillierter beschrieben wird, dass insbesondere dort, wo einzelne Datenwerte betroffen sind, die Partitionen manchmal besser als „Ströme” veranschaulicht werden.
Nochmals zurück zu 2 gilt, dass in Phase 45 irgendwelche Aufteilungen ausgeführt werden, die auf dateispezifischen Eigenschaften basieren. So können beispielsweise die Werte, die den Datenelementen in den einzelnen Töpfen entsprechen, die in Phase 44 identifiziert wurden, weiter in Untertöpfe (oder Unterströme) aufgeteilt werden, basierend auf einem oder mehreren dateispezifischen Kriterien, wie etwa dem Kontext innerhalb der Datei. Genauer gilt, dass in einer bestimmten Ausführungsform die Bitwerte in jedem Topf in acht Untertöpfe aufgeteilt werden, basierend auf den Werten der drei unmittelbar vorausgehenden Bits. Wird diese Ausführungsform auf das in 3 dargestellte Beispiel angewendet, gilt entsprechend, dass der Bitwert für jedes der Bits (61, 56), (62, 56), (63, 56), (64, 56), (65, 56), (66, 56), (61, 57), (62, 57), (63, 57), (64, 57), (65, 57), (66, 57), ..., wobei (x, y) das Bit an der Bitposition y in der Datei x bezeichnet, dem Untertopf 0 zugewiesen wird, wenn die drei vorangehenden Werte in der Datei 000 sind, dem Untertopf 1 zugewiesen wird, wenn die drei vorangehenden Werte in der Datei 001 sind, dem Untertopf 2 zugewiesen wird, wenn die drei vorangehenden Werte in der Datei 010 sind, und so weiter. Bit 70, das entsprechend dieser Benennung als (61, 56) bezeichnet würde, wird somit dem Untertopf 5 zugewiesen, da die Werte der drei vorangehenden Bits 71–73 in seiner Datei entsprechend 101 sind. Gleichzeitig würden die Werte für das Datenelement 58 vorzugsweise in getrennte Unterströme aufgeteilt, da das Datenelement 58 zu einem anderen Topf gehört als die Datenelemente 56 und 57.
Obwohl Phase 45 so dargestellt und beschrieben wurde, dass sie nach Phase 44 auftritt, ist zu bemerken, dass diese Reihenfolge auch umgedreht und/oder in jeder gewünschten Aneinanderreihung ausgeführt werden kann. Beispielsweise werden in einer anderen Ausführungsform Datenelemente und/oder Werte zuerst basierend auf dateispezifischen Überlegungen oder Eigenschaften aufgeteilt, dann unteraufgeteilt, basierend auf Statistiken oder anderen Überlegungen quer durch die Dateien, und anschließend weiter unteraufgeteilt, basierend auf weiteren dateispezifischen Überlegungen oder Eigenschaften.
Schließlich werden in Phase 47 eine oder mehrere Dateien komprimiert, basierend auf den gemachten Aufteilungen. Wie weiter unten genauer beschrieben wird, betrachtet die vorliegende Erfindung allgemein zwei Kategorien von Ausführungsformen. In der ersten werden die identifizierten Partitionen verwendet, um eine Quelldateischätzung zu erstellen (beispielsweise eine Schätzung der in 1 dargestellten Quelldatei 15) und anschließend wird diese Quelldateischätzung als Referenz zur differenziellen Kompression einer solchen Datei oder solcher Dateien verwendet. In der zweiten Kategorie werden die Partitionen (oder Unterpartitionen) als Ströme (oder Unterströme) von Datenwerten behandelt und getrennt komprimiert, ohne irgendeine Art von Quelldateischätzung zu erzeugen.
Für gewöhnlich werden in den bevorzugten Ausführungsformen der Erfindung alle Dateien in der Sammlung, die anfänglich in Phase 41 empfangen wurde (beispielsweise alle Dateien, die zur Festlegung der Partitionen verwendet wurden), in dieser Weise komprimiert. In einigen Fällen wird jedoch nur eine Teilmenge dieser Dateien komprimiert und/oder in einigen Fällen werden zusätzliche Dateien (beispielsweise Dateien, die nicht zur Festlegung der Partitionen verwendet wurden), basierend auf der Aufteilungsinformation, die in Phase 44 und/oder in Phase 45 erhalten wurde, komprimiert. Letzterer Fall ist besonders nützlich, beispielsweise wenn erwartet wird, dass eine neu ankommende Datei ähnliche statistische Eigenschaften hat wie die Dateien, die in Phase 44 und/oder Phase 45 verwendet wurden.
Es werden nun mehrere speziellere Ausführungsformen der Erfindung genauer beschrieben. Die bevorzugten Implementierungen der folgenden Ausführungsformen folgen im Allgemeinen dem oben beschriebenen Verfahren 40. Wie jedoch weiter unten detaillierter beschrieben wird, können die Wege, auf denen die verschiedenen Phasen des Verfahrens 40 ausgeführt werden, zwischen verschiedenen Implementierungen der folgenden Ausführungsformen variieren. Bei weiteren unten beschriebenen Implementierungen/Ausführungsformen werden die oben im Zusammenhang mit dem Verfahren 40 besprochenen Eigenschaften erweitert, modifiziert und/oder weggelassen, so wie es geeignet erscheint.
Ein Verfahren 100 zur Kompression von Dateien unter Verwendung einer Quelldateischätzung gemäß der bevorzugten Ausführungsformen der vorliegenden Erfindung ist in 4 dargestellt. Jede der in 4 dargestellten Phasen wird vorzugsweise in vorgegebener Weise durchgeführt, so dass der gesamte Vorgang 100 durch einen Computerprozessor ausgeführt werden kann, der maschinenlesbare Verarbeitungsschritte ausführt, oder auf einem der anderen in diesem Dokument beschriebenen Wege.
Kurz zusammengefasst, wird mit Bezug auf 4 in Phase 101 eine Sammlung von Dateien empfangen, in Phase 102 wird basierend auf diesen Dateien eine Quelldateischätzung erstellt und anschließend werden in Phase 103 basierend auf der Quelldatei eine oder mehrere Dateien komprimiert. Die die Phase 101 betreffenden Überlegungen sind dieselben, wie diejenigen, die die oben besprochenen Phasen 41 und 42 betreffen. Die die Kompressionsphase 103 betreffenden Überlegungen sind dieselben wie diejenigen der oben besprochenen Phase 47, wobei die tatsächlich verwendete Kompressionstechnik (nachdem die Quelldatei konstruiert wurde) jede verfügbare (beispielsweise herkömmliche) Technik zur differenziellen Kompression einer Datei relativ zu einer anderen sein kann (beispielsweise P. Subrahmanya und T. Berger, "A sliding-window Lempel-Ziv algorithm for differential layer encoding in progressive transmission", Proceedings of IEEE Symposium an Information Theory, Seite 266, 1995). Die meisten wichtigen Eigenschaften der vorliegenden Ausführungsformen, über die oben und andernorts in dieser Offenbarung beschriebenen Überlegungen hinaus, betreffen die Konstruktion einer Quelldateischätzung in Phase 102; diese Phase wird nun im Detail beschrieben.
Zuerst veranschaulicht jedoch 5 den Kontext, in dem die vorliegende Ausführungsform vorzugsweise arbeitet. Die in Phase 101 empfangene Dateisammlung 131 wird anfänglich in die Quelldateischätzfunktion 132 eingegeben, die vorzugsweise den Vorgang 170 (unten beschrieben) ausführt, um eine Schätzung f ^ 135 einer angenommenen zugrundeliegenden Quelldatei f zu erzeugen. Die Quelldateischätzung 135 kann konzeptuell als eine Art Schwerpunkt der Menge von Eingabedateien 131 aufgefasst werden. In den bevorzugten Ausführungsformen wird die Quelldateischätzung 135 in einer Weise erstellt, die die Art der differenziellen Kompression berücksichtigt, die am Ende im Kompressionsmodul 137 ausgeführt wird. Sowohl die Dateien 131 als auch die Quelldateischätzung 135 sind Eingaben für den herkunftseinbeziehenden (engl. source aware) Kompressor 137, der vorzugsweise jede der Eingabedateien 131 (wie auch etwaige zusätzliche, nicht dargestellte Dateien, für die vorzugsweise festgestellt wurden, dass sie in ähnlicher Weise wie die Dateien 131 erzeugt wurden) relativ zur Quelldateischätzung 135 getrennt komprimiert, beispielsweise unter Verwendung irgendeiner für diesen Zweck verfügbaren Technik (beispielsweise irgendeine herkömmliche Technik zur differenziellen Kompression einer Datei relativ zu einer anderen, vorzugsweise verlustfrei). Später, wenn irgendeine bestimmte Datei zurückgeholt werden soll, wird ihre komprimierte Version, zusammen mit der Quelldateischätzung 135, in den herkunftseinbeziehenden Dekompressor 140 eingegeben, der dann die entsprechende Dekompression ausführt. Eine solche Dekompression ist vorzugsweise eine direkte Umkehrung der im Modul 137 eingesetzten Kompressionstechnik.
Die Dateien 131 teilen vorzugsweise einen gemeinsamen Satz von Datenelementen (entweder durch ihre Beschaffenheit oder als Ergebnis irgendeiner in Phase 101 ausgeführten Vorverarbeitung). Entsprechend können die Dateien 131 vorzugsweise als die Dateien 61–66 in 3 veranschaulicht werden. Noch bevorzugter ist jedes der Datenelemente vorzugsweise eine andere Bitposition, so dass jede Datei als Sequenz geordneter Bitpositionen betrachtet wird. Der Ansatz der vorliegenden Ausführungsform ist insbesondere in einem solchen Kontext anwendbar, also mit Bezug auf ein Modell, in dem es eine reale oder angenommene Quelldatei 15 gibt und in dem für die Eingabedateien 131 (oder 61–66) angenommen wird, dass sie mit der Quelldatei 15 als Ausgangspunkt und der Veränderung einzelner Bitwerte (oder Werte anderer Datenelemente) erzeugt wurden, und insbesondere dort, wo ein solches Bit-Flipping kontextabhängig ist.
Es wird nun mit Bezug auf 6 ein typisches Verfahren 170 zum Erstellen der Quelldateischätzung 135 beschrieben. Jede Phase des Verfahrens 170 wird vorzugsweise in vorgegebener Weise durchgeführt, so dass der gesamte Vorgang 170 durch einen Computerprozessor ausgeführt werden kann, der maschinenlesbare Verarbeitungsschritte ausführt, oder auf einem der anderen in diesem Dokument beschriebenen Wege.
Zuerst werden in Phase 171 die Datenelemente in Töpfe aufgeteilt. Zur Vereinfachung der vorliegenden Besprechung sei angenommen, dass jedes Datenelement eine unterschiedliche Bitposition ist. Es versteht sich jedoch, dass dieses Beispiel lediglich dazu dient, die vorliegenden Konzepte ein wenig konkreter zu machen und im Normalfall kann jeder Bezug in diesem Dokument auf eine „Bitposition” auf eine beliebige andere Art von Datenelement verallgemeinert werden.
Die in Phase 171 durchgeführte Aufteilung kann jede der weiter oben in Verbindung mit den Phasen 44 und 45 in 1 beschriebenen Techniken einsetzen. Vorzugsweise wird für die vorliegende Ausführungsform jedoch die Aufteilung nur oder in erster Linie basierend auf Statistiken für die Datenelementwerte quer durch die Dateisammlung 131 hindurch ausgeführt. In einer bevorzugten Implementierung werden somit die Datenelemente in 2^k Töpfe aufgeteilt, basierend auf den kontextabhängigen repräsentativen Werten quer durch die Dateisammlung 131 hindurch, beispielsweise unter Verwendung einer der weiter oben in Verbindung mit der Phase 44 beschriebenen Techniken. Im vorliegenden Beispiel, in dem die Datenelemente Bitpositionen sind (von denen jede einen Wert von entweder 0 oder 1 hat), kann ein solches Aufteilungskriterium gleichbedeutend als der kontextabhängige Bruchteil von Dateien formuliert werden, in denen die Bitposition den Wert 1 (oder gleichwertig 0) hat. Wie oben beschrieben, können die Datenelemente basierend auf solchen kontextabhängigen Bruchteilen in die 2^k verschiedenen Töpfe aufgeteilt werden, und dies unter Verwendung jeder gewünschten Clusterungstechnik.
In Phase 172 werden eine oder mehrere Abbildungen (vorzugsweise eins-zu-eins Abbildungen) zwischen den 2^k Töpfen und 2^k entsprechenden anfänglichen Kontexten (beispielsweise k-Bit Zeichenketten im vorliegenden Beispiel) in der zu erstellenden Quelldateischätzung 135 identifiziert. Das Ziel ist es also, jedes Datenelement auf einen einzigen Kontext in der Quelldateischätzung 135 abzubilden, wobei alle Datenelemente in jedem Topf auf denselben Kontext in der Quelldateischätzung 135 abgebildet werden.
Jede Bitposition f_i in der endgültigen Quelldateischätzung hat einen Kontext, der aus f_i selber, möglicherweise einer Anzahl von Bits vor f_i und möglicherweise einer Anzahl von Bits nach f_i besteht. Obwohl dieses „Kontextfenster” für unterschiedliche i verschieden (in Bezug auf die Größe und/oder Positionen relativ zu f_i) sein kann, geht die vorliegende Diskussion davon aus, dass alle solche Kontextfenster identisch sind. Die Annahme ist also, dass jedes dieser Kontextfenster dieselbe Zahl von Bits l links von f_i und dieselbe Zahl von Bits r rechts von f_i umfasst, so dass der Kontext des i'ten Bits in der Quelldateischätzung 135 f_i-l ... f_i ... f_i+r ist, wobei r + l + 1 = k ist, der gesamten Zahl von Bits, die zur Beschreibung des Kontexts notwendig sind.
Jede Abbildung f.{1, 2, ... 2^k) → {0, 1)^k, von der Menge von Töpfen auf {0, 1}^k, definiert eine Folge von Kontexten. Um dies zu sehen sei angenommen, dass B:{l + 1, l + 2, ..., n – r} → {1, 2, ... 2^k} eine Aufteilung der Bitpositionen bezeichnet. Die Folge der Kontexte ist dann durch f(B(l + 1)), f(B(l + 2)), ..., f(B(n – r)) gegeben.
Es gibt 2^k! mögliche eins-zu-eins Abbildungen der 2^k Töpfe auf unterschiedliche k-Bit Zeichenketten. In den bevorzugten Ausführungsformen ist die einzige oder wenigstens die wichtigste Überlegung bei der Wahl aus den möglichen Abbildungen die Folgende: welche der möglichen Abbildungen ergibt eine Kontextfolge, die am nächsten an einer gültigen Kontextfolge ist? Dies bedeutet im vorliegenden Beispiel, dass eine gewählte Abbildung eine Folge von Bitpositionen in eine Folge von Kontexten konvertiert. In vielen Fällen ist jedoch eine identifizierte Kontextfolge ungültig, das heißt sie kann in einer Quelldatei nicht auftreten.
In dieser Erläuterung bezeichnen c_l+1c_l+2 ... c_n-r eine Folge von Kontexten, wobei jedes der c_i eine k-Bit Zeichenfolge ist. Eine solche Folge von Kontexten ist nur dann gültig oder, mit anderen Worten, repräsentiert nur dann die Folge von Kontexten für aufeinanderfolgende Bits, wenn für alle i die letzten k – 1 Bit von c_i gleich den ersten k – 1 Bit von c_i+1 sind. Die Menge aller gültigen Kontextfolgen kann durch die Menge aller gültigen Pfade im Graphen G_k = (V_k, E_k), der nachfolgend beschrieben wird, repräsentiert werden. Die Vertexmenge V_k ist die Menge aller k-Bit Zeichenfolgen. Es gibt eine gerichtete Kante von einem Vertex a zu einem Vertex b genau dann, wenn die letzten k – 1 Bit des Kontextes, der durch den Vertex a repräsentiert wird, gleich den ersten k – 1 Bit des Kontextes sind, der durch b repräsentiert wird. Ein solcher Graph wird als De-Bruijn-Graph bezeichnet (siehe beispielsweise, Van Lint und Wilson, „A course in combinatorics", Cambridge University Press). Jede gültige Kontextfolge entspricht einem gültigen Pfad im Graphen. In dieser Erläuterung wird angenommen, dass L_k die Menge aller gültigen Folgen von k-Bit Kontexten in einer Zeichenfolge der Länge n bezeichnet.
7 zeigt den De-Bruijn-Graphen G₂. Wie dargestellt, ist die Kontextfolge 00, 01, 10, 01, 11, die den Vertices 201, 202, 204, 202 bzw. 203 entspricht, eine gültige Folge von Kontexten und die Folge 00, 01, 10, 11, die den Vertices 201, 202, 204 bzw. 203 entspricht, ist es nicht, da ein Übergang von Vertex 204 zu Vertex 203 nicht gestattet ist.
Da weder für die Aufteilung noch für die Abbildung sichergestellt ist, dass sie korrekt sind, ist es mit dieser Hintergrundinformation möglich zu sehen, dass die anfängliche Kontextfolge, die durch irgendeine gewählte Abbildung identifiziert wurde, oftmals ungültig ist. Um dieses Problem anzugehen, werden, nachdem eine Abbildung gewählt wurde, Veränderungen vorzugsweise derart an der Kontextfolge vorgenommen, dass sich eine gültige Kontextfolge ergibt. Daher ist ein Weg die beste Abbildung zu wählen, diese zwei Schritte zu kombinieren, indem eine vollständige Suche über alle möglichen 2^k! Abbildungen und über alle möglichen Veränderungen solcher Abbildungen ausgeführt wird, um die Kombination zu finden, die die wenigsten Veränderungen oder, allgemeiner, die Veränderungen mit den geringsten Kosten ergibt. Unglücklicherweise ist die Berechnungskomplexität dieses Ansatzes 2^k!2^kn, was nur für sehr kleine Werte von k durchführbar ist.
Die bevorzugten Ausführungsformen trennen daher die Bestimmung in zwei getrennte Phasen. In der aktuellen Phase 172 wird eine einzige Abbildung (oder in bestimmten Ausführungsformen ein kleine Menge potentieller Abbildungen) identifiziert, vorzugsweise durch das Identifizieren einer kleinen Menge von Abbildungen aus den potentiellen Abbildungen, basierend auf dem Grad der Übereinstimmung mit einer gültigen Kontextfolge. Noch bevorzugter wird eine solche Identifikation wie folgt ausgeführt.
Für jedes Paar von Töpfen, u, v ∊ {1, 2, ... 2^k} wird das Gewicht w(u, v) = |i:B(i) = u, B(i + 1) = v| berechnet, welches die Anzahl der Fälle ist, in denen i in Topf u war und i + 1 in Topf v. Außerdem wird für jede Abbildung f die Menge der Fehlanpassungen als M(f) = {(u, v) ∊ {1, 2, ... 2^k} × {1, 2, ... 2^k}:(f(u), f(v))
E_k} definiert, das heißt als Menge aller Paare (u, v) derart, dass ihre Abbildungen (f(u), f(v)) nicht in der Kantenmenge E_k des De-Bruijn-Graphen G_k liegen. Der Fehlanpassungsausfall von f wird dann als
definiert, das heißt eine Zählung der gesamten Zahl von Fehlanpassungen. Die Abbildung f wird daher wie folgt gewählt:
das heißt als die Abbildung mit dem geringsten Fehlanpassungsausfall, was wiederum bei der vorliegenden Technik einfach eine ungewichtete Zählung der Zahl von Fehlanpassungen ist. In anderen Ausführungsformen kann der Fehlanpassungsausfall jedoch als irgendeine andere Funktion der Fehlanpassungen definiert werden.
Die vorangehende Minimierung kann durch eine vollständige Suche ausgeführt werden. Die zeitliche Komplexität dieses Vorgangs ist O(2^k!), was etwas reduziert werden kann, indem bestimmte Symmetrieargumente genutzt werden. Es ist zu bemerken, dass die zeitliche Komplexität nicht von n (der Zahl der Datenelemente) oder von m (der Zahl der zu komprimierenden Dateien) abhängt. Wenn daher k von der Größenordnung loglog n ist, dann ist diese Berechnung vernachlässigbar gegenüber dem Rest der Kompressionstechnik.
In bestimmten Ausführungsformen wird in dieser Phase 172 nur die Abbildung gewählt, die den absolut minimalen Fehlanpassungsausfall aufweist. Es ist jedoch anzumerken, dass für diese Abbildung nicht sichergestellt ist, dass sie die bestgültige Kontextfolge ergibt. Daher wird in anderen Ausführungsformen in dieser Phase 172 eine kleine Menge der Abbildungen mit den geringsten Fehlanpassungsausfällen ausgewählt (beispielsweise eine feste Zahl von Abbildungen oder, falls ein natürliches Cluster von Abbildungen mit den geringsten Fehlanpassungsausfällen auftaucht, alle Abbildungen in einem solchen Cluster).
In Phase 174 wird die nächste Abbildung (oder die erste, wenn es die erste Iteration innerhalb der Gesamtausführung des Verfahrens 170 ist) ausgewertet, die in Phase 172 ausgewählt wurde. Vorzugsweise wird diese Phase ausgeführt, indem die „am nächsten liegende” gültige Kontextfolge für eine solche Abbildung identifiziert und ein Maß für den Abstand zwischen dieser „am nächsten liegenden” Folge und der anfänglichen Kontextfolge berechnet wird, das heißt einer, die direkt von der Abbildung erzeugt wurde.
In den bevorzugten Ausführungsformen ist die „am nächsten liegende” gültige Kontextfolge für eine bestimmte Abbildung wie folgt festgelegt:
wobei 1(·) die Inidikatorfunktion ist, die gleich 1 ist, wenn ihr Argument wahr ist und 0 andernfalls. Mit anderen Worten ist die am nächsten liegende gültige Kontextfolge diejenige, die am wenigsten von f(B(l + 1)), f(B(l + 2)), ..., f(B(n – r)) abweicht. Die Suche nach dem Minimum kann durch einen standardmäßigen Algorithmus zur dynamischen Programmierung erreicht werden, der ähnlich dem Viterbi-Algorithmus ist (beispielsweise G. D. Forney, "The Viterbi Algorithm" Proceedings of the IEEE 61 (3): 268–278, März 1973). Die zeitliche Komplexität eines solchen Algorithmus ist O(2^kn). Es ist anzumerken, dass die vorliegende Ausführungsform eine bestimmte Kostenfunktion verwendet, bei der jedem Unterschied in den Kontextfolgen das gleiche Gewicht zugewiesen wird. In alternativen Ausführungsformen kann stattdessen jede andere Kostenfunktion verwendet werden, beispielsweise das Zählen der minimalen Anzahl von Bits, die geändert werden müssten, um eine gültige Folge zu erhalten.
In Phase 175 wird eine Bestimmung durchgeführt, ob alle in Phase 172 identifizierten Abbildungen ausgewertet wurden. Falls nicht, kehrt der Vorgang zu Phase 174 zurück, um die Nächste auszuwerten. Falls doch, geht der Vorgang zu Phase 177 weiter.
In Phase 177 wird die beste Abbildung identifiziert. Falls in Phase 172 mehr als eine Abbildung identifiziert wurde, wird vorzugsweise diejenige gewählt, die die geringsten Kosten verursacht, um ihre anfängliche Kontextfolge in eine gültige Kontextfolge umzuwandeln (beispielsweise unter Verwendung derselben Kostenfunktion, die auch in Phase 174 verwendet wird).
Schließlich wird in Phase 179 die gültige Kontextfolge, die in Phase 174 für die in Phase 177 identifizierte Abbildung identifiziert wurde, verwendet, um die Quelldateischätzung 135 zu erzeugen. Diese Phase kann in direkt gegebener Weise durchgeführt werden, wobei beispielsweise der erste Kontext die ersten k Bit der Quelldateischätzung 135 definiert und das letzte Bit jedes nachfolgenden Kontexts das nächste Bit der Quelldateischätzung 135 definiert.
Der vorhergehende Ansatz bestimmt explizit eine Quelldateischätzung 135 und verwendet dann diese Quelldateischätzung 135 als eine Referenz zur Kompression einer Anzahl anderer Dateien. Weitere Vorgänge gemäß bestimmten Konzepten der vorliegenden Erfindung stellen eine Kompression ohne die Notwendigkeit der expliziten Bestimmung einer Quelldateischätzung bereit.
Ein solcher Vorgang 230 ist in 8 dargestellt. Jede der Phasen des Verfahrens 230 wird vorzugsweise in vorgegebener Weise durchgeführt, so dass der gesamte Vorgang 230 durch einen Computerprozessor ausgeführt werden kann, der maschinenlesbare Verarbeitungsschritte ausführt, oder auf einem der anderen in diesem Dokument beschriebenen Wege.
Zuerst wird in Phase 231 eine Sammlung von Dateien empfangen. Diese Phase ist ähnlich Phase 101, die weiter oben in Verbindung mit 4 beschrieben wurde, und dieselben Überlegungen sind hier zutreffend. Wie bei dieser Technik enthalten die empfangenen Dateien vorzugsweise eine gemeinsame Menge von Datenelementen.
In Phase 232 werden diese Datenelemente in verschiedene Töpfe aufgeteilt. Diese Phase ist ähnlich der Phase 171, die weiter oben in Verbindung mit 6 beschrieben wurde, und dieselbe Menge von Überlegungen ist im Allgemeinen hier zutreffend. Allerdings werden in Phase 171 die Datenelemente vorzugsweise in 2^k Töpfe aufgeteilt, wohingegen es in dieser Phase 232 keine Präferenz dafür gibt, dass die Zahl der resultierenden Töpfe eine Potenz von 2 ist.
In Phase 234 werden die Datenwerte aus einer oder mehreren Dateien basierend auf (vorzugsweise ausschließlich basierend auf) den lokalen Datenwerten selbst aufgeteilt. In einem Beispiel wird eine bestimmte Datei in mehrere Ströme aufgeteilt, basierend auf dem Kontext der Bits, beispielsweise den vorangehenden k Bit in der Datei. Genauer sei mit Bezug auf dieses Beispiel k = 3 angenommen. Dann bilden alle Bits in der Datei, denen 000 vorangeht, einen Strom, alle Bits, denen 001 vorangeht, bilden einen weiteren Strom und so fort.
In alternativen Ausführungsformen werden andere lokale Kriterien verwendet (entweder anstatt oder zusätzlich), wie etwa die speziellen Datenwerte, die selbst den verschiedenen Strömen zugewiesen werden, insbesondere dort, wo die Datenelemente einen größeren Bereich von Werten haben können. In solch einem Fall werden beispielsweise Datenwerte, die in bestimmte Bereiche fallen, in bestimmte Ströme geleitet.
In jedem Fall ist in 9 das Ergebnis dargestellt. Hier wurde die Folge von Datenwerten 260 für die gesamte Datei (beispielsweise die Datenwerte 261 und 262 einschließend) ausgewertet und in Ströme aufgeteilt, die in der vorliegenden Ausführungsform als „primäre Ströme” bezeichnet werden. Beispielsweise wurde der primäre Strom 270 erzeugt, indem bestimmte Datenwerte (beispielsweise die Datenwerte 271 und 272) aus der originalen Folge von Datenwerten 260 genommen werden, entsprechend dem für diesen primären Strom 270 festgelegten Kriterium (beispielsweise irgendeinem der weiter oben beschriebenen Kriterien). Wiederum wird vorzugsweise jeder Wert in der originalen Folge 260 basierend auf dem Aufteilungskriterium in einen der vordefinierten Ströme geleitet.
In Phase 235 wird jeder der primären Ströme weiter in Unterströme aufgeteilt, basierend auf den in Phase 232 identifizierten Topfaufteilungen. Beispielsweise werden alle Datenwerte innerhalb eines primären Stroms, deren zugehörige Datenelemente zum selben Topf gehören, in einem Unterstrom zusammengruppiert. Wiederum mit Bezug auf 9 gilt daher, dass bestimmte Werte aus dem Strom 262 herausgeholt werden (beispielsweise lediglich basierend auf den Datenelementen, zu denen sie gehören), um einen Unterstrom 264 zu erzeugen. Genauer und weiterhin mit Bezug auf das oben beschriebene Beispiel gilt, dass die Datenwerte 281 und 282 aus dem primären Strom 270 herausgeholt werden, um den Unterstrom 280 zu bilden, und dies einfach deshalb, weil sie der 6. und 39. Bitposition in der originalen Datendatei 266 entsprechen und weil diese Bitpositionen in Phase 232 demselben Topf zugeordnet wurden.
Schließlich werden in Phase 237 die einzelnen Ströme getrennt komprimiert. Vorzugsweise sind die komprimierten Ströme die Unterströme, die in Phase 235 erzeugt wurden. In bestimmten Ausführungsformen werden jedoch die in Phase 234 erzeugten primären Ströme ohne irgendwelche Unteraufteilungen komprimiert (wobei in diesem Fall die Phasen 232 und 235 wegfallen können). In jedem Fall kann jeder der relevanten Ströme unter Verwendung irgendeiner oder mehrerer verfügbarer (vorzugsweise verlustfreier) Kompressionstechnik(en) komprimiert werden, wie etwa Lempel-Ziv-Algorithmen (LZ'77, LZ'78) oder die Krichevsky-Trofimov Wahrscheinlichkeitszuweisung gefolgt von arithmetischer Kodierung (beispielsweise R. Krichevsky and V. Trofimov, "The performance of universal encoding", IEEE Transactions an Information Theory, 1981).
Die für einzelne Dateien erzeugten Ströme (wie etwa für jede der in Phase 231 empfangenen Dateien) können in der zuvor erwähnten Weise komprimiert werden. Alternativ können mehrere Dateien zusammen komprimiert werden, beispielsweise indem ihre entsprechenden Ströme aneinandergehängt und diese zusammengesetzten Ströme dann getrennt komprimiert werden.
Ein etwas anderes Verfahren 300 zur Kompression von Dateien ohne die zwischengeschaltete Phase der Erstellung einer Quelldateischätzung wird nun mit Bezug auf 10 besprochen. Jede der dargestellten Phasen wird vorzugsweise in vorgegebener Weise durchgeführt, so dass der gesamte Vorgang 300 durch einen Computerprozessor ausgeführt werden kann, der maschinenlesbare Verarbeitungsschritte ausführt, oder auf einem der anderen in diesem Dokument beschriebenen Wege.
Zuerst wird in Phase 301 eine Sammlung von Dateien empfangen. Diese Phase ist ähnlich der Phase 101, die weiter oben in Verbindung mit 4 beschrieben wurde, und es gelten hier dieselben Überlegungen. So wie bei dieser Technik, enthalten die empfangenen Dateien vorzugsweise eine gemeinsame Menge von Datenelementen.
In Phase 302 werden diese Datenelemente in unterschiedliche Töpfe aufgeteilt. Diese Phase ist ähnlich der Phase 232, die weiter oben mit Bezug auf 8 beschrieben wurde, und dieselbe Menge an Überlegungen ist im Allgemeinen hier zutreffend. Allerdings werden in der vorliegenden Ausführungsform die Werte der Datenelemente innerhalb einzelner Töpfe als die getrennten primären Datenströme behandelt (beispielsweise der in 9 dargestellte primäre Strom 270).
In Phase 304 werden diese primären Ströme vorzugsweise in Unterströme aufgeteilt, basierend auf lokalen Kontexten (beispielsweise dem Kontext jedes der jeweiligen Datenwerte). Genauer und mit Bezug auf eine gegebene Datei X i gilt, dass die Datenwerte innerhalb jedes Topfes B_j, 1 ≤ j ≤ l, so in 2^p Unterströme aufgeteilt werden, dass alle Datenwerte in einem Unterstrom denselben Kontext in X i haben, beispielsweise sind die vorangehenden p Bit aller Datenwerte in einem gegebenen Unterstrom identisch.
Schließlich werden in Phase 305 die einzelnen Ströme getrennt komprimiert. Vorzugsweise sind die komprimierten Ströme die in Phase 304 erzeugten Unterströme. In bestimmten Ausführungsformen werden jedoch die in Phase 302 erzeugten primären Ströme ohne irgendeine Unteraufteilung komprimiert (wobei in diesem Fall Phase 304 wegfallen kann). In jedem Fall kann jeder der relevanten Ströme unter Verwendung irgendeiner oder mehrerer verfügbarer (vorzugsweise verlustfreier) Kompressionstechnik(en) komprimiert werden, wie etwa die Krichevsky-Trofimov Wahrscheinlichkeitszuweisung gefolgt von arithmetischer Kodierung.
Die für einzelne Dateien erzeugten Ströme (wie etwa für jede der in Phase 301 empfangenen Dateien) können in dieser Weise komprimiert werden. Alternativ können mehrere Dateien zusammen komprimiert werden, beispielsweise indem ihre entsprechenden Ströme aneinandergehängt und diese zusammengesetzten Ströme dann getrennt komprimiert werden.
Es ist anzumerken, dass die vorangehende Erläuterung in erster Linie auf Kompressionstechniken fokussiert ist. Die Dekompression wird im Allgemeinen in einer direkt gegebenen Weise ausgeführt, basierend auf der tatsächlich angewendeten Art der Kompression. Dies bedeutet, dass die vorliegenden Erfindung allgemein auf eine bestimmte Vorverarbeitung fokussiert ist, die es ermöglicht, dass einen Sammlung ähnlicher Dateien unter Verwendung verfügbarer (beispielsweise herkömmlicher) Kompressionsalgorithmen komprimiert wird. Dementsprechend wird die Dekompressionsphase typischerweise eine direkte Umkehrung des gewählten Kompressionsalgorithmus sein.
Es ist weiterhin anzumerken, dass die vorliegenden Techniken offen für zwei verschiedene Szenarien sind – batch und sequenziell. Im Batch-Kompressionsszenario hat der Kompressor gleichzeitigen Zugriff auf alle Dateien. Die Technik erzeugt die geeignete statistische Information über alle diese Dateien hinweg (beispielsweise nur Topfaufteilungen oder eine Quelldateischätzung, die unter Verwendung dieser Aufteilungen erstellt wurde), und anschließend wird jede Datei basierend auf dieser Information komprimiert. In diesem Szenario sind zur Dekompression einer bestimmten Datei nur die passende statistische Information (beispielsweise nur die Topfaufteilungen oder die Quelldateischätzung) und die betreffende Datei notwendig.
Im sequenziellen Kompressionsszenario kommen die Dateien nacheinander am Kompressor an, was erforderlich ist, um die Dateien on-line zu komprimieren. Daher ändert sich die statistische Information mit der Auswertung jeder neuen Datei. Die i'te Datei wird relativ zu f ^i , der Quelldateischätzung nach der Bearbeitung von i Dateien, komprimiert. Wenn angenommen wird, dass eine neue Datei in ähnlicher Weise zu den vorhergehenden Dateien erzeugt wurde oder anderweitig statistisch ähnlich zu diesen vorhergehenden Dateien ist, dann kann sie alternativ, wie oben bemerkt, ohne eine Veränderung dieser statistischen Information komprimiert werden.
In bestimmten der oben diskutierten Ausführungsformen werden Daten (typischerweise über mehrere Dateien hinweg) in Töpfe, Untertöpfe, Ströme und/oder Unterströme aufgeteilt, die dann in gewisser Hinsicht individuell verarbeitet werden (beispielsweise, indem jeder getrennt komprimiert wird, selbst wenn für jeden dieselbe Kompressionsmethodologie verwendet wird). Sofern nicht deutlich und ausdrücklich das Gegenteil gesagt wird, soll diese Terminologie nicht irgendeine Notwendigkeit für eine getrennte Speicherung dieser verschiedenen Töpfe, Untertöpfe, Ströme und/oder Unterströme implizieren. Entsprechend können die verschiedenen Töpfe, Untertöpfe, Ströme und/oder Unterströme sogar zusammen verarbeitet werden, indem die einzelnen Töpfe, Untertöpfe, Ströme und/oder Unterströme, zu denen die einzelnen Datenwerte gehören, berücksichtigt werden.
Es ist weiterhin anzumerken, dass die Quelldateischätzung 135 oder die Information zur Aufteilung in Töpfe, Untertöpfe, Ströme und/oder Unterströme, in dem Fall, dass eine Quelldateischätzung nicht explizit erstellt wird, vorzugsweise komprimiert (beispielsweise unter Verwendung herkömmlicher Techniken) und zur späteren Verwendung bei der Dekompression der Dateien, wenn dies gewünscht ist, gespeichert wird. Beide Typen von Information können jedoch stattdessen auch in unkomprimierter Form gespeichert werden.
Systemumgebung
Allgemein gesagt, und solange nicht deutlich etwas anderes angegeben wird, gilt, dass alle in diesem Dokument beschriebenen Systeme, Verfahren und Techniken unter Verwendung einer oder mehrerer programmierbarer universell einsetzbarer Datenverarbeitungsvorrichtungen ausgeführt werden können. Solche Vorrichtungen schließen typischerweise und beispielsweise wenigstens einige der folgenden Komponenten ein, die, beispielsweise über einen gemeinsamen Bus, miteinander verbunden sind: einen oder mehrere Hauptprozessoren (CPUs); Nur-Lese-Speicher (ROM); Speicher mit wahlfreiem Zugriff (RAM); Eingabe/Ausgabe-Software und -Schaltungen zur Kommunikation mit anderen Vorrichtungen (beispielsweise unter Verwendung einer festverdrahteten Verbindung, wie etwa einem seriellen Port, einem Parallelport, einem USB-Anschluss oder einem FireWire-Anschluss oder unter Verwendung eines Wireless-Protokolls, wie etwa Bluetooth oder einem 802.11-Protokoll); Software und Schaltungen zum Verbinden mit einem oder mehreren Netzwerken, beispielsweise unter Verwendung einer festverdrahteten Verbindung, wie etwa einer Ethernet-Karte, oder einem Wireless-Protokoll, wie etwa dem Codemultiplexverfahren (Code Division Multiple Access, CDMA), dem Global System for Mobile Communications (GSM), Bluetooth, einem 802.11-Protokoll oder irgendeinem anderen zellbasierten oder nicht zellbasierten System, wobei diese Netzwerke ihrerseits, in vielen Ausführungsformen der Erfindung, mit dem Internet oder mit irgendwelchen anderen Netzwerken verbunden sind; einem Monitor (wie etwa einem Kathodenstrahlröhrenmonitor, einem Flüssigkristallmonitor, einem Monitor mit organischen Leuchtdioden, einem Monitor mit Polymer-LEDs oder irgendeinem anderen Dünnfilm-Monitor); weitere Ausgabevorrichtungen (wie etwa einen oder mehrere Lautsprecher, einen Kopfhörer und einen Drucker); eine oder mehrere Eingabevorrichtungen (wie etwa eine Maus, ein Touchpad, Tablet, einen berührungsempfindlichen Monitor oder ein anderes Zeigegerät, eine Tastatur, Tastenfeld, Mikrofon und einen Scanner); eine Massenspeichereinheit (wie etwa eine Festplatte); eine Echtzeituhr; eine entfernbare Lese/Schreib Speichervorrichtung (wie etwa zum Lesen vom und Schreiben zum RAM, eine Magnetplatte, ein Magnetband, eine optisch-magnetische Platte, eine optische Platte oder Ähnliches); und ein Modem (beispielsweise zum Senden von Faxen oder zum Verbinden mit dem Internet oder mit irgendeinem anderen Computernetzwerk über eine Wählverbindung). Im Betrieb sind die Verarbeitungsschritte zur Implementierung der obenstehenden Verfahren und Funktionalitäten, die in diesem Umfang von einem solchen universell einsetzbaren Computer ausgeführt werden, typischerweise anfänglich auf einem Massenspeicher (beispielsweise der Festplatte) gespeichert, werden anschließend in den RAM-Speicher geladen und dann von der CPU aus dem RAM heraus ausgeführt. In einigen Fällen sind die Verarbeitungsschritte jedoch anfänglich in einem RAM- oder ROM-Speicher gespeichert.
Geeignete Vorrichtungen zur Verwendung bei der Implementierung der vorliegenden Erfindung können von verschiedenen Lieferanten bezogen werden. In den verschiedenen Ausführungsformen werden unterschiedliche Typen von Vorrichtungen eingesetzt, in Abhängigkeit von der Größe und der Komplexität der Aufgaben. Geeignete Vorrichtungen umfassen Mainframe-Computer, Mehrprozessor-Computer, Workstations, Personal Computer und auch kleinere Computer wie etwa PDAs, drahtlose Telefone oder jedes andere Gerät oder Vorrichtung, ob allein operierend, per Kabel in ein Netzwerk eingebunden oder drahtlos mit einem Netzwerk verbunden.
Obwohl obenstehend universell einsetzbare programmierbare Vorrichtungen beschrieben wurden, werden außerdem in alternativen Ausführungsformen stattdessen (oder Zusätzlich) ein oder mehrere Prozessoren oder Computer für Spezialaufgaben eingesetzt. Im Allgemeinen ist anzumerken, dass, außer falls dies deutlich anders angegeben ist, jede der oben beschriebenen Funktionalitäten in Software, Hardware, Firmware oder irgendeiner Kombination dieser implementiert werden kann, wobei die spezielle Implementierung basierend auf bekannten technischen Abwägungen gewählt wird. Genauer gilt, dass dort, wo die oben beschriebene Funktionalität in einer festen, vorgegebenen oder logischen Weise implementiert wird, diese durch Programmierung (beispielsweise Software oder Firmware), eine geeignete Anordnung logischer Komponenten (Hardware) oder jede Kombination dieser beiden erreicht werden kann, wie vom Fachmann leicht zu erkennen ist.
Es versteht sich, dass die vorliegende Erfindung auch maschinenlesbare Medien betrifft, auf denen Computerprogrammanweisungen zur Ausführung der Verfahren und Funktionalitäten dieser Erfindung gespeichert sind. Solche Medien schließen beispielsweise Magnetplatten, Magnetbänder, optisch lesbare Medien wie etwa CD-ROMs und DVD-ROMs, oder Halbleiterspeicher wie etwa PCMCIA-Karten, verschiedene Typen von Speicherkarten, USB-Speichergeräte etc. ein. In jedem Fall kann das Medium die Form eines tragbaren Objekts haben, wie etwa ein Mini-Disk-Laufwerk oder eine Small-Disk, Diskette, Cassette, Cartridge-Speicher, Karten, Sticks etc., oder es kann die Form eines relativ größeren oder ortsfesten Objekts haben, wie etwa einer Festplatte, einem ROM- oder RAM-Speicher, die in einem Computer oder einem anderen Gerät bereitgestellt werden.
Die vorangehende Beschreibung betont primär elektronische Computer und Geräte. Es versteht sich jedoch, dass stattdessen jede andere Datenverarbeitungs- oder andere Art von Vorrichtung verwendet werden kann, wie etwa eine Vorrichtung, die irgendeine Kombination von elektronischer, optischer, biologischer und chemischer Verarbeitung einsetzt.
Zusätzliche Überlegungen
Obenstehend werden mehrere verschiedene Ausführungsformen der vorliegenden Erfindung beschrieben, wobei jede dieser Ausführungsformen bestimmte Eigenschaften umfasst. Es ist jedoch beabsichtigt, dass Eigenschaften, die in Verbindung mit der Erläuterung zu einer einzelnen Ausführungsform beschrieben sind, nicht auf diese Ausführungsform beschränkt sind, sondern dass sie ebenso in verschiedenen Kombinationen in irgendeiner der anderen Ausführungsform eingeschlossen und/oder angeordnet werden können, wie vom Fachmann zu erkennen ist.
Analog wird in der obenstehenden Beschreibung eine Funktionalität manchmal einem bestimmten Modul oder einer bestimmten Komponente zugeschrieben. Die Funktionalität kann jedoch gegebenenfalls wie gewünscht auf irgendwelche verschiedenen Modulen oder Komponenten neu verteilt werden, wodurch sich in einigen Fällen die Notwendigkeit für eine bestimmte Komponente oder ein bestimmtes Modul vollständig erübrigt und/oder das Hinzufügen neuer Komponenten oder Module notwendig wird. Die genaue Verteilung der Funktionalität wird vorzugsweise, mit Bezug auf die spezielle Ausführungsform der Erfindung, entsprechend bekannter technischer Abwägungen vorgenommen, wie vom Fachmann zu erkennen ist.
Daher gilt, dass, obwohl die vorliegende Erfindung detailliert mit Bezug auf deren beispielhafte Ausführungsformen und die beigefügte Zeichnung beschrieben wurde, es für den Fachmann zu erkennen ist, dass verschiedene Anpassungen und Veränderungen der vorliegenden Erfindung vorgenommen werden können, ohne die Idee und den Rahmen der Erfindung zu verlassen. Dementsprechend ist die Erfindung nicht auf die in der Zeichnung dargestellten und oben beschriebenen genauen Ausführungsformen eingeschränkt. Es ist vielmehr beabsichtigt, dass alle Variationen, die vom Geist der Erfindung nicht abweichen, als in deren Rahmen angesehen werden, so wie dies nur durch die diesem Dokument beigefügten Ansprüche eingeschränkt wird.
ZUSAMMENFASSUNG
Bereitgestellt werden, unter anderen Dingen, Systeme, Verfahren und Techniken zur gemeinsamen Kompression, bei denen eine Sammlung von Dateien (61–66) empfangen (41) wird, wobei individuelle Exemplare der Dateien (61–66) eine Menge geordneter Datenelemente (56–58) umfassen (beispielsweise Bitpositionen) und wobei individuelle Exemplare der Datenelemente (56–58) verschiedene Werte in verschiedenen Exemplaren der Dateien (61–66) haben, wobei jedoch die Menge geordneter Datenelemente (56–58) über die Dateien (61–66) hinweg gemeinsam ist. Die Datenelemente (56–58) werden in einen identifizierten Satz von Töpfen aufgeteilt (44), basierend auf Statistiken für die Werte der Datenelemente (56–58) quer durch die Dateisammlung (61–66), und eine empfangene Datei (131) wird basierend auf den Töpfen der Datenelemente (56–58) komprimiert (47).
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

- M. Factor und D. Sheinwald, „Compression in the presence of shared dara”, Information Sciences, 135: 29–41, 2001 [0004]
- K. Eshghi, M. Lillibridge, L. Wilcock, G. Belrose, und R. Hawkes, ”Jumbo Store: Providing efficient incremental upload and versioning for a utility rendering service”, Proceedings of the 5th USENIX Conference an File and Storage Technologies (FAST'07), Seiten 123–138, San Jose, Kalifornien, Februar 2007 [0005]
- P. Subrahmanya und T. Berger, ”A sliding-window Lempel-Ziv algorithm for differential layer encoding in progressive transmission”, Proceedings of IEEE Symposium an Information Theory, Seite 266, 1995 [0042]
- Van Lint und Wilson, „A course in combinatorics”, Cambridge University Press [0052]
- G. D. Forney, ”The Viterbi Algorithm” Proceedings of the IEEE 61 (3): 268–278, März 1973 [0060]
- R. Krichevsky and V. Trofimov, ”The performance of universal encoding”, IEEE Transactions an Information Theory, 1981 [0072]

Claims

Verfahren zur gemeinsamen Kompression, Folgendes umfassend: Empfangen (41) einer Sammlung von Dateien (61–66), wobei individuelle Exemplare der Dateien (61–66) eine Menge geordneter Datenelemente (56–58) umfassen und wobei individuelle Exemplare der Datenelemente (56–58) verschiedene Werte in verschiedenen Exemplaren der Dateien (61–66) haben, wobei jedoch die Menge geordneter Datenelemente (56–58) über die Dateien (61–66) hinweg gemeinsam ist; Aufteilen (44) der Datenelemente (56–58) in einen identifizierten Satz von Töpfen, basierend auf Statistiken für die Werte der Datenelemente (56–58) quer durch die Dateisammlung (61–66); und Komprimieren (47) einer empfangene Datei (131), basierend auf den Töpfen der Datenelemente (56–58).
Verfahren nach Anspruch 1, bei dem der Kompressionsschritt (47) das Erstellen einer Schätzung der Quelldatei (135) und das Komprimieren (137) der empfangenen Datei (131) relativ zur Quelldateischätzung (135) umfasst.
Verfahren nach Anspruch 2, bei dem die Quelldateischätzung (135) erstellt wird, indem der identifizierte Satz vom Töpfen auf einen anfänglichen Satz von Kontexten in der Quelldateischätzung (135) abgebildet (172) und anschließend, basierend auf der Abbildung, eine gültige Folge von Kontexten erstellt wird (174).
Verfahren nach Anspruch 3, bei dem die Abbildung identifiziert wird, indem basierend auf dem Grad der Übereinstimmung mit einer gültigen Kontextfolge mehrere potentielle Abbildungen ausgewertet werden (177).
Verfahren nach Anspruch 2, bei dem die Quelldateischätzung (135) in erster Linie basierend auf einem Kriterium zum Identifizieren einer gültigen Kontextfolge innerhalb der Quelldateischätzung (135) erstellt wird (174), die dem identifizierten Satz von Töpfen entspricht.
Verfahren nach Anspruch 1, bei dem der Kompressionsschritt (47), basierend auf den Töpfen, das Erzeugen von Strömen von Datenwerten und anschließend das getrennte Komprimieren der Ströme (237) umfasst.
Verfahren nach Anspruch 6, bei dem die Ströme erzeugt werden, indem eine lokale Aufteilung der Datenwerte in einer individuellen Datei ausgeführt wird (234) und anschließend weitere Aufteilungen basierend auf den Töpfen ausgeführt werden (235).
Verfahren nach Anspruch 6, bei dem die Ströme erzeugt werden, indem Datenwerte basierend auf lokalem Kontext in die Töpfe aufgeteilt werden (304).
Verfahren nach Anspruch 1, bei dem die Datenelemente (56–58) verschiedene Bitpositionen in den Dateien sind, derart, dass ein einzelnes Datenelement (56) eine gemeinsame Bitposition quer durch die Dateien (61–66) repräsentiert.
Verfahren nach Anspruch 1, bei dem ein Datenelement (56) basierend auf einem repräsentativen Wert für das Datenelement quer durch alle Dateien (61–66) in der Menge einem der Töpfe zugewiesen wird.