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


129

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).


1
"Multi-Skema tampaknya dirancang untuk memiliki tabel yang sedikit berbeda untuk setiap penyewa" Jadi? Apa yang salah dengan multi-skema dan semua tabel yang sama? Apakah Anda mengatakan Anda tidak ingin membuat ulang struktur tabel yang identik di semua skema? Atau apakah Anda mengatakan bahwa Anda tidak dapat membuat struktur identik di semua skema?
S.Lott

+1 untuk pertanyaan baik / menarik
AdaTheDev

2
@ S.Banyak Saya harapkan 10.000+ penyewa dengan 100+ pendaftaran setiap hari. Memiliki jutaan entri dalam satu tabel definisi (definisi = dibagi, data = terisolasi) membuat saya merasa lebih baik daripada memiliki ribuan entri dalam ribuan definisi tabel. Karena tidak banyak orang yang melakukannya dengan cara itu saya tidak begitu percaya diri dengan multi-skema.
Marcel Jackwerth

1
Saya setuju dengan Daniel, multi-database dikecualikan berdasarkan angka-angka itu. Saya telah memperbarui jawaban saya untuk mencerminkan hal itu, tetapi menyimpannya lebih untuk sejarah. Pendekatan bersama jelas merupakan pendekatan yang paling masuk akal.
AdaTheDev

2
dari dynjo dalam sebuah jawaban: " Artikel bagus dari Ryan Bigg tentang topik yang pasti"
Félix Gagnon-Grenier

Jawaban:


95

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:

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)


1
Oh, saya memindai artikel itu kemarin dan melewatkan bagian kesalahpahaman itu. Perlu membacanya lagi.
Marcel Jackwerth

1
@ Marscel: Namun, terlepas dari apa persepsi pelanggan tentang keamanan, saya yakin keputusan Anda tentang pendekatan multi-tenant mana yang akan diambil harus didasarkan pada faktor-faktor seperti 4 poin yang saya kutip dari artikel MSDN: 1. Jumlah penyewa yang diharapkan . - 2. Persyaratan penyimpanan yang diharapkan untuk setiap penyewa. - 3. Jumlah pengguna akhir bersamaan yang diharapkan. - 4. Add-on per-tenant yang diharapkan.
Daniel Vassallo

1
Terima kasih telah menunjukkan bagian itu. Angka = 10k, Penyimpanan = 50mb, Pengguna Akhir Bersamaan = 2 per penyewa, Addons = 0. Jadi situasi saat ini memiliki pendekatan bersama tampaknya menjadi yang paling masuk akal. Saya pikir saya akan melakukan beberapa panggilan minggu depan untuk mencari tahu apa yang benar-benar dibutuhkan / diharapkan pelanggan. Jerman dan keamanan data / TI adalah kisah yang sangat sulit.
Marcel Jackwerth

1
Hanya untuk pengguna yang membaca ini mulai sekarang, artikel yang disebutkan tidak ada lagi, seseorang membuat salinan, mungkin?
gmslzr

1
@guillesalazar Saya tidak yakin ini sama tapi saya kira itu - docs.microsoft.com/en-us/azure/sql-database/… (@DanielVassallo jika itu sama, mungkin pertimbangkan memperbarui tautan di Anda jawaban :-))
Shai Kerer

20

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)


Ya, maaf saya tidak mengklarifikasi itu sebelumnya. Masih +1. ;)
Marcel Jackwerth

berbicara tentang keamanan data, akankah Anda mengatakan bahwa setiap basis data harus ditempatkan pada server / VM yang terpisah? atau memiliki semua database di server tunggal / berkerumun dengan pengguna sql yang berbeda cukup aman?
Shay

@Shay - Tidak, tidak perlu menempatkannya di server terpisah - bayangkan Anda memiliki 100-an, itu adalah banyak contoh server / lisensi yang Anda perlukan untuk memulai. Lihat jawaban Daniel lebih jauh, ada beberapa tautan bagus di sana.
AdaTheDev

Saya berpendapat kembali bahwa meskipun multi-DB berarti 10.000 database terpisah dan gilirannya meningkatkan biaya perawatan secara signifikan, Anda masih dapat menjinakkan binatang buas ini menggunakan skrip otomatisasi di atas infrastruktur cloud Anda sehingga semuanya menjadi dikelola secara terprogram, membutuhkan sedikit atau tidak ada upaya manusia sama sekali
Korayem

17

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.


10

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.

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.