PostgreSQL Bloat Yönetimi: Vacuum, Autovacuum ve pg_repack 2026

PostgreSQL’de postgres vacuum mekanizmasını doğru çalıştırmak, MVCC mimarisinin doğrudan bir sonucu olan tablo ve indeks şişmesini (bloat) kontrol altında tutmanın tek yoludur. Bloat birikmiş bir OLTP veritabanında, 200 GB’lık bir tabloda fiziksel boyutun %35-55’i ölü tuple’lardan oluşabilir; bu durum sequential scan sürelerini 2-4 katına çıkarır, planner istatistiklerini bozar ve disk maliyetini doğrudan büyütür. Bu yazı 2025-2026 itibarıyla PostgreSQL 16 ve 17 sürümlerinde vacuum davranışını, autovacuum tuning’i, pg_repack ile online reorganization’ı ve VACUUM FULL ile pg_squeeze arasındaki karar çerçevesini sayısal olarak ele alır.

PostgreSQL’in 2024 sonu Stack Overflow Developer Survey verilerine göre profesyonel geliştiriciler arasında %49 kullanım payıyla en çok tercih edilen veritabanı olması, bloat yönetiminin teorik bir konu değil, milyonlarca prod sisteminde günlük operasyonel bir gerçek olduğunu gösteriyor. Bloat’ı doğru yönetmeyen ekipler, her 6-12 ayda bir maintenance window’a sığınmak ya da disk ekleyerek semptomu maskelemek zorunda kalıyor. Bu rehber, ölçüm → tuning → online reorganization sırasını net bir karar diyagramına oturtuyor.

1. MVCC ve bloat: Sorunun kökü

PostgreSQL Multi-Version Concurrency Control (MVCC) kullanır: bir satır UPDATE edildiğinde eski versiyon (tuple) hemen silinmez, yeni bir versiyon eklenir; eski satır “dead tuple” olarak işaretlenir. DELETE’te de aynı şey olur — satır fiziksel olarak gitmez, sadece xmax değeri set edilir. Bu mekanizma okuyucu sorguların lock almadan tutarlı snapshot görmesini sağlar, ama temizlik gerektirir. Resmi PostgreSQL routine vacuuming dokümantasyonu, bu temizliğin yapılmaması durumunda hem disk kullanımının hem de transaction ID wraparound riskinin büyüdüğünü açıkça belirtir.

Bloat üç katmanda birikir: tablo bloat (heap içindeki ölü tuple’lar), indeks bloat (B-tree sayfalarındaki silinmiş referanslar) ve TOAST bloat (büyük alanlar için ayrı saklama tablosu). Yüksek UPDATE oranlı bir tabloda — örneğin bir kuyruk (queue) tablosu veya sayaç (counter) tablosu — bir gün içinde tablo boyutu 2-3 katına çıkabilir. pgstattuple eklentisiyle ölçüldüğünde 50 GB’lık bir tabloda dead_tuple_percent değerinin %40’a ulaşması nadir değildir.

Bloat tipi	Sebep	Tipik %	Etki	Çözüm
Tablo (heap) bloat	UPDATE/DELETE sonrası dead tuple birikimi	%20-50	Seq scan yavaşlar, disk şişer	Autovacuum, pg_repack
İndeks bloat	B-tree sayfa parçalanması	%30-70	Index scan latency artar	REINDEX CONCURRENTLY, pg_repack -x
TOAST bloat	Büyük metin/JSONB güncellemeleri	%15-40	Disk kullanımı, cache verimliliği	VACUUM, autovacuum_vacuum_scale_factor
Visibility map bloat	VACUUM çalıştırılmaması	—	Index-only scan devre dışı kalır	Düzenli VACUUM (FREEZE değil)
FSM (Free Space Map)	VACUUM olmadan yer dönüşü	—	Yeni satırlar boş alanı bulamaz	VACUUM (FSM güncellemesi)

Bloat ölçümünün başlangıç noktası iki sorgu seti: pg_stat_user_tables view’ı (n_dead_tup, n_live_tup, last_autovacuum) ve pgstattuple eklentisi (tuple_count, dead_tuple_percent, free_percent). Üretim ortamında pgstattuple_approx fonksiyonu, full tablo taraması yapmadan örnekleme tabanlı hızlı tahmin verir; 500 GB’lık bir tabloda 30-90 saniyede çalışır.

