Навеяно вот этим постом.

Есть всем известный сайт stackoverflow.com
Возмем его упрощенную структуру: пользователи, вопросы, ответы, комменты, голоса, связи надеюсь понятны.

Надо спроектировать БД так чтобы она могла выдержать больше объемы, сравнимые с самим stackoverflow. Это около миллиона вопросов, 50 тыщ активных пользователей, 10 миллионов ответов и столько же комментов, 10 миллионов голосов.

Функционал как на сайте — список последних вопросов, список популярных вопросов, список неотвеченных вопросов, вопрос с ответами и комментами с сортировкой по ответам (дата, количество голосов), статистика пользователя: что когда где написал, прокомментил, проголосовал. Ну и сами действия: написание\правка вопроса, ответа, коммента, голосование.

Полнотекстовый поиск отдаем внешнему компоненту, типа lucene или google\bing.

Подход RDB очевиден:
1)создать нормализованные таблицы
2)сделать индексированные view, считающие количество голосов по ответам, комментам, пользователям
3)Сделать индексированное view для подсчета количества ответов и голосов по вопросам
4)В случае невозможности сделать view — пересчитывать в триггерах
5)Понаделать индексов чтобы не было ни одного scan для выборки

Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.

Что нам предложит NoSQL подход в данном случае?