EF Core vs redb Pro: 54 tablo ve 31 Include'a karşı tek sınıf
redb.core ekibi, aynı iş nesnesini (adresler, kişiler, sözlükler içeren bir Employee) EF Core ile 54 tabloya ve 31 Include zincirine karşı kendi ORM'lerinde tek sınıfla karşılaştırıyor. 100 bin nesnelik veri setinde EF Core bir çalışanı 62 SQL sorgusu ve yaklaşık 2 saniyede okurken, redb Pro 9 sorgu ve 131 ms'de tamamlıyor. Yazı, farkın motordan değil grafı kaç tablodan topladığınızdan kaynaklandığını benchmark tablolarıyla gösteriyor.
Kilit noktalar
- Aynı iş nesnesi EF Core'da 54 tabloya, 59 foreign key'e ve 31 Include zincirine dönüşüyor
- AsSplitQuery olmadan bağımsız koleksiyonların JOIN'i satır sayısını çarpıyor (cartesian explosion)
- redb 4.3.0'daki "akış" formu alanları GROUP BY yerine LEFT JOIN ile birleştiriyor
- 4.4.0 ile gelen structure-value-object indeks sırası seçici filtrelerde ve sıralı sayfalarda büyük kazanç sağlıyor
- SQL Server'da IN listesinin STRING_SPLIT yerine ayrı parametrelerle gönderilmesi tek başına 2-5 kat hız kazandırdı
- Ölçümler satıcının kendi kütüphanesi lehine; kendi şemanızda doğrulamadan karar vermeyin
Yazı, normal formda tutulan aynı modelin EF Core tarafında 54 tablo ve 59 foreign key'e ayrıldığını gösteriyor. Grafiği tek seferde okumak için 31 Include ve zorunlu AsSplitQuery gerekiyor; aksi halde bağımsız koleksiyonların JOIN'i satırları çarpıyor. redb ise nesneleri iki tabloda, her alanı bir satır olarak sakladığı için sorgu sayısı alan ve koleksiyon sayısına değil, referans derinliğine bağlı kalıyor.
Sürüm 4.3.0 ile gelen "akış" sorgu formu, alanları GROUP BY ile tek satıra katlamak yerine LEFT JOIN'lerle birleştiriyor; 4.4.0'daki "structure, value, object" sıralı indeksler ise seçici filtreleri ve sıralı sayfaları hızlandırıyor. Yazarın kendi ölçümlerinde PostgreSQL'de 2-8, SQL Server'da 4-25 kat kazanç var; SQLite'ta sonucu belirleyen şeyin memory-mapped dosya ve indeksler olduğu belirtiliyor. Karşılaştırma taraflı olduğu için rakamları kendi şemanızda doğrulamanız gerekiyor.
Gerçek dünyada kullanımı
- Adres, kişi ve sözlük koleksiyonları içeren müşteri/çalışan kayıtlarını tek ekranda gösteren CRM benzeri uygulamalar
- Derin nesne graflarını okuyan raporlama ve arama ekranlarında EF Core Include maliyetini azaltmak
- Çok kiracılı bir SaaS'ta büyük tablolarda filtrelenmiş, sayfalanmış listelerin yanıt süresini düşürmek
- EF Core sorgularını kendi veri setinizde benchmark ederek indeks ve sorgu formu kararlarını ölçümle vermek
Neden önemli
EF Core'da graf okuma maliyeti büyük ölçüde tablo ve koleksiyon sayısıyla büyür; makale, Include sayısını ve indeks sırasını ölçümle yönetmenin bir ORM değiştirmekten daha ucuz olabileceğini gösteriyor.