SQL Server 2016, Shard içeren çok kiracılı bir sistem mi yoksa kiracı başına ayrı veritabanı üzerinden Kiracı izolasyonu mu olmalı?


12

Kullanım durumu göz önüne alındığında:

  • Kiracı verileri çapraz konuşmamalı, bir kiracının başka bir kiracının verilerine ihtiyacı yoktur.
  • Her kiracı potansiyel olarak büyük geçmiş veri hacmine sahip olabilir.
  • SQL Server, AWS EC2 yönetim ortamında barındırılmaktadır.
  • Her kiracı coğrafi olarak uzaktır.
  • PowerBI Embedded gibi üçüncü taraf görselleştirme araçlarını kullanma niyeti vardır
  • Veri hacminin zaman içinde artması bekleniyor
  • Sistemin maliyeti sınırlıdır.
  • Çözüm, 7/24 üretim DBA'sı olmadan sürdürülebilir olmalıdır
  • Çözelti yatay olarak ölçeklenebilmelidir.
  • Toplam kiracı sayısı 50'den az

Tavsiye edilen mimari ne olurdu, bu kullanım durumu için referans uygulamaları var mı? Birçok kişinin kurumsal yazılım geliştirme için zaten bu sorunla karşılaşmış olabileceğine inanıyorum.

Bence bu, Çok Kiracılı Veritabanı Mimarisinde artan Kiracıların ele alınmasından farklı bir durum . Bu soruda adı geçen kullanım vakası, çok az (50) büyük kiracıya sahip olmaktan çok farklı olan daha fazla sayıda kiracı ile ilgilidir. Bahsedilen mimari, burada daha fazla bilgi edinmek istediğim bir çözüm olabilir.

Yanıtlar:


16

Kırma ile gotcha uygulama sorgulamak için hangi kırığı bilmek zorunda olmasıdır. Genellikle, bu müşteri gibi bir şey üzerinde parçalanarak yapılır. Cevabım olarak kullanmak için eski blog yayınlarımdan birini uyarlayacağım .

Çok sayıda istemci için bir uygulama oluştururken, veritabanlarını tasarlamanın iki yaygın yolu vardır:

  • Seçenek A: Tüm istemcileri aynı veritabanına koyun
  • 2. Seçenek: İstemci başına bir veritabanı oluşturun

Tüm İstemcileri Aynı Veritabanına Yerleştirme

Çok basit: şemanın üst kısmına bir İstemci tablosu eklemeniz, insanların yalnızca kendi verilerini görmesini sağlamak için bir ClientUsers tablosu eklemeniz yeterlidir.

Bu yaklaşımın faydaları:

Daha kolay şema yönetimi. Geliştiriciler uygulamanın yeni bir sürümünü dağıttığında, yalnızca bir veritabanında şema değişiklikleri yapmak zorundadırlar. Farklı müşterilerin senkronize olmamaları veya yanlış sürümde olmaları konusunda endişe yoktur.

Daha kolay performans ayarı. Dizin kullanımını ve istatistikleri tek bir yerde kontrol edebilir, kolayca iyileştirmeler yapabilir ve tüm müşterilerimiz üzerindeki etkileri anında görebiliriz. Yüzlerce veya binlerce veritabanında, en küçük değişikliğin bile koordinasyonu zor olabilir. Yordam önbellek içeriğimizi kontrol edebilir ve tüm uygulamanızda hangi sorguların veya saklı yordamların en yoğun olduğunu belirleyebiliriz, ancak istemci başına ayrı veritabanları kullanırsak, farklı yürütme planlarında sorgu kullanımını daha zorlaştırabiliriz.

Harici bir API oluşturmak daha kolaydır. Dışarıdan gelenlerin ürün geliştirmesi için tüm veritabanımıza erişim izni vermemiz gerekiyorsa, tüm veriler tek bir veritabanındaysa bunu daha kolay yapabiliriz. API, birden çok sunucudaki birden çok veritabanındaki verileri gruplandırmakla ilgileniyorsa, geliştirme ve test süresi ekler. (Öte yandan, bu “birden çok sunucu” olayı, bir veritabanı-kural-hepsi-hepsi senaryosu için bir kısıtlamaya işaret etmeye başlar: bir veritabanı genellikle tüm yükümüzün yalnızca bir veritabanı sunucusunu etkilediği anlamına gelir.) , PowerBI ile herkesin tek bir veritabanında bulunması bağlantıları yönetmeyi çok daha kolay hale getirir.

