Kami sedang membangun platform web yang menggabungkan beberapa layanan, masing-masing dengan data dasarnya sendiri. Layanan ini sedang dibangun secara independen mengikuti prinsip Arsitektur Berorientasi Layanan , tetapi mereka bertransaksi terhadap data yang berpotensi terkait. Kami sedang mempertimbangkan apakah layanan ini harus berbagi satu basis data besar atau masing-masing memiliki basis data sendiri. (Kami berencana untuk menggunakan SQL Server 2008 Enterprise pada cluster Windows 2008.)

Beberapa keuntungan untuk setiap pendekatan yang telah kami pertimbangkan meliputi:

Database tunggal

• Menghubungkan data dari berbagai layanan dapat diikat bersama oleh batasan kunci asing
• Ekstrak analitik lebih mudah ditulis dan dieksekusi lebih cepat
• Jika terjadi bencana, mengembalikan platform ke kondisi yang konsisten lebih mudah
• Untuk data yang direferensikan oleh beberapa layanan, data yang di-cache oleh satu layanan kemungkinan akan digunakan segera setelah oleh layanan lain
• Administrasi dan pemantauan lebih sederhana dan lebih murah di muka

Banyak Database

• Pekerjaan pemeliharaan, masalah perangkat keras, pelanggaran keamanan dan sebagainya tidak selalu berdampak pada seluruh platform
• Dengan asumsi setiap basis data berada pada perangkat keras terpisah, meningkatkan beberapa mesin menghasilkan lebih banyak manfaat kinerja daripada meningkatkan satu besar

Dari perspektif operasional, apakah lebih menguntungkan bahwa setiap layanan dalam platform ini mendapatkan basis datanya sendiri, atau bahwa mereka semua masuk dalam database yang sama? Faktor kunci apa yang menginformasikan jawaban untuk pertanyaan ini?

Menurut pendapat saya, pembeda utama dari sistem SOA sejati (lebih dari SOA semu, sistem ntier / terdistribusi yang menjadi mana-mana) adalah harus ada nol interaksi antara layanan diskrit. Ketika hal ini tercapai, aplikasi apa pun yang Anda buat dari layanan ini dapat dan harus dibangun untuk mentolerir kegagalan setiap bagian yang konsisten. Kegagalan mengurangi fungsionalitas tetapi layanan tetap dipertahankan.

Dalam skenario ini logis, atau diperlukan, untuk memisahkan basis data yang mendasari untuk setiap layanan. Namun jika Anda memiliki layanan yang saling tergantung, ada sedikit (mungkin tidak ada) yang bisa diperoleh dari split.

Saya akan merekomendasikan membaca situs-situs seperti HighScalability.com yang menggali arsitektur yang diadopsi oleh situs-situs bertipe tidak pernah gagal. Salah satu favorit saya akhir-akhir ini adalah kisah Netflix Chaos Monkey yang disebutkan di Coding Horror .

Mengatasi beberapa poin dalam pertanyaan Anda:

Jika terjadi bencana, mengembalikan platform ke kondisi yang konsisten lebih mudah.

Ini benar tetapi Anda mungkin harus berpikir tentang cara memisahkan layanan ini dengan lebih baik sehingga ini berhenti menjadi masalah. Atau, ada metode untuk memastikan sinkronisasi di beberapa basis data, misalnya tanda transaksi di SQL Server .

Untuk data yang direferensikan oleh beberapa layanan, data yang di-cache oleh satu layanan kemungkinan akan digunakan segera setelah oleh layanan lain.

Solusi cache terdistribusi (memcached et al) dapat membantu di sini tetapi Anda akan melanggar prinsip independensi layanan. Ini akan sebanding dengan memiliki dua layanan berkomunikasi satu sama lain secara langsung, atau lebih buruk lagi memiliki akses layanan lain menyimpan data, melewati antarmuka layanan sama sekali. Tidak dapat dihindari bahwa data akan terkait dan akan diserahkan di antara layanan dengan platform panggilan, keputusan sulit cenderung berada di sekitar layanan mana yang akan memiliki bagian data mana. Situs StackOverflow atau Programmer mungkin lebih baik ditempatkan untuk membantu dengan masalah SOA yang lebih umum.

Dengan asumsi setiap basis data berada pada perangkat keras yang terpisah, meningkatkan skala menghasilkan lebih banyak manfaat kinerja.

Tentu saja bisa lebih murah untuk meningkatkan skala pada beberapa mesin dengan spesifikasi lebih rendah daripada meningkatkan satu mesin. Meskipun, biaya perangkat keras yang lebih rendah dapat dikerdilkan dalam total biaya kepemilikan ketika biaya lunak dari upaya pengembangan tambahan dan kompleksitas operasional diperhitungkan.

Jika ini bukan SOA dan Anda hanya memiliki kasus di mana layanan komponen platform ini sedang dibangun oleh tim / pemasok yang berbeda untuk alasan logistik, tetap dengan database tunggal dan sepenuhnya mengabaikan semua yang di atas! :)