it-swarm.asia

Masalah apa yang akan saya dapatkan dalam membuat basis data per pelanggan?

Saya ingat dari podcast stackoverflow yang Fog Creek menggunakan database per pelanggan untuk Fogbugz . Saya berasumsi itu berarti server Fogbugz On Demand memiliki 10s dari ribuan database.

Kami baru mulai mengembangkan aplikasi web dan memiliki masalah yang sama untuk dipecahkan (banyak pelanggan dengan data terisolasi mereka sendiri).

Masalah apa yang harus saya harapkan dengan menggunakan database per pelanggan? Bagaimana saya bisa menyelesaikannya?

Pikiran Awal Saya

Keuntungan dari basis data per pelanggan

  • Skema basis data yang lebih sederhana
  • Cadangan yang lebih sederhana - Anda dapat membuat cadangan setiap pelanggan tanpa benar-benar berdampak pada pelanggan lain.
  • Memudahkan untuk mengekspor data pelanggan yang diberikan.
  • Kinerja cache yang lebih baik - penulisan ke salah satu tabel yang lebih aktif hanya berdampak pada satu pelanggan yang melakukan penulisan.
  • Lebih mudah untuk mengukur seluruh perangkat keras. Misalnya, ketika kita perlu beralih dari 1 ke 2 server, kami hanya memindahkan setengah pelanggan kami ke server baru.

Kerugian

  • Bisakah MySQL mengatasi 5.000 basis data? Akankah kinerja payah?
  • Perubahan skema mungkin sulit untuk ditiru di semua database. Kami benar-benar harus memiliki rencana otomatis untuk ini, seperti versi skema dan skrip yang mengerti cara mengambil database dari satu versi ke versi lain.
  • Melakukan sesuatu yang umum bagi semua pelanggan kami mungkin canggung atau tidak mungkin
  • Mirip dengan di atas, tetapi analitik apa pun yang ingin kami lakukan di semua pelanggan kami mungkin tidak mungkin. Bagaimana seharusnya kita melacak penggunaan di semua pelanggan misalnya?
49
Rik Heywood

Solusi ini disebut desain multi-penyewa di mana setiap penyewa (pelanggan) memiliki database mereka sendiri. Mengingat bahwa, ada beberapa pertimbangan lain untuk pendekatan alternatif yang merupakan basis data tunggal:

  1. Dengan satu basis data, setiap orang harus memiliki versi yang sama apa pun yang terjadi. Tidak mungkin meningkatkan beberapa pelanggan dan bukan yang lain. Ini bisa bermasalah jika pelanggan menginginkan perbaikan terbaru dari aplikasi yang tidak siap untuk rilis luas.
  2. Dengan satu basis data, saat Anda melakukan peningkatan, setiap klien tidak aktif. Jika terjadi kesalahan, setiap klien kacau.
  3. Dengan satu basis data, jauh lebih sulit untuk membatasi sumber daya. Yaitu, jika satu klien memalu basis data, lebih sulit untuk memberi mereka lebih banyak sumber daya terpisah dari orang lain.
  4. Jauh lebih sulit untuk mengizinkan pengguna untuk Host versi mereka sendiri dari aplikasi Anda. Jika Anda membangun solusi yang akan digunakan oleh perusahaan besar, ini sering kali bukan pemula. Departemen TI mereka ingin kontrol penuh atas akses ke sistem.
  5. Mungkin lebih murah untuk memperbesar basis data daripada meningkatkannya. Yaitu, harus berinvestasi dalam perangkat keras yang lebih cepat untuk menjadi tuan rumah satu basis data untuk memerintah mereka semua mungkin lebih mahal daripada mampu mengubah skala pelanggan ke server basis data yang lebih kecil dan lebih murah. Saya tidak dapat mengatakan ini secara definitif karena sangat tergantung pada perangkat lunak server. Jika Anda tetap menggunakan MySQL, ini mungkin benar karena biaya lisensi dapat diabaikan. Namun, jika Anda beralih ke SQL Server misalnya, penskalaan menjadi jauh lebih mahal kecuali jika Anda menggunakan lingkungan VPS dan manfaat biaya dari penskalaan vs penskalaan perubahan. Saya dapat mengatakan, bahwa begitu database Anda menjadi sangat besar, manajemen membutuhkan tingkat keahlian yang semakin besar. Basis data yang sangat besar membutuhkan bermain-main dengan beberapa grup file dan mendorong indeks tertentu ke spindle yang berbeda untuk mendapatkan kinerja yang lebih baik. Singkatnya, mereka bisa rumit dengan sangat cepat.

Memiliki database yang terpisah berarti Anda harus membangun mekanisme pembaruan yang cocok dengan versi database dengan versi aplikasi/situs. Namun, database terpisah memang menyediakan isolasi data yang superior dan IMO memiliki biaya hosting yang lebih rendah. Itu bukan solusi untuk semua skenario. Jika sistem Anda tidak akan di-host di luar hosting Anda dan perlu meningkatkan pelanggan dengan cepat dan memiliki semua pengguna pada versi aplikasi yang sama dan skema database diinginkan, maka tentu saja memiliki satu database adalah pendekatan yang lebih baik.

42
Thomas

Dalam pengalaman saya, Anda tidak harus membuat satu database per pelanggan. Biarkan saya memberi Anda sebuah contoh:

Tahun lalu saya bekerja dengan 70 basis data (jauh lebih sedikit dari 5000), masing-masing dengan skema yang sama dan semuanya. Secara teori, segala sesuatunya berjalan sesuai rencana (seperti yang Anda sebutkan di bagian kelebihan), tetapi kenyataannya tidak begitu banyak. Kami memiliki banyak masalah dengan memperbarui skema, dukungan pengguna, pembaruan perangkat lunak, apa saja. Itu mengerikan.

