Parçalama düzeni

Veri deposunu bir dizi yatay bölüme veya parçaya ayırın. Bu düzen, büyük hacimli verileri depolarken ve bu verilere erişirken ölçeklenebilirliği artırabilir.

Bağlam ve sorun

Tek bir sunucu tarafından barındırılan bir veri deposu aşağıdaki sınırlamalara tabi olabilir:

• Depolama alanı. Büyük ölçekli bir bulut uygulaması için veri deposunun zaman içinde önemli ölçüde artırabilen çok büyük bir veri hacmi içermesi beklenir. Bir sunucu genellikle yalnızca sınırlı miktarda disk depolama alanı sağlar, ancak var olan diskleri büyük olanlarla değiştirebilir veya veri hacimleri büyüdükçe makineye daha fazla disk ekleyebilirsiniz. Bununla birlikte, sistem belirli bir sunucu üzerindeki depolama kapasitesini kolayca artırmanın mümkün olmadığı bir sınıra sonunda ulaşır.

• Bilgi işlem kaynakları. Bir bulut uygulamasının, her biri veri deposundan bilgi alan sorgular çalıştıran çok sayıda eşzamanlı kullanıcıyı desteklemesi gerekir. Veri depoyu barındıran tek bir sunucu bu yükü desteklemek için gerekli bilgi işlem gücünü sağlayamayabilir ve bu da kullanıcılar için uzun yanıt sürelerine ve veri depolamaya ve veri almaya çalışan uygulamalar zaman aşımına uğramaya çalışırken sık karşılaşılan hatalara neden olabilir. Bellek eklemek veya işlemcileri yükseltmek mümkün olabilir, ancak işlem kaynaklarını daha fazla artırmak mümkün olmadığında sistem bir sınıra ulaşacaktır.

• Ağ bant genişliği. Nihai olarak, tek bir sunucu üzerinde çalışan bir veri deposunun performansı, sunucunun istekleri alabildiği ve yanıtları gönderebildiği hıza göre yönetilir. Trafik hacminin sunucuya bağlanmak için kullanılan ağın kapasitesini aşması ve başarısız isteklerle sonuçlanması mümkündür.

• Coğrafya. Belirli kullanıcılar tarafından oluşturulan verilerin yasal, uyumluluk veya performans amaçlı kullanıcılarla ya da veri erişimi gecikmesini azaltmak amacıyla aynı bölgede depolanması gerekebilir. Kullanıcılar farklı ülke veya bölgeler arasında dağılmışsa, uygulamaya ait tüm verilerin tek bir veri deposunda depolanması mümkün olmayabilir.

Daha fazla disk kapasitesi, işleme gücü, bellek ve ağ bağlantısı ekleyerek dikey yönde ölçeklendirmek, bu sınırlamalardan bazılarının etkilerini erteleyebilir ancak yalnızca geçici bir çözüm olabilir. Çok sayıda kullanıcıyı ve yüksek hacimli verileri destekleyebilen ticari bir bulut uygulaması neredeyse süresiz olarak ölçekleyebilmelidir, bu nedenle ölçeklendirmenin mutlaka en iyi çözüm olması gerekmez.

Çözüm

Veri deposunu yatay bölümlere veya parçalara ayırın. Her parça aynı şemaya sahiptir ancak kendi ayrı veri alt kümesini tutar. Parça, depolama düğümü olarak görev yapan bir sunucu üzerinde çalışan, kendi çapında bir veri deposudur (farklı türlerdeki birçok varlığın verilerini içerebilir).

Bu düzen aşağıdaki avantajlara sahiptir:

• Ek depolama düğümleri üzerinde çalışan daha fazla parça ekleyerek sistemin ölçeğini genişletebilirsiniz.

• Bir sistem her depolama düğümü için özelleştirilmiş ve pahalı bilgisayarlar yerine piyasada satılan donanımları kullanabilir.

• Parçalar arasındaki iş yükünü dengeleyerek çekişmeyi azaltabilir ve performansı artırabilirsiniz.

• Bulutta parçalar, verilere erişecek kullanıcıların fiziksel olarak yakınına konumlandırılabilir.

Bir veri deposunu parçalara bölerken her bir parçaya hangi verilerin yerleştirilmesi gerektiğine karar verin. Bir parça genellikle verilerin bir veya daha fazla özniteliği ile belirlenmiş belirli bir aralığa denk düşen öğeler içerir. Bu öznitelikler parça anahtarını (bazı durumlarda bölüm anahtarı olarak adlandırılır) oluşturur. Parça anahtarı statik olmalıdır. Değişebilecek verileri temel almamalıdır.

