Veritabanı Optimizasyonu: PostgreSQL’de Zaman Bazlı Bölümleme

Veritabanı optimizasyonu için bölümleme adayını ölçerek seçin

Kararı sadece ortalama gecikmeyle vermeyin. Üretime yakın bir kopyada son 30 günlük sorguyu EXPLAIN (ANALYZE, BUFFERS, SETTINGS) ile çalıştırıp Planning Time, shared read ve dönen satır sayısını kaydedin. Örneğin 900 milyon satırlık bir event_log tablosunda hedef; 24 saatlik sorgunun tüm tabloyu taraması yerine yalnızca bir günlük partition’a gitmesi, yani planda tek bir child relation görünmesidir. Önce-sonra karşılaştırmasını aynı parametreler, sıcak/soğuk cache koşulları ve en az 30 tekrar ile yapın; yalnızca ilk çalıştırmanın süresini kıyaslamak OS page cache etkisi nedeniyle yanıltıcıdır.

Zaman aralıklı partition şemasını doğru anahtarla kurun

Partition sınırlarını UTC ile tanımlayın ve uygulamanın yerel saatinden gelen timestamp’leri yazmadan önce normalize edin. Yaz saati geçişinde timestamp without time zone kullanılması, aynı yerel saatin iki kez oluşmasına veya bir saatin hiç oluşmamasına neden olabilir. Aylık partition çoğu log iş yükü için yönetilebilir bir başlangıçtır; günlük partition’a ancak günlük veri hacmi, vakum süresi veya retention silme penceresi aylık partition’ı operasyonel olarak taşınamaz hale getiriyorsa geçin. Gelecek partition’ları önceden üretmek için pg_partman kullanılabilir; aracı kullanmıyorsanız CI/CD içinde her ayın son haftasında CREATE TABLE ... PARTITION OF çalıştıran idempotent bir migration ekleyin.

Database indexleme: B-tree ile BRIN’i veri korelasyonuna göre ayırın

Bu database indexleme kararını tahminle değil planla doğrulayın. 24 saatlik tenant sorgusunda Index Scan veya seçicilik düşükse Bitmap Heap Scan beklenir; Seq Scan her zaman hata değildir, seçilen satır oranı yüksekse daha ucuz olabilir. EXPLAIN (ANALYZE, BUFFERS) çıktısında Rows Removed by Index Recheck değeri BRIN için aşırı yükselirse önce pages_per_range değerini 128’den 32’ye düşürerek test edin; bu indeks boyutunu artırır ama her range’in zaman aralığını daraltır. CREATE INDEX CONCURRENTLY transaction block içinde çalışmaz; migration aracı tüm migration’ı tek transaction’a sarıyorsa bu komutu transaction dışı çalışacak şekilde işaretleyin.

Veritabanı performans ayarlama: pruning ve prepared statement tuzağı

Önce-sonra raporunda en az şu dört alanı saklayın: Planning Time, Execution Time, shared_blks_read ve aktif partition sayısı. Partition sayısı büyüdüğünde 1 günlük sorgu hızlı kalsa bile planlama süresi artabilir; bunu pg_stat_statements.mean_plan_time ile izleyin. Sorun generic plan kaynaklıysa tanı amaçlı olarak oturumda SET LOCAL plan_cache_mode = force_custom_plan; çalıştırıp planı yeniden alın. Bunu kalıcı çözüm diye üretim geneline uygulamayın: her çağrıda yeniden planlama CPU maliyeti doğurur. Uygulama tarafında parametre türlerinin doğru gönderildiğini ve zaman koşuluna date_trunc(occurred_at) gibi sütun üzerinde fonksiyon uygulanmadığını doğrulayın; bu ifade hem B-tree erişimini hem pruning seçeneklerini daraltır.

Retention işlemini DELETE yerine partition yaşam döngüsüyle yönetin

