Aracılığıyla paylaş

Azure'da görev açısından kritik iş yükleri için veri platformunda dikkat edilmesi gerekenler

  • Makale

Etkili bir uygulama veri platformunun seçilmesi, diğer tasarım alanlarında çok geniş bir etki alanı olan daha önemli bir karar alanıdır. Azure, büyük ölçüde farklı özelliklere sahip çok sayıda ilişkisel, ilişkisel olmayan ve analitik veri platformu sunar. Bu nedenle, temel işlevsel olmayan gereksinimlerin tutarlılık, çalışabilirlik, maliyet ve karmaşıklık gibi diğer karar faktörleriyle birlikte tam olarak dikkate alınması önemlidir. Örneğin, çok bölgeli bir yazma yapılandırmasında çalışma olanağı, küresel olarak kullanılabilir bir platform için uygun olma konusunda kritik bir öneme sahip olacaktır.

Bu tasarım alanı uygulama tasarımını genişleterek en uygun veri platformunun seçilmesini bilgilendirmek için önemli noktalar ve öneriler sağlar.

Önemli

Bu makale, Azure İyi Tasarlanmış görev açısından kritik iş yükü serisinin bir parçasıdır. Bu seriyi bilmiyorsanız görev açısından kritik iş yükü nedir? ile başlamanızı öneririz.

Büyük Verilerin Dört Karşılaştırması

'Four Vs of Big Data', yüksek oranda kullanılabilir bir veri platformu için gerekli özellikleri ve iş değerini en üst düzeye çıkarmak için verilerin nasıl kullanılabileceğini daha iyi anlamak için bir çerçeve sağlar. Bu bölümde uygun veri teknolojilerini kullanarak bir veri platformu tasarlamaya yardımcı olmak için Birim, Hız, Çeşitlilik ve Veracity özelliklerinin kavramsal düzeyde nasıl uygulanabileceği incelenir.

  • Voluşturma: Depolama kapasitesi ve katmanlama gereksinimlerini bildirmek için gelen veri miktarı (veri kümesinin boyutudur).
  • Vkonumluluğu: Toplu veya sürekli akışlar olarak verilerin işlenme hızı, akış hızıdır.
  • Vözelliği: Birden çok depo veya türdeki veriler olan yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış biçimleri yakalayan verilerin organizasyonu ve biçimi.
  • Veracity: verilerin doğruluğu olan idare ve veri kalitesi güvencesi için göz önünde bulundurulan veri kümelerinin başarısı ve seçkisini içerir.

Tasarım Konusunda Dikkat Edilmesi Gerekenler

Hacim

  • Mevcut (varsa) ve gelecekteki beklenen veri hacimleri, iş hedeflerine ve planlarına uygun olarak tahmin edilen veri büyüme oranlarına dayalıdır.

    • Veri hacmi, verilerin kendisini ve dizinleri, günlükleri, telemetri verilerini ve diğer geçerli veri kümelerini içermelidir.
    • İş açısından kritik ve görev açısından kritik büyük uygulamalar genellikle günlük olarak yüksek hacimli (GB ve TB) oluşturur ve depolar.
    • Veri genişletmeyle ilişkili önemli maliyet etkileri olabilir.

  • Değişen iş koşulları veya temizlik prosedürleri nedeniyle veri hacminde dalgalanmalar olabilir.

  • Veri hacmi, veri platformu sorgu performansı üzerinde derin bir etkiye sahip olabilir.

  • Veri platformu hacmi sınırlarına ulaşmakla ilgili derin bir etki olabilir.

    • Kapalı kalma süresine neden olacak mı? Ve eğer öyleyse, ne kadar süreyle?
    • Risk azaltma yordamları nelerdir? ve azaltma için uygulama değişiklikleri gerekecek mi?
    • Veri kaybı riski olacak mı?

  • Yaşam Süresi (TTL) gibi özellikler, geçen bir süreden sonra kayıtları otomatik olarak silerek kayıt oluşturma veya değiştirme yoluyla veri büyümesini yönetmek için kullanılabilir.

    • Örneğin, Azure Cosmos DB yerleşik bir TTL özelliği sağlar.

Hız

  • Verilerin çeşitli uygulama bileşenlerinden hangi hızda yayıldığı ve verilerin ne kadar hızlı işlenip alınması gerektiğiyle ilgili aktarım hızı gereksinimleri, önemli iş yükü senaryoları için en uygun veri teknolojisini belirlemek için kritik öneme sahiptir.

    • Aktarım hızı gereksinimlerinin doğası, yoğun okuma veya yazma ağırlıklı olanlar gibi iş yükü senaryosuna göre farklılık gösterir.
      • Örneğin analitik iş yüklerinin genellikle büyük bir okuma aktarım hızına uygun olması gerekir.
    • Gerekli aktarım hızı nedir? Aktarım hızının nasıl büyümesi bekleniyor?
    • Başvuru yük düzeyleri altında P50/P99'daki veri gecikme süresi gereksinimleri nelerdir?

  • Kilitsiz tasarım, dizin ayarlama ve tutarlılık ilkelerini destekleme gibi özellikler yüksek aktarım hızı elde etmek için kritik öneme sahiptir.

    • Yüksek aktarım hızı için yapılandırmayı en iyi duruma getirmek, tam olarak anlaşılması gereken dengelemelere neden olur.
    • Aktarım hızını daha da iyileştirmek için CQRS ve Olay Kaynağını Belirleme gibi yük dengeleme kalıcılığı ve mesajlaşma desenleri kullanılabilir.

  • Yük düzeyleri birçok uygulama senaryosunda doğal olarak dalgalanır ve doğal zirveler, aktarım hızını ve gecikme süresini korurken değişken talebi işlemek için yeterli düzeyde esneklik gerektirebilir.

    • Çevik ölçeklenebilirlik, kapasite düzeylerini fazla sağlamadan değişken aktarım hızını ve yük düzeylerini etkili bir şekilde desteklemek için önemlidir.
      • Hem okuma hem de yazma aktarım hızının uygulama gereksinimlerine ve yüküne göre ölçeklendirilmesi gerekir.
      • Değişen yük düzeylerine yanıt vermek için hem dikey hem de yatay ölçeklendirme işlemleri uygulanabilir.

  • Aktarım hızı düşüşlerinin etkisi iş yükü senaryosuna göre farklılık gösterebilir.

    • Bağlantı kesintisi olacak mı?
    • Kontrol düzlemi çalışmaya devam ederken tek tek işlemler hata kodları döndürecek mi?
    • Veri platformu azaltmayı etkinleştirecek mi ve etkinleştirecekse ne kadar süreyle etkinleştirilecek?

  • Etkin-etkin bir coğrafi dağılımın kullanılmasına yönelik temel uygulama tasarımı önerisi, veri tutarlılığıyla ilgili güçlükler doğurmsıyor.

    • Tam ACID işlem semantiği ve geleneksel kilitleme davranışı açısından tutarlılık ve performans arasında bir denge vardır.
      • Yazma gecikme süresini en aza indirmek, veri tutarlılığı maliyetine neden olur.

  • Çok bölgeli yazma yapılandırmasında değişikliklerin eşitlenmesi ve tüm çoğaltmalar arasında birleştirilmesi gerekir ve gerektiğinde çakışma çözümü gerekir ve bu durum performans düzeylerini ve ölçeklenebilirliği etkileyebilir.

  • Salt okunur çoğaltmalar (bölge içi ve bölgeler arası) gidiş dönüş gecikme süresini en aza indirmek ve performansı, aktarım hızını, kullanılabilirliği ve ölçeklenebilirliği artırmak için trafiği dağıtmak için kullanılabilir.

  • Önbelleğe alma katmanı, kullanıcı deneyimini ve uçtan uca istemci yanıt sürelerini geliştirmek için okuma aktarım hızını artırmak için kullanılabilir.

    • Verilerin güncelliğini iyileştirmek için önbellek süre sonu sürelerinin ve ilkelerinin dikkate alınması gerekir.

Çeşit

  • Veri modeli, veri türleri, veri ilişkileri ve hedeflenen sorgu modeli, veri platformu kararlarını güçlü bir şekilde etkiler.

    • Uygulama bir ilişkisel veri modeli gerektiriyor mu yoksa değişken şemasını veya ilişkisel olmayan bir veri modelini destekleyebilir mi?
    • Uygulama verileri nasıl sorgulayacak? Sorgular ilişkisel birleşimler gibi veritabanı katmanı kavramlarına mı bağlı olacak? Yoksa uygulama böyle bir semantik sağlıyor mu?

  • Uygulama tarafından dikkate alınan veri kümelerinin yapısı, görüntüler ve videolar gibi yapılandırılmamış içeriklerden veya CSV ve Parquet gibi daha yapılandırılmış dosyalardan değişebilir.

    • Bileşik uygulama iş yükleri genellikle farklı veri kümelerine ve ilişkili gereksinimlere sahip olur.

  • İlişkisel veya ilişkisel olmayan veri platformlarına ek olarak, graf veya anahtar-değer veri platformları da belirli veri iş yükleri için uygun olabilir.

    • Bazı teknolojiler, veri öğelerinin birbirine benzediği ve/veya birlikte depolandığı ve sorgulandığı ancak yapısal olarak farklılık gösterdiği değişken şema veri modellerine uygundur.

  • Mikro hizmet mimarisinde, tek tek uygulama hizmetleri tek bir monolitik veri deposuna bağlı olarak değil, senaryo için iyileştirilmiş ayrı veri depolarıyla oluşturulabilir.

    • Farklı veri depoları arasındaki tutarlılığı ve bağımlılıkları yönetmek için SAGA gibi tasarım desenleri uygulanabilir.
      • Veritabanları arası doğrudan sorgular ortak konum kısıtlamaları uygulayabilir.
    • Birden çok veri teknolojisinin kullanılması, kapsanan teknolojileri korumak için bir derece yönetim yükü ekler.

  • Her Azure hizmeti için özellik kümeleri diller, SDK'lar ve API'ler arasında farklılık gösterir ve bu da uygulanabilecek yapılandırma ayarlama düzeyini büyük ölçüde etkileyebilir.

  • Veri modeli ve kapsamış veri türleriyle iyileştirilmiş hizalama özellikleri, veri platformu kararlarını güçlü bir şekilde etkiler.

    • Saklı yordamlar ve nesne ilişkisel eşleyiciler gibi sorgu katmanları.
    • Güvenli REST API katmanı gibi dilden bağımsız sorgu özelliği.
    • Yedekleme ve geri yükleme gibi iş sürekliliği özellikleri.

  • Analitik veri depoları genellikle çeşitli veri yapısı türleri için çok teknolojili depolamayı destekler.

    • Apache Spark gibi analitik çalışma zamanı ortamlarında çok teknolojili veri yapılarını analiz etmek için tümleştirme kısıtlamaları olabilir.

  • Kurumsal bağlamda, mevcut süreçlerin ve araçların kullanımı ve becerilerin sürekliliği, veri platformu tasarımı ve veri teknolojilerinin seçimine önemli ölçüde bağlı olabilir.