Parçalama işlemi, verileri fiziksel olarak düzenler. Bir uygulama veri depolayıp aldığında, parçala mantığı uygulamayı uygun parçaya yönlendirir. Bu parçalama mantığı, uygulamadaki veri erişim kodunun bir parçası olarak uygulanabilir veya parçalamayı saydam bir şekilde destekliyorsa veri depolama sistemi tarafından uygulanabilir.

Parçalama mantığında verilerin fiziksel konumunun soyutlanması, parçaların hangi verileri içerdiğine dair yüksek düzeyde denetim sağlar. Ayrıca, parçalardaki verilerin daha sonra yeniden dağıtılması gerekirse (örneğin, parçalar dengesiz hale gelirse), verilerin bir uygulamanın iş mantığı üzerinde yeniden çalışmadan parçalar arasında geçiş yapmasına olanak tanır. Denge, alınan her veri öğesinin konumunu belirlerken gereken ek veri erişimi yüküdür.

En iyi performans ve ölçeklenebilirliği sağlamak için verileri uygulamanın gerçekleştirdiği sorgu türlerine uygun bir şekilde bölmek önemlidir. Birçok durumda, parçalama düzeninin her sorguya ait gereksinimlerle tam olarak eşleşme olasılığı düşüktür. Örneğin, çok kiracılı bir sistemde bir uygulamanın kiracı kimliğini kullanarak kiracı verilerini alması gerekebilir, ancak kiracının adı veya konumu gibi diğer bazı özniteliklere göre de bu verileri araması gerekebilir. Bu durumların üstesinden gelmek için, en yaygın olarak gerekleştirilen sorguları destekleyen bir parça anahtarı ile parçalama stratejisi uygulayın.

Sorgular öznitelik değerlerinin bir birleşimini kulanarak düzenli aralıklarla veri alıyorsa, öznitelikleri birbirine bağlayarak bileşik bir parça anahtarı tanımlayabilirsiniz. Alternatif olarak, parça anahtarı kapsamında olmayan özniteliklere göre verileri hızlı aramayı sağlayan Dizin Tablosu gibi bir düzen kullanın.

Parçalama stratejileri

Parça anahtarı seçerken ve parçalar arasında verilerin nasıl dağıtılacağına karar verirken yaygın olarak üç strateji kullanılır. Parçalar ile bunları barındıran sunucular arasında bire bir yazışma olması gerekmez; tek bir sunucu birden çok parça barındırabilir. Stratejiler şunlardır:

Arama stratejisi. Bu stratejide parçalama mantığı, parça anahtarını kullanarak bir veri isteğini bu verileri içeren parçaya yönlendiren bir eşleme uygular. Çok kiracılı bir uygulamada bir kiracının tüm verileri, parça anahtarı olarak kiracı kimliği kullanılarak bir parçada birlikte depolanabilir. Birden çok kiracı aynı parçayı paylaşabilir, ancak tek bir kiracının verileri birden fazla parça arasında yayılmaz. Şekilde, kiracı kimliklerine göre parçalama kiracı verileri gösterilmektedir.

Parça anahtarı değeri ile verilerin bulunduğu fiziksel depolama alanı arasındaki eşleme, her parça anahtarı değerinin fiziksel bir bölüme eşlendiği fiziksel parçaları temel alabilir. Alternatif olarak, parçaları yeniden dengelemek için daha esnek bir teknik, parça anahtarları değerlerinin aynı sayıda sanal parçayla eşlendiği ve daha az fiziksel bölümle eşlendiği sanal bölümlemedir. Bu yaklaşımda bir uygulama, bir sanal parçaya başvuran bir parça anahtarı değeri kullanarak verileri bulur ve sistem sanal parçaları fiziksel bölümlere saydam bir şekilde eşler. Bir sanal parça ile fiziksel bölüm arasındaki eşleme, uygulama kodunun farklı bir parça anahtarı değerleri kümesi kullanacak şekilde değiştirilmesi gerekmeden değişebilir.

