Aracılığıyla paylaş


Azure SQL Veritabanı ile ölçek genişletme

Şunlar için geçerlidir:Azure SQL Veritabanı

Elastik Veritabanı araçlarını kullanarak Azure SQL Veritabanı veritabanlarının ölçeğini kolayca genişletebilirsiniz. Bu araçlar ve özellikler, işlem iş yükleri ve özellikle Hizmet Olarak Yazılım (SaaS) uygulamaları için çözümler oluşturmak üzere Azure SQL Veritabanı veritabanı kaynaklarını kullanmanıza olanak tanır. Elastik Veritabanı özellikleri şunlardan oluşur:

Aşağıdaki grafikte, bir veritabanı koleksiyonuyla ilgili Elastik Veritabanı özelliklerini içeren bir mimari gösterilmektedir.

Bu grafikte, veritabanının renkleri şemaları temsil eder. Aynı renge sahip veritabanları aynı şemayı paylaşır.

  1. Parçalama mimarisi kullanılarak Azure'da bir dizi SQL veritabanı barındırılır.
  2. Elastik Veritabanı istemci kitaplığı, bir parça kümesini yönetmek için kullanılır.
  3. Veritabanlarının bir alt kümesi elastik havuza alınır.
  4. Elastik Veritabanı işi tüm veritabanlarında T-SQL betikleri çalıştırır.
  5. Böl ve birleştir aracı, verileri bir parçadan diğerine taşımak için kullanılır.
  6. Elastik Veritabanı sorgusu, parça kümesindeki tüm veritabanlarını kapsayan bir sorgu yazmanızı sağlar.
  7. Esnek işlemler , çeşitli veritabanlarına yayılan işlemleri çalıştırmanıza olanak sağlar.

Elastik veritabanı araçlarının diyagramı.

Araçları neden kullanmalısınız?

Bulut uygulamaları için esneklik ve ölçek elde etmek, VM'ler ve blob depolama için basittir. Yalnızca birim ekleyin veya çıkarın ya da gücü artırın. Ancak, ilişkisel veritabanlarında durum bilgisi olan veri işlemesi için bir zorluk olmaya devam etti. Bu senaryolarda zorluklar ortaya çıktı:

  • İş yükünüzün ilişkisel veritabanı bölümü için kapasiteyi büyütme ve küçültme.
  • Meşgul bir son müşteri (kiracı) gibi belirli bir veri alt kümesini etkileyen ortaya çıkabilecek etkin noktaları yönetme.

Geleneksel olarak, bu gibi senaryolar uygulamayı desteklemek için daha büyük ölçekli sunuculara yatırım yaparak ele alınmıştır. Ancak bu seçenek, tüm işlemlerin önceden tanımlanmış emtia donanımında gerçekleştiği bulutta sınırlıdır. Bunun yerine, verileri ve işlemeyi aynı yapılandırılmış veritabanlarına dağıtmak ("parçalama" olarak bilinen bir ölçek genişletme deseni), hem maliyet hem de esneklik açısından geleneksel ölçek artırma yaklaşımlarına alternatif sağlar.

Yatay ve dikey ölçeklendirme

Aşağıdaki şekilde, esnek veritabanlarının ölçeklendirilebileceği temel yöntemler olan ölçeklendirmenin yatay ve dikey boyutları gösterilmektedir.

Yatay ve dikey ölçeği genişletme karşılaştırmasını açıklayan diyagram.

Yatay ölçeklendirme, "ölçeği genişletme" olarak da adlandırılan kapasiteyi veya genel performansı ayarlamak için veritabanlarını eklemeyi veya kaldırmayı ifade eder. Verilerin aynı yapılandırılmış veritabanları koleksiyonunda bölümlendiği parçalama, yatay ölçeklendirmeyi uygulamanın yaygın bir yoludur.

Dikey ölçeklendirme, "yukarı ölçeklendirme" olarak da bilinen, tek bir veritabanının işleme kaynaklarını artırmayı veya azaltmayı ifade eder.

Bulut ölçeğindeki veritabanı uygulamalarının çoğu bu iki stratejinin bir bileşimini kullanır. Örneğin, Hizmet Olarak Yazılım (SaaS) uygulaması, yeni son müşteriler sağlamak için yatay ölçeklendirme ve her bir son müşterinin veritabanının iş yüküne göre kaynakları büyütmesine veya küçültmesine olanak tanımak için dikey ölçeklendirme kullanabilir.

  • Yatay ölçeklendirme, Elastik Veritabanı istemci kitaplığı kullanılarak yönetilir.
  • Dikey ölçeklendirme, hizmet katmanını değiştirmek için Azure PowerShell cmdlet'leri kullanılarak veya veritabanlarını elastik havuza yerleştirerek gerçekleştirilir.

Sharding (Veri tabanı parçalaması)

