Skip to main content

> monoliti_parçalamak:_mikroservisler_arasında_i̇lişkisel_yabancı_anahtarları_(foreign_keys)_ayırma_stratejileri

Monoliti Parçalamak: Mikroservisler Arasında İlişkisel Yabancı Anahtarları (Foreign Keys) Ayırma Stratejileri

İlişkisel bir monolit veritabanını ayrı mikroservis veritabanlarına bölmek neden çok risklidir; yabancı anahtar (FK) kısıtlamaları, çapraz SQL JOIN sorguları ve dağıtık işlemler nasıl güvenle ayrıştırılır?

Principal/Architect (L7+)

ÖZET VE TEKNİK CEVAP

Mikroservis geçişlerindeki en zorlu engel uygulama kodunu bölmek değil, **Paylaşılan İlişkisel Veritabanını Parçalamaktır**. Monolitte geliştiriciler veritabanı motorunun sağladığı süper güçlere güvenir: `FOREIGN KEY (kullanici_id) REFERENCES kullanicilar(id)`, tablolar arası SQL `JOIN` sorguları ve tek işlemde ACID garantisi. Sistem bağımsız servislere (`KullaniciServisi` ve `SiparisServisi`) bölündüğünde bu yetenekler bir gecede yok olur: (1) **Yabancı Anahtarlar (FK) Yok Olur**: `siparisler.kullanici_id` artık veritabanı denetimi olmayan düz bir sayıya dönüşür; kullanıcı silinirse arkada sahipsiz (orphaned) siparişler kalır. (2) **Veritabanları Arası SQL JOIN Yapılamaz**: Kullanıcı, sipariş ve ödeme tablolarını birleştiren tek bir SQL sorgusu yazılamaz. (3) **Dağıtık ACID İşlemleri İmkansızlaşır**: Stok düşme ve karttan para çekme aynı SQL işlemine sokulamaz. Canlı projeler bunu **4 Aşamalı Veri Ayrıştırma Protokolü** ile yönetir: (1) SQL JOIN'leri kod içinde API/Hafıza birleştirmeleriyle değiştirmek, (2) Fiziksel FK kısıtlamalarını kaldırıp bütünlüğü koda taşımak, (3) Şemaları ayrı fiziksel veritabanlarına taşımak, ve (4) Veri tutarlılığını Olay Güdümlü Saga ve CDC ile sağlamak.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Veri ayrıştırma Genişlet-Daralt (Expand-Contract) modeliyle çalışır: (1) JOIN Sorgularını Kaldırma: `JOIN` sorgularını uygulama içinde iki adıma bölün: Önce siparişleri çekin, kullanıcı ID'lerini toplayıp Kullanıcı Servisinden toplu sorgulayın. (2) Sanal Yabancı Anahtarlar: Fiziksel `CONSTRAINT fk_kullanici` kuralını silin; kullanıcı kontrolünü sipariş oluşturulurken kod içinde API ile yapın. (3) Mantıksal Şema Ayrımı: Tabloları aynı sunucu içinde farklı şemalara (`kullanicilar_sema`, `siparisler_sema`) taşıyarak çapraz sorgu kalmadığını kanıtlayın. (4) Fiziksel Ayrım ve CDC: Şemayı tamamen bağımsız bir veritabanı sunucusuna taşıyın. Change Data Capture (Debezium) ile kullanıcı güncellemelerini Sipariş Servisindeki yerel önbellek tablosuna senkronize edin.

2. Doğru Kullanım Senaryosu

Eski monolitik ilişkisel veritabanlarını bağımsız mikroservis veritabanlarına bölme projeleri.

3. Prodüksiyon Arıza Modları

Veritabanlarını ayırırken servisler arasında iki aşamalı onay (2PC) işlemleri kullanıp tüm sistemi kilitlemek; bir serviste ana kaydı silip diğer servislerde sahipsiz (orphaned) milyonlarca çöp kayıt bırakmak.

4. Teşhis ve Telemetri Sinyalleri

Veritabanı ayrımı sonrası 'Cross-database references' hatalarının patlaması; tek bir SQL JOIN yerine N+1 adet HTTP çağrısı yapılması yüzünden ekranların yavaşlaması; kullanıcı durumu ile sipariş durumu arasında veri tutarsızlıkları.

5. Önleme ve Mimari Bariyerler