Aralık stratejisi. Bu strateji, ilgili öğeleri aynı parçada gruplandırır ve parça anahtarına göre sıralar; parça anahtarları sıralı olur. Aralık sorguları (belirli bir aralığa denk gelen bir parça anahtarı için bir veri öğeleri kümesi döndüren sorgular) kullanarak sıklıkla öğe kümeleri alan uygulamalar için yararlıdır. Örneğin, bir uygulama belirli bir ayda verilen tüm siparişleri düzenli olarak bulması gerekiyorsa, bir aya ait tüm siparişlerin aynı parçaya tarih ve saat sırasıyla depolanması durumunda bu veriler daha hızlı bir şekilde alınabilir. Her sipariş farklı bir parçada depolanmışsa, çok sayıda nokta sorgu (tek bir veri öğesi döndüren sorgular) gerçekleştirilerek siparişlerin tek tek getirilmesi gerekir. Aşağıdaki şekilde, sıralı veri kümelerinin (aralıklar) parçalarda depolanması gösterilmektedir.

Bu örnekte parça anahtarı, en önemli unsur olarak siparişi, ardından sipariş günü ve saatini içeren bir bileşik anahtardır. Yeni siparişler oluşturulup bir parçaya eklendiğinde sipariş verileri doğal olarak sıralanır. Bazı veri depoları, parçayı tanımlayan bir bölüm anahtarı öğesi ve parçadaki öğeyi benzersiz şekilde tanımlayan bir satır anahtarı içeren iki kısımlı parça anahtarlarını destekler. Veriler genellikle parçada satır anahtarı sırasıyla tutulur. Aralık sorgularına tabi olup birlikte gruplanması gereken öğeler, bölüm anahtarı için aynı ancak satır anahtarı için benzersiz bir değere sahip olan parça anahtarını kullanabilir.

Karma stratejisi. Bu stratejinin amacı etkin nokta (orantısız miktarda yük alan parçalar) olasılığını azaltmaktır. Verileri her parçanın boyutu ile her parçanın karşılaşacağı ortalama yük arasında bir denge kuracak şekilde parçalar arasında dağıtır. Parçalama mantığı bir veya daha fazla veri özniteliğinin karmasına göre bir öğeyi depolayacak şekilde parçayı hesaplar. Seçilen karma işlevi, muhtemelen hesaplamaya rastgele öğeler ekleyerek verileri parçalar arasında eşit olarak dağıtmalıdır. Aşağıdaki şekilde, bir kiracı kimlikleri karmasına göre parçalama kiracı verileri gösterilmektedir.

Karma stratejisinin diğer parçalama stratejilerine göre avantajını anlamak için, yeni kiracıları sırayla kaydeden çok kiracılı bir uygulamanın kiracıları veri deposundaki parçalara nasıl atayabileceğini düşünün. Aralık stratejisini kullanırken, 1 ile n arasındaki kiracı verilerinin tümü A parçasında, n+1 kiracı verilerinin tümü B parçasında vb. depolanır. En son kaydedilen kiracılar aynı zamanda en etkin kiracılar değilse, veri etkinliklerinin çoğunluğu az sayıda parça içinde oluşur ve etkin noktalar oluşur. Buna karşılık, Karma stratejisi kiracıları kendi kiracı kimliklerinin karmasına göre parçalara ayırır. Diğer bir deyişle, sıralı kiracılar büyük olasılıkla farklı parçalara ayrılır ve yük bunlar arasında dağıtılır. Yukarıdaki şekilde 55. ve 56. kiracılar için bu durum gösterilmiştir.

Üç parçalama stratejisi aşağıdaki avantajları ve dikkat edilmesi gereken noktaları içerir:

• Arama. Parçaların yapılandırılma ve kullanılma şekli üzerinde daha fazla denetim sağlar. İş yükünü dengelemek üzere yeni fiziksel bölümler eklenebildiği için sanal parçaların kullanılması, veriler yeniden dengelenirken oluşan etkiyi azaltır. Bir sanal parça ile parçayı uygulayan fiziksel bölümler arasındaki eşleme, veri depolayıp almak için parça anahtarı kullanan uygulama kodunu etkilemeden değiştirilebilir. Parça konumlarını aramak ek bir yük oluşturabilir.

• Aralık. Bunun uygulanması kolaydır ve genellikle tek bir işlemde tek bir parçadan birden fazla öğe getirebildiği için aralık sorgularıyla iyi çalışır. Bu strateji daha kolay veri yönetimi sunar. Örneğin, aynı bölgedeki kullanıcılar aynı parça içindeyse, yerel yüke ve talep desenine göre her saat diliminde güncelleştirmeler zamanlanabilir. Ancak, bu strateji parçalar arasında en iyi dengelemeyi sağlamaz. Parçaların yeniden dengelenmesi zordur ve etkinliğin büyük bölümü bitişik parça anahtarlarına yönelikse eşit olmayan yük sorununu çözemeyebilir.

