Bagaimana cara membuat database multi-tenant dengan struktur tabel bersama?

Perangkat lunak kami saat ini berjalan pada MySQL. Data semua penyewa disimpan dalam skema yang sama. Karena kami menggunakan Ruby on Rails, kami dapat dengan mudah menentukan data milik penyewa mana. Namun ada beberapa perusahaan yang khawatir bahwa data mereka dapat dikompromikan, jadi kami mengevaluasi solusi lain.

Sejauh ini saya telah melihat tiga opsi:

• Multi-Database (masing-masing penyewa mendapatkan sendiri - hampir sama dengan 1 server per pelanggan)
• Multi-Skema (tidak tersedia di MySQL, masing-masing penyewa mendapatkan skema sendiri dalam database bersama)
• Skema Bersama (pendekatan kami saat ini, mungkin dengan catatan identifikasi tambahan pada setiap kolom)

Multi-Skema adalah favorit saya (mempertimbangkan biaya). Namun membuat akun baru dan melakukan migrasi tampaknya cukup menyakitkan, karena saya harus mengulangi semua skema dan mengubah tabel / kolom / definisi mereka.

T: Multi-Skema tampaknya dirancang untuk memiliki tabel yang sedikit berbeda untuk setiap penyewa - Saya tidak menginginkan ini. Apakah ada RDBMS yang memungkinkan saya untuk menggunakan solusi multi-skema multi-penyewa, di mana struktur tabel dibagi antara semua penyewa?

PS By multi, maksud saya sesuatu seperti ultra-multi (10.000+ penyewa).

Namun ada beberapa perusahaan yang khawatir bahwa data mereka dapat dikompromikan, jadi kami mengevaluasi solusi lain.

Ini sangat disayangkan, karena pelanggan terkadang menderita kesalahpahaman bahwa hanya isolasi fisik yang dapat menawarkan keamanan yang cukup.

Ada artikel MSDN yang menarik, berjudul Multi-Tenant Data Architecture , yang mungkin ingin Anda periksa. Inilah cara penulis mengatasi kesalahpahaman terhadap pendekatan bersama:

Kesalahpahaman umum menyatakan bahwa hanya isolasi fisik yang dapat memberikan tingkat keamanan yang sesuai. Bahkan, data yang disimpan menggunakan pendekatan bersama juga dapat memberikan keamanan data yang kuat, tetapi membutuhkan penggunaan pola desain yang lebih canggih.

Adapun pertimbangan teknis dan bisnis, artikel ini membuat analisis singkat di mana pendekatan tertentu mungkin lebih tepat daripada yang lain:

Jumlah, sifat, dan kebutuhan penyewa yang Anda harapkan untuk melayani semua mempengaruhi keputusan arsitektur data Anda dengan cara yang berbeda. Beberapa pertanyaan berikut mungkin bias Anda terhadap pendekatan yang lebih terisolasi, sementara yang lain mungkin bias Anda terhadap pendekatan yang lebih umum.

• Berapa calon penyewa yang Anda harapkan untuk ditargetkan? Anda mungkin tidak dapat memperkirakan penggunaan prospektif dengan otoritas, tetapi pikirkan dalam hal urutan besarnya: apakah Anda membangun aplikasi untuk ratusan penyewa? Ribuan? Puluhan ribu? Lebih? Semakin besar Anda mengharapkan basis penyewa Anda, semakin besar kemungkinan Anda ingin mempertimbangkan pendekatan yang lebih umum.

• Berapa banyak ruang penyimpanan yang Anda harapkan untuk ditempati oleh data rata-rata penyewa? Jika Anda mengharapkan beberapa atau semua penyewa untuk menyimpan jumlah data yang sangat besar, pendekatan basis data terpisah mungkin yang terbaik. (Memang, persyaratan penyimpanan data mungkin memaksa Anda untuk mengadopsi model database terpisah. Jika demikian, akan lebih mudah untuk merancang aplikasi seperti itu sejak awal daripada pindah ke pendekatan database terpisah nanti.)

• Berapa banyak pengguna akhir secara bersamaan yang Anda harapkan dari penyewa rata-rata untuk mendukung? Semakin besar angkanya, semakin tepat pendekatan yang lebih terisolasi untuk memenuhi kebutuhan pengguna akhir.

• Apakah Anda berharap untuk menawarkan layanan nilai tambah per penyewa, seperti cadangan per-penyewa dan kemampuan memulihkan? Layanan seperti itu lebih mudah ditawarkan melalui pendekatan yang lebih terisolasi.

UPDATE: Selanjutnya untuk memperbarui tentang jumlah penyewa yang diharapkan.

Jumlah penyewa yang diharapkan (10k) harus mengecualikan pendekatan multi-database, untuk sebagian besar, jika tidak semua skenario. Saya tidak berpikir Anda akan menyukai gagasan mempertahankan 10.000 contoh database, dan harus membuat ratusan yang baru setiap hari.

Dari parameter itu saja, sepertinya shared-database, pendekatan skema tunggal adalah yang paling cocok. Fakta bahwa Anda akan menyimpan hanya sekitar 50MB per penyewa, dan bahwa tidak akan ada tambahan per penyewa, membuat pendekatan ini semakin tepat.

Artikel MSDN yang dikutip di atas menyebutkan tiga pola keamanan yang menangani pertimbangan keamanan untuk pendekatan database bersama:

• Koneksi Basis Data Tepercaya
• Filter Tampilan Penyewa
• Enkripsi Data Penyewa

