Türkiye'nin ilk Cross-Platform OldSchool MOBİL & PC 1-99 Sunucusu Lamira2 6 Kasım'da Açılıyor! Büyük Açılışı Kaçırma HEMEN TIKLA!
PostgreSQL Query Planner: Bir SQL Sorgusu Veritabanında Nasıl Çalıştırılır?
Bir SQL sorgusunun performansı yalnızca yazılan SQL kodunun uzunluğuna veya karmaşıklığına bağlı değildir. Aynı sonucu üreten iki farklı sorgu, PostgreSQL içerisinde tamamen farklı yürütme planları kullanabilir. Bu noktada devreye PostgreSQL Query Planner girer.Query Planner, veritabanına gönderilen bir SQL sorgusunu analiz ederek en düşük tahmini maliyetle çalıştırılabilecek yürütme planını belirlemeye çalışan bileşendir. Bu süreçte tablo istatistikleri, indeksler, tahmini satır sayıları, disk erişim maliyetleri ve CPU maliyetleri gibi birçok faktör değerlendirilir.
1. PostgreSQL Query Planner Nasıl Çalışır?
PostgreSQL'de bir SQL sorgusu doğrudan çalıştırılmaz. Sorgu, birbirini takip eden çeşitli aşamalardan geçer:- Parser: SQL sorgusunun sözdizimini kontrol eder ve parse tree oluşturur.
- Analyzer: Tablo, kolon, fonksiyon ve veri tiplerini doğrular.
- Rewriter: Gerekli sorgu yeniden yazma işlemlerini gerçekleştirir.
- Planner / Optimizer: Alternatif yürütme planlarını değerlendirerek uygun planı seçer.
- Executor: Seçilen yürütme planını gerçekleştirir ve sonuçları üretir.
SQL:
SELECT *
FROM users
WHERE email = 'test@example.com';
PostgreSQL bu sorguyu çalıştırırken users tablosunun tamamını taramak zorunda değildir. Eğer email kolonu üzerinde uygun bir indeks bulunuyorsa indeks üzerinden erişim sağlayabilir.
Ancak indeksin varlığı her zaman indeks kullanılacağı anlamına gelmez. Planner, tablodaki satır sayısını ve sorgunun tahmini maliyetini değerlendirerek Sequential Scan kullanmayı da tercih edebilir.
2. EXPLAIN ile Query Plan Analizi
PostgreSQL'de sorguların nasıl çalıştırılacağını incelemek için kullanılan en önemli araçlardan biri EXPLAIN komutudur.
SQL:
EXPLAIN
SELECT *
FROM users
WHERE email = 'test@example.com';Gerçek çalışma süresini ve gerçekleşen satır sayılarını incelemek için ise EXPLAIN ANALYZE kullanılabilir:
SQL:
EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM users
WHERE email = 'test@example.com';
Burada dikkat edilmesi gereken bazı önemli alanlar vardır:
- Seq Scan: Tabloyu baştan sona tarar.
- Index Scan: İndeks üzerinden ilgili kayıtlara ulaşır.
- Index Only Scan: Uygun koşullarda tabloya gitmeden yalnızca indeks üzerinden sonuç üretir.
- Bitmap Heap Scan: Birden fazla indeks kaydını bitmap yapısında birleştirerek tablo erişimini optimize eder.
- Nested Loop: Bir tablodaki satırlar üzerinden diğer tabloya tekrar tekrar erişir.
- Hash Join: Join işlemi için hash tablosu oluşturur.
- Merge Join: Sıralanmış veriler üzerinden birleştirme gerçekleştirir.
3. Sequential Scan Her Zaman Kötü müdür?
Veritabanı optimizasyonunda sık yapılan hatalardan biri Sequential Scan görüldüğünde sorgunun mutlaka yavaş çalıştığını düşünmektir.Aslında bu yaklaşım doğru değildir.
Örneğin 500 satırlık küçük bir tabloda PostgreSQL'in tüm tabloyu taraması, indeks üzerinden erişim sağlamasından daha düşük maliyetli olabilir.
Bunun yanında bir sorgu tablonun büyük bölümünü döndürecekse Sequential Scan kullanılması da oldukça mantıklı olabilir.
Önemli olan kullanılan operatörün adı değil, seçilen yürütme planının gerçek çalışma koşullarında ne kadar verimli olduğudur.
4. İndeks Oluşturmak Neden Her Zaman Performans Kazandırmaz?
Örneğin email kolonu üzerinde indeks oluşturduğumuzu düşünelim:
SQL:
CREATE INDEX idx_users_email
ON users(email);Bu indeks, email üzerinden yapılan aramalarda performansı artırabilir.
Ancak indekslerin de maliyetleri vardır:
- INSERT işlemlerinde indeksin güncellenmesi gerekir.
- UPDATE işlemleri ek maliyet oluşturabilir.
- DELETE işlemleri indeks kayıtlarını da etkiler.
- İndeksler disk alanı tüketir.
- Gereksiz indeksler bakım ve yazma performansını olumsuz etkileyebilir.
5. PostgreSQL İstatistikleri ve ANALYZE Mekanizması
Query Planner'ın doğru karar verebilmesi için tablolardaki veri dağılımını mümkün olduğunca doğru tahmin etmesi gerekir.PostgreSQL bu amaçla istatistikler kullanır.
Kod:
ANALYZE users;İstatistiklerin eski veya yetersiz olması durumunda PostgreSQL sorgunun döndüreceği satır sayısını yanlış tahmin edebilir. Bu da yanlış yürütme planlarının seçilmesine neden olabilir.
Özellikle büyük veri setlerinde tahmin edilen satır sayısı ile gerçekleşen satır sayısı arasındaki farkı incelemek önemlidir.
6. Gerçek Performans Analizinde Nelere Bakılmalı?
Bir SQL sorgusunu optimize ederken yalnızca Execution Time değerine odaklanmak yeterli değildir.Aşağıdaki alanlar birlikte değerlendirilmelidir:
- Planning Time: Yürütme planının hazırlanması için geçen süre.
- Execution Time: Sorgunun gerçekleştirilmesi için geçen süre.
- Actual Rows: Gerçekte döndürülen satır sayısı.
- Plan Rows: Planner tarafından tahmin edilen satır sayısı.
- Buffers: Bellek ve disk blok erişimlerinin dağılımı.
- Shared Hit Blocks: PostgreSQL shared buffer üzerinden karşılanan bloklar.
- Shared Read Blocks: Diskten okunarak shared buffer'a alınan bloklar.
Bu tür farklılıklar sorgu performansını doğrudan etkileyebilir.
Sonuca Gelecek Olursak;
PostgreSQL Query Planner, veritabanı performansının merkezinde yer alan önemli bir mekanizmadır. SQL sorgularını optimize etmek isteyen geliştiricilerin yalnızca sorgu yazmayı değil, sorguların veritabanı içerisinde nasıl yürütüldüğünü de anlaması gerekir.EXPLAIN ANALYZE, BUFFERS, indeks analizi ve istatistiklerin doğru değerlendirilmesi sayesinde performans problemlerinin kaynağı çok daha net tespit edilebilir.
Gerçek veritabanı optimizasyonu, rastgele indeks eklemek veya SQL sorgularını kısaltmak değil; PostgreSQL'in neden belirli bir yürütme planını seçtiğini anlayabilmekle başlar.
