Paylaşılan tablo yapılarına sahip çok kiracılı bir veritabanı nasıl oluşturulur?


129

Yazılımımız şu anda MySQL üzerinde çalışıyor. Tüm kiracıların verileri aynı şemada saklanır. Ruby on Rails kullandığımız için hangi verinin hangi kiracıya ait olduğunu kolayca belirleyebiliyoruz. Ancak elbette verilerinin tehlikeye girebileceğinden korkan bazı şirketler var, bu yüzden başka çözümleri değerlendiriyoruz.

Şimdiye kadar üç seçenek gördüm:

  • Çoklu Veritabanı (her kiracı kendine ait olur - neredeyse müşteri başına 1 sunucu ile aynıdır)
  • Çoklu Şema (MySQL'de mevcut değildir, her kiracı paylaşılan bir veritabanında kendi şemasını alır)
  • Paylaşılan Şema (mevcut yaklaşımımız, belki her sütunda ek tanımlama kaydı ile)

Multi-Schema benim favorim (maliyetler dikkate alınarak). Bununla birlikte, yeni bir hesap oluşturmak ve geçiş yapmak oldukça zahmetli görünüyor, çünkü tüm şemaları yinelemem ve tablolarını / sütunlarını / tanımlarını değiştirmem gerekiyor.

S: Multi-Schema, her kiracı için biraz farklı tablolara sahip olacak şekilde tasarlanmış gibi görünüyor - bunu istemiyorum. Tablo yapısının tüm kiracılar arasında paylaşıldığı çok şemalı çok kiracılı bir çözüm kullanmama izin veren herhangi bir RDBMS var mı?

PS Multi ile ultra-multi (10.000'den fazla kiracı) gibi bir şeyi kastediyorum.


1
"Çoklu Şema, her kiracı için biraz farklı tablolara sahip olacak şekilde tasarlanmış gibi görünüyor" Peki? Çoklu şema ve aynı tabloların nesi var? Tüm şemada aynı tablo yapılarını yeniden oluşturmak istemediğinizi mi söylüyorsunuz? Yoksa tüm şemalarda aynı yapıları oluşturamayacağınızı mı söylüyorsunuz?
S.Lott

İyi / ilginç soru için +1
AdaTheDev

2
@ S.Lott Günde 100'den fazla kayıt olan 10.000'den fazla kiracı bekliyorum. Tek bir tablo tanımında (tanım = paylaşılan, veri = yalıtılmış) milyonlarca girişe sahip olmak, binlerce tablo tanımında binlerce girişe sahip olmaktan daha iyi hissettiriyor. Pek çok insan bunu bu şekilde yapmadığından, çoklu şemaya pek güvenmiyorum.
Marcel Jackwerth

1
Daniel'e katılıyorum, çoklu veri tabanı bu rakamlara göre hariç tutulmuştur. Cevabımı bunu yansıtacak şekilde güncelledim, ancak bunu tarih için daha fazla sakladım. Paylaşılan yaklaşım kesinlikle en mantıklı yaklaşım gibi görünüyor.
AdaTheDev

2
dan dynjo bir cevap: " Büyük maddesinde kesin konuda Ryan Bigg dan"
Félix Gagnon-Grenier

Yanıtlar:


95

Ancak elbette verilerinin tehlikeye girebileceğinden korkan bazı şirketler var, bu yüzden başka çözümleri değerlendiriyoruz.

Bu talihsiz bir durumdur, çünkü müşteriler bazen yalnızca fiziksel izolasyonun yeterli güvenliği sağlayabileceği yanılgısından muzdariptir.

Çok Kiracılı Veri Mimarisi başlıklı , kontrol etmek isteyebileceğiniz ilginç bir MSDN makalesi var . Yazarlar, paylaşılan yaklaşıma yönelik yanılgıya şu şekilde değindi:

Yaygın bir yanılgı, yalnızca fiziksel izolasyonun uygun bir güvenlik seviyesi sağlayabileceğini savunmaktadır. Aslında, paylaşılan bir yaklaşım kullanılarak depolanan veriler de güçlü veri güvenliği sağlayabilir, ancak daha karmaşık tasarım modellerinin kullanılmasını gerektirir.

Teknik ve ticari konulara gelince, makale belirli bir yaklaşımın nerede diğerinden daha uygun olabileceğine dair kısa bir analiz yapıyor:

Hizmet vermeyi beklediğiniz kiracıların sayısı, yapısı ve ihtiyaçları, veri mimarisi kararınızı farklı şekillerde etkiler. Aşağıdaki sorulardan bazıları sizi daha izole bir yaklaşıma yönlendirebilirken, diğerleri sizi daha ortak bir yaklaşıma yönlendirebilir.

  • Kaç potansiyel kiracı hedeflemeyi bekliyorsunuz? Muhtemel kullanımı otorite ile tahmin etmeye yakın bir yerde olmayabilirsiniz, ancak büyüklük sırasına göre düşünün: yüzlerce kiracı için bir uygulama mı oluşturuyorsunuz? Binlerce? Onbinlerce? Daha? Kiracı tabanınızın ne kadar büyük olmasını beklerseniz, daha ortak bir yaklaşımı değerlendirme olasılığınız o kadar artar.

  • Ortalama bir kiracının verilerinin ne kadar depolama alanı kaplamasını bekliyorsunuz? Kiracıların bazılarının veya tümünün çok büyük miktarda veri depolamasını bekliyorsanız, ayrı veritabanı yaklaşımı muhtemelen en iyisidir. (Aslında, veri depolama gereksinimleri sizi yine de ayrı bir veritabanı modeli benimsemeye zorlayabilir. Öyleyse, uygulamayı baştan bu şekilde tasarlamak, daha sonra ayrı bir veritabanı yaklaşımına geçmekten çok daha kolay olacaktır.)

  • Ortalama bir kiracının kaç eşzamanlı son kullanıcıyı desteklemesini bekliyorsunuz? Sayı ne kadar büyükse, son kullanıcı gereksinimlerini karşılamak için daha izole bir yaklaşım o kadar uygun olacaktır.

  • Kiracı başına yedekleme ve geri yükleme yeteneği gibi kiracı başına katma değerli hizmetler sunmayı bekliyor musunuz? Bu tür hizmetlerin daha izole bir yaklaşımla sunulması daha kolaydır.


GÜNCELLEME: Beklenen kiracı sayısı hakkında daha fazla güncelleme.

Beklenen kiracı sayısı (10.000), senaryoların tümü olmasa da çoğu için çoklu veritabanı yaklaşımını hariç tutmalıdır. 10.000 veritabanı örneğini koruma ve her gün yüzlerce yeni veritabanı oluşturma fikrinden hoşlanacağınızı sanmıyorum.

Yalnızca bu parametreden, paylaşılan veritabanı, tek şema yaklaşımı en uygun olanı gibi görünüyor. Kiracı başına yaklaşık 50Mb depolayacağınız ve kiracı başına eklenti olmayacağı gerçeği, bu yaklaşımı daha da uygun hale getiriyor.

Yukarıda bahsedilen MSDN makalesi, paylaşılan veritabanı yaklaşımı için güvenlik hususlarını ele alan üç güvenlik modelinden bahseder:

Uygulamanızın veri güvenliği önlemlerinden emin olduğunuzda, müşterilerinize güçlü veri güvenliği garantileri sağlayan bir Hizmet Seviyesi Anlaşması sunabilirsiniz . SLA'nızda, garantilerin yanı sıra, verilerin tehlikeye atılmamasını sağlamak için alacağınız önlemleri de tanımlayabilirsiniz.

GÜNCELLEME 2: Görünüşe göre Microsoft çalışanları bu konuyla ilgili yeni bir makale taşıdı / yazdı, orijinal bağlantı gitti ve bu yeni: Çok kiracılı SaaS veritabanı kiralama kalıpları (Shai Kerer'e tebrikler)


1
Oh, o makaleyi dün taradım ve bu yanlış anlama bölümünü atladım. Tekrar okumalıyım.
Marcel Jackwerth

1
@Marcel: Bununla birlikte, müşterilerin güvenlik algısının yanı sıra, hangi çok kiracılı yaklaşımın benimsenmesi gerektiğine dair kararınızın, MSDN makalesinde alıntı yaptığım 4 puan gibi faktörlere dayanması gerektiğine inanıyorum: 1. Beklenen kiracı sayısı . - 2. Her kiracı için beklenen depolama gereksinimi. - 3. Beklenen eşzamanlı son kullanıcı sayısı. - 4. Kiracı başına beklenen eklentiler.
Daniel Vassallo

1
Bu bölümü işaret ettiğiniz için teşekkürler. Sayı = 10k, Depolama = 50mb, Eşzamanlı Son Kullanıcılar = kiracı başına 2, Eklentiler = 0. Bu nedenle, paylaşılan bir yaklaşıma sahip mevcut durum en mantıklı gibi görünüyor. Sanırım önümüzdeki hafta müşterilerin gerçekten neye ihtiyaç duyduğunu / beklediğini öğrenmek için bazı telefon görüşmeleri yapacağım. Almanya ve veri / BT güvenliği gerçekten zor bir hikaye.
Marcel Jackwerth

1
Sadece bundan sonra bunu okuyanlar için, söz konusu makale artık yok, birisi bir kopya yaptı, belki?
gmslzr

1
@guillesalazar Aynı olduğundan emin değilim ama sanırım - docs.microsoft.com/en-us/azure/sql-database/… (@DanielVassallo aynıysa, belki de cevap :-))
Shai Kerer

20

Deneyimim (SQL Server olsa da), her istemcinin kendi veritabanına sahip olduğu çoklu veritabanının gitme yoludur. MySQL veya Ruby On Rails deneyimim olmamasına rağmen, girdimin biraz değer katacağını umuyorum.

Dahil edilmesinin nedenleri:

  1. veri güvenliği / felaket kurtarma. Her şirket verileri diğerlerinden tamamen ayrı olarak depolanır ve verilerin tehlikeye atılma riskini azaltır (bir kod hatası oluşturup, olmaması gerektiği halde yanlışlıkla diğer müşteri verilerine bakması anlamına gelen bir kod hatası ortaya koyarsanız), bir müşterinin potansiyel kaybını en aza indirir. belirli veri tabanı bozulur vb. İstemciye algılanan güvenlik faydaları daha da büyüktür (ilave bonus yan etkisi!)
  2. ölçeklenebilirlik. Esasen, daha fazla ölçeklenebilirlik sağlamak için verilerinizi bölümlere ayırırsınız - örneğin veritabanları farklı disklere yerleştirilebilir, birden fazla veritabanı sunucusunu çevrimiçi duruma getirebilir ve yükü dağıtmak için veritabanlarını daha kolay taşıyabilirsiniz.
  3. performans ayarı. Bir çok büyük ve çok küçük bir müşteriniz olduğunu varsayalım. Kullanım modelleri, veri hacimleri vb. Çılgınca değişiklik gösterebilir. İhtiyaç duyduğunuz her müşteri için daha kolay ayarlama / optimizasyon yapabilirsiniz.

Umarım bu bazı yararlı bilgiler sağlar! Daha fazla neden var ama aklım boştu. Tekrar devreye girerse, güncelleyeceğim :)

DÜZENLEME:
Bu cevabı gönderdiğimden beri, 10.000'den fazla kiracıdan bahsettiğimiz artık açık. Deneyimim yüzlerce büyük ölçekli veritabanında - 10.000 ayrı veritabanının senaryonuz için fazla yönetilebilir olacağını düşünmüyorum, bu yüzden şimdi senaryonuz için çoklu-db yaklaşımını tercih etmiyorum. Özellikle artık her kiracı için küçük veri hacimlerinden bahsettiğiniz artık açık.

Cevabımı, benzer bir teknedeki (daha az kiracı olan) diğer insanlar için bir miktar işe yarayabileceği için burada tutuyorum


Evet, bunu daha önce açıklamadığım için üzgünüm. Hala +1. ;)
Marcel Jackwerth

