La meilleure façon de stocker / récupérer des millions de fichiers lorsque leur méta-données dans une base de données SQL

Question

J'ai un processus qui va générer initialement 3-4 millions de fichiers PDF, et continuer au taux de 80K / jour. Ils seront assez petit (50K) chacun, mais ce que je suis inquiet au sujet de la façon de gérer la masse totale des fichiers que je suis générer pour la recherche facile. Quelques détails:

1. Je vais avoir d'autres étapes pour exécuter une fois un fichier ont été générés, et il y aura quelques serveurs participants, donc je vais besoin de regarder des fichiers comme ils sont générés.
2. Une fois généré, les fichiers seront disponibles si un processus de recherche que j'ai écrit. Essentiellement, je vais devoir les tirer sur la base d'un numéro de commande, qui est unique par fichier.
3. A tout moment, un numéro d'ordre existant peut être soumis à nouveau, et le fichier généré devra remplacer la copie originale.

A l'origine, je l'avais prévu d'écrire ces fichiers tout dans un seul répertoire sur un NAS, mais je me rends compte que cela pourrait ne pas être une bonne idée, car il y a des millions d'entre eux et Windows risque de ne pas traiter un million de fichiers recherche très gracieusement. Je cherche quelques conseils:

1. Est-ce qu'un seul dossier d'accord? Les fichiers ne seront jamais listés -. Ils ne seront récupérés à l'aide d'un System.IO.File avec un nom de fichier que je l'ai déjà déterminé
2. Si je fais un dossier, puis-je regarder pour les nouveaux fichiers avec un System.IO.DirectoryWatcher, même avec que de nombreux fichiers, ou seront-ils commencer à devenir lent avec autant de fichiers?
3. Faut-il être stockés sous forme de BLOB dans une base de données SQL Server à la place? Depuis que je vais devoir les récupérer par une valeur de référence, peut-être cela fait plus de sens.

Merci pour vos pensées!

Answer 1

Je groupe les fichiers dans des sous-dossiers spécifiques, et d'essayer de les organiser (les sous-dossiers) d'une manière logique métier. Peut-être que tous les fichiers faits au cours d'un jour donné? Au cours d'une période de six heures de chaque jour? Ou tous les # fichiers, je dirais quelques 1000 max. (Il y a probablement un nombre idéal là-bas, nous espérons que quelqu'un va poster.)

Est-ce que les fichiers vieillissent jamais et obtenir supprimés? Si oui, trier et fichier être supprimables morceau. Sinon, je peux être votre fournisseur de matériel?

Il y a des arguments des deux côtés de stockage de fichiers dans une base de données.

• D'une part, vous obtenez une sécurité accrue, parce qu'il est plus difficile à tirer les fichiers de la base de données; d'autre part, vous obtenez des performances potentiellement moins bonne, parce qu'il est plus difficile à tirer les fichiers de la base de données.
• Dans la DB, vous n'avez pas à vous soucier de combien de fichiers par dossier, secteur, cluster NAS, peu importe - qui est le problème de DB, et probablement ils ont une bonne mise en œuvre pour cela. D'un autre côté, il sera plus difficile à gérer / examiner les données, comme ce serait un blobs bazillion dans une seule table, et, bien, beurk. (Vous pouvez partitionner la table en fonction de l'infiniment plus facile logique métier, ce qui rendrait la suppression ou l'archivage mentionné ci-dessus à effectuer. Ce, ou peut-être vues partitionnées, étant donné que le partitionnement de table a une limite de 1000 partitions.)
• SQL Server 2008 a le type de données FileStream; Je ne sais pas grand-chose à ce sujet, peut-être dignes d'intérêt.

Un dernier point à se soucier est de garder les données « aligné ». Si le DB stocke les informations sur le fichier avec le chemin / nom au fichier, et le fichier est déplacé, vous pouvez obtenir totalement lavé au jet.

Answer 2

Pour répondre à vos questions:

1. Je ne les stocker dans un seul dossier. Comme les chances sont à un moment donné vous voulez regarder les fichiers réels sur le disque, plutôt que d'une autre façon.
   Au lieu de cela, pourquoi ne pas les stocker dans des répertoires séparés, divisés en lots de 1000? Peut-être en utilisant l'ID comme clé.
