Pada titik apa satu basis data per klien menjadi tidak layak?

31

Untuk salah satu sistem kami, kami memiliki data klien yang sensitif dan menyimpan data masing-masing klien dalam database terpisah. Kami memiliki sekitar 10-15 klien untuk sistem itu.

Namun, kami sedang mengembangkan sistem baru yang akan memiliki 50-100 klien, mungkin lebih. Saya pikir mungkin tidak mungkin memiliki satu basis data per klien dalam hal ini (untuk menyimpan catatan sensitif dan riwayat audit). Namun saya tidak tahu apakah ini normal atau tidak, atau apakah ada cara lain untuk menjaga keamanan.

Ada pemikiran tentang ini?

database-design sql-server-2012

— NibblyPig
sumber

Saya tidak tahu pro-kontra memiliki banyak basis data per server (saya tidak pernah memiliki masalah dengan itu) tetapi banyak skema konsep technet.microsoft.com/en-us/library/dd207005.aspx dalam database yang sama, menawarkan keduanya isolasi dan keamanan. Jadi, Anda dapat mencoba arsitektur ini juga.

— Alexandros

2

Pemisahan skema @Alexandros menawarkan sedikit, tetapi itu tidak memungkinkan Anda untuk menggunakan model pemulihan terpisah, membuat cadangan pada jadwal yang berbeda, mengembalikan satu klien ke titik waktu tertentu, menghapus satu klien dengan mudah, memindahkan satu klien dengan mudah, dll

— Aaron Bertrand

4

Saya telah melihat sistem dengan 3.000+ basis data (1 per klien) pada satu server. Saya tidak akan terlalu khawatir - pastikan Anda merencanakan sumber daya dengan cermat dan memantau penggunaan saat jumlah klien meningkat.

— Max Vernon

Anda dapat membaca ini, secara khusus catat tanggal dan komentar ops: stackoverflow.com/questions/5596755/…

— NotMe

48

Mengelola 100 atau 500 database benar-benar tidak jauh berbeda dari mengelola 5 atau 10 - Anda hanya perlu merangkul otomatisasi dan memiliki rencana skalabilitas (dan tidak berencana untuk menggunakan fitur database per biaya tinggi seperti mirroring di semua klien).

Pada pekerjaan saya sebelumnya, kami menggunakan arsitektur ini dan saya tidak akan pernah berpikir untuk menggabungkan dua klien menjadi satu database, meskipun beberapa tantangan bisa "sulit."

Manfaat besar adalah model pemulihan independen ( abisa sederhana, bbisa penuh, dll.), Kemampuan untuk mengembalikan ke titik waktu (atau menghapus seluruhnya) klien tanpa mengganggu orang lain, kemampuan untuk memindahkan mulus sumber daya klien berat ke penyimpanannya sendiri atau ke server yang sama sekali berbeda dengan sangat sedikit transparansi (Anda memperbarui file atau tabel konfigurasi yang memberi tahu aplikasi tempat menemukan klien itu).

Saya membahas beberapa keberatan, dan / atau cara mendekati masalah, dalam posting ini:

Itu semua mengatakan, saya tidak berpikir ada di antara kita yang bisa memberi tahu Anda titik di mana manajemen menjadi tidak praktis bagi Anda - ketahuilah bahwa apa pun tantangan spesifik yang Anda temui, Anda dapat bertanya tentang masalah-masalah itu secara individual.

— Aaron Bertrand
sumber

6

Anda juga akan memerlukan konvensi penamaan yang baik, diterapkan secara konsisten.

— Greenstone Walker

Terima kasih itu beberapa tautan yang bagus. Ini bukan masalah manajemen (saat ini), saya hanya khawatir hal-hal akan terhenti. Tapi sepertinya saya tidak perlu khawatir tentang itu dan hanya memastikan saya bisa mengatur semuanya. Jadi terima kasih!

— NibblyPig

@ Harun saya punya skenario serupa di OMS di mana saya memiliki beberapa bengkel yang memproses pesanan dan mereka independen. Lokakarya dipilih berdasarkan alamat pesanan (Pelanggan). Sehingga pelanggan dapat memiliki pesanan dalam beberapa workshpos. Jadi sulit ketika perlu memuat riwayat pesanan Pelanggan karena harus pergi pada setiap server database.

— Navrattan Yadav

15

Saya sarankan Anda membaca Arsitektur Data Multi-Tenant , kertas putih yang membahas opsi yang Anda miliki, dan pro dan kontra. Untuk meringkas, ini memberikan tiga opsi:

pisahkan DB
skema terpisah
skema bersama

