Existe-t-il des alternatives pour créer des fichiers conteneurs volumineux multi-plateformes?

Question

Auparavant, je posais la question .

Le problème est que les exigences de notre structure de fichiers sont très élevées.

Par exemple, nous essayons de créer un conteneur contenant jusqu'à 4500 fichiers et 500 Mo de données.

La structure de fichier de ce conteneur est composée de

• Base de données SQLite (moins de 1 Mo)
• Fichier de type XML basé sur du texte

• Images dans une structure de dossiers dynamique constituant le reste des 4 500 fichiers

• Après la création initiale, les fichiers d'images sont en lecture seule, à l'exception de la suppression.

• La petite base de données est utilisée régulièrement lors de l'accès au conteneur.

Tar, Zip et les goûts sont trop lents (même avec une compression 0). Lent est subjectif, je sais, mais décoller un conteneur de cette taille dure plus de 20 secondes.

Avez-vous des idées?

Answer 1

Trois choses.

1) Ce que Timothy Walters a dit est exact, je vais entrer dans les détails.

2) 4500 fichiers et 500 Mo de données représentent simplement beaucoup de données et d’écritures sur disque. Si vous exploitez l'ensemble du jeu de données, le processus sera lent. Juste I / O vérité.

3) Comme d'autres l'ont mentionné, le cas d'utilisation n'est pas détaillé.

Si nous supposons un scénario à accès aléatoire en lecture seule, alors ce que Timothy dit est plutôt décevant et sa mise en œuvre est simple.

En bref, voici ce que vous faites.

Vous concaténez tous les fichiers dans un seul blob. Pendant que vous les concaténez, vous suivez leur nom de fichier, leur longueur et le décalage que le fichier commence dans le blob. Vous écrivez cette information dans un bloc de données, trié par nom. Nous appellerons cela la table des matières ou bloc TOC.

Ensuite, concaténez les deux fichiers ensemble. Dans le cas simple, vous avez d'abord le bloc COT, puis le bloc de données.

Lorsque vous souhaitez obtenir des données à partir de ce format, recherchez le nom du fichier dans la table des matières, saisissez le décalage à partir du début du bloc de données, ajoutez la taille de bloc de la table des matières et lisez FILE_LENGTH octets de données. Simple.

Si vous voulez être intelligent, vous pouvez placer la table des matières à la fin du fichier blob. Ensuite, ajoutez tout à la fin le décalage par rapport au début de la table des matières. Ensuite, lseek jusqu'à la fin du fichier, sauvegardez 4 ou 8 octets (en fonction de la taille de votre numéro), prenez CETTE valeur et lseek encore plus loin jusqu'au début de votre table des matières. Ensuite, vous revenez à la case départ. Pour ce faire, vous n'avez pas à reconstruire l'archive deux fois au début.