2. Que de nombreux fichiers vont probablement inonder le DirectorWatcher, de sorte que certains seront perdus. Je l'ai utilisé dans le passé, et au-delà d'un certain point (cent AFEW), je l'ai trouvé commence à manquer des fichiers. Peut-être utiliser un autre répertoire pour les fichiers entrants et ensuite traiter ce tout aussi souvent. Cela peut alors déclencher un processus pour mettre à jour l'original.
3. Je ne stocker les documents dans une base de données, mais sans aucun doute stocker les métadonnées dans une base de données.

Answer 3

Vous pouvez facilement organiser des fichiers dans plusieurs dossiers sans avoir à le faire par la logique métier, ou ordre par jour, ce qui est particulièrement bien si ce genre de commande serait « clumpy » (beaucoup de coups dans un dossier, peu d'autres).

La meilleure façon de le faire est de créer un hachage unique pour le nom du fichier, de sorte que peut-être vous obtenez quelque chose comme ceci:

sf394fgr90rtfofrpo98tx.pdf

Puis briser ce en blocs de deux caractères, et vous obtiendrez ceci:

sf/39/4f/gr/90/rt/fo/fr/po/98/tx.pdf

Comme vous pouvez le voir, il vous donne une arborescence profonde que vous pouvez facilement naviguer.

Avec une bonne fonction de hachage, ce sera réparti de façon homogène, et vous ne serez jamais obtenir plus de 1296 entrées par répertoire. Si jamais vous obtenez une collision (qui devrait être extrêmement rare), il suffit d'ajouter un numéro à la fin: tx.pdf, tx_1.pdf, tx_2.pdf. Encore une fois, les collisions sur ces grandes hash devraient être extrêmement rares, de sorte que le genre de agglomérante vous obtenez à cause de cela est un non-problème.

Vous avez dit que les documents sont signés numériquement, de sorte que vous avez probablement le hachage dont vous avez besoin, il sous forme de la chaîne de signature.

Answer 4

1) Un dossier simple peut être rapide avec un acceptablement index séparé, mais comme il est trivial de le mettre dans les sous-répertoires qui vous permettra la possibilité de parcourir tout le faire.
Alors maintenant, vous devez comprendre votre convention de nommage. Bien que je suggère normalement un hachage pour obtenir une répartition uniforme de ids mais comme vous faites tellement il est probablement judicieux d'utiliser les valeurs que vous avez déjà. Si vous avez un numéro de commande avez-vous un horodatage aussi? Si oui, préfixe juste le numéro de commande avec un horodatage.

Il faut savoir que si vous utilisez ids de commande vous pouvez rencontrer http: // fr .wikipedia.org / wiki / Benford% 27s_law

Answer 5

Vous devez le tester. Toutes ces solutions dépendent du système de fichiers sous-jacent. Certains systèmes de fichiers peuvent gérer d'énormes répertoires, certains ne peuvent pas. Certains indice des systèmes de fichiers leurs annuaires, certains ne le font pas (ces deux points ne sont pas nécessairement liés).

Briser les choses dans un arbre de répertoires a la chance raisonnable d'être performant, tout simplement parce que, à la fin, les répertoires individuels ont tendance à avoir peu d'entrées globales. Cela fonctionne pour la plupart tout système de fichiers, tout simplement parce que même un « stupide » qui fait une recherche de répertoire linéaire pour votre fichier peut rechercher une centaine ou deux entrées assez rapidement.

Si le système de fichiers est l'indexation des répertoires (comme, disons, un btree, ou simplement le tri en interne qui est effectivement la même chose dans ce contexte), les tailles de répertoire sont moins importants, bien que certains outils peuvent se plaindre (chargement d'un Explorateur windows avec des fichiers 4M, qui savent ce qui se passera).

Alors, je recherche votre système d'exploitation prévu et les options de système de fichiers, et de le tester et voir ce qui fonctionne le mieux pour vous.

Answer 6

Déterminer un certain ordre logique des sous-répertoires et de les stocker dans des blocs de pas plus de 512 ou si des fichiers dans un dossier.

Ne pas stocker les fichiers dans une base de données. Les bases de données sont pour les données, les serveurs de fichiers sont des fichiers. les stocker sur un serveur de fichiers, mais stocker le chemin et la récupération des informations dans une base de données.