2. VACUUM, autovacuum ve VACUUM FULL: Üç farklı operasyon

Tek kelime “vacuum” altında üç tamamen farklı operasyon vardır ve bunları karıştırmak ciddi outage’lara yol açar. Manuel VACUUM komutu tablo üzerinde paylaşımlı kilit alır, okuma ve yazmayı bloklamaz, ölü tuple’ları “yer dönüştür ama dosyayı küçültme” mantığıyla işaretler. autovacuum ise arka plan worker’ları tarafından eşik değerlerine göre otomatik tetiklenen aynı operasyondur — varsayılan olarak her 1 dakikada bir uyanır ve threshold’u geçen tabloları işler.

VACUUM FULL tamamen farklı bir hayvandır: tablo üzerinde ACCESS EXCLUSIVE kilit alır (okuma dahil her şeyi bloklar), tabloyu yeni bir fiziksel dosyaya kopyalar, eski dosyayı siler. Bu işlem disk alanını geri kazandırır ama tabloyu kilitler. 200 GB’lık bir tabloda VACUUM FULL süresi disk hızına göre 40-90 dakika arası değişir ve bu süre boyunca tablo erişilemez. Üretimde bunu çalıştırmak çoğu zaman kabul edilemez.

• VACUUM — Avantaj: Online, lock-free okuma. Dezavantaj: Dosya küçülmez. Ne zaman seç: Her zaman, autovacuum’a güvenmek dahil rutin temizlik.
• VACUUM (FREEZE) — Avantaj: Wraparound riskini önler. Dezavantaj: Tüm tabloyu taramak gerekir. Ne zaman seç: 200M+ transaction yaşı olan tablolarda.
• VACUUM FULL — Avantaj: Disk %100 geri kazanılır. Dezavantaj: Exclusive lock, uzun süre. Ne zaman seç: Yalnız maintenance window’da, alternatif yoksa.
• VACUUM ANALYZE — Avantaj: Planner istatistikleri tazelenir. Dezavantaj: Ek I/O. Ne zaman seç: Büyük DML sonrası.
• autovacuum — Avantaj: Otomatik, ayarlanabilir. Dezavantaj: Default değerler büyük tablolara uygun değil. Ne zaman seç: Her zaman açık, ama tablo-bazlı tune et.

PostgreSQL 16 ve 17, manuel VACUUM komutuna BUFFER_USAGE_LIMIT parametresi ekledi. Bu, buffer cache’i kirletmeden vacuum çalıştırmayı sağlar — özellikle gece bakım pencerelerinde production cache’i bozmadan büyük tabloları temizlemek için kritik bir özellik. Resmi VACUUM SQL referansı bu parametre için minimum 128 kB, maksimum 16 GB sınırlarını belirtir.

3. Autovacuum tuning: Default değerler neden yetmez

PostgreSQL’in postgresql.conf‘taki autovacuum defaultları, 2008 dönemi donanım ve veri hacimleri için tasarlandı; modern üretim ortamlarında doğrudan kullanılması ciddi sorunlar üretir. Default autovacuum_vacuum_scale_factor = 0.2, “tablo boyutunun %20’si ölü tuple olduğunda tetikle” demektir. 100 GB’lık bir tabloda bu 20 GB dead tuple birikene kadar bekleme anlamına gelir — pratikte felaket.

Modern tuning yaklaşımı: büyük tablolarda scale_factor’ü 0.01 veya 0.005’e indirip, threshold’u sabit bir rakama (örn. 100000 tuple) çekmektir. Bu, autovacuum’un tablo büyüse de tutarlı sıklıkla çalışmasını sağlar. Percona’nın autovacuum internals analizi, büyük OLTP tablolarında bu parametreyi tablo-bazlı override etmenin standart pratik olduğunu vurgular.

Parametre	Default	OLTP Önerisi	Açıklama
autovacuum_max_workers	3	5-8	Çekirdek sayısına göre, max 1/4 CPU
autovacuum_naptime	1min	15s-30s	Sık tetikleme, yoğun OLTP
autovacuum_vacuum_scale_factor	0.2	0.01-0.05	Büyük tablolarda agresif
autovacuum_vacuum_threshold	50	1000-10000	Küçük tablolar için sabit eşik
autovacuum_vacuum_cost_limit	-1 (200)	2000-4000	Throttling’i azalt
autovacuum_vacuum_cost_delay	2ms	0-2ms	SSD’de 0 makul
maintenance_work_mem	64MB	1-2GB	VACUUM ve REINDEX hızı
autovacuum_work_mem	-1	512MB-1GB	Worker başına ayrı limit

