Apa pendekatan yang direkomendasikan terhadap database multi-tenant di MongoDB?

98

Saya sedang berpikir untuk membuat aplikasi multi-tenant menggunakan MongoDB. Saya belum bisa menebak berapa banyak penyewa yang saya miliki, tapi saya ingin bisa mencapai ribuan.

Saya dapat memikirkan tiga strategi:

  1. Semua penyewa dalam koleksi yang sama, menggunakan bidang khusus penyewa untuk keamanan
  2. 1 Koleksi per penyewa dalam satu DB bersama
  3. 1 Database per penyewa

Suara di kepalaku menyarankan agar aku memilih opsi 2.

Pikiran dan implikasinya, siapa?

mongodb  multi-tenant 
— Braintapper
sumber
@Braintapper yang terhormat, kami berada dalam situasi yang sama saat ini dengan aplikasi kami yang perlu memiliki kemampuan multi-tenancy. Apakah Anda punya pengalaman untuk dibagikan? Bagus sekali, terima kasih.
— Joshua Muheim
3
Untuk aplikasi saya, saya akhirnya menggunakan Postgresql (kami mendapatkan manfaat dari database relasional dengan beberapa fungsionalitas seperti NoSQL melalui ekstensi hstore) daripada MongoDB dan menangani multi-tenancy di Rails dengan pelingkupan. Kami menggunakan pendekatan serupa dengan yang digunakan dalam Railscast ini: railscasts.com/episodes/388-multitenancy-with-scopes
— Braintapper
2
saya tahu jawaban telah dipilih untuk pertanyaan ini tetapi siapa pun harus merujuk ke dokumen resmi ini di situs mongohq: support.mongohq.com/use-cases/multi-tenant.html . Ini jelas mendukung solusi @Braintapper di bawah ini
— lafama
1
Jawaban diperbarui. Informasi di tautan Anda tidak tersedia pada Mei 2010.
— Braintapper
@Braintapper apakah Anda menggunakan solusi postgresql (berdasarkan railscasts.com) sekarang? Saya ingin menggunakannya tetapi saya tidak yakin apakah itu menambah keamanan dan berapa banyak penyewa yang dapat didukung! tolong saya butuh tanggapan Anda tentang pengalaman ini. terima kasih
— medBouzid

Jawaban:

73

Saya memiliki masalah yang sama untuk dipecahkan dan juga mempertimbangkan varian. Karena saya memiliki pengalaman bertahun-tahun membuat aplikasi multi-tenant SaaS, saya juga akan memilih opsi kedua berdasarkan pengalaman saya sebelumnya dengan database relasional.

Saat melakukan penelitian, saya menemukan artikel ini di situs dukungan mongodb (cara kembali ditambahkan sejak hilang): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html

Orang-orang menyatakan untuk menghindari opsi ke-2 dengan biaya berapa pun, yang seperti yang saya mengerti tidak terlalu spesifik untuk mongodb. Kesan saya adalah bahwa ini berlaku untuk sebagian besar dbs NoSQL yang saya teliti (CoachDB, Cassandra, CouchBase Server, dll.) Karena spesifikasi desain database.

Koleksi (atau keranjang atau bagaimanapun mereka menyebutnya dalam DB yang berbeda) tidak sama dengan skema keamanan di RDBMS meskipun mereka berperilaku sebagai wadah untuk dokumen, mereka tidak berguna untuk menerapkan pemisahan penyewa yang baik. Saya tidak dapat menemukan database NoSQL yang dapat menerapkan batasan keamanan berdasarkan koleksi.

