컬렉션으로의 LINQ to SQL/LINQ 성능

Question

SQL로 채워진 컬렉션에 LINQ를 처리하는 두 가지 옵션이 있습니다 (Oracle 공급자를 사용하므로 LINQ없이 ORM이 없음).

1. 는 하나 개의 큰 SQL 쿼리를 수행 콜렉션의 일종으로 결과를 덤프하고 데이터베이스에 하나의 큰 무승부가 있으므로, 컬렉션에 LINQ 쿼리를 수행하지만, 그 이후별로 둔화.

2. 작은 SQL 쿼리를 수행하고 많은 작은 컬렉션으로 결과를 덤프하고 그 결과에 대한 LINQ 쿼리를 수행하므로 데이터베이스의 그리기가 줄어들지 만 응용 프로그램 전체에서 일관된 속도 저하가 발생합니다.

누구든지 이에 대해 의견이 있으십니까?

Answer 1

두 가지 방법에는 큰 차이가 있습니다. 데이터가 필요할 때마다 데이터베이스에 쿼리하면 최신 데이터를 얻게되는 반면, 모든 데이터를 읽고 다시 사용하면 모든 것을 다시 읽을 때까지 최신 변경 내용을 볼 수 없습니다. 두 시스템 모두 장점과 단점이 있지만이 차이점을 알아야합니다.

성능 차이 - 로컬 데이터의 LINQ to Objects가 항상 데이터베이스 쿼리보다 빠르다고 가정하지 마십시오. 데이터베이스는 다양한 쿼리 유형에 대해 매우 잘 최적화되어 있으며 인덱스를 활용할 수 있습니다. LINQ to Object 쿼리는 일반적으로 전체 데이터 집합을 반복합니다. 따라서 데이터를 로컬로 가져가도 데이터를 직접 인덱싱하지 않으면 일부 쿼리가 작업을 수행하는 데 필요한 데이터베이스보다 실제로 느려질 수 있습니다.

인덱스를 사용할 수없는 쿼리의 경우에도 데이터베이스는 여전히 순진한 LINQ to Objects 접근 방식을 이길 수 있습니다. 데이터베이스에는 LINQ to Objects에서 구현되지 않은 몇 가지 고급 알고리즘이 있습니다. 예를 들어 일반적인 쿼리는 필터를 사용하여 일부 기준으로 정렬 된 상위 100 개 항목을 가져 오는 것입니다. OrderBy(x => x.Foo).Take(100)은 먼저 O (n log n) 정렬을 수행 한 다음 처음 100 개의 요소를 취하고 나머지는 버리기 때문에 충분한 크기의 결과 집합에 사용할 수있는 인덱스가 없어도 데이터베이스가 LINQ보다 개체 성능이 뛰어날 수 있습니다. SQL Server 팀은 이러한 유형의 쿼리가 일반적이므로 O (n) 시간에이 작업을 수행 할 수있는 특별한 최적화 호출 TOP N SORT을 추가했습니다. 오라클과 유사한 최적화가 있다고 생각합니다. 필자는 LINQ to SQL 대 LINQ to Objects 쿼리의 성능 측정을 포함하여이 시점에 대해 더 자세히 설명하는 another answer을 작성했습니다.