За и против: Когда стоит и не стоит использовать MongoDB

MongoDB не подходит для хранения реляционных данных. Об этом говорят сами разработчики.
Вы привели самый простой способ организации хранения данных в данном случае, на самом деле их больше.
Обычно выбирают родительский пост и плоский список комментариев, затем их превращают в дерево уже на уровне языка программирования. Обычно комментариев немного, случаи вроде этого — исключения, но и они решаемы. В любом варианте, отдача десятков тысяч комментариев на странице просто убьет браузер, особенно на телефоне.
MongoDB используется на доске объявлений Craigslist, как вы понимаете, там особых связей не нужно. Плоская структура для сайта с гигантской посещаемостью и огромным количеством данных.
MongoDB подойдет там, где база растет, документы не требуют связности и их структура варьируется достаточно сильно. Представьте, что вам нужно добавить новое поле для 10 записей в таблице MySQL с триллионом записей. При этом у вас 100 обращений в секунду на чтение к этой таблице. Как вы будете решать такую задачу без блокировок? Предполагаю, что будет некоторый простой в работе сервиса.

Как всегда, во всех примерах комментарии добавляются прямо в документ, чтобы показать насколько это круто.
Наверное, людям нравится держать в голове (или они забивают на это), что размер документа не должен превышать 16МБ, а это не так много.
Блин, хватит уже писать про JOIN в Mongo. Их там не должно быть, т.к ты не можешь быть уверен, что заJOIN'еный объект лежит на том же севере, на котором ты делаешь запрос. Mongo изначально делалась, чтобы решить проблемы, который у обычных RDBMS возникнут потом. Не у всех, правда.
То, что делается на Mongo максимально просто и понятно, а при возникновении проблем с объемом данных в реляционных БД будут изобретаться такие велосипеды, который все достоинства этих баз сведут к нулю.
Тяжело, вам, наверное делать изначально ограниченный проект на обычных реляционных базах, т.е не думать о том, что будет, когда все будет потихоньку накрываться…
Лучше побольше времени потратить на изначальное проектирование данных, которое снимет вообще все вопросы в будущем.

https://docs.mongodb.org/ecosystem/use-cases/storing-comments/ вот так.
В статье как раз и говориться, что если у вас много сложных связей, тогда монго не ваш выбор.

Вот и я не понимаю, почему в половине статей про монгу в качестве хорошего примера приводят блог и комментарии

Люди просто берут mongo потому что 'модно, молодёжно', даже не задумываясь о том, что что-то подойдёт лучше для решения задачи.
Как только встречают элементарную задачу, комментарии те же, создают табличку и 'связывают'. И потом начинают всем рассказывать, что так делать — хороший вариант. Но вот взять реляционную бд, которая отлично справляется с этими проблемами — не вариант для любителей 'модно, молодёжно'. Mongo везде и всегда.

Ну вообще я использовал OrientDB только как документно-ориентированную и она работает 1 в 1 как MongoDB на уровне кода и апи + даже есть возможность сделать схему данных. Читал про то что есть сырые фичи, которые выкатывают в релизы и просто с новыми фичами надо быть осторожнее.
Мне еще понравилось то, что она может встраиваться в Java проекты как embedded и работать без сервера. Отличный вариант для тех, кто ищет документно-ориентированную базу like MongoDB для проекта, но чтобы все работало как embedded из коробки.
P.S. Авторы OrientDB заявляют на сайте, что ее можно использовать и как графовую и как документно-ориентированную. Для каждого случая свое АПИ.

Что сложного в графах? Это в таблицы раскладывать модели и джойнить талицы, чтобы получить данные обратно ложно. А пройтись по ссылкам — что может быть проще? Мои впежатления от использования графов очень положительные. И с какими-то нерешаемыми проблемами в ориенте я не стакивался.

Колоночно-ориентированная субд отличается способом хранения данных. Она позволяет делать последовательные чтения с диска для получения данных из отдельных колонок. Предназначена для аналитических запросов. Часто умеет хорошо сжимать разреженные данные. Схема жестко задана. В качестве примера — формат хранения данных parquet. Данные бьются сначала на группы строк (это связанно с надежностью хранения), а внутри группы строк хранятся уже поколоночно. Схема внутри одной группы строк неизменяема.


Семейство колонок — это способ организации хранения в базах типа ключ-значение. Данные хранятся построчно. Доступ к строке по ключу. Внутри строки хранится список кортежей из двух элементов. Первый — имя колонки, второй — значение в данной строке и данной колонке. Это позволяет для каждого ключа иметь произвольный набор колонок.

А column-family (которые теперь зовут просто таблицами) у неё просто так?

Абсолютно верно, не просто так! Они потому и стали зваться таблицами, что это лучше отображает суть.



Отличия между column и row oriented базами:

Id в MongoDB по умолчанию проиндексирован

Я говорю о всем множестве «особенностей» mongo.

1. Про write concern, когда терялись записанные и ACK'нутые данные в самом строгом режиме записи. В середине 2013 (меньше 3 лет назад) он, насколько я вижу, был еще актуален. База к тому времени существовала 4 года (и видимо эти 4 года не гарантировала совсем ничего в смысле целостности данных). 3 года это вообще не срок, у иных традиционных БД аптайм больше.

2. Проблема eventual consistency в том, что это самое eventual может не наступить никогда. Я не зря спрашиваю про кейсы использования. По большому счету сценариев где можно взять и потерять часть данных — не так уж много. Я практически уверен, что существенная часть пользователей mongo плохо понимает этот ньюанс.

3. Отсутствие вменяемого, доказанного алгоритма согласования данных при передаче лидерства. Даже несмотря на то, что есть определенные проблески в виде мажорити и выбора лидера. Почему написал «не гарантировала» — потому что сейчас там Tokutek то ли пишет, то ли уже написал имплементацию движка, основанную на Raft, и дела пожалуй станут несколько лучше.

Вот хорошая ссылка по делу: https://aphyr.com/posts/284-jepsen-mongodb

Сначала неверно истолковал вопрос, в таком случае требуется агрегация с группировкой:

db.posts.aggregate([{
    $project: {
        items: {
            $filter: {
                input: "$comments",
                as: "comm",
                cond: {
                    $eq: ["$$comm.userID", 10]
                }
            }
        }
    }
}, {
    $group: {
        _id: "all",
        messages: {
            "$push": "$items"
        }
    }
}]);

Рабочая, проверил. Но если честно, впервые пишу выборку для такой структуры, может более опытные товарищи смогут написать агрегацию лаконичнее.

А вот-так даже красивее гораздо:

db.posts.aggregate([{$unwind : "$comments"}, {$match: {"comments.userID": 10}}]);

1)

db.posts.aggregate([
    {$lookup: {"from": "comments", "localField": "_id", "foreignField": "postID", "as": "comments"}},  {$unwind : "$comments"},
    {$lookup: {"from": "users", "localField": "comments.userID", "foreignField": "_id", "as": "comments.user"}}, 
    {$group : { _id: "$_id", comments: {$push: "$comments"}}}
]);

2)

db.comments.aggregate([
    {$group: {_id: "$postID", count: { $sum: 1}}},
    {$lookup: {"from": "posts", "localField": "_id", "foreignField": "_id", "as": "post"}},  
]);