SQL Server ve Mongo birlikte kullanılabilir mi?

Yüksek web trafiğine sahip büyük bir haber odaklı sitemiz var. Mimari sık görülen DB - Repo Katman - Hizmetler Katmanı - Asp.Net MVC. Gördüğümüz sorun okuma performansıyla ilgili. Tüm bu DDD etki alanı nesne öğelerinin teoride, iş kuralları için harika olduğu, ancak okuma performansını optimize etme konusunda hayatı zorlaştırdığı ortaya çıktı.

Bir çözüm olarak, tamamen yeni bir şey (bizim için) düşünüyorum: noSQL kullanarak. Web sitemizde sunulan veriler için bir noSQL veritabanı kullanmak istiyorum. SQL Server'ımızdan kurtulamayız (en azından yakın zamanda değil), ancak bana göre pratik bir adım, Mongo'yu tüm yeni geliştirme için bir sorgu veritabanı olarak kullanmak olacaktır.

Benim sorum SQL Server kayıt veritabanı ve Mongo birlikte sorgu veritabanı olarak kullanmak mümkün olup olmadığıdır ?

Editörlerimizden biri bir kaydı güncellediğinde, veriler SQL Server'da saklanır. Bu gereklidir, çünkü bir gecede yeniden yazılamayacak çok fazla eski kod vardır.

Ancak, web sitesindeki bir görüntüleyici bir makaleyi veya makale listesini görüntülediğinde, Mongo'nun SQL Server'a karşı performansından yararlanmak istiyorum. Verileri biraz güncel tutmak için, diyelim ki 15 dakika veya daha eski, SQL Server verilerinin Mongo'yu yenilemesi gerekir. RDBMS böyle işlemler için çoğaltma araçları var ve SQL Server'dan Mongo'ya aynı şeyi yapacak bir şey olup olmadığını merak ediyorum. Lync sunucusu, belki?

— John
kaynak

Mümkün? Tabii ki, iki ayrı veri deposu olarak mümkündür. Tam olarak burada ne soruyorsun?

— Oded

Ama onları birlikte kullanabilir misin? Mongo DB temel olarak veriler için salt okunur bir önbellek gibi davranıyor mu?

— John

Yine, elbette "bunları birlikte kullanabilirsiniz". Ancak bunun ne anlama geldiği belli değil. Mongo için bir çeşit güncelleme mekanizmanız olduğu sürece, gitmekte fayda var. Udi Dahan'ın gönderilerine bakın - ama mekanizmayı tanımlamak size kalmış.

— Oded

Asla MongoDB'ye taşınmadık, ancak gelecek yıl gibi görünüyor. Yaptığımız bir geçiş yolu JSON'u varchar alanlarında depolamaktır. Okuduğum her şeyden, verileri NoSQL ve SQL arasında ileri geri taşımanın iyi bir yolu yok - özellikle orada olan NoSQL veritabanları, işleri nasıl yaptıkları konusunda büyük ölçüde değiştiğinden, özel olması gerekecek. .

— John

@John ilişkisel bağlı kalmak ve SQL Server'dan uzaklaşmaya istekli iseniz, Postgresql ve onun json entegrasyonu bakmak isteyebilirsiniz . Böylece, daha sonra veritabanı içinde manipüle edilebilir bir json sütununda veri depolamak.

Yanıtlar:

Birçoğunun önünüzde yaşadığı bir problemle karşılaştınız ... okuma için optimize edilmiş bir veritabanı yazma verimliliği için nadiren iyidir ve tersi de geçerlidir. Bu okuma-yazma engelinden doğan bir yaklaşım, CQRS'dir (Komut Sorgusu Sorumluluk Ayrımı). Vikipedi'ye rağmen, ikisi CQRS ve CQS'yi birbirine bağlayan teknik olarak farklıdır. CQS sadece bir yöntemin ya değişiklik (komut) yapmasını ya da bilgi istemesini (sorgu) hiçbir zaman ikisini birden istememesini ister.

CQRS bunu bir adım daha ileri götürür ve Sorgular ve Komutlar için ayrı bir modeliniz olduğunu belirtir. Bu tek adım, okuma ve yazma veritabanınızı ayırmak gibi şeyleri mümkün kılar. Yapmak istediğin şey bu.

Mongo konusunda uzman olduğumu veya SQL Server ile çalışacak şekilde yapılandırıldığımı söyleyemem. Ama benim anlayışımdan, insanlar Mongo'yu işlemsel veri tabanlarının denormalize bir görüntüsü olarak kullanıyorlar. İşlemsel db'den Mongo'yu güncellemek bir SQL Agent'ı çalıştırmaya gelebilir. Veya veritabanını yoklamak için ayrı bir hizmete sahip olmak.

Daha da iyi bir alternatif, Komut hizmetinizin her güncelleme yapıldığında bir olay başlatmasını sağlamak olabilir. Bu olayı dinleyen ve MongoDB'yi bu bilgilerle güncelleyen bir hizmetiniz olur. Etkinlik Kaynaklarına temel yaklaşım budur (sayfada Etkinlik Kaynaklarını arayın).

DDD dünyasındaki düşünce liderlerinden Greg Young, halen CQRS'de Olay Merkezli (eskiden CQRS olarak adlandırılıyordu) olarak adlandırılan Fowler İmza Serisi'nde bir kitap yazıyor . Fowler, bliki hakkında yaklaşımı açıklayan bir yazı yazdı

— Michael Brown
kaynak

+1 CQRS buraya çok iyi uyuyor. Görünümlerinizi oluşturmak için kullanılan bir belge veritabanını doldurmak ve güncellemek için etkinlikleri kullanın ve sql veritabanınızı olduğu gibi bırakın.

— quentin-starin

CQRS sistemini kabul etmedik, ancak Greg, Udi ve diğerlerinin yazdıklarına dikkat ettim. CQRS'nin büyük bir kısmı belirli bir platform değildir, sadece komutları ve sorguları ayrı ayrı düşünür. Microsoft Patterns and Practices bir kitap yayınlasa da Greg'in bir kitap yazdığını hiç sanmıyorum.

— John

Bu yanıta ekleyeceğim tek şey şudur: Kullanım durumunuz özellikle MS SQL ve MVC ile kullanımdaysa, NoSQL kısmı için MongoDB yerine BrightstarDB'yi düşündünüz mü? Sizin için geçişi kolaylaştırabilecek Entity Framework ve LINQ uyumluluğuna sahiptir.

— CrazyPyro

Evet. Şu anki projemde veri alıyor ve SQL Server'da saklıyoruz ve sonra Lucene / Solr kullanarak arama indeksleri oluşturuyor ve MongoDB'de saklıyoruz. MongoDB doldurma özel bir yükleyici ile yapılır - SQL Server çoğaltma veya otomatik yenileme yok.

— TMN
kaynak

Tamam, merak ediyorum, neden doğrudan mongoyu doldurmuyorsun? Eğer aynı kısıtı altında mıyız sahip her ikisini de kullanmak?

— yati sagade

Mevcut SQL Server'ımız bir gecede yeniden yazılamaz. Benim düşüncem bu küçük ama kullanışlı bir bebek adımı.

— John

@yatisagade: Doğru. SQL Server'da çalıştırılması gereken raporlarımız var, ancak Lucene dizinlerini kullanan global bir arama uygulamamız var.

— TMN