On Tuesday 20 February 2007 10:55:42 Paul Ebermann wrote:
Hast du das selbst ausprobiert?
Ich habe es gerade mal mit deiner E-Mail ausprobiert ... [...] -rw----r-- 1 ebermann ma2000 3031 20. Feb 10:35 beispiel1.zip -rw----r-- 1 ebermann ma2000 6052 20. Feb 10:36 beispiel2.zip
$
Die zweite Datei ist fast doppelt so groß :-)
Beim Zip-Format wird jede einzelne Datei in einem Archiv unabhängig komprimiert, um ein einfaches Hinzufügen, Extrahieren und Löschen einzelner Dateien daraus zu ermöglichen. Dies geht zu Lasten des Komprimierungsgrades bei mehreren ähnlichen Dateien ...
Deswegen wird für Datei-Komprimierung mehrerer Dateien unter Unix auch häufiger .tar.gz genommen (tar packt mehrere Dateien (unkomprimiert in eine, gzip komprimiert dann das ganze)).
Danke für deine Analyse. Daran, dass Zip im Gegensatz zum Gespann Tar + Gzip Einzeldateien nicht zusammenfasst hab ich in der Tat nicht gedacht. Ich hatte es nur mit tar.gz- und tar.bz2-Archiven ausprobiert, da ich selber Linux verwende und hatte zip keine allzugroße Beachtung geschenkt (zumal Winzip tar.gz entpacken kann).
Ich hatte das Thema vor längeren mal in ganz anderem Kontext ausprobiert. Vor einiger Zeit stand in Spektrum der Wissenschaft ein recht interessanter Artikel zum Thema computergesteuerte Verwandtschaftsanalyse von DNS-Fragmenten: Zusammen komprimieren und mit der getrennten Komprimierung vergleichen und dann die Dateigrößen verrechnen sind eine recht gute Maßzahl zur Erszellung einer Karte der genetischen verwandtschaft verschiedener Lebewesen.
Das ganze lässt sich auch super nutzen um Texte zu vergleichen. Im Spektrum-Artikel wurde dazu der Stammbaum von Kettenbriefen erstellt. Evtl. ließe sich das also auch gegen Spam einsetzen (bzw. ich denke mal dass gängige Spamfilter soetwas bereits in ihrem Maßnahmenköcher haben).
Mit Kompressionsalgorithem lassen sich noch ganz andere Dinge anstellen wie Datensalat eines Zufallsgenerators rückwärts durch eine geeignete Kompressionsroutine laufen lassen, was Nonsenstexte im Stile des Bürgerlichen Gesetzbuchs oder im Stil von Karl May erzeugt. Dazu braucht es aber einen etwas anderen Algorithmus, der versteckte sprach- und textabhängige Redundanzen findet: Das Wort "ein" ist für Zip nicht komprimierbar, wenn man aber weiß, dass das "e" im Deutschen der häufigste erste Buchstabe im Wort ist kann man es mit einer 1 codieren, der häufigste zweite Buchstabe ist ein "i" und wird somit ebenfalls mit 1 codiert, dasselbe gilt für den dritten Buchstaben "n". "ein" kann also bei bekanner Sprache (bzw. bekannter Häufigkeitsmatrix) mit "111" codiert werden, was sich nun gut komprimieren ließe. Egal, das führt zu weit und ist Off-Topic hier ;)...
Um zum Thema zurückzukommen: Zum Glück werden bei MediaWiki (zumindest bei der Wikipedia-Variante) jeweils 20 Versionen zusammen komprimiert, und damit kann schon ein Großteil des Platzes gespart werden. (Disclaimer: Diese Information von mir ist schon einige Monate alt, es kann sein, dass es inzwischen wieder anders optimiert wird ...)
Es wird nach wie vor Gzip in der von dir beschriebenen Form verwendet. Bzip2 wäre zwar besser, allerdings ist der Unterschied nicht so groß. Gzip reduziert die Datenbank nach dem was ich weiß auf ca. 15%, Bzip2 auf 10%. Der Mehraufwand für Bzip2 lohnt also nicht angesichts des exponentiellem Wachstum der Wikipediadatenbank (Das Speichern der Differenzen und gemeinsame Kompression dieser Differenzen bringt ebenfalls kaum Platzersparnis, würde aber sehr viel mehr Rechenzeit kosten).
Ein Algorithmus der um Größenordnungen besser wäre als Gzip/Bzip2 ist der obige skizzierte, welcher versteckte Redundanzen findet (wär übrigens sehr dankbar wenn mir einer sagen kann wie der Algorithmus heißt, ich hab es mal vor Jahren gesehen, aber den Namen vergessen).
Grüße, Arnomane