Daha kolay kullanılabilirlik ve olağanüstü durum kurtarma. Endişelenecek tek şey sadece bir veritabanı ise, veritabanı yansıtma, günlük sevkiyatı, çoğaltma ve kümelemeyi yönetmek gerçekten, gerçekten basittir. Hızlı bir şekilde bir altyapı inşa edebiliriz.

Her İstemciyi Kendi Veritabanına veya Kırığına Yerleştirme

Hala bir müşteri listesine ihtiyacınız var, ancak şimdi bir dizin haline geliyor - her müşteri için, içinde yaşadığı parçayı da izliyorsunuz. Başlangıçta, uygulamanız bu tabloyu sorgular ve RAM'de önbelleğe alır. Bir istemci için verilere ihtiyaç duyduğunda, doğrudan bu parçaya (veritabanı ve sunucu) bağlanır.

Bu yaklaşımın faydaları:

Daha kolay tek istemci geri yüklenir. Müşteriler güvenilir olmayan et torbasıdır. (Benimkiler dışında - güvenilir et torbaları.) Tüm verilerini zaman içinde bir noktaya geri getirmek istedikleri her türlü “oops” anları var ve verileri karışmışsa arkada büyük bir acı var aynı tablodaki diğer istemci verileri. Tek bir istemci-veritabanı senaryosunda geri yükleme beyin ölü kolaydır: sadece istemcinin veritabanını geri yükleyin. Başka hiç kimse etkilenmez.

Daha kolay veri aktarımı. Müşteriler verilerini ellerinden almaya bayılırlar. Korkunç satıcı kilitleme senaryosundan kaçınarak verilerini istedikleri zaman çıkarabileceklerini bilmenin güvenliğini istiyorlar ve kendi raporlarını yapmak istiyorlar. Her müşterinin verileri kendi veritabanında izole edildiğinde, onlara kendi veritabanı yedeklerinin bir kopyasını verebiliriz. Veri dışa aktarma API'leri oluşturmak zorunda değiliz.

Daha kolay çoklu sunucu ölçeklenebilirliği. Uygulamamız tek bir sunucudan alabileceğimizden daha fazla güce ihtiyaç duyduğunda, veritabanlarını birden çok sunucu arasında bölebiliriz. Ayrıca yükü coğrafi olarak yayarak Asya ya da Avrupa'daki sunucuları müşterilere daha yakın hale getirebiliriz.

Müşteri başına daha kolay performans ayarı. Bazı istemciler farklı özellikler veya raporlar kullanıyorsa, herkesin veri boyutunu büyütmeden yalnızca bu istemciler için özel bir dizi dizin veya dizine alınmış görünüm oluşturabiliriz. Burada bazı riskler var - müşteriler arasındaki şema farklılıklarına izin vererek, kod dağıtımlarımızı biraz daha riskli hale getirdik ve performans yönetimimizi daha da zorlaştırdık.

Daha kolay güvenlik yönetimi. Güvenliği veritabanı başına bir kullanıcıyla düzgün bir şekilde kilitlediğimiz sürece, İstemci X'in İstemci Y'nin verilerine erişmesi konusunda endişelenmemize gerek yoktur. Ancak, herkes için tek bir giriş kullanırsak, bu endişeye gerçekten değinmedik.

Daha kolay bakım pencereleri. Müşterilerin dünyanın dört bir yanına dağıldığı küresel bir ortamda, gruplar veya bölgeler halinde yapabilirsek, müşterileri bakım için çevrimdışına almak daha kolaydır.

Hangisi sizin için uygun?

Doğru seçim yok: kendi şirketinizin güçlü ve zayıf yanlarını bilmelisiniz. Örnek olarak iki müşterimi ele alalım.

A Şirketi donanım performans ayarında mükemmeldir. Gerçekten, donanımın son parçasını bitirmek konusunda gerçekten çok iyi ve SQL Server donanımlarını 12-18 aylık bir döngüde değiştirmenin bir sakıncası yok. (Web sunucularını her 4-6 ayda bir yeniler!) Aşil topuğu aşırı uyum ve güvenlik gereksinimleridir. İnanılmaz denetim ihtiyaçları var ve onlar için kurşun geçirmez kontrolleri tek bir sunucuda, tek bir veritabanında uygulamak onlarca sunucudaki binlerce veritabanında bu gereksinimleri yönetmekten daha kolaydır. Bir veritabanı, bir sunucu, birçok istemci seçtiler.

