MongoDB против SQL Server для хранения рекурсивных деревьев данных

Question

В настоящее время я определяю проект, в котором хранятся многопоточные деревья комментариев.

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

Id int  --PK
ThreadId int  --FK
UserId int  --FK
ParentCommentId int  --FK (relates back to Id)
Comment nvarchar(max)
Time datetime

Что я делаю, это выбираю все комментарии по ThreadId, а затем в коде рекурсивно создаю дерево объектов. Я также делаю объединение, чтобы получить такие вещи, как имя пользователя.

Мне просто кажется, что, возможно, хранилище документов, такое как MongoDB, которое представляет собой NoSql, было бы лучшим выбором для такой модели. Но я ничего не знаю об этом.

• Какие будут подводные камни, если я выберу MongoDB?
• Если я храню его в качестве документа в MongoDB, нужно ли мне включать имя пользователя в каждый комментарий, чтобы не приходилось подтягивать каждую запись пользователя по ключу, поскольку она не "реляционная"?
• Вам нужно агрессивно кэшировать "связанные" данные на объектах, которые вам нужны, когда вы используете MongoDB?

---

EDIT: я нашел эту статью о хранении деревьев информации в MongoDB. Учитывая, что одним из моих требований является возможность перечислять вошедшему в систему пользователю список его недавних комментариев, я сейчас сильно склоняюсь к тому, чтобы просто использовать SQL Server, потому что я не думаю, что смогу сделать что-нибудь умное с MongoDB, что приведет к реальным преимуществам производительности. Но я могу ошибаться. Я действительно надеюсь, что эксперт (или два) по этому вопросу предоставит больше информации.

Answer 1

Основным преимуществом хранения иерархических данных в Mongo (и других базах документов) является возможность хранить несколько копий данных таким образом, чтобы сделать запросы более эффективными для различных вариантов использования. В вашем случае было бы очень быстро извлечь весь поток, если бы он хранился как иерархический вложенный документ, но вы, вероятно, также захотите хранить каждый комментарий не вложенным или возможно в массиве под записью пользователя, чтобы удовлетворить 2-е требование. Из-за произвольного вложения я не думаю, что Mongo сможет эффективно индексировать вашу иерархию по идентификатору пользователя.

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

Надеюсь, что поможет