Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Azure Veri Gezgini'da çok kiracılılık kavramı, farklı kiracılara hizmet vermek ve verilerini tek bir kümede depolamak anlamına gelir.
Important
Çok kiracılı bir çözüm, Eventhouse içindeki KQL veritabanları kullanılarak Microsoft Fabric Real-Time Intelligence iş yükünde de tasarlanabilir.
Kiracı bir müşteriyi, bir kullanıcı grubunu veya verilerin kiracı sınırları boyunca ayrılması gereken kullanıcı sınıflandırmalarını temsil edebilir. Her birine birden çok kiracıya sahip birden fazla uygulama gibi, çok katmanlı, çok kiracılı bir senaryonuz da olabilir. Bu makalede bu senaryo ele alınmıyor ancak benzer ilkeler geçerli.
Önemli bir faktör, son kullanıcıların kiracı verilerine erişme şeklidir. Son kullanıcılar Azure Veri Gezgini'ne doğrudan eriştiklerinde, kullanıcının görünümünü kendi verilerine yalıtmak için erişim denetiminin Azure Veri Gezgini'nde yapılandırılması gereklidir. Bir ara sunucu uygulaması Azure Veri Gezgini'daki verilerine eriştiğinde, yalıtım gerçekleştirebilir.
Bu makalede bazı dağıtım mimarileri açıklanır ve her birine yönelik özellikler sağlanır. Hangi mimarinin çözümünüz için en uygun olduğunu belirlemenize yardımcı olması için özelliklerini kullanabilirsiniz.
Gürültülü komşu
Genel olarak, kullanılan mimariden bağımsız olarak bir kümeyi birçok kiracı arasında paylaşmak, farklı kiracıların kümenin kaynaklarını paylaştığı anlamına gelir. Bu, gürültülü komşu kötü modeline yol açabilir.
Örneğin, bir kiracı çok fazla işlem yoğunluklu sorgu veya yükleme gerçekleştiriyorsa, diğer kiracılar büyük olasılıkla kaynak açlığı nedeniyle etkilenecektir. Bu, iş yükü grupları kullanılarak azaltılabilir. Önbelleğe alma ve genel depolamayı denetlemek için ilkeleri de kullanabilirsiniz.
Mimarilere genel bakış
Sonraki bölümlerde dağıtım mimarileri ayrıntılı olarak incelenmektedir. Bu bölümde karar almayı kolaylaştırmak için mimariler karşılaştırılır.
| Architecture | Strengths |
|---|---|
| Veritabanı başına bir kiracı | - Kiracıların yalıtımı: ara sunucu gerekmez - Kiracı başına saklama politikaları gibi farklı ilkelere sahip olabilir. - Kiracı başına şema evriminde esneklik - Kiracı verilerinin kolay ve hızlı bir şekilde kaldırılması |
| Birçok kiracı için bir tablo | - Verimli veri birleştirme ve kapsam yönetimi - Basitleştirilmiş şema evrimi - Gerçekleştirilmiş görünümler için en uygun - Bölümleme için idealdir |
| Tek bir veritabanında tablo başına bir kiracı | Önerilmez |
Mimari: Veritabanı başına bir kiracı
Bu yaygın ve basit bir mimaridir. Her kiracı kendi veritabanına sahip olur. Her veritabanı aynı şemaya sahiptir.
Bu mimarinin özellikleri şunlardır:
Yeni bir kiracı sağlama: Yeni bir veritabanı oluşturulmasını ve üzerinde şema varlıklarının dağıtılması gerekir.
Kiracıyı kaldırma: Veritabanını silmeyi gerektirir. Veritabanını silme işlemi birkaç saniye içinde gerçekleştirilebilir. Kiracının veri hacmiyle doğrusal olmayan çok az ve sabit kaynak kullanır.
Veritabanı şemaları güncellemeleri: Her kiracı, farklı zamanlarda bağımsız güncellenebilir. Veritabanlarına erişen uygulamalar, etkileşimde bulundukları her veritabanının sürümünün farkında olmalıdır.
Bekletme ve önbelleğe alma ilkeleri: Her kiracının, müşterilerinize özel saklama ve önbelleğe alma ilkeleri sağlamanıza olanak tanıyan kendi benzersiz ilkeleri olabilir.
Kiracı başına güvenlik sınırı:
- Çok kiracılı uygulama (ara sunucu) için: Uygulamanızı ilgili veritabanını hedef olacak şekilde yapılandırın. Veritabanları arası sorguları yasaklama amacıyla sorgularda erişim kısıtlamasını kullanın.
- Doğrudan erişimi olan kullanıcılar için: Kullanıcılara veritabanı düzeyinde erişim verilebilir. Kullanıcılara veritabanlarına doğrudan erişim vermek, uygulama ayrıntıları için bir bağımlılık oluşturarak uygulamanın değiştirilmesini zorlaştırır. Bu nedenle, veritabanına erişmek için proxy yaklaşımını kullanmanızı kesinlikle öneririz.
Büyük ölçekte birden çok kiracıdan veri toplama: Veritabanları arasındaki verileri toplamak için birleşim işlecini kullanın. Ancak, kiracı sayısı arttıkça bu yöntem hantal hale gelebilir. Birden çok kiracıdan veri toplama, kiracının perspektifinden bir tasarım hedefi olsa da, çözüm sahibinin istatistikleri toplamak için tüm kiracılardan veri toplaması ilgi çekici olabilir.
Kapsam parçalanması: Veritabanı tablosu başına birkaç kayıt alan her kiracı, daha sonra birleştirilmesi gereken küçük uzantıların oluşturulmasına yol açar. Bu, kapsam yönetimi için daha yüksek maliyete neden olur. Bu nedenle, akış işlemesi gibi Event Hubs veya Event Grid işlemesinin kullanılmasını kesinlikle öneririz. Akış ile veri alımını kullanmak için, küme ve tablodaki işlevselliğinin etkinleştirildiğinden emin olmanız gerekir.
Gerçekleştirilmiş görünümler ve bölümleme ilkesi. Kiracı sayısı arttıkça, bir kümenin verimli bir şekilde çalıştırabileceği gerçekleştirilmiş görünümler ve bölüm ilkeleri sayısının sınırları olduğunu unutmayın.
Event Grid ve Event Hubs veri bağlantıları: Bu veri bağlantıları veritabanı başına oluşturulur. Bu nedenle, bu mimari için kiracı başına bir veri bağlantısı ve Event Grid veya Event Hubs örneği gerekir ve bu da yönetim karmaşıklığını artırır. Event Hubs ve Event Grid için olay yönlendirmeyi kullanmayı göz önünde bulundurun.
Mimari: Çoklu kira sahipleri için tek bir tablo
Bu mimari, tüm kiracılar için tek bir veritabanı kullanarak birleştirmede daha agresiftir. Veritabanındaki her tablonun, tek bir kiracının verilerini filtrelemeye olanak tanıyan bir Kiracı Kimliği sütunu veya eşdeğeri vardır. Sorgu performansını geliştirmek için tabloları kiracıya göre bölümleyebilirsiniz, çünkü sorguların çoğu kiracıya göre filtreleyebilir. Mümkün olduğunda, herhangi bir bileşik anahtarı kullanarak başka bir sütunla bölümlendirme yapmayı göz önünde bulundurmalısınız. Örneğin, kiracı kimliği ve başka bir sütunun değerlerini birleştirerek bileşik bir bölüm anahtarı oluşturabilirsiniz.
Bu mimarinin özellikleri şunlardır:
Yeni kiracı sağlama: Yeni bir kiracı sağlamak için veritabanı oluşturma veya şema ayarlaması gerekmez. Yeni kiracı kimliği yeni kayıtlarda kullanılır.
Kiracıyı kaldırma: Kiracı verilerini geçici silme veya temizleme gerektirir. Kaynak tüketimi üzerindeki etkiyi sınırlamak için birden çok temizleme işlemini birlikte, örneğin hafta sonunda toplu olarak yapabilirsiniz.
Veritabanı şemaları güncelleştirmeleri: Tüm kiracıların şeması aynı anda yükseltilir. Tüm kiracılar tabloyu paylaştığından, tablo şemalarının değiştirilmesi tüm kiracıları aynı anda değiştirir.
Bekletme ve önbelleğe alma ilkeleri: İlkeler tüm kiracılar için aynıdır çünkü hepsi aynı tabloyu paylaşır.
Kiracı başına güvenlik sınırı:
- Çok kiracılı uygulama (proxy) için: Restrict deyimini kullanın
- Doğrudan erişimi olan kullanıcılar için: Satır Düzeyi Güvenlik İlkesi'ni kullanın ve sınırlamaları hakkında bilgi sahibi olun. Kullanıcılara veritabanlarına doğrudan erişim vermek, uygulama ayrıntıları için bir bağımlılık oluşturarak uygulamanın değiştirilmesini zorlaştırır. Bu nedenle, veritabanına erişmek için proxy yaklaşımını kullanmanızı kesinlikle öneririz.
Büyük ölçekte birden çok kiracıdan veri toplama: Yeterli erişim izinlerine sahip kullanıcılar, birden çok kiracının verileri üzerinde standart bir toplama sorgusu çalıştırabilir.
Uzantıların parçalanması: Tüm kiracılar verileri aynı tabloya aldığı için, veriler genellikle bir veya birkaç uzantıda birleştirilebilir ve verimli bir şekilde alınabilir.
Gerçekleştirilmiş görünümler ve bölümleme ilkesi: Bunlar çok kiracılı tabloda kullanılabilir. Kiracı Kimliği veya eşdeğer bir sütuna bölümleyerek performansı artırabilirsiniz. Daha fazla bilgi için Bölümleme ilkeleri ile ilgili senaryolar bölümüne bakın.
Event Grid ve Event Hubs veri bağlantıları: Tüm kiracıların verileri tek bir tabloda sonlandığı için veri bağlantılarını birleştirmişsinizdir.
Mimari: Tek bir veritabanında tablo başına bir kiracı
Bu mimari, tüm kiracıların verilerinin tek bir veritabanında ancak ayrı tablolarda sona erdiği önceki mimarilerin bir bileşimidir. Bu mimari, diğer mimarilerin tüm avantajlarını yakalayamıyor.
Her kiracının verileri ayrılmış olsa da, hepsi aynı veritabanının aynı güvenlik bağlamında bulunur. Çok veritabanılı mimaride olduğu gibi bu mimari de büyük ölçüde parçalanmalara yol açabilir. Tablo adı her kiracı için farklıdır ve bu nedenle sorguların her kiracı için özelleştirilmesi gerekir.