MongoDB'de çok kiracılı veritabanlarına yönelik önerilen yaklaşım nedir?

MongoDB kullanarak çok kiracılı bir uygulama oluşturmayı düşünüyorum. Henüz kaç kiracım olacağına dair herhangi bir tahminim yok, ancak binlere ölçeklenebilmek istiyorum.

Üç strateji düşünebilirim:

1. Güvenlik için kiracıya özel alanları kullanarak aynı koleksiyondaki tüm kiracılar
2. Tek bir paylaşılan DB'de kiracı başına 1 Koleksiyon
3. Kiracı başına 1 veritabanı

Kafamdaki ses 2. seçeneği tercih etmemi öneriyor.

Düşünceler ve çıkarımlar, kimse?

Çözmem gereken aynı problem var ve varyantları da göz önünde bulunduruyorum. SaaS çok kiracılı uygulamalar yaratma konusunda uzun yıllara dayanan deneyimim olduğu için, ilişkisel veritabanları ile önceki deneyimlerime dayanarak ikinci seçeneği de seçecektim.

Araştırmamı yaparken mongodb destek sitesinde bu makaleyi buldum (gittiğinden beri eklenmiştir): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html

Adamlar ne pahasına olursa olsun 2. seçeneklerden kaçınmayı söylediler, anladığım kadarıyla özellikle mongodb'a özgü değil. Benim izlenimim, veritabanı tasarımının özellikleri nedeniyle araştırdığım NoSQL veritabanlarının çoğu (CoachDB, Cassandra, CouchBase Server, vb.) İçin geçerli olduğu yönünde.

