Django'nun ORM katmanı, veritabanı sorgularını otomatik olarak nasıl optimize eder?

08 Eki 02:16

Geçen sene bir e‑ticaret projesinde sipariş‑müşteri ilişkisini modellerken, admin panelinde listeleme yaptığımda bir anda 500 + SQL sorgusu çıktığını gördüm, valla o an panikledim. Sorunu araştırınca ORM’in default lazy loading’i yüzünden her satırda `order.customer` çağrısı ayrı bir SELECT atıyormuş. Bunun yerine `Order.objects.select_related('customer')` ile tek bir JOIN yapıp aynı anda çektiğimizde sorgu sayısı 1’e indi, sayfa 2‑3 kat daha hızlı yüklendi. Ancak aynı projede ürün‑etiket many‑to‑many ilişkisini aynı yöntemle çözmeye çalıştığımda select_related işe yaramadı; o yüzden `prefetch_related('tags')` kullanıp ayrı bir sorgu ile etiket setlerini önceden cache’ledik ve yine N+1 probleminden kurtulduk. Bence sık yapılan hata, hangi ilişki tipinde hangi yöntemi uygulayacağımızı karıştırmak; many‑to‑many ve ters foreign‑key’lerde select_related işe yaramaz, prefetch gerekir. Ayrıca `prefetch_related`’i gereksiz yere tüm ilişkilerde kullanmak da veri çekme miktarını şişiriyor, sadece ihtiyacınız olan alanları (`only`, `defer`) sınırlandırın. Migration sırasında otomatik oluşturulan indeksleri ve `RunSQL` ile eklediğiniz custom sorguları gözden kaçırmak da performansı etkileyebilir; migration sonrası `EXPLAIN ANALYZE` ile sorgu planlarını kontrol edip eksik indeksleri eklemek iyi bir alışkanlık. Kısacası, ilişkilerin yönünü ve tipini iyi analiz edip uygun eager loading metodunu seçmek, sıkıntıyı çözmenin en pratik yolu.

08 Eki 02:39

Django’nun ORM’i aslında sorgu planını olabildiğince “temiz” tutmak için bir dizi akıllı kural üzerine kurulmuş. Varsayılan davranışı lazy loading, yani bir ilişkili nesneye ilk kez erişildiğinde o nesneyi ayrı bir SELECT ile çekmek. Bu, tek bir obje üzerinden dolaşırken çok rahat ama döngü içinde (ör. `for user in users: print(user.profile.bio)`) çalıştırılırsa N+1 sorgu problemi doğurur. N+1, N tane ana sorguya ek olarak N tane ekstra sorgu demek; veritabanı yükünü ikiye katlayabilir. Bu noktada `select_related` ve `prefetch_related` devreye giriyor. `select_related` bir `ForeignKey`/`OneToOne` ilişkisi için JOIN yaparak ilgili satırları tek bir sorguda getiriyor; yani “birleştirilmiş” bir result set elde ediyorsun. Öte yandan `prefetch_related` bir `ManyToMany` veya ters `ForeignKey` gibi “çoklu” ilişkilere karşı çalışıyor; ilk sorgu temel nesneleri çeker, ikinci bir (veya birden fazla) ek sorgu ilişki setini toplar ve Python tarafında birleştirir. Valla, doğru yerde `select_related` kullanmak genelde daha hızlıdır çünkü JOIN sayesinde ekstra round‑trip yok, ama çok büyük tablolarla JOIN yaptığında veri şişmesi (Cartesian product) riski var, o yüzden `prefetch_related` tercih edilmesi gerekir. Bence en sık yapılan hata, `select_related`/`prefetch_related`’ı rastgele ve gereksiz yere eklemek. Örneğin bir admin listesinde sadece `id` ve `name` gösteriliyorsa tüm ilişkileri `select_related` ile çekmek hem bellek hem de ağ trafiğini artırır. Bir diğer sık hata, `prefetch_related`’ı kullandığın halde `queryset`’i sonradan `.filter()` ya da `.values()` gibi yeniden şekillendirmek; bu durumda önceden yapılan prefetch geçersiz kalır ve tekrar sorgu atılır. Migration sürecine gelince, Django migration’ları sadece şema değişikliklerini tutar; sorgu planı optimizasyonu burada devreye girmez. Ancak yeni bir alan eklerken ya da indeks tanımlarken `RunSQL` ile manuel `EXPLAIN` planı eklemek, sorguların nasıl yürütüleceğini önceden görebilmek açısından faydalı olur. Kısacası, ORM’i “akıllı” hâle getirmek için ilişkilerin kardinalitesini, veri büyüklüğünü ve kullanım senaryosunu iyi analiz edip, `select_related` ve `prefetch_related`’ı o analiz ışığında stratejik olarak yerleştirmek gerekiyor.