Ketika Anda yakin dengan langkah-langkah keamanan data aplikasi Anda, Anda akan dapat menawarkan klien Anda Tingkat Layanan yang memberikan jaminan keamanan data yang kuat. Di SLA Anda, selain dari jaminan, Anda juga bisa menggambarkan tindakan yang akan Anda ambil untuk memastikan bahwa data tidak dikompromikan.

UPDATE 2: Rupanya orang-orang Microsoft pindah / membuat artikel baru tentang subjek ini, tautan asli hilang dan ini adalah yang baru: Pola tenancy basis data SaaS database multi-penyewa (pujian untuk Shai Kerer)

Pengalaman saya (walaupun SQL Server) adalah bahwa multi-database adalah cara untuk pergi, di mana setiap klien memiliki database mereka sendiri. Jadi, meskipun saya tidak memiliki pengalaman mySQL atau Ruby On Rails, saya berharap input saya dapat menambah nilai.

Alasan mengapa meliputi:

1. keamanan data / pemulihan bencana. Setiap data perusahaan disimpan sepenuhnya secara terpisah dari yang lain sehingga mengurangi risiko data dikompromikan (memikirkan hal-hal seperti jika Anda memperkenalkan bug kode yang berarti sesuatu yang keliru melihat data klien lain ketika tidak seharusnya), meminimalkan potensi kerugian pada satu klien jika satu database tertentu menjadi rusak dll. Manfaat keamanan yang dirasakan untuk klien bahkan lebih besar (efek samping bonus ditambahkan!)
2. skalabilitas. Pada dasarnya Anda akan mempartisi data Anda untuk memungkinkan skalabilitas yang lebih besar - misalnya basis data dapat disimpan ke disk yang berbeda, Anda dapat membawa beberapa server basis data daring dan memindahkan basis data lebih mudah untuk menyebarkan beban.
3. penyempurnaan kinerja. Misalkan Anda memiliki satu klien yang sangat besar dan satu yang sangat kecil. Pola penggunaan, volume data, dll. Dapat sangat bervariasi. Anda dapat menyetel / mengoptimalkan lebih mudah untuk setiap klien jika perlu.

Saya harap ini menawarkan beberapa masukan yang bermanfaat! Ada lebih banyak alasan, tetapi pikiran saya menjadi kosong. Jika kembali, saya akan memperbarui :)

EDIT:
Karena saya memposting jawaban ini, sekarang jelas bahwa kita berbicara 10.000 penyewa. Pengalaman saya ada dalam ratusan basis data skala besar - Saya tidak berpikir 10.000 basis data terpisah akan terlalu mudah dikelola untuk skenario Anda, jadi saya sekarang tidak mendukung pendekatan multi-db untuk skenario Anda. Terutama karena sekarang jelas Anda sedang berbicara volume data kecil untuk setiap penyewa!

Tetap menjaga jawaban saya di sini karena mungkin ada gunanya bagi orang lain di kapal yang sama (dengan penyewa lebih sedikit)

Di bawah ini adalah tautan ke buku putih di Salesforce.com tentang bagaimana mereka menerapkan multi-tenancy:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

Mereka memiliki 1 tabel besar dengan 500 kolom string (Value0, Value1, ... Value500). Tanggal dan Angka disimpan sebagai string dalam format sedemikian rupa sehingga dapat dikonversi ke tipe asalnya di tingkat basis data. Ada tabel data meta yang menentukan bentuk model data yang bisa unik per penyewa. Ada tabel tambahan untuk pengindeksan, hubungan, nilai unik dll.

Kenapa harus repot?

Setiap penyewa dapat menyesuaikan skema data mereka sendiri pada saat run-time tanpa harus membuat perubahan di tingkat database (mengubah tabel dll). Ini jelas cara yang sulit untuk melakukan hal seperti ini tetapi sangat fleksibel.

Seperti yang Anda sebutkan satu database per penyewa adalah pilihan dan memang memiliki beberapa trade-off yang lebih besar dengannya. Ini dapat bekerja dengan baik pada skala yang lebih kecil seperti satu digit atau 10-an rendah penyewa, tetapi di luar itu menjadi lebih sulit untuk dikelola. Keduanya hanya migrasi tetapi juga hanya dalam menjaga dan menjalankan database.

Model per skema tidak hanya berguna untuk skema unik untuk masing-masing, meskipun masih menjalankan migrasi di semua penyewa menjadi sulit dan pada 1000 dari skema Postgres dapat mulai mengalami masalah.

Pendekatan yang lebih scalable adalah benar-benar memiliki penyewa didistribusikan secara acak, disimpan dalam database yang sama, tetapi di berbagai pecahan logis (atau tabel ) Bergantung pada bahasa Anda, ada sejumlah perpustakaan yang dapat membantu dalam hal ini. Jika Anda menggunakan Rails ada perpustakaan untuk menyewa acts_as_tenant, itu membantu memastikan permintaan penyewa Anda hanya menarik kembali data itu. Ada juga permata apartment- meskipun menggunakan model skema itu tidak membantu dengan migrasi di semua skema. Jika Anda menggunakan Django ada nomor tetapi salah satu yang lebih populer tampaknya ada di seluruh skema . Semua ini membantu lebih banyak di level aplikasi. Jika Anda mencari sesuatu yang lebih langsung di tingkat basis data, Citus berfokus untuk membuat jenis sharding inimulti-tenancy bekerja lebih baik dengan Postgres.