Beaucoup de petits fichiers ou un couple énorme?

Question

En termes de performances et d'efficacité, est-il préférable d'utiliser beaucoup de petits fichiers (par lots, je veux dire jusqu'à quelques millions) ou un couple (une dizaine) d'énormes fichiers (plusieurs gigaoctets)? Disons simplement que je construis une base de données (pas tout à fait vrai, mais tout ce qui compte, c'est que l'on puisse y accéder BEAUCOUP).

Je suis principalement concerné par les performances de lecture. Mon système de fichiers est actuellement ext3 sous Linux (Ubuntu Server Edition si c'est important), même si je suis dans une position où je peux encore changer, donc les comparaisons entre différents systèmes de fichiers seraient fabuleuses. Pour des raisons techniques, je ne peux pas utiliser un SGBD réel pour cela (d'où la question), donc "juste utiliser MySQL" n'est pas une bonne réponse.

Merci d'avance, et laissez-moi savoir si je dois être plus précis.

---

EDIT: Je vais être stocker beaucoup de morceaux de données relativement faible, ce qui explique pourquoi en utilisant beaucoup de petits fichiers serait plus facile pour moi. Donc si j'utilisais quelques fichiers volumineux, je ne récupérerais que quelques Ko à la fois. J'utiliserais aussi un index, donc ce n'est pas vraiment un problème. En outre, certaines données pointent vers d'autres données (elles pointent vers le fichier dans le cas des lots de petits fichiers et pointent vers l'emplacement des données dans le fichier dans le cas des fichiers volumineux).

Answer 1

Il ya beaucoup de suppositions ici, mais, à toutes fins utiles, la recherche par un fichier volumineux sera beaucoup plus rapide que la recherche à travers un tas de petits fichiers. Supposons que vous êtes à la recherche d'une chaîne de texte contenue dans un fichier texte.

La recherche d'un fichier 1TB sera beaucoup plus rapidement que l'ouverture 1 000 000 Mo fichiers et la recherche à travers ceux-ci.

Chaque opération d'ouverture de fichier prend du temps. Un fichier volumineux ne doit être ouvert qu'une seule fois.

Et, compte tenu de la performance disque, un seul fichier est beaucoup plus susceptible d'être stocké contigously qu'une grande série de fichiers.

... Encore une fois, ce sont des généralisations sans en savoir plus sur votre application spécifique.

Profitez,

Robert C. Cartaino

Answer 2

Le problème principal ici concerne l'indexation. Si vous voulez rechercher des informations dans un fichier volumineux sans un bon index, vous devrez scanner tout le fichier pour obtenir les informations correctes qui peuvent être longues. Si vous pensez que vous pouvez construire des mécanismes d'indexation forts, alors vous devriez aller avec le fichier énorme.

Je préférerais déléguer cette tâche à ext3 qui devrait être plutôt bonne.

modifier:

Une chose à considérer selon cette wikipedia article on ext3 est que la fragmentation ne se produit au fil du temps. Donc, si vous avez un grand nombre de petits fichiers qui prennent un pourcentage important du système de fichiers, vous perdrez des performances au fil du temps.

L'article valident également la demande sur les 32k fichiers par limite de répertoire (en supposant un article wikipedia peut valider quoi que ce soit)

Answer 3

Je crois que Ext3 a une limite d'environ 32000 fichiers/répertoires par répertoire. Si vous utilisez la route des millions de fichiers, vous devrez les diffuser dans de nombreux répertoires. Je ne sais pas ce que cela ferait pour la performance.

Ma préférence serait pour plusieurs fichiers volumineux. En fait, pourquoi en avoir plusieurs, à moins qu'il s'agisse d'unités logiquement séparées? Si vous êtes encore en train de le diviser juste pour le partager, je dis ne fais pas ça. Ext3 peut gérer de très gros fichiers très bien.

Answer 4

Cela dépend. vraiment. Différents systèmes de fichiers sont optimisés d'une manière différente, mais en général, les petits fichiers sont compressés efficacement. L'avantage d'avoir de gros fichiers est que vous n'avez pas besoin d'ouvrir et de fermer beaucoup de choses. ouvrir et fermer sont des opérations qui prennent du temps. Si vous avez un gros fichier, vous normalement ouvrir et fermer une seule fois et que vous utilisez opérations de recherche

Si vous optez pour les lots-de-fichiers solution, je vous suggère une structure comme

b/a/bar 
b/a/baz 
f/o/foo 

parce que vous avoir des limites sur le nombre de fichiers dans un répertoire.

Answer 5

Je travaille avec un système qui stocke jusqu'à environ 5 millions de fichiers sur un système de fichiers XFS sous Linux et n'a pas eu de problèmes de performances. Nous utilisons uniquement les fichiers pour stocker les données, nous ne les analysons jamais complètement, nous avons une base de données pour la recherche et l'un des champs d'une table contient un guid que nous utilisons pour récupérer. Nous utilisons exactement deux niveaux de répertoires comme ci-dessus avec les noms de fichiers étant le guid, bien que plus pourrait être utilisé si le nombre de fichiers est encore plus grand. Nous avons choisi cette approche pour éviter de stocker quelques téraoctets de plus dans la base de données qui devaient seulement être stockés/retournés et jamais recherchés et cela a bien fonctionné pour nous. Nos fichiers vont de 1k à environ 500k.

Nous avons également lancé le système sur ext3, et il a bien fonctionné, même si je ne suis pas sûr si nous l'avons déjà dépassé un million de fichiers. Nous aurions probablement besoin d'aller à un système de répertoire 3 en raison du nombre maximal de fichiers par limite d'annuaire.