Можно ли использовать SQL Server и Mongo вместе?

У нас есть большой новостной сайт с высоким веб-трафиком. Архитектура - это ваша часто встречающаяся БД - Уровень репо - Уровень услуг - Asp.Net MVC. Проблема, которую мы видели, связана с производительностью чтения. Оказывается, что все эти объекты объекта DDD теоретически хороши для бизнес-правил, но усложнили жизнь, когда речь заходит об оптимизации производительности чтения.

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

Мой вопрос: возможно ли использовать SQL Server в качестве базы данных записей и Mongo в качестве базы данных запросов вместе ?

Поэтому, когда один из наших редакторов обновит запись, данные будут сохранены в SQL Server. Это необходимо, потому что слишком много устаревшего кода, который нельзя переписать в одночасье.

Но когда зритель на веб-сайте просматривает статью или список статей, я бы хотел воспользоваться преимуществами Mongo по сравнению с SQL Server. Чтобы поддерживать актуальность данных, скажем, 15 минут или меньше, данные SQL Server должны были бы обновить Mongo. В СУБД есть инструменты репликации для подобных операций, и мне интересно, есть ли что-то, что можно сделать так же, от SQL Server до Mongo. Сервер Lync, может быть?

— Джон
источник

Возможно? Конечно, это возможно, как два отдельных хранилища данных. Что именно вы спрашиваете здесь?

— Одед

Но вы можете использовать их вместе? С БД Mongo, действующей в основном как кэш только для чтения данных?

— Джон

Опять же, конечно, вы можете «использовать их вместе». Но не ясно, что это значит. Пока у вас есть какой-то механизм обновления для Монго, вы готовы к работе. Посмотрите посты Уди Дахана - но это зависит от вас, чтобы определить механизм.

— Одед

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

— Джон

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

Ответы:

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

CQRS делает еще один шаг вперед и указывает, что у вас есть отдельная модель для запросов и команд. Этот единственный шаг позволяет разделить базу данных для чтения и записи. Что ты хочешь сделать.

Я не могу сказать, что я эксперт по Mongo или настраиваю его для работы с SQL Server. Но, насколько я понимаю, люди используют Mongo как денормализованное представление своей транзакционной базы данных. Обновление Mongo из транзакционной базы данных может привести к запуску агента SQL. Или имея отдельный сервис для опроса базы данных.

Еще лучшая альтернатива - запуск службы Command при каждом обновлении. Затем у вас будет служба, которая прослушивает это событие и обновляет MongoDB с этой информацией. Это фундаментальный подход к Event Sourcing (поиск Event Sourcing на странице).

Грег Янг, один из лидеров мысли в мире DDD, в настоящее время пишет книгу в серии Fowler Signature по 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
источник

Хорошо, мне просто любопытно, почему бы не заселить монго напрямую? Вы находитесь в одном и том же ограничении необходимости использовать оба?

— Яти Сагаде

Наш существующий SQL Server не может быть переписан за одну ночь. Я думаю, что это маленький, но полезный шаг ребенка.

— Джон

@yatisagade: Верно. У нас есть отчеты, которые должны работать с SQL Server, но у нас есть приложение глобального поиска, которое использует индексы Lucene.

— TMN