Как я могу найти подмножество дерева эффективно в монго?

Question

У меня есть данные в базе данных базы данных Mongo, где каждый документ имеет идентификатор родителя. Если я хочу искать все документы, у которых есть конкретный документ (я буду называть его как P) в его родословной (т.е. P - это его родитель, дедушка, прабабушка и т. Д.), Каковы мои варианты, чтобы сделать это эффективно, и каковы эти возможности сильные и слабые стороны?

я могу думать о следующем:

• магазина всей родословной в каждом документе, так что вы можете осуществлять поиск документов, которые родословная списка содержит P.
  • Сильных стороны:
    • постоянного время посмотреть до
  • Слабости:
    • Если родительский объект изменен, соответствующее обновление - O (n), где n - число потомков документа, родитель которого изменен.
    • Некоторые издержки на хранение, O (a), где a - средняя глубина документа
• при поиске, первым построить список идентификаторов дочерних документов P, затем внучатые документов и т.д. Затем найти все документы с этими идентификаторами
  • Сильные стороны:
    • Никаких изменений не требуется к хранилищу электронная структура, нет дополнительного пространства над головой
  • Недостатки:
    • Построение списка идентификаторов представляет собой операцию О (п), где п числа документов потомка P
    • Поиска по, возможно, сотням из идентификаторов не может быть эффективным

Кто-нибудь знает другие методы?

Answer 1

Нормализовать или не нормализовать; Я считаю, что поднебесная NoSQL часто приводит людей к SQL/RDBMS. Я предпочитаю не нормализовать, чтобы обеспечить простые запросы с индексом в реальном времени с базовым бэкэнд-кодом и интерфейсом. Heres некоторый псевдокод в related question, который показывает сложный код, необходимый при нормализации. Его трудно подражать объединениям и отношениям в NoSQL.

Предоставлено NoSQL открывает открытые крысы для крыс, таких как ваш «Если родительский объект изменен, соответствующее обновление - O (n), где n - число потомков документа, родитель которого изменился« Я вызываю те «сценарии реляционного обслуживания». Но я нахожу, что вы можете запускать их на запланированной основе (crontab) в нерабочее время. Можно также настоятельно рассмотреть безопасные таблицы/коллекции и построить изменчивые или рабочие таблицы. См. this question относительно таблиц OLAP. Там вы можете иметь свои отношения в хороших аккуратных таблицах, а затем создавать эти уродливые быстрые коллекции.

Это вопрос определения того, действительно ли NoSQL для вас. Даже на личном уровне вы предпочитаете более быстрый, масштабируемый и беспорядочный - или медленный, нескромный и аккуратный/организованный.Компромиссы похожи на классический быстрый, хороший и дешевый треугольник. В принципе, NoSQL быстрый и дешевый; SQL хорош. Хорошая масштабируемость NoSQL; в то время как скорость SQL на самом деле респектабельна.