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

Saya ingat dari podcast stackoverflow bahwa 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 mereka sendiri yang terisolasi).

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
• Pencadangan 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 lintas perangkat keras. Misalnya, ketika kita perlu beralih dari 1 ke 2 server, kami hanya memindahkan setengah pelanggan kami ke server baru.

Kekurangan

• Bisakah MySQL mengatasi 5.000 database? Akankah kinerja payah?
• Perubahan pada skema mungkin sulit untuk ditiru di semua basis data. Kami benar-benar harus memiliki rencana otomatis untuk ini, seperti membuat 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?

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, ketika Anda melakukan peningkatan, setiap klien tidak aktif. Jika ada yang salah, setiap klien kacau.
3. Dengan satu basis data, jauh lebih sulit untuk membatasi sumber daya. Yaitu, jika satu klien memalu database, lebih sulit untuk memberi mereka lebih banyak sumber daya terpisah dari orang lain.
4. Jauh lebih sulit untuk mengizinkan pengguna meng-host versi aplikasi Anda sendiri. 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 meng-host satu database untuk memerintah mereka semua mungkin lebih mahal daripada mampu skala pelanggan ke server database yang lebih kecil, 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 banyak grup file dan mendorong indeks tertentu ke spindle yang berbeda untuk mendapatkan kinerja yang lebih baik. Singkatnya, mereka bisa rumit dengan sangat cepat.

Memiliki basis data 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 yang sama dari aplikasi dan skema database diinginkan, maka tentu saja memiliki satu database adalah pendekatan yang lebih baik.

Dalam pengalaman saya, Anda seharusnya tidak 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 keunggulan), 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 dapat melakukannya, saya mengatakan hal-hal bisa menjadi sangat salah dan jujur, daftar keuntungan Anda tidak terdengar cukup menarik untuk mengambil risiko. Sebagian besar dari mereka dapat dicapai dengan satu basis data.

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 seharusnya 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 bisa mengatur banyak tautan basis data menggunakan tabel gabungan dalam basis data master Anda untuk mengakses data dari satu tempat, karena Anda baru saja membaca dari tabel.

...

Perlu diketahui juga bahwa mereka tidak menggunakan mySQL untuk pertukaran stack, 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.

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.

Kami baru-baru ini 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) ke server DB yang 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 : Meningkatkan 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 indeks yang miring mengarah ke pemindaian tabel setelah pemindaian tabel, atau setidaknya indeks yang tidak pernah digunakan karena dikesampingkan oleh Kueri MySQL. Pengoptimal. Tidak ada pengganti untuk desain yang tepat.

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

Tidak ada yang mengatakan Anda harus meng-host versi 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.