Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek
“Linked Server” Bitti mi? Modern Çağın Federasyonunu Keşfet
Açıkçası, Şöyle bir dürüstçe sorayım: Eski “linked server” hikayesini kim unuttu? Bir ara hepimiz “bağla, çek, göster” kafasındaydık; iş de yürüyordu açıkçası. İstanbul’daki o telekom projesinde şehirlerarası SQL’leri linked server ile birbirine bağladığımda ekipten bayağı ses çıkmıştı, iyi anlamda. Kolaydı çünkü. Hatta beklediğimizden pratikti. Ama sonra işler değişti. Veri artık tek bir SQL sunucusunda oturmuyor; Postgres var, Cosmos DB var, bulutta dolaşan servisler var… Üstüne bir de herkes “bana özel sandbox lazım” deyince, eski yöntemler elde kalıyor resmen.
Peki şimdi ne yapacağız? Linked server’a izin yoksa ya da kullanmak mümkün değilse, farklı veritabanlarından gelen datayı tek yerden kullanıcıya nasıl göstereceğiz? Uygulama geliştiricilerin şemaya dokunması da yasaksa… Cross-database açmayı düşünmek bile gereksiz.
Zincirin Gücü: Data API Builder ile Pratik Kompozisyon
Bak şimdi, Birkaç ay önce Logosoft tarafında bu konuyla karşılaştım; büyük bir bankanın bulut göçü operasyonunda tablo öyleydi ki insan bakınca “bu iş buradan nasıl toparlanacak?” diye düşünüyor. Milyonlarca ürün kaydı SQL’de duruyor, depo stoğu başka vendor’ın yönettiği Postgres üzerinde ve öneri motorunun çıktısı Cosmos DB’ye düşüyor… Lafı gevelemeden söyleyeyim: Hepsinden canlı veri çekip tek REST API’dan sunmak şart olmuştu.
Data API Builder (DAB) burada baya iş görüyor. Hatta geçen yıl detaylarına şurada değinmiştim. Ama zincirleme kombinasyon kısmı ayrı bir dünya gerçekten!
aynı anda sorgu atabiliyorsunuz — kod satırı yazmadan!
Neden DAB Chaining?
- Sınırlı erişim: Şemayı değiştirmeye ya izin yok ya da ekip kapıyı kapatıyor mu? Fark etmez, çözüm yine geliyor.
- Karma platformlar: Veri MS SQL’den çıkıp Postgres’e sapabilir — sıkıntı çıkmadan ilerleyebiliyorsunuz.
- Kullanıcı deneyimi: Tek istekle full yanıt alıyorsun; hız da fena değil hani.
Zinciri Oluşturmak Kolay mı?
Açık konuşayım; ilk bakışta kafa biraz karışıyor. “sp_invoke_external_rest_endpoint” fonksiyonu devreye girince işi doğrudan veritabanının içinde çevirebiliyorsun. Eskiden uygulamada call-a-call modeli kurardık ya, şimdi aynı mantığı SQL prosedürünün içine gömmek mümkün oluyor. Garip geliyor başta — alışınca gayet keyifli aslında. Daha fazla bilgi için Azure SQL’de DiskANN Vektör İndeksleri: Gerçekten Neler Değişti? yazımıza bakabilirsiniz.
DAB Zincirlemenin Temel Senaryosu: Gerçek Hayattan Bir Örnek
Senenin ilk aylarında e-ticaret müşterisinde pat diye önümüze şöyle bi tablo çıktı:
| # | Açıklama | Sistem / Kaynak |
|---|---|---|
| 1 | Katalog & ürün temel bilgisi | MSSQL (DB1) |
| 2 | Anlık stok durumu & envanter işlemleri | PostgreSQL (DB2 – dış vendor) |
| 3 | Tavsiye edilen benzer ürünler / ilişkiler | Cosmos DB (DB3 – ML output’u) |
Tek istekte her kaynaktan zenginleştirilmiş data dönmek gerçek mi hayal mi?
Vallahi oluyor! Yalnız bazı ince detayları ve beklenmedik tuzakları var…
Şöyle söyleyeyim, Müşteri dedi ki:
“Kullanıcı ürünü görüyor tamam da, stoğunu canlı bilsin istiyorum;
bir yandan makine öğrenmesiyle gelen benzer ürünleri de sıralayın.”
Güzel istekler (kendi tecrübem). Fakat stok başka yerde,
öneri bambaşka sistemde geziniyor.
Şimdi sen karar ver:
Tüm parçaları anında toplamak için hangi yolu denersin? Bu konuyla ilgili SQL Server 2025’te JSON Depolama: Artık Sadece NVARCHAR’a Mahkûm Değiliz! yazımıza da göz atmanızı tavsiye ederim.
Senkron Zincirleme Tasarımı Nasıl İşler?
Tüm İşlem Tek Akışta Gerçekleşiyor mu?
İlginç olan şu ki, Eğer her şeyi senkron tutacağım diyorsan—yani kullanıcı butona bastığında her kaynaktan gerçek zamanlı cevap gelsin istiyorsan—ilk bakışta kolay görünüyor. Ama ufak(!) risklere hazır ol… Bir sistem geciktiğinde domino gibi hepsi yavaşlıyor!
CREATE OR ALTER PROCEDURE dbo.sp_GetProduct
@productId INT,
@userId INT
AS
BEGIN
SET NOCOUNT ON;
— Katalogdan ürünü al (DB1)
— REST endpoint ile depo stoğunu çek (DB2)
— REST endpoint üzerinden önerilen ürünleri çek (DB3)
— Sonuçları şekillendirip döndür
END
GO
Ankara’daki lojistik raporunda bunu ilk defa canlı test ettim; tarih 2019’du yanlış hatırlamıyorsam. Beklediğim şey olmadı desem yeridir. REST çağrıları arka arkaya sıraya (belki yanılıyorum ama) girince ikinci ve üçüncü uç noktanın cevabını almadan iş ilerlemiyor. Yani paralellik sıfır gibi bir şey! Her veri parçası sıradaki kardeşi bitmeden gelmiyor maalesef… Peki, daha fazla bilgi için VS Code’da MSSQL Eklentisinde Neler Değişti? Yapay Zekâlı Şema Tasarımı ve Daha Fazlası yazımıza bakabilirsiniz.
Senkron Modelde Karşılaşılan Tuzaklar Nelerdir?
- Kritik nokta şu:
süreklilik/freshness vs gecikme/latency dengesi darmadağın olabilir. - Ağ koparsa veya ilgili servis cevap vermezse
Kullanıcının ekranda saat başına dönmesine neden olursunuz ya da eksik datayla ekran dizmek zorunda kalırsınız. - Maliyet detayı unutulmamalı.
Hele dış vendor ücretlendiriyorsa istek/adediyle — faturaya dikkat! - Tamamen zincire bağımlısın;
Arada biri çökünce tüm akış bozulur.- Kişisel tavsiye:
Böyle ortamlarda failover/kesinti planınız mutlaka olsun;
Yoksa gece vakti telefonunuz susmaz!
- Kişisel tavsiye:
Zincirde Alternatif Modeller ve Tasarım İpuçları
B Planı Var mı? Asenkron & Ön-Hazırlıklı Çözümler
Şunu söyleyeyim, Bazen “her şey o an canlı olsun!” demek gereksiz pahalı ya da risklidir (inanın bana). Önden hazırlanan cache veya ara tablo kullanımı tam tersine hız sağlar ama en güncel bilgiyi kaçırabilirsin.
Mesela geçen ay hibrit modelde sabah-akşam batch job’larla topluca depolardan bilgi çekip ara tabloda sakladık — sorgular jet gibi çalıştı; ama acil stok değişikliğini birkaç dakika geç gösterdik diye müşteri servisine ekstra yük bindirdik! Her tercihin artısı eksisi var yani… Kısacası, daha fazla bilgi için VS Code’da MSSQL Eklentisinin 1.40 Güncellemesi: Gerçekten Fark Yaratıyor mu? yazımıza bakabilirsiniz.
• Zinciri bayağı uygulama katmanına bırakınca hız kazanılır fakat bakım işleri karmaşa çıkarır.
• Veritabanındaki prosedürlerle kurarsanız kontrol sizdedir fakat debug/migration işiniz uzar.
• Mesela finans sektöründe politika kısıtlarını hiç küçümsemeyin – kaç defa yolum kesildi saymadım!
Pratik örneklerle devam etmek isteyenlere:
Polyglot Veritabanı Maliyeti: Tüm Yumurtaları Aynı Sepete Koymanın Bedeli Ne?.
Küçük Startup İçin Mi Enterprise’a Göre mi Daha Uygun?
- Ekip minikse veya startup’sa,
API kompozisyonu çoğu zaman hızlıca çözüme ulaşmanı sağlar.
Fakat kurumsal firmalarda yönetmelikler ve cross-team kararlar yüzünden genelde iş database katmanına yığılır —
Logosoft’taki son projede compliance onayı olmadan taş üstüne taş koyamadık örneğin…
Hızlı hareket sevenler için el freni gibiydi!
DAB Chaining’in Pratikte Güzel Yanları ve Sancılı Köşeleri
Nerede Parlıyor Nerede Zorluyor?
| DAB Chain Avantajları | Sıkıntılı Noktalar | ||
|---|---|---|---|
| Hızlı entegrasyon Çeşit çeşit sistemde esneklik Kod yükü azalır API seviyesinde federasyon desteği Cloud-native uyumlu yapı |
Her işlem peş peşe gidiyor — paralellik yok Ağda takılan uç noktalar herkesi bekletir Politika nedeniyle debugging kabusa dönebilir Compliance-süreçlerinde evrak trafiği oluşur |
||
| (Bazı avantajlara kanıp heveslendim zamanında; ama kurum içi network/politika duvarlarına takıldığımda anladım ki gerçek hayatta işler kağıttaki kadar pürüzsüz ilerlemiyor!) |
|||
AZ-305 sınavına hazırlanırken kafa patlattığım ilk mimarı buydu — konsept çok parlak ama iş pratiğe gelince ağ politikası bazen insana saç baş yolduruyor!
Zincirin Koduna Dalalım mı? Basitleştirilmiş Demo Senaryo!
-- Not: Bu prosedür demo amaçlı sadeleştirildi!
CREATE OR ALTER PROCEDURE dbo.sp_GetProductFullInfo
@productId INT,
@userId INT
AS
BEGIN
SET NOCOUNT ON;
-- Adım 1: Ana ürün bilgisini DB1'den getir.
SELECT * FROM Products WHERE ProductId = @productId;
-- Adım 2: Depo stoğunu REST üzerinden sorgula.
EXEC sp_invoke_external_rest_endpoint
@url = 'https://warehouse-vendor/api/inventory/' + CAST(@productId AS VARCHAR),
@method = 'GET',
@headers = '{''Authorization'': ''Bearer xyz...''}';
-- Adım 3: Önerilen ürünleri Cosmos DB'den çek.
EXEC sp_invoke_external_rest_endpoint
@url = 'https://cosmos-api/products/' + CAST(@productId AS VARCHAR) + '/related',
@method = 'GET';
-- Sonuçları birleşik formatta şekillendirip döndür.
END;
GO
-- Not: Gerçek dünyada error handling/logging/vb gerekli!
Labaratuvarda oynarken sıkıntısız ilerledi tabiî —
Ama prod ortamına geçtiğimiz anda log sayısını artırdık ve hata yönetimini güçlendirdik çünkü network/time-out problemleri er ya da geç mutlaka çıkıyor arkadaşlar…
Hele bir de cloud’da latency’yi stabil tutmak ciddi mesele. Burada Azure Monitör’un (bakabilirsiniz buradan 🡕)) yardımı büyük oluyor.
Peki Ya Gelecek? Federation’ın Evrimi Nereye Gidiyor?
No-Code’dan AI Destekliye Yolculuk…
Geliştiriciye dayanan külfet artık iyice servislerin ve gömülü araçların omuzuna doğru kayıyor sanki… Hafta başında bir takipçi blogdan yazmıştı:“Abi no-code araçlarla federasyonu hallediyoruz diyebilir miyiz?” Kesin konuşmam zor ama DAB’in yeni sürümlerindeki otomatik şema kurucu ve MCP desteklerini görünce umutlandığımı saklayamam. Burada uzun uzun yazdığım gibi; kod derdi azaldıkça IT hayatımız kolaylaşacak galiba… Veya fazla rehavet iyi midir bilmiyorum:)
Evet, doğru duydunuz.
tabiî süreç oturursa! Tavsiye ederim —
yarın denerseniz sonucu yorumlara bırakın;\)
Sıkça Sorulan Sorular
DAB chaining ne demek? Ne zaman işe yarıyor?
DAB chaining dediğimiz şey aslında çok basit: birden fazla veritabanından veriyi sırayla çekip tek seferde getiriyorsun. Hani federasyon mantığının pratik hali diyelim. Linked server yasak mı, karışık teknoloji yığını mı var, yoksa politikalar mı boğuyor? O zaman tam da aradığın şey bu :)
sp_invoke_external_rest_endpoint hangi sürümlerde çalışıyor?
Bu fonksiyon Azure SQL Database’de zaten hazır geliyor ama on-premise klasik SQL Server’da varsayılan olarak açık değil (ciddiyim). Açıkçası teknik şartlar ve desteklenen sürümler için Microsoft’un kendi dokümantasyonuna bir göz atmak şart — orası sürekli güncelleniyor.
Senkron zincirde performans nasıl etkileniyor?
Her adım sırayla işlediği için herhangi bir uç noktanın yavaşlaması tüm toplam süreyi doğrudan etkiliyor. Yani zincirin en yavaş halkası her şeyi geriletebiliyor. Bence kritik noktalarda latency’yi iyi izlemek gerekiyor, timeout. Hata yakalama mekanizmalarını da baştan düzgün kurmak şart!
Zinciri uygulama tarafında değil de neden veritabanında kurmalıyız?
Bazen uygulamanın erişimi güvenlik veya yetki sorunlarından dolayı kısıtlı olabiliyor. Böyle durumlarda federasyonu veritabanı tarafında merkezileştirmek çok daha kontrollü bir yapı sağlıyor. Tabii bakım yükünün de arttığını hesaba katman gerekiyor. Tecrübeme göre özellikle finans ve regülasyon gerektiren projelerde bu neredeyse zorunlu hale geliyor (en azından benim deneyimim böyle)
Kaynaklar ve İleri Okuma
- Orijinal Blog Yazısı – Data API Builder Chaining
- Microsoft Docs – sp_invoke_external_rest_endpoint Açıklaması
- Resmî Data API Builder Belgeleri
- Birden Fazla Veritabanını Tek API ile Bağlamak – Kendi Deneyimlerim (Blog)
- Veriye Akıllıca Soru Sormak İçin MCP Destekli DAB Üzerine Blog Yazım — bunu es geçmeyin
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder