2009-12-27 5 views
2

Je réfléchissais à la redondance des données et je voulais juste tout écrire avant de continuer (et de vérifier si cette idée a déjà été mise en pratique)).Compression de fichiers distribués

Très bien, alors voilà. Internet est rempli de données redondantes, y compris du texte, des images, des vidéos, etc. La compression et la décompression à la volée de gzip et de bzip2 sur HTTP ont donc nécessité beaucoup d'efforts. De grands sites comme Google et Facebook ont ​​des équipes entières qui consacrent leur temps à faire charger leurs pages plus rapidement.

Ma « question » se rapporte au fait que la compression est effectuée uniquement sur un par fichier base (gzip file.txt cède file.txt.gz). Sans aucun doute, il existe de nombreux points communs entre des données apparemment sans rapport avec l'Internet. Et si vous pouviez stocker ces fragments communs et les combiner, côté client ou côté serveur, pour générer dynamiquement du contenu? Pour ce faire, il faudrait trouver les «morceaux» les plus communs de données sur Internet. Ces morceaux peuvent être de n'importe quelle taille (il y a probablement un choix optimal ici) et, en combinaison, ils devraient être capables d'exprimer n'importe quelle donnée imaginable. À titre d'exemple, supposons que nous ayons les 5 blocs de données communs suivants: a, b, c, d, and e. Nous avons deux fichiers qui seulement contiennent ces morceaux. Nous avons des programmes appelés chunk et combine. chunk prend des données, les compresse via bzip2, gzip ou un autre algorithme de compression, et sort les blocs qui contiennent les données (après compression). combine étend les morceaux et décompresse le résultat concaténé. Voici comment ils pourraient être utilisés:

$ cat gettysburg.txt 
"Four score and seven years ago...cont'd" 
$ cat test.txt 
"This is a test" 
$ chunk gettysburg.txt test.txt 
$ cat gettysburg.txt.ck 
abdbdeabcbdbe 
$ cat test.txt.ck 
abdeacccde 
$ combine gettysburg.txt.ck test.txt.ck 
$ cat gettysburg.txt 
"Four score and seven years ago...cont'd" 
$ cat test.txt 
"This is a test" 

Lors de l'envoi d'un fichier par HTTP, par exemple, le serveur pourrait chunk les données et l'envoyer au client, qui a alors la capacité de combine les données CHUNKED et rendre .

Quelqu'un at-il essayé avant? Si non, je voudrais savoir pourquoi, et si oui, s'il vous plaît poster comment vous pourriez faire ce travail. Un bon premier pas serait de détailler comment vous pourriez comprendre ce que ces morceaux sont. Une fois que nous avons trouvé comment obtenir les morceaux, alors nous comprenons comment ces deux programmes, chunk et combine, pourraient fonctionner.

Je vais probablement mettre une prime sur ceci (selon la réception) parce que je pense que c'est un problème très intéressant avec des implications du monde réel.

+0

Pourriez-vous élaborer sur ce que font exactement les fonctions chunk et combine? – Vitaliy

+0

Juste ajouté quelques phrases sur ce qu'ils font exactement. –

Répondre

3

Vous avez demandé si quelqu'un avait fait quelque chose de semblable avant et ce que la taille du morceau devrait être, et je pensais que je vous signale les deux documents qui sont venus à l'esprit:

  • (une équipe) Google tente d'accélérer les requêtes Web en exploitant les données partagées entre les documents. Le serveur communique un dictionnaire pré-calculé au client, qui contient des données communes aux documents et référencées sur les demandes ultérieures. Cela ne fonctionne que pour un seul domaine à la fois, et - actuellement - seulement avec Google Chrome: Shared Dictionary Compression Over HTTP

  • (Une équipe) Microsoft a déterminé dans leur travail Optimizing File Replication over Limited-Bandwidth Networks using Remote Differential Compression que pour leur cas de synchronisation du système de fichiers d'une taille de morceau de environ 2KiB fonctionne bien. Ils utilisent un niveau d'indirection, de sorte que la liste des morceaux nécessaires pour recréer un fichier est elle-même divisée en morceaux - le papier est fascinant à lire, et pourrait vous donner de nouvelles idées sur la façon dont les choses pourraient être faites.

