Saya memiliki masalah yang sama untuk dipecahkan dan juga mempertimbangkan varian. Karena saya memiliki pengalaman bertahun-tahun dalam membuat aplikasi multi-penyewa 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 (ditambahkan kembali 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 cara apa pun, yang menurut saya 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 ember 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 fungsi dalam database untuk penyewa yang berbeda.
- Desain aplikasi Anda akan memungkinkan penyewa hanya membuat penyesuaian minimal saat runtime.
- 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 baik.
- Jika Anda TIDAK akan membuat cadangan data berdasarkan penyewa (simpan cadangan terpisah untuk setiap penyewa). Dimungkinkan untuk melakukan itu bahkan dalam skenario ini tetapi upayanya akan sangat besar.
Saya akan memilih varian 3 jika:
- Anda akan memiliki daftar kecil penyewa (beberapa ratus).
- Kekhususan bisnis mengharuskan Anda untuk dapat mendukung perbedaan besar dalam struktur database untuk penyewa yang berbeda (mis. integrasi dengan sistem pihak ketiga, ekspor-impor data).
- Desain aplikasi Anda akan memungkinkan pelanggan (penyewa) membuat perubahan signifikan pada waktu proses aplikasi (menambahkan modul, menyesuaikan bidang, dll.).
- Jika Anda memiliki sumber daya yang cukup untuk menskalakan dengan 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 sepenuhnya memanfaatkan fitur keamanan bawaan mongodb seperti peran.
- Ada perbedaan besar dalam hal 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 detail.
