Еж с ужом в одной корзине, а также немного об отсутствии схемы

[schroeder]

Спасибо за статью.

Можно немного по подробней про общую архитектуру? Например, вот приходит запрос на показ какой то страницы, что происходит(общий порядок действий)?

[BugagaController]

Если это страница какой-либо программы или непосредственно статьи то мы из монги вытаскиваем данные по идентификатору, преобразуем дата модель во вью модель и показываем.
Если же у нас на странице показываюся тайлы, как например во втором случае, к монге идет запрос к коллекции тайлов, возвращающий набор разных тайлов с базовым классом BaseTile. Для каждого типа тайлов у нас есть своя вьюха, которая знает какой тип ей нужен и какие данные она должна отображать. Наш проект реализован на aspnet mvc, и для этого нам было досаточно вызывать что-то вроде:

foreach (var tile in Model.Tiles)
{
	<text>
		@Html.DisplayFor(tile)
	</text>
}

[schroeder]

Не, я имел ввиду немного другой момент. Как, где и когда происходит совместная работа sql и nosql?

[BugagaController]

С sql у нас фактически работает админка сайта, что гарантирует нам наличие гарантированно достоверного набора данных. После того как данные попадают в sql, они должны как-либо попадать в монгу, это может либо событие на выполнение транзакции sql реальизованное непосредственно в части админки, что к сожалению, не гарантирует того что данные попадут в nosql корректно, либо можно воспользоваться очередью сообщений, например msmq или rabbitmq. Кроме того при такой схеме мы получили пару дополнительных возможностей
1) На случай если что-то пошло сильно не так, нажатием одной кнопки мы можем полностью восстановить данные в nosql
2) В качестве админки сайта можно взять любую бесплатную цмску с удобным интерфейсом управления контентом, не задумываясь о ее производительности, т.к. клиентская часть сайта, находящаяся под наибольшей нагрузкой никак не будет зависеть от производительности этой цмс

[potan]

Вполне практичный подход. Например, сервер БД virtuoso умеет работать как с SQL, так и с SRARQL (близко к графовым nosql-базам).

[usualdesigner]

Как часто происходит публикация данных их sql в nosql? Что Вы делаете, если пользователям нужно показывать оперативную информацию ил nosql, а публикация еще не произошла?

[BugagaController]

У нас навешивается событие на сохранение данных в sql, кроме того у нас не очень много источников данных — около 5-10 редакторов контента плюс фиды из нескольких источников, поэтому данные попадают в монгу практически мгновенно.

[lair]

Я так понимаю, вы изобрели очередную вариацию CQRS?

[david_mz]

Например, в PostgreSQL есть тип JSON. В него можно класть произвольные JSON-данные, а кроме того, делать из поля этого типа выборки ('{«a»:1,«b»:2}'::json->'b') и строить индексы по полям этих данных (с версии 9.3). Кажется, при таких возможностях, нет смысла параллельно держать Монгу?

[BugagaController]

У нас использование монги сложилось можно сказать исторически. Кроме того в качестве реляционного хранилища нам было удобнее использовать ms sql.
А так конечно да. Постгрес вполне подходящий инструмент для описанного в статье подхода

[kefirfromperm]

MS SQL Server умеет XML, так что…

[BugagaController]

С XML у MS SQL сервера далеко не все гладко. ОРМ если и поддеживают его то не в сильно приятном виде — через xpath, который, к сожалению, далек от мечты

[gandjustas]

Linq2SQL возвращает xml как XElement, а EF как строку. Где вы нашли XPath?

[gandjustas]

Пока вы не делаете запросов к данным, то хранить можно как угодно, хоть в строковых полях в БД, хоть в файлах, хоть в key-value. У меня всегда контент страниц хранился в виде строк в базе и проблем не было.

[gricom]

Похоже, что вы просто используете MongoDB как кеш (насколько я понял вы в неё публикуете все данные, но читаете только небольшой набор самых свежих), тогда почему именно MongoDB, а не обычный кеш?

[kefirfromperm]

Вот да, персистентность от монги в данном случае вовсе не требуется. В первом случае, какой-нибудь ORM-фрэймворк вообще возьмет всю заботу на себя. Во втором, ну тут интересней.

[gricom]

Во-втором случае можно подтягивать данные в кеш из БД по факту запроса данных (в простонародье read-through).
Я как раз делаю такой опенсорсный кластерный кеш, примерно через месяц планирую выкатить функциональность, которая позволяет не ходить самому в базу, а просто делать запрос в кеш, который сам пойдет в БД за данными и закеширует их (при этом кеш отдает данные, как ваш доменный объект, надо просто в конфигурации сконфигурить структуру объекта). Способ доставания из БД конфигурится: можно сделать обычный маппинг на таблицу БД, можно вставить кастомный sql запрос, можно вызывать хранимую процедуру, можно использовать для каждого поля объекта свой способ, можно вообще один объект доставать из разных БД.
Поддержка пока только для PHP, но следующим релизом должна пойти поддержка Ruby либо Python.

[gricom]

Лежит тут bitbucket.org/aolenev/sproot/

[BugagaController]

Кеш это хорошая идея, но есть две потенциальных трудности
1) Я писал выше что данные у нас не стльно много источников данных, однако для кеша он все же обновляются достаточно часто, тем самым сбрасывая его
2) нам была необходимость на разных страницах показывать свежие данные с опрееленным фильтром
Получается достаточно серьезная нагрузка на реляционную БД, даже при наличии кеша

[gandjustas]

Да сейчас во всех субд это работает, mysql, postgres, oracle умеют с json работать. MS SQL пока только с xml.

[gandjustas]

В целом, все выглядит довольно неплохо, однако при использовании денормализованной коллекции телепрограмм в монге не нужно ничего придумывать — достаточно сделать один запрос, вытаскивающий данные по идентификатору — и все.

Снова типичная ошибка. Кроме запроса по идентификатору у вас будет еще 100500 запросов не по идентификатору. Например нужно будет показать все сериалы, которые начали в 2010 году (то есть дата вещания первого эпизода первого сезона попадает в 2010 год). Монга от такого запроса умрет, придется шаманть с индексами, чтобы этого не случилось, и не факт что получится. SQL спокойно ответит на такой запрос и еще на 100500 других нетривиальных запросов.

На практике свести все запросы к выборкам по ключу нереально. Это можно сделать в кэше — промежуточном слое, где приложение сохраняет готовые к отображению объекты. А основное долговременное хранилище должно отвечать на нетривиальные запросы с приемлемой скоростью. Но для кэша монга как-то тяжеловата, а для основного хранилища — слабовата.