Чи можна використовувати SQL Server та Mongo разом?

У нас великий веб-сайт, орієнтований на новини, який має високий веб-трафік. Архітектура - це ваш часто бачується БД - шар Repo - шар послуг - Asp.Net MVC. Проблема, яку ми бачили, полягає в швидкості читання. Виявляється, всі ці об’єкти доменних об'єктів DDD теоретично чудові для ділових правил, але ускладнюють життя, коли йдеться про оптимізацію продуктивності читання.

Як рішення я розглядаю щось абсолютно нове (для нас): використання noSQL. Я хотів би використовувати базу даних noSQL для представлення даних на нашому веб-сайті. Ми не можемо позбутися нашого SQL-сервера (принаймні, не скоро), але мені здається, що практичним кроком було б використання Mongo як бази даних запитів для всіх нових розробок.

Моє запитання: чи можна використовувати SQL Server як базу даних записів, а Mongo - як спільну базу запитів ?

Отже, коли один з наших редакторів оновить запис, дані будуть зберігатися в SQL Server. Це необхідно, оскільки є занадто багато застарілого коду, який не можна переписати протягом ночі.

Але коли глядач на веб-сайті переглядає статтю чи список статей, я хотів би скористатися продуктивністю Mongo та SQL Server. Для того, щоб зберегти дані дещо актуальними, скажімо, дані старі 15 хвилин чи менше, дані SQL Server повинні були оновити Mongo. RDBMS мають інструменти реплікації для таких операцій, і мені цікаво, чи існує щось, щоб зробити те ж саме від SQL Server до Mongo. Lync-сервер, можливо?

— Джон
джерело

Можливо? Звичайно, це можливо, як два окремих сховища даних. Що саме ви тут запитуєте?

— Одід

Але чи можете ви їх використовувати разом? З базовою базою даних Mongo, яка працює в основному як кеш даних лише для читання?

— Джон

Знову ж таки, звичайно, ви можете "використовувати їх разом". Але не ясно, що це означає. Поки у вас є якийсь механізм оновлення монго, ви добре піти. Дивіться публікації Уді Дахана - але ви вирішите визначити механізм.

— Одід

Ми ніколи не переїжджали до MongoDB, проте, схоже, наступного року ми можемо. Один із перехідних способів, який ми зробили, - це зберігання JSON у варчарних полях. З усього, що я прочитав, немає жодного хорошого способу переміщення даних між NoSQL і SQL - це все буде потрібно на замовлення, тим більше, що бази даних NoSQL, які знаходяться там, сильно відрізняються тим, як вони роблять речі .

— Іван

@John, якщо ви хочете дотримуватися реляційних даних і готові відійти від SQL Server, ви можете подивитися на Postgresql та його інтеграцію json . Таким чином, зберігання даних у колонці json, яким потім можна керувати всередині бази даних.

Відповіді:

Ви зіткнулися з проблемою, яку багато хто має перед собою ... база даних, оптимізована для читання, рідко корисна для ефективності запису і навпаки. Один із підходів, що розвинувся внаслідок цього перешкоди для читання-запису, - це CQRS (Сегрегація відповідальності за запити команд). Незважаючи на те, що Вікіпедія пов'язує два разом CQRS і CQS технічно відрізняються. CQS просто вимагає, щоб метод або вносив зміни (команду), або запитував інформацію (запит) ніколи і того й іншого.

CQRS робить це на крок далі і вказує, що у вас є окрема модель для запитів і команд. Цей єдиний крок дає змогу поділити подію вашої бази читання та запису. Що ви хочете зробити.

Я не можу сказати, що я фахівець Mongo або налаштовую його на роботу з SQL Server. Але з мого розуміння, люди використовують Монго як денормалізований погляд на свою транзакційну базу даних. Оновлення Mongo від транзакційного db може звестись до запуску агента SQL. Або мати окремий сервіс для опитування бази даних.

Ще кращою альтернативою було б, щоб ваша служба Command запускала подію кожного разу, коли проводиться оновлення. Потім у вас з’явиться служба, яка прослухала цю подію та оновила MongoDB з цією інформацією. Це фундаментальний підхід до пошуку подій (пошук пошуку подій на сторінці).

Грег Янг, один із лідерів думок у світі DDD, зараз пише книгу із серії підписів Фаулера про CQRS під назвою Event-Centric (раніше її називали CQRS). Фаулер написав пост на своїх бліках, де описав підхід

— Майкл Браун
джерело

+1 CQRS тут добре підходить. Використовуйте події, щоб заповнити та оновити базу даних документів, яка використовується для побудови переглядів, і залиште свою базу даних sql такою, якою вона є.

— квентин-зірин

Ми не прийняли систему CQRS, однак я звернув увагу на те, що написали Грег, Уді та інші. Значна частина CQRS - це не конкретна платформа, а лише продумування команд та запитів окремо. Я не думаю, що Грег коли-небудь писав книгу, хоча Microsoft Patterns and Practices випустив її.

— Іван

Єдине, що я хотів би додати до цієї відповіді: Якщо ваш випадок використання спеціально полягає у використанні цього з MS SQL та MVC, чи розглядали ви BrightstarDB замість MongoDB для частини NoSQL? Він має Entity Framework та сумісність LINQ, що може полегшити вам перехід.

— CrazyPyro

Так. У моєму поточному проекті ми отримуємо дані та зберігаємо їх у SQL Server, а потім будуємо індекси пошуку за допомогою Lucene / Solr та зберігаємо їх у MongoDB. Населення MongoDB здійснюється за допомогою спеціального завантажувача, однак - немає реплікації SQL Server або автоматичного оновлення.

— TMN
джерело

Гаразд, мені просто цікаво, чому б безпосередньо не заселити монго? Ви під тим же бажанням маючи використовувати обидва?

— yati sagade

Наш існуючий SQL Server не може бути переписаний протягом ночі. Думаю, що це маленький, але корисний дитячий крок.

— Джон

@yatisagade: Правильно. У нас є звіти, які повинні працювати проти SQL Server, але у нас є глобальний додаток пошуку, який використовує індекси люцена.

— TMN