RDBMS’ten Cosmos DB’ye Geçiş: AI Asistanı Ne Kadar İşe Yarar?
Açık konuşayım: ilişkisel veritabanından NoSQL’e geçiş, bizim sektörde yıllardır “bir ara bakarız” diye ötelenen işlerin başında geliyor. Şirket tarafında karar vermek kolay gibi dürüyor, ama asıl mesele uygulama katmanına el değince başlıyor; şimdi Microsoft, Visual Studio Code’un içine gömülü bir AI destekli göç asistanı çıkarıp “biz bu işin %70’ını sız uğraşmadan halledelim” diyor. E peki, sonuç ne öldü? Bakalım gerçekten öyle mi.
Şahsen, Geçen hafta duyurulan Azure Cosmos DB Migration Assistant for RDBMS to NoSQL şu an public preview’da. SQL Server, PostgreSQL, Oracle, MySQL ve Db2’den Cosmos DB for NoSQL’e geçişi otomatikleştirmeyi hedefliyor. Hedef büyük. Ben ilk anda biraz şüpheyle yaklaştım, çünkü bu tarz araçların çoğu demo’da yüz gülduruyor, prod’a gelince insanın omzuna bakıyor; yine de mimarı tarafı fena değil, bunu da dürüstçe söyleyeyim.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Neden bu iş bu kadar zor? Önce sorunu netleştirelim
İlişkisel dünyadan NoSQL’e geçerken aslında sadece veritabanı değiştirmiyorsunuz. Düşünme biçimini değiştiriyorsunuz. Bu küçük gibi görünen fark, sahada çoğu ekibin hesap etmediği kadar yorucu oluyor; JOIN’sız hayatı pek sevmeyen geliştiriciye “şimdi bunları denormalize edip tek document yapacağız” dediğinizde yüz ifadesi zaten her şeyi anlatıyor.
Bunu yaşayan biri olarak söyleyeyim, İşin teknik tarafına girince klasik tıkanıklıklar hemen ortaya çıkıyor: (yanlış duymadınız)
- Denormalizasyon kararı: Hangi tablolar birleşecek, hangileri referans kalacak? Cevap schema’da değil, access pattern’de saklı.
- Partition key seçimi: Yanlış seçim yaparsanız sistemin boğazına oturuyor. Cosmos DB’deki “hot partition” mevzusu boşuna efsane olmadı.
- Index stratejisi: Otomatik indexleme rahat geliyor ama RU tüketimini sessizce yukarı çekebiliyor. — ciddi fark yaratıyor
- Uygulama kodu refactor: ORM’in yerini SDK çağrıları alınca iş sadece find&replace olmuyor; repository pattern’den transaction yönetimine kadar her şey yeniden düşünülüyor.
Kısacası manuel gittiğinizde önünüze beş altı ayrı uzmanlık alanı çıkıyor, hem de aynı anda (en azından benim deneyimim böyle). Microsoft’un asistanı tam bu noktaya parmak basıyor gibi dürüyor.
Asistan ne yapıyor peki?
Dürüst olmak gerekirse, VS Code içindeki Azure Cosmos DB extension’ına entegre edilmiş durumda. Yanı ayrı tool kurayım, başka pencereye geçeyim derdi yok; IDE’nın içinden ilerliyorsunuz — açıkçası bu bile rahatlatıcı. Arkada Azure Cosmos DB Agent Kit çalışıyor, yanı işin omurgası LLM agent yaklaşımına dayanıyor.
Aslında, Akış beş fazlı ilerliyor. Şöyle toparlayayım:
- Discovery — Şema DDL’ınız, varsa volumetric veriler, access pattern’ler ve repo’nuzdan dil/framework/ORM sinyalleri toplanıyor.
- Design — Optimal NoSQL data modelini öneriyor. Hangi entity embed olacak, hangisi reference kalacak; buna karar vermeye çalışıyor.
- Partitioning & Indexing — Partition key ve index stratejisi için tavsiye veriyor.
- Provisioning & Data Load — Hedef kaynakları açıyor ve dönüştürülmüş örnek veriyi yüklüyor.
- Code Migration — AI üretimli bir migration planı çıkarıp önü uygulamaya koyuyor.
Bana göre en iyi tarafı şu: üretilen bütün artefact’ler .cosmosdb-migration/ klasörüne yazılıyor. Yanı süreç bayağı izlenebilir, tekrar edilebilir ve versiyonlanabilir hâle geliyor. Bu ufak bir ayrıntı gibi görünüyor ama değil; çoğu AI aracının sıkıntısı “neden böyle karar verdin?” sorusuna düzgün cevap verememesi. Burada her faz dosya olarak dürüyor, code review’a sokabiliyorsunuz, Git’e atabiliyorsunuz.
Bence bu aracın asıl katkısı kod yazmak değil. Asıl katkı, deneyimsiz bir ekibin daha baştan kötü tasarım kararı almasını biraz olsun engellemesi. NoSQL tarafında erken verilen yanlış kararın faturası ağır oluyor.
Peki Türkiye’de durum nasıl?
Tuhaf ama, Konuya yerel taraftan bakınca tablo biraz tanıdık geliyor. Türkiye’de kurumsal müşteri tarafında Cosmos DB benimsenmesi global eğilimin gerisinde kalıyor; sebebi de çok karmaşık değil: core sistemlerin çoğu hâlâ Oracle veya SQL Server üstünde dönüyor, DBA ekipleri o ürünlere yatırım yapmış oluyor ve “niye değiştireyim?” sorusuna net bir TCO cevabı çoğu zaman çıkmıyor — bence çok yerinde bir karar —
Tam burada bu asistan ilginçleşiyor. Çünkü göç maliyetinin büyük kısmı insan gücüydü; üç dört kişilik ekibin aylarca aynı işe yüklenmesiydi. Bu süre bir buçuk iki aya inerse ROI hesabı başka yere kayıyor. Mesela e-ticaret, fintech ve oyun şirketleri için Cosmos DB’nın global dağıtım ve elastik ölçek avantajı zaten cazipti; sadece geçiş bariyeri vardı.
Maliyet kısmını da es geçmeyelim. Cosmos DB’nın RU bazlı fiyatlandırması TL ile bakınca ilk anda insanın kaşını kaldırıyor, evet öyle bir his var (ciddiyim). Ama şunu da unutmayalım: ilişkisel tarafta ödediğiniz lisans, donanım, DBA. İlginç, değil mi? HA/DR maliyetlerini yan yana koyunca doğru kurgulanmış bir Cosmos DB workload’u çoğu zaman daha mantıklı çıkabiliyor; tabiî burada kilit kelime doğru tasarlanmış, çünkü yanlış partition key ile fatura bir anda kabarıyor.
Küçük ekip mi büyük kurum mu?
Eğer 5-10 kişilik bir startup ekibiniz varsa ve hâlâ MVP aşamasındaysanız: bu asistan size biraz zaman kazandırır, belki yarım gün belki de birkaç gün; güzel ama oyunun kaderini tek başına değiştirmez.
Hani, Ama elinizde 200+ tablolu, on yılı geçmiş bir monolith ilişkisel uygulama varsa işler değişiyor — burada asistan baya iş görüyor çünkü o karmaşıklığı elle çözmek tek başına aylar alabiliyor. Yine de önemli uyarıyı söylemeden geçmeyeyim: dönen çıktıyı körü körüne uygulamayın. Neden önemli bu? Discovery sonrası gelen modeli mutlaka kıdemli biriyle gözden geçirin; AI bazen access pattern’i ters okuyabiliyor.
Bakalım beş fazda neler oluyor?
Discovery: adı sakın ama en kritik yer burası
“Keşif” deyip geçiyoruz ama aslında migration’ın kaderi burada çiziliyor desek abartmış olmayız. Asistan DDL’i parse ediyor, repo içindeki kodu tarıyor. Hangi query’lerin sık çalıştığını anlamaya uğraşıyor; sız access pattern bilgisini ayrıca verirseniz — ki bence vermelisiniz — çıkan model belirgin biçimde daha işabetli oluyor (evet, doğru duydunuz)
İşte tam da bu noktada devreye giriyor.
Eh, Sahada gördüğüm en yaygın hata şu öldü hep: ekipler “nasıl olsa AI çözer” diye discovery’ye yeterince vakit ayırmıyor. Sonra Design fazında çıkan modeli görünce “bu bizim sisteme uymamış” diyorlar. Tabi uymayacak — sız veri girişi yapmadınız ki? Neyse uzatmayayım ama mesele tam olarak bu.
Design: Embed mi kalsın reference mı?
NoSQL modellemenin klasik sorusu bu zaten. Asistan burada kardinaliteye bakıyor, okuma/yazma oranını tartmaya çalışıyor (yanlış duymadınız). Update sıklığını hesaba katıp öneri veriyor; tipik bir örnek üzerinden gidersem durum şöyle görünüyor:
// İlişkisel: Customer ve Orders ayrı tablolar (JOIN ile birleşiyor)
Customers (CustomerId, Name, Email)
Orders (OrderId, CustomerId, Date, Amount)
// NoSQL önerisi (embed):
{
"id": "cust-001",
"partitionKey": "cust-001",
"name": "Ahmet Yılmaz",
"email": "ahmet@example.com",
"recentOrders": [
{ "orderId": "ord-501", "date": "2026-06-12", "amount": 1250 },
{ "orderId": "ord-498", "date": "2026-06-10", "amount": 340 }
]
}Bazen daha da akıllıca davranıp hibrit model öneriyor; mesela eski siparişleri ayrı container’a taşırken son 10 siparişi embed bırakmak gibi fikirler sunabiliyor. Bu detay önemli çünkü unbounded array problemi NoSQL tarafının en sinsi tuzaklarından biri oluyor.
Bölüm bölüm ilerleyelim mi? Partitioning kısmı öyle istiyor
Doğrusu, Peki neden? Çünkü partition key seçimi hata affetmeyen kararların başında geliyor da ondan. Asistan cardinality analizi yapıp tavsiye veriyor; bu konuda Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor yazımda detaylı anlatmıştım — iyi haber şu ki artık değiştirmek mümkün sayılır ama yine de en doğrusu baştan doğru seçmek oluyor.
İşte tam da bu noktada devreye giriyor.
Provisioning ve Data Load biraz mekanik kalıyor
Küçük bir detay: Burası diğer fazlara göre daha düz ilerliyor diyebilirim. Hedef account açılıyor, database ve container’lar oluşturuluyor; sample data yüklenince sonraki kod migration adımı test edilebilir hâle geliyor. Bicep/ARM template üretmesi de hoş bir artı çünkü IaC tarafınızı da toparlayabiliyorsunuz.
Error olabilir mi? Code Migration en heyecanlı ama en şüpheli kısım
Işte burada AI mevcut ORM kodunu Cosmos DB SDK çağrılarına çevirmeye çalışıyor. Demo ortamında seyretmesi güzel dürüyor ama gerçek hayatta özellikle complex transaction’lar, stored procedure’ler (ilk duyduğumda inanamadım). Trigger logic söz konusuysa üretilen kodu kontrol etmeden production’a almak bana göre akıllıca olmaz; başlangıç noktası olarak kullanın yeter.
Klasik araçlardan fark nerede?
Daha önce Microsoft’un Data Migration Tool, Cosmos DB Migration Service gibi araçları vardı zaten; onlar daha çok veri taşımaya odaklanıyordu. Bu yeni asistanın farkı işe taşımadan önce tasarımısorgulaması diyebiliriz:
| Özellik | Eeski Migration Tool’tan beklenenler değilse ne olur? |
|---|