conception .NET système de gestion des documents - des questions de performance

Question

je dois développer un système de gestion des documents .NET de base avec les spécifications suivantes:

1. Les données doivent être portable et autonome, donc je sérialiser les documents (les formats typiques incluent Word, PDF, Excel et Powerpoint) en données binaires. Je vais ensuite stocker les données binaires dans une base de données SQL Server 2005. Lorsqu'un utilisateur doit télécharger un document, le système désérialise les données binaires et le présente dans son format original.

2. La taille moyenne des lignes ne peut pas être supérieure à 200k.

3. Nous prévoyons qu'un maximum de 500 documents seront téléchargés mensuellement pour une période de trois ans.

4. Nous ne prévoyons pas d'aller toujours plus la taille de la base de données de plus de 6 Go

5. Nous avons cible maximum de 20.000 personnes qui pourraient accéder au système en même temps.

Ma question est: Comment la technologie ne robuste besoin d'être afin d'offrir de solides performances, éviter les temps d'arrêt du site, etc? Je suis un développeur débutant et je ne suis pas familier avec ce type d'architecture et de design.

Answer 1

Pour quelle raison avez-vous besoin de stocker les fichiers dans la base de données, au lieu de simplement stocker le chemin d'accès du document sur un serveur de fichiers ou un CDN? Cela réduirait considérablement la charge de votre serveur de base de données et vous offrirait des options plus souples pour le stockage de documents.

Si vous rencontrez des problèmes avec les fichiers déplacés/supprimés dans un système comme celui que je suggère, alors peut-être aussi envisager d'autres options, telles que:

• autorisations de verrouillage du système de fichiers sous-jacent à tout le monde, sauf le rôle de l'application est en cours d'exécution sous (option la plus facile)
• exécution d'un service d'arrière-plan qui écoute les changements aux dossiers, etc et met à jour la base de données en conséquence

en fin de compte, une solution de base de données ne peut être plus simple, mais Je w Ne sous-estimez pas la charge que vous pourriez avoir en stockant des fichiers volumineux pour des dizaines de milliers d'utilisateurs.

Answer 2

Ceci est plus qu'un simple système "de base". Donc, voici mes préoccupations dès le départ:

• 500 documents par mois pendant 3 ans semble qu'il pourrait bien dépasser 6 Go pour la taille de la base de données. Vous voudrez peut-être déterminer la taille maximale du document et voir si ce calcul tient le coup.
• 20 000 utilisateurs c'est beaucoup. Combien pouvez-vous attendre à la fois? Si c'est plus de 100 utilisateurs simultanés, je commencerais à enquêter sur les batteries de serveurs/web fermes pour pouvoir gérer la charge
• juste un choix de nit, mais vous ne serez pas "sérialiser" au sens .NET "sérialisable" .Vous aurez juste stocker les octets de documents bruts dans le DB
• si vous avez besoin de haute disponibilité, vous aurez besoin de regarder la réplication DB à une autre instance DB au cas où votre DB serveur tombe en panne

Enfin. Je dois croire qu'il existe des systèmes prêts à l'emploi qui font ce que vous voulez, et qui incluent également des fonctionnalités plus avancées telles que l'accès par permission et la révision de documents.

Mike

Answer 3

Une partie importante de la programmation est de savoir quand vous êtes sur votre tête. Si le CTQ que vous avez posté est réel, en particulier l'exigence d'accès simultané, alors vous êtes dans un monde de mal. Même ceux d'entre nous qui ont passé beaucoup de temps dans les tranchées seront dans un monde de blessures avec ce genre d'exigence. J'aborder le problème avec l'état d'esprit suivant:

Je vais me tromper de plusieurs façons que je peux actuellement imaginer.

Sachant cela beaucoup, la plus simple que vous gardez cette architecture, plus il est probable à l'échelle. Cependant, la société pour laquelle je travaille est absolument massive et je doute même que nous ayons des systèmes qui ont exactement 20.000 utilisateurs simultanés. Alors ne mordez pas plus que vous ne pouvez mâcher.

Concevez votre architecture pour qu'elle soit simple et robuste (une tâche importante) et vous verrez qu'elle évoluera naturellement jusqu'à ce que vous ayez besoin d'appeler les gros canons.

Je peux suggérer que vous devriez au moins dépenser de l'argent sur l'accès à SQL Server 2008. Avec cette version, votre problème devrait être assez élémentaire pour les débutants. Utilisez le stockage FILESTREAM pour les fichiers. Aucune sérialisation nécessaire. Cela stockera les fichiers sur un système de fichiers NTFS et maximisera votre facilité de programmation, de maintenance et d'évolutivité.

Si pour une raison quelconque vous n'avez que SQL Server 2005, vous devrez faire face à BLOB s, ce qui n'est pas vraiment difficile, mais c'est plutôt compliqué. Je vous suggère de lire To BLOB or Not to BLOB de Microsoft Research pour prendre la décision si le stockage des données dans SQL Server 2005 est le meilleur choix pour vous. Si oui, il y a beaucoup d'articles détaillant comment mettre des fichiers dans SQL Server BLOB s. Sachez que c'est rarement la solution la plus efficace ou la plus évolutive.