Doğru -luğunu

  • Bir uygulamadaki verilerin doğruluğunu doğrulamak için çeşitli faktörlerin dikkate alınması gerekir ve bu faktörlerin yönetimi veri platformunun tasarımına önemli ölçüde bağlı olabilir.

    • Veri tutarlılığı.
    • Platform güvenlik özellikleri.
    • Veri idaresi.
    • Değişiklik yönetimi ve şema evrimi.
    • Veri kümeleri arasındaki bağımlılıklar.

  • Birden çok veri çoğaltması olan herhangi bir dağıtılmış uygulamada, CAP ve PACELC teoremlerinde belirtildiği gibi tutarlılık ve gecikme süresi arasında bir denge vardır.

    • Okuyucular ve yazarlar ayrı bir şekilde dağıtıldığında, bir uygulamanın veri öğesinin yeni tamamlanan bir yazma (güncelleştirme) veya veri öğesinin en güncel sürümüyle karşılaştırıldığında güncel olmasa bile veri öğesinin en hızlı kullanılabilir sürümünü veya veri öğesinin en güncel sürümünü döndürmeyi seçmesi gerekir. Bu, en son durumu belirlemek ve elde etmek için ek gecikmeye neden olabilir.
    • Tutarlılık ve kullanılabilirlik, platform düzeyinde veya tek tek veri isteği düzeyinde yapılandırılabilir.
    • Verilerin kullanıcıya en yakın çoğaltmadan sunulduğunda farklı bir çoğaltmanın en son durumunu yansıtmayan kullanıcı deneyimi nedir? Örneğin, uygulama güncel olmayan veriler sunma desteği sağlayabilir mi?

  • Çok bölgeli yazma bağlamında, her iki değişiklik de çoğaltılmadan önce aynı veri öğesi iki ayrı yazma çoğaltmasında değiştirildiğinde, çözülmesi gereken bir çakışma oluşturulur.

    • "Son Yazma Kazançları" gibi standartlaştırılmış çakışma çözümleme ilkeleri veya özel mantık içeren özel bir strateji uygulanabilir.

  • Güvenlik gereksinimlerinin uygulanması aktarım hızını veya performansı olumsuz etkileyebilir.

  • Bekleyen şifreleme, istemci tarafı şifrelemesi ve/veya gerekirse sunucu tarafı şifrelemesi kullanılarak veri katmanı kullanılarak uygulama katmanında uygulanabilir.

  • hizmet tarafından yönetilen anahtarları kullanan sunucu tarafı şifreleme, Key Vault'ta müşteri tarafından yönetilen anahtarlar veya müşteri tarafından denetlenen donanımlarda müşteri tarafından yönetilen anahtarlar gibi çeşitli şifreleme modellerini Azure desteği.

    • İstemci tarafı şifreleme ile anahtarlar Key Vault'ta veya başka bir güvenli konumda yönetilebilir.

  • MACsec (IEEE 802.1AE MAC) veri bağlantısı şifrelemesi, Microsoft omurga ağındaki Azure veri merkezleri arasında hareket eden tüm trafiğin güvenliğini sağlamak için kullanılır.

    • Paketler gönderilmeden önce cihazlarda şifrelenir ve şifreleri çözülür ve fiziksel 'ortadaki adam' veya gözetleme/dinleme saldırıları engellenir.

  • Veri düzlemine ve kontrol düzlemine kimlik doğrulaması ve yetkilendirme.

    • Veri platformu uygulama erişimini ve işletimsel erişimi nasıl doğrulayacak ve yetkilendirilecek?

  • İzleme platformu sistem durumu ve veri erişimi aracılığıyla gözlemlenebilirlik.

    • Kabul edilebilir operasyonel sınırların dışındaki koşullar için uyarı nasıl uygulanacak?

Tasarım Önerileri

Hacim

  • Organik büyümeyle ilişkili gelecekteki veri hacimlerinin veri platformu özelliklerini aşmasını beklemediğinden emin olun.

    • İş planlarına uygun veri büyüme oranlarını tahmin edin ve devam eden kapasite gereksinimlerini bilgilendirmek için belirlenmiş oranları kullanın.
    • Toplama ve veri başına kayıt birimlerini veri platformu sınırlarıyla karşılaştırın.
    • Olağanüstü durumlarda sınırlara ulaşılma riski varsa kapalı kalma süresini ve veri kaybını önlemek için operasyonel azaltmaların uygulandığından emin olun.

  • Ölçek sınırlarını ve beklenen veri büyüme oranlarını göz önünde bulundurarak veri hacmini izleyin ve bir kapasite modeline göre doğrulayın.

    • Ölçeklendirme işlemlerinin depolama, performans ve tutarlılık gereksinimleriyle uyumlu olduğundan emin olun.
    • Yeni bir ölçek birimi kullanıma sunulduğunda, temel alınan verilerin çoğaltılması gerekebilir ve bu da zaman alabilir ve çoğaltma gerçekleşirken büyük olasılıkla bir performans cezasına neden olur. Bu nedenle bu işlemlerin mümkünse kritik iş saatleri dışında gerçekleştirildiğinden emin olun.

  • Eski verilerin kaldırılmasını veya boşaltılmasını kolaylaştırmak için veri kümelerini kullanım ve kritikliğe göre sınıflandırmak için uygulama veri katmanları tanımlayın.

    • Veri kümelerini 'sık erişimli', 'sıcak' ve 'soğuk' ('arşiv') katmanlarına sınıflandırmayı göz önünde bulundurun.
      • Örneğin, temel başvuru uygulamaları uygulama tarafından etkin olarak kullanılan 'sık erişimli' verileri depolamak için Azure Cosmos DB'yi kullanırken, Azure Depolama ise analiz amacıyla 'soğuk' işlem verileri için kullanılır.

  • Veri büyümesini iyileştirmek ve sorgu performansı ve veri genişletmeyi yönetme gibi veri verimliliklerini yönlendirmek için temizlik yordamlarını yapılandırın.

    • Artık gerekli olmayan ve uzun vadeli analiz değeri olmayan veriler için Yaşam Süresi (TTL) süre sonunu yapılandırın.
      • Eski verilerin ikincil depolama alanına güvenli bir şekilde katmanlanabildiğini veya uygulamayı olumsuz etkilemeden tamamen silinebileceğini doğrulayın.
    • Kritik olmayan verileri ikincil soğuk depolama alanına boşaltabilirsiniz, ancak analiz değeri için ve denetim gereksinimlerini karşılamak için bu verileri koruyun.
    • DevOps ekiplerinin temizlik gereksinimlerini ve 'doğru boyut' veri depolarını sürekli değerlendirmesine olanak tanımak için veri platformu telemetrisi ve kullanım istatistiklerini toplayın.

  • Mikro hizmet uygulama tasarımına uygun olarak, belirli iş yükü senaryoları ve birim gereksinimleri için iyileştirilmiş veri çözümleriyle birden çok farklı veri teknolojisini paralel olarak kullanmayı göz önünde bulundurun.

    • Genişletmeden gelen veri hacminin yönetilmesinin zor olabileceği tek bir monolitik veri deposu oluşturmaktan kaçının.

Hız

  • Veri platformunun, senaryo için iyileştirilmiş veri çözümlerini kullanarak performansı en üst düzeye çıkarmak için farklı bağlamlara ayrılmış iş yükleriyle birlikte yüksek aktarım hızını destekleyecek şekilde tasarlanması ve yapılandırılması gerekir.

    • Her veri senaryosu için okuma ve yazma aktarım hızının beklenen yük desenlerine göre ölçeklendirilediğinden ve beklenmeyen varyans için yeterli toleransa sahip olduğundan emin olun.
    • İşlem ve analitik işlemler gibi farklı veri iş yüklerini ayrı performans bağlamlarına ayırın.

  • CQRS veya Olay Kaynağını Belirleme desenleri gibi zaman uyumsuz engelleyici olmayan ileti kullanımı aracılığıyla yük düzeyi.

    • Yazma istekleri ile yeni verilerin okunmaya uygun hale gelmesi arasında gecikme olabilir ve bu durum kullanıcı deneyimini etkileyebilir.
      • Bu etki, önemli iş gereksinimleri bağlamında anlaşılmalı ve kabul edilebilir olmalıdır.

  • Değişken aktarım hızını ve yük düzeylerini desteklemek için çevik ölçeklenebilirlik sağlayın.

    • Yük düzeyleri son derece geçiciyse, aktarım hızının ve performansın korunmasını sağlamak için kapasite düzeylerini fazla sağlamayı göz önünde bulundurun.
    • Aktarım hızı korunamıyorsa bileşik uygulama iş yüklerine etkisini test edin ve doğrulayın.

  • Yük düzeyinde volatiliteye hızlı yanıt vermek için otomatik ölçeklendirme işlemleriyle Azure'a özel veri hizmetlerinin önceliklerini belirleyin.

    • Hizmet iç ve uygulama kümesi eşiklerine göre otomatik ölçeklendirmeyi yapılandırın.
    • Ölçeklendirme, iş gereksinimleriyle tutarlı zaman çerçevelerinde başlatılıp tamamlanmalıdır.
    • El ile etkileşimin gerekli olduğu senaryolar için, el ile işlem eylemleri gerçekleştirmek yerine tetiklenebilen otomatik operasyonel 'playbook'lar oluşturun.
      • Otomatik tetikleyicilerin sonraki mühendislik yatırımlarının bir parçası olarak uygulanıp uygulanamayacağını göz önünde bulundurun.

  • P50/P99 gecikme süresi gereksinimlerine karşı uygulama verilerini okuma ve yazma aktarım hızını izleyin ve bir uygulama kapasitesi modeliyle uyumlu hale getirme.

  • Fazla aktarım hızı, veri platformu veya uygulama katmanı tarafından düzgün bir şekilde işlenmeli ve işletimsel gösterim için sistem durumu modeli tarafından yakalanmalıdır.

  • Yanıt sürelerini en aza indirmek için 'sık erişimli' veri senaryoları için önbelleğe alma uygulayın.

    • Önbellek süre sonu ve evde tutma için uygun ilkeleri uygulayarak kaçak veri büyümesine engel olun.
      • Yedekleme verileri değiştiğinde önbellek öğelerinin süresinin dolması.
      • Önbellek süre sonu kesinlikle Yaşam Süresi (TTL) tabanlıysa, güncel olmayan verileri sunmanın etkisi ve müşteri deneyiminin anlaşılması gerekir.

Çeşit

  • Bulut ve Azure'a özel tasarım ilkesine uygun olarak, işletim ve yönetim karmaşıklığını azaltmak ve Microsoft'un gelecekteki platform yatırımlarından yararlanmak için yönetilen Azure hizmetlerine öncelik vermek kesinlikle önerilir.

  • Gevşek bağlanmış mikro hizmet mimarilerinin uygulama tasarım ilkesine uygun olarak, tek tek hizmetlerin ayrı veri depolarını ve senaryo için iyileştirilmiş veri teknolojilerini kullanmasına izin verin.

  • Seçili veri teknolojileri için gerekli özelliklerin kullanılabilir olduğunu doğrulayın.

    • Gerekli diller ve SDK özellikleri için destek olduğundan emin olun. Her dil/SDK için her özellik aynı şekilde kullanılamaz.

