Dans quelle mesure LINQ est-il évolutif ?[fermé]
https://stackoverflow.com/questions/214233
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Des conversations récentes avec des collègues ont donné lieu à des points de vue variés sur cette question.Qu’en dites-vous, membres du SO ?
Je sais, même le concept d'évolutivité peut être abordé de tant de manières et de contextes différents, mais cela faisait partie de la discussion lorsque cela a été évoqué.Tout le monde semblait avoir une vision différente de ce que signifie réellement l’évolutivité.Je suis également curieux de voir les différentes prises ici.En fait, j'ai posté un question juste pour ce concept.
La solution
Je suppose que la meilleure méthode de vérification consiste à écrire des points de repère, mais à mon avis, LINQ offre la possibilité d'optimisations, contrairement à l'écriture manuelle de code similaire. Je ne sais pas à quel point il tire parti de ceux-là pour le moment.
LINQ vous permet d’exprimer ce que vous voulez, pas comment le générer. Un avantage évident est que LINQ est automatiquement parallélisable (voir PLINQ ).
Un autre avantage de LINQ est qu’il est paresseux. Vous pouvez donc effectuer des calculs en puisant dans la collection au besoin. Vous pouvez coder à la main un équivalent, mais il est peut-être beaucoup plus facile de comprendre correctement LINQ.
Autres conseils
Lors des tests que nous avons effectués, LINQ to objects (ForEach) était environ deux fois plus lente que la boucle foreach.
LINQ to SQL (base de données MS SQL) est presque 10x plus lent que la requête directe utilisant un lecteur de données, la plupart du temps créant du code SQL à partir de l'arborescence des expressions (vous serez donc lié au processeur et à la base de données). sera au ralenti) Pour éviter cela, vous devez utiliser des requêtes compilées.
Voir cette pour plus. La plupart des informations du message sont toujours valables avec .NET 3.5 SP1.
Cette question est un peu comme si vous demandiez & "A quel point les collections sont-elles évolutives? &";
Parlons simplement de LINQ aux objets. En règle générale, dans la mesure où la plupart des implémentations de IEnumerable<T> effectuent une itération sur chaque élément de la collection sous-jacente, LINQ a un grand potentiel d'échelle. Créez un List<Foo> qui contient dix millions d’articles et qui ressemble à ceci:
var list = from Foo f in fooList
where f.Value = "Bar"
select f;
va être lent. Mais ce n'est vraiment pas la faute de LINQ. Vous êtes celui qui lui a donné une liste de dix millions d'articles.
Vous gérez cela de la même manière que si LINQ n'existait pas: en construisant des dictionnaires et des listes triées, etc. qui vous aident à réduire l'espace de recherche.
LINQ peut améliorer l’évolutivité (en d’autres termes, faciliter l’accès à l’évolutivité) via l’exécution de requêtes différée. Vous pouvez remplacer une méthode naïve qui crée une liste, la filtre en une nouvelle liste, en une autre liste, etc., avec une série de requêtes LINQ:
var list1 = from Foo f in fooList where f.Value1 = "Bar" select f;
var list2 = from Foo f in list1 where f.Value2 = "Baz" select f;
var list3 = from Foo f in list2 where f.Value3 = "Bat" select f;
qui sont tous exécutés en un seul passage dans la collection sous-jacente lorsque (et si) il devient nécessaire de parcourir la liste finale. Encore une fois, ce n’est pas nouveau: si vous n’aviez pas LINQ, vous finiriez probablement par remplacer votre méthode naïve par une autre qui ferait la même chose. Mais LINQ le rend beaucoup plus facile.
À mon avis, LINQ est conçu pour simplifier les choses du point de vue du développement et non pour traiter l’évolutivité.
En réalité, utiliser LINQ facilite grandement les choses en masquant de nombreuses complications, ce qui pourrait conduire à une utilisation irresponsable des problèmes d’évolutivité.
Les exemples abondent dans d’autres réponses, mais pour citer les plus significatives:
-
Si vous interrogez une collection d'objets, vous ne pouvez pas ignorer sa taille. Peut-être que le faire dans le modèle, avec LINQ, sonnait bien quand il y avait quelques objets à interroger ... mais à mesure que la taille augmente, il devient évident que la requête doit se produire dans la base de données, pas dans le modèle.
-
Si vous générez automatiquement SQL avec LINQ, autant que je sache, vous ne pouvez pas donner à votre base de données d'indications sur la manière de compiler des requêtes, par exemple
WITH (NOLOCK). À mesure que la taille de votre table augmente, il est impératif de pouvoir résoudre ces problèmes. -
Semblable à ce qui précède, mais peut-être plus général: lorsque vous résolvez des problèmes d’évolutivité avec une base de données, vous devez contrôler ce que fait la base de données. Avoir un langage qui compile en SQL, qui est ensuite compilé à nouveau dans un plan d'exécution, supprime le contrôle de vos mains.
-
Que se passe-t-il si vous devez modifier votre schéma de base de données afin de le rendre plus évolutif et que votre code y soit fortement lié, car vous n'avez aucune procédure stockée?
-
Bien que cela paraisse simple, vous ne pouvez pas changer de fournisseur LINQ sans trop de peine: interroger SQL Server n'est pas la même chose que interroger un objet ou interroger XML. Le LINQ est très similaire cependant. Je m'attends à ce que certains de mes développeurs débutants se lancent dans une & "; Fête de LINQ &"; parce que c’est plus facile que d’apprendre à faire des choses avec l’évolutivité en tête.
En conclusion, je pense qu’il est possible d’écrire du code évolutif avec LINQ, mais seulement en l’utilisant avec soin. Il n'y a pas de outils tueurs, seulement du code .
.Cela dépend grandement du fournisseur LINQ que vous utilisez et de la manière dont vous l'utilisez.LINQ n'est probablement pas connu pour sa vitesse d'exécution incroyable, mais offre plutôt aux développeurs une productivité nettement meilleure.
Selon ce le lien même avec certains CTP Linq to SQL était déjà meilleur que l'utilisation de SQL direct dans certains cas.
Si vous êtes préoccupé par la vitesse et que vous utilisez beaucoup LINQ to object ici est un projet codeplex (je pense) pour un fournisseur qui peut vous offrir des améliorations de performances 1 000 fois supérieures.
Votre question sur l’évolutivité dépend à certains égards de votre utilisation de LINQ. Dans les applications métier, vous ne trouverez pas beaucoup de commandes SQL en cours d'exécution - elles sont lentes et doivent être compilées dans le SGBD. Au lieu de cela, vous verrez beaucoup d'appels de procédures stockées. Celles-ci seront légèrement plus rapides dans LINQ.
N'oubliez pas que LINQ to SQL, etc., est basé sur TOP of ADO.NET. Il ne s'agit pas d'une méthodologie complètement différente ni de quoi que ce soit. Bien sûr, LINQ to XML utilisera différentes API sous les couvertures. Cela ressemblera beaucoup à un compilateur - il y a toujours certaines optimisations que les humains peuvent faire, ce qui pourrait être plus rapide, mais la plupart du temps, ces API seront capables de générer du code plus rapide et moins bogué que le code que vous écrivez vous-même.
En termes de dimensionnement, vous pouvez toujours placer LINQ derrière un service Web si vous souhaitez distribuer un peu vos données ou utiliser la réplication SQL Server. Il ne devrait pas être moins évolutif qu’ADO.NET.
L’évolutivité et les performances sont deux choses différentes mais liées. Si vous souhaitez mesurer les performances, vous devez savoir combien d'utilisateurs (par exemple) peuvent être pris en charge avec un seul boîtier. Lorsque vous mesurez l'évolutivité, vous ajoutez une autre boîte et vous voyez si vous pouvez supporter le double du montant initial. Il est peu probable, et vous n'augmenterez peut-être que 75% de votre puissance de traitement, tandis que la suivante n'ajoutera que 50% de l'unité d'origine, ce qui réduira à zéro assez rapidement. Peu importe le nombre de boîtes que vous ajoutez à ce rythme, vous avez la chance de doubler le nombre d'utilisateurs pris en charge. C'est l'évolutivité.
La manière dont votre module Linq évolue dépend probablement davantage de la base de données, de la puissance de la machine, de la conception de la base de données et de la conception de votre application.
Vous voyez souvent des micro-points de référence qui sont supposés révéler quelque chose de concluant, mais ils ne le font jamais, car ils ne sont que des trous pour le problème.
Vous pouvez tirer le bon vieil exemple 20/80 ici. Il s’agit probablement de 20% pour l’outil et de 80% pour tous les types de biens meubles corporels constituant votre demande.
Linq est évolutif à bien des égards.
L’un des aspects est l’implémentation de la spécification derrière linq, qui permet d’interpréter Expression comme s’il était hors processus, dans un langage différent (Linq2Sql, Linq2Hibernate) ou dans un environnement informatique réparti tel qu’un cluster à réduction de carte ( DryadLINQ )
Un autre aspect est la sémantique que linq fournit au langage. Vous pouvez parcourir des milliards d’objets sans remplir la collection en mémoire si votre fournisseur prend en charge le chargement différé ou si vous pouvez paralyser ou optimiser la requête (PLINQ ou i4o).