veri güvenliğinden bahsederken, her bir veritabanının ayrı sunuculara / VM'lere yerleştirilmesi gerektiğini mi söyleyeceksiniz? veya tüm veritabanlarının farklı sql kullanıcıları ile tek / kümelenmiş bir sunucuda olması yeterince güvenli mi?
Shay

@Shay - Hayır, bunları ayrı sunuculara yerleştirmenize gerek yok - 100'ünüz olduğunu hayal edin, bu bir başlangıç ​​için ihtiyacınız olan çok sayıda sunucu örneği / lisansı. Daniel'in cevabını biraz daha yukarıda görün, orada bazı iyi bağlantılar var.
AdaTheDev

Çoklu DB 10.000 ayrı veritabanı anlamına gelse ve bakım maliyetini önemli ölçüde artırsa bile, bu canavarı yine de bulut altyapınız üzerinden otomasyon komut dosyalarını kullanarak evcilleştirebileceğinizi, böylece her şeyin programlı olarak yönetilebileceğini ve hiç insan çabası gerektirmediğini iddia ediyorum.
Korayem

17

Aşağıda, Salesforce.com'da çoklu kiracılığın nasıl uygulandığına ilişkin bir teknik incelemeye bağlantı bulunmaktadır:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

500 dize sütunu içeren 1 büyük tabloları var (Değer0, Değer1, ... Değer500). Tarihler ve Sayılar, veritabanı düzeyinde yerel türlerine dönüştürülebilecekleri bir biçimde dizeler olarak saklanır. Kiracı başına benzersiz olabilen veri modelinin şeklini tanımlayan meta veri tabloları vardır. İndeksleme, ilişkiler, benzersiz değerler vb. İçin ek tablolar vardır.