Doğru -luğunu

  • Çok bölgeli bir veri platformu tasarımı benimseyin ve verileri uygulama uç noktalarına yaklaştırarak en yüksek güvenilirlik, kullanılabilirlik ve performans için çoğaltmaları bölgeler arasında dağıtın.

    • Bölge içi kullanılabilirliği en üst düzeye çıkarmak için veri çoğaltmalarını bir bölgedeki Kullanılabilirlik Alanları (AZ) arasında dağıtın (veya alanlar arası yedekli hizmet katmanlarını kullanın).

  • Tutarlılık gereksinimlerinin buna olanak sağladığı durumlarda, genel kullanılabilirliği ve güvenilirliği en üst düzeye çıkarmak için çok bölgeli yazma veri platformu tasarımı kullanın.

    • Aynı veri öğesi iki ayrı yazma çoğaltmasında değiştirildiğinde, değişiklik çoğaltılmadan ve bu nedenle çakışma oluşturmadan önce çakışma çözümü için iş gereksinimlerini göz önünde bulundurun.
      • Mümkün olduğunda "Son kazanan" gibi standartlaştırılmış çakışma çözümleme ilkelerini kullanın
        • Özel mantık içeren özel bir strateji gerekiyorsa, özel mantığı yönetmek için CI/CD DevOps uygulamalarının uygulandığına emin olun.

  • Sürekli teslim süreçlerinde kaos testi aracılığıyla yedekleme ve geri yükleme özelliklerini ve yük devretme işlemlerini test edin ve doğrulayın.

  • Aktarım hızı ve performans gereksinimlerinin şifreleme gibi gerekli güvenlik özelliklerinin eklenmesinden etkilenmediğinden emin olmak için performans karşılaştırmalarını çalıştırın.

    • Sürekli teslim işlemlerinin bilinen performans karşılaştırmalarına göre yük testi yapmayı göz önünde bulundurdığından emin olun.

  • Şifreleme uygularken, yönetim karmaşıklığını azaltmanın bir yolu olarak hizmet tarafından yönetilen şifreleme anahtarlarının kullanılması kesinlikle önerilir.

    • Müşteri tarafından yönetilen anahtarlar için belirli bir güvenlik gereksinimi varsa, tüm dikkate alınan anahtarların kullanılabilirliğini, yedeklemesini ve döndürmesini sağlamak için uygun anahtar yönetimi yordamlarının uygulandığından emin olun.

Not

Daha geniş bir kuruluş uygulamasıyla tümleştirme yaparken, uygulama tasarımında veri platformu bileşenlerinin sağlanması ve çalıştırılması için uygulama merkezli bir yaklaşımın uygulanması kritik önem taşır.

Daha ayrıntılı olarak belirtmek gerekirse, güvenilirliği en üst düzeye çıkarmak için tek tek veri platformu bileşenlerinin diğer uygulama bileşenlerini içerebilecek operasyonel eylemler aracılığıyla uygulama durumuna uygun şekilde yanıt vermesi kritik önem taşır. Örneğin, ek veri platformu kaynaklarının gerekli olduğu bir senaryoda, veri platformunu ve diğer uygulama bileşenlerini kapasite modeline göre ölçeklendirmek, büyük olasılıkla ek ölçek birimlerinin sağlanması yoluyla gerekli olacaktır. Merkezi operasyon ekibinin veri platformuyla ilgili sorunları yalıtılmış olarak ele almak için sıkı bir bağımlılığı varsa, bu yaklaşım nihai olarak kısıtlanır.

Sonuç olarak, merkezi veri hizmetlerinin (Yani Merkezi BT DBaaS) kullanılması, büyük ölçüde metinsiz bir yönetim deneyimi aracılığıyla çevikliği önemli ölçüde engelleyen ve görev açısından kritik veya iş açısından kritik bir bağlamda kaçınılması gereken operasyonel performans sorunlarına neden olur.

Ek başvurular

ek veri platformu kılavuzuna Azure Uygulaması Lication Mimari Kılavuzu'nda ulaşabilirsiniz.

Genel olarak dağıtılmış çok bölgeli yazma veri deposu

Bir uygulama tasarımının genel olarak dağıtılan etkin-etkin hedeflerine tam olarak uyum sağlamak için, ayrı yazılabilir çoğaltmalarda yapılan değişikliklerin eşitlendiği ve tüm çoğaltmalar arasında birleştirildiği, gerektiğinde çakışma çözümüne sahip dağıtılmış çok bölgeli yazma veri platformunu göz önünde bulundurmanız kesinlikle önerilir.

Önemli

Mikro hizmetlerin tümü dağıtılmış bir çok bölgeli yazma veri deposu gerektirmeyebilir, bu nedenle her iş yükü senaryosunun mimari bağlamı ve iş gereksinimlerine dikkat edilmelidir.

Azure Cosmos DB, genel olarak dağıtılmış ve yüksek oranda kullanılabilir bir NoSQL veri deposu sunarak çok bölgeli yazma işlemleri ve kullanıma hazır ayarlanabilir tutarlılık sunar. Bu nedenle bu bölümdeki tasarım konuları ve önerileri en iyi Azure Cosmos DB kullanımına odaklanacaktır.

Tasarımla ilgili dikkat edilecek noktalar

Azure Cosmos DB

  • Azure Cosmos DB, verileri, milisaniye sırasına göre yanıt süreleriyle hızlı işlemsel okuma ve yazma işlemlerine olanak sağlamak için tasarlanmış, dizine alınmış, satır tabanlı işlemsel depolar olan Kapsayıcılar içinde depolar.

  • Azure Cosmos DB, SQL, Cassandra ve MongoDB gibi farklı özellik kümelerine sahip birden çok farklı API'yi destekler.

    • NoSQL için birinci taraf Azure Cosmos DB, en zengin özellik kümesini sağlar ve genellikle yeni özelliklerin ilk kullanıma sunulacağı API'dir.

  • Azure Cosmos DB, Ağ Geçidi ve Doğrudan bağlantı modlarını destekler. Burada Direct, daha az ağ atlamasıyla iyileştirilmiş performans için arka uç Azure Cosmos DB çoğaltma düğümlerine TCP üzerinden bağlantıyı kolaylaştırırken, Ağ Geçidi ön uç ağ geçidi düğümlerine HTTPS bağlantısı sağlar.

    • Doğrudan mod yalnızca NoSQL için Azure Cosmos DB kullanıldığında kullanılabilir ve şu anda yalnızca .NET ve Java SDK platformlarında desteklenir.

  • Kullanılabilirlik Alanı özellikli bölgelerde Azure Cosmos DB, bir bölgedeki bölgesel hatalara karşı yüksek kullanılabilirlik ve dayanıklılık için Kullanılabilirlik Alanı (AZ) yedekliliği desteği sunar.

  • Azure Cosmos DB, verilerin dört çoğaltmasını tek bir bölgede tutar ve Kullanılabilirlik Alanı (AZ) yedekliliği etkinleştirildiğinde Azure Cosmos DB, bölgesel hatalara karşı koruma sağlamak için veri çoğaltmalarının birden çok AZ'ye yerleştirilmesini sağlar.

    • Bölge içindeki çoğaltmalar arasında çekirdek elde etmek için Paxos konsensüs protokolü uygulanır.

  • Azure Cosmos DB hesabı, tek bir bölgenin kullanılamama riskini azaltmak için verileri birden çok bölgede çoğaltacak şekilde kolayca yapılandırılabilir.

    • Çoğaltma, tek bölgeli yazmalar veya çok bölgeli yazmalarla yapılandırılabilir.
      • Tek bölge yazma işlemlerinde, tüm yazma işlemlerine hizmet vermek için birincil bir 'hub' bölgesi kullanılır ve bu 'hub' bölgesi kullanılamaz duruma gelirse, başka bir bölgeyi yazılabilir olarak yükseltmek için bir yük devretme işlemi gerçekleşmelidir.
      • Çok bölgeli yazma işlemleriyle, uygulamalar yapılandırılmış herhangi bir dağıtım bölgesine yazabilir ve bu da değişiklikleri diğer tüm bölgeler arasında çoğaltabilir. Bir bölge kullanılamıyorsa, yazma trafiğine hizmet vermek için kalan bölgeler kullanılır.

  • Çok bölgeli yazma yapılandırmasında, yazıcıların aynı öğeyi birden çok bölgede eşzamanlı olarak güncelleştirdiği güncelleştirme (ekleme, değiştirme, silme) çakışmaları oluşabilir.

  • Azure Cosmos DB, çakışmaları otomatik olarak gidermek için uygulanabilen iki çakışma çözümleme ilkesi sağlar.

    • Son Yazma Kazançları (LWW), çakışma çözümleme yolu olarak sistem tanımlı bir zaman damgası _ts özelliği kullanan bir zaman eşitleme saat protokolü uygular. Bir çakışma durumunda, çakışma çözümleme yolu için en yüksek değere sahip olan öğe kazanan olur ve birden çok öğe aynı sayısal değere sahipse sistem, tüm bölgelerin kaydedilmiş öğenin aynı sürümüne yakınsayabilmesi için bir kazanan seçer.
      • Silme çakışmaları ile, silinen sürüm her zaman çakışma çözümleme yolu değerinden bağımsız olarak ekleme veya değiştirme çakışmaları üzerinde kazanır.
      • Son Yazma Wins varsayılan çakışma çözümleme ilkesidir.
      • NoSQL için Azure Cosmos DB kullanılırken, çakışma çözümlemesi için özel zaman damgası tanımı gibi özel bir sayısal özellik kullanılabilir.
    • Özel çözüm ilkeleri, uygulama tanımlı semantiğin çakışmalar algılandığında otomatik olarak çağrılan kayıtlı bir birleştirme saklı yordamı kullanarak çakışmaları mutabık kılabilmesine olanak sağlar.
      • Sistem, taahhüt protokolünün bir parçası olarak birleştirme yordamının yürütülmesi için tam olarak bir kez garanti sağlar.
      • Özel çakışma çözümleme ilkesi yalnızca NoSQL için Azure Cosmos DB ile kullanılabilir ve yalnızca kapsayıcı oluşturma zamanında ayarlanabilir.

  • Çok bölgeli yazma yapılandırmasında, tüm çakışma çözümlemelerini gerçekleştirmek için tek bir Azure Cosmos DB 'hub' bölgesine bağımlılık vardır ve hub bölgesindeki çoğaltmalar arasında çekirdek elde etmek için Paxos konsensüs protokolü uygulanır.

    • Platform, yük düzeyine ve geçici hatalar için yedeklilik sağlamak üzere hub bölgesindeki yazma çakışmaları için bir ileti arabelleği sağlar.
      • Arabellek, fikir birliği gerektiren birkaç dakikalık yazma güncelleştirmelerini depolayabilme özelliğine sahiptir.