Şirket 2 geliştirme uygulamalarında mükemmeldir. Binlerce veritabanında şema değişikliklerini ve kod dağıtımlarını yönetmek onlar için sorun değil. Dünyanın dört bir yanında müşterileri var ve bu müşteriler için 24 saat kredi kartı işlemleri yapıyorlar. Yükü coğrafi olarak dağıtma yeteneğine ihtiyaç duyarlar ve dünyadaki sunucuları her 12-18 ayda bir değiştirmek istemezler. Her müşteri için bir veritabanı seçtiler ve denizaşırı müşterileri için Asya ve Avrupa'daki SQL Server'ları kullanmaya başladıklarında işe yaradı.


"Sizin durumunuzda, PowerBI ile herkesin tek bir veritabanında bulunması bağlantıları yönetmeyi çok daha kolay hale getirecektir". Şu anda PowerBI Embedded, Satır Düzeyi güvenliğine sahip değildir ve bu nedenle her kiracıyı bir veritabanında bulundurmak bu kullanım durumu hakkında bazı şüphelere neden olmaktadır, bkz: community.powerbi.com/t5/Developer/… , bu bilgilerin ışığında lütfen yeniden ifade edebilir misiniz? bu bir alternatif mi yoksa anlayışımı düzeltmek mi?
DS

Ayrıca, "Her İstemciyi Kendi Veritabanına veya Parçacığına Koymak", bu iki öneri arasındaki farkı inceleyebilir misiniz
DS

Sadece birden fazla veritabanına konuşlandırmanın sesinizi duyurmak kadar kötü olmadığını söyleyeceğim. 2017'de, 1, 5 veya 900 veritabanına değişiklikleri dağıtmayı çok kolaylaştıran birçok seçeneğimiz var. Belirli müşteriler için istisnalarınız olduğunda, bunlar genellikle bu veritabanlarına ortak koda müdahale etmeyecek şekilde tanıtılabilir.
Aaron Bertrand

5

Başka bir cevap daha başka cevaplarda görmedim.

Tek bir veritabanında birçok kiracıya izin veren bir tasarıma sahip olmak daha sonra esneklik sağlayacaktır. Yükleme / ölçeklendirme / güvenlik / coğrafi konum talepleri daha sonra bir kiracı ayrı bir veritabanına sahip olmalıdır, yeni örnekte currect DB geri yüklenerek oluşturulabilir. Diğer kiracıların verileri, mevcut mekanizmalar tarafından korunmaktadır. Artık kullanılmayan veriler, parçaların izin verdiği ölçüde hem eski hem de yeni veritabanlarından parça parça çıkarılabilir.

Tersi doğru değil. Birçok kiracı veritabanını birleştirmek çok daha fazla çalışma gerektirecektir.


4

Normalleştirmeyi * kırsa bile çok kiracılı modelleri çok daha kolay hale getiren bir uygulama, kiracı için her masaya bir sütun eklemektir. Buna TenantID diyebilirsiniz. Bu şekilde, veritabanına karşı çalıştırılan her sorgu, her tabloda TenantID üzerinde filtre uygulayabilir ve her bir kiracı için verileri izole etmek ve hizalanmış bölümlere sahip sorguları hızlandırmak için veritabanı bölümlemesini kullanabilirsiniz. Tüm kiracıların tek bir veritabanında bu şekilde bulunması çok daha kolay.

* Her zaman normalleşmeyi bozmaz, ama çözebilir. Örneğin, bir Personve PersonAddresstablonuz varsa. PersonTablo olacak TenantID, PersonIDbirincil anahtar olarak. PersonAddressTablo olacak TenantID, PersonID, AddressTypeIDben öneriyorum ne birincil anahtar olarak.

Normalde PersonIDyeterli olur, çünkü bunu Personbulmak için masaya geri katılabilirsin Tenant. Daha TenantIDince bir anahtar çalışsa bile, sonraki her tabloya ilerlemenizi öneririm.

Anladığım kadarıyla, diğer verilerden türetilebilecek herhangi bir bilgiyi bir tabloya iletmenin normalleşmeyi kırma olarak kabul edildiğini düşünüyorum. Ancak belki de ince tuşlar kullanmak sadece en iyi uygulamadır.


Teşekkürler, öneriye katılıyorum ve üstüne eklemek için, bu alanın TenantID'in bir GUID değil tamsayı türü olması gerektiğini belirtmek isterim, performans için bu şekilde yakıldık.
DS

3
Ancak, TenantID'i yapmak zorunda olmadığınız alt tablolara taşımayı seçseniz bile, daha geniş bir anahtar normalleşmenin "bozulduğu" anlamına gelmez. KİMLİK üzerinde bir GUID (daha geniş bir anahtar) seçmek normalleşmeyi bozmaz ve vekil kullanmak yerine daha geniş bir doğal anahtar seçmek gibi.
Aaron Bertrand
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.