Satu Basis Data Besar vs. Beberapa Yang Lebih Kecil

Kami memiliki situasi ketika kami dapat (A) menggunakan contoh aplikasi dalam satu database MySQL menggunakan awalan tabel atau (B) menggunakan database MySQL yang berbeda untuk setiap instance aplikasi, misalnya,

Pengaturan "A":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Hasil akhirnya menjadi db besar dengan banyak tabel.

Setup "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Hasil akhirnya menjadi banyak database dengan beberapa tabel.

Semua hal sama (misalnya, jumlah data, jumlah instance aplikasi, dll), apa pro dan kontra dari pergi dengan pendekatan baik? Apa yang akan merusak kinerja dan pemeliharaan basis data? Aplikasi ini berbasis PHP 5, berjalan di atas Apache 2.x, dan kami menjalankan MySQL 5.x.

Terima kasih banyak atas waktu dan pikiran Anda!

Saya menjalankan sistem dengan bagian terbaik dari seribu database, tersebar di beberapa server. Mereka semua struktur yang identik dan disinkronkan dengan database templat yang ada di masing-masing mesin.

Ini memungkinkan saya kemampuan untuk memigrasi basis data dari satu db ke yang lain jika salah satu kelebihan beban, dan ketika campuran klien berubah, saya bisa membuat basis data baru di server yang berbeda untuk memuat keseimbangan di seluruh server. Ini adalah keuntungan terbesar yang saya dapatkan dari sistem, karena saya memiliki beberapa gumpalan besar timah yang melakukan beberapa pertanyaan rumit secara bersamaan di server yang terpisah.

Hal yang hebat tentang ini, adalah Anda dapat menambahkan server ke konfigurasi dengan kecepatan Anda sendiri, karena setiap server mulai kelebihan beban, menambahkan yang lain ke dalam campuran, memigrasi beberapa dbs ke server baru dan berakhir dengan baik memuat set server yang seimbang. Cara yang sangat bagus dan sederhana untuk menambah skala ke sistem sebagaimana dan ketika diperlukan!

Alasan saya pergi dengan pendekatan ini daripada pendekatan database tunggal besar, adalah ukuran semata-mata dari database potensial yang akan dibuat ... masing-masing dari 1000 database memiliki 200 tabel, dan banyak tabel individual dalam masing-masing basis data terdiri dari ratusan juta baris data!

Konfigurasi database tunggal akan membutuhkan tabel tertentu (kira-kira 8 dari mereka) untuk memiliki multi-miliaran baris data, dan ukuran total db akan lebih dari 10Tb. Kami dapat memiliki beberapa server dengan 5Tb penyimpanan RAID 10, dengan banyak database masing-masing.

Itu yang akan saya lakukan! Semoga ini membantu pengambilan keputusan Anda ... :)

Apakah aplikasi yang Anda sedang membangun aplikasi SaaS? Jika demikian, saya akan menyarankan Anda mempertimbangkan pendekatan ketiga - memiliki satu DB, dengan struktur umum untuk semua contoh aplikasi dengan satu perbedaan - tambahkan kolom userid / applicationid di semua tabel. Ini akan sangat mengurangi biaya pengembangan / pemeliharaan aplikasi Anda. Ini menurut pengalaman saya adalah salah satu pendekatan terbaik untuk menyimpan data multi-tenant.

Lihat juga kertas putih hebat dari Microsoft tentang arsitektur data multi-tenant

Ini juga menyoroti keuntungan / kerugian dari pendekatan yang telah Anda sebutkan.

Pengaturan B adalah cara yang lebih mudah untuk dikelola

Masing-masing tablenduduk di folder yang berbeda. Itu bisa sangat bermanfaat jika Anda tidak ingin menguji batas OS .

Misalnya, majikan saya meng-host MySQL untuk sistem CRM dari dealer mobil. Klien memiliki 800 dealer. Setiap database dealer memiliki 160 tabel. Itu 128.000 tabel.

• Di bawah Pengaturan A, semua 128.000 tabel akan berada di bawah satu basis data.
• Di bawah Pengaturan B, setiap set 160 tabel berada di dalam subfolder di bawah / var / lib / mysql.

Dari perspektif OS dan kemampuannya untuk menangani simpul-i (atau tabel FAT untuk Windows), yang termasuk memiliki jumlah maksimum file per folder:

• Di bawah Pengaturan A, Anda akan khawatir tentang 128.000 file di bawah satu folder. Dapatkah OS Anda mendukung banyak file di bawah satu folder?
• Di bawah Pengaturan B, tidak perlu khawatir.

Jika Anda harus tweek struktur tabel menggunakan ALTER TABLEatau beberapa DDL lainnya:

• Di bawah Pengaturan A, Anda harus membuat skrip DDL yang diperlukan menggunakan PHP (atau skrip MySQL khusus) dengan nama tabel spesifik dan kueri terkait sebelum mengaksesnya dan membuat perubahan
• Di bawah Pengaturan B, Hubungkan ke database yang tepat, lalu akses tabel yang sama setiap kali. Paradigma akses akan selalu bersih:
  • Database khusus
  • Folder spesifik di bawah /var/lib/mysql
  • Nama Tabel Specfic.

