Şarding deseni

Veri deposunu bir dizi yatay bölüme veya parçaya ayırın. Bu yaklaşım, büyük hacimli verileri depolayıp bunlara erişirken ölçeklenebilirliği geliştirebilir.

Bağlam ve sorun

Tek bir sunucudaki veri deposu aşağıdaki sınırlamalara sahiptir:

Depolama alanı: Büyük ölçekli bir bulut uygulaması için veri deposu, zaman içinde büyüyen büyük miktarda veri içerebilir. Sunucu sınırlı miktarda disk depolama alanı sağlar ve mevcut diskleri daha büyük disklerle değiştirebilir veya veri birimleri büyüdükçe daha fazla disk ekleyebilirsiniz. Sistem sonunda tek bir sunucudaki depolama kapasitesini artırabileceğiniz bir sınıra ulaşır.
Bilgi işlem kaynakları: Bulut uygulaması, her biri veri deposunda sorgu çalıştıran çok sayıda eşzamanlı kullanıcıyı desteklemelidir. Tek bir sunucu bu yük için yeterli bilgi işlem gücü sağlamayabilir ve bu da uzun yanıt süreleri ve zaman aşımlarıyla sonuçlanabilir. Bellek veya yükseltme işlemcileri ekleyebilirsiniz, ancak sistem işlem kaynaklarını daha fazla artıramayabileceğiniz bir sınıra ulaşır.
Ağ bant genişliği: Tek bir sunucunun istek alma ve yanıt gönderme hızı veri deposu performansını sınırlar. Ağ trafiği hacmi, ağ bağlantısının kapasitesini aşabilir ve bu da başarısız isteklerle sonuçlanabilir.
Coğrafya: Yasal, uyumluluk veya performans gereksinimleri, kullanıcı verilerini kullanıcılarla aynı coğrafi bölgede depolamanızı gerektirebilir. Kullanıcılar ülkelere/bölgelere yayılmışsa, uygulamanın tüm verilerini tek bir veri deposunda depolayamayabilirsiniz.

Bu sınırlamaları geçici olarak ertelemek için disk kapasitesi, işlem gücü, bellek ve ağ bağlantıları ekleyerek dikey olarak ölçeklendikleyebilirsiniz. Çok sayıda kullanıcıyı ve yüksek veri hacimlerini desteklemesi gereken bir bulut uygulamasının yatay olarak ölçeklendirilmesi gerekir.

Çözüm

Veri deposunu yatay bölümlere veya parçalara ayırın. Her parça aynı şemaya sahiptir ancak verilerin kendi ayrı alt kümesini içerir. Her parça, farklı türlerdeki birçok varlık için veri içerebilen eksiksiz bir veri deposudur. Shard, bir depolama düğümü olarak işlev gören bir sunucuda çalışır.

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

Ek depolama düğümlerine daha fazla parça ekleyerek sistemin ölçeğini genişletebilirsiniz.
Bir sistem, her depolama düğümü için özel ve pahalı bilgisayarlar yerine önceden oluşturulmuş donanım kullanabilir.
Parçalar arasındaki iş yükünü dengeleyerek çekişmeyi azaltabilir ve performansı artırabilirsiniz.
Bulutta parçalar, verilere erişen kullanıcılara fiziksel olarak yakın bir konumda bulunabilir.

Veri depolarını parçalara böldüğünüzde, her parçaya hangi verilerin yerleştirildiğine karar verin. Her parça genellikle bir veya daha fazla veri özniteliğine göre gruplandırılmış öğeleri tutar. Bu öznitelikler, bazen bölüm anahtarı olarak da adlandırılan parça anahtarını oluşturur.

Parçalama işlemi, verileri fiziksel olarak düzenler. Bir uygulama verileri depolayıp aldığında, parçalama mantığı verileri uygun parçaya yönlendirir. Bu mantığı uygulamanın veri erişim kodunda veya parçalanmayı saydam bir şekilde destekliyorsa veri depolama sisteminde uygulayabilirsiniz.

Parçalama mantığındaki verilerin fiziksel konumunu soyutlama, hangi parçaların hangi verileri içerdiği üzerinde denetim sağlar. Ayrıca, parçaların dengesiz hale gelmesi gibi verileri yeniden dağıtmanız gerektiğinde uygulama iş mantığını değiştirmeden parçalar arasında veri geçirebilirsiniz. Bu durum, alma sırasında her veri öğesinin konumunu belirlemek için ek veri erişimi zaman ve kaynak tüketimini içerir.

Parça anahtarı seçimi

