it-swarm.asia

Pro / Kontra menggunakan banyak basis data vs menggunakan satu basis data tunggal

Saya sedang mengerjakan sebuah proyek baru yang memiliki persyaratan untuk menggunakan 7 database, dengan alasan bahwa kinerja, stabilitas, optimasi lebih mudah diimplementasikan.

Meskipun saya tidak setuju, saya mengalami kesulitan mengumpulkan argumen yang bagus untuk menggunakan database tunggal (memecah tabel menjadi domain logis).

Satu argumen yang saya miliki sejauh ini adalah integritas data (saya tidak bisa menggunakan kunci asing di antara basis data).

Apa pro/kontra yang baik untuk menggunakan database tunggal atau ganda?

[ringkasan sejauh ini]

Argumen terhadap banyak basis data:

  • Kehilangan integritas data (tidak dapat menggunakan kunci asing di atas basis data)

  • Kehilangan mengembalikan integritas

  • Mendapatkan kompleksitas (pengguna/peran db)

  • Server/database peluang kecil akan turun

Solusi:

  • Gunakan skema untuk memisahkan domain.

  • POC: Gunakan data dummy untuk membuktikan poin dalam rencana eksekusi 7/1 db

14
rdkleine

Tidak ada kinerja, stabilitas, optimasi yang benar. Adakah yang punya argumen kuat atau artikel referensi mengapa ini benar?

Sumber daya tidak dialokasikan ke database: SQL Server Instance menyeimbangkan sumber daya sehingga membuat tidak ada perbedaan

Kamu kalah:

  • integritas data
  • mengembalikan integritas (data dalam DB7 akan lebih baru dari DB1)

Anda mendapatkan kompleksitas:

  • keamanan (pengguna, peran dll) harus ada di semua basis data
  • anda akan memiliki beberapa data yang tidak sesuai dengan 1 basis data dengan baik

Pilihan:

  • memisahkan database ke disk terpisah dapat dilakukan dengan filegroup
  • menggunakan skema untuk memisahkan data secara logis (berdasarkan jawaban lain)
16
gbn

Jika Anda setelah membagi data dengan domain logis Anda selalu dapat melihat menggunakan skema dalam SQL2008 (menjauh dari default dbo.) Tetapi bahkan itu menyakitkan dan dapat menyebabkan masalah dengan OR/Ms yang tidak mengharapkan non skema-standar.

Saya sudah dalam posisi mengumpulkan data dari lebih dari satu database dan itu menyakitkan dan jauh dari kinerja tinggi. Anda akhirnya menyimpan data cache atau setidaknya menggunakan trik untuk mempertahankan kecepatan.

Sebagai tes, buat 7 database dummy. Buat kueri yang membutuhkan data secara bersamaan dari semua 7, atau setidaknya jumlah yang baik.

Kemudian bandingkan rencana eksekusi! Saya pikir Anda akan memenangkan kasus Anda di sana.

6
CResults

Alasan yang baik untuk membuat database terpisah adalah untuk mendukung persyaratan ketersediaan yang berbeda atau menyederhanakan administrasi. Misalnya, jika basis data Anda memerlukan jadwal pencadangan yang sangat berbeda atau model pemulihan yang berbeda. Alasan lain adalah jika Anda ingin menjalankannya pada contoh berbeda.

Tidak ada optimisasi kinerja yang tersedia dengan banyak basis data yang tidak dapat Anda capai dengan satu basis data. Bisakah Anda memberikan detail lebih lanjut tentang apa yang Anda maksud dengan "kinerja, stabilitas, optimisasi"?

6
nvogel

Eksperimen pemikiran: Alih-alih membagi basis data Anda menjadi tujuh bagian, bagilah menjadi 7.000 bagian. Apa kemungkinan kegagalan perangkat keras akan berdampak pada aplikasi Anda? Jika ada kemungkinan 0,1% bahwa server mana pun bisa mati pada hari tertentu, apakah peluang Anda lebih baik atau lebih buruk bahwa Anda akan terkena dampak kegagalan perangkat keras saat menambah jumlah mesin yang Anda andalkan?

Saya pikir ini penting untuk membagi gagasan "database" menjadi dua bagian: skema dan data vs. perangkat keras yang digunakan untuk melayani data.

Memecah basis data di beberapa mesin tidak ada gunanya karena banyak alasan yang dijelaskan oleh jawaban lain dalam topik ini.

Jika Anda akan menggunakan beberapa mesin untuk keandalan dan peningkatan kinerja, mungkin Anda dapat menyusunnya sehingga Anda memiliki server master dengan beberapa mesin siaga panas/panas yang juga dapat digunakan untuk mendistribusikan kueri ke seluruh. Dengan cara ini jika ada satu mesin mengalami kegagalan, Anda tidak kehilangan data, dan paling buruk Anda harus me-restart permintaan. Tentu saja, ini lebih kompleks dari ini, tetapi dasar-dasarnya memang berlaku.

4
unpythonic

Saya setuju dengan satu DB dan menggunakan opsi file dan skema sebagai gantinya.

Ada kasus Tepi di mana pemisahan menjadi beberapa bagian masuk akal.

Konfigurasi lingkungan aplikasi (dev, test, prod), seperti server FTP, jalur file ekspor, dll ..., Hal-hal yang ingin Anda simpan per server, dan tidak ditimpa pada pengembalian.

Juga sebagai cara untuk mengisolasi perubahan prosedur spesifik klien.

Tetapi ini adalah dukungan dan bukan masalah kinerja.

2
Rawheiser