Jika Anda ingin meletakkan basis data yang berbeda pada disk yang berbeda:

• Di bawah Pengaturan A, symlink untuk setiap tabel yang dipindahkan ke disk terpisah hanya akan memperburuk masalah "jumlah inode dalam folder". Disk I / O dan akses tabel keseluruhan menjadi lebih rumit dan meningkatkan beban server keseluruhan karena .frmfile diakses berulang kali.
• Di bawah Pengaturan B, cukup pindahkan folder keseluruhan basis data ke dalam mount data terpisah. Disk I / O dapat didistribusikan sesuai permintaan.
• CAVEAT: Sangat tidak disarankan untuk InnoDB

Berbicara secara metaforis, mana yang lebih Anda sukai?

• sebuah apartemen raksasa dengan satu kamar tidur, satu kamar mandi dan satu dapur (SetupA)
• beberapa apartemen, masing-masing dengan kamar tidur, kamar mandi dan dapur sendiri (SetupB)

Ketika datang untuk memperbaiki radiator di apartemen:

• Dengan Setup A, setiap penyewa dapat merasa tidak nyaman dan harus terlibat karena Anda harus berbicara dengan penyewa yang terkena dampak di depan semua orang seperti itu urusan semua orang
• Dengan Pengaturan B, selain mendengar suara gedoran di dinding atau pipa, penyewa dapat melanjutkan kehidupan pribadi mereka
• Daftar ini dan metafornya dapat berlanjut dan terus

IHMO Meskipun anggaran mungkin merupakan kekuatan pendorong untuk keputusan desain / infrastruktur, saya akan dengan mudah mendukung pemisahan database per klien.

Saya juga memiliki produk SaaS dan menggunakan pengaturan yang sama seperti yang disebutkan Dave Rix.

Setiap pelanggan memiliki database mereka sendiri

Saya akan membuat beberapa saran lagi:

• Anda harus memiliki database "controller" load-balanced (master-master), yang menyimpan lokasi basis data (ip), nama basis data, dan nama pelanggan. Pengontrol ini adalah tempat aplikasi Anda tahu di mana setiap basis data pelanggan.

• Aplikasi Anda dapat di mana saja Anda inginkan - Anda dapat memiliki basis data untuk banyak pusat data di seluruh dunia.

• Aplikasi Anda dapat tumbuh sebanyak yang Anda inginkan. Jika ini adalah SaaS Web, Anda bisa membuat layanan webserver yang seimbang yang menunjuk ke masing-masing database, sesuai waktu ketika pelanggan masuk.

• Anda dapat membuat VIEW / Database khusus untuk beberapa pelanggan - tanpa memengaruhi yang lain. Itu penting jika Anda mencoba menawarkan penyesuaian sebagai bagian dari bisnis Anda.

• Anda dapat mengatur dua peternakan web + peternakan basis data: satu untuk "EDGE" dan satu lagi untuk rilis "STABIL". Kemudian, Anda harus memiliki sekelompok kecil pelanggan yang mau menguji sesuatu dan mengonfirmasi bahwa semuanya berfungsi seperti yang diharapkan (dengan kata lain, jaminan kualitas [QA]), sebelum Anda berlaku untuk semua pelanggan Anda.

• Anda harus memiliki pekerjaan pencadangan otomatis per basis data setidaknya sekali sehari.

• Anda harus memiliki server lain untuk melakukan replikasi. Host yang sama dapat mereplikasi banyak basis data (menggunakan port yang berbeda untuk setiap server pada host yang sama) jika Anda tidak mampu membeli server host "master" dan "slave" dengan jumlah yang sama.

  Sebagai contoh, 5 server master + 1 server slave dengan 5 database yang berjalan pada port yang berbeda - cukup RAM untuk melakukannya.

• Anda harus melakukan alat "migrasi" untuk memindahkan satu basis data ke server lain kapan saja Anda mau.

• Anda harus memigrasikan pelanggan VIP ke server database yang lebih aman / tersedia agar pendapatan Anda terlindungi. Ingat, seringkali 20% pelanggan mewakili 80% dari pendapatan Anda. Jaga pelanggan khusus.

• Anda harus memiliki kolektor "hapus" pencadangan cadangan, untuk melakukan "pencadangan terakhir" dan menghapus basis data ketika pelanggan meninggalkan perusahaan Anda.

• Anda harus memiliki gambar basis data tempat Anda mengekspor dan menggunakan akun baru.

• Anda harus memiliki alat tambalan basis data untuk menerapkan tambalan baru ke akun yang ada.

• Simpan versi semua tambalan SQL Anda, menggunakan alat versi seperti subversi atau git dan buat penomoran Anda sendiri. xxx-4.3.0.sql - terkadang penambalan salah dan Anda harus tahu cara memulihkan / menyelesaikan tugas penambalan.

Nah, ini semua saya lakukan di perusahaan saya dengan produk yang memiliki sekitar 5k database dengan masing-masing sekitar 600 tabel.