Azure Cosmos DB platformunun stratejik yönü, küresel düzeyde ve bir bölge içinde çekirdek elde etmek için 2 aşamalı paxos yaklaşımını kullanarak çok bölgeli yazma yapılandırmasında çakışma çözümü için bu tek bölge bağımlılığını kaldırmaktır.

  • Birincil 'hub' bölgesi, Azure Cosmos DB'nin içinde yapılandırıldığı ilk bölge tarafından belirlenir.

    • Yük devretme amacıyla ek uydu dağıtım bölgeleri için öncelik sırası yapılandırılır.

  • Mantıksal ve fiziksel bölümler arasında veri modeli ve bölümleme, en iyi performans ve kullanılabilirlik elde edilmesinde önemli bir rol oynar.

  • Tek bir yazma bölgesi ile dağıtıldığında Azure Cosmos DB, tüm okuma bölgesi çoğaltmaları dikkate alınarak tanımlanmış bir yük devretme önceliğine göre otomatik yük devretme için yapılandırılabilir.

  • Azure Cosmos DB platformu tarafından sağlanan RTO yaklaşık 10-15 dakikadır ve merkez bölgesini etkileyen olağanüstü bir olağanüstü durum durumunda Azure Cosmos DB hizmetinin bölgesel yük devretmesini gerçekleştirmek için geçen süreyi yakalar.

    • Bu RTO, çakışma çözümü için tek bir 'hub' bölgesine bağımlılık göz önünde bulundurulduğunda çok bölgeli yazma bağlamında da geçerlidir.
      • 'Hub' bölgesi kullanılamaz duruma gelirse, hizmet yük devredilene ve yeni bir hub bölgesi kurulana kadar çakışma çözümü gerçekleşemeyeceğinden, ileti arabelleği dolduktan sonra diğer bölgelere yapılan yazma işlemleri başarısız olur.

Azure Cosmos DB platformunun stratejik yönü, bölüm düzeyinde yük devretmelere izin vererek RTO'yu yaklaşık 5 dakikaya düşürmektir.

  • Kurtarma Noktası Hedefleri (RPO) ve Kurtarma Süresi Hedefleri (RTO), tutarlılık düzeyleri aracılığıyla yapılandırılabilir ve veri dayanıklılığı ile aktarım hızı arasında bir denge sağlar.

    • Azure Cosmos DB, çok bölgeli yazma işlemleriyle rahat bir tutarlılık düzeyi için en az 0 RTO veya tek yazma bölgesiyle güçlü tutarlılık için 0 RPO sağlar.

  • Azure Cosmos DB, yazılabilir olarak birden çok Azure bölgesiyle yapılandırılmış Veritabanı Hesapları için hem okuma hem de yazma kullanılabilirliği için %99,999 SLA sunar.

    • SLA, %100 - Ortalama Hata Oranı olarak hesaplanan Aylık Çalışma Süresi Yüzdesi ile temsil edilir.
    • Ortalama Hata Oranı, faturalama ayındaki her bir saat için Hata Oranlarının toplamının faturalama ayındaki toplam saat sayısına bölünmesi olarak tanımlanır; burada Hata Oranı, belirli bir saatlik aralıkta Toplam İstekler'e bölünen Toplam İstek sayısıdır.

  • Azure Cosmos DB, beş Tutarlılık Düzeyinden herhangi biriyle yapılandırıldığında tek bir Azure bölgesi kapsamındaki Veritabanı Hesapları için aktarım hızı, tutarlılık, kullanılabilirlik ve gecikme süresi için %99,99 SLA sunar.

    • %99,99 SLA, dört gevşek Tutarlılık Düzeyi'nin herhangi biriyle yapılandırılmış birden çok Azure bölgesine yayılan Veritabanı Hesapları için de geçerlidir.

  • Azure Cosmos DB'de sağlanabilir iki tür aktarım hızı vardır: standart ve otomatik ölçeklendirme, saniye başına İstek Birimleri (RU/sn) kullanılarak ölçülür.

    • Standart aktarım hızı, belirtilen RU/sn değerini garanti etmek için gereken kaynakları ayırır.
      • Standart, sağlanan aktarım hızı için saatlik olarak faturalandırılır.
    • Otomatik ölçeklendirme en yüksek aktarım hızı değerini tanımlar ve Azure Cosmos DB, uygulama yüküne bağlı olarak maksimum aktarım hızı değeri ile maksimum aktarım hızı değerinin en az %10'unun arasında otomatik olarak ölçeği artırır veya küçültür.
      • Otomatik ölçeklendirme, tüketilen maksimum aktarım hızı için saatlik olarak faturalandırılır.

  • Değişken bir iş yüküyle sağlanan statik aktarım hızı azaltma hatalarıyla sonuçlanabilir ve bu da algılanan uygulama kullanılabilirliğini etkiler.

    • Otomatik ölçeklendirme, Azure Cosmos DB'nin ölçeği gerektiği gibi artırmasına olanak tanıyarak azaltma hatalarına karşı koruma sağlarken, yük azaldığında ölçeği azaltarak maliyet korumasını korur.

  • Azure Cosmos DB birden çok bölgede çoğaltıldığında, sağlanan İstek Birimleri (RU) bölge başına faturalandırılır.

  • Çok bölgeli yazma ile tek bölgeli yazma yapılandırması arasında önemli bir maliyet değişikliği vardır ve bu da çoğu durumda çok ana azure Cosmos DB veri platformlarının maliyetinin engelleyici olmasına neden olabilir.

Tek Bölge okuma/yazma Tek Bölge Yazma - İkili Bölge Okuma İkili Bölge Okuma/Yazma
1 RU 2 RU 4 RU

Tek bölgeli yazma ile çok bölgeli yazma arasındaki değişim, yukarıdaki tabloya yansıtılan 1:2 oranından daha azdır. Daha açık belirtmek gerekirse, çoklu bölge yazma yapılandırmasında olduğu gibi RU maliyetleri içinde yakalanmayan tek yazma yapılandırmasındaki yazma güncelleştirmeleriyle ilişkili bölgeler arası veri aktarımı ücreti vardır.

  • Tüketilen depolama alanı, belirli bir saat boyunca verileri ve dizinleri barındırmak için kullanılan toplam depolama (GB) miktarı için sabit bir fiyat olarak faturalandırılır.

  • Session , veriler yazma işlemleriyle aynı sırada alındığından varsayılan ve en yaygın kullanılan tutarlılık düzeyidir .

  • Azure Cosmos DB, çakışan özellikler sağlayan Microsoft Entra kimliği veya Azure Cosmos DB anahtarları ve kaynak belirteçleri aracılığıyla kimlik doğrulamayı destekler.