Tablo-bazlı override en güçlü araçtır. Sık güncellenen bir orders tablosu için ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.01, autovacuum_vacuum_threshold = 5000, autovacuum_analyze_scale_factor = 0.005); tek satır komut, o tabloda autovacuum’u yaklaşık 20 kat daha sık tetikler. Bunun maliyeti ek I/O, kazancı ise stabil tablo boyutu ve tahmin edilebilir performans.

Cost-based vacuum throttling, autovacuum worker’ının ne kadar I/O harcayabileceğini sınırlar. vacuum_cost_limit = 200 ve vacuum_cost_delay = 2ms ile autovacuum saniyede ~3-4 MB temizler — bu, 100 GB’lık bir tablo için günler anlamına gelir. SSD ortamlarında cost_limit’i 4000’e, delay’i 0’a çekmek aynı temizliği saatlere indirir. CYBERTEC PostgreSQL tuning rehberi bu çarpan ilişkisini somut örneklerle açıklar.

4. pg_repack ile online reorganization

pg_repack, NTT Open Source Software Center tarafından geliştirilen ve 2025 itibarıyla 1.8K+ GitHub yıldızıyla en olgun online vacuum-full alternatifidir. Çalışma prensibi: hedef tabloyu read-write açık tutarken arka planda aynı tabloyu yeni bir dosyaya kopyalar, kopyalama sırasında gelen değişiklikleri bir log tablosu üzerinden replay eder, son aşamada çok kısa bir exclusive lock alıp yeni dosyayı atomik olarak swap eder.

Pratik sonuç: 200 GB’lık bir tabloyu VACUUM FULL ile 60 dk lock ile reorganize etmek yerine, pg_repack ile aynı tabloyu okuma-yazma açık tutarak 80-120 dk içinde online temizlemek mümkün. Final swap fazı genelde 1-3 saniye sürer. 24/7 SaaS uygulamaları için bu pratikte tek kabul edilebilir çözümdür.

pg_repack’ın çalışma gereksinimleri net: hedef tabloda PRIMARY KEY veya UNIQUE NOT NULL indeks olmalı (replication için), disk üzerinde tablo boyutu kadar boş alan olmalı (kopya için), ve eklenti superuser tarafından CREATE EXTENSION pg_repack; ile yüklenmiş olmalı. AWS RDS, Aurora PostgreSQL ve Google Cloud SQL pg_repack’ı yönetilen eklenti olarak destekler.

1. Pre-check: pg_repack --dry-run -t orders ile çalıştırılabilirlik testi.
2. Tablo full repack: pg_repack -d mydb -t public.orders --no-kill-backend.
3. Sadece indeks repack: pg_repack -d mydb -t public.orders -x (indeksleri online rebuild eder).
4. Specific indeks repack: pg_repack -d mydb -i orders_user_id_idx.
5. Throttling: -T 3600 ile lock timeout, --wait-timeout=60 ile başlangıç gecikmesi.
6. Cleanup: Hata durumunda pg_repack -D ile yarım kalan repack tablolarını temizle.

Bir bankacılık SaaS müşterisi için Ömer Önal’ın yürüttüğü danışmanlık projesinde 380 GB’lık transactions tablosu pg_repack ile 142 dakikada %48 bloat’tan %3’e indirildi; downtime toplam 2.1 saniye sürdü. Aynı işlem VACUUM FULL ile dener yaklaşık 2 saatlik tam outage gerektirirdi. Veri katmanı kararlarının operasyonel disipline doğrudan etkisi bu örnekte ölçülebilir hale geliyor; bu nedenle PostgreSQL performans optimizasyonu çalışmalarında bloat yönetimi ilk kontrol kalemlerinden biridir.

5. pg_squeeze ve native online reorganization seçenekleri

