Veritabanı Performans Ayarlama: Çevrimiçi Şema Değişimleri

Veritabanı Eğitimi İçin Doğru Model: Expand-Contract Dağıtımı

Çalışan sistemde NOT NULL sütun eklemek, büyük tabloda tek bir DDL komutu olmaktan fazlasıdır: uygulama eski ve yeni şema ile bir süre birlikte çalışmak zorundadır. Bu nedenle veritabanı eğitimi içinde ezberlenmesi gereken pratik model expand-contract yaklaşımıdır. Önce geriye uyumlu şemayı genişletin, uygulamanın iki alanı da yazmasını sağlayın, mevcut satırları küçük partilerle doldurun, okuma trafiğini yeni alana taşıyın ve en son eski alanı kaldırın. PostgreSQL tarafında aşağıdaki değişiklik, varsayılan değeri doğrudan sütun tanımına koymak yerine üç aşamaya ayırır; böylece uygulama sürümü ile DDL鈥檔in dağıtım sırası ayrıştırılır.

-- 1. Expand: mevcut istemcileri kırmadan nullable alan ekle
ALTER TABLE orders ADD COLUMN currency_code text;

-- 2. Backfill: kısa transaction'lar ve tekrar çalıştırılabilir iş
UPDATE orders
SET currency_code = 'TRY'
WHERE id > :last_id
  AND id <= :last_id + 10000
  AND currency_code IS NULL;

-- 3. Uygulama yeni alanı yazmaya başladıktan sonra doğrula
ALTER TABLE orders
  ADD CONSTRAINT orders_currency_code_present
  CHECK (currency_code IS NOT NULL) NOT VALID;

ALTER TABLE orders
  VALIDATE CONSTRAINT orders_currency_code_present;

Buradaki NOT VALID ayrıntısı önemlidir: kısıt yeni yazılan satırlara hemen uygulanır, mevcut tablonun taraması ise sonraki VALIDATE adımına taşınır. Bu, uzun süren tarama ile kısıt ekleme anındaki kilit davranışını ayırır; ancak uygulama backfill tamamlanmadan önce currency_code okumaya geçerse halen NULL görebileceğinden okuma kodunda geçici fallback bulunmalıdır.

SQL Eğitimi Perspektifiyle Kilit Penceresini Ölçmek

Şema değişikliği öncesinde 'bakım penceresi yeterli mi?' sorusunu tahminle değil, üretime yakın veri hacminde kilit telemetrisiyle cevaplayın. SQL eğitimi kapsamında özellikle DDL鈥檔in beklediği kilidi ve onu bloke eden oturumu ayırt etmek gerekir. PostgreSQL鈥檇e migration çalışırken aşağıdaki sorguyu 1-2 saniye aralıkla kaydedin; wait_event_type = 'Lock' olan satırlar ile pg_locks.granted = false satırları, komutun veri taramasından mı yoksa başka bir transaction鈥檇an mı beklediğini gösterir.

SELECT a.pid,
       a.usename,
       a.application_name,
       a.state,
       a.wait_event_type,
       a.wait_event,
       now() - a.xact_start AS transaction_age,
       left(a.query, 180) AS query
FROM pg_stat_activity a
WHERE a.datname = current_database()
  AND (a.wait_event_type = 'Lock'
       OR a.xact_start < now() - interval '2 minutes')
ORDER BY a.xact_start NULLS LAST;

Ölçümde yalnızca migration süresini değil, p95 uygulama sorgu gecikmesini, lock wait sayısını ve en yaşlı açık transaction süresini önce-sonra karşılaştırın. Örneğin değişiklik öncesi 500 ms olan sipariş oluşturma p95'i migration sırasında 8 s'ye çıkıyorsa, kök neden çoğu zaman DDL değil; connection pool'dan alınmış ve commit edilmemiş bir transaction'ın DDL kuyruğunu uzatmasıdır. PostgreSQL için migration bağlantısına SET lock_timeout = '3s'; SET statement_timeout = '15min'; uygulamak, sonsuz bekleyen dağıtım yerine kontrollü hata üretir; hata alan pipeline aynı migration'ı idempotent biçimde tekrar deneyebilmelidir.

