Partitioning performans sihri değildir
Partitioning büyük tabloyu daha küçük fiziksel parçalara böler. Bu, doğru sorgularda daha az veri okumayı ve eski veriyi daha kolay yönetmeyi sağlar. Ama sorgular partition anahtarını kullanmıyorsa sistem yine çok fazla parça gezebilir.
Bu yüzden partitioning kararından önce sorguların gerçekten hangi alanlarla filtrelediğini görmek gerekir. Tarih aralığı her sorguda varsa range partition mantıklı olabilir; yoksa partitioning yalnızca bakım maliyetini artırabilir.
- Sorgular partition anahtarını düzenli kullanıyor mu?
- Eski veri drop/archive ihtiyacı var mı?
- Tek partition altında indeks boyutu hâlâ yönetilebilir mi?
- Partition sayısı planlama ve bakım maliyetini artıracak mı?
Önce tablo ve indeks büyümesini ölçün
Büyük tablo hissi yerine ölçüm gerekir. Tablo boyutu, indeks boyutu, satır dağılımı ve sorguların tarih aralığı kullanımı birlikte okunmalıdır. Tek başına satır sayısı partitioning için yeterli gerekçe değildir.
Tablo ve indeks büyüklüğü
SELECT relname, pg_size_pretty(pg_relation_size(relid)) AS table_size, pg_size_pretty(pg_indexes_size(relid)) AS index_size, pg_size_pretty(pg_total_relation_size(relid)) AS total_size FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 20;
Tarih dağılımını görmek
SELECT date_trunc('month', created_at) AS month, count(*)
FROM events
GROUP BY month
ORDER BY month DESC
LIMIT 24;Range partitioning ne zaman iyi çalışır?
Zaman serisi, event, log, ödeme hareketi veya sipariş geçmişi gibi verilerde sorgular çoğu zaman tarih aralığıyla çalışır. Bu durumda aylık veya günlük range partition, hem sorgu pruning hem de eski veriyi yönetmek için güçlü olabilir.
Ama çok küçük partitionlar planlama maliyeti ve bakım karmaşası yaratır. Günlük partition mı aylık partition mı sorusu veri hacmi, retention ve sorgu aralığıyla birlikte düşünülmelidir.
Basit range partition örneği
CREATE TABLE events (
tenant_id uuid NOT NULL,
created_at timestamptz NOT NULL,
event_name text NOT NULL,
payload jsonb NOT NULL
) PARTITION BY RANGE (created_at);
CREATE TABLE events_2026_06 PARTITION OF events
FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');
CREATE INDEX ON events_2026_06 (tenant_id, created_at DESC);Migration planı olmadan partitioning yapmayın
Mevcut büyük tabloyu partitionlı yapıya taşımak canlı sistemde dikkat ister. Yeni tablo, kopyalama, trigger/CDC, kısa kesinti, doğrulama ve rollback planı olmadan “ALTER ile hallederiz” yaklaşımı risklidir.
TürkDB tarafında PITR, yedek ve bakım penceresi bu tür işlerde hedeflenen güvenlik ağıdır. Yine de partitioning geçişi uygulama ve veri modeli seviyesinde planlanmalıdır.
Geçiş öncesi güvenlik kontrolü
turkdb backup create app-pg turkdb cluster pitr window app-pg turkdb cluster events app-pg --limit 20