Olayla Taşınan Durum Aktarımı (ECST) kullanarak alt servislerin ihtiyaç duyduğu kullanıcı verisini yerel okuma kopyasında tutmasını sağlayın; fiziksel silme yerine Mantıksal Silme (`deleted_at`) kullanın ve silme olaylarıyla alt servisleri temizleyin.

6. Mimari Ödünleşimler (Trade-offs)

Veritabanlarını ayırmak takımlara tam bağımsız ölçeklenme ve dağıtım özgürlüğü verir; ancak anlık ACID garantisini feda eder ve olay güdümlü nihai tutarlılık mimarileri kurmayı gerektirir.

Vaka İncelemesi (TinyCTO Örneği)

Bir pazaryeri monolitik PostgreSQL veritabanını `KullaniciDB` ve `SiparisDB` olarak ikiye böldü. Başlangıçta sipariş verme işlemi kullanıcı bakiyesini tek bir SQL işlemiyle denetliyor ve FK ile kullanıcının varlığını garanti ediyordu. Ayrım sonrası sahte bir kullanıcı silindiğinde Sipariş veritabanında 20.000 sahipsiz sipariş kaldı. Ekip Olay Güdümlü Saga kurdu: Bir kullanıcı silindiğinde Kafka'ya `KullaniciKapatildi` olayı fırlatıldı. Sipariş Servisi bu olayı dinleyerek o kullanıcıya ait tüm bekleyen siparişleri otomatik iptal etti; yabancı anahtar olmadan iki izole veritabanı arasında tam veri bütünlüğü sağlandı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Bir veritabanı mikroservislere bölündüğünde SQL Yabancı Anahtar (Foreign Key) kısıtlamalarına ne olur?

Fiziksel veritabanı sınırları arasında var olamazlar ve silinmelidir; veri bütünlüğü uygulama kodu ve olay güdümlü saga akışlarıyla korunmalıdır.
Q2

Mikroservisler eksik olan çapraz SQL JOIN sorgularını nasıl çözer?

Olayla Taşınan Durum Aktarımı (ihtiyaç duyulan veriyi olaylarla yerel kopyaya çekmek) veya API Gateway / GraphQL üzerinde birleştirme yaparak.

Monoliti Parçalamak: Mikroservisler Arasında İlişkisel Yabancı Anahtarları (Foreign Keys) Ayırma Stratejileri — Sıkça Sorulan Sorular

Verileri fiziksel olarak ayrı sunuculara taşımadan önce neden mantıksal şemaları ayırmalısınız?

Tek veritabanı üzerinde çalışırken ve kolay geri dönüş imkanı varken, kod tabanında hiçbir gizli çapraz SQL JOIN sorgusunun kalmadığını kesin olarak kanıtlamak için.

Olayla Taşınan Durum Aktarımı (Event-Carried State Transfer - ECST) nedir?

Olay mesajlarının sadece varlık ID'sini değil, güncellenmiş tüm veriyi taşıdığı; böylece alt servislerin üst API'yi çağırmadan kendi yerel kopyalarını güncelleyebildiği mimari modeldir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Veritabanını bölmek yabancı anahtarları, SQL JOIN sorgularını ve ACID işlemlerini ortadan kaldırır.
  • ▸4 aşamalı geçişi izleyin: JOIN'leri kaldırın, FK'ları silin, şemaları ayırın, fiziksel olarak bölün.
  • ▸Servisler arasında yerel okuma kopyaları tutmak için Olayla Taşınan Durum Aktarımı (ECST) kullanın.
  • ▸Veri bütünlüğünü ve silme temizliklerini asenkron Saga iş akışları ile sağlayın.

Yaygın Yanılgılar

  • ✗Yanılgı: Mikroservisler arasında İki Aşamalı Onay (2PC) kullanılmaya devam edilebilir (Gerçek: 2PC yüksek gecikme, kilitlenme ve sistem çapında tek hata noktası yaratır).
  • ✗Yanılgı: Yeni bir projeye başlarken ilk günden veritabanları ayrılmalıdır (Gerçek: Erken veritabanı ayrımı iş sınırları oturmadan önce devasa bir karmaşa yaratır).

Karar Kılavuzu & Önceliklendirme

Mikroservis geçişlerinde veri kaybı yaşamamak için monolitik veritabanlarını Genişlet-Daralt modeli ve olay güdümlü saga'lar ile kademeli olarak ayrıştırın.

Doğrulanmış Kaynaklar & Referanslar