Multi-tenancy - database tunggal vs beberapa database

20

Kami memiliki sejumlah klien, yang sistemnya berbagi beberapa fungsi, tetapi juga memiliki tingkat keanekaragaman yang cukup. Jumlah klien bertambah - selalu hal yang sehat! - dan keragaman di antara bisnis mereka juga meningkat.

Saat ini terdapat satu Situs Web ASP.Net (Formulir Web) (sebagai lawan dari proyek web), yang memiliki sub-folder untuk setiap penyewa, dengan halaman-halaman non-standar penyewa itu. Ada proyek model terpisah, yang berkaitan dengan akses basis data dan logika bisnis.

Mana yang lebih disukai - dan yang paling penting, mengapa - antara memiliki (a) 1 database per klien, dengan hanya fitur yang terkait dengan klien itu; atau (b) database tunggal yang digunakan bersama oleh semua klien, di mana hanya sebagian dari tabel yang digunakan oleh satu klien.

Kekhawatiran utama dalam bisnis sudah berakhir:

pemeliharaan beberapa aset - cadangan, kontrol versi, dan sejenisnya
mempromosikan penggunaan ulang sebanyak mungkin

Bagaimana Anda memastikan masalah ini ditangani, solusi mana yang lebih disukai, dan mengapa? (Saya juga telah menyusun respons untuk pertanyaan serupa)

database-design projects-and-solutions multitenancy

— RichardW1001
sumber

Apakah ada kemungkinan ini akan pindah ke lingkungan cloud PaaS seperti Azure? Jika demikian, Anda juga ingin mempertimbangkan praktik terbaik untuk lingkungan. Terakhir kali saya melihat, MS merekomendasikan banyak basis data untuk perangkat lunak multitenant di Azure.

— Harper Shelby

Terima kasih untuk bertanya. Saya telah bertanya-tanya tentang hal-hal yang serupa, tetapi belum dapat menempatkan ke dalam format pertanyaan dengan fasih seperti Anda.

— MathAttack

Anda harus membaca seri blog multi-tenancy dari Ayende. Dia membuat beberapa poin yang sangat bagus tentang database multi vs tunggal.

— Sebazzz

12

Berikut ini sorotan dari penelitian dari sumber lain (aslinya dari revisi 2 pertanyaan ):

Haruskah saya menggunakan satu database per aplikasi atau berbagi satu database di antara beberapa aplikasi
Mendukung multitenancy
Arsitektur Data Multi-Penyewa MSDN
SO Bagaimana cara membuat database multi-tenant dengan struktur tabel bersama?
CloudExpo SaaS - Opsi Desain Basis Data Multi-Tenant
Blog MSDN Pindah ke Model Database Multi-Tenant Dimudahkan dengan Federasi SQL Azure
Tanyakan SQL Server Central One atau beberapa database?
SQL Server Central Mixing tables dari berbagai database / aplikasi menjadi satu database
Ayende @ Rahien blog Multi Tenancy - The Physical Data Model
Proyek Kode Multi-Penyewa Database Arsitektur
Joel pada perancangan basis data Multi-tenant Perangkat Lunak
SO Beberapa aplikasi menggunakan satu database?
SO Database tunggal atau ganda
Kata-kata kasar - Multi-tenancy Bagian 1, Strategi dan Bagian 2, Komponen dan Konteks

— user40980
sumber

10

Jika Anda menggunakan SQL Server, gunakan satu database tetapi gunakan skema. Gunakan dbo untuk hal-hal yang umum untuk semua klien dan buat skema untuk setiap klien dan jadikan skema default untuk pengguna dari klien itu. Sekarang Anda dapat memiliki objek umum (katakanlah get getBudget proc) di skema dbo dan yang disesuaikan untuk klien dalam skema mereka dengan nama yang sama.

— HLGEM
sumber

+1 Ini juga akan memungkinkan Anda untuk menghindari mengkonfigurasi MSDTC dan mengambil overhead terkait (komitmen dua fase)

— brian

Dan mudah-mudahan Anda menghindari jebakan memiliki kolom seperti CustomField1 hingga CustomField30 dan / atau memiliki tabel seperti Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName, dll.