Parça anahtarı, parçalı sistemdeki en kritik tasarım kararıdır. Bir parça anahtarını seçtikten sonra değiştirmek için, genellikle tüm verileri canlı bir sistemde pahalı ve riskli bir işlem olan yeni bir parça düzenine geçirmeniz gerekir. Kod yazmadan önce bu kararı dikkatli bir şekilde verme.

Etkili bir parça anahtarı sabittir, yüksek kardinaliteye sahiptir, verileri eşit olarak dağıtır ve baskın sorgu desenlerinizle hizalanır, böylece çoğu istek tek bir parçaya karşı çözümlenebilir. Monotonik artan değerlerden (otomatik artışlı tamsayılar ve sıralı zaman damgaları), düşük kardinaliteli özniteliklerden (booleanlar ve küçük enum kümeleri) ve sık değişen değişken özniteliklerden kaçının. Bu öznitelikler etkin noktalara veya yüksek maliyetli çapraz parça veri hareketine yol açar.

Bu ölçütleri karşılayan tek bir öznitelik yoksa, iki veya daha fazla özniteliği birleştirerek bileşik bir parça anahtarı tanımlayın. Sorguların parça anahtarının parçası olmayan özniteliklere göre veri alması gerekiyorsa, ikincil aramalar sağlamak için Dizin Tablosu deseni gibi bir desen kullanın.

Azure hizmetlerinde bölüm anahtarlarını seçme hakkında daha fazla bilgi için bkz. Veri bölümleme kılavuzu ve Veri bölümleme stratejileri.

Parçalama stratejileri

Parça anahtarını seçip verileri parçalar arasında nasıl dağıtabileceğinize karar vermek için aşağıdaki stratejilerden birini kullanın. Parçalar ve bunları barındıran sunucular arasında bire bir yazışmaya ihtiyacınız yoktur. Tek bir sunucu birden çok parça barındırabilir.

Arama tabanlı parçalama stratejisi

Dizin tabanlı strateji olarak da adlandırılan arama stratejisinde parçalama mantığı, parça anahtarını kullanarak veri isteğini bu verileri içeren parçaya yönlendiren bir eşleme uygular. Çok kiracılı bir uygulamada, parça anahtarı olarak kiracı kimliğini kullanarak bir kiracının tüm verilerini bir parçada birlikte depolayabilirsiniz. Birden çok kiracı aynı parçayı paylaşabilir, ancak tek bir kiracının verileri birden çok parçaya yayılmaz. Aşağıdaki diyagramda kiracı verileri, kiracı kimliklerine göre parçalanarak gösterilmektedir.

Parça anahtarı değerleri ile fiziksel depolama arasındaki eşleme, her parça anahtarı değerinin fiziksel bir bölüme eşlendiği doğrudan olabilir. Daha esnek bir teknik, parça anahtarı değerlerinin sanal parçalara eşlendiği ve sistemin bu sanal parçaları daha az fiziksel bölümle eşlediği sanal bölümlemedir. Bir uygulama, 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 kodu değişikliklerine gerek kalmadan değişebilir.

Aralık tabanlı parçalama stratejisi

Aralığa dayalı strateji, ilgili öğeleri aynı bölümde gruplandırır ve sıralı bölüm anahtarına göre sıralar. Bu strateji, aralık sorgularını kullanarak sık sık öğe kümeleri alan uygulamaları destekler. Aralık sorguları, belirli bir aralığın içinde yer alan bir parça anahtarı için bir veri öğeleri kümesi döndürür.

Örneğin, bir uygulamanın belirli bir ayda verilen tüm siparişleri düzenli olarak bulması gerekiyorsa, bir ayın tüm siparişlerini aynı parçada tarih ve saat sırasına göre depolarsanız verileri daha hızlı alabilirsiniz. Her siparişi farklı bir parçada depolarsanız, uygulamanın çok sayıda nokta sorgusu gerçekleştirerek bunları tek tek getirmesi gerekir. Aşağıdaki diyagramda parçalarda depolanan verilerin sıralı kümeleri veya aralıkları gösterilmektedir.

Bu örnekte parça anahtarı, en önemli öğe olarak sipariş ayını ve ardından sipariş günü ve saatini içeren bileşik bir anahtardır. Yeni siparişler, oluşturulduklarında ve bir parçaya eklendikçe doğal olarak sıralanır.

Bazı veri depoları iki parçalı parça anahtarlarını destekler. Bölüm anahtarı parçayı tanımlar ve satır anahtarı parça içindeki bir öğeyi benzersiz olarak tanımlar. Parça genellikle verileri satır anahtarı sırasına göre depolar. Aralık sorguları gerektiren ve birlikte gruplanması gereken öğeler için, bölüm anahtarı için aynı değere ancak satır anahtarı için benzersiz bir değere sahip bir parça anahtarı kullanabilirsiniz.

Hash tabanlı parçalama stratejisi

