Rechercher des informations sur la création de grands systèmes d'entreprise

Question

Comment organisez-vous la couche de base de données, la logique métier et l'API multiplate-forme de votre système de gestion de l'information, si le téléchargement et le traitement de 500 000 enregistrements de données au cours d'une session sont des opérations normales (C # .NET 3.5 + MS SQL 2005)?

Je suis particulièrement intéressé par les modèles de radiomessagerie éprouvés en production qui se comportent bien avec la simultanéité, l'évolutivité et la fiabilité.

Quelqu'un at-il des idées, dans quelle direction creuser?

• Projets Open Source (ne vous souciez pas de la langue ni de la plate-forme, tant que ce n'est pas Ook)
• livres
• articles
• Mots clés Google
• forums ou groupes de discussion

Toute aide serait grandement appréciée!

Mise à jour:

• pagination simple (c'est-à-dire: numéro à SQL 2005) ne fonctionne pas, car il existe y a beaucoup de changements simultanés à la base de données. L'élément supprimé ou inséré entre les demandes de page rend automatiquement l'index de page actuel non valide.

Answer 1

Fait l'implémentation. On m'a informé récemment que l'un des téléchargements concernait environ 2148849 enregistrements. Tiers a réussi à gérer quelques connexions rompues et des dizaines d’impasses au niveau de la base de données au cours de ce téléchargement.

Si quelqu'un d'autre a besoin d'informations:

• page du produit
• Action de gestion des exceptions Politiques

Answer 2

C’est un bon livre pour commencer:

Modèles d'architecture d'application d'entreprise de Martin Fowler

Answer 3

En ce qui concerne l'optimisation de la base de données pour d'énormes quantités de données, vous bénéficierez probablement de l'utilisation de & # 8220; BigTable & # 8221; technique. J'ai trouvé l'article ici

Pour la pagination dans MS SQL 2005, vous voudrez obtenir plus d’informations sur l’utilisation de la fonction ROW_NUMBER. Voici un exemple simple , vous & # 8217; J'en trouverai des tonnes à l'aide de Google (mots-clés: ROW_NUMBER paging SQL 2005). Ne creusez pas trop si & # 8211; il n'y a pas de magie dans la mise en œuvre, mais dans comment allez-vous utiliser / présenter la pagination elle-même. La recherche Google en est un bon exemple.

Remarque: nous avons constaté que la prise en charge de la pagination native du framework NHibernate n'était pas suffisante pour notre solution.

De plus, vous serez probablement intéressé par la création d'un index FULLTEXT et l'utilisation de la recherche en texte intégral. Voici un article MSDN sur la création d'index en texte intégral et quelques informations sur la recherche en texte intégral.

Bonne chance.

Answer 4

dandikas,

merci d’avoir mentionné la dénormalisation partielle. Oui, c’est l’approche que j’envisage pour améliorer les performances de certaines requêtes.

Malheureusement, NHibernate ORM ne fait pas partie de la solution, en raison de la surcharge de performances qu’il ajoute. Idem pour la pagination SQL - cela ne fonctionne pas dans le scénario de nombreuses modifications simultanées (comme détecté par le tests de stress )

Answer 5

Je m'occupe d'un entrepôt de données d'entreprise qui télécharge des flux de centaines de milliers d'enregistrements.
Je ne suis pas sûr que ce soit votre scénario, mais nous:

• Recevez les fichiers texte que nous téléchargeons dans une base de données Sybase.
• Formatez les différents flux à l'aide de awk afin qu'ils soient dans un format commun.
• Chargez-les dans une table intermédiaire dénormalisée à l'aide de bcp.
• Exécution de procédures stockées pour renseigner la structure de base de données normalisée.
• Supprimer de la table intermédiaire dénormalisée.

Cela fonctionne assez bien, mais nous forçons nos téléchargements à être séquentiels. C'est à dire. quand les flux arrivent, ils entrent dans une file d'attente et nous traitons le flux en tête de file avant de regarder le reste.

Est-ce que cela est utile?

Answer 6

  

Idem avec la pagination SQL - cela ne fonctionne pas dans le cas de nombreux   éditions simultanées (comme détecté par le test de stress)

Comme je l’ai déjà mentionné, la mise en œuvre de la pagination n’est pas magique, soit vous utilisez ROW_NUMBER, soit une table temporaire. La magie consiste à évaluer quel est votre scénario d'utilisation le plus courant dans le monde réel. L'utilisation d'une table temporaire avec le suivi des utilisateurs peut aider un peu à surmonter le scénario de modifications simultanées. Même si je sens que vous gagnerez plus en répondant à des questions:

1. Combien de temps l'utilisateur reste sur une page avant de passer à une autre?
2. À quelle fréquence l'utilisateur passe-t-il de la première à une autre page?
3. Quel est le nombre de pages communes que cet utilisateur va parcourir?
4. À quel point il est crucial que certaines informations changent lorsque l'utilisateur passe d'une page à l'autre et inversement?
5. À quel point il est important de supprimer certaines informations alors que l'utilisateur est sur la page qui les affiche?

Essayez de ne pas vous concentrer sur des questions telles que: & # 8220; Comment gérer tout scénario de modifications simultanées éventuelles lors de la pagination? & # 8221; avant de répondre aux questions ci-dessus, puis de ne gérer que les situations qui comptent vraiment.

Une autre note est l'interface utilisateur. Découvrez autant d’interfaces utilisateur de pagination que vous pouvez trouver, car il existe de bien meilleures solutions que les flèches droite et gauche, ou les numéros de page alignés. Certaines solutions permettent de masquer / de surmonter les scénarios de pagination techniquement impossibles à résoudre.

P.S. Si cette réponse est utile, je la combinerai avec la première.