pg_repack’ın en güçlü alternatifi pg_squeeze eklentisidir. CYBERTEC tarafından geliştirilen bu eklenti, pg_repack’tan farklı olarak logical decoding (WAL streaming) kullanır — trigger tabanlı log tablosu yerine WAL’dan değişiklikleri okur. Bu, daha düşük write amplification ve daha az transactional overhead anlamına gelir.

Özellik	VACUUM FULL	pg_repack	pg_squeeze	CLUSTER
Online (no read block)	Hayır	Evet	Evet	Hayır
Disk geri kazanım	%100	%100	%100	%100
Final lock süresi	Tüm işlem	1-3 sn	1-3 sn	Tüm işlem
Mekanizma	Heap rewrite	Trigger log	Logical decoding	Index-order rewrite
PK gereksinimi	Hayır	Evet	Evet	Index gerekli
Disk alanı (geçici)	1x tablo	1x tablo + log	1x tablo	1x tablo
Managed cloud desteği	Native	RDS, Aurora, Cloud SQL	Sınırlı	Native
Otomatik schedule	Yok	Yok	Var (built-in)	Yok
Tipik süre (100GB)	30-45 dk	45-70 dk	40-65 dk	30-45 dk

PostgreSQL 16, ortak bir pg_visibility module iyileştirmesiyle visibility map manipülasyonunu kolaylaştırdı; bu özellik gelecekte native bir online vacuum-full mekanizması için temel oluşturuyor. 2026 itibarıyla 18 sürümü için tartışılan “block-skipping VACUUM” RFC’si, autovacuum’un visible tüm sayfaları atlayarak sadece dead tuple içeren sayfalara odaklanmasını hedefliyor — bu uygulamaya geçerse otomatik temizlik 3-5 kat hızlanabilir.

6. İndeks bloat ve REINDEX CONCURRENTLY

İndeks bloat tablo bloat’tan ayrı bir problem ve genellikle daha sinsidir. B-tree indekslerinde sayfa silmeleri sonrası boş alan kaldığında, indeks dosyası küçülmez. Yoğun UPDATE’leri olan tablolarda indeksler tablo boyutundan büyüyebilir. pgstatindex eklentisi avg_leaf_density alanıyla bunu ölçer — sağlıklı değer %70-90, sorunlu değer %30-50’dir.

PostgreSQL 12’den beri gelen REINDEX CONCURRENTLY, indeksleri lock-free yeniden inşa eder. Mekanik olarak yeni bir indeks oluşturur, eskisini drop eder ve yeni indeksin adını eskinin adına çevirir. Bu işlem 50 GB’lık bir indeks için yaklaşık 25-50 dakika sürer ve süreç boyunca tablo tamamen kullanılabilir.

• REINDEX INDEX CONCURRENTLY idx_name — Tek indeks, online.
• REINDEX TABLE CONCURRENTLY orders — Tablonun tüm indeksleri, online.
• REINDEX SCHEMA CONCURRENTLY public — Schema bazlı toplu işlem.
• REINDEX DATABASE — Concurrently desteklenmez; system catalog için maintenance window gerekir.

REINDEX CONCURRENTLY çalışırken iki indeks aynı anda bellekte tutulur — geçici olarak indeks boyutu kadar ek disk gerekir. İşlem yarıda kalırsa INVALID işaretli ölü indeks bırakır; bunu DROP INDEX ... CONCURRENTLY ile temizlemek gerekir. PostgreSQL REINDEX dokümantasyonu bu edge case’leri ayrıntılı listeler.

7. Transaction ID wraparound: Felaket senaryosu

PostgreSQL’in 32-bit transaction ID alanı yaklaşık 4.2 milyar değer alır. Bu sayaç dolduğunda (wraparound), eski transaction’lar “gelecekten” gibi görünmeye başlar ve veri corruption riski doğar. Bunu önlemek için PostgreSQL, eski tuple’ları “frozen” olarak işaretler — bu işlem VACUUM FREEZE’in temel görevidir.

autovacuum_freeze_max_age = 200000000 (200M transaction) eşiği aşıldığında PostgreSQL aggressive autovacuum moduna geçer ve durdurulması neredeyse imkansızdır — sistem load’una bakmadan çalışır. Eğer 2 milyar değerine yaklaşıldığında hala temizlenmemişse, veritabanı read-only moda alınır ve operasyonel felaket başlar. 2015’te Sentry, 2017’de Mailchimp gibi büyük şirketlerin postmortem’lerinde bu senaryo public olarak anlatılmıştır.