Azure Cosmos DB Erişim Özellikleri

  • Anahtarları ve kaynak belirteçlerini yalnızca veri işlemleriyle sınırlandırmak için anahtarlar veya kaynak belirteçleri kullanarak kaynak yönetimi işlemlerini devre dışı bırakmak mümkündür. Bu sayede Microsoft Entra rol tabanlı erişim denetimi (RBAC) kullanılarak ayrıntılı kaynak erişim denetimi yapılabilir.

  • Azure Cosmos DB'deki Microsoft Entra RBAC desteği, hesap ve kaynak denetim düzlemi yönetim işlemleri için geçerlidir.

  • Azure Cosmos DB kaynakları (hesaplar, veritabanları ve kapsayıcılar) Kaynak Kilitleri kullanılarak yanlış değişiklik veya silmeye karşı korunabilir.

    • Kaynak Kilitleri hesap, veritabanı veya kapsayıcı düzeyinde ayarlanabilir.
    • Bir kaynakta ayarlanan Kaynak Kilidi tüm alt kaynaklar tarafından devralınır. Örneğin, Azure Cosmos DB hesabındaki bir Kaynak Kilidi kümesi, hesaptaki tüm veritabanları ve kapsayıcılar tarafından devralınır.
    • Kaynak Kilitleri yalnızca denetim düzlemi işlemleri için geçerlidir ve veri oluşturma, değiştirme veya silme gibi veri düzlemi işlemlerini engellemez.
    • Denetim düzlemi erişimi ile disableKeyBasedMetadataWriteAccesskısıtlanmadıysa, istemciler hesap anahtarlarını kullanarak denetim düzlemi işlemleri gerçekleştirebilir.

  • Azure Cosmos DB değişiklik akışı, Azure Cosmos DB kapsayıcısında verilerde yapılan değişikliklerin zaman sıralı akışını sağlar.

    • Değişiklik akışı yalnızca kaynak Azure Cosmos DB kapsayıcısına ekleme ve güncelleştirme işlemlerini içerir; silmeleri içermez.

  • Değişiklik akışı, kaynak Kapsayıcıdan değişiklik akışı tarafından beslenen hedef veri deposunda devam eden güncelleştirmeler ile uygulama tarafından kullanılan birincil Kapsayıcıdan ayrı bir veri deposu tutmak için kullanılabilir.

    • Değişiklik akışı, ek veri platformu yedekliliği veya sonraki analitik senaryolar için ikincil depoyu doldurmak için kullanılabilir.

  • Silme işlemleri düzenli olarak kaynak Kapsayıcı içindeki verileri etkilerse, değişiklik akışı tarafından beslenen depo yanlış olur ve silinen veriler için geri başvurulmaz.

    • Veri kayıtlarının değişiklik akışına dahil edilmesi için Geçici Silme düzeni uygulanabilir.
      • Veri kayıtlarını açıkça silmek yerine, öğenin silinmiş olarak kabul edildiğini belirtmek için bir bayrak (örn. IsDeleted) ayarlanarak veri kayıtları güncelleştirilir.
      • Değişiklik akışı tarafından beslenen tüm hedef veri depolarının silinmiş bayrağı True olarak ayarlanmış öğeleri algılaması ve işlemesi gerekir; geçici olarak silinen veri kayıtlarını depolamak yerine, hedef depodaki veri kaydının mevcut sürümünün silinmesi gerekir.
    • Azure Cosmos DB'nin süresi dolan verileri otomatik olarak silmesi için geçici silme düzeniyle kısa bir Yaşam Süresi (TTL) kullanılır, ancak yalnızca silinen bayrağı True olarak ayarlanmış değişiklik akışına yansıtıldıktan sonra.
      • Özgün silme amacını gerçekleştirirken, silme işlemini değişiklik akışı aracılığıyla da yayılır.

  • Azure Cosmos DB, geleneksel ETL işlem hatlarında ortaya çıkan karmaşıklık ve gecikme sorunlarını gidermek için iyileştirilmiş analitik sorgular için bir sütun biçimi uygulayan bir analiz deposu olarak yapılandırılabilir.

  • Azure Cosmos DB, performansı veya kullanılabilirliği etkilemeden ve RU/sn kullanmadan düzenli aralıklarla verileri otomatik olarak yedekler.

  • Azure Cosmos DB iki ayrı yedekleme moduna göre yapılandırılabilir.

    • Periyodik , yedeklemelerin düzenli aralıklarla alındığı ve destek ekibiyle bir istek oluşturularak verilerin geri yüklendiği tüm hesaplar için varsayılan yedekleme modudur.
      • Varsayılan düzenli yedekleme saklama süresi sekiz saattir ve varsayılan yedekleme aralığı dört saattir; yani varsayılan olarak yalnızca en son iki yedekleme depolanır.
      • Yedekleme aralığı ve saklama süresi hesap içinde yapılandırılabilir.
        • Maksimum saklama süresi, en az bir saatlik yedekleme aralığıyla bir aya kadar uzanır.
        • Yedekleme depolama yedekliliğini yapılandırmak için Azure "Cosmos DB Hesap OkuyucuSu Rolü" için bir rol ataması gerekir.
      • İki yedek kopya ek ücret ödemeden dahil edilir, ancak ek yedeklemeler ek ücrete tabidir.
      • Varsayılan olarak, düzenli yedeklemeler doğrudan erişilebilir olmayan ayrı Coğrafi Olarak Yedekli Depolama (GRS) içinde depolanır.
        • Yedekleme depolama alanı birincil 'hub' bölgesinde bulunur ve temel alınan depolama çoğaltması aracılığıyla eşleştirilmiş bölgeye çoğaltılır.
        • Temel alınan yedekleme depolama hesabının yedeklilik yapılandırması Alanlar Arası Yedekli Depolama veya Yerel Olarak Yedekli Depolama olarak yapılandırılabilir.
      • Geri yükleme işlemi gerçekleştirmek için destek isteği gerekir çünkü müşteriler doğrudan geri yükleme gerçekleştiremez.
        • Destek bileti açmadan önce, yedekleme saklama süresi veri kaybı olayından sonraki sekiz saat içinde en az yedi güne yükseltilmelidir.
      • Geri yükleme işlemi, verilerin kurtarıldığı yeni bir Azure Cosmos DB hesabı oluşturur.
        • Mevcut bir Azure Cosmos DB hesabı Geri Yükleme için kullanılamaz
        • Varsayılan olarak, adlı <Azure_Cosmos_account_original_name>-restored<n> yeni bir Azure Cosmos DB hesabı kullanılır.
          • Bu ad, örneğin özgün hesap silinmişse mevcut adı yeniden kullanarak ayarlanabilir.
      • Aktarım hızı veritabanı düzeyinde sağlanırsa, veritabanı düzeyinde yedekleme ve geri yükleme gerçekleşir
        • Geri yükleneceği kapsayıcıların bir alt kümesini seçmek mümkün değildir.
    • Sürekli yedekleme modu, son 30 gün içinde herhangi bir noktaya geri yükleme yapılmasını sağlar.
      • Geri yükleme işlemleri, bir saniyelik ayrıntı düzeyine sahip belirli bir noktaya (PITR) dönmek için gerçekleştirilebilir.
      • Geri yükleme işlemleri için kullanılabilir pencere 30 güne kadardır.
        • Kaynak örnekleme durumuna geri yüklemek de mümkündür.
      • Sürekli yedeklemeler, Azure Cosmos DB hesabının bulunduğu her Azure bölgesinde alınır.
        • Sürekli yedeklemeler, Kullanılabilirlik Alanları destekleyen bölgelerde Yerel Olarak Yedekli Depolama (LRS) veya Bölgesel Olarak Yedekli Depolama (ZRS) kullanılarak her Azure Cosmos DB çoğaltmasıyla aynı Azure bölgesinde depolanır.
      • Azure portalı veya ARM şablonları gibi IaC yapıtları kullanılarak self servis geri yükleme gerçekleştirilebilir.
      • Sürekli Yedekleme ile ilgili çeşitli sınırlamalar vardır.
        • Sürekli yedekleme modu şu anda çok bölgeli yazma yapılandırmasında kullanılamıyor.
        • Şu anda yalnızca NoSQL için Azure Cosmos DB ve MongoDB için Azure Cosmos DB Sürekli yedekleme için yapılandırılabilir.
        • Bir kapsayıcıda TTL yapılandırılmışsa, TTL'sini aşan geri yüklenen veriler hemen silinebilir
      • Geri yükleme işlemi, belirli bir noktaya geri yükleme için yeni bir Azure Cosmos DB hesabı oluşturur.
      • Sürekli yedekleme ve geri yükleme işlemleri için ek depolama maliyeti vardır.

  • Mevcut Azure Cosmos DB hesapları Düzenli'den Sürekli'ye geçirilebilir, ancak Sürekli'den Düzenli'ye geçirilebilir; geçiş tek yönlüdür ve geri alınamaz.

  • Her Azure Cosmos DB yedeklemesi sağlanan aktarım hızı, dizin oluşturma ilkeleri, dağıtım alanları ve kapsayıcı TTL ayarları için verilerin kendisinden ve yapılandırma ayrıntılarından oluşur.

  • Düzenli ve Sürekli yaklaşımların uygun olmadığı senaryolar için özel bir yedekleme ve geri yükleme özelliği uygulamak mümkündür.

    • Özel bir yaklaşım, anlaşılması ve dikkatle değerlendirilmesi gereken önemli maliyetler ve ek yönetim ek yükü getirir.
      • Veri öğesindeki bir hesabın, veritabanının, kapsayıcının bozulması veya silinmesi gibi yaygın geri yükleme senaryoları modellenmelidir.
      • Yedeklemenin yayılmasını önlemek için temizlik yordamları uygulanmalıdır.
    • Azure Depolama veya alternatif bir veri teknolojisi kullanılabilir, örneğin alternatif bir Azure Cosmos DB kapsayıcısı.
      • Azure Depolama ve Azure Cosmos DB, Azure İşlevleri ve Azure Data Factory gibi Azure hizmetleriyle yerel tümleştirmeler sağlar.

  • Azure Cosmos DB belgelerinde özel yedeklemeler uygulamak için iki olası seçenek gösterilir.

    • Ayrı bir depolama tesisine veri yazmak için Azure Cosmos DB değişiklik akışı .
      • Azure işlevi veya eşdeğer bir uygulama işlemi, değişiklik akışına bağlanmak ve öğeleri depolamaya işlemek için değişiklik akışı işlemcisini kullanır.
    • Değişiklik akışı kullanılarak hem sürekli hem de düzenli (toplu) özel yedeklemeler uygulanabilir.
    • Azure Cosmos DB değişiklik akışı henüz silmeleri yansıtmadığından boole özelliği ve TTL kullanılarak geçici silme düzeni uygulanmalıdır.
      • Değişiklik akışı tam uygunluk güncelleştirmeleri sağladığında bu düzen gerekli olmayacaktır.
    • Verileri kopyalamak için Azure Cosmos DB için Azure Data Factory Bağlayıcısı (NoSQL için Azure Cosmos DB veya MongoDB API bağlayıcıları).
      • Azure Data Factory (ADF), el ile yürütmeyi ve Zamanlama, Atlayan pencere ve Olay tabanlı tetikleyicileri destekler.
        • Hem Depolama hem de Event Grid için destek sağlar.
      • ADF, toplu iş odaklı düzenlemesi nedeniyle öncelikle düzenli özel yedekleme uygulamaları için uygundur.
        • Düzenleme yürütme yükü nedeniyle sık gerçekleşen olaylarla sürekli yedekleme uygulamaları için daha az uygundur.
      • ADF, yüksek ağ güvenlik senaryoları için Azure Özel Bağlantı destekler

Azure Cosmos DB birçok Azure hizmeti tasarımında kullanıldığından, Azure Cosmos DB için önemli bir bölgesel kesinti söz konusu bölgedeki çeşitli Azure hizmetlerinde basamaklı bir etkiye sahip olacaktır. Belirli bir hizmet üzerindeki kesin etki, temel alınan hizmet tasarımının Azure Cosmos DB'yi nasıl kullandığına bağlıdır.

Tasarım Önerileri

Azure Cosmos DB

  • Gereksinimlerin izin aldığı birincil veri platformu olarak Azure Cosmos DB'yi kullanın.

  • Görev açısından kritik iş yükü senaryoları için Azure Cosmos DB'yi her dağıtım bölgesinde bir yazma çoğaltması ile yapılandırarak gecikme süresini azaltın ve maksimum yedeklilik sağlayın.

    • Uygulama yükünü, performansını ve bölgesel RU/sn tüketimini iyileştirmek amacıyla yazma ve okuma işlemleri için yerel Azure Cosmos DB çoğaltmasının kullanımına öncelik vermek üzere uygulamayı yapılandırın.
    • Çok bölgeli yazma yapılandırması önemli bir maliyetle gelir ve yalnızca en yüksek güvenilirlik gerektiren iş yükü senaryoları için önceliklendirilmelidir.

  • Daha az kritik iş yükü senaryoları için, genel olarak dağıtılmış okuma amaçlı çoğaltmalarla tek bölgeli yazma yapılandırmasının (Kullanılabilirlik Alanları kullanılırken) kullanımına öncelik sağlayın, çünkü bu daha cazip bir fiyat noktasında yüksek düzeyde veri platformu güvenilirliği (%99,999 yazma işlemleri için %99,999 SLA) sunar.

    • Okuma performansını iyileştirmek için uygulamayı yerel Azure Cosmos DB okuma çoğaltmasını kullanacak şekilde yapılandırın.

  • Çakışma çözümlemenin çok bölgeli yazma yapılandırmasında gerçekleşeceği ve tüm yazmaların tek bölgeli yazma yapılandırmasında gerçekleştirileceği en uygun 'hub' dağıtım bölgesini seçin.

    • Diğer dağıtım bölgelerine göre mesafeyi ve birincil bölgeyi seçmeye ilişkin gecikme süresini ve Kullanılabilirlik Alanları desteği gibi gerekli özellikleri göz önünde bulundurun.

  • Bir bölgedeki bölgesel hatalara dayanıklılık sağlamak için Az desteğine sahip tüm dağıtım bölgelerinde Kullanılabilirlik Alanı (AZ) yedekliliği ile Azure Cosmos DB'yi yapılandırın.

  • Özellikle performans ayarlama konusunda en kapsamlı özellik kümesini sunduğundan NoSQL için Azure Cosmos DB'yi kullanın.

    • Alternatif API'ler öncelikli olarak geçiş veya uyumluluk senaryoları için dikkate alınmalıdır.
      • Alternatif API'leri kullanırken, en iyi yapılandırmayı ve performansı sağlamak için gerekli özelliklerin seçili dil ve SDK ile kullanılabilir olduğunu doğrulayın.

  • Arka uç Azure Cosmos DB düğümlerine doğrudan TCP bağlantısı aracılığıyla ağ performansını iyileştirmek için Doğrudan bağlantı modunu kullanın ve ağ 'atlama sayısı' azaldı.