Answer 7

Pourquoi ne pas considérer tous ces fichiers Stockage après été converti en PDF dans la base de données (blob) Par conséquent Avantages:

1. Je vous beleive avez l'habitude de traiter direclty avec l'OS d'E / S, et tout laisser à la DB.
2. Pas besoin de nommer hachage
3. Facile à sauvegarder et maintenir

Answer 8

Lorsque vous utilisez une base de données pour stocker vos fichiers, en particulier avec petit fichier les frais généraux devrait être faible. mais vous pouvez aussi faire des choses comme:

DELETE FROM BLOBTABLE WHERE NAME LIKE '<whatever>'

ou lorsque vous avez une date d'expiration, ou si vous voulez rafraîchir un fichier, vous supprimez par:

DELETE FROM BLOBTABLE WHERE CREATIONDATE < ...
etc...

Answer 9

Question:

Pourquoi ces documents doivent être générés et stockés sous forme de fichiers PDF?

Si elles peuvent être générées, pourquoi ne pas simplement conserver les données dans la base de données et les générer à la volée lorsque cela est nécessaire? Cela signifie que vous pouvez rechercher les données réelles qui est nécessaire pour la recherche de toute façon et ne pas avoir les fichiers sur le disque. De cette façon, vous pouvez également mettre à jour le modèle PDF si nécessaire, sans la nécessité de régénérer quoi que ce soit?

Answer 10

1) Cela va tout à fait contraire à ce que je prêche en général, mais vous pouvez les stocker dans une base de données SQL, car ils sont trully petits fichiers. SQL Server serait également vous permettre de trouver rapidement et facilement les fichiers dont vous avez besoin sans bousiller disque fou normalement associé à un si grand énumération répertoire. En outre, le stockage des fichiers dans SQL (alors que je suis généralement contre) serait grandement facilité la sauvegarde / restauration processus.

2) les stocker dans des répertoires et soit les indexer avec le service d'indexation de Windows ( frissonne ) ou créer votre propre index dans SQL Server qui contiendrait le nom du fichier et chemin complet. Je suggère de les stocker dans des répertoires distincts, avec seulement quelques dizaines de milliers de fichiers chacun. Peut-être que vous pourriez utiliser l'année afin que le nom du dossier?

Quelle que soit la façon dont leur stockée - ne pas analyser le répertoire pour trouver les fichiers -. Vous aurez certainement besoin d'avoir un indice de quelque sorte

Hope this helps!

Answer 11

Ma base de données de fichier contient plus de 4 millions de dossiers, avec de nombreux fichiers dans chaque dossier.

Il suffit simplement ballottés tous les dossiers dans un répertoire. NTFS peut gérer cela sans aucun problème, et des outils avancés comme robocopy peuvent aider quand vous avez besoin de le déplacer.

Assurez-vous que vous pouvez indexer les fichiers sans analyse. Je l'ai fait en lançant mon index dans une base de données MySQL.

Donc, pour obtenir un fichier que je recherche dans la base de données MySQL sur des métadonnées et obtenir un indice. Puis-je utiliser cet index pour lire le fichier directement. bien Scaled pour moi jusqu'à présent. Mais ne notez que vous tournerez tout dans un accès aléatoire et lecture aléatoire donc / écriture. Ceci est la mauvaise performance pour le disque dur, mais heureusement SSD vous aidera beaucoup.

En outre, je ne lancer les fichiers dans la base de données MySQL. Vous ne serez pas en mesure de le faire ReadS réseau sans avoir un client qui comprend mysql. En ce moment, je peux accéder à tous les fichiers sur le réseau en utilisant un programme parce que je peux utiliser son URL réseau.

Answer 12

Je pense comme tant d'autres l'ont dit, vous devriez faire des sous-dossiers, mais d'une manière que vous pouvez trouver les données par code. Par exemple, si fonctionne datetime, utiliser. De la lecture de ce que vous avez dit, il semble qu'il y ait une certaine forme de structure hiérarchique des rapports (quotidiens, rapport hebdomadaire, quotidien X, rapport horaire Y, etc.) Je regardais la structure quand et pourquoi les rapports sont générés et construire mes répertoires de cette façon.