Apakah DB multi-penyewa memiliki banyak basis data atau tabel bersama?

Apakah basis data multi-penyewa:

Server DB yang memiliki basis data / skema yang berbeda (identik) untuk setiap pelanggan / penyewa ?; atau
Server DB yang memiliki database / skema di mana pelanggan / penyewa berbagi catatan di dalam tabel yang sama?

Sebagai contoh, di bawah Opsi # 1 di atas, saya mungkin memiliki server MySQL di, katakanlah mydb01.example.com,, dan mungkin memiliki customer1database di dalamnya. customer1Database ini mungkin memiliki, katakanlah, 10 tabel yang mendukung aplikasi saya untuk pelanggan tertentu (Pelanggan # 1). Mungkin juga memiliki customer2database dengan 10 tabel yang sama persis di dalamnya, tetapi hanya berisi data untuk Pelanggan # 2. Mungkin memiliki customer3database, customer4database, dan sebagainya.

Dalam Opsi # 2 di atas, hanya akan ada satu basis data / skema, katakanlah myapp_db, lagi dengan 10 tabel di dalamnya (sama seperti di atas). Tapi di sini, data untuk semua pelanggan ada di dalam 10 tabel itu, dan karena itu mereka "berbagi" tabel. Dan pada lapisan aplikasi, logika dan kontrol keamanan dimana pelanggan memiliki akses ke catatan mana dalam 10 tabel tersebut, dan sangat hati-hati untuk memastikan bahwa Pelanggan # 1 tidak pernah masuk ke aplikasi dan melihat data Pelanggan # 3, dll.

Manakah dari paradigma ini yang merupakan DB "multi-tenant" tradisional? Dan jika tidak ada, maka dapatkah seseorang memberi saya contoh (menggunakan skenario yang dijelaskan di atas) tentang apa itu DB multi-penyewa?

database-design multitenancy

— smeeb
sumber

"multi tenant" menyiratkan keamanan yang kuat - diterapkan di suatu tempat - sehingga satu penyewa tidak dapat melihat data orang lain, tidak dapat memodifikasinya, tidak dapat menolak akses ke sana, dll. Keamanan itu harus diimplementasikan entah bagaimana. Opsi # 1 dan # 2 OP keduanya berfungsi tetapi analisis keamanan dan pekerjaan yang diperlukan untuk mengimplementasikan keamanan berbeda. Untuk apa nilainya, saya bekerja di startup yang menerapkan multi-tenancy melalui opsi # 2 di mana tabel - dengan baris milik beberapa penyewa - disembunyikan (melalui izin) dari semua pengguna akhir dan keamanan diimplementasikan sepenuhnya dalam prosedur tersimpan.

— davidbak

Kemungkinan duplikat Multi-tenancy - database tunggal vs beberapa database

— JeffO

Jika ini akhirnya ditutup sebagai duplikat, saya pikir kita harus menandai untuk menggabungkannya dengan target dupe karena kedua pertanyaan memiliki beberapa jawaban yang sangat bagus.

Jawaban:

Manakah dari paradigma ini yang merupakan DB "multi-tenant" tradisional

Kedua konsep ini disebut multi-tenancy, karena ini hanya konsep logis "di mana satu contoh perangkat lunak berjalan di server dan melayani beberapa penyewa" (dari Wikipedia ). Tetapi bagaimana Anda menerapkan konsep ini "secara fisik" terserah Anda.

Tentu saja, aplikasi membutuhkan konsep basis data yang memungkinkan untuk memisahkan data dari penyewa yang berbeda, dan gagasan multi-penyewa adalah memiliki beberapa sumber daya server dibagi (setidaknya perangkat keras) untuk pemanfaatan sumber daya yang lebih baik, dan administrasi yang lebih mudah. Jadi "multi tenant DB" adalah yang mendukung ini secara langsung , di mana bagian-bagian dari model atau tabel db dibagi.

Lebih tepatnya, adalah mungkin untuk membangun aplikasi multi-tenant dengan DB non-multi-tenant, memberikan instance DB individual per klien. Namun, ini menghalangi untuk berbagi sumber daya DB langsung antara penyewa, dan lapisan aplikasi harus memastikan untuk menghubungkan penyewa yang tepat ke database yang tepat.

— Doc Brown
sumber

Terima kasih @Doc Brown (1) tapi kemudian, bagaimana mungkin Anda bisa memiliki apa pun basis data yang tidak multi-penyewa?!?

