EF Core vs redb: 54 tabloya karşı nesne grafiği ve Include
Yazarın kendi grafik veritabanı ORM'i redb Pro ile EF Core'u aynı Employee nesnesi üzerinden karşılaştırdığı ölçüm çalışması: EF Core tarafında 54 tablo, 59 foreign key ve 31 `Include` zinciri gerekiyor, redb tarafında tek bir sınıf yetiyor. Yazı, farkın motordan değil grafiği kaç tablodan geri birleştirdiğinizden kaynaklandığını ölçümlerle anlatıyor ve yeni sürümlerdeki sorgu biçimi ile index değişikliklerini paylaşıyor.
Kilit noktalar
- 54 tabloya ve 59 foreign key'e açılan tek bir iş nesnesini okumak EF Core'da 31 `Include` zinciri ve `AsSplitQuery()` gerektiriyor.
- 100k nesnelik örnek veride bir çalışanı tam okumak EF Core'da 62 sorgu / ~2 s, redb Pro'da 9 sorgu / 131 ms sürüyor.
- Büyük `Include` grafiklerinde maliyet satır sayısıyla değil şemanın genişliğiyle büyüyor; bağımsız koleksiyonlar bölünmüş sorgu olmadan satır çarpımına yol açıyor.
- Değer index'lerinin "structure, value, object" sırasına alınması PostgreSQL'de filtrelenmiş bir sayfayı 229 ms'den 2 ms'ye indiriyor.
- Yazar kendi ürününü ölçtüğü için sayılar referans alınırken metodoloji ve donanım koşullarıyla birlikte okunmalı.
Yazı tek bir iş nesnesini ölçüyor: adresler, iletişim bilgileri, sözlükler ve başka nesnelere referanslar içeren bir çalışan kaydı. EF Core tarafında bu model normal forma açıldığında 54 tablo ve 59 foreign key çıkıyor; grafiği okumak 31 `Include` zinciri ve `AsSplitQuery()` gerektiriyor. 100 bin nesnelik veri setinde bir çalışanı tam okumak EF Core'da 62 sorgu ve yaklaşık 2 saniye, redb Pro'da 9 sorgu ve 131 ms sürüyor.
Asıl ders index'lerde: değer index'leri "structure, object, value" sırasındayken "bu değere sahip hangi nesneler var" sorusu yanıtlanamıyor. 4.4.0 ile "structure, value, object" sırasına geçilmesi PostgreSQL'de filtrelenmiş bir sayfayı 229 ms'den 2 ms'ye indiriyor. Ölçümlerin yazarın kendi ürününü karşılaştırdığı bir çalışma olduğunu akılda tutmak gerekiyor.
Gerçek dünyada kullanımı
- ERP veya seyahat yönetimi gibi tek bir kaydın onlarca alt tabloya yayıldığı domain modellerinde okuma maliyetini planlamak.
- `Include` zincirleri büyüyen mevcut bir EF Core `DbContext`'inde `AsSplitQuery()` kararlarını gözden geçirmek.
- PostgreSQL veya SQL Server üzerinde anahtar/değer biçiminde saklanan verilerde index kolon sırasını gerçek sorgu pattern'ine göre seçmek.
- Raporlama ve analitik için grafik verinin ilişkisel düz tablolara kopyasını çıkarma ihtiyacını değerlendirmek.
Neden önemli
EF Core'da ilişki grafiği genişledikçe okuma maliyeti veri hacmiyle değil modelin şekliyle artıyor; bu yüzden `Include` tasarımı ve sorgu parçalama stratejisi mimari bir karar haline geliyor.