Bisakah SQL Server dan Mongo digunakan bersama?


14

Kami memiliki situs berorientasi berita besar yang memiliki lalu lintas web yang tinggi. Arsitekturnya adalah DB - Repo Layer - Layer Layanan - Asp.Net MVC yang sering Anda lihat. Masalah yang kami lihat adalah seputar kinerja baca. Ternyata semua ini objek objek DDD besar, secara teori, untuk aturan bisnis, tetapi telah membuat hidup lebih sulit ketika datang untuk mengoptimalkan kinerja membaca.

Sebagai solusi, saya sedang mempertimbangkan sesuatu yang sama sekali baru (bagi kami): menggunakan noSQL. Saya ingin menggunakan database noSQL untuk data yang disajikan di situs web kami. Kami tidak dapat menyingkirkan SQL Server kami (setidaknya tidak dalam waktu dekat), tetapi bagi saya tampaknya langkah praktis adalah menggunakan Mongo sebagai basis data kueri untuk semua pengembangan baru.

Pertanyaan saya adalah apakah mungkin untuk menggunakan SQL Server sebagai database catatan dan Mongo sebagai query database Anda bersama-sama ?

Jadi ketika salah satu editor kami memperbarui catatan, data akan disimpan dalam SQL Server. Ini perlu, karena ada terlalu banyak kode warisan yang tidak dapat ditulis ulang semalaman.

Tetapi ketika pengunjung di situs web melihat artikel atau daftar artikel, saya ingin memanfaatkan kinerja Mongo versus SQL Server. Untuk menjaga agar data tetap terkini, misalkan berumur 15 menit atau kurang, data SQL Server perlu menyegarkan Mongo. RDBMS memiliki alat replikasi untuk operasi seperti ini dan saya ingin tahu apakah ada yang bisa dilakukan dari SQL Server ke Mongo. Server Lync, mungkin?


3
Bisa jadi? Tentu saja mungkin, karena dua toko data terpisah. Apa sebenarnya yang kamu tanyakan di sini?
Oded

Tetapi bisakah Anda menggunakannya bersama? Dengan Mongo DB pada dasarnya bertindak sebagai cache read-only untuk data?
John

1
Sekali lagi, tentu saja Anda dapat "menggunakannya bersama". Tetapi tidak jelas apa artinya itu. Selama Anda memiliki semacam mekanisme pembaruan untuk mongo, Anda dapat melakukannya. Lihat posting Udi Dahan - tetapi terserah Anda untuk menentukan mekanismenya.
Oded

1
Kami tidak pernah pindah ke MongoDB, namun sepertinya tahun depan mungkin. Salah satu cara transisi yang telah kami lakukan adalah menyimpan JSON di bidang varchar. Dari semua yang saya baca, tidak ada cara yang baik untuk memindahkan data antara NoSQL dan SQL - semuanya perlu custom, terutama karena database NoSQL yang ada di luar sana sangat bervariasi dalam hal cara mereka melakukan sesuatu. .
John

1
@ John jika Anda ingin tetap menggunakan relasional dan bersedia pindah dari SQL Server, Anda mungkin ingin melihat Postgresql dan integrasi json -nya . Dengan demikian, menyimpan data dalam kolom json yang kemudian dapat dimanipulasi dalam database.

Jawaban:


13

Anda mengalami masalah yang dimiliki banyak orang sebelum Anda ... sebuah database yang dioptimalkan untuk membaca jarang baik untuk efisiensi menulis dan sebaliknya. Salah satu pendekatan yang telah berkembang dari hambatan baca-tulis ini adalah CQRS (Command Query Responsibility Segregation). Meskipun Wikipedia menghubungkan keduanya, CQRS dan CQS secara teknis berbeda. CQS hanya menuntut agar suatu metode baik membuat perubahan (perintah) atau meminta informasi (permintaan) tidak pernah keduanya.

CQRS mengambil langkah lebih jauh dan menentukan bahwa Anda memiliki model terpisah untuk Permintaan dan Perintah. Langkah tunggal ini memungkinkan hal-hal seperti memisahkan basis data baca dan tulis Anda. Yang ingin kamu lakukan.

Saya tidak bisa mengatakan bahwa saya ahli tentang Mongo atau mengonfigurasinya agar berfungsi dengan SQL Server. Tetapi dari pemahaman saya, orang menggunakan Mongo sebagai pandangan denormalized dari basis data transaksional mereka. Memperbarui Mongo dari db transaksional mungkin muncul untuk menjalankan Agen SQL. Atau memiliki layanan terpisah untuk polling basis data.

Alternatif yang lebih baik lagi adalah membuat layanan Command Anda menjalankan suatu peristiwa setiap kali pembaruan dilakukan. Anda kemudian akan memiliki layanan yang mendengarkan acara itu dan memperbarui MongoDB dengan informasi itu. Itu adalah pendekatan mendasar untuk Pengadaan Acara (mencari Pengadaan Acara di halaman).

Greg Young, salah satu pemimpin pemikiran di dunia DDD saat ini sedang menulis buku di Fowler Signature Series tentang CQRS yang disebut Event-Centric (dulu disebut CQRS). Fowler telah menulis posting di bukunya yang menggambarkan pendekatan


+1 CQRS sangat cocok di sini. Gunakan acara untuk mengisi dan memperbarui database dokumen yang digunakan untuk membangun pandangan Anda, dan biarkan database sql Anda apa adanya.
quentin-starin

Kami belum mengadopsi sistem CQRS, namun saya telah memperhatikan apa yang ditulis oleh Greg, Udi dan yang lainnya. Sebagian besar CQRS bukan platform spesifik, tetapi hanya memikirkan perintah dan pertanyaan secara terpisah. Saya tidak berpikir bahwa Greg pernah akhirnya menulis buku, meskipun Microsoft Patterns and Practices memang merilisnya.
John

1
Satu-satunya hal yang saya tambahkan ke jawaban ini adalah: Jika use case Anda secara khusus menggunakan ini dengan MS SQL dan MVC, sudahkah Anda mempertimbangkan BrightstarDB bukannya MongoDB untuk porsi NoSQL? Ini memiliki Entity Framework dan kompatibilitas LINQ, yang mungkin memudahkan transisi untuk Anda.
CrazyPyro

1

Iya. Pada proyek saya saat ini, kami mendapatkan data dan menyimpannya di SQL Server, dan kemudian membangun indeks pencarian menggunakan Lucene / Solr dan menyimpannya di MongoDB. Mempopulasikan MongoDB dilakukan dengan loader kustom, meskipun - tidak ada replikasi SQL Server atau refresh otomatis.


Oke saya hanya ingin tahu, mengapa tidak langsung mengisi mongo? Apakah Anda berada di bawah kendala yang sama karena harus menggunakan keduanya?
yati sagade

SQL Server kami yang ada tidak dapat ditulis ulang dalam semalam. Pikiran saya adalah bahwa ini adalah langkah bayi yang kecil tapi bermanfaat.
John

@yatisagade: Benar. Kami memiliki laporan yang harus dijalankan terhadap SQL Server, tetapi kami memiliki aplikasi pencarian global yang menggunakan indeks Lucene.
TMN
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.