Bu yaklaşım, sql eğitimi kapsamında sık görülen DELETE FROM event_log WHERE occurred_at < ... alışkanlığından farklıdır: detach/drop sonrasında eski satırlar için VACUUM beklenmez. Buna karşılık uzun süren transaction’lar eski partition’a erişiyorsa ALTER TABLE ... DETACH PARTITION kilit bekleyebilir. Bakım işinden önce pg_stat_activity üzerinde xact_start değerini kontrol edin ve uygulama connection pool’unda idle-in-transaction timeout tanımlayın. NoSQL eğitimi alan ekipler için de aynı ders geçerlidir: örneğin belge deposunda TTL kullanmak operasyonu kolaylaştırabilir, fakat ilişkisel olay verisini PostgreSQL’de tutuyorsanız retention maliyetini çözmenin karşılığı zaman hizalı partition yaşam döngüsüdür.

SQL Server eğitimi bağlamında aynı tasarımı karşılaştırın

SQL Server eğitimi yapan ekiplerde eşdeğer yaklaşım partition function, partition scheme ve bakım penceresinde ALTER TABLE ... SWITCH PARTITION kullanmaktır. PostgreSQL’deki DETACH PARTITION gibi, SQL Server’da da metadata-only switch için kaynak ve hedef tablonun kolonları, indeksleri, constraint’leri ve partition sınırları uyumlu olmalıdır. Önce sys.dm_db_partition_stats ile partition başına satır sayısını alın; dengesiz dağılım, yanlış tarih sınırı veya beklenmeyen backfill işaretidir.

SELECT OBJECT_NAME(object_id) AS table_name,
       partition_number,
       row_count,
       reserved_page_count * 8 / 1024.0 AS reserved_mb
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID(N'dbo.EventLog')
  AND index_id IN (0, 1)
ORDER BY partition_number;

Sık Sorulan Sorular

Veritabanı performans ayarlama sırasında PostgreSQL partition sayısını nasıl seçmeliyim?

Önce retention penceresini ve en sık kullanılan zaman filtresini çıkarın. 12 aylık retention ve günlük sorgular için aylık partition ile başlayın; her partition’ın satır sayısını, VACUUM süresini ve pg_stat_statements.mean_plan_time değerini izleyin. Planlama süresi veya bakım süresi kabul edilemezse günlük partition’ı üretim kopyasında EXPLAIN (ANALYZE, BUFFERS) ile karşılaştırın.

Database indexleme için BRIN mi B-tree mi kullanmalıyım?

Tenant_id eşitliği ve kısa zaman aralığıyla arama yapıyorsanız (tenant_id, occurred_at) B-tree kullanın. Append-only kayıtlar fiziksel olarak zaman sırasındaysa yalnızca occurred_at için BRIN test edin. Kararı indeks boyutu, shared_blks_read ve Rows Removed by Index Recheck metrikleriyle verin; düşük correlation değerinde BRIN beklenenden fazla heap sayfası okuyabilir.

SQL eğitimi sırasında partition edilmiş tabloda neden unique constraint hatası alıyorum?

PostgreSQL partition edilmiş tabloda unique veya primary key constraint’i partition anahtarını içermek zorundadır. Tablo RANGE (occurred_at) ile partition edildiyse yalnızca event_id için PRIMARY KEY tanımlanamaz; PRIMARY KEY (event_id, occurred_at) gibi partition anahtarını içeren bir tasarım kurun ya da küresel benzersizliği uygulama/ayrı kimlik tablosu seviyesinde yönetin.

NoSQL eğitimi alan bir ekip zaman serisi veriyi yine de ilişkisel veritabanında tutabilir mi?

Evet; sorgular tenant, zaman aralığı ve transaction gerektiriyorsa PostgreSQL partition + B-tree/BRIN kombinasyonu uygulanabilir. Karar öncesinde gerçek sorgu şeklini pg_stat_statements ile ölçün. TTL tabanlı silme gereksinimi varsa partition detach/drop ile aynı retention davranışını, büyük hacimli DELETE maliyeti olmadan oluşturabilirsiniz.