lega

Монга перекрывает 80-90% функционала sql-баз если рассмартивать средний проект, но дополнительно дает бо'льшую скорость работы, скорость и гибкость разработки, ну и масштабирование из коробки.
А от хейтеров вы осбо хорошего и не услышите ;-)

Ведь в блоге есть автор, у которого есть статьи, которые в свою очередь связаны с категориями, тегами и т.д. А еще у статей есть комментарии.

Категории, теги, да и сам автор может быть уже на клиенте, особенно если это веб-приложение, в этом случае реляции не обязательно подгружать, таким образом идет экономия поиска/чтения из базы и меньше трафика для передачи клиенту - т.е. выше производительность.
Так же автор может быть продублирован в документе (завсисит от задачи) и на крайний случай есть lookup и подобные способы.
Комментарии так же могут быть сохранены в самом документе, таким образом вы читаете из базы всего 1 документ, а не тысячу, что увеличивает скорость "на порядки".

Так же гибкость с надежностью - на каждую операцию вы выбираете использовать транзакцию или атомарность, кол-во реплик для сохранения т.п. что дает повышенную производительность.

Вообщем если нужна гибкость и скорость - то попробуйте монгу.

Загляните в syslog, возможно это oom-killer убивает могу когда та начинает жрать всю память (если так - то нехватка памяти), так же ещё сделайте swap если ещё нету (а если есть, что показывает?).

Вывод: если требуется фильтровать по полям вложенных док-ов, то стоит реализовать коллекции не как вложенные, а в виде отдельной коллекции, как в РБД.

Чаще да. Так же бывают такие варианты как пометить определенных пользователей чтобы всех не перебирать, либо дублировать "отличительные" комментарии в отдельную коллекцию или наоборот дублировать в "документ пользователя", в nosql оно гибче.

N * LogM. То есть нужно просмотреть каждого пользователя - N итераций

Чтобы не делать N итераций используют индекс, чтобы получить нужные документы без переборов (а переборы задействуют "диск").

Так же тут нужно смотреть на то как вы будете изменять поле "количество просмотров", если комментарии находятся в отдельной коллекции - то это будет проще и быстрее.

Comments будет иметь N * M док-ов, а сложность будет Log( N * M ).

Откуда у вас тут Log? Чтобы получить "все комментарии имеющие 200 просмотров.", коллекцию пользователей трогать вообще не обязательно.

Заваисит от конкретного примера, как вариант можно использовать (частично использовать) фасетный фильтр.

Теги складываете в массив внутри документа и его индексируете - будете быстро находить документы по тегу.

Обновлять по id, id искать по куке, куки могут быть как в объекте пользователя так и вне.

Плохое решение, так сессию не заиндексировать - а значит монга будет делать full scan коллекции, что приведет к тормозам при росте коллекции.
Как компромис - можете продублировать сессю в массив и сделать на него индекс.

Используйте индексы, тогда можно будет быстро находить нужные посты без прохода по всей базе.

см. фильтры $eq, $in, $all

Я бы сделал простой запрос по индексу (from-to) - получить все занятые на период. И уже на бекенде (из кеша или монги) выдал бы все что не попали в список (т.к. номеров не много).
Это один из самых производительных вариантов. А сложные запросы и запросы с отрицанием (not) часто приводят к полному перебору.

PS: но для учебного проекта не факт что подойдет.

Добавляйте нолики при получении данных из монги да и все.

Затем мне нужно несколько тысяч раз циклками пройтись...

Нет смысла, т.к. в результате будет только один order_id.

При превращении в словарь будет +- то же самое

Один словарь - один индекс, если нужно несколько индексов - делайте несколько словарей. Это самое быстрое - O(1), если все в память влазит. Для этого и монга особа не нужна.

Но я не думаю что у вас это критично по скорости, поэтому лучше не парится и испльзовать монгу как есть, она достаточно быстра.

лучший вариант исходить из реляции верно?

Нет, нужно смотреть по фичам, в среднем, можете попробовать Монго если вам не нужны (сложные) транзакции.