Erken uyarı sorgusu: SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY 2 DESC; herhangi bir veritabanı 1.5 milyar civarına ulaşmışsa kritik aksiyon zamanıdır. Crunchy Data’nın wraparound rehberi, 150M transaction yaşında manuel VACUUM FREEZE başlatmanın ve transaction yaşlanmasını günlük monitor etmenin standart pratik olduğunu vurgular.

Transaction yaşı	Durum	Aksiyon
0 – 100M	Sağlıklı	Rutin autovacuum yeterli
100M – 150M	İzlenmeli	VACUUM FREEZE schedule planla
150M – 200M	Dikkat	Manuel VACUUM FREEZE başlat
200M – 1B	Aggressive autovacuum	Devam ediyor, kesme
1B – 1.5B	Uyarı	Acil VACUUM FREEZE, kapasite artır
1.5B – 2B	Kritik	Tüm workload’ları kapat, freeze tamamla
2B+	Read-only	Felaket; emergency vacuum tek seçenek

PostgreSQL 14’ten itibaren pg_stat_progress_vacuum view’ı vacuum ilerlemesini gerçek zamanlı gösterir; aggressive autovacuum sırasında bu view’ı izlemek ETA hesaplamak için kritiktir. Veri ekosistemindeki bu tür operasyonel disiplinler, doğrudan veri yönetişimi politikalarının teknik tarafıyla örtüşür: SLA, recovery time objective ve data retention pencereleriyle birebir bağlantılıdır.

8. Bloat monitoring: pgstattuple, pg_bloat_check ve Datadog

Bloat’ı yönetmenin önkoşulu sürekli ölçmektir. Üç ana yaklaşım vardır: PostgreSQL native eklentileri, açık kaynak monitoring tool’ları ve ticari APM çözümleri. pgstattuple eklentisi, kesin değer ister ama tablo full scan yapar — 200 GB’lık tabloda 10-20 dakika sürebilir. pgstattuple_approx aynı eklentinin örnekleme tabanlı versiyonu, %1-3 hata payıyla saniyeler içinde sonuç döner.

Üretim ortamında en yaygın açık kaynak araç pg_bloat_check Python scriptidir. Tüm veritabanını tarayıp tablo ve indeks bloat’ını rapor eder, threshold-based alerting yapar. Cron ile haftalık çalıştırıldığında bloat trendini takip etmek için yeterlidir.

• pgstattuple — Avantaj: Tam doğruluk. Dezavantaj: I/O ağır. Ne zaman seç: Reactive analiz.
• pgstattuple_approx — Avantaj: Hızlı, üretim güvenli. Dezavantaj: %1-3 hata. Ne zaman seç: Düzenli monitoring.
• pg_bloat_check (Python) — Avantaj: Open source, customizable. Dezavantaj: Setup gerekir. Ne zaman seç: Çok sayıda tablo.
• Datadog / New Relic APM — Avantaj: Dashboard, alerting. Dezavantaj: Maliyet ($15-31/host/ay). Ne zaman seç: Mature SRE ekipleri.
• pganalyze — Avantaj: PG-spesifik, AI-driven öneriler. Dezavantaj: $239/instance/ay başlangıç. Ne zaman seç: Ciddi PG fleet yönetimi.

Stack Overflow 2024 Developer Survey’e göre veritabanı katmanında en sık kullanılan APM tool’u Datadog (kullanıcıların %14’ü), ardından New Relic ve Grafana Cloud geliyor. Açık kaynak Grafana + Prometheus + postgres_exporter kombinasyonu, ücretsiz bir alternatif olarak n_dead_tup, last_autovacuum ve pg_stat_activity metriklerini PG seviyesinde toplar.

Tool	Tip	Maliyet	Bloat metriği	Alerting
pgstattuple_approx	Native eklenti	Ücretsiz	Tam (sampled)	Yok
pg_bloat_check	Python script	Ücretsiz	Heap+Index	Threshold (custom)
Datadog PG integration	SaaS APM	~$15/host/ay + kullanım	n_dead_tup based	Built-in
pganalyze	PG-spesifik SaaS	~$239/instance/ay	Sampled + autovacuum	AI advisor
Grafana + postgres_exporter	Open source stack	Self-host maliyeti	n_dead_tup, age()	Alertmanager
AWS RDS Performance Insights	AWS native	7 gün ücretsiz, sonrası saat	Wait events	CloudWatch

