Есть MySQL OLTP система со множеством отношений между таблицами. Например есть таблица products и вокруг нее десятки связанных таблиц.. различные типы, описания, скриншоты и так далее. Отношения между ними как 1 к 1 так и 1 ко многим, много ко многоим. Для отображения на клиенте каталога продукции необходимо делать запросы к mysql используя сложные joins что очень негативно сказывается на производительности.

Возникла идея денормализировать сущность product. Тоетсь при наступлении любого из CRUD событий с продуктом, мы будем формировать сообщение об этом в gearman queue а на другой стороне gearman worker будет создавать полное денормализированное представление продукта со всеми зависимостями и формировать документ на базе JSON и сохранять его в колекции products MongoDB.

С этим все более менее понятно, но вопрос возникает по след поводу - у продукта могут быть комментарии от пользователя. У каждого продукта их может быть разное число. Когда мы отображаем каталог продуктов возле каждого продукта хотелось бы показывать это число комментариев. Понятно что на лету просчитывать count для каждой записи в реляционной структуре это не самый лучший вариант. Здесь тоже напрашивается решение с отложенной обработкой через gearman queue который или будет заново пересчитывать через count общее число коментов для продукта и писать в mongodb либо делать +1 на числе из mongodb и обновлять там значение.

Вопрос - где лучше в Монго держать значение comments_number ? в той же коллекции products в отдельном филде или полностью в отдельной коллекции ?

Так же для каждого продукта в каталоге будет возможность сортировки по дате создания, числу закачек, имени. Для того что б сортировка происходила быстро нам необходимо будет все эти значения держать в отдельных филдах коллекции products ?

Посоветуйте плиз как лучше организовать данные в Монго для описанных мной сценариев. Спасибо !

просто хочу сразу убежать от модели вертикального масштабирования на горизонтальное(именно для клиентских запросов которых могут быть сотни тысяч и миллионы). Плюс для денормализации NoSQL изначально и был изобретен и оформлен в отдельную концепцию которую обычно приходится изобретать самому на базе RDBMS. С ростом трафика к NoSQL будем просто подкидывать новые узлы и тем самым не думать о распределении нагрузки.

Вопрос только где держать поля которые намного чаще будут изменяться чем теже поля содержащие в себе документы продуктов.
Держать эти поля(comments_number, downloads_number) вместе с product в одной колекции products или разнести их по разным колекциям ?

scf, спасибо за ответ.

Да, sphinx уже установлен в системе и рассматривается как система полноценного поиска. На счет фильтрации, сортировки, пейджинации удивлен что он(sphinx) может помочь, но это скорее от моего незнания возможностей этого продукта. Займусь его изучением.

Несколько смутило ваше замечание по поводу извлечение продуктов вторично
А если оно не вторично а так же важно как и критерии описанные выше то как здесь быть ? Решит ли sphinx и эту проблему ?