Vous ne savez pas si cela vous aide, mais ici c'est le cas. :-)

1

Vous n'avez pas vraiment besoin de l'analyser pour les morceaux les plus courants - en fait, une telle prise de décision distribuée pourrait être très difficile. Comment est quelque chose comme ceci:

Prenons le cas du transfert de données HTTP. Coupez chaque fichier en blocs de 10MiB (ou quelle que soit la taille souhaitée, je suis sûr qu'il y a des implications de performance dans chaque sens) et calculez leur SHA-256 (ou un hachage dont vous êtes sûr qu'il devrait être sûr contre les collisions)

Par exemple, vous avez le fichier F1 avec les blocs B1..Bn et les sommes de contrôle C1..Cn. Maintenant, le serveur HTTP peut répondre à une demande de fichier F1 avec simplement la liste C1 ..Cn

Pour rendre cela utile, le client doit conserver un registre des blocs connus - si la somme de contrôle est déjà là, il suffit de récupérer le bloc localement. Terminé. Si ce n'est pas le cas, prenez-le dans un cache local ou récupérez simplement les blocs du serveur HTTP distant dont vous venez d'obtenir la liste de contrôle.

Si vous téléchargez un autre fichier depuis n'importe quel serveur (même totalement différent) qui partage un bloc, vous l'avez déjà téléchargé et il est aussi sécurisé que l'algorithme de hachage que vous avez choisi.

Maintenant, cela ne traite pas le cas où il y a des décalages (par exemple, un fichier est

AAAAAAAA 

et l'autre

BAAAAAAAA 

qui un algorithme de compression sans doute pourrait traiter. Mais peut-être si vous avez comprimé les blocs eux-mêmes, vous constaterez que vous obtenez la plupart des économies de toute façon ...

Réflexions?

0

Pas exactement lié à votre réponse mais vous le voyez déjà. Microsoft (et d'autres) fournissent déjà des réseaux de périphérie pour héberger les bibliothèques jquery. Vous pouvez vous référer à ces mêmes URI et obtenir les avantages de l'utilisateur ayant accédé au fichier d'un site différent et de son navigateur le mettant en cache.

Cependant, à quel point faites-vous référence à un contenu auquel quelqu'un d'autre s'est référé au cours des 20 dernières minutes (un nombre arbitraire)? Vous pourriez voir un avantage dans une grande entreprise où beaucoup d'employés partagent une application, mais sinon je pense que vous auriez du mal à DÉTERMINER le morceau que vous voulez et qui l'emporterait sur tout avantage à le partager.

1

Il existe un moyen plus simple de gérer les données textuelles. Actuellement, nous stockons du texte sous forme de flux de lettres représentant des sons. Cependant, l'unité de langue est le mot pas son. Par conséquent, si nous avons un dictionnaire de tous les mots et que nous stockons ensuite des "pointeurs" sur ces mots dans les fichiers, nous pouvons dynamiquement reconstituer le texte en utilisant les pointeurs et en recherchant la liste des mots.

Cela devrait réduire la taille des choses par un facteur de 3 ou 4 tout de suite. Dans cette méthode, les mots sont les mêmes que les morceaux que vous avez en tête.La prochaine étape est les groupes de mots communs tels que "ceci est", "je suis", "pleine lune", "sérieux mec", "oh bébé" etc.

Une liste de mots aide également à la vérification orthographique et devrait être implémenté par le système d'exploitation. Y a-t-il une raison pour laquelle les vérificateurs orthographiques ne font pas partie du système d'exploitation?