Entité, traitant avec un grand nombre d'enregistrements (> 35 mlns)

Mon expérience avec EF4.1, code d'abord: si vous n'avez besoin que de lire les enregistrements (c'est-à-dire que vous ne les écrirez pas), vous obtiendrez une performance boost en tournant le suivi des modifications pour votre contexte:

yourDbContext.ChangeTracker.DetectChanges();

à mon travail, je suis confronté à une situation similaire. Nous avons eu une base de données avec de nombreuses tables et la plupart d'entre elles contenaient environ 7 à 10 millions d'enregistrements chacun. Nous avons utilisé l'établissement d'entité pour afficher les données, mais la page semblait afficher très lente (comme 90 à 100 secondes). Même le tri sur la grille a pris du temps. On m'a donné la tâche de voir si cela pourrait être optimisé ou non. et bien après le profilage (profileur des fourmis), j'ai pu l'optimiser (moins de 7 secondes).

La réponse est donc oui, l'entité framework peut gérer des charges d'enregistrements (en millions), mais certains soins doivent être pris

1. Comprenez cet appel à la base de données effectuée uniquement lorsque les enregistrements sont requis. Toutes les opérations sont simplement utilisées pour rendre la requête (SQL) afin d'essayer de chercher uniquement une donnée de données plutôt que de demander un grand nombre d'enregistrements. Coupez la taille de la récupération autant que possible
2. Oui, vous ne devez pas utiliser les procédures stockées et les importer dans votre modèle et avoir des importations de fonctions pour eux. Vous pouvez également les appeler directement exécutstorecommand (), exécutantestorequery <> (). Sames va pour les fonctions et les points de vue, mais EF a une manière vraiment étrange d'appeler des fonctions "Sélectionnez DBO.BLAH (@ID)".
3. EF fonctionne plus lentement lorsqu'il doit remplir une entité avec une hiérarchie profonde. Soyez extrêmement prudent avec des entités avec une hiérarchie profonde.
4. Parfois, lorsque vous demandez des enregistrements et que vous n'êtes pas obligé de les modifier, vous devez indiquer à EF de ne pas regarder les modifications de la propriété (autodétchanges). Ainsi, la récupération d'enregistrement est beaucoup plus rapide
5. L'indexation de la base de données est bonne mais en cas d'EF, il devient très important. Les colonnes que vous utilisez pour récupération et tri doivent être correctement indexées.
6. Lorsque vous modèle est grand, le concepteur modèle VS2010 / VS2012 devient réel fou. Alors casser votre modèle dans des modèles de taille moyenne. Il existe une limitation que les entités provenant de différents modèles ne peuvent pas être partagées, même s'ils peuvent être dirigés vers la même table dans la base de données.
7. Lorsque vous devez apporter des modifications dans la même entité à différents endroits, essayez d'utiliser la même entité en le passant et envoyez les modifications uniquement une fois que chacun récupérant une pièce fraîche, apporte des changements et le stocke (gain de performance réel Conseil).
8. Lorsque vous avez besoin d'informations dans une ou deux colonnes, essayez de ne pas récupérer la totalité de l'entité. Vous pouvez soit exécuter votre SQL directement ou avoir une mini-entité quelque chose. Vous devrez peut-être mettre en cache des données fréquemment utilisées dans votre application également.
9. Les transactions sont lentes. Soyez prudent avec eux.

   Si vous gardez ces choses à l'esprit EF, EF devrait donner des performances presque similaires comme une nature simple ado.net sinon la même.

Le moment où j'entends des déclarations comme: "La société est normalisée sur EF4 ou EF5, ou quoi que ce soit" ceci envoie des frissons froids dans la colonne vertébrale.

C'est l'équivalent d'une location de voiture disant "Nous avons normalisé sur un modèle de voiture unique pour toute notre flotte".

ou un charpentier disant "J'ai normalisé les ciseaux comme toute ma boîte à outils. Je n'aurai pas de scies, d'exercices, etc."

Il y a quelque chose appelé le bon outil pour le bon travail Cette déclaration ne fait que souligner que la personne chargée de la prise de décisions clés d'architecture de logiciels n'a aucune idée de l'architecture logicielle.

Si vous avez affaire à plus de 100 000 enregistrements et que les DataModels sont complexes (c'est-à-dire non trivial), peut-être que EF6 n'est pas la meilleure option. EF6 est basé sur les concepts de réflexion dynamique et présente des modèles de conception similaires à l'enregistrement actif du projet Castle Project

Avez-vous besoin de charger tous les enregistrements de 100 000 en mémoire et effectuez des opérations sur ces? Si oui, demandez-vous que vous avez vraiment besoin de le faire et pourquoi n'exécuterait-il pas une procédure stockée dans les enregistrements de 100 000 à la même chose. Faites une analyse et voyez quel est le modèle d'utilisation réelle des données. Peut-être que l'utilisateur effectue une recherche qui renvoie 100 000 enregistrements, mais ils ne naviguent que dans le premier 200. Exemple de recherche de Google, à peine quiconque passe au-delà de la page 3 des millions de résultats de recherche.

Si la réponse est toujours oui, vous devez charger tous les enregistrements de 100 000 en mémoire et effectuer des opérations. Ensuite, peut-être que vous devez considérer quelque chose d'autre comme un cache d'écriture construit sur mesure avec des objets de poids léger. Peut-être que des pointeurs d'objet dynamiques de chargement paresseux pour des objets imbriqués. etc ... une instance où j'utilise quelque chose comme ceci est de gros catalogues de produits pour les sites de commerce électronique où de très grand nombre de recherches sont exécutées contre le catalogue. Pourquoi doit-il fournir un comportement personnalisé tel que la recherche de sortie précoce et la recherche générique de GRANDGEG à l'aide de RegEx pré-compilés ou d'index de hashtable personnalisés dans le catalogue de produits.

Il n'y a pas de taille unique pour toutes les réponses à cette question. Tout dépend des scénarios d'utilisation des données et de la manière dont l'application fonctionne avec les données. Considérer Gorilla vs requin qui gagnerait? Tout dépend de l'environnement et du contexte.

Peut-être que EF6 est parfait pour une pièce qui bénéficierait d'une réflexion dynamique, tandis que Nettiers est meilleur pour un autre qui nécessite une réflexion statique et un orj extensible. Tandis que le niveau de niveau bas est peut-être préférable pour des pièces extrêmes de haute performance.