Kami menggunakan Firebird dan saya dipekerjakan setelah produk dikirim, tetapi ini memberi saya pengetahuan untuk tidak pernah bekerja dengan basis data yang terpisah.

Saya tidak mengatakan Anda tidak bisa melakukannya, saya katakan semuanya bisa sangat salah dan jujur, daftar keuntungan Anda tidak terdengar cukup menarik untuk mengambil risiko. Sebagian besar dari mereka dapat dicapai dengan satu basis data.

14
eiefai

Anda mungkin ingin menyimpan basis data lain untuk melacak versi masing-masing pelanggan, sehingga Anda dapat melacak yang mana yang sudah atau belum menjalani putaran terakhir modifikasi.

Membuat skrip pemutakhiran tidak akan sesulit itu ... Anda bisa menulis sesuatu yang terlihat di katalog basis data dan menerapkan perubahan yang diperlukan untuk membuat setiap basis data ke versi terbaru, mungkin melewatkan yang tidak boleh ditingkatkan karena alasan tertentu.

Karena 'database' mysql hanyalah skema, seperti yang ditunjukkan Gayus, jika semuanya berjalan dari instance server yang sama, Anda bisa saja memenuhi syarat nama tabel yang Anda coba modifikasi, atau dapatkan informasi dari:

alter schema.table ...
select ... from schema.table

...

Jika Anda mulai memecah banyak hal di beberapa server, Anda masih bisa membuat skrip sesuatu yang membuat koneksi ke beberapa server sehingga Anda dapat menerapkan semua perubahan; untuk analitik, sekali lagi, Anda dapat mengatur sekelompok tautan basis data menggunakan tabel gabungan di basis data master Anda untuk mengakses data dari satu tempat, karena Anda hanya akan membaca dari tabel.

...

Perlu diketahui juga bahwa mereka tidak menggunakan mySQL untuk pertukaran tumpukan, mereka menggunakan SQL Server.

Dan saya tidak tahu seperti apa overhead kinerja di mysql pada skala itu, saya tidak berpikir saya pernah melewati 30 'database' di mysql.

9
Joe

Saya memiliki klien Web/DB Hosting yang memiliki 750+ basis data pelanggan dengan jumlah tabel yang sama (162) dan struktur tabel yang sama. Gabungan, semua data pelanggan klien saya total 524GB (95% InnoDB)

Bayangkan semua database ini bersaing untuk 13G pool buffer innodb pada sembilan server DB melalui replikasi melingkar. Melakukan scaling dengan konfigurasi perangkat keras itu tidak cukup. Segera, kami merekomendasikan kepada klien untuk meningkatkan.

Baru-baru ini kami memigrasikan klien ini ke 3 server DB dengan tenaga kuda yang jauh lebih banyak (Bagaimanapun, jauhi SSD di lingkungan menulis tinggi, SELALU !!!). Kami memutakhirkannya dari MySQL 5.0.90 ke MySQL 5.5.9. Perbedaan dramatis terlihat hampir secara instan.

Menskalakan juga harus dipertimbangkan karena jika Anda memiliki ratusan klien yang memukul memori dan sumber daya disk yang sama, penskalaan mengurangi penggunaannya secara linear (O (n)) di mana n didasarkan pada jumlah server DB dalam lingkungan multimaster.

Dalam kasus klien saya, perusahaan saya mengurangi dia dari 9 server DB (Kode Quad, 32GB RAM, 824G RAID10) menjadi server DB lebih cepat (Dual HexaCore [itu benar 12 CPU], RAM 192GB, 1.7TB RAID10) dari MySQL 5.5 .9 (ke tabel manfaatkan beberapa CPU). Selain itu, bayangkan 150GB innodb buffer pool di 50 partisi masing-masing 3GB (Multiple InnoDB buffer pool adalah fitur baru di MySQL 5.5). Skala yang lebih kecil, tetapi peningkatan yang besar, telah berhasil untuk infrastruktur unik klien saya.

MORAL OF THE STORY: Memperbesar atau memperkecil tidak selalu merupakan solusi jika Anda memiliki tabel yang didesain dengan buruk. Maksud saya adalah ini: Jika halaman indeks memiliki populasi kunci miring untuk indeks multikolom, meminta kunci dari bagian miring indeks mengarah ke pemindaian tabel setelah pemindaian tabel, atau setidaknya indeks yang tidak pernah digunakan karena dikesampingkan oleh Permintaan MySQL. Pengoptimal. Tidak ada pengganti untuk desain yang tepat.

7
RolandoMySQLDBA

MySQL membuat database dalam direktori terpisah sehingga sangat tergantung pada sistem operasi yang mendasarinya dan berapa banyak folder/file yang dapat ditangani. Seharusnya tidak menjadi masalah dengan sistem operasi modern tetapi di situlah banyak kemacetan akan datang.

2
David Hall

Tidak ada yang mengatakan Anda harus Host versi yang berbeda dari database atau aplikasi. Apa yang salah dengan hanya mengisolasi data dengan melakukan satu db per pelanggan dan memiliki satu versi database dan aplikasi? Tentu saja setiap pelanggan db harus dikloning dari templat versi kerja saat ini. Dari sudut pandang keamanan dan isolasi data, saya pikir ini ideal.

Satu-satunya downside yang saya lihat adalah Anda harus memperbarui setiap basis data secara manual saat membuat versi baru. Ini bisa dengan mudah diotomatisasi.

1
Sean Siegel