— jfrankcarr

Ada lapisan akses data yang ada yang menggunakan banyak prosedur tersimpan - 190 tabel, 5 prosedur yang dihasilkan kode per tabel, ditambah beberapa prosedur khusus - sementara sasaran jangka menengah adalah untuk memperkenalkan Entity Framework, apakah akan ada kebutuhan untuk mereplikasi penyimpanan yang disimpan prosedur untuk setiap skema?

— RichardW1001

@ RichardW1001: tergantung. Anda dapat melakukan SQL dinamis di sp, untuk membuatnya generik, tetapi itu tentu saja tergantung pada mereka memiliki setidaknya struktur yang agak mirip. Alternatif yang mungkin untuk sql dinamis, akan menjadi Sinonim , sayangnya, seperti yang saya pahami, mereka luas sistem dan tidak terkandung dalam transaksi, jadi tidak cocok untuk penggunaan bersamaan dengan nilai yang berbeda.

— jmoreno

Jika kami menggunakan beberapa skema, menggunakan EF Code First, mungkinkah akan memigrasi semua skema ke versi terbaru setelah sistem ditayangkan?

— Yashvit

4

Karena database dan fungsionalitas klien berbeda, maka itu berarti bahwa pada satu titik mereka akan menjadi sistem yang berbeda, jadi dalam hal ini saya akan merekomendasikan sistem terpisah karena biaya mempertahankan penyesuaian untuk setiap klien akan lebih besar daripada manfaat dari satu sistem basis data.

Sistem basis data tunggal terbaik untuk ketika perubahan antara pelanggan yang berbeda hanyalah konfigurasi tetapi bukan fitur tambahan untuk setiap klien.

— Stephen Senkomago Musoke
sumber

Apa saran Anda tentang bagaimana mengelola fungsi umum dengan rasa sakit minimal?

— RichardW1001

1

Dalam sistem kontrol versi Anda, pertahankan kepala untuk aplikasi inti, dan buat cabang utama untuk setiap pelanggan, dengan cabang pembantu untuk fitur-fitur baru yang mereka perlu pertahankan. Kembangkan fitur spesifik pelanggan di cabang, dengan opsi untuk memperbarui bagasi dll. Anda kemudian dapat memutar lingkungan khusus pelanggan dengan mudah kapan pun Anda membutuhkannya

— Stephen Senkomago Musoke

3

Anda melewatkan beberapa masalah. Masalah akan muncul seiring dengan pertumbuhan. Jika Anda dapat berasumsi bahwa suatu hari nanti Anda akan tumbuh lebih besar dari satu server DB - satu database yang kompleks pasti akan membuat Anda pusing. Kecuali Anda akan berinvestasi dalam arsitektur terlebih dahulu. Tapi ini juga langkah mahal)

Jadi, jangan lupa, bahwa keduanya berkali-kali lebih murah dan berkali-kali lebih mudah untuk memperkecil beberapa basis data yang berbeda, daripada yang besar)

— rangsangan
sumber

Apakah Anda memiliki data yang mengonfirmasi kemudahan penskalaan? Jika demikian, itu akan menjadi kasus yang sangat menarik. Bisakah Anda menguraikan keprihatinan lain yang hilang? Saya mencoba membangun argumen selengkap mungkin di kedua sisi.

— RichardW1001

1

Satu area yang belum saya lihat dibahas dalam jawaban adalah masalah dengan benar mengamankan aplikasi DB multi-tenant. Aplikasi multi-penyewa harus dirancang dengan sangat hati-hati untuk menghindari masalah keamanan. Sebagian besar Database dan aplikasi menyediakan beberapa, tetapi tidak isolasi lengkap - biasanya ada cara untuk secara langsung atau tidak langsung menyimpulkan data di seluruh skema DB. Dan beberapa sumber daya bersama (log dan file lainnya, tabel DBA, kursor ...) yang dapat, paling tidak, mengarah pada serangan Denial of Service yang mudah terhadap penyewa lain, dan biasanya jauh lebih banyak.

— Kuntul
sumber