Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor
Azure Cosmos DB ile çalışan ekiplerin canını en çok sıkan şeylerden biri, yanlış seçilmiş bir partition key yüzünden aylar sonra duvara toslamak oluyor. İlk günlerde her şey yolunda gidiyor; trafik düşük, veri küçük, sorgular da masum görünüyor. Sonra ürün büyüyor, erişim paterni değişiyor. Bir bakıyorsunuz hot partition yüzünden RU tüketimi zıplamış, bazı sorgular fan-out yapmaya başlamış, gecikme de sessizce yukarı tırmanıyor. İşin aslı şu: partition key seçimi sadece teknik bir detay değil, mimarinin omurgası.
📋 İçindekiler
-
Küçük ekip mi, kurumsal yapı mı?
Eh, Küçük ekipler için önerim basit: önce yeni partition key ile gerçekten hangi sorguların iyileştiğini ölçün, sonra taşıyın. Çünkü her migration emek ister ve bütçe küçükse gereksiz deneme lüksünüz olmayabilir.
Bir şey dikkatimi çekti: Büyük kurumlarda işe iş biraz daha formal ilerlemeli. Test ortamında online copy sürecini birebir simüle etmek şart olurdu benim gözümde (özellikle regülasyonlu sektörlerde). Ayrıca uygulama katmanında connection string / container referansı değişimini nasıl yöneteceğinizi önceden netleştirin. Yoksa canlıya çıkınca herkes birbirine bakıyor.
Sahada nasıl uygulanır?
Ne yalan söyleyeyim, Geçen yıl İzmir’de bir lojistik firmasına danışmanlık verirken benzer bir geçiş planladık ama o zaman Change Partition Key GA değildi; mecburen paralel yapı kurduk. Oldukça uğraştırdı bizi. Şimdi aynı senaryoda portal üzerinden job başlatıp ilerlemeyi izlemek çok daha temiz olurdu diye düşünüyorum.
Süreç kabaca üç parçaya ayrılıyor: job başlatma, ilerlemeyi izleme ve cutover yapma. Online modda kaynak container’daki yazmalar hedefe taşınmaya devam ediyor; sız de portal üzerinden doküman sayısını takip ediyorsunuz. Kopya neredeyse tamamlandığında yazmayı durdurup işlemi bitiriyorsunuz. Kulağa basit geliyor ama şey… canlı sistemde basit görünen işler bazen gece yarısı alarmına dönüşebiliyor.
# Pratik kontrol listesi 1) Mevcut access pattern'i çıkar 2) Yeni partition key için query'leri test et 3) Online copy job'u test ortamında dene 4) Cutover zamanını düşük trafikte planla 5) Uygulama tarafında bağlantı geçişini hazır tut 6) Eski container'ı hemen silme; kısa süre doğrulama bırakNerede hata yaptım?
Bunu saklamayayım: İlk Cosmos DB göçlerinden birinde destination container’ı doğru hazırladığımız hâlde throughput tarafını hafif tutmuşuz ve kopyalama sırasında beklediğimizden fazla gecikme aldık. Hata mesajı çok dramatik değildi ama performans bize tokat gibi geldi diyebilirim. Çözümümüz basitti: geçici olarak kapasiteyi artırdık ve job’u tekrar koşturduk.
Bu yüzden ben hep şunu söylerim: veri modeli kadar kapasite planlaması da önemli. Bilhassa TL bazında bakınca Azure maliyetleri bazı ekiplerde hassas konu oluyor — haklılar da — fakat yanlış planlanmış bir migration’ın operasyon maliyeti çoğu zaman birkaç günlük ekstra kapasiteden pahalıya geliyor.
Maliyet ve risk açısından nasıl okumalı?
Bütçe kısıtlıysa iki yolu karşılaştırırım ben genelde: ya mevcut sistemi olduğu gibi tutup kısa vadeli riskleri kabul edeceksiniz ya da kontrollü biçimde yeniden bölümlendirme yapacaksınız (kendi tecrübem). Birincisi ucuz görünür ama gizli maliyet taşır; ikincisi başlangıçta biraz masraf çıkarır ama uzun vadede nefes aldırır. Daha fazla bilgi için
💡 Bilgi: Eğer bütçe dar işe önce sorgu deseninizi optimize edin; gereksiz cross-partition sorguları azaltmak bazen migration’dan daha hızlı kazanç sağlar.Bunu kendi projelerimde nasıl konumlandırıyorum?
AZ-305 sınavına hazırlanırken bile şunu tekrar tekrar görmüştüm: doğru veri yerleşimi sadece teoride değil gerçek mimaride de oyunun kaderini değiştiriyor. Cosmos DB bunun en net örneklerinden biri. AZ-104 tarafında operasyonu öğreniyorsunuz, AZ-500’de güvenlik kısmını oturtuyorsunuz, ama data modeling kısmı ayrı bir kaş istiyor — önü geliştirmeden sağlıklı bulut mimarisi olmuyor.
Logosoft’ta çalışırken bir telekom müşterisinde benzer şekilde event yoğunluğu yüksek bir yapı analiz etmiştik. Orada asıl problem “veri kötü” değildi; access pattern eski kalmıştı. Bu ayrımı yapmak önemli. Çünkü bazen çözüm servisi değiştirmek değil,anahtarı yeniden düşünmek oluyor — itiraf edeyim, beklentimin üstündeydi —. İşte bu özellik tam o noktada işe yarıyor.
Tavsiyem ne?
- Önce workload’unuzu okuyun: hangi kullanıcı hangi veriye dokunuyor? — ciddi fark yaratıyor
- Kritik sorguları tek tek test edin; tahmin etmeyin.
- Cutover öncesi geri dönüş planı hazırlayın.
- Eğer üretimdeyseniz offline yerine online modu değerlendirin.
- Eski container’ı hemen silmeyin; birkaç gün gözlem bırakın.
Neyse uzatmayayım… Benim görüşüm şu: Microsoft burada gerçekten doğru yönde adım atmış. Ama hâlâ eksik olan şeylerin başında süreç rehberlerinin biraz daha gerçek dünya senaryolarıyla zenginleştirilmesi geliyor. Mesela çok kiracılı SaaS uygulamalarında tenant bazlı geçiş örnekleri ya da yüksek trafik altında throttle davranışı daha açık anlatılabilir.
Sıkça Sorulan Sorular
Azure Cosmos DB’de partition key sonradan değiştirilebilir mi?
Evet, artık Change Partition Key özelliğiyle bu mümkün oluyor. Üstelik online copy desteği sayesinde kaynak container’daki yazmaları tamamen durdurmadan geçiş yapabiliyorsunuz — bence bu gerçekten büyük bir kolaylık.
Online copy ile offline copy arasındaki fark nedir?
Online copy’de kaynak container’a yazmalar devam ederken hedefe kopyalama sürüyor (buna dikkat edin). Offline copy’de işe genelde yazmaları durdurmanız gerekiyor; yanı geçiş penceresi daha belirgin oluyor ve planlama daha kritik hâle geliyor.
Bu özellik her senaryoda risksiz mi?
Kendi deneyimimden konuşuyorum, Hayır, açıkçası değil. Veri modeli uyumsuzsa ya da cutover iyi planlanmadıysa sorun yaşayabilirsiniz. Özellik işi kolaylaştırıyor, ama tasarım hatasını ortadan kaldırmıyor — bunu unutmamak lazım.
Küçük ekipler için uygun mu?
Evet, hatta bazı durumlarda özellikle uygun olabiliyor. Ama tecrübeme göre önce maliyet-fayda hesabını yapmak gerekiyor; çünkü her taşıma operasyonel efor istiyor.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Azure Cosmos DB Blog Yazısı
Azure Cosmos DB Partitioning Overview — Microsoft Learn
Azure Cosmos DB’de GSI: Okuma Yükünü Hafifletmenin Pratik Yolu
Azure Cosmos DB vNext Emülatör: Yerelde Gerçek Gibi Test Etmek
Azure Cosmos DB’de Bölüm Bazlı Otomatik Failover: Sessiz Devrim
Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Burcu Ç.
Biz de geçen yıl yanlış seçilen bir partition key yüzünden ciddi hot partition sorunları yaşadık, o süreçte veriyi yeniden migrate etmek gerçekten çok can sıkıcıydı. Bu özellik o dönemde olsaydı epey zaman kazanırdık. Bu arada şu yazınız da güzeldi: GitHub’ın Unuttuğu Depolar İçin Güvenlik Kontrolü: Bence Asıl Mesaj Bu — https://www.askinkilic.com.tr/githubin-unuttugu-depolar-icin-guvenlik-kontrolu-bence-asil/
Burak S.
Tam da geçen ay bu sorunu yaşadık, hot partition yüzünden RU maliyetlerimiz ikiye katlandı. Microsoft’un bu özelliği biraz geç getirdiği söylenebilir ama yine de “artık mümkün” demesi büyük rahatlama. Peki migration sırasında downtime kaçınılmaz mı oluyor, bununla ilgili bir deneyiminiz var mı?
Merve Ş.
Geçen ay tam bu sorunu yaşadık, hot partition olayı gerçekten can sıkıcı. Partition key seçimini baştan doğru yapmak ne kadar kritik, sonradan değiştirmeye çalışmak bile olsa ciddi bir iş. Bu özelliğin ne kadar downtime gerektirdiğine de değinilmiş mi yazıda?
İrem B.
Partition key seçimi konusunda başlangıçta “işe yarar bir şey seçeyim” deyip sonradan hot partition cehennemine düşmek gerçekten can sıkıcı oluyor. Bu özellik çok geç geldi ama iyi ki geldi, bütün container’ı yeniden oluşturmak zorunda kalmak tam bir kabustu. Bu arada şu yazınız da güzeldi: CodeQL 2.25.6 ile Sessiz Ama Güçlü Güvenlik Sıçraması — https://www.askinkilic.com.tr/codeql-2256-ile-sessiz-ama-guclu-guvenlik-sicramasi/
4 comments