Koleksiyonlar (veya kovalar veya farklı DB'lerde adlandırırlarsa), RDBMS'deki güvenlik şemalarıyla aynı şey değildir, ancak belgeler için konteynır görevi görmelerine rağmen, iyi kiracı ayırımı uygulamak için yararsızdır. Koleksiyonlara göre güvenlik kısıtlamaları uygulayabilecek NoSQL veritabanı bulamadım.

Tabii ki, veritabanı / sunucu düzeyinde erişimi kısıtlamak için mongodb rol tabanlı güvenliği kullanabilirsiniz. ( http://docs.mongodb.org/manual/core/authorization/ )

1. seçeneği şu durumlarda tavsiye ederim:

• Bu senaryonun tasarımı, uygulaması ve testinin karmaşıklığıyla başa çıkmak için yeterli zamana ve kaynağa sahipsiniz.
• Farklı kiracılar için veritabanında yapı ve işlevsellik açısından çok fazla farklılık olmayacaksa.
• Uygulama tasarımınız, kiracıların çalışma zamanında yalnızca minimum özelleştirme yapmasına izin verecektir.
• Alanı optimize etmek ve donanım kaynaklarının kullanımını en aza indirmek istiyorsanız.
• Binlerce kiracınız olacaksa.
• Hızlı ve iyi bir maliyetle ölçeklendirmek istiyorsanız.
• Kiracılara bağlı olarak verileri yedeklemeyecekseniz (her kiracı için ayrı yedeklemeler bulundurun). Bu senaryoda bile bunu yapmak mümkündür ama çaba çok büyük olacaktır.

Aşağıdaki durumlarda varyant 3'e giderim:

• Küçük bir kiracı listeniz olacak (birkaç yüz).
• İşin özellikleri, farklı kiracılar için veritabanı yapısındaki büyük farklılıkları destekleyebilmenizi gerektirir (örn. 3. taraf sistemlerle entegrasyon, verilerin içe-dışa aktarılması).
• Uygulama tasarımınız, müşterilerin (kiracıların) uygulama çalışma zamanında önemli değişiklikler yapmasına (modül ekleme, alanları özelleştirme vb.) Olanak tanır.
• Yeni donanım düğümleriyle hızla ölçeklendirmek için yeterli kaynağa sahipseniz.
• Kiracı başına verilerin sürümlerini / yedeklerini tutmanız gerekiyorsa. Ayrıca geri yükleme de kolay olacaktır.
• Sizi farklı veritabanlarında (hatta veri merkezlerinde) farklı kiracıları tutmaya zorlayan yasal / düzenleyici kısıtlamalar vardır.
• Mongodb'un roller gibi kullanıma hazır güvenlik özelliklerinden tam olarak yararlanmak istiyorsanız.
• Kiracılar arasında büyüklük bakımından büyük farklılıklar vardır (çok sayıda küçük kiracınız ve çok az sayıda çok büyük kiracınız var).

Başvurunuz hakkında ek ayrıntılar gönderirseniz, belki size daha ayrıntılı tavsiyelerde bulunabilirim.

Bu bağlantıdaki yorumlarda iyi bir cevap buldum:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Temelde 2. seçenek, gitmenin en iyi yolu gibi görünüyor.

David Mytton'ın yorumundan alıntı:

MongoDB'nin veri dosyalarını tahsis etme şekli nedeniyle müşteri başına bir veri tabanı oluşturmamaya karar verdik. Her veritabanı kendi dosya kümesini kullanır:

Bir veritabanı için ilk dosya dbname.0'dır, ardından dbname.1 vb. Dbname.0 64MB, dbname.1 128MB vb. 2GB'a kadar olacaktır. Dosyalar 2 GB boyutuna ulaştığında, birbirini izleyen her dosya da 2 GB olur.

Bu nedenle, mevcut son veri dosyası 1GB ise, yakın zamanda ulaşılmışsa bu dosya% 90 boş olabilir.

kılavuzdan.

Kullanıcılar deneme sürümüne kaydoldukça ve bir şeyler yaptıkça, veri dosyasının tamamı kullanılmasa bile, en az 2 GB boyutunda daha fazla veri tabanı elde edecektik. Bunun, disk alanının maksimum verimlilikte kullanılabileceği tüm müşteriler için birkaç veritabanına sahip olmakla karşılaştırıldığında çok büyük miktarda disk alanı kullandığını gördük.

Parçalama, standart olarak koleksiyon bazında olacaktır ve bu, koleksiyonun parçalanmaya başlamak için hiçbir zaman minimum boyuta ulaşmadığı bir problemi ortaya çıkarır, tıpkı pek çoğumuzda olduğu gibi (örneğin, sadece kullanıcı oturum açma bilgilerini depolayan koleksiyonlar). Bununla birlikte, bunun aynı zamanda veritabanı bazında da yapılabilmesini talep ettik. Bkz. Http://jira.mongodb.org/browse/SHARDING-41

Çok sayıda koleksiyon kullanarak performans değiş tokuşu yoktur. Bkz. Http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Orada çok kiracı veri mimarisi hakkında MSDN'de makul makale size başvurmak isteyebilirsiniz. Bu makalede değinilen bazı önemli konular:

• Ekonomik hususlar
• Güvenlik
• Kiracı değerlendirmeleri
• Düzenleyici (yasal)
• Beceri seti endişeleri

Ayrıca, Hizmet Olarak Yazılım (SaaS) yapılandırmasının bazı modellerine de değinilmiştir.

Ek olarak, bir göz atmaya değer, Anywhere SQL çalışanlarının ilginç bir yazımıdır .

Benim kişisel görüşüm - zorunlu güvenlik / güvenden emin değilseniz, seçenek 3'ü tercih ederim ya da ölçeklenebilirlik endişeleri en azından 2. seçeneğe geri dönüşü yasaklıyorsa. Bununla birlikte ... MongoDB konusunda profesyonel değilim. Paylaşılan bir "şema" kullanırken oldukça gergin oluyorum - ama daha deneyimli uygulayıcıları seve seve erteleyeceğim.

2. seçenek için giderdim.

Ancak mongod.exe komut satırı seçeneğini --smallfiles olarak ayarlayabilirsiniz. Bu, bir kapsamın en büyük dosya boyutunun 2 gigabayt değil, 0,5 gigabayt olacağı anlamına gelir. Bunu mongo 1.42 ile test ettim. Yani 3. seçenek imkansız değil.

MongoDB'deki araştırmama göre . Trucos y consejos. Aplicaciones çok kiracılı. Kaç kiracıya sahip olabileceğinizi bilmiyorsanız, bu seçenek tavsiye edilmez, binlerce olabilir ve parçalama söz konusu olduğunda karmaşık olabilir, ayrıca tek bir veritabanında binlerce koleksiyona sahip olduğunuzu hayal edin ... Öyleyse sizin durumunuzda birinci seçeneğin kullanılması önerilir. Şimdi, sınırlı sayıda kullanıcınız olacaksa, bu zaten farklıdır ve evet, düşündüğünüz gibi ikinci seçeneği kullanabilirsiniz.

Buradaki tartışma NoSQL ve öncelikle MongoDB üzerindeyken, Citus'ta PostgreSQL kullanıyoruz ve dağıtılmış / parçalanmış çok kiracılı bir veritabanı oluşturuyoruz.

Bizim kullanım-vaka kılavuzu şema ve çeşitli çoklu kiracı özgü özellikleri kapsayan bir örnek uygulaması yoluyla yürür.

Daha fazla yapılandırılmamış veri için, bu tür ve kiracıya özel verileri depolamak için PostgreSQL'in JSONB sütununu kullanırız.