Azure Cosmos DB SLA'sı, %99,999 güvenilirlik katmanı hata bütçesiyle doğrudan uyumlu olmayan, başarısız isteklerin ortalamasını alarak hesaplanır. Bu nedenle %99,999 SLO için tasarım yaparken bölgesel ve çok bölgeli Azure Cosmos DB yazma kullanılamaması için planlama yapmak ve sonraki yeniden yürütme için kalıcı ileti kuyruğu gibi bir hata durumunda geri dönüş depolama teknolojisinin konumlandırılmasını sağlamak çok önemlidir.

  • Veri modeline göre veri dağıtımını iyileştirmek için hem mantıksal hem de fiziksel bölümler arasında bir bölümleme stratejisi tanımlayın.

    • Bölümler arası sorguları en aza indirin.
    • En iyi performansı sağlamak için bölümleme stratejisini yinelemeli olarak test edin ve doğrulayın .

  • En uygun bölüm anahtarını seçin.

    • Bölüm anahtarı koleksiyon içinde oluşturulduktan sonra değiştirilemez.
    • Bölüm anahtarı değişmeyen bir özellik değeri olmalıdır.
    • Çok çeşitli olası değerler içeren yüksek kardinaliteye sahip bir bölüm anahtarı seçin.
    • Bölüm anahtarı, RU tüketimini ve veri depolamasını fiziksel bölümler arasında ru tüketimi ve depolama dağılımının eşit olmasını sağlamak için tüm mantıksal bölümlere eşit olarak yaymalıdır.
    • RU tüketimini ve gecikme süresini azaltmak için bölümlenmiş sütunda okuma sorguları çalıştırın.

  • Dizin oluşturma performans açısından da çok önemlidir, bu nedenle RU/sn ve depolama gereksinimlerini azaltmak için dizin dışlamalarının kullanıldığından emin olun.

    • Yalnızca sorgular içinde filtreleme için gereken alanları dizine alın; en çok kullanılan koşul için tasarım dizinleri.

  • Azure Cosmos DB SDK'sının yerleşik hata işleme, yeniden deneme ve daha kapsamlı güvenilirlik özelliklerinden yararlanın.

    • İstemcilerde SDK içinde yeniden deneme mantığını uygulayın.

  • Yönetim karmaşıklığını azaltmak için hizmet tarafından yönetilen şifreleme anahtarlarını kullanın.

    • Müşteri tarafından yönetilen anahtarlar için belirli bir güvenlik gereksinimi varsa yedekleme ve döndürme gibi uygun anahtar yönetimi yordamlarının uygulandığına emin olun.

  • Yerleşik Azure İlkesi uygulayarak Azure Cosmos DB anahtar tabanlı meta veri yazma erişimini devre dışı bırakın.

  • Sağlanan aktarım hızı (RU/sn) gibi önemli ölçümleri ve tanılama günlüklerini toplamak için Azure İzleyici'yi etkinleştirin.

    • Azure İzleyici işletimsel verilerini Azure Cosmos DB'ye ve uygulama tasarımındaki diğer genel kaynaklara ayrılmış bir Log Analytics çalışma alanına yönlendirin.
    • Uygulama trafiği desenlerinin otomatik ölçeklendirme için uygun olup olmadığını belirlemek için Azure İzleyici ölçümlerini kullanın.

  • Sağlanan aktarım hızı türleri için en uygun seçeneği seçmek üzere uygulama trafiği desenlerini değerlendirin.

    • Sağlanan aktarım hızını otomatik olarak ölçeklendirin ve iş yükü talebini otomatik olarak yükseltin.

  • geliştirilmiş gecikme süresi ve aktarım hızı için istemci tarafı ve sunucu tarafı yapılandırmasını iyileştirmek için Azure Cosmos DB için Microsoft performans ipuçlarını değerlendirin.

  • İşlem platformu olarak AKS kullanırken: Yoğun sorgu kullanan iş yükleri için gecikme süresini ve CPU değişimlerini azaltmak için hızlandırılmış ağ etkinleştirilmiş bir AKS düğümü SKU'su seçin.

  • Tek yazma bölgesi dağıtımları için Azure Cosmos DB'nin otomatik yük devretme için yapılandırılması kesinlikle önerilir.

  • Azure Cosmos DB'ye güncelleştirme yazan sistem akışları içinde zaman uyumsuz, engelleyici olmayan mesajlaşma kullanımıyla yük düzeyi.

  • Azure Cosmos DB hesabını sürekli yedeklemeler için yapılandırarak son 30 gün içinde kurtarma noktalarının ayrıntılı bir ayrıntı düzeyini elde edin.

    • Kapsanan verilerin veya Azure Cosmos DB hesabının silindiği veya bozulduğu senaryolarda Azure Cosmos DB yedeklemelerinin kullanımını göz önünde bulundurun.
    • Kesinlikle gerekli olmadıkça özel bir yedekleme yaklaşımı kullanmaktan kaçının.

  • Standart iş sürekliliği operasyon hazırlığı kapsamında üretim dışı kaynaklar ve veriler üzerinde kurtarma yordamları uygulamanız kesinlikle önerilir.

  • Azure Cosmos DB yedekleme geri yüklemesinin yapılandırma ayarlarını ve özelliklerini yeniden oluşturmak için IaC yapıtlarını tanımlayın.

  • Azure Cosmos DB Yedekleme ve Kurtarma için Azure Güvenlik Temeli denetim kılavuzunu değerlendirin ve uygulayın.

  • Çok bölgeli kullanılabilirlik gerektiren analitik iş yükleri için, iyileştirilmiş analitik sorgular için sütun biçimi uygulayan Azure Cosmos DB Analiz Deposu'nı kullanın.

İlişkisel veri teknolojileri

Yüksek düzeyde ilişkisel veri modeline veya mevcut ilişkisel teknolojilere bağımlılıklara sahip senaryolar için Azure Cosmos DB'nin çok bölgeli yazma yapılandırmasında kullanılması doğrudan geçerli olmayabilir. Bu gibi durumlarda, kullanılan ilişkisel teknolojilerin bir uygulama tasarımının çok bölgeli etkin-etkin hedeflerini destekleyecek şekilde tasarlanıp yapılandırılması çok önemlidir.

Azure, Azure SQL Veritabanı ve MySQL, PostgreSQL ve MariaDB gibi yaygın işletim sistemi ilişkisel çözümleri için Azure Veritabanı gibi birçok yönetilen ilişkisel veri platformu sağlar. Bu nedenle bu bölümdeki tasarım konuları ve önerileri, güvenilirliği ve genel kullanılabilirliği en üst düzeye çıkarmak için Azure SQL Veritabanı ve Azure Veritabanı işletim sistemi türlerinin en iyi kullanımına odaklanacaktır.

Tasarımla ilgili dikkat edilecek noktalar

  • İlişkisel veri teknolojileri okuma işlemlerini kolayca ölçeklendirecek şekilde yapılandırılsa da, yazma işlemleri genellikle tek bir birincil örnekten geçecek şekilde kısıtlanır ve bu da ölçeklenebilirlik ve performans açısından önemli bir kısıtlamaya neden olur.

  • Parçalama , verileri ve işlemeyi birden çok özdeş yapılandırılmış veritabanına dağıtmak, veritabanlarını yatay olarak bölümleyerek platform kısıtlamalarına gitmek için uygulanabilir.

    • Örneğin, parçalama genellikle kiracı gruplarını ayrı veri platformu yapılarına ayırmak için çok kiracılı SaaS platformlarında uygulanır.

Azure SQL Veritabanı

  • Azure SQL Veritabanı, SQL Server veritabanı altyapısının ve temel işletim sisteminin en son kararlı sürümünde her zaman çalışan tam olarak yönetilen bir veritabanı altyapısı sağlar.

    • Performans ayarlama, tehdit izleme ve güvenlik açığı değerlendirmeleri gibi akıllı özellikler sağlar.

  • Azure SQL Veritabanı, okuma amaçlı çoğaltmaları Azure bölgelerine dağıtmak için yerleşik bölgesel yüksek kullanılabilirlik ve anahtar teslimi coğrafi çoğaltma sağlar.

    • Coğrafi çoğaltma ile, yük devretme başlatılana kadar ikincil veritabanı çoğaltmaları salt okunur kalır.
    • Aynı veya farklı bölgelerde en fazla dört ikincil desteklenir.
    • İkincil çoğaltmalar, okuma performansını iyileştirmek için salt okunur sorgu erişimi için de kullanılabilir.
    • Yük devretme el ile başlatılmalıdır, ancak otomatik işlem yordamlarında sarmalanabilir.

  • Azure SQL Veritabanı sağlar Veritabanlarını ikincil bir sunucuya çoğaltan ve hata durumunda saydam yük devretmeye izin veren Otomatik Yük Devretme Grupları.

    • Otomatik yük devretme grupları, gruptaki tüm veritabanlarının farklı bir bölgedeki tek bir ikincil sunucuya veya örneğe coğrafi çoğaltmasını destekler.
    • Otomatik yük devretme grupları şu anda Hiper Ölçek hizmet katmanında desteklenmiyor.
    • İkincil veritabanları okuma trafiğini boşaltmak için kullanılabilir.

  • Premium veya İş Açısından Kritik hizmet katmanı veritabanı çoğaltmaları ek ücret ödemeden Kullanılabilirlik Alanları arasında dağıtılabilir.

    • Denetim halkası aynı zamanda birden çok bölgede üç ağ geçidi halkası (GW) olarak çoğaltılır.
      • Belirli bir ağ geçidi halkasına yönlendirme, Azure Traffic Manager tarafından denetlenilir.
    • İş Açısından Kritik katmanı kullanılırken, alanlar arası yedekli yapılandırma yalnızca 5. Nesil işlem donanımı seçildiğinde kullanılabilir.

  • Azure SQL Veritabanı, tüm hizmet katmanlarında temel %99,99 kullanılabilirlik SLA'sı sunar, ancak kullanılabilirlik alanlarını destekleyen bölgelerdeki İş Açısından Kritik veya Premium katmanları için %99,995 daha yüksek bir SLA sağlar.

    • Alanlar Arası Yedekli Dağıtımlar için yapılandırılmamış Azure SQL Veritabanı İş Açısından Kritik veya Premium katmanların kullanılabilirlik SLA'sı %99,99'dır.

  • Coğrafi çoğaltma ile yapılandırıldığında, Azure SQL Veritabanı İş Açısından Kritik katmanı dağıtılan saatlerin %100'ünün 30 saniyelik bir Kurtarma Süresi Hedefi (RTO) sağlar.

  • Coğrafi çoğaltma ile yapılandırıldığında, Azure SQL Veritabanı İş Açısından Kritik katmanının dağıtılan saatlerin %100'ünün 5 saniyelik bir Kurtarma Noktası Hedefi (RPO) vardır.

  • Azure SQL Veritabanı Hiper Ölçek katmanı, en az iki çoğaltmayla yapılandırıldığında %99,99 kullanılabilirlik SLA'sı içerir.

  • Azure SQL Veritabanı ile ilişkili işlem maliyetleri Rezervasyon İndirimi kullanılarak azaltılabilir.

    • DTU tabanlı veritabanları için ayrılmış kapasite uygulamak mümkün değildir.

  • Belirli bir noktaya geri yükleme , veritabanını ve içerdiği verileri zamanın önceki bir noktasına döndürmek için kullanılabilir.

  • Coğrafi geri yükleme , veritabanını coğrafi olarak yedekli bir yedeklemeden kurtarmak için kullanılabilir.