Parçalama , büyük miktarlarda aynı yapılandırılmış verileri birçok bağımsız veritabanına dağıtmaya yönelik bir tekniktir. Bulut geliştiricilerinin son müşteriler veya işletmeler için Hizmet Olarak Yazılım (SAAS) teklifleri oluşturması özellikle popülerdir. Bu son müşteriler genellikle "kiracılar" olarak adlandırılır. Parçalama, çeşitli nedenlerle gerekli olabilir:

  • Toplam veri miktarı tek bir veritabanının kısıtlamalarına sığmayacak kadar büyük
  • Genel iş yükünün işlem aktarım hızı tek bir veritabanının özelliklerini aşıyor
  • Kiracılar birbirinden fiziksel yalıtım gerektirebilir, bu nedenle her kiracı için ayrı veritabanları gerekir
  • Uyumluluk, performans veya jeopolitik nedenlerle veritabanının farklı bölümlerinin farklı coğrafyalarda bulunması gerekebilir.

Dağıtılmış cihazlardan veri alımı gibi diğer senaryolarda parçalama, zamansal olarak düzenlenmiş bir veritabanı kümesini doldurmak için kullanılabilir. Örneğin, her gün veya haftaya ayrı bir veritabanı ayrılabilir. Bu durumda, parçalama anahtarı tarihi temsil eden bir tamsayı olabilir (parçalanmış tabloların tüm satırlarında bulunur) ve bir tarih aralığı için bilgi alan sorguların uygulama tarafından söz konusu aralığı kapsayan veritabanlarının alt kümesine yönlendirilmesi gerekir.

Parçalama, bir uygulamadaki her işlem tek bir parçalama anahtarı değeriyle sınırlanabilirken en iyi sonucu verir. Bu, tüm işlemlerin belirli bir veritabanında yerel olmasını sağlar.

Çok kiracılı ve tek kiracılı

Bazı uygulamalar, her kiracı için ayrı bir veritabanı oluşturmanın en basit yaklaşımını kullanır. Bu yaklaşım, kiracı düzeyinde yalıtım, yedekleme/geri yükleme özelliği ve kaynak ölçeklendirme sağlayan tek kiracı parçalama desenidir. Tek kiracılı parçalamada, her veritabanı belirli bir kiracı kimliği değeriyle (veya müşteri anahtarı değeriyle) ilişkilendirilir, ancak bu anahtarın verilerin kendisinde mevcut olması gerekmez. Her isteği uygun veritabanına yönlendirmek uygulamanın sorumluluğundadır ve istemci kitaplığı bu görevi basitleştirebilir.

Tek kiracı ile çok kiracılı karşılaştırma diyagramı.

Diğer senaryolarda, birden çok kiracı ayrı veritabanlarında yalıtmak yerine, aynı veritabanlarında toplanmaktadır. Bu desen tipik bir çok kiracılı parçalama düzenidir ve bir uygulamanın çok sayıda küçük kiracıyı yönetmesi ile yönlendirilebilir. Çok kiracılı parçalamada, veritabanı tablolarındaki satırların tümü kiracı kimliğini veya parçalama anahtarını tanımlayan bir anahtar taşıyacak şekilde tasarlanmıştır. Yine uygulama katmanı, kiracının isteğini uygun veritabanına yönlendirmeden sorumludur ve bu, elastik veritabanı istemci kitaplığı tarafından desteklenebilir. Ayrıca, her kiracının erişebileceği satırları filtrelemek için satır düzeyi güvenlik kullanılabilir. Veritabanları arasında verilerin yeniden dağıtılması, çok kiracılı parçalama deseniyle gerekli olabilir ve bu işlem, elastik veritabanı böl ve birleştir aracı tarafından kolaylaştırılır. Elastik havuzları kullanan SaaS uygulamalarına yönelik tasarım desenleri hakkında daha fazla bilgi edinmek için bkz . Çok Kiracılı SaaS veritabanı kiracı desenleri.

Birden çok kiracılı veritabanından tek kiracılı veritabanına veri taşıma

SaaS uygulaması oluştururken, potansiyel müşterilere yazılımın deneme sürümünü sunmak tipik bir durumdur. Bu durumda, veriler için çok kiracılı bir veritabanı kullanmak uygun maliyetlidir. Ancak, bir müşteri adayı müşteri olduğunda, tek kiracılı veritabanı daha iyi performans sağladığından tercih edilir. Müşteri deneme süresi boyunca veri oluşturursa, verileri çok kiracılı veritabanından yeni tek kiracılı veritabanına taşımak için bölünmüş birleştirme aracını kullanın.

Not

Çok kiracılı veritabanlarından tek bir kiracıya geri yükleme mümkün değildir.

Örnekler ve öğreticiler

İstemci kitaplığını gösteren bir örnek uygulama için, Elastik Veritabanı araçlarını kullanmaya başlama bölümüne bakın.

Mevcut veritabanlarını araçları kullanacak şekilde dönüştürmek için bkz Mevcut veritabanlarını ölçek büyütmek için geçirme.

Elastik havuzun ayrıntılarını görmek için Elastik havuz için fiyat ve performans değerlendirmeleri başlıklı makaleye bakın veya elastik havuzlarla yeni bir havuz oluşturun.

Elastik veritabanı araçlarını henüz kullanmıyor musunuz? Başlarken Kılavuzumuza göz atın. Sorular için, SQL Veritabanı ve özellik istekleri için Microsoft Soru-Cevap soru sayfasından bizimle iletişime geçin, yeni fikirler ekleyin veya SQL Veritabanı geri bildirim forumunda mevcut fikirler için oy verin.