SQL Server Eğitiminde Çevrimiçi İndeks ve Migration Riski

SQL Server eğitimi sırasında sık atlanan ayrım, çevrimiçi indeks işleminin tamamen kilitsiz olmamasıdır. ONLINE = ON, veri taşıma fazında eşzamanlı DML'ye izin verebilir; fakat başlangıç ve son aşamada şema kilidi ihtiyacı devam eder. Yoğun API trafiğinde bekleyen bir okuma transaction'ı bile bu kısa aşamayı uzatabilir. Enterprise/Azure SQL yetenekleri bulunan ortamlarda aşağıdaki yapı, düşük öncelikte belirli süre bekleyip bloklayıcıları öldürmek yerine kendi işlemini durdurur; operasyon ekibi sonraki pencerede devam ettirebilir.

CREATE INDEX IX_Orders_CustomerId_CreatedAt
ON dbo.Orders(CustomerId, CreatedAt)
INCLUDE (Status, TotalAmount)
WITH (
  ONLINE = ON (
    WAIT_AT_LOW_PRIORITY (
      MAX_DURATION = 5 MINUTES,
      ABORT_AFTER_WAIT = SELF
    )
  ),
  RESUMABLE = ON,
  MAX_DURATION = 30 MINUTES
);

RESUMABLE = ON ile yarım kalan işi ALTER INDEX IX_Orders_CustomerId_CreatedAt ON dbo.Orders RESUME; komutuyla sürdürmek mümkündür; ancak bunu migration aracının işlem (transaction) sarmalına koymayın. Araçların DDL transaction'ı açması, hata durumunda geri alma maliyetini ve log büyümesini artırabilir. Ayrıca database indexleme kararında 'online' seçeneğini varsayılan kabul etmek hatalıdır: ek indeks her INSERT, UPDATE ve DELETE işleminde bakım maliyeti üretir. Dağıtımdan önce sys.dm_db_index_usage_stats ile hedef tablonun yazma/okuma oranını, dağıtımdan sonra ise Query Store üzerinden aynı sorgu kimliğinin ortalama süre ve logical read değerlerini karşılaştırın.

Veritabanı Optimizasyonu: Backfill İşini Trafikten Ayırmak

Veritabanı optimizasyonu açısından en tehlikeli migration türü, milyonlarca satırı tek transaction içinde güncelleyen backfill işidir. Tek transaction; WAL veya transaction log'un uzun süre tutulmasına, replika gecikmesine ve rollback gerektiğinde aynı büyüklükte ikinci bir yazma dalgasına neden olur. Backfill worker'ını anahtar aralığıyla, sınırlı batch boyutuyla ve her batch sonunda commit edecek şekilde tasarlayın. PostgreSQL örneğinde FOR UPDATE SKIP LOCKED, aynı işi paralel çalıştıran worker'ların birbirinin satırını beklemesini önler.

WITH batch AS (
  SELECT id
  FROM orders
  WHERE currency_code IS NULL
  ORDER BY id
  FOR UPDATE SKIP LOCKED
  LIMIT 5000
)
UPDATE orders o
SET currency_code = 'TRY'
FROM batch
WHERE o.id = batch.id
RETURNING o.id;

Batch boyutunu sabit bir dogma olarak kullanmayın: pg_stat_replication içindeki replay gecikmesi, WAL üretim hızı ve uygulama p95 gecikmesi ile geri beslemeli ayarlayın. Örneğin replika gecikmesi 30 saniyeyi aşınca worker sayısını 4'ten 1'e düşürmek veya batch'i 5000'den 500'e indirmek, okunabilir replikalarda stale veri bütçesini korur. SQL Server'da eşdeğer gözlem için sys.dm_hadr_database_replica_states ve transaction log tüketimi için sys.dm_db_log_space_usage kullanılabilir; yalnızca CPU grafiği bu yazma baskısını göstermez.