Hash tabanlı strateji, orantısız miktarda yük alan parçalar olan sıcak noktaların oluşma olasılığını azaltır. Bu strateji, her parçanın boyutunu ve her parçanın karşılaştığı ortalama yükü dengelemek için verileri 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 verileri parçalar arasında eşit bir şekilde dağıtmalıdır. Aşağıdaki diyagram, kiracı kimliklerinin karmasına göre kiracı verilerinin kırılmasını (parçalanmasını) göstermektedir.

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 kullandığınızda, 1 ile n kiracılarının verileri A parçasında depolanır, n+1 ile m kiracılarının verileri B parçasında depolanır ve daha sonraki kiracı aralıkları ardışık parçalarla eşlenir. En son kaydedilen kiracılar aynı zamanda en aktif olan kiracılarsa, çoğu veri etkinliği birkaç parçada gerçekleşir ve bu da ana noktaların oluşmasına neden olabilir. Buna karşılık, karma stratejisi kiracıları, kiracı kimliklerinin karması temelinde kümelere dağıtır. Hash genellikle art arda gelen kiracıları farklı bölümler arasında dağıtarak iş yükünü dengeler. Önceki diyagramda 55 ve 56 kiracıları için bu yaklaşım gösterilmektedir.

Coğrafi parçalama stratejisi

Coğrafi strateji, verilerin coğrafi kaynağına veya hedeflenen tüketim bölgesine göre parçalara veri atar. Birçok iş yükünde kullanıcılar ve oluşturdukları veriler belirli bölgelerde yoğunlaştırılmıştır. Veri yerleşimi yasaları gibi mevzuat gereksinimleri, belirli verilerin belirli bir yargı alanında kalmasını gerektirebilir. Mevzuat sürücüleri olmasa bile, verileri en sık erişen kullanıcıların yakınlarına yerleştirmek, okuma ve yazma işlemleri için ağ gecikmesini azaltır.

Bu stratejide, parça anahtarını kullanıcının ülkesi/bölgesi, kaynak veri merkezi bölgesi veya bölgesel kiracı tanımlayıcısı gibi bir coğrafi öznitelikten türetebilirsiniz. Her bir parçayı, bu coğrafi sınır içindeki altyapıda barındırır veya bu parçaya sabitlersiniz.

Örneğin, Kuzey Amerika, Avrupa ve Asya-Pasifik'teki müşterilere hizmet veren bir uygulama, her Azure bölgesinde bir grup olmak üzere üç shard grubu bulundurabilir. Yalnızca Avrupalı kullanıcılara hizmet veren bir Avrupa uygulaması, bir isteği Avrupa parçasına yönlendirir. Bu yaklaşım gecikme süresini azaltır ve veri yerleşimi gereksinimlerini karşılar.

Coğrafi parçalama, eşit olmayan veri dağıtımı riskini ortaya çıkartır. Kullanıcılarınızın çoğu tek bir bölgede bulunuyorsa, bu bölgenin parçası yük ve depolamanın orantısız bir paylaşımını taşır. Yükü aynı coğrafi sınır içindeki birden çok parçaya eşit olarak dağıtmak için coğrafi parçalama ile her bölge içinde karma veya arama gibi başka bir stratejiyi birleştirebilirsiniz.

Her stratejinin avantajları ve dikkat edilmesi gerekenler

Dört parçalama stratejisi aşağıdaki avantajlara ve dikkat edilmesi gereken noktalara sahiptir:

Arama stratejisi parça yapılandırması üzerinde daha fazla denetim sağlar. Sanal parçalar yeniden dengelemenin etkisini azaltır çünkü iş yükünü dengelemek için yeni fiziksel bölümler ekleyebilirsiniz. Uygulama kodunu etkilemeden bir sanal parça ile fiziksel bölümleri arasındaki eşlemeyi değiştirebilirsiniz. Parça konumlarını aramak ek yük getirir.
Aralık stratejisinin uygulanması kolaydır ve aralık sorgularıyla iyi çalışır. Aralık sorguları tek bir işlemde tek bir parçadan birden çok veri öğesi alabilir. Veri yönetimi daha basittir. Örneğin, aynı bölgedeki kullanıcılar bir parça paylaştığında yerel yük desenlerine göre saat dilimi başına güncelleştirmeleri zamanlayabilirsiniz. Ancak bu strateji, parçalar arasında yükü eşit olarak dengelemez. Yeniden dengeleme zordur ve çoğu etkinlik bitişik parça anahtarlarına odaklandığında eşit olmayan yükü çözemeyebilir.
Karma strateji , veri ve yük dağıtımı için bile daha iyi bir şans sağlar. Bir harita tutmadan karma fonksiyonunu kullanarak istekleri doğrudan iletebilirsiniz. Karmayı hesaplama biraz ek yük getirir. Tutarlı hashleme olmadan yeniden dengeleme zordur.
Coğrafi strateji, diğer stratejilerin doğal olarak ele almamış olduğu veri yerleşimi ve egemenlik gereksinimlerini karşılar. Kullanıcılar kendi bölgelerindeki verilere eriştiğinde okuma ve yazma gecikme süresini azaltır. Ancak coğrafi parçalama, kullanıcı popülasyonları bölgeler arasında eşit olarak dağıtılamadığında önemli veriler ve yük dengesizliği oluşturabilir. Genel raporlama gibi bölgelere yayılan sorguların tüm coğrafi parçalardan veri alması ve daha yüksek gecikme süresine neden olması gerekir. Hem uyumluluk hem de yük dağıtımına ihtiyaç duyduğunuzda coğrafi parçalama ile her bölge içinde başka bir stratejiyi birleştirin.