Modern data stack’lerde bloat metriklerini diğer veri kalitesi sinyalleriyle birlikte izlemek standart hale geliyor. Veri kalitesi framework’leri, sadece içerik doğruluğunu değil, fiziksel saklama sağlığını da kontrol kapsamına alıyor.

9. Karar çerçevesi: Hangi araç ne zaman?

Operasyonel kararı bir flowchart yerine prensiplere indirgemek mümkün. Birinci prensip: Önce ölç — pgstattuple_approx ile gerçek bloat’ı bilmeden vacuum çalıştırmak gerekli olmayabilir veya yetersiz olabilir. İkinci prensip: Autovacuum’a önce şans ver — tablo-bazlı tuning ile %95 senaryoda yeterlidir. Üçüncü prensip: pg_repack veya pg_squeeze üretim için VACUUM FULL’dan üstündür; tek istisna planlı maintenance window ve PK eksikliğidir.

Modern veri mimarisi katmanında PostgreSQL operasyonel disiplini, başka veri katmanı kararlarını da etkiler. Data lakehouse ya da analytics warehouse kullanan ekipler, OLTP PostgreSQL’i CDC (change data capture) ile aktarırken bloat-induced lag artışını sıkça yaşar — bloat ne kadar yüksekse, WAL volume ve replication lag o kadar artar. Big data işleme pipeline‘larına PG’den veri akıtan Debezium connector’ları, tablo bloat’ı yüksekken snapshot fazında 2-3 kat yavaşlar.

1. Tablo bloat %30 altı, autovacuum çalışıyor: Aksiyon gerekmez, izleme yeterli.
2. Tablo bloat %30-60, autovacuum yetişemiyor: Tablo-bazlı autovacuum tuning (scale_factor düşür, cost_limit artır).
3. Tablo bloat %60+ aktif yazma yoğun: pg_repack veya pg_squeeze ile online reorg.
4. Tablo bloat %60+, maintenance window var: VACUUM FULL veya CLUSTER (daha hızlı).
5. İndeks bloat tek başına: REINDEX CONCURRENTLY, pg_repack -x.
6. Transaction yaşı >150M: Manuel VACUUM FREEZE schedule başlat.
7. Transaction yaşı >1.5B: Emergency mode — workload kes, freeze tamamla.

SSS — Sıkça Sorulan Sorular

Sonuç

PostgreSQL bloat yönetimi, MVCC mimarisinin doğrudan operasyonel maliyetidir ve görmezden gelinemez. 2026 itibarıyla doğru yaklaşım net: autovacuum’u tablo-bazlı agresif tune et, pgstattuple_approx ile haftalık bloat ölç, %60’ı geçen tabloları pg_repack veya pg_squeeze ile online reorganize et, transaction yaşını günlük monitor et. Bu dört disiplin bir araya geldiğinde 24/7 üretim PostgreSQL ortamları yıllarca downtime’sız çalışabilir.

Karar çerçevesinin merkezinde “ölç → tune → reorg” sırası vardır; sıralamayı bozmak — örneğin tuning yapmadan doğrudan pg_repack’a koşmak — zaman israfı ve gereksiz disk amplifikasyonudur. Aynı şekilde sadece monitoring yapıp tuning yapmamak, bloat’ın trend olarak büyümesini izleyip aksiyon almamak da sürdürülemez. PostgreSQL 17’nin BUFFER_USAGE_LIMIT, REINDEX CONCURRENTLY iyileştirmeleri ve gelecek 18 sürümünün block-skipping VACUUM RFC’si bu disiplinin önümüzdeki 3-5 yılda otomatize olmaya devam edeceğine işaret ediyor.

OLTP veritabanlarınızı bloat yönetimi, autovacuum tuning ve online reorganization stratejisi açısından gözden geçirmek istiyorsanız iletişim sayfası üzerinden kapasite analizi talep edebilirsiniz; gerçek metriklere dayalı bir baseline çıkararak yıllık disk maliyetini ve potansiyel outage riskini birlikte değerlendirebiliriz.