Performans sorunlarının kaynağını bulmak
Power BI performans sorunu yaşadığınızda ilk adım, sorunun kaynağını doğru teşhis etmek. Rapor mu, veri modeli mi, DAX sorguları mı yoksa Power BI hizmetinin kendisi mi? Yanlış yere odaklanmak, saatlerinizi boşa harcamanıza neden olabilir.
DAX Studio, performans analizinde en güçlü silahınız. SSMS veya Visual Studio ile birlikte ücretsiz olarak indirilebilen bu araç, sorgularınızın ne kadar sürede çalıştığını, her adımda ne kadar zaman harcandığını ve bellek tüketimini gösteriyor. Sorgu planı analizi ile darboğazı görünür hale getiriyor.
Veri modeli: Temeli sağlam atın
Performans optimizasyonunun en etkili noktası veri modelidir. Doğru modelleme, sonraki tüm optimizasyonların üzerine inşa edildiği temeldir. Birçok performans sorunu aslında modelleme hatasından kaynaklanıyor.
Yıldız şeması (star schema), Power BI'da performans için altın standart. Merkezde bir fact table (olgu tablosu), çevresinde ise boyut tabloları (dimension). Bu yapı, VertiPaq sıkıştırma motorunun verimli çalışmasını sağlıyor. Snowflake şeması (normalized dimension) bazı durumlarda kullanışlı olsa da, genellikle sorgu performansını yavaşlatıyor.
Kullanılmayan sütunları modelden çıkarmak, hem dosya boyutunu hem de sorgu süresini doğrudan azaltıyor. Her sütun, VertiPaq motorunun hafızasında bir miktar yer kaplıyor ve her sorguda değerlendiriliyor. "Belki ileride lazım olur" mantığıyla eklenen sütunlar, performansı gizlice yiyor.
💡 VertiPaq ipucu: Cardinality (benzersiz değer sayısı) ne kadar düşük olursa, sıkıştırma o kadar iyi çalışır. Tarih tablosundaki TarihID sütunu (1, 2, 3...) tarih metninden çok daha düşük cardinality'ye sahiptir ve daha iyi sıkıştırılır. Mümkün olan her yerde ID kullanın, metin değil.
DAX'ta performans tuzakları
DAX, güçlü bir dil ama bazı yazım şekilleri performansı ciddi şekilde yavaşlatabiliyor. İşte dikkat edilmesi gerekenler:
SUMX ve AVERAGEX gibi iteratif fonksiyonlar
Bu fonksiyonlar her satır için ayrı ayrı hesaplama yapar. Büyük tablolarda ciddi performans kaybına neden olurlar. Mümkünse SUM, AVERAGE gibi toplama fonksiyonlarını tercih edin. Eğer iteratif fonksiyon şartsa, önce filtre uygulayıp tabloyu küçültmek bir nebze yardımcı olabilir.
FILTER fonksiyonunun aşırı kullanımı
FILTER, tablonun her satırını değerlendirdiği için pahalı bir operasyondur. CALCULATE ile birlikte koşul kullanmak genellikle daha performanslıdır. Örneğin:
-- SUMX ile (yavaş):
SUMX(
FILTER(Satislar, Satislar[Kategori] = "Elektronik"),
Satislar[Bedel]
)
-- CALCULATE ile (hızlı):
CALCULATE(
SUM(Satislar[Bedel]),
Satislar[Kategori] = "Elektronik"
)
Değişken kullanımı (VAR)
DAX'ta VAR kullanımı hem kod okunabilirliğini artırır hem de performansı iyileştirir. Aynı hesaplamayı birden fazla yerde kullanıyorsanız, sonucu bir değişkende tutmak tekrarlı hesaplamayı önler. Power BI, VAR içindeki ifadeyi yalnızca bir kez hesaplar ve sonucu bellekte saklar.
Row Level Security (RLS) performansı
RLS, büyük veri modellerinde performansı olumsuz etkileyen en yaygın nedenlerden biri. Özellikle karmaşık DAX filter ifadeleri içeren RLS kuralları, sorgu süresini dramatik şekilde artırabiliyor.
RLS performansını iyileştirmek için öncelikle kural başına tablo cardinality'sini düşük tutmaya çalışın. Kullanıcı bazında satır filtrelemek yerine, rol bazında gruplandırma yapmak daha performanslı çalışır. Ayrıca RLS kurallarınızı DAX Studio ile test ederek sorgu planını inceleyebilirsiniz.
VertiPaq sıkıştırma ayarları
Power BI Desktop'ta "Analyze in Excel" veya DAX Studio'da "View Metrics" ile VertiPaq analizi yapabilirsiniz. Bu analiz, her sütunun ne kadar bellek kapladığını, sıkıştırma oranını ve satır başına ortalama boyutu gösterir.
Sıkıştırma performansınız düşükse, şunlara dikkat edin: Benzersiz değer sayısı yüksek sütunlar (çok yüksek cardinality) sıkıştırmayı zorlaştırır. Tarih sütunları yerine tarih ID kullanmak sıkıştırmayı artırır. Bool (TRUE/FALSE) sütunları en düşük bellek tüketimine sahiptir.
Import vs DirectQuery: Doğru modu seçmek
Power BI'da veri modelini import edebilir veya DirectQuery ile kaynağa canlı bağlanabilirsiniz. Her iki modun avantaj ve dezavantajları var.
Import mode, verileri Power BI'ın belleğine yükler. Sorgular çok hızlıdır ama verilerin güncelliği, refresh schedule'a bağlıdır. Büyük veri setlerinde dosya boyutu artar ve bellek sınırlarına takılabilirsiniz.
DirectQuery, her sorguda kaynak veritabanına gider. Veriler her zaman günceldir ama sorgu performansı veritabanının kapasitesine bağlıdır. Karmaşık DAX sorguları, kaynak veritabanında çok sayıda SQL üretebilir.
Composite model, her iki dünyanın avantajlarını birleştiriyor. Bazı tablolar import edilirken, bazıları DirectQuery olarak bağlanabilir. Büyük transaction tabloları DirectQuery'de tutulurken, küçük boyut tabloları import edilebilir.
Uygulanabilir kontrol listesi
Performans optimizasyonu büyük bir liste gibi görünebilir ama önceliklendirme yapılırsa sonuç almak mümkün. İşte sıralı kontrol listesi:
- DAX Studio ile analiz: Önce sorunu ölçün. En yavaş sorgular hangileri?
- Modeli kontrol edin: Yıldız şemasına uygun mu? Kullanılmayan sütunlar var mı?
- RLS kurallarınızı inceleyin: Karmaşık DAX filter ifadeleri var mı?
- Import/DirectQuery dengesini ayarlayın: Composite model uygun mu?
- DAX ifadelerini optimize edin: Iteratif fonksiyonlar, FILTER kullanımı, VAR tercih edin.
- VertiPaq analizi yapın: Sıkıştırması düşük sütunları bulun ve ID'ye çevirin.