Parçalama sistemlerinin çoğu bu yaklaşımlardan birini uygular, ancak uygulamanızın iş gereksinimlerini ve veri kullanım düzenlerini de göz önünde bulundurmanız gerekir. Örneğin, çok kiracılı bir uygulamada:

verileri iş yüküne göre parçalayabilirsiniz. Diğer kiracıların veri erişim hızını artırmak için, yüksek değişkenliğe sahip kiracıların verilerini ayrı parçalara ayırın.
Verileri kiracı konumuna göre parçalayabilirsiniz. Belirli bir coğrafi bölgedeki kiracı verilerini, o bölgenin yoğun olmayan saatlerinde yedekleme ve bakım için çevrimdışına alın, diğer bölgelerdeki kiracı verileri ise iş saatlerinde çevrimiçi kalır.
Yüksek değerli kiracılara kendi ayrılmış, az yüklenmiş parçalarını atayın. Düşük değerli kiracılar daha yoğun paketlenmiş parçaları paylaşabilir.
Güçlü veri yalıtımı ve gizlilik gerektiren kiracılar için verileri ayrı sunucularda depolayın.

Her strateji için ölçeklendirme ve veri taşıma işlemleri

Her parçalama stratejisi ölçeği daraltma, ölçeği genişletme, veri taşıma ve durum bakımını yönetmek için farklı özellikler ve karmaşıklık düzeyleri sağlar.

Arama stratejisi , çevrimiçi veya çevrimdışı olarak kullanıcı düzeyinde ölçeklendirme ve veri taşıma işlemlerine olanak tanır. Verileri taşımak için:
1. Genellikle yoğun olmayan dönemlerde kullanıcı etkinliklerinden bazılarını veya tümünü askıya alın.
2. Verileri yeni sanal bölüme veya fiziksel parçaya taşıyın.
3. Eşlemeleri güncelleştirin.
4. Bu verileri barındıran tüm önbellekleri geçersiz kılın veya yenileyin.
5. Kullanıcı etkinliğini sürdür.
Bu işlemi genellikle merkezi olarak yönetebilirsiniz. Arama stratejisi, durumun yüksek oranda önbelleğe alınabilir ve çoğaltma dostu olmasını gerektirir.
Genellikle veri deposunun bir bölümü veya tamamı çevrimdışıyken verileri parçalar arasında bölmeniz ve birleştirmeniz gerektiğinden, aralık stratejisi ölçeklendirme ve veri taşıma işlemlerini sınırlar. Parçaları yeniden dengelemek için verileri taşıdığınızda, çoğu etkinlik aynı aralıktaki bitişik parça anahtarlarına veya veri tanımlayıcılarına odaklanıyorsa dengesiz yükü ortadan kaldıramayabilirsiniz. Aralık stratejisi, aralıkları fiziksel bölümlere eşleme durumunu da gerektirebilir.
Karma strateji , ölçeklendirme ve veri taşıma işlemlerini karmaşıklaştırır. Bölüm anahtarları, parça anahtarlarının veya veri tanımlayıcılarının karmalarıdır. Standart bir karma işlevi (örn. hash(key) mod N) ile, bir parçacık eklenmesi veya çıkarılması birçok anahtarın yeniden atanmasına ve büyük ölçekli veri geçişlerini tetiklemesine neden olur. Tutarlı hash, parça sayısı değiştiğinde anahtarların sadece küçük bir kısmının taşınmasına yol açarak bu etkiyi azaltmak için hash alanını düzenler. Hash stratejisi, ayrı bir eşleme durumu bakımı gerektirmez.
Coğrafi strateji, ölçeklendirme işlemlerini bölgesel altyapı sağlama ile doğrudan bağlar. Kapasitenin bir bölgeye eklenmesi, başka bir bölgedeki yükü hafifletmiyor. Coğrafi parçalama gerektiren mevzuat gereksinimleri, coğrafi sınırlar arasında veri hareketini de kısıtlayabilir. Her bölge içinde ölçeklendirme, verileri bu bölgenin parçaları arasında dağıtan ikincil stratejiyi kullanır.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:

Dikey bölümleme ve işlevsel bölümleme gibi diğer bölümleme biçimleri için parçalama tamamlayıcısı kullanın. Örneğin, tek bir parça dikey olarak bölümlenmiş varlıklar içerebilir ve işlevsel bir bölümü birden çok parça olarak uygulayabilirsiniz. Daha fazla bilgi için bkz. Yatay, dikey ve işlevsel veri bölümleme.
Benzer bir giriş/çıkış (G/Ç) birimini işleyebilmeleri için parçaları dengeli tutun. Kayıtlar eklenip silindiğinde zaman içinde veri dengesizliği birikerek sıcak noktalara yol açar. Düzenli aralıklarla yeniden dengelemeyi planlayın.

Yeniden dengeleme verileri parçalar arasında taşır ve genellikle kesinti veya aktarım hızının azalmasına neden olur. Daha az sıklıkta yeniden dengelemek için sanal bölümleri kullanın. Birçok mantıksal bölümü daha az fiziksel parçayla eşleyin. Bir parça aşırı yüklendiğinde, veri kümesinin tamamını yeniden dağıtmadan sanal bölümlerini yeni fiziksel parçalara yeniden dağıtın. Azure Cosmos DB, bölüm düzenini fiziksel altyapıdan ayrıştırmak için bu yaklaşımı kullanır.

Birkaç büyük parça yerine birçok küçük parça tercih edin. Daha küçük parçalar daha hızlı geçer, yükü daha dengeli dağıtır ve veri yeniden dağıtımı için daha fazla esneklik sağlar.
Parça anahtarı için kararlı veriler kullanın. Parça anahtarı değişirse, ilgili veri öğesini parçalar arasında taşımanız gerekebilir ve bu da güncelleştirme işlemi ek yükünü artırır. Parça anahtarını geçici olabilecek bilgilere dayandırmaktan kaçının. Sabit veya doğal olarak bir anahtar oluşturan öznitelikleri seçin.
Parça anahtarlarının benzersiz olduğundan emin olun. Örneğin, parça anahtarı olarak otomatik olarak artan alanlar kullanmaktan kaçının. Bazı sistemlerde otomatik artan alanlar, parçalar arasında uyumlu çalışamaz ve bu da farklı parçalardaki öğelerin aynı parça anahtarına sahip olmasına neden olabilir.

Uyarı

Parçalanmış anahtar olmayan diğer alanlardaki otonom olarak arttırılan değerler de sorunlara neden olabilir. Örneğin, benzersiz kimlikler oluşturmak için otomatik olarak eklenen alanları kullanırsanız, farklı parçalardaki iki farklı öğeye aynı kimlik atanabilir.
En sık gerçekleştirilen sorguları desteklemek için verileri parçala. Verilerle ilgili her sorgunun gereksinimleriyle eşleşen bir parça anahtarı tasarlayamayabilirsiniz. Gerekirse, parça anahtarının parçası olmayan özniteliklere göre veri alan sorguları desteklemek için ikincil dizin tabloları oluşturun. Daha fazla bilgi için bkz. Dizin Tablosu düzeni.
Çoğu işlemin kapsamını tek bir parça olarak tutmak için parça anahtarınızı ve veri modelinizi tasarlayın. Yalnızca tek bir parçaya erişen sorgular, birden çok parçadan veri alan sorgulardan daha verimlidir. Verilerinizi denormalize edin, böylece müşteriler ve siparişleri gibi sık sorgulanan ilgili varlıkları aynı parçada tutarak ayrı okuma miktarını azaltabilirsiniz.

Parçalar arası sorgular gecikme süresi, kaynak tüketimi ve karmaşıklık ekler. Bir uygulamanın birden çok parçadan veri alması gerektiğinde, eşzamanlı olarak her parçaya karşı çalışan ve sonuçları toplayan paralel fan-out sorguları kullanın. Paralellik ile bile en yavaş parça genel gecikme süresini belirler.

İpucu

