Azure Cosmos DB’de Partition Key Değiştirme Yolları
Azure Cosmos DB’de bir container oluşturduğunuzda, seçtiğiniz partition key kalıcıdır ve yerinde değiştirilemez. Ancak zamanla bu anahtar; cross-partition sorgular veya hot partition gibi problemler doğurabilir. Bu noktada elinizde birkaç farklı seçenek bulunuyor ve her birinin kendine göre bir maliyeti, karmaşıklığı ve kullanım senaryosu var. Bu yazıda partition key’i “değiştirmenin” aslında ne anlama geldiğini ve dört farklı yaklaşımın nerede işinize yarayacağını inceliyoruz.
Önce Niyetinizi Belirleyin
Yola çıkmadan önce sormanız gereken soru şu: Verinin fiziksel dağılımını mı değiştirmek istiyorsunuz, yoksa yalnızca farklı bir anahtarla sorgu mu yapmak istiyorsunuz?
- Veriyi yeniden bölümlemek (re-partition): Mevcut öğelerin ve gelecekteki yazma işlemlerinin farklı bir anahtar altında yaşamasını istiyorsanız, yeni bir container’a taşınmak zorundasınız. Bunun için en az efordan en fazlasına doğru üç yol var: portaldeki Change partition key özelliği, container copy jobs ve kendi yazdığınız migrasyon.
- Farklı bir anahtarla sorgu yapmak: Yazma tarafında bir sorun yoksa ve derdiniz yalnızca partition’lar arasına yayılan okuma desenleriyse, Global Secondary Index (GSI) sizi taşımaktan kurtarabilir. GSI, kaynak container’la otomatik senkronize kalan, farklı bir partition key’e ve kendi veri modeline sahip ayrı bir salt-okunur container ekler.
Dikkat edilmesi gereken bir nokta: GSI hariç tüm “partition key değiştirme” seçenekleri aslında bir taşıma operasyonudur. Veriyi yeni anahtara sahip yeni bir container’a alır, sonra uygulamanızı oraya yönlendirirsiniz.
Seçenek 1: Portaldeki Change Partition Key Özelliği
En düşük efor gerektiren yol, Azure portalındaki yönetilen seçenektir. Data Explorer üzerinden container’ınıza gidip Scale & Settings → Partition Keys altındaki Change seçeneğini kullanabilirsiniz.
Portal, aynı veritabanı içinde bir hedef container oluşturur veya seçer ve veriyi container copy jobs motoruyla oraya kopyalar. Hedef container’ı portalın oluşturmasına izin verirseniz, partition key ve unique key dışındaki tüm yapılandırmalar hedefe kopyalanır; siz yalnızca bu ikisini yeniden tanımlarsınız. Kopyalama işlemi online ya da offline modda çalıştırılabilir. Online modda iş bittikten sonra Complete seçeneğiyle tamamlanır ve yeni container’ı kullanmaya başlarsınız; eskisini silmek isteğe bağlıdır.
Seçenek 2: Container Copy Jobs (CLI ile Doğrudan)
Portalın arka planda kullandığı motor container copy jobs’tır. Bu işleri Azure CLI üzerinden (cosmosdb-preview eklentisi ile) doğrudan kendiniz de oluşturup yönetebilirsiniz. Bu yol; scripting, otomasyon veya daha ince kontrol ihtiyacı olduğunda tercih edilir. Akış şu şekildedir: istediğiniz partition key, throughput ve unique key ayarlarıyla hedef container’ı oluşturun, kopya işini başlatın, izleyin ve cutover yapın. Kaynak ile hedef farklı hesaplarda ise önce hedef hesabın identity’sine kaynak container üzerinde read yetkisi vermeniz gerekir; aynı hesap içindeki kopyalarda bu adım yoktur.
Online ve Offline Mod Farkı
Container copy’nin iki modu vardır:
- Online mod: Kopyalama sürerken kaynağa yazma devam eder ve iş sonunda kısa bir Complete-then-cutover adımı vardır. Ancak online kopya etkinken kaynağa yapılan her yazma işlemi çift RU ile ücretlendirilir. Ayrıca continuous backup, all-versions-and-deletes change feed ve hesap seviyesinde ilgili özelliğin açık olması gerekir.
- Offline mod: Bu ön koşulları atlar, ancak cutover’a kadar kaynakta yazma dondurulur.
Her iki mod da best-effort çalışır (garantili tamamlanma süresi yoktur) ve işler yazma bölgesinde tek tek yürütülür. Planlarken iki nokta önemlidir: kopyalama TTL’i taşımaz, yani süresi henüz dolmamış bir öğe hedefte geri sayımı sıfırdan başlatır; ayrıca hedefin kaynağın yaklaşık iki katı throughput ile hazırlanması akışa yetişmeyi kolaylaştırır.
Cutover Öncesi Kontrol Listesi
Yeni bir container aynı zamanda yalnızca oluşturma anında ayarlanabilecek özellikleri açmak için de tek fırsatınızdır. Bunların başında hierarchical partition keys gelir; iş yükünüze uygunsa bu geçişte değerlendirmekte fayda var. Bir de yeni partition key değeri ile id kombinasyonunun hedefte benzersiz kaldığını doğrulayın; aksi halde önceden farklı olan iki öğe hedefte çakışabilir.
Seçenek 3: Kendi Migrasyonunuzu Yazmak
Taşıma sırasında dönüşüm (transform) yapmanız gerekiyorsa, container’ınız container copy limitlerini aşıyorsa veya süreç üzerinde tam kontrol istiyorsanız, hedef container’ı kendiniz oluşturup veriyi kendi pipeline’ınızla taşımanız gerekir. Bu yaklaşımın yapı taşları şunlardır:
- Bulk ingestion: Yeni container’ı hızlıca doldurmak için..NET v3 SDK’da yerleşik olarak gelir;.NET SDK 2.x üzerinde kalan uygulamalar için bulk executor library kullanılabilir.
- Azure Data Factory: Küçük veri kümeleri için kod yazmadan kaynak ve hedef yapılandırılabilir. Spark ile çalışıyorsanız Spark connector alternatif olabilir.
- Change feed: Bulk yükleme sonrasında kaynağa gelen yeni yazmaları yakalayıp cutover’a kadar hedefe yansıtmak için kullanılır. Varsayılan latest-version modu silme ve TTL süresi dolmuş öğeleri atladığından, silme operasyonlarını da yakalamak için all-versions-and-deletes modu tercih edilmelidir; bu da continuous backup gerektirir.
Hedefi yeterli RU/s ile önceden oluşturmak ve yükleme sırasında indexing’i kapatmak yazma maliyetini düşürmeye yardımcı olur. Buna karşılık artırımlı senkronizasyon, hata yönetimi, cutover ve yeniden şekillendirme tamamen sizin sorumluluğunuzdadır.
Taşımadan Farklı Bir Anahtarla Sorgu: Global Secondary Index
Tek sıkıntınız cross-partition sorgular ise, yani filtre alanınız partition key olmadığı için okumalar birden fazla partition’a yayılıyorsa, taşımaya gerek kalmayabilir. Bu senaryoda Global Secondary Index (GSI) devreye girer.
GSI, farklı bir partition key ile anahtarlanmış, kendi veri modeline sahip, ayrı ve salt-okunur bir container’dır. Bu model, öğeleriniz üzerinde çalışan bir projection sorgusudur (SELECT * ile tüm özellikler ya da yalnızca sorguladığınız alt küme) ve kaynak container ile otomatik olarak senkron kalır. Mevcut container’a mevcut anahtarınızla yazmaya devam edersiniz; GSI’nin partition key’ine denk düşen filtrelere sahip sorgular, kaynak container üzerindeki cross-partition sorgular yerine GSI üzerinde tek partition sorgusuna dönüşebilir. Yani GSI, yalnızca kendisi için anahtarladığınız desenlere yardım eder, her cross-partition sorguyu iyileştirmez.
GSI’nin uygun olduğu durum; mevcut partition key’i değiştirmenin operasyonel olarak sancılı olması ve tek bir anahtarın karşılayamayacağı birden fazla sorgu deseninizin bulunmasıdır. Hesap üzerinde continuous backup gerektirir, tutarlılık seviyenizden bağımsız olarak eventual consistency ile çalışır ve kendi depolama ile RU maliyetiyle autoscale üzerinde koşar. Bir GSI oluşturulduktan sonra kaynak container üzerindeki replace ve delete operasyonları %50–100 daha fazla RU tüketir; create operasyonları etkilenmez.
Önemli sınır: GSI yalnızca okuma tarafını iyileştirir. Yazmaların nereye düştüğünü değiştirmediği için kaynaktaki bir write-side hot partition sorununu çözmez. Sorununuz yazma dağılımıysa veya verinin farklı bir birincil anahtara ihtiyacı varsa, tekrar veri taşıma seçeneklerine dönmeniz gerekir.
Hangi Seçenek Ne Zaman?
Kararı sadeleştirmek için dört yolu yan yana koymak faydalı olur:
| Seçenek | Taşıma sırasında kaynağa yazma? | Efor | Ne zaman kullanılır? |
|---|---|---|---|
| Portaldeki “Change partition key” | Evet (online) veya hayır (offline) | En düşük | Tıkla-geç bir akış istiyorsanız; container 1.000.000 RU/s ve 4 TB altındaysa; desteklenen bölgede |
| Container copy jobs (CLI) | Evet (online) veya hayır (offline) | Düşük–orta | Aynı yönetilen motoru script üzerinden, açık online/offline kontrolüyle kullanmak istediğinizde |
| Kendi migrasyonunuz (bulk / ADF / Spark + change feed) | Evet, artırımlı senkronizasyonu kendiniz kurarsanız | En yüksek | Dönüşüm gerekiyorsa, copy limitlerinin üzerindeyseniz veya cutover üzerinde tam kontrol istiyorsanız |
| Global Secondary Index | Uygulanmaz; kaynak olduğu gibi kalır, GSI otomatik senkron | Orta | Sorun cross-partition okumalar ise, write hot partition değilse ve kaynak anahtarı korumak mümkünse |
Özetle: Yazmalarınızın farklı bir anahtara ihtiyacı varsa, veriyi bir şekilde taşımak zorundasınız; asıl karar, kopyalamanın ne kadarını Azure Cosmos DB’ye devredeceğinizdir. Yalnızca okumalarınız partition’lara yayılıyorsa, yazmaların yerini değiştirmeden GSI ile bu problemi çözebilirsiniz.
Kaynaklar ve İleri Okuma
- Orijinal yazı: Need a different partition key in Azure Cosmos DB? Pick the right approach (Abhishek Gupta)
- Azure Cosmos DB’de partitioning
- Partition key değiştirme (portal özelliği)
- Container copy jobs
- Container copy jobs oluşturma ve yönetme (CLI)
- Global secondary indexes
- Change feed
- Change feed modları
- Büyük ölçekli veri migrasyonu
- Bulk executor library’e genel bakış
- Container üzerinde sorgu yapma
- 429 (request rate too large) sorun giderme
- Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor
- Azure Cosmos DB’de GSI: Okuma Yükünü Hafifletmenin Pratik Yolu
- Azure Cosmos DB’de Silinenleri Görmek: Change Feed’in Sessiz Gücü
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.
Yorum gönder