Как бороться с отношениями при использовании mongodb - PullRequest
Новая
       47

Как бороться с отношениями при использовании mongodb

1 голос
/ 25 февраля 2012

Я знаю, думайте «денормализованным способом» или «nosql way».

, но расскажите мне об этом простом сценарии использования. 

db.users
db.comments

некоторые пользователи оставляют комментарии, иЯ хочу получить некоторые пользовательские данные при получении комментария.скажем, я хочу показать динамические данные, такие как "userlevel", и статические данные, такие как "username".

со статическими данными, у меня никогда не будет проблем, но как насчет динамических данных?

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

архивируется ли это каким-то образом?

1 Ответ

3 голосов
/ 25 февраля 2012

EDIT:

Только что нашел ответ Брендана МакАдамса, парня из 10gen, который явно авторитетнее меня, и он рекомендует встраивать документы.

старый текст:

Первый - вручную включить в каждый комментарий ObjectID пользователя, которому они принадлежат. 

comment: { text : "...", 
           date: "...", 
           user: ObjectId("4b866f08234ae01d21d89604"),
           votes: 7 }

Второй и самый умный способ - использовать DBRefs

мы добавляем дополнительный ввод / вывод на наш диск, теряя производительность, я прав? (я не уверен, как это работает внутри), поэтому мы должны избегать ссылок, если это возможно, верно?

Да - будет еще один запрос, но драйвер сделает это за вас - вы можете думать об этом как о синтаксисе сахара. Влияет ли это на производительность? На самом деле, это тоже зависит :) Одна из причин, по которой Mongo так чертовски быстр, заключается в том, что он использует отображенные в память файлы и Монго стараются изо всех сил хранить весь рабочий набор (плюс индексы) непосредственно в оперативной памяти. И каждые 60 секунд (по умолчанию) он синхронизирует снимок памяти с файлом на диске.
Когда я говорю рабочий набор , я имею в виду вещи, с которыми вы работаете: вы можете иметь три коллекции - foo , bar , baz , но если вы работаете сейчас только с foo и bar, они должны быть загружены в ram, в то время как baz остается на оставленном диске. Кроме того, отображаемые в память файлы позволяют загружать только часть коллекции. Поэтому, если вы создаете что-то вроде engadget или techcrunch, существует высокая вероятность того, что рабочим набором будут комментарии за последние несколько дней, а старые страницы будут восстанавливаться гораздо реже (комментарии будут появляться в памяти по требованию), поэтому это не так. значительно влияет на производительность.

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

...