EF Core 11, AsSplitQuery 쿼리에서 불필요한 reference navigation join 제거해 성능 개선
- EF Core 11부터 AsSplitQuery 사용 시 collection 쿼리에서 불필요한 reference navigation의 JOIN을 자동으로 pruning함
- 기존 EF Core 10까지는 Post 컬렉션을 가져오는 쿼리에도 관련 없는 BlogType 테이블 JOIN과 ORDER BY 컬럼이 딸려 나와 reference navigation이 5개면 5개 JOIN이 매 collection 쿼리마다 붙었음
- 벤치마크 결과 blog 5000개, post 25000개 기준 .NET 10에서 68.53ms, 30.15MB 소요였던 것이 .NET 11에서는 62.07ms, 30.15MB로 줄어듦(메모리 할당도 33.35MB에서 30.15MB로 감소)
- 해당 이슈는 dotnet/efcore GitHub 이슈 #29182에서 제기됐고 EF Core 11 preview 3부터 반영됨
- 작성자는 .NET 10과 11 두 변수를 동시에 바꿔 측정했다고 밝혀 개선 효과가 EF Core 11만의 것인지 완전히 확정하지는 않았다고 언급함
Hacker News opinions
EF 11에서 진짜 개선은 split query에서 reference nav join 빼버린 거임, AsSplitQuery 나온 이후로 계속 쓸데없는 join이었음
AsSplitQuery가 왜 단일 라운드트립 멀티조인보다 빠를 수 있는지 이해 안 됨, dup은 그냥 포인터 문제 아니냐, 누가 설명 좀
네트워크 상에서는 진짜 bit-for-bit 중복임, 쿼리 결과가 단일 테이블로 직렬화되니까 중복 데이터가 그대로 전송됨
customer 하나에 order 100개 include하면 조인 결과가 100줄 나오고 각 줄마다 customer 데이터가 반복됨, include 두 개면 곱으로 늘어남, 이게 Cartesian explosion이라는 이름 붙은 문제임
EF한테 필요한 건 postgresql의 array_agg를 Include할 때 쓸 수 있게 지원하는 거임
hasura나 postgraphile이 graphql에서 비슷한 거 함, 다만 필터링에 쓰면 최적화가 깨짐
EF Core도 Dapper처럼 raw SQL을 1급 지원했으면 좋겠음
Database.SqlQuery랑 ExecuteSql 있잖아, 이미 지원함
표준 SQL이 nested data 다루는 깔끔한 방법이 없다는 게 이상함, array_agg 정도는 표준화됐어야 함
그거 찾는거 아니야? SQL 표준에 있는 postgresql property graph 기능 말하는거임
모든 언어에 EF Core나 DLINQ 같은 게 필요함