Tentu saja Anda dapat menggunakan keamanan berbasis peran mongodb untuk membatasi akses pada tingkat database / server. ( http://docs.mongodb.org/manual/core/authorization/ )

Saya akan merekomendasikan opsi pertama ketika:

  • Anda memiliki cukup waktu dan sumber daya untuk menangani kerumitan desain, implementasi, dan pengujian skenario ini.
  • Jika Anda tidak akan memiliki banyak perbedaan dalam struktur dan fungsionalitas dalam database untuk penyewa yang berbeda.
  • Desain aplikasi Anda akan memungkinkan penyewa hanya membuat sedikit penyesuaian pada waktu proses.
  • Jika Anda ingin mengoptimalkan ruang dan meminimalkan penggunaan sumber daya perangkat keras.
  • Jika Anda ingin memiliki ribuan penyewa.
  • Jika Anda ingin meningkatkan skala dengan cepat dan dengan biaya yang terjangkau.
  • Jika Anda TIDAK akan mencadangkan data berdasarkan penyewa (simpan cadangan terpisah untuk setiap penyewa). Dimungkinkan untuk melakukan itu bahkan dalam skenario ini tetapi usahanya akan sangat besar.

Saya akan memilih varian 3 jika:

  • Anda akan memiliki daftar kecil penyewa (beberapa ratus).
  • Spesifikasi bisnis mengharuskan Anda untuk dapat mendukung perbedaan besar dalam struktur database untuk penyewa yang berbeda (misalnya integrasi dengan sistem pihak ketiga, ekspor-impor data).
  • Desain aplikasi Anda akan memungkinkan pelanggan (penyewa) membuat perubahan signifikan dalam runtime aplikasi (menambahkan modul, menyesuaikan bidang, dll.).
  • Jika Anda memiliki cukup sumber daya untuk mengembangkan node perangkat keras baru dengan cepat.
  • Jika Anda diharuskan menyimpan versi / cadangan data per penyewa. Pemulihannya juga akan mudah.
  • Ada batasan hukum / peraturan yang memaksa Anda untuk menyimpan penyewa yang berbeda di database yang berbeda (bahkan pusat data).
  • Jika Anda ingin memanfaatkan sepenuhnya fitur keamanan mongodb seperti peran.
  • Ada perbedaan besar dalam masalah ukuran antara penyewa (Anda memiliki banyak penyewa kecil dan sedikit penyewa yang sangat besar).

Jika Anda memposting detail tambahan tentang aplikasi Anda, mungkin saya dapat memberikan saran yang lebih rinci.

— Ruslan Kiskinov
sumber
9
Saya kira tautan asli sudah mati, pergi untuk yang diarsipkan: web.archive.org/web/20140812091703/http://support.mongohq.com/…
— Peter Butkovic
Halo, Bagaimana cara membuat db baru dengan db saat ini menggunakan mongodb?
— HEMAL
@Russian Bagaimana kita akan menangani pengindeksan jika kita akan memilih 1
— Robins Gupta
10

Saya menemukan jawaban yang bagus di komentar di tautan ini:

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

Pada dasarnya opsi # 2 tampaknya menjadi cara terbaik untuk pergi.

Kutipan dari komentar David Mytton:

Kami memutuskan untuk tidak memiliki database per pelanggan karena cara MongoDB mengalokasikan file datanya. Setiap database menggunakan kumpulan filenya sendiri:

File pertama untuk database adalah dbname.0, lalu dbname.1, dll. Dbname.0 akan menjadi 64MB, dbname.1 128MB, dll., Hingga 2GB. Setelah ukuran file mencapai 2GB, setiap file berturut-turut juga berukuran 2GB.

Jadi jika datafile terakhir yang ada adalah, 1GB, file itu mungkin 90% kosong jika baru saja dicapai.

dari manual.

Saat pengguna mendaftar ke uji coba dan mencobanya, kami akan mendapatkan lebih banyak database yang berukuran setidaknya 2GB, bahkan jika seluruh file data tidak digunakan. Kami menemukan ini menggunakan ruang disk yang sangat besar dibandingkan dengan memiliki beberapa database untuk semua pelanggan di mana ruang disk dapat digunakan untuk efisiensi maksimum.

Sharding akan menggunakan basis per koleksi sebagai standar yang menghadirkan masalah di mana koleksi tidak pernah mencapai ukuran minimum untuk memulai sharding, seperti yang terjadi pada beberapa kasus kami (misalnya, koleksi yang hanya menyimpan detail login pengguna). Namun, kami telah meminta agar ini juga dapat dilakukan pada level per database. Lihat http://jira.mongodb.org/browse/SHARDING-41

Tidak ada pengorbanan kinerja menggunakan banyak koleksi. Lihat http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

— Braintapper
sumber
2
Seperti yang disarankan dalam jawaban lain, # 2 bukanlah pendekatan yang baik. Harap pertimbangkan untuk mengubah jawaban yang diterima, karena ini bisa kehilangan prospek pengembang lain.
— clopez
1
Mengubah jawaban yang diterima, karena banyak hal telah berubah secara signifikan sejak 2010, ketika pertanyaan pertama kali diajukan.
— Braintapper
3

Ada artikel yang masuk akal di MSDN tentang arsitektur data multi-tenant yang mungkin ingin Anda rujuk. Beberapa topik utama yang disinggung oleh artikel ini:

  • Pertimbangan ekonomi
  • Keamanan
  • Pertimbangan penyewa
  • Regulatif (legal)
  • Keterampilan mengatur perhatian

Yang juga disinggung adalah beberapa pola untuk konfigurasi Software as a Service (SaaS).

Selain itu, patut dilihat adalah artikel menarik dari SQL Anywhere guys .

Pandangan pribadi saya sendiri - kecuali Anda yakin dengan keamanan / kepercayaan yang diberlakukan, saya akan memilih opsi 3, atau jika masalah skalabilitas melarang fallback ke opsi 2 minimal. Yang mengatakan ... Saya bukan pro dengan MongoDB. Saya menjadi sangat gugup menggunakan "skema" bersama - tetapi saya dengan senang hati akan tunduk kepada praktisi yang lebih berpengalaman.

— AJ.
sumber
Saya akrab dengan artikel MSDN itu, karena rencana awal saya adalah menggunakan database relasional. Namun, data saya cukup tidak terstruktur, yang sekarang membuat saya menyelidiki dbs NoSQL seperti MongoDB. Tampaknya MongoDB tidak memiliki dukungan ACL seperti yang dilakukan Lotus Domino, dan saya tidak benar-benar ingin menemukan kembali roda, yang membuat saya juga berpikir bahwa 2 atau 3 adalah cara terbaik. Saya juga tidak tahu apakah ada batasan yang mungkin saya temui dalam hal # koleksi atau dbs yang diizinkan di MongoDB.
— Braintapper
0

Menurut penelitian saya di MongoDB. Trucos y consejos. Aplicaciones multitenant. opsi itu tidak disarankan jika Anda tidak tahu berapa banyak penyewa yang dapat Anda miliki, bisa jadi ribuan dan akan rumit jika menyangkut sharding, bayangkan juga memiliki ribuan koleksi dalam satu database ... Jadi dalam kasus Anda, ini disarankan untuk menggunakan opsi satu. Sekarang jika Anda akan memiliki jumlah pengguna yang terbatas, itu sudah berbeda dan ya, Anda dapat menggunakan opsi dua seperti yang Anda pikirkan.

— Osleynin Mambell Ramos
sumber
-2

Sementara pembahasan di sini adalah tentang NoSQL dan terutama MongoDB, kami di Citus menggunakan PostgreSQL dan membangun database multi-tenant terdistribusi / sharded.

Panduan kasus penggunaan kami menjelaskan aplikasi contoh, yang mencakup skema dan berbagai fitur khusus multi-tenant.

Untuk data yang lebih tidak terstruktur, kami menggunakan kolom JSONB PostgreSQL untuk menyimpan data tersebut dan data khusus penyewa.

— Sumedh
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.