Veritabanını değiştirmeden önce pahalı isteği bulun
Kategori yükleme, makale araması, sepete ekleme veya sipariş gönderimi gibi bir kullanıcı eyleminden başlayın. Rotasını, sorgu sayısını, veritabanı süresini, dönen satır sayısını ve isteğin süresini kaydedin. Yavaş bir sayfa aynı zamanda uygulama kodu veya başka bir bağımlılıktan bekliyor olabilir; bu yüzden yalnızca sayfa yükleme süresinden teşhis yapmayın.
Bir sorgu planı tablolar, indeksler, join'ler, sıralamalar ve agregalar boyunca veritabanının izlediği yolu gösterir. PostgreSQL’de EXPLAIN bu yolu gösterir. EXPLAIN ANALYZE ifadeyi çalıştırır ve gerçek satırları ile zamanlamaları raporlar; bu nedenle güvenli bir temsilci sorgu kullanın. Tahmini ile gerçek satır arasındaki büyük fark, istatistiklerin veya koşulların araştırılması için bir neden olup otomatik bir indeks talebi değildir.
Aday bir sorguyu bir rota ve sonuçla ilişkilendirin; sadece panoya dayalı bir rapor yavaş bir ödemeyi gölgede bırakmasın.
Değişiklik öncesi zamanlamaları ve karşılaştırılabilir trafiği, müşteri kimlikleri, tokenlar veya kartla ilgili değerler kaydetmeden saklayın.
Gerçek kullandığınız erişim yolu için indeks tasarlayın
İndeks, satırları bulmaya veya sıralı şekilde döndürmeye yardımcı olan korunan bir yapıdır; genel bir hız düğmesi değildir. Önce önemli bir sorgunun filtrelerini, join anahtarlarını ve sıralama düzenini belirleyin, sonra önerilen indeksin bir planda kullanıldığını doğrulayın. PostgreSQL belgeliyor ki eşleşen bir B-tree indeksi, özellikle küçük LIMIT değerlerinde, ayrı bir sıralama olmadan ORDER BY gereksinimini karşılayabilir.
İndeksler depolama ve yazma işini artırır çünkü ekleme, güncelleme ve silme işlemleri bunları korur. Tabloyun büyük bir bölümünü gerektiren bir sorgu için sıralı tarama (sequential scan) ve açık sıralama daha hızlı olabilir. Üretime benzer veride test edin ve fayda maliyeti haklı çıkarmadıkça indeksi tutmayın.
Sorgunun gerçek filtrelerini ve ORDER BY ifadesini kullanın; arayüz kararlı bir sıra gerektiriyorsa deterministik bir tie-breaker ekleyin.
Bir indeksin kullanılıp kullanılmadığını ve yazma sırasında maliyetini gözden geçirin; veri ve trafik değiştikçe yeniden kontrol edin.
Sayfalamayı kararlı ve uygun maliyetli yapın
Sayfa numarasıyla yapılan sayfalama genellikle LIMIT artı OFFSET kullanır. Her zaman öngörülebilir bir sıra (ORDER BY) zorunlu kılın. PostgreSQL, ORDER BY olmadan LIMIT'in tahmin edilemez bir alt küme döndürebileceğini uyarır; farklı LIMIT veya OFFSET değerleri optimizer'ın farklı planlar seçmesine yol açabilir.
Büyük offset değerleri atlanmış satırların yine de hesaplanması gerektiği için dikkat gerektirir. Derin katalog, sipariş geçmişi veya arşiv gezintileri için cursor veya keyset sayfalama (anahtar tabanlı) düşünün: son görülen kararlı sıralama değeri ve benzersiz tie-breaker sonrasında satırları isteyin. Arayüzü değiştirmeden önce yeni ya da silinmiş kayıtların nasıl görüneceğini tanımlayın.
Sınırsız bir sonuç yerine en küçük kullanışlı sayfayı döndürün.
Arayüzün her istekte tam bir toplam sayıya gerçekten ihtiyacı olup olmadığını kararlaştırın.
Yanlış yanıt vermeden okuma işini önbelleğe alın
Önbellekleme, veritabanından yeniden oluşturmak yerine önceki bir sonucu yeniden kullanır. Sürümlenmiş varlıklar ve genel, tekrar eden sayfalar için HTTP katmanından başlayın; çünkü bir önbellek isabeti uygulama ve veritabanı işini atlayabilir. web.dev, sürümlendirilmiş URL'ler için uzun ömürlü önbellekleme önermektedir; URL değiştirmek pratik bir geçersiz kılma mekanizmasıdır.
Önbellek politikası bir doğruluk (correctness) kararıdır. Paylaşılan bir önbellek bir yanıtı kullanıcılar arasında yeniden kullanabilir, bu yüzden hesap, sepet, fiyat veya yetkilendirmeye özel çıktıyı paylaşmayın; aksi takdirde kapsam için tasarlanıp test edilmelidir. Cache-Control private tarayıcı önbelleğine kısıtlama getirir, no-store ise önbelleklere saklamamayı belirtir.
Genel katalog veya makale çıktısını oturum-spesifik, konum-spesifik ve izinlere duyarlı çıktılardan ayırın.
Bir kişinin ne kadar süreyle eski bir değeri görebileceğini, süresini ve geçersiz kılma ya da yeniden doğrulama yolunu tanımlayın.
Tavanı yükseltmek yerine bağlantı kapasitesini koruyun
Bağlantı (connection) veritabanına canlı bir istemci oturumudur. Worker'lar, cron işleri, önizlemeler veya yeniden denemeler tek tek sorgular kabul edilebilir görünse bile yuvaları (slots) tüketebilir. PostgreSQL’in max_connections eşzamanlı bağlantıları kontrol eder, sunucu başlatılırken ayarlanır ve daha yüksek bir değer daha fazla kaynak (örn. paylaşılan bellek) ayırır. İş yükü modeliniz olmadan bunu yükseltmek hatayı başka yere taşıyabilir.
Web worker'ları, arka plan işleri, yönetim ve replika arasında tek bir bütçe belirleyin. Uygun yerlerde sınırlı connection pooling kullanın, kurtarma için boşluk (headroom) bırakın ve takılmış işler süresiz beklemesin diye zaman aşımı (timeout) uygulayın. Güvenli sayılar motor, bellek, sorgu karışımı ve sağlayıcı limitlerine bağlıdır; bunları işletmeci ile doğrulayın.
Web süreçleri, kuyruklar, planlanmış görevler, migration'lar, raporlama araçları ve dağıtım işleri dahil olsun.
Eşzamanlılığı sınırlayın ve bir hata bağlantı talebini çoğaltmasın diye geri çekilmeli (backoff) strateji kullanın.
Sorgu maliyetini bağlam ve gizlilik kontrolleriyle gözlemleyin
Tek bir yavaş örneğe göre değil, toplam etkiye göre veritabanı işini sıralayın. Binlerce kez çağrılan orta derecede yavaş bir sorgu nadir bir rapordan daha fazla önem taşıyabilir. PostgreSQL’in pg_stat_statements planlama ve yürütme verilerini, çağrıları, toplam ve ortalama yürütme zamanını, satırları ve buffer etkinliğini toplayarak sunar. Bu eklentiyi eklemek veya çıkarmak sunucu yapılandırması ve yeniden başlatma gerektirir; planlamanın izlenmesi ek yük getirebilir.
Sorgu gruplarını rota, yayın sürümü ve zaman penceresi ile ilişkilendirin. OpenTelemetry, parametreleri temizledikten (literals'i değiştirdikten) sonra sorgu metnini varsayılan olarak toplamayı ve düşük kardinaliteli sorgu özetleriyle gruplamayı önerir. Bu, sahiplerin müşteri verilerini dışa aktarmadan veya her değer için ayrı bir etiket oluşturmadan eğilimleri görmesine yardımcı olur.
Süre, toplam zaman, çağrılar, hatalar, bağlantılar ve satırlar gibi ölçümleri gözden geçirin; her biri farklı bir hata modunu ortaya koyar.
Parametreli sorgular kullanın ve izler veya loglar uygulamadan çıkmadan önce literal değerlerin kaldırıldığını doğrulayın.
Veritabanı değişikliklerini geri alınabilir güvenilirlik işi olarak gönderin
Bir indeks, yeniden yazım, önbellek politikası, pool ayarı veya şema değişikliğini sahipli, başarı ölçütü ve geri alma kararı olan bir üretim değişikliği gibi ele alın. Temsilî bir ortamda doğrulayın, sınırlı bir dilime yayın ve etkilenen yolculuğu izleyin. Daha hızlı olmak, değişiklik yanlış, eksik, yinelenen veya bayat veri döndürürse başarı değildir.
Şema değişiklikleri dikkat ister çünkü uygulama sürümleri örtüşebilir. Google Cloud rehberi uyumluluk sırasını şöyle açıklar: eskisini ve yenisini idare eden bir uygulama sürümünü yayınlayın, şemayı değiştirin, sonra onu kullanan özelliği yayınlayın. Bu, uygulama geri alma yolunu korur. Kilitleme ve çevrimiçi değişim (online-change) davranışı motor ve yönetilen hizmete göre farklılık gösterir; yüksek hacimli veya ödeme ile ilgili sistemler için nitelikli inceleme alın.
Rotayı, performans ve doğruluk sinyallerini ve dağıtımı durduracak eşiği adlandırın.
Kontrollü bir dilimde performans ve doğruluğu doğrulayın; geri dönüş yolunu bir olay dışında da pratik edin.