¿Qué tan rápido es LINQ?

Question

Necesito manipular 100,000 - 200,000 registros.
Estoy pensando en usar LINQ (en SQL) para hacer esto.
Sé por experiencia que el filtrado de dataviews es muy lento.
Entonces, ¿qué tan rápido es LINQ?

¿Puede decirme sus experiencias y si vale la pena usarlas, o sería mejor utilizar procedimientos almacenados SQL (pesados ​​y menos flexibles)?

Dentro de los miles de registros que necesito para encontrar grupos de datos y luego procesarlos, cada grupo tiene aproximadamente 50 registros.

Answer 1

LINQ to SQL traduce su expresión de consulta en T-SQL, por lo que el rendimiento de su consulta debería ser exactamente el mismo que si enviara esa consulta SQL a través de ADO.NET. Supongo que hay un poco de sobrecarga para convertir el árbol de expresiones para su consulta en el T-SQL equivalente, pero mi experiencia es que esto es pequeño en comparación con el tiempo de consulta real.

Por supuesto, puede averiguar exactamente qué se genera T-SQL y, por lo tanto, asegúrese de tener buenos índices de respaldo.

La principal diferencia con DataViews es que LINQ to SQL no trae todos los datos a la memoria y los filtra allí. Más bien hace que la base de datos haga lo que es bueno y solo trae los datos coincidentes a la memoria.

Answer 2

Normalmente, la manipulación de tantos registros debe realizarse lo más cerca posible de la base de datos. Si fuera mi tarea, buscaría hacerlo en procs almacenados. Eso yo personalmente. Linq es otra capa de abstracción además del acceso a datos y, aunque funciona bien para necesidades "normales", es decir, unos cientos de entidades enviadas a la interfaz de usuario no deberían considerarse como un reemplazo para las operaciones de tipo depósito de datos.

Answer 3

Depende de lo que trates de hacer. LINQ ha sido muy rápido para mí para extraer datos de la base de datos, pero LINQ-to-SQL traduce directamente su solicitud a SQL para ejecutarlo. Sin embargo, hay veces que he encontrado que usar procedimientos almacenados es mejor en algunas circunstancias.

Por ejemplo, tengo algunos datos que necesito consultar que involucran varias tablas y claves bastante intensas. Con LINQ, y la relativa inflexibilidad de LINQ para personalizar las consultas, estas consultas tomarían varios minutos. Ajustando manualmente el SQL (es decir, colocando argumentos de tipo 'DONDE' en JOIN para minimizar la intensidad de datos de JOIN), pude mejorar drásticamente el rendimiento.

Mi consejo, utilice LINQ siempre que pueda, pero no dude en seguir la ruta del Procedimiento almacenado si determina que el SQL generado por LINQ es simplemente demasiado lento, y el SQL se puede ajustar manualmente para lograr Que necesitas.

Answer 4

Tiene que ser más específico con lo que quiere decir manipular los registros. Si los cambios no son 100% individuales para cada registro y se pueden establecer en conjunto, lo más probable es que sea mejor hacer los cambios en T-SQL en el lado db (procs almacenados). En otras palabras, evite extraer grandes cantidades de datos a través de la red y/o los límites del proceso si es posible.

Answer 5

¿Cuánto dura un trozo de cuerda? Qué tan rápido es LInq a SQL. Depende de como lo uses.

"filtrado de dataviews es muy lento" porque en este modelo recuperas todos los registros y luego filtras en el cliente. Pero Linq to SQL no funciona así a menos que lo abuse.

Una consulta Linq solo se evalúa en el último minuto posible que tiene que ser. De modo que puede agregar restricciones de "dónde" a una consulta antes de que se evalúe. Toda la expresión, incluidos los filtros, se ejecutará en la base de datos, como debería.

Stackoverflow utiliza Linq, y no es una base de datos pequeña.

Algunos recomendarán procs almacenados para acceder a su base de datos a través de SQL o ORMS. Esto ha sido debatido en otras preguntas. Por ejemplo, here y here

Mi opinión es que para algunas cosas, querrá un DBA profesional para diseñar un proceso almacenado óptimo. A continuación, puede acceder a esto desde Linq si lo desea. Sin embargo, el 80% o más de los métodos de acceso a la base de datos no serán críticos para el rendimiento, y los procesos almacenados pueden suponer un exceso de tiempo para estos.

Para las actualizaciones, las operaciones del lado del servidor basadas en el conjunto en un proceso almacenado o sql con una "actualización ... donde ..." serán mucho más rápidas que utilizando múltiples recorridos de ida y vuelta para leer un registro, escribir un registro, repita.

Answer 6

me parece que las consultas generadas por LINQ son buenas. hay algunas mejores prácticas implementadas en consultas de linq, como por ejemplo, el nombre de la tabla de prefijos del propietario, evitar (*), etc. cuando las consultas son complejas (más que una simple combinación) encontré que linq siempre encontraba una buena solución, y mi solución nunca fue mejor (por lo que mi analista de SQL dice).

Entonces la pregunta es: ¿es mejor la consulta directa ... o envolver la consulta en el proceso almacenado? el proceso almacenado debería ser mejor, porque el plan de ejecución está almacenado. pero, de hecho, cuando seleccionas un proveedor de servidor .net sql seleccionado, llamas a un procedimiento almacenado especial, donde el primer parámetro es tu texto de consulta. entonces el plan de ejecución se almacena en caché de todos modos.

Si en su tienda hace más de 1 seleccionar, un shuold almacenado será mejor.

Answer 7

Vale la pena tener en cuenta que LINQ to SQL primero recupera el objeto de la base de datos, luego aplica cambios de propiedad a los objetos y llama a SubmitChanges para persistirlos y cada fila/objeto emite la declaración de actualización necesaria.

Para las actualizaciones masivas esto no es tan eficiente como enviar una sola declaración de actualización que se aplica a un lote completo de filas a la vez.