Bir parçadaki bir varlık başka bir parçadaki bir varlığa başvuruda bulunursa, ikinci varlığın parça anahtarını ilk varlığın şemasının bir parçası olarak ekleyin. Bu yaklaşım, parçalar arasında ilgili verilere başvuran sorguların performansını geliştirebilir.
İş yükünüz parça sınırları boyunca güçlü işlem bütünlüğü gerektiriyorsa parça anahtarınızı veya parçalamanın gereksinimlerinize uygun olup olmadığını yeniden düşünün. Parçalar arası işlemler zorluklar ortaya çıkarır. İki aşamalı işleme, gecikme süresi ekleme, hata modları sunma ve aktarım hızını azaltma gibi dağıtılmış koordinasyon protokolleri. Parçalı sistemlerin çoğu dağıtılmış işlemlerden kaçınıyor ve bunun yerine nihai tutarlılığı benimser. Bu modelde her parça bağımsız olarak güncelleştirilir ve uygulama geçici tutarsızlıkları işler.
Her parça depolama düğümü için kullanılabilir kaynakların, veri boyutu ve aktarım hızı açısından ölçeklenebilirlik gereksinimlerini işleyebileceğinden emin olun. Daha fazla bilgi için bkz. Veri bölümleme stratejileri.
Referans verilerini tüm parçalara çoğaltmayı düşünün. Parçaya yönelik bir sorgu statik veya yavaş hareket eden verilere de başvuruyorsa, bu verileri parçaya ekleyin. Uygulama daha sonra ayrı bir veri deposuna gidiş dönüş yapmadan sorgunun tüm verilerini getirebilir.

Uyarı

Birden çok parçada tutulan başvuru verileri değişirse, sistemin bu değişiklikleri tüm parçalar arasında eşitlemesi gerekir. Bu eşitleme çalışırken bir miktar tutarsızlık oluşabilir. Uygulamalarınızı bu tutarsızlığı tolere etmek için tasarlar.
Parçalı sistemler operasyonel yükü artırıyor. Bu endişeler için planlayın:
- Izleme: Sistem durumunun tam görünümünü elde etmek için tüm parçalar genelinde ölçümleri ve günlükleri toplamanız gerekir.
- Yedekleme ve geri yükleme: Parçalar arası tutarlılığı korumak için her bir parçanın yedeğini bağımsız olarak yedeklemeli ve geri yükleme yordamları tasarlamanız gerekir. Bir parçanın belirli bir noktaya geri yüklenmesi diğer parçalarla tutarsızlıklar oluşturabilir.
- Şema değişiklikleri: Her parçada Veri Tanımı Dili (DDL) değişikliklerini koordine etmeniz gerekir.
Betikleri veya diğer otomasyon çözümlerini kullanarak bu görevleri uygulayabilirsiniz.
Verilerini kullanan uygulama örneklerinin yakınına yerleştirmek için parçaları coğrafi olarak yerleştirebilirsiniz. Bu yaklaşım performansı geliştirebilir ancak farklı konumlardaki birden çok parçaya erişmesi gereken işlemler için ek planlama gerektirir.

Bu desen ne zaman kullanılır?

İpucu

Özel bir parçalama katmanı tasarlamadan önce, veri platformunuzun zaten hangi parçalama sorumluluklarını işlediğini belirleyin. Bazı hizmetler parçalama işlemini tamamen yönetir. Örneğin, Azure Cosmos DB verileri fiziksel bölümler arasında dağıtır, bölmeleri işler ve sorguları uygulama katılımı olmadan yönlendirir. Diğer hizmetler parçalama işlemini kısmen yönetir. Örneğin, Azure SQL Veritabanı parça eşlemesi yönetimi ve verilere bağımlı yönlendirme için esnek veritabanı araçları sağlar, ancak parça anahtarını tasarlar ve bölme işlemlerini yönetirsiniz. Parçalama mantığını kendiniz oluşturup çalıştırırken parçalama desenini kullanın.

Bu düzeni aşağıdaki durumlarda kullanın:

Toplam veri hacmi tek bir veritabanı örneğinin depolama kapasitesini aşıyor ve hiçbir dikey ölçeklendirme seçeneği bu eksikliği gideremiyor.
İşlem aktarım hızı veya sorgu eşzamanlılığı tek bir örneğin sürdürebileceği değeri aşıyor ve yazma yükü de yüksek olduğundan yalnızca okuma çoğaltmaları bu sorunu çözemiyor.

Uyarı

Parçalama, bir sistemin performansını ve ölçeklenebilirliğini artırır ve kullanılabilirliği de iyileştirebilir. Bir bölümdeki hata, bir uygulamanın diğer bölümlerdeki verilere erişmesini engellemez. Operatör, tüm verileri kullanılamaz hale getirmeden bir bölümün bakımını veya kurtarma işlemini gerçekleştirebilir. Daha fazla bilgi için bkz. Veri bölümleme kılavuzu.
Mevzuat veya uyumluluk gereksinimleri, belirli veri alt kümelerinin belirli coğrafi yargı bölgelerinde bulunmasını gerektirmektedir. Tek bölgeli bir dağıtım, tüm gereksinimleri karşılayamaz.
Ayrı kiracılar veya müşteri kesimleri güvenlik, performans veya sözleşmeye bağlı nedenlerle fiziksel veri yalıtımı gerektirir.