Si vous étalez votre table des matières en blocs (d'une taille de 1 Ko, par exemple), vous pouvez facilement effectuer une recherche binaire sur la table des matières. Il suffit de remplir chaque bloc avec les entrées d’informations sur le fichier et, lorsque vous manquez de place, écrivez un marqueur, un pavé avec des zéros et avancez au bloc suivant. Pour effectuer la recherche binaire, vous connaissez déjà la taille de la table des matières, commencez au milieu, lisez le premier nom de fichier et partez de là. Bientôt, vous trouverez le bloc, puis vous lisez dans le bloc et vous le scannez pour rechercher le fichier. Cela le rend efficace pour la lecture sans avoir la totalité de la table des matières dans la RAM. L’autre avantage est que le blocage nécessite moins d’activité sur le disque qu’un schéma chaîné tel que TAR (vous devez analyser l’archive pour trouver quelque chose).

Je vous suggère également de compresser les fichiers aux tailles de bloc. Les disques, comme ceux qui fonctionnent avec des blocs de données de taille normale, ne sont pas difficiles non plus.

Il est difficile de mettre à jour ceci sans reconstruire l’ensemble. Si vous souhaitez un système de conteneur pouvant être mis à jour, vous pouvez également consulter certaines des conceptions de système de fichiers les plus simples, car c’est précisément ce que vous recherchez dans ce cas.

En ce qui concerne la portabilité, je vous suggère de stocker vos nombres binaires dans l'ordre du réseau, car la plupart des bibliothèques standard disposent de routines pour gérer ces informations à votre place.

Answer 2

Alors que vous semblez effectuer des opérations de système de fichiers arbitraires sur votre conteneur (par exemple, création, suppression de nouveaux fichiers dans le conteneur, écrasement de fichiers existants, ajout), je pense que vous devriez opter pour un système de fichiers. Allouez un fichier volumineux, puis créez-y une structure de système de fichiers.

Il existe plusieurs options pour le système de fichiers disponible: pour Berkeley UFS et Linux ext2 / ext3, des bibliothèques en mode utilisateur sont disponibles. Il est également possible que vous trouviez une implémentation FAT quelque part. Assurez-vous de bien comprendre la structure du système de fichiers et choisissez-en un qui permette l’extension. Je sais qu’ext2 est assez facile à étendre (par un autre groupe de blocs) et que FAT est difficile à étendre (nécessité d’ajouter à la FAT).

Vous pouvez également placer un format de disque virtuel sous le système de fichiers, permettant ainsi un remappage arbitraire des blocs. Ensuite, "gratuit" les blocs du système de fichiers n'ont pas besoin d'apparaître sur le disque et vous pouvez allouer le disque virtuel beaucoup plus volumineux que ne le sera le fichier conteneur réel.

Answer 3

Partant du principe que vous n’avez besoin que d’un accès en lecture seule aux fichiers, pourquoi ne pas simplement les fusionner et créer un deuxième "index" fichier (ou un index dans l'en-tête) qui vous indique le nom du fichier, la position de départ et la longueur. Tout ce que vous avez à faire est de rechercher le point de départ et de lire le nombre d'octets correct. La méthode varie en fonction de votre langue, mais elle est plutôt simple dans la plupart des cas.

La partie la plus difficile devient alors la création de votre fichier de données + index, et même cela reste assez basique!

Answer 4

Une image de disque ISO pourrait faire l'affaire. Il devrait pouvoir contenir facilement de nombreux fichiers et est pris en charge par de nombreux logiciels sur tous les principaux systèmes d'exploitation.

Answer 5

Tout d’abord, merci d’avoir élargi votre question, cela aide beaucoup à fournir de meilleures réponses.

Étant donné que vous allez de toute façon avoir besoin d’une base de données SQLite, avez-vous examiné les performances de son intégration dans la base de données? Mon expérience est basée sur SQL Server 2000/2005/2008 et je ne suis donc pas convaincue des capacités de SQLite, mais je suis sûr que ce sera une option assez rapide pour rechercher des enregistrements et obtenir les données, tout en permettant la suppression. et / ou les options de mise à jour.

Habituellement, je ne recommanderais pas de placer des fichiers dans la base de données, mais étant donné que la taille totale de toutes les images est d'environ 500 Mo pour 4500 images, vous regardez un peu plus de 100 Ko par image, n'est-ce pas? Si vous utilisez un chemin dynamique pour stocker les images, dans une base de données légèrement plus normalisée, vous pouvez avoir un "ImagePaths". table qui associe chaque chemin à un ID, vous pouvez alors rechercher des images avec ce PathID et charger les données de la colonne BLOB selon vos besoins.

Le ou les fichiers XML peuvent également figurer dans la base de données SQLite, ce qui vous donne un "fichier de données" unique pour votre application, qui peut être déplacé sans problème entre Windows et OSX. Vous pouvez simplement compter sur votre moteur SQLite pour fournir les performances et la compatibilité dont vous avez besoin.

La façon dont vous l’optimisez dépend de votre utilisation. Par exemple, si vous avez fréquemment besoin d’obtenir toutes les images sur un certain chemin, un PathID (sous la forme d’un entier pour la performance) sera rapide, mais si vous affichez tous les les images commençant par "A" et affichez simplement le chemin en tant que propriété, puis un index sur la colonne ImageName serait plus utile.

Je suis toutefois un peu préoccupé par le fait que cela ressemble à une optimisation prématurée, car vous devez vraiment trouver une solution qui fonctionne 'assez rapidement', abstenez-vous de la mécanique de votre application (ou des deux applications si vous avez à la fois Mac et PC). versions) utilisent un référentiel simple ou similaire et vous pouvez ensuite modifier la méthode de stockage / récupération à volonté, sans implication pour votre application.

Answer 6

Vérifiez le système de fichiers solides - il semble que ce soit ce dont vous avez besoin.