• Karma. Bu strateji daha eşit veri ve yük dağılımı olasılığını artırır. İstek, karma işlevi kullanılarak doğrudan yönlendirilebilir. Bir eşleme yapmak gerekmez. Karma hesaplamanın ek yük oluşturabileceğini unutmayın. Ayrıca, parçaların yeniden dengelenmesi zordur.

Birçok yaygın parçalama sistemi yukarıda açıklanan yaklaşımlardan birini uygular, ancak uygulamalarınızın iş gereksinimlerini ve veri kullanımı düzenlerini de dikkate almanız gerekir. Örneğin, çok kiracılı bir uygulamada:

• Verileri iş yüküne göre parçalayabilirsiniz. Ayrı parçalardaki yüksek oranda geçici kiracılar için verileri ayırabilirsiniz. Sonuç olarak diğer kiracılar için veri erişiminin hızı iyileştirilebilir.

• Verileri kiracıların konumuna göre parçalayabilirsiniz. Diğer bölgelerdeki kiracıların verileri kendi iş saatleri sırasında çevrimiçi ve erişilebilir durumda kalırken belirli bir coğrafi bölgedeki kiracıların verilerini o bölgenin yoğun olmayan saatlerinde yedekleme ve bakım için çevrimdışı yapabilirsiniz.

• Yüksek değerli kiracılara kendi özel, yüksek performanslı, hafif yüklenen parçaları atanabilirken, düşük değerli kiracıların daha yoğun paketlenmiş, meşgul parçaları paylaşması beklenebilir.

• Yüksek derecede veri yalıtımı ve gizliliğe gereksinim duyan kiracıların verileri tamamen ayrı bir sunucuda depolanabilir.

Ölçeklendirme ve veri taşıma işlemleri

Parçalama stratejilerinin her biri ölçek azaltma, ölçeği genişletme, veri taşıma ve durum koruma amacıyla farklı özellikler ve karmaşıklık düzeyleri uygular.

Arama stratejisi, kullanıcı düzeyinde çevrimiçi veya çevrimdışı olarak ölçeklendirme ve veri taşıma işlemlerinin gerçekleştirilmesine izin verir. Kullanıcı etkinliğinin bir kısmını veya tamamını (belki de yoğun olmayan dönemlerde) askıya alma, verileri yeni sanal bölüme veya fiziksel parçaya taşıma, eşlemeleri değiştirme, bu verileri tutan tüm önbellekleri geçersiz kılma ya da yenileme ve sonra kullanıcı etkinliğinin devam etmesine izin verme tekniği kullanılır. Bu işlem türü genellikle merkezi olarak yönetilebilir. Arama stratejisi, durumun yüksek oranda önbelleğe alınabilir ve çoğaltmaya uygun olmasını gerektirir.

Aralık stratejisi, ölçeklendirme ve veri taşıma işlemlerine bazı sınırlamalar getirir. Verilerin parçalar arasında bölünmesi ve birleştirilmesi gerektiğinden, bu işlemlerin genellikle veri deposu kısmen ya da tamamen çevrimdışı olduğunda gerçekleştirilmesi gerekir. Etkinliğin büyük bölümü bitişik parça anahtarlarına veya aynı aralıktaki veri tanımlayıcılara yönelikse, parçaları yeniden dengelemek üzere verilerin taşınması eşit olmayan yük sorununu çözemeyebilir. Aralık stratejisi ayrıca aralıkları fiziksel bölümlere eşlemek için bazı durumların sürdürülmesini gerektirebilir.

Bölüm anahtarları parça anahtarlarının veya veri tanımlayıcıların karmaları olduğundan karma stratejisi, ölçeklendirme ve veri taşıma işlemlerini daha karmaşık hale getirir. Her parçanın yeni konumu karma işlevinden belirlenmeli veya işlev doğru eşlemeleri sağlayacak şekilde değiştirilmelidir. Ancak, Karma stratejisi durumun sürdürülmesini gerektirmez.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:

• Parçalama, dikey bölümleme ve işlevsel bölümleme gibi diğer bölümleme biçimlerini tamamlayıcı niteliktedir. Örneğin, tek bir parça dikey olarak bölümlenmiş varlıklar içerebilir ve bir işlevsel bölüm, birden çok parça halinde uygulanabilir. Bölümleme hakkında daha fazla bilgi için bkz. Veri Bölümleme Kılavuzu.

• Parçaları tümü benzer bir G/Ç hacmini işleyecek şekilde dengede tutun. Veriler eklenip silindikçe parçaların eşit bir dağılımı garanti edecek ve etkin nokta olasılığını azaltacak şekilde düzenli aralıklarla yeniden dengelenmesi gerekir. Yeniden dengeleme, pahalı bir işlem olabilir. Yeniden dengeleme gereksinimini azaltmak için, her parçanın beklenen değişiklik hacmini işleyecek yeterlilikte boş alan içerdiğinden emin olarak büyümeyi planlayın. Ayrıca, gerekli hale gelirse parçaları hızlıca yeniden dengelemek için kullanabileceğiniz stratejiler ve betikler geliştirmeniz gerekir.

• Parça anahtarı için kararlı veriler kullanın. Parça anahtarı değişirse, karşılık gelen veri öğesinin parçalar arasında taşınması gerekebilir ve güncelleştirme işlemleri tarafından gerçekleştirilen iş miktarını artırabilir. Bu nedenle, parça anahtarını geçici olabilecek bilgilere dayandırmamaya özen gösterin. Bunun yerine, sabit olan veya doğal olarak bir anahtar oluşturan öznitelikleri arayın.

• Parça anahtarlarının benzersiz olduğundan emin olun. Örneğin, parça anahtarı olarak otomatik artan alanlar kullanmaktan kaçının. Bazı sistemlerde otomatik olarak basılan alanlar parçalar arasında eşgüdümlü olamaz ve büyük olasılıkla farklı parçalardaki öğelerin aynı parça anahtarına sahip olmasına neden olur.

  Parça anahtarı olmayan diğer alanlardaki otomatik artırılan değerler de sorunlara yol açabilir. Örneğin, benzersiz kimlikler oluşturmak için otomatik artırılan alanlar kullanırsanız, farklı parçalarda bulunan iki farklı öğeye aynı kimlik atanabilir.

• Verilere yönelik her olası sorgunun gereksinimleriyle eşleşen bir parça anahtarı tasarlamak mümkün olmayabilir. En sık gerçekleştirilen sorguları desteklemek üzere verileri parçalayın ve gerekirse, parça anahtarına ait olmayan öznitelikleri temel alan ölçütleri kullanarak veri alan sorguları desteklemek amacıyla ikincil dizin tabloları oluşturun. Daha fazla bilgi için bkz. Dizin Tablosu düzeni.

• Yalnızca tek bir parçaya erişimi olan sorgular, birden fazla parçadan veri alan sorgulardan daha verimlidir; bu nedenle, uygulamaların farklı parçalarda tutulan verileri birleştiren çok sayıda sorgu gerçekleştirmesi ile sonuçlanan bir parçalama sistemi uygulamaktan kaçının. Tek bir parçanın birden fazla varlık türü için veri içerebildiğini unutmayın. Bir uygulamanın gerçekleştirdiği ayrı okuma işlemlerinin sayısını azaltmak üzere aynı parçada yaygın olarak sorgulanan ilgili varlıkları (örneğin, müşterilerin ayrıntıları ve verdikleri siparişler) bir arada tutmak için verilerinizi normal durumdan çıkarmayı düşünün.

  Bir parça içindeki varlık başka bir parça içinde depolanmış varlığa başvuruyorsa, ikinci varlığın parça anahtarını birinci varlığın şemasına dahil edin. Bunun yapılması, parçalar arasında ilgili verilere başvuran sorguların performansını artırmaya yardımcı olabilir.

• Bir uygulamanın birden çok parçadan veri alan sorgular gerçekleştirmesi gerekiyorsa, bu verileri paralel görevler kullanarak getirmek mümkün olabilir. Birden fazla parçadan verilerin paralel olarak alındıktan sonra tek bir sonuçta toplandığı yaygın sorgular bunun örneklerindendir. Ancak, bu yaklaşım bir çözümün veri erişim mantığına kaçınılmaz olarak biraz karmaşıklık ekler.

• Küçük parçalar yük dengeleme için daha fazla fırsat sunduğundan, birçok uygulama için çok sayıda küçük parça oluşturmak az sayıda büyük parçaya sahip olmaktan daha verimlidir. Bunun yapılması, parçaları bir fiziksel konumdan diğerine geçirmeyi öngörüyorsanız da yararlı olabilir. Küçük bir parça, büyük bir parçadan daha hızlı taşınabilir.

