Где хранить ссылку на другие модели данных (в mongoDB) для лучшей производительности - PullRequest
Новая
       9

Где хранить ссылку на другие модели данных (в mongoDB) для лучшей производительности

0 голосов
/ 18 февраля 2019

В моем проекте есть пользователи и круги.Круги могут иметь несколько пользователей, а пользователь может находиться в нескольких кругах.Наконец есть события.Каждое событие может иметь несколько пользователей в одном круге.Позже события получат много контента, поэтому будет много материала для загрузки (изображения, комментарии и т. Д.).

Я думал, что это будут хорошие модели данных: 

User =  {
        _id: "uuid",
        name: "string",
        password: "string",
        circles: [Circle._id],
}

Event = {
    _id: "uuid",
    name: "string",
    location: "string",
    circles:Circle._id,
    participants: [User._id],
}

Circle = {
    _id: "uuid",
    name: "string"
}

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

API с этими моделями данных (я думаю) будет означать получение пользователей и событий из одного круга, база данных должна искать среди всех пользователей и событий и проверять, находятся ли они в этом круге.С большим количеством пользователей и событий, я думаю, что это не самый эффективный способ?

Итак, я думал о том, чтобы поместить пользователя и события в массивы круга следующим образом: 

User =  {
      _id: "uuid",
      name: "string",
      password: "string",
}

Event = {
     _id: "uuid",
     name: "string",
     location: "string",
     participants: [User._id],
}

Circle = {
     _id: "uuid",
     name: "string",
     users:[User._id],
     events:[Event._id]
}

Теперь, когда пользователь выбирает круг, круг загружается медленнее, потому что пользователии события должны быть загружены в первую очередь.Но я думал, что поиск пользователей и событий теперь будет быстрее.Это правильный подход / мышление?Имеет ли смысл сохранять ссылку на конкретные идентификаторы круга в модели данных «Пользователь и событие»?

1 Ответ

0 голосов
/ 18 февраля 2019

Если вы хотите использовать mongoDb в полной мере, я настоятельно рекомендую денормализовать ваши данные.

Если вы нормализуете свои данные, вам, возможно, придется использовать $ lookup для объединения нескольких коллекций.Даже если вы сэкономите на своем жестком диске, вы будете в конечном итоге выполнять относительно тяжелые вычисления.

Предполагая, что приложение обычно имеет 90% обращений при чтении и 10% при записи, имеет смысл смоделировать ваши данные удобным для чтения способом.Следовательно, очень денормализуйте ваши данные до тех пор, пока они действительно не станут необходимыми для создания ссылок на другие коллекции.Оптимизация может быть позже достигнута путем индексации и кэширования, но подумайте ниже: 

User =  {
        _id: "uuid",
        name: "string",
        password: "string",
        circles: ["circle1","circle2"],
        events : ["event1","event2"]
}

Event = {
     _id: "uuid",
     name: "string",
     location: "string"
}

Circle = {
     _id: "uuid",
     name: "string"
}

Попробуйте заранее узнать ваши запросы, архивируя большую часть ваших данных в коллекции User.Поле circles и events в коллекции User также может быть массивом объектов [{},{}], если есть еще свойства, которые нужно сохранить.

Я уверен, что чем больше коллекций вы объедините, тем сложнее будут обрабатываться ваши запросы, а также будет больше вычислений.

Я не рекомендую хранить userId в circle или eventКоллекции как пользователи могут расти со временем, и вы не хотите заканчивать коллекцией, в которой есть документ с одним полем, хранящим тысячи элементов массива.Напротив, пользователь может участвовать в сотнях кругов и событий, и если мы сохраним эти данные в коллекции User, их будет довольно просто запрашивать и обрабатывать.

Короче говоря: не обрабатыватьnosql db как реляционный db.Он никогда не будет вписываться. Смоделируйте вашу базу данных, помня ваши будущие запросы.Сильно денормализуйте ваши данные, чтобы упростить чтение, т. Е. Избегать ссылок.

...