Question de conception de référentiel de base de documents / images

Question

Question:

Dois-je écrire mon application pour accéder directement à une base de données Image Repository ou pour créer un middleware permettant de gérer les demandes de document.

Arrière-plan:

Je dispose d’une application personnalisée de traitement de documents et de flux de documents qui stocke actuellement environ 15 millions de documents / images de documents (90% + une page, groupes de 4, le reste des documents PDF, Word et Excel). Le référentiel d'images est une application tierce commerciale très coûteuse qui, franchement, comporte trop de frais généraux. J'ai juste besoin d'un système pour stocker et récupérer les images de documents.

J'envisage de transférer la création d'image directement dans une base de données SQL Server 2005. Les informations d'indexation sont très limitées - essentiellement 2 champs d'index. Il s’agit d’un système d’administration de polices d’assurance-vie. J’indexe donc les images avec un numéro de police et un numéro d’identification unique. Il existe d'autres valeurs d'index, mais elles sont stockées et gérées séparément des données d'image. Ces valeurs d’index me permettent de rechercher la valeur id unique pour la récupération d’images individuelles.

Le serveur de base de données est une boîte Windows 2003 à double cœur, avec des disques SAN hébergeant les fichiers de base de données. La taille actuelle du référentiel d'images est d'environ 650 Go. Je n'ai fait aucun test pour voir la taille de la base de données convertie. Je ne parle pas vraiment de la conception de la base de données - je travaille avec nos administrateurs de base de données sur cet aspect. Si cela change, je serai de retour: -)

Le système actuel à remplacer est évidemment une application middleware, mais c’est un système très lourd réparti sur 3 serveurs Windows. Si je vais dans cette voie, ce sera un système à serveur unique.

Mes principales préoccupations sont la scalabité et la performance, fortement orientées vers la performance. J'ai environ 100 utilisateurs, et la croissance de l'utilisation sera probablement lente pour les prochaines années. La plupart des utilisateurs sont principalement des utilisateurs lus - ils n'ajoutent pas d'images au système très souvent. Nous avons un service qui gère la numérisation et ajoute des images dans le référentiel. Nous avons également quelques autres applications qui reçoivent des documents (via ftp) et les insèrent dans le référentiel automatiquement au fur et à mesure de leur réception, soit des informations d'index complètes, soit sous forme de & "; Lots &"; qu'un utilisateur passe en revue et indexe.

La plupart (90% +) des documents / images sont très petits, < 100K, probablement & Lt; Je pense donc que le stockage des images dans le fichier de base de données sera le plus efficace au lieu d’obtenir SQL 2008 et d’utiliser un flux de fichiers.

Answer 1

Souvent, l’évolutivité et les performances sont finalement mariées les unes aux autres en ce sens que, dans six mois, la direction revient et dit & "La fonction Y de l’Application X est extrêmement lente, comment pouvons-nous l’accélérer? quot; Et souvent, la solution consiste à mettre à niveau la solution finale. Et s’agissant de la mise à niveau des back-ends, il est presque toujours moins coûteux de le faire évoluer que de le faire au niveau matériel.

Bref, je vous recommanderais de créer une application middleware qui gère spécifiquement les demandes entrantes de l'application utilisateur, puis les achemine vers la destination appropriée. Cela va suffisamment éloigner votre application utilisateur frontale de la solution de stockage dorsale pour que, lorsque l’évolutivité devienne un problème, seule la mise à jour de l’application middleware soit nécessaire.

Answer 2

C'est simple. Écrivez l'application sur une interface, utilisez un mécanisme d'usine pour fournir cette interface et implémentez-la comme vous le souhaitez.

Une fois que vous êtes satisfait de votre interface, l'application est (principalement) isolée de l'implémentation, qu'il s'agisse de parler directement à une base de données ou à un autre composant.

Réfléchissez un peu à la conception de votre interface, mais faites des bêtises stupides, & "C’est simple, ça marche ici, ça marche maintenant &"; les implémentations offrent un bon équilibre entre la mise à l'épreuve future du système sans nécessairement trop l'ingénierie.

Il est facile de dire que vous n’avez même pas besoin d’une interface à ce stade, mais simplement d’une simple classe que vous instanciez. Mais si votre contrat est bien défini (c’est-à-dire la signature de l’interface ou de la classe), c’est ce qui vous protège du changement (tel que la reprise de l’implémentation dorsale). Vous pouvez toujours remplacer la classe par une interface ultérieurement si vous le jugez nécessaire.

En ce qui concerne l'évolutivité, testez-la. Vous saurez alors non seulement si vous devez peut-être adapter, mais peut-être aussi quand. & "; fonctionne très bien pour 100 utilisateurs, problématique pour 200. Si nous atteignons 150, nous voudrons peut-être envisager de jeter un autre coup d’œil au back-end, mais c’est bon pour le moment. &";

C’est une diligence raisonnable et une tactique de conception responsable, à mon humble avis.

Answer 3

Je suis d'accord avec gabriel1836. Cependant, un avantage supplémentaire serait que, pendant un certain temps, vous pourriez utiliser un système hybride, car vous n'allez pas convertir 14 millions de documents de votre système propriétaire en un système développé du jour au lendemain.

De plus, je vous encourage fortement à stocker les documents en dehors d'une base de données. Stockez-les sur un système de fichiers (local, SAN, NAS, peu importe) et stockez les pointeurs vers les documents de la base de données.

J'aimerais savoir quel système de gestion de documents vous utilisez maintenant.

Ne sous-estimez pas non plus l'effort de remplacement de la capture (numérisation et importation) fournie par le système propriétaire.