Anda sekarang berada pada tahap DB terpisah, yang menawarkan pemisahan terbaik (isolasi antara penyewa), tetapi merupakan yang paling sulit untuk dikelola. Ketika Anda tumbuh menjadi ratusan penyewa, Anda akan menyadari bahwa logistik untuk mengelola 100-an DB jauh dari mudah. Pikirkan backup-restore (lokasi file yang dicadangkan, pekerjaan, jadwal dll). Pikirkan bagaimana Anda akan memantau dan mengelola alokasi file, ruang disk yang digunakan, dan pertumbuhan basis data di ratusan DB. Pikirkan skenario skenario High-Availability / Disaster-Recoverability Anda dalam waktu dekat dengan 1000 tenant? 1000 mirrored DBs, 1000 sesi pengiriman log? Pikirkan bagaimana jika dalam 6 bulan tim dev Anda mendatangi Anda dan berkata "Saya tahu bagaimana memberikan fitur yang luar biasa ini kepada produk kami, kami akan menggunakan Replikasi Transaksional!", Apa yang akan Anda katakan? "tentu, izinkan saya menyiapkan 500 penerbit,"! Bukan tidak mungkin untuk mengelola ratusan DB, tetapi jika Anda berencana untuk melakukannya, Anda lebih baik memoles keterampilan PowerShell Anda dan berhenti menggunakan alat manajemen UI sekarang .

Selain itu, Anda perlu mempertimbangkan bahwa banyak (ratusan) DB memiliki dampak yang terukur terhadap kinerja dan biaya:

ruang disk fisik kurang efisien digunakan (setiap database harus memiliki beberapa kamar kosong, Anda akan memiliki ruangan cadangan dikalikan dengan jumlah DBs)
Tidak ada cara Anda dapat membuat disk log khusus untuk tugas-tugas intensif, Anda harus memindahkan semua LDF ke satu (atau lebih) penyimpanan SSD
menulis log akan kurang efisien pada komit yang sering karena mereka tersebar di banyak catatan blok log individu vs. agregat menjadi satu (Anda akan mendapatkan blok log yang kurang dimanfaatkan). Lihat Apa itu LSN: Nomor Urutan Log untuk memahami apa yang saya bicarakan.

DB yang terpisah datang dengan beberapa keuntungan meskipun karena isolasi, keuntungan utama adalah backup / restore independen.

Skenario seperti milik Anda adalah kandidat sempurna untuk database SQL Azure . Tidak ada administrasi ruang disk, tidak perlu menyediakan HA / DR, tumbuh hingga ratusan / ribuan DB, dll.

— Remus Rusanu
sumber

Terima kasih ini beberapa saran yang bagus, terutama mungkin beralih ke model cloud. Saya harus memikirkan dengan serius bagaimana saya akan menangani masalah ini.

— NibblyPig

Dan begitu otomasi Anda dikembangkan dengan cukup baik untuk mendukung database terpisah untuk setiap klien, itu bukan lompatan besar dari sana untuk menyediakan VM terpisah untuk setiap klien. Lagi pula, inilah yang dilakukan perusahaan hosting "cloud". Setuju bahwa ini mungkin kasus penggunaan yang baik untuk SQL Azure

— Gavin Campbell

2

Di pekerjaan saya sebelumnya, kami meng-host tidak hanya satu database per klien - dalam banyak kasus, itu lebih dari itu! Ketika saya pergi, ada lebih dari 4.500 basis data yang berjalan di satu kluster MariaDB, hampir 7.000 di kluster lain (ironisnya lebih kecil), dan 4 "pecahan" (sepenuhnya terpisah, server independen dan server basis data, bahkan di pusat data yang sepenuhnya terpisah) masing-masing hosting 200-500 database dalam satu server MySQL. Dan perusahaan itu masih tumbuh dengan baik.

Panjang dan pendeknya adalah keberhasilan perusahaan itu membuktikan bahwa arsitektur semacam itu memang layak. (Peringatan: Bertolak belakang dengan keuntungan yang tampak dalam isolasi dengan menggunakan basis data terpisah, semua data diakses melalui trio aplikasi yang digabungkan secara ketat yang semuanya menggunakan pengguna basis data yang sama / lulus! Saya menduga kinerja mungkin akan sangat berkurang jika setiap klien memiliki pengguna / pass yang terpisah - tetapi hanya sedikit.)

Dari pengalaman saya bekerja sama dengan admin sys (secara teknis saya adalah seorang programmer di perusahaan, tetapi pada kenyataannya saya adalah DBA terbaik yang mereka miliki, dan satu - satunya orang yang mereka miliki yang tahu cara mengatur firewall!), Terkait kinerja kekhawatiran terkait dengan akses bersamaan, kompleksitas kueri / waktu, kinerja indeks, dll. - semua tersangka yang biasa, dengan kata lain, dan jumlah database di server tidak memainkan bagian yang dapat dilihat, kesimpulan yang ditegaskan oleh spesialis bayaran tinggi konsultan kami berkonsultasi secara teratur.

Intinya adalah bahwa Anda harus memfokuskan kekhawatiran Anda pada aplikasi Anda, pada infrastruktur Anda, dan bukan pada jumlah database yang Anda miliki. Semua faktor lain akan lebih dari cukup untuk membuat Anda sibuk menyelesaikan masalah kinerja dan kemacetan.

— Kromey
sumber