— smeeb

@smeeb: multi-tenancy adalah properti aplikasi yang digunakan oleh penyewa yang berbeda, bukan dari database "di belakang" aplikasi. Tentu saja, konsep db perlu mendukung multi tenancy untuk memungkinkan hal ini.

— Doc Brown

@smeeb: Andaikan Anda memiliki tabel Pengguna dengan batasan bahwa nama pengguna itu unik, sekarang beberapa karyawan penyewa tidak dapat menggunakan nama pengguna lagi hanya karena seseorang yang bekerja di penyewa lain sudah menggunakannya.

— RemcoGerlich

@smeeb: jika satu-satunya cara melayani dua penyewa adalah dengan menginstal dan menjalankan aplikasi dua kali, pada dua server yang berbeda, dengan dua database terpisah, saya pikir seseorang tidak akan memanggil multi-tenancy ini.

— Doc Brown

Saya pergi ke presentasi tentang Azure beberapa waktu lalu yang mengatakan MYOB menjalankan solusi cloud mereka di Azure, dan setiap penyewa mendapatkan DB mereka sendiri (dan mungkin juga server web); mereka hanya memiliki beberapa alat otomasi hebat untuk mengelola ratusan instance DB yang harus dibutuhkan. Di sisi lain, organisasi tempat saya bekerja saat ini menjalankan ratusan pelanggan dari satu basis data, hanya ada sedikit pekerjaan yang dilakukan dalam perangkat lunak untuk menegakkan isolasi data pelanggan. Kami juga mempertimbangkan hibrida, di mana pelanggan terbesar kami akan mendapatkan DB mereka sendiri, sementara yang lain membagikan yang asli.

— David Keaveny

Menurut Microsoft, istilah ini memiliki 3 arti potensial (satu database untuk semua penyewa, atau satu databaser per penyewa).

Untuk menggunakan contoh Anda, setiap pelanggan adalah penyewa sendiri.

Database per penyewa (pelanggan)
- Setiap penyewa terisolasi dari yang lain (tidak ada akses tidak disengaja ke data penyewa lain)
- Isolasi juga membuatnya lebih mudah untuk mengelola pemulihan data serta menyesuaikan kebutuhan penyimpanan untuk kebutuhan penyewa.
Basis data bersama, skema terpisah.
- Setiap penyewa memiliki skema sendiri, dan data mereka ada di tabel mereka sendiri.
- Memulihkan bisa memakan waktu lebih lama, karena semua orang ada di database yang sama, Anda tidak bisa hanya mengembalikan database ke cadangan sebelumnya (itu akan memutar kembali data setiap penyewa). Sebuah opsi adalah mengembalikan ke database baru dan kemudian menggabungkan / menyalin hanya data 1 penyewa.
Basis data bersama, skema bersama.
- Data setiap penyewa berada di tabel yang sama. Misalnya, jika Anda melacak pesanan, pesanan setiap penyewa akan berada di "dbo.Orders".
- Data penyewa dipisahkan oleh kolom di setiap tabel (bisa juga TenantId), yang menunjukkan pemilik baris.

Ada pro dan kontra untuk masing-masing, dijelaskan dengan baik dalam artikel ini: https://msdn.microsoft.com/en-us/library/aa479086.aspx

Bonus: Anda dapat menganggapnya sebagai tempat tinggal (sangat disederhanakan).

Setiap penyewa memiliki rumahnya sendiri. Mereka dapat melakukan apa pun yang mereka inginkan, dan jika terbakar, itu tidak benar-benar mempengaruhi orang lain.
Setiap penyewa berada di gedung yang sama, tetapi memiliki apartemen sendiri.
Semua orang tinggal di apartemen yang sama, dan semua barang ditandai dengan kertas tempel untuk menunjukkan siapa pemiliknya.

— lmms90
sumber

Terima kasih atas jawaban Anda. Bisakah Anda jelaskan sedikit jawaban Anda. Itu akan menciptakan jawaban yang lebih baik.

— Thomas Junk

contoh bonus Anda luar biasa @ imms90

— Aravin

Microsoft telah menjatuhkan halaman yang Anda tautkan dari MSDN. The Mesin wayback masih memiliki salinan.

— Mike Sherrill 'Cat Recall'

Artikel serupa dari MS (mungkin sama yang telah pindah): docs.microsoft.com/en-us/azure/sql-database/…

— Pierre Henry