PostgreSQL Hataları ve Veritabanı Performansını Koru
PostgreSQL Kullanıyorsun Ama Bu Hataları Yapıyorsan Veritabanını Yoruyorsun
PostgreSQL, güçlü, güvenilir ve gelişmiş özelliklere sahip bir veritabanıdır. Ancak, bu gücün yanına yanlış kullanıldığında ciddi performans sorunları getirebileceğini unutmamak gerekiyor. Gerçek projelerde PostgreSQL’i kötü kullanmak; yavaş sorgulara, gereksiz disk kullanımına, yanlış index tasarımına, veri tutarsızlığına ve bakım zorluklarına neden olabilir. Bu yazıda, PostgreSQL kullanıcılarının en sık yaptığı 7 hatayı ele alacağız.
HATA 1: Her Kolona Rastgele Index Açmak
Indexler, sorgu performansını artırabilir ama her zaman çözüm değildir. Gereksiz index yazma işlemleri, performansı yavaşlatır ve disk kullanımını artırır. Her foreign key alanına düşünmeden index açmak, her filtrelenen kolona index eklemek veya kullanılmayan indexleri kontrol etmemek sık yapılan hatalardır.
Doğru Yaklaşım:
- WHERE, JOIN, ORDER BY ve sık kullanılan filtreleri analiz et.
- EXPLAIN ANALYZE ile sorgunun gerçekten index kullanıp kullanmadığını kontrol et.
- Kullanılmayan indexleri takip et.
|
1 2 3 4 5 |
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 15 ORDER BY created_date DESC; |
Kısaca, index açmak değil, doğru index açmak performans kazandırır.
HATA 2: SELECT * Kullanmak
SELECT * kullanmak kolaydır ama gereksiz veri çekilmesine neden olur. Özellikle geniş tablolar, JSONB kolonları veya büyük text alanları varsa, performansı ciddi şekilde etkileyebilir.
Yanlış Kullanım:
|
1 2 |
SELECT * FROM invoices; |
Doğru Kullanım:
|
1 2 |
SELECT id, invoice_no, customer_id, total_amount, created_date FROM invoices; |
API, raporlama ve listeleme ekranlarında sadece ihtiyaç olan kolonlar çekilmelidir. Ne kadar az ve doğru veri çekerseniz, sistem o kadar rahat çalışır.
HATA 3: JSONB’yi Her Şey İçin Kullanmak
PostgreSQL’in JSONB desteği çok güçlüdür. Ancak, JSONB alanları, ilişkisel modelin yerini almamalıdır. Sürekli filtrelenmesi gereken alanları JSONB içine gömmek veya raporlanacak verileri JSONB içinde saklamak gibi yanlış kullanımlar yapmaktan kaçının.
Doğru Yaklaşım:
- Esnek ve değişken metadata için JSONB kullanın.
- Ana iş verilerini ilişkisel kolonlarda tutun.
- JSONB içinde sık sorgulanan alanlar için uygun index stratejisi düşünün.
|
1 2 |
CREATE INDEX idx_orders_metadata_status ON orders ((metadata->>'status')); |
JSONB güçlüdür ama kontrolsüz kullanılırsa, veri modeli zamanla çöplüğe dönebilir.
HATA 4: Transaction Mantığını Küçümsemek
PostgreSQL transaction yönetiminde oldukça etkilidir. Uygulama tarafında transaction doğru tasarlanmadığında veri tutarsızlığına sebep olabilir. Örneğin, sipariş oluşturma, stok düşürme ve fatura kaydı işlemlerinin hepsinin başarılı olması gerekir. Aksi takdirde, tüm işlemler geri alınmalıdır.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
BEGIN; INSERT INTO orders(customer_id, total_amount) VALUES (1, 2500); UPDATE stocks SET quantity = quantity - 1 WHERE product_id = 10; INSERT INTO account_movements(customer_id, amount) VALUES (1, 2500); COMMIT; -- Hata durumunda: ROLLBACK; |
Vurgulamak gerekirse, ERP, stok, sipariş ve fatura gibi işlemlerde transaction kullanılmamalıdır.
HATA 5: Veri Tiplerini Rastgele Seçmek
PostgreSQL’de veri tipi seçimi, performans ve doğruluk açısından kritik öneme sahiptir. Para alanlarında float kullanmak ya da tarih için text kullanmak gibi hatalardan kaçınılmalıdır.
Doğru Veri Tipleri:
- Para alanları için numeric(18,2)
- Tarih/saat alanları için timestamptz
- Boolean değeri için boolean
Yanlış veri tipi, küçük projede görünmeyebilir ama büyük projelerde ciddi sorunlar yaratır.
HATA 6: EXPLAIN ANALYZE Kullanmadan Performans Yorumu Yapmak
Bir sorgunun neden yavaş olduğunu tahmin etmek yerine, PostgreSQL’in query planına bakmalısınız. Sequential Scan her zaman kötü değildir; index kullanımını iyi analiz etmek gerekmektedir.
|
1 2 3 4 5 |
EXPLAIN ANALYZE SELECT id, customer_id, total_amount FROM invoices WHERE created_date >= '2026-01-01' AND created_date < '2027-01-01'; |
Performans optimizasyonu, tahminle değil, ölçümle yapılır.
HATA 7: Migration ve Şema Değişikliklerini Kontrolsüz Yapmak
Canlı sistemlerde tablo değiştirmek, kolon eklemek ya da index oluşturmak dikkat ister. Küçük görünen migrationlar bile büyük tablolar üzerinde sistemi kilitleyebilir.
Doğru Yaklaşım:
- Migration dosyalarını inceleyin.
- Büyük tablolar için değişiklikleri parça parça planlayın.
- Gerekirse concurrent index oluşturmayı düşünün.
|
1 2 |
CREATE INDEX CONCURRENTLY idx_invoices_created_date ON invoices(created_date); |
Migration, sadece kod değişikliği değil; canlı veri üzerinde yapılan ciddi bir operasyondur.
Sonuç
PostgreSQL, güçlü bir veritabanıdır ama doğru kullanılmadığında performans sorunlarını gizlemez. Çalışan sorgu her zaman iyi sorgu değildir. Doğru index, doğru veri tipi, doğru transaction ve doğru veri modeli, büyük fark yaratır. JSONB, migration, query plan ve transaction gibi konular, gerçek projelerde mutlaka bilinmelidir. Özellikle ERP, CRM, stok, sipariş, fatura ve raporlama sistemleri için PostgreSQL’in kalitesi, doğrudan sistem kalitesini etkiler.
PostgreSQL’de asıl seviye, sadece tablo oluşturmak değil, verinin yıllar sonra bile doğru, hızlı ve yönetilebilir kalmasını sağlamaktır.