PostgreSQL için Azure Veritabanı

  • PostgreSQL için Azure Veritabanı üç farklı dağıtım seçeneğiyle sunulur:

    • Tek Sunucu, SLA %99,99
    • Kullanılabilirlik Alanı yedekliliği sunan Esnek Sunucu, %99,99 SLA
    • Yüksek Kullanılabilirlik modu etkinleştirildiğinde Hiper Ölçek (Citus), SLA %99,95.

  • Hiper Ölçek (Citus), uygulama değişikliği olmadan parçalama aracılığıyla dinamik ölçeklenebilirlik sağlar.

    • Tablo satırlarını birden çok PostgreSQL sunucusuna dağıtmak, Hiper Ölçek'te (Citus) ölçeklenebilir sorgular sağlamak için önemlidir.
    • Birden çok düğüm, geleneksel bir veritabanından daha fazla veriyi toplu olarak tutabilir ve çoğu durumda maliyetleri iyileştirmek için çalışan CPU'larını paralel olarak kullanabilir.

  • Otomatik ölçeklendirme , değişen trafik desenlerine yanıt olarak esneklik sağlamak için runbook otomasyonu aracılığıyla yapılandırılabilir.

  • Esnek sunucu, sunucuyu durdurma/başlatma özelliği ve sürekli işlem kapasitesi gerektirmeyen iş yükleri için uygun bir seri işlem katmanı aracılığıyla üretim dışı iş yükleri için maliyet verimlilikleri sağlar.

  • Toplam sağlanan sunucu depolama alanının %100'ünün yedek depolama alanı için ek ücret alınmaz.

    • Ek yedekleme depolama alanı tüketimi, tüketilen GB/ay'a göre ücretlendirilir.

  • PostgreSQL için Azure Veritabanı ile ilişkili işlem maliyetleri, Tek Sunuculu Rezervasyon İndirimi veya Hiper Ölçek (Citus) Rezervasyon İndirimi kullanılarak azaltılabilir.

Tasarım Önerileri

  • İlişkisel veritabanlarını farklı uygulama ve veri bağlamlarına göre bölümleyerek platform kısıtlamaları arasında gezinmeye, ölçeklenebilirlik ve kullanılabilirliği en üst düzeye çıkarmaya ve hata yalıtımına yardımcı olmak için parçalama yapmayı göz önünde bulundurun.

    • İlişkisel teknoloji kısıtlamaları küresel olarak dağıtılmış veri platformlarını önemli ölçüde engelleyebileceğinden bu öneri özellikle uygulama tasarımında üç veya daha fazla Azure bölgesi dikkate alındığında yaygındır.
    • Parçalama tüm uygulama senaryoları için uygun olmadığından bağlamsal değerlendirme gereklidir.

  • Azure platformundaki olgunluğu ve çok çeşitli güvenilirlik özellikleri nedeniyle ilişkisel gereksinimlerin mevcut olduğu Azure SQL Veritabanı kullanımına öncelik verme.

Azure SQL Veritabanı

  • Kritik dayanıklılık özelliklerine erişim de dahil olmak üzere güvenilirlik ve kullanılabilirliği en üst düzeye çıkarmak için İş Açısından Kritik hizmet katmanını kullanın.

  • İşlem ve depolama kaynaklarının iş yükü hacmi ve aktarım hızı gereksinimlerine göre bağımsız olarak seçilmesini kolaylaştırmak için sanal çekirdek tabanlı tüketim modelini kullanın.

    • İşlem ve depolama kaynağı gereksinimlerini bilgilendirmek için tanımlı kapasite modelinin uygulandığını emin olun.

  • İş Açısından Kritik veritabanı çoğaltmalarını aynı bölgede Kullanılabilirlik Alanları yaymak için Alanlar Arası Yedekli dağıtım modelini yapılandırın.

  • Tüm dağıtım bölgelerine okunabilir çoğaltmalar dağıtmak için Etkin Coğrafi Çoğaltma kullanın (en fazla dört).

  • İkincil bölgeye saydam yük devretme sağlamak için Otomatik Yük Devretme Gruplarını kullanın; okuma iyileştirmesi ve veritabanı yedekliliği için ek dağıtım bölgelerine çoğaltma sağlamak üzere coğrafi çoğaltma uygulanır.

    • Yalnızca iki dağıtım bölgesiyle sınırlı uygulama senaryolarında Otomatik Yük Devretme Gruplarının kullanımına öncelik verilmelidir.

  • Otomatik Yük Devretme Grubu içindeki birincil ve ikincil örneği etkileyen bir hata durumunda coğrafi olarak çoğaltılan örneklere yük devretme gerçekleştirmek için uygulama sistem durumu modeline hizalanmış uyarılara dayalı otomatik operasyonel tetikleyicileri göz önünde bulundurun.

Önemli

Dörtten fazla dağıtım bölgesi göz önünde bulunduran uygulamalarda, azure cosmos DB gibi çok bölgeli yazma teknolojilerini desteklemek için uygulama kapsamlı parçalama veya yeniden düzenleme konusunda önemli noktalara dikkat edilmelidir. Ancak, uygulama iş yükü senaryosunda bu mümkün değilse, tek bir coğrafyadaki bir bölgeyi coğrafi olarak çoğaltılmış bir örneği kapsayan birincil bir duruma yükseltmeniz ve daha eşit dağıtılmış okuma erişimine sahip olması önerilir.

  • Okuma performansını iyileştirmek üzere okuma sorguları için çoğaltma örneklerini sorgulamak üzere uygulamayı yapılandırın.

  • Güvenilirlik olaylarının algılanması için Azure SQL DB'de neredeyse gerçek zamanlı operasyonel içgörüler için Azure İzleyici ve Azure SQL Analytics'i kullanın.

  • Uygun şekilde boyutlandırılıp boyutlandırıldıklarını belirlemek üzere tüm veritabanlarının kullanımını değerlendirmek için Azure İzleyici'yi kullanın.

    • UYGUN veri platformu davranışını doğrulamak için CD işlem hatlarının temsili yük düzeyleri altında yük testi yapmayı göz önünde bulundurdığından emin olun.

  • veritabanı bileşenlerinin iş gereksinimlerine ve kaynak kullanımına göre sistem durumunu gözlemlemek için bir sistem durumu ölçümü hesaplayın; uygun durumlarda otomatik işlem eylemini yönlendirmek için izleme ve uyarılar kullanın.

    • Hizmet düşüşü oluştuğunda hızlı işlem yapılabilmesi için anahtar sorgu performansı ölçümlerinin dahil edildiğinden emin olun.

  • Sorgu Performansı İçgörüleri ve Microsoft tarafından sağlanan yaygın performans önerilerini kullanarak sorguları, tabloları ve veritabanlarını iyileştirin.

  • Azure SQL Veritabanı bağlantıyı etkileyen geçici hataları azaltmak için SDK kullanarak yeniden deneme mantığını uygulayın.

  • Bekleyen şifreleme için sunucu tarafı Saydam Veri Şifrelemesi (TDE) uygularken hizmet tarafından yönetilen anahtarların kullanımına öncelik verme.

    • Müşteri tarafından yönetilen anahtarlar veya istemci tarafı (AlwaysEncrypted) şifrelemesi gerekiyorsa, anahtarların yedeklemeler ve otomatik döndürme olanaklarıyla uygun şekilde dayanıklı olduğundan emin olun.

  • Ciddi yapılandırma hatalarından kurtarmak için belirli bir noktaya geri yüklemenin operasyonel bir playbook olarak kullanılmasını göz önünde bulundurun.

PostgreSQL için Azure Veritabanı

Sık Erişimli Katman Verileri için Önbelleğe Alma

Sık erişim katmanı veri senaryolarında okuma aktarım hızını önemli ölçüde artırarak ve uçtan uca istemci yanıt sürelerini iyileştirerek veri platformunu geliştirmek için bellek içi önbelleğe alma katmanı uygulanabilir.

Azure, veri platformu okuma erişimini soyutlayıp iyileştirmek için konumlandırılmış Redis için Azure Cache anahtar veri yapılarını önbelleğe almak için uygun özelliklere sahip çeşitli hizmetler sunar. Bu nedenle bu bölüm, ek okuma performansının ve veri erişimi dayanıklılığının gerekli olduğu senaryolarda en uygun Redis için Azure Cache kullanımına odaklanacaktır.

Tasarım Konusunda Dikkat Edilmesi Gerekenler

  • Önbelleğe alma katmanı ek veri erişimi dayanıklılığı sağlar, çünkü temel alınan veri teknolojilerini etkileyen bir kesinti olsa bile, bir uygulama veri anlık görüntüsüne önbelleğe alma katmanı üzerinden erişmeye devam edilebilir.

  • Bazı iş yükü senaryolarında, bellek içi önbelleğe alma uygulama platformunun kendi içinde uygulanabilir.

Redis için Azure Önbelleği

  • Redis cache, açık kaynak bir NoSQL bellek içi depolama sistemidir.

  • Kurumsal ve Kurumsal Flash katmanları, coğrafi çoğaltma aracılığıyla bir bölge içindeki ve farklı Azure bölgelerindeki Kullanılabilirlik Alanları etkin-etkin bir yapılandırmada dağıtılabilir.

    • Tüm Önbellek örnekleri için etkin coğrafi çoğaltmanın etkinleştirildiği her bölgede en az üç Azure bölgesi ve üç veya daha fazla Kullanılabilirlik Alanları dağıtıldığında Redis için Azure Cache, bir bölgesel önbellek uç noktasına bağlantı için %99,999 SLA sağlar.
    • Tek bir Azure bölgesinde üç Kullanılabilirlik Alanları dağıtıldığında %99,99 bağlantı SLA'sı sağlanır.

  • Enterprise Flash katmanı, RAM ve flash geçici olmayan bellek depolamasının bir bileşiminde çalışır ve bu küçük bir performans cezası sunarken, kümeleme ile 13 TB'a kadar çok büyük önbellek boyutlarına da olanak tanır.

  • Coğrafi çoğaltma ile, önbellek örnekleriyle ilişkili doğrudan maliyetlere ek olarak bölgeler arasında veri aktarımı ücretleri de geçerli olur.

  • Zamanlanmış Güncelleştirmeler özelliği, temel alınan VM işletim sistemine uygulanan Azure güncelleştirmelerini veya güncelleştirmelerini içermez.

  • Veriler yeni örneklere geçirilirken ölçeği genişletme işlemi sırasında CPU kullanımında bir artış olacaktır.

Tasarım Önerileri

  • Okuma aktarım hızını artırmak ve yanıt sürelerini iyileştirmek için "sık erişimli" veri senaryoları için iyileştirilmiş bir önbelleğe alma katmanını göz önünde bulundurun.

  • Kaçak veri büyümesini önlemek için önbellek süre sonu ve temizlik için uygun ilkeleri uygulayın.

    • Yedekleme verileri değiştiğinde önbellek öğelerinin süresi dolmayı göz önünde bulundurun.