• Her parça depolama düğümünün kullanabildiği kaynakların veri boyutu ve aktarım hızı açılarından ölçeklenebilirlik gereksinimlerini karşılamak için yeterli olduğundan emin olun. Daha fazla bilgi için Veri Bölümleme Kılavuzu'ndaki "Bölümleri Ölçeklenebilirlik için Tasarlama" bölümüne bakın.

• Başvuru verilerini tüm parçalara çoğaltmayı düşünün. Bir parçadan veri alan bir işlem aynı sorgu kapsamında statik veya yavaş hareket eden verilere de başvuruyorsa, bu verileri parçaya ekleyin. Bundan sonra uygulama, ayrı bir veri deposuna ilave bir gidiş dönüş yapmak zorunda kalmadan sorgunun tüm verilerini kolayca getirebilir.

  Birden fazla parçada tutulan başvuru verileri değişirse, sistem bu değişiklikleri tüm parçalarda eşitlemelidir. Bu eşitleme gerçekleşirken sistem bir miktar tutarsızlık yaşayabilir. Bunu yaparsanız uygulamalarınızı bu tutarsızlığı giderecek şekilde tasarlamanız gerekir.

• Parçalar arasında bilgi tutarlılığının sürdürülmesi zor olabilir; bu nedenle, birden fazla parçadaki verileri etkileyen işlemleri en aza indirmeniz gerekir. Bir uygulamanın parçalar arasındaki verileri değiştirmesi gerekirse, tam veri tutarlılığının gerçekten gerekli olup olmadığını değerlendirin. Bunun yerine, bulutta yaygın bir yaklaşım son tutarlılığı gerçekleştirmektir. Her bölümdeki veriler ayrı ayrı güncelleştirilir ve uygulama mantığı tüm güncelleştirmelerin başarıyla tamamlandığından emin olmanın yanı sıra sonunda tutarlı bir işlem çalışırken verileri sorgulamaktan kaynaklanabilecek tutarsızlıkları gidermenin sorumluluğunu üstlenmelidir. Son tutarlılık uygulama hakkında daha fazla bilgi için bkz. Veri tutarlılığı Temel Bilgileri.

• Çok sayıda parçayı yapılandırmak ve yönetmek zor olabilir. İzleme, yedekleme, tutarlılık denetimi ve günlüğe kaydetme veya denetim gibi görevler, muhtemelen birden fazla konumda tutulan birden çok parça ve sunucuda gerçekleştirilmelidir. Bu görevler betikler veya diğer otomasyon çözümleri kullanılarak uygulanabilir, ancak ek yönetim gereksinimlerini tamamen ortadan kaldıramayabilir.

• Parçalar, içerdikleri verilerin veriyi kullanan bir uygulamaya ait örneklere yakın olması için coğrafi olarak konumlandırılabilir. Bu yaklaşım, performansı önemli ölçüde artırabilir ancak farklı konumlardaki birden fazla parçaya erişmesi gereken görevler için daha fazla değerlendirme gerektirir.

Bu düzenin kullanılacağı durumlar

Bir veri deposunu tek bir depolama düğümünde mevcut olan kaynakların dışında ölçeklendirme gereksinimi yüksek bir olasılık ise veya bir veri deposunda çekişmeyi azaltarak performansı iyileştirmek amacıyla bu düzeni kullanın.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için parçalama düzeninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.

Örnek

Dünya çapında yayımlanan kitaplarla ilgili kapsamlı bir bilgi koleksiyonunu ortaya çıkaran bir web sitesi düşünün. Bu iş yükünde kataloglanmış olası kitap sayısı ve tipik sorgu/kullanım desenleri, kitap bilgilerini depolamak için tek bir ilişkisel veritabanının kullanımını gösterir. İş yükü mimarı, parça anahtarı için kitapların statik Uluslararası Standart Kitap Numarası'nı (ISBN) kullanarak verileri birden çok veritabanı örneğinde parçalamaya karar verir. Özellikle, ISBN'nin denetim basamaklarını (0 - 10) kullanırlar, bu da 11 olası mantıksal parça verir ve veriler her parça arasında oldukça dengelenir. İlk olarak, 11 mantıksal parçanın üç fiziksel parça veritabanına ayrılmaya karar verir. Arama parçalama yaklaşımını kullanır ve anahtardan sunucuya eşleme bilgilerini bir parça eşleme veritabanında depolar.

Arama parça eşlemesi

Parça eşleme veritabanı aşağıdaki parça eşleme tablosunu ve verilerini içerir.

SELECT ShardKey, DatabaseServer
FROM BookDataShardMap

| ShardKey | DatabaseServer |
|----------|----------------|
|        0 | bookdbshard0   |
|        1 | bookdbshard0   |
|        2 | bookdbshard0   |
|        3 | bookdbshard1   |
|        4 | bookdbshard1   |
|        5 | bookdbshard1   |
|        6 | bookdbshard2   |
|        7 | bookdbshard2   |
|        8 | bookdbshard2   |
|        9 | bookdbshard0   |
|       10 | bookdbshard1   |

Örnek web sitesi kodu - tek parça erişimi

Web sitesi fiziksel parça veritabanı sayısını (bu örnekte üç tane) veya bir parça anahtarını bir veritabanı örneğine eşleyen mantığın farkında değildir, ancak web sitesi bir kitabın ISBN'sinin denetim rakamının parça anahtarı olarak kabul edilmesi gerektiğini biliyor. Web sitesi parça haritası veritabanına salt okunur erişime ve tüm parça veritabanlarına okuma-yazma erişimine sahiptir. Bu örnekte web sitesi, gizli dizileri bağlantı dizesi dışında tutmak üzere yetkilendirme için web sitesini barındıran Azure Uygulaması Hizmeti'nin sistem tarafından yönetilen kimliğini kullanıyor.

Web sitesi, bu örnekte olduğu gibi bir appsettings.json dosyada veya App Service uygulama ayarları aracılığıyla aşağıdaki bağlantı dizesi ile yapılandırılır.

{
  ...
  "ConnectionStrings": {
    "ShardMapDb": "Data Source=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=ShardMap;Authentication=Active Directory Default;App=Book Site v1.5a",
    "BookDbFragment": "Data Source=tcp:SHARD.database.windows.net,1433;Initial Catalog=Books;Authentication=Active Directory Default;App=Book Site v1.5a"
  },
  ...
}

Parça eşleme veritabanına bağlantı bilgileri kullanılabilir durumda olduğundan, web sitesi tarafından iş yükünün veritabanı parça havuzuna yürütülen bir güncelleştirme sorgusu örneği aşağıdaki koda benzer olacaktır.

...

// All data for this book is stored in a shard based on the book's ISBN check digit,
// which is converted to an integer 0 - 10 (special value 'X' becomes 10).
int isbnCheckDigit = book.Isbn.CheckDigitAsInt;

// Establish a pooled connection to the database shard for this specific book.
using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: isbnCheckDigit, cancellationToken))
{
  // Update the book's Library of Congress catalog information
  SqlCommand cmd = sqlConn.CreateCommand();
  cmd.CommandText = @"UPDATE LibraryOfCongressCatalog
                         SET ControlNumber = @lccn,
                             ...
                             Classification = @lcc
                       WHERE BookID = @bookId";

  cmd.Parameters.AddWithValue("@lccn", book.LibraryOfCongress.Lccn);
  ...
  cmd.Parameters.AddWithValue("@lcc", book.LibraryOfCongress.Lcc);
  cmd.Parameters.AddWithValue("@bookId", book.Id);

  await cmd.ExecuteNonQueryAsync(cancellationToken);
}

...

Yukarıdaki örnek kodda book.Isbn 978-8-1130-1024-6 ise 6isbnCheckDigit olmalıdır. çağrısı OpenShardConnectionForKeyAsync(6) genellikle edilgen önbellek yaklaşımıyla uygulanır. Parça anahtarı 6 için önbelleğe alınmış parça bilgileri yoksa, bağlantı dizesi ShardMapDb ile tanımlanan parça eşleme veritabanını sorgular. Uygulamanın önbelleğinden veya parça veritabanından bookdbshard2 değeri bağlantı dizesi yerini SHARD BookDbFragment alır. Bookdbshard2.database.windows.net için havuza alınan bağlantı (yeniden) oluşturulur, açılır ve çağrı koduna döndürülür. Kod daha sonra bu veritabanı örneğindeki mevcut kaydı güncelleştirir.

Örnek web sitesi kodu - birden çok parça erişimi

Nadiren de olsa web sitesi tarafından doğrudan, parçalar arası sorgu gerektiğinde, uygulama tüm parçalar arasında paralel bir fan-out sorgusu gerçekleştirir.

...

// Retrieve all shard keys
var shardKeys = shardedDatabaseConnections.GetAllShardKeys();

// Execute the query, in a fan-out style, against each shard in the shard list.
Parallel.ForEachAsync(shardKeys, async (shardKey, cancellationToken) =>
{
  using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: shardKey, cancellationToken))
  {
    SqlCommand cmd = sqlConn.CreateCommand();
    cmd.CommandText = @"SELECT ...
                          FROM ...
                         WHERE ...";

    SqlDataReader reader = await cmd.ExecuteReaderAsync(cancellationToken);

    while (await reader.ReadAsync(cancellationToken))
    {
      // Read the results in to a thread-safe data structure.
    }

    reader.Close();
  }
});

...

Bu iş yükündeki parçalar arası sorgulara alternatif olarak, site araması veya çok yönlü gezinti işlevi gibi Azure AI Search'te harici olarak tutulan bir dizin kullanmak da olabilir.

Parça örnekleri ekleme

İş yükü ekibi, veri kataloğunun veya eşzamanlı kullanımının üçten fazla veritabanı örneğinin önemli ölçüde artması durumunda gerekli olabileceğinin farkındadır. İş yükü ekibi veritabanı sunucularını dinamik olarak eklemeyi beklemez ve yeni bir parçanın çevrimiçi olması gerektiğinde iş yükü kapalı kalma süresine dayanıklıdır. Yeni bir parça örneğini çevrimiçi yapmak için mevcut parçalardan yeni parçaya veri taşımanın yanı sıra parça eşleme tablosuna bir güncelleştirme yapılması gerekir. Bu oldukça statik yaklaşım, iş yükünün web sitesi kodunda parça anahtarı veritabanı eşlemesini güvenle önbelleğe almasına olanak tanır.

Bu örnekteki parça anahtarı mantığının en fazla 11 fiziksel parça üst sınırı vardır. İş yükü ekibi yük tahmin testleri yapar ve sonunda 11'den fazla veritabanı örneği gerekeceğini değerlendirirse, parça anahtarı mantığında invaziv bir değişiklik yapılması gerekir. Bu değişiklik, kod değişikliklerinin dikkatli bir şekilde planlanması ve yeni anahtar mantığına veri geçişi içerir.

SDK işlevselliği

Azure SQL Veritabanı örneklerine parça yönetimi ve sorgu yönlendirme için özel kod yazmak yerine Elastik Veritabanı istemci kitaplığını değerlendirin. Bu kitaplık hem C# hem de Java'da parça eşleme yönetimini, verilere bağımlı sorgu yönlendirmeyi ve parçalar arası sorguları destekler.

Sonraki adımlar

Bu düzeni uygularken aşağıdaki yönergeler de yararlı olabilir:

• Veri Tutarlılığı Temel Bilgileri. Farklı parçalara dağıtılan veriler için tutarlılığın sürdürülmesi gerekli olabilir. Dağıtılmış veriler üzerinde tutarlılık sağlama konusundaki sorunları özetlemesinin yanı sıra farklı tutarlılık modellerinin avantajlarını ve dezavantajlarını açıklar.
• Veri Bölümleme Kılavuzu. Bir veri deposunun parçalanması bir dizi ek sorunu ortaya çıkarabilir. Ölçeklenebilirliği artırmak, çekişmeyi azaltmak ve performansı iyileştirmek üzere bu sorunları buluttaki veri depolarını bölümlemeyle ilgili olarak açıklar.

İlgili kaynaklar

Bu desen uygulanırken aşağıdaki desenler de uygun olabilir:

• Dizin Tablosu deseni. Bazı durumlarda sorguların yalnızca parça anahtarı tasarımıyla tamamen desteklenmesi mümkün değildir. Bir uygulamanın, parça anahtarı dışında bir anahtar belirterek büyük bir veri deposundan verileri hızlıca almasını sağlar.
• Gerçekleştirilmiş Görünüm düzeni. Bazı sorgu işlemlerinin performansını korumak için, özellikle bu özet veriler parçalar arasında dağıtılan bilgileri temel alıyorsa, verileri toplayıp özetleyen gerçekleştirilmiş görünümler oluşturmak yararlıdır. Bu görünümlerin nasıl oluşturulup doldurulacağını açıklar.