Neden güçlük?

Her kiracı, veritabanı düzeyinde değişiklik yapmak zorunda kalmadan çalışma zamanında kendi veri şemasını özelleştirebilir (tabloyu değiştirme vb.). Bu kesinlikle böyle bir şeyi yapmanın zor yoludur ama çok esnektir.


10

Bahsettiğiniz gibi, kiracı başına bir veritabanı bir seçenektir ve onunla bazı büyük ödünleşimlere sahiptir. Tek basamaklı veya düşük 10'lu kiracı gibi daha küçük ölçekte iyi çalışabilir, ancak bunun ötesinde yönetimi zorlaşır. Hem yalnızca geçişler hem de yalnızca veritabanlarını çalışır durumda tutmak için.

Şema başına model, yalnızca her biri için benzersiz şemalar için yararlı değildir, ancak yine de tüm kiracılar arasında geçişleri çalıştırmak zorlaşır ve 1000'lerce şemada Postgres sorun yaşamaya başlayabilir.

Daha ölçeklenebilir bir yaklaşım, kiracıların kesinlikle rastgele dağıtılmış, aynı veritabanında, ancak farklı mantıksal parçalar (veya tablolar ) arasında depolanmasıdır . Dilinize bağlı olarak bu konuda yardımcı olabilecek birkaç kütüphane vardır. Rails kullanıyorsanız, kiracılığın devamı için bir kitaplık vardır acts_as_tenant, bu, kiracı sorgularınızın yalnızca bu verileri geri çekmesine yardımcı olur. Ayrıca bir mücevher de var apartment- şema modelini kullanmasına rağmen, tüm şemalarda geçişlere yardımcı oluyor. Django kullanıyorsanız, bir numara var, ancak daha popüler olanlardan biri şemalar arasında görünüyor . Bunların tümü uygulama düzeyinde daha fazla yardımcı olur. Doğrudan veritabanı düzeyinde bir şey arıyorsanız, Citus bu tür bir parçalama yapmaya odaklanır.çok kiracılı Postgres ile kutudan çıkar çıkmaz daha fazla çalışın.

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.