Redis için Azure Önbelleği

  • Güvenilirliği ve performansı en üst düzeye çıkarmak için Premium veya Kurumsal SKU'yu kullanın.

    • Son derece büyük veri hacimlerine sahip senaryolar için Enterprise Flash katmanı dikkate alınmalıdır.
    • Yalnızca pasif coğrafi çoğaltmanın gerekli olduğu senaryolar için Premium katmanı da göz önünde bulundurulabilir.

  • Tüm kabul edilen dağıtım bölgelerinde etkin bir yapılandırmada coğrafi çoğaltma kullanarak çoğaltma örneklerini dağıtın.

  • Çoğaltma örneklerinin her bir Azure bölgesi içinde Kullanılabilirlik Alanları dağıtıldığından emin olun.

  • Redis için Azure Cache değerlendirmek için Azure İzleyici'yi kullanın.

    • bölgesel önbellek bileşenlerinin iş gereksinimlerine ve kaynak kullanımına göre sistem durumunu gözlemlemek için sistem durumu puanını hesaplayın.
    • Önbelleğin ölçeklendirilmesi gereken içgörüler için yüksek CPU, yüksek bellek kullanımı, yüksek sunucu yükü ve çıkarılan anahtarlar gibi önemli ölçümleri gözlemleyin ve uyarın.

  • Yeniden deneme mantığı, zaman aşımları uygulayarak ve Redis bağlantı çoklayıcısının tek bir uygulamasını kullanarak bağlantı dayanıklılığını iyileştirin.

  • Redis Server güncelleştirmelerinin önbelleğe uygulandığı gün ve saatleri belirlemek için zamanlanmış güncelleştirmeleri yapılandırın.

Analitik Senaryolar

Görev açısından kritik uygulamaların analitik senaryoları, kapsamış veri akışlarından ek değer elde etmek için bir araç olarak değerlendirmesi giderek yaygın hale gelmektedir. Bu nedenle uygulama ve işletimsel (AIOps) analiz senaryoları, son derece güvenilir veri platformunun önemli bir yönünü oluşturur.

Analitik ve işlemsel iş yükleri, kendi bağlamlarında kabul edilebilir performans için farklı veri platformu özellikleri ve iyileştirmeleri gerektirir.

Açıklama Analitik İşlem Tabanlı
Kullanım Örneği Çok büyük hacimli verileri analiz etme ("büyük veri") Çok büyük hacimli bireysel işlemleri işleme
Şunun için iyileştirildi: Birçok kayıt üzerinde sorguları ve toplamaları okuma Birkaç kayıt üzerinde neredeyse gerçek zamanlı Oluşturma/Okuma/Güncelleştirme/Silme (CRUD) sorguları
Temel Özellikler - Kayıt veri kaynaklarından birleştirme
- Sütun tabanlı depolama
- Dağıtılmış depolama
- Paralel işleme
-Normalleştirilmemiş
- Düşük eşzamanlılık okuma ve yazma işlemleri
- Sıkıştırma ile depolama birimi için iyileştirme		 - Uygulama için kayıt veri kaynağı
- Satır Tabanlı Depolama
- Bitişik depolama
- Simetrik işleme
-Normalleştirilmiş
- Yüksek eşzamanlılık okuma ve yazma işlemleri, dizin güncelleştirmeleri
- Bellek içi depolama ile hızlı veri erişimi için iyileştirme

Azure Synapse, büyük veri analizini kolaylaştırmak için Azure Cosmos DB gibi Azure hizmetleriyle yerleşik tümleştirmeyi kullanarak ilişkisel ve ilişkisel olmayan verileri Spark teknolojileriyle bir araya getiren kurumsal bir analiz platformu sağlar. Bu nedenle bu bölümdeki tasarım konuları ve önerileri analiz senaryoları için en uygun Azure Synapse ve Azure Cosmos DB kullanımına odaklanacaktır.

Tasarım Konusunda Dikkat Edilmesi Gerekenler

  • Geleneksel olarak, büyük ölçekli analitik senaryolar, verileri sonraki analiz sorguları için iyileştirilmiş ayrı bir veri platformuna ayıklayarak kolaylaştırılır.
    • Verileri ayıklamak için kullanılan Ayıklama, Dönüştürme ve Yükleme (ETL) işlem hatları aktarım hızını tüketir ve işlem iş yükü performansını etkiler.
    • Aktarım hızını ve performans etkilerini azaltmak için ETL işlem hatlarının seyrek çalıştırılması analiz verilerinin daha az güncel olmasıyla sonuçlanır.
    • Veri dönüşümleri daha karmaşık hale geldikçe ETL işlem hattı geliştirme ve bakım ek yükü artar.
      • Örneğin, kaynak veriler sık sık değiştiriliyor veya siliniyorsa ETL işlem hatlarının analitik sorgular için hedef verilerdeki değişiklikleri ekli/sürümlü bir yaklaşım, döküm ve yeniden yükleme ya da analiz verilerindeki yerinde değişiklikleri hesaba katması gerekir. Bu yaklaşımların her biri, dizinin yeniden oluşturulması veya güncelleştirilmesi gibi türev etkilere sahip olacaktır.

Azure Cosmos DB

  • Azure Cosmos DB işlem verileri üzerinde çalıştırılan analitik sorgular genellikle büyük hacimli veriler üzerinde bölümler arasında toplanır ve bu da işlemsel iş yüklerinin performansını etkileyerek önemli miktarda İstek Birimi (RU) aktarım hızı kullanır.

  • Azure Cosmos DB Analiz Deposu, Azure Cosmos DB işlem iş yüklerini etkilemeden Azure Synapse'ten Azure Cosmos DB verileri üzerinde büyük ölçekli analizlere olanak tanıyan, şemalı, tamamen yalıtılmış bir sütun odaklı veri deposu sağlar.

    • Bir Azure Cosmos DB Kapsayıcısı Analiz Deposu olarak etkinleştirildiğinde kapsayıcıdaki işletimsel verilerden dahili olarak yeni bir sütun deposu oluşturulur. Bu sütun deposu, kapsayıcının satır odaklı işlem deposundan ayrı olarak kalıcıdır.
    • İşletimsel verilerde oluşturma, Güncelleştirme ve Silme işlemleri analiz deposuyla otomatik olarak eşitlenir, bu nedenle değişiklik akışı veya ETL işleme gerekmez.
    • İşlemden analiz deposuna veri eşitleme, Kapsayıcı veya Veritabanında sağlanan aktarım hızı İstek Birimlerini (RU) kullanmaz. İşlem iş yükleri üzerinde performans etkisi yoktur. Analiz Deposu, Bir Azure Cosmos DB Veritabanı veya Kapsayıcısı üzerinde ek RU'ların ayrılmasını gerektirmez.
    • Otomatik Eşitleme, işletimsel veri değişikliklerinin Analiz Deposu ile otomatik olarak eşitlendiği işlemdir. Otomatik Eşitleme gecikme süresi genellikle iki (2) dakikadan kısadır.
      • Paylaşılan aktarım hızına ve çok sayıda Kapsayıcıya sahip bir Veritabanı için Otomatik Eşitleme gecikme süresi beş (5) dakikaya kadar sürebilir.
      • Otomatik Eşitleme tamamlanır tamamlanmaz Azure Synapse'ten en son veriler sorgulanabilir.
    • Analiz Deposu depolama alanı, veri hacmi ve okuma ve yazma işlemlerinin sayısı için ücretlendirilen tüketim tabanlı bir fiyatlandırma modeli kullanır. Analiz deposu fiyatlandırması, işlemsel mağaza fiyatlandırmasından ayrıdır.

  • Azure Synapse Link kullanılarak Azure Cosmos DB Analiz Deposu doğrudan Azure Synapse'ten sorgulanabilir. Bu, Synapse'ten ETL olmayan Karma İşlem-Analitik İşleme 'yi (HTAP) etkinleştirir, böylece Azure Cosmos DB verileri Synapse'ten gelen diğer analiz iş yükleriyle birlikte neredeyse gerçek zamanlı olarak sorgulanabilir.

  • Azure Cosmos DB Analiz Deposu varsayılan olarak bölümlenmez.

    • Belirli sorgu senaryolarında, sorgu koşullarında sık kullanılan anahtarları kullanarak Analiz Deposu verilerini bölümleyerek performans artar.
    • Bölümleme, Azure Synapse'te Synapse Link kullanarak Spark not defteri çalıştıran ve Azure Cosmos DB Analiz Deposu'ndaki verileri yükleyen ve Synapse çalışma alanının birincil depolama hesabındaki Synapse bölümlenmiş deposuna yazan bir iş tarafından tetiklenir.

  • Azure Synapse Analytics SQL Sunucusuz havuzları, otomatik olarak güncelleştirilen görünümler veya komutlar aracılığıyla SELECT / OPENROWSET Analiz Deposu'nu sorgulayabilir.

  • Azure Synapse Analytics Spark havuzları, otomatik olarak güncelleştirilen Spark tabloları veya komutu aracılığıyla Analiz Deposu'nı spark.read sorgulayabilir.

  • Sağlanan Azure Synapse SQL havuzu kaynaklarının kullanılabilmesi için veriler Azure Cosmos DB Analiz Deposu'ndan Spark kullanılarak ayrılmış bir Synapse SQL havuzuna da kopyalanabilir.

  • Azure Cosmos DB Analiz Deposu verileri Azure Synapse Spark ile sorgulanabilir.

Azure Cosmos DB Analitik Sütun Deposu

Azure Synapse

  • Azure Synapse, günlük ve zaman serisi analizi için SQL veri ambarı, Spark büyük veri ve Veri Gezgini gibi analiz özelliklerini bir araya getirir.

    • Azure Synapse, Azure Depolama gibi diğer hizmetlere bağlantıları tanımlamak için bağlı hizmetleri kullanır.
    • Desteklenen kaynaklardan Kopyalama etkinliği aracılığıyla Synapse Analytics'e veri alınabiliyor. Bu, Synapse'te kaynak veri depoyu etkilemeden veri analizine izin verir, ancak veri aktarımı nedeniyle zaman, maliyet ve gecikme süresi ek yükü ekler.
    • Veriler, desteklenen dış depolarda yerinde sorgulanabilir ve veri alımı ve hareket yükünden kaçınılabilir. Data Lake 2. Nesil ile Azure Depolama Synapse için desteklenen bir depodur ve Log Analytics'in dışarı aktarılmış verileri Synapse Spark aracılığıyla sorgulanabilir.

  • Azure Synapse Studio , alma ve sorgulama görevlerini birleştirir.

    • Azure Cosmos DB Analiz Deposu verileri ve Log Analytics Dışarı Aktarma verileri dahil olmak üzere kaynak veriler, iş zekası ve diğer toplu analitik kullanım örneklerini desteklemek için sorgulanır ve işlenir.

Azure Synapse Analytics

Tasarım Önerileri

  • İşlem performansını korumak için analiz iş yüklerinin işlem uygulaması iş yüklerini etkilemediğinden emin olun.

Application Analytics

AIOps ve Operasyonel Analiz

  • Kaynaklardan işletimsel verilerin gönderildiği her kaynak Azure Depolama hesabı için bağlı hizmetler ve veri kümeleri içeren tek bir Azure Synapse çalışma alanı oluşturun.

  • Ayrılmış bir Azure Depolama hesabı oluşturun ve Synapse çalışma alanı kataloğu verilerini ve meta verilerini depolamak için bunu çalışma alanı birincil depolama hesabı olarak kullanın. Azure Data Lake 2. Nesil'i etkinleştirmek için hiyerarşik ad alanıyla yapılandırın.

    • Kaynak analiz verileri ile Synapse çalışma alanı verileri ve meta verileri arasında ayrım yapın.
      • İşletimsel verilerin gönderildiği bölgesel veya genel Azure Depolama hesaplarından birini kullanmayın.

Sonraki adım

Ağ konusunda dikkat edilmesi gereken noktaları gözden geçirin.

Ağ ve bağlantı