NoSQL Eğitimi ve Şema Evriminde Okuma Uyumluluğu

NoSQL eğitimi alan ekiplerde şemasız depolamayı şema evrimi gerektirmiyor sanmak yaygın bir üretim hatasıdır. MongoDB'de aynı koleksiyonda eski belgenin fullName, yeni belgenin ise profile.name taşıdığı dönem, sorgu ve indeks seçiciliğini doğrudan etkiler. Okuyucuyu geçiş süresince iki biçimi de anlayacak şekilde yazın; sonra arka plan güncellemesiyle belge biçimlerini birleştirin ve yalnızca yeni alan için indeks oluşturun.

db.users.updateMany(
  { 'profile.name': { $exists: false }, fullName: { $type: 'string' } },
  [
    { $set: { profile: { name: '$fullName' } } },
    { $unset: 'fullName' }
  ]
)

db.users.createIndex(
  { 'profile.name': 1 },
  { name: 'users_profile_name', partialFilterExpression: { 'profile.name': { $exists: true } } }
)

Bu örnekte partial index, eski belge popülasyonunu indekse yazmadığı için indeks boyutunu ve yazma maliyetini sınırlar. Ancak sorgu filtresi partial filtreyle mantıksal olarak uyumlu değilse sorgu planlayıcı indeksi kullanmayabilir; bunu varsaymak yerine db.users.find({'profile.name':'Ada'}).explain('executionStats') çıktısındaki totalDocsExamined ve totalKeysExamined değerlerini geçiş öncesi ve sonrası kaydedin. Böylece veritabanı performans ayarlama çalışması, yalnızca migration'ın bittiği zamanı değil, yeni veri modelinin gerçekten daha az belge tarayıp taramadığını da doğrular.

Sık Sorulan Sorular

Veritabanı performans ayarlama sırasında şema migration kilidini nasıl ölçerim?

PostgreSQL'de migration boyunca pg_stat_activity ve pg_locks çıktısını periyodik kaydedin; lock bekleyen PID'nin açık transaction yaşını ölçün. SQL Server'da sys.dm_exec_requests, sys.dm_tran_locks ve blocked process report ile bekleme zincirini çıkarın. Karşılaştırmada migration öncesi ve sırasındaki p95 istek gecikmesi, lock wait süresi ve replika gecikmesini aynı zaman penceresinde kullanın.

SQL Server eğitiminde ONLINE index neden uygulama kesintisini tamamen engellemez?

ONLINE = ON veri oluşturma aşamasında eşzamanlı DML'yi desteklese de indeks işleminin başlangıç ve son aşamalarında şema kilidi gerekir. Uzun açık transaction bu kilidi geciktirebilir. WAIT_AT_LOW_PRIORITY ile bekleme süresini sınırlayın, RESUMABLE = ON kullanın ve işlemden sonra Query Store'da duration, CPU ve logical read regresyonu olup olmadığını sorgu kimliği bazında kontrol edin.

Database indexleme backfill işleminden önce mi sonra mı yapılmalı?

Yeni alanı dolduran UPDATE işlemi, o alan üzerindeki indeks varsa her satırda indeks bakımı yapar; bu nedenle çoğu senaryoda önce backfill, sonra indeks daha düşük toplam yazma üretir. Fakat uygulama backfill devam ederken yeni alanla seçici sorgu çalıştırmak zorundaysa, partial index veya filtreli index ile yalnızca doldurulmuş satırları indeksleyin. Kararı explain plan, write throughput ve indeks boyutu ölçümleriyle verin.

NoSQL eğitimi için MongoDB şema değişiminde eski belgeler nasıl yönetilir?

Okuyucu kodunu geçiş döneminde hem eski hem yeni alanı çözebilecek biçimde dağıtın, yeni yazımları yalnızca yeni şemaya yönlendirin ve updateMany işlemini idempotent bir filtreyle batch halinde çalıştırın. Ardından explain('executionStats') ile belge tarama sayısını doğrulayın; eski alanı ancak tüm tüketiciler yeni sürüme geçtikten sonra kaldırın.