Bu gibi senaryolarda parçalama düzeni bazen geleneksel veri depolarının ötesine uygulanır. Örneğin, DNS bölge yönetim sistemi, DNS değişikliklerinin patlama yarıçapını azaltmak ve net sahiplik sınırları oluşturmak için ekip, ortam veya bölgeye göre parçalanabilir. Bu bağlamda, birincil motivasyon ölçeklenebilirlik yerine operasyonel segmentlere ayırmadır. Daha fazla bilgi için bkz . Özel DNS bölgelerini parçalama.

Parçalama, veri mimarinizde önemli ve kalıcı karmaşıklık sağlar. Bu karmaşıklık, sistemin ömrü boyunca geliştirme, işlemler, test, sorgu tasarımı ve hata kurtarmayı etkiler.

Bu düzen aşağıdaki durumlarda uygun olmayabilir:

Veri hacminiz ve aktarım hızınız, öngörülen büyümeyle bile tek bir veritabanı örneğine sığar. Dikey ölçeklendirme, sorgu basitliğini ve işlem bütünlüğünü korur.
Performans dar boğazınız, yazma hacmi veya depolama kapasitesi değil, okuma hacmidir. Okuma çoğaltmaları ve önbelleğe alma katmanları, parçalamanın neden olduğu parçalar arası sorgu karmaşıklığı olmadan okuma trafiğini boşaltabilir.
Veritabanı altyapınız, performans gereksinimlerinizi karşılayan tablo düzeyinde bölümlemesi destekler. Tek bir örnek içinde bölümleme için birden çok sunucu veya yönlendirme mantığı gerekmez.
Baskın sorgu düzenleriniz için çapraz varlık birleşimleri, çoklu varlık işlemleri veya tüm veri kümesiyle ilgili toplama işlemleri gereklidir. Parçalama, bu işlemleri pahalı hale getirir ve yayılım sorguları ile dağıtılmış koordinasyonun getirdiği ek yük, ölçeklendirme faydalarından daha ağır basabilir.

İş yükü tasarımı

Azure Well-Architected Framework yapılarında ele alınan hedefleri ve ilkeleri ele almak için iş yükünün tasarımında Parçalama deseninin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin her bir sütunun hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.

Ana Direk	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün hatalı çalışmaya dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma geldiğinden emin olmasına yardımcı olur.	Veriler ve işleme parçaya yalıtılır, bu nedenle bir parçadaki bir arıza o parçaya yalıtılmış olarak kalır. - Veri bölümleme - RE:07 Kendini koruma
Maliyet İyileştirme, iş yükünüzün yatırım getirisinisürdürmeye ve geliştirmeye odaklanır.	Parçalar uygulayan bir sistem genellikle tek bir daha pahalı kaynak yerine daha az maliyetli işlem veya depolama kaynaklarının birden çok örneğini kullanmanın avantajlarından yararlanır. Çoğu durumda, bu yapılandırma size para tasarrufu sağlayabilir. - CO:07 Bileşen maliyetleri
Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar.	Ölçeklendirme stratejinizde parçalama kullandığınızda, veriler ve işleme her parça için yalıtılır, bu nedenle istekler yalnızca atanan parça içindeki kaynaklar için rekabet eder. Coğrafyaya göre iyileştirme yapmak için parçalama özelliğini de kullanabilirsiniz. - PE:05 Ölçeklendirme ve bölümleme - PE:08 Veri performansı

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Example

Dünya çapında yayımlanan kitaplar hakkında geniş bir bilgi koleksiyonunu ortaya çıkaran bir web sitesi düşünün. Bu iş yükünde kataloglanmış olası kitap sayısı ve tipik sorgu ve kullanım desenleri, tek bir ilişkisel veritabanının işleyebileceği değeri aşıyor. İş yükü mimarı, parça anahtarı olarak kitapların statik ISBN'sini kullanarak verileri birden çok veritabanı örneğinde parçalamaya karar verir. Özellikle, mimar ISBN'nin denetim basamasını (0 - 10) kullanır ve bu da oldukça dengeli veri dağılımına sahip 11 olası mantıksal parça sağlar.

Başlangıç olarak, mimar 11 mantıksal parçayı üç fiziksel parça veritabanında birleştirir. Bu sanal bölüm yaklaşımında, birçok mantıksal bölüm daha az fiziksel düğümle eşlenir. Sistem mimarı lookup parçalama yaklaşımını kullanır ve anahtardan sunucuya eşlemeyi parça eşleme veritabanında depolar.

Kitap kataloğu uygulaması için parçalı SQL Veritabanı mimarisini gösteren diyagram.

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çalı erişim

Web sitesi, kaç fiziksel parça veritabanı (bu örnekte üç tane) olduğunu veya bir parça anahtarını bir veritabanı örneğine eşleyen mantığın farkında değildir. Yalnızca bir kitabın ISBN'sinin kontrol rakamının parça anahtarı olduğunu bilir. 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 yetkilendirme için Azure App Service ana bilgisayarının sistem tarafından yönetilen kimliğini kullanır ve bu da gizli dizileri bağlantı dizelerinin dışında tutar.

Web sitesi, bu örnekte gösterildiği gibi bir appsettings.json dosyada veya App Service uygulama ayarları aracılığıyla aşağıdaki bağlantı dizeleriyle 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"
  },
  ...
}

Aşağıdaki kod, web sitesinin iş yükünün veritabanı parça havuzunda nasıl bir güncelleştirme sorgusu çalıştıracaklarını gösterir.

...

// 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);
}

...

Önceki örnek kodda book.Isbn978-8-1130-1024-6 ise isbnCheckDigit olmalıdır. OpenShardConnectionForKeyAsync(6) çağrısı genellikle bir önbellek dışı yaklaşımı kullanılarak uygulanır. Parça anahtarı 6 için önbelleğe alınmış parça bilgileri kullanılamıyorsa, yöntem bağlantı dizesi tarafından ShardMapDb tanımlanan parça eşleme veritabanını sorgular. Bu yöntem, uygulama önbelleğinden veya parça veritabanından bookdbshard2 değerini alır ve bağlantı dizesinde SHARD yerine koyar. Yöntem daha sonra bookdbshard2.database.windows.net için havuza alınmış bir bağlantı kurar veya yeniden kurar, onu açar ve çağıran koda geri iade eder. Kod daha sonra bu veritabanı örneğindeki mevcut kaydı güncelleştirir.

Örnek web sitesi kodu: birden çok shard erişimi

Web sitesinin doğrudan, parçalar arası sorgu gerektirdiği nadir durumlarda uygulama tüm parçalar arasında paralel bir fan-out sorgusu gerçekleştirir.

...

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

// Run 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))
    {
      // Collect the results into a thread-safe data structure.
    }

    reader.Close();
  }
});

...

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

Parçalı örnekler ekleyin

İş yükü ekibi, veri kataloğunun veya eşzamanlı kullanımının önemli ölçüde artması durumunda üçten fazla veritabanı örneği gerektirebileceğini bilir. İş yükü takımı veritabanı sunucularını dinamik olarak eklemeyi beklemez ve yeni bir parça çevrimiçi olduğunda iş yükü kesintisini kabul ederler. Yeni bir parça örneğini çevrimiçi yapmak için mevcut parçalardan yeni parçaya veri taşıması ve parça eşleme tablosunu güncelleştirmeleri gerekir. Bu oldukça statik yaklaşımla iş yükü, parça anahtarı veritabanı eşlemesini web sitesi kodunda güvenle önbelleğe alabilir.

Bu örnekteki parça anahtarı mantığının üst sınırı 11 fiziksel parçadır. İş yükü ekibi, yük tahmini yoluyla sonunda 11'den fazla veritabanı örneğine ihtiyaç duyulduğunu belirlerse, parça anahtarı mantığında invaziv bir değişiklik yapmaları 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

Parça yönetimi ve SQL Veritabanı örneklerine 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ım

Azure Cosmos DB'deki tutarlılık düzeyleri: Verileri parçalar arasında dağıtmak tutarlılık dengelerini sağlar. Bu makalede güçlüden nihaie kadar tutarlılık modellerinin spektrumu ve bunların kullanılabilirlik ve gecikme süresi üzerindeki etkileri açıklanmaktadır.

Yatay, dikey ve işlevsel veri bölümleme: Bu makalede, ölçeklenebilirliği geliştirmek, çekişmesini azaltmak ve performansı iyileştirmek için verileri bulutta bölümlemeye yönelik diğer stratejiler açıklanmaktadır.
Dizin Tablosu düzeni: Bazen yalnızca parça anahtarının tasarımı aracılığıyla tüm sorguları destekleyemezsiniz. Bir uygulama, parça anahtarı dışında bir anahtar belirterek büyük bir veri deposundan veri almak için Dizin Tablosu desenini kullanabilir.
Gerçekleştirilmiş Görünüm düzeni: Bazı sorgu işlemlerinin performansını korumak için, özellikle bu verileri parçalar arasında dağıtıyorsanız, verileri toplayan ve özetleyen gerçekleştirilmiş görünümler oluşturabilirsiniz.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-04-03