Эффективный способ хранить акции постов в MongoDB на сайте социальной сети? - PullRequest
Новая
       26

Эффективный способ хранить акции постов в MongoDB на сайте социальной сети?

1 голос
/ 13 января 2012

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

Вариант использования: у вас есть подключения.Вы видите сообщения из ваших подключений или сообщения, опубликованные вашими подключениями.Посты имеют «скорость», по которой они упорядочены на странице.Общий пост может либо наследовать и сохранять скорость оригинала, либо жить, либо умирать собственной скоростью.Не уверен, что лучше.

Опции, которые я рассмотрел: 

Post {id :uniquePostId, userId: authorId, shares: [userIds of those who shared], tagIds: [tagIds for post]}

Проблема с этим методом: Mongo не позволяет индексировать два массива.Таким образом, запрос медленный, как ад, если вы хотите делать запросы как по tagIds, так и по общим ресурсам.Индексирование обоих по отдельности приводит к почти полному сканированию таблицы.

Другой вариант:

Вы дублируете сообщение следующим образом: 

Post {id: uniquePostId, userId: user who authored or shared the post, original: {postId: the original postId, or null if this is it, userId: the author of the original post}}

Проблемы с этим подходом: скажем, вы хотитечтобы получить 20 сообщений, вы запрашиваете идентификатор пользователя в своих соединениях. Как вы справляетесь с дублирующимися ресурсами в своих соединениях?Становится некрасиво.

Другие подходы, которые я читал: 

post: {
 shares_and_tags: [{type: share, id: 1}, {type: tag, id:4}, ...]
}

Кажется, это решает проблемы с индексацией, но я не знаю достаточно о Mongo, чтобы понять последствия для производительности здесь,Вскоре проведу тестирование, но подумал, что я посмотрю, есть ли у сообщества какие-либо советы или опыт.Спасибо!

1 Ответ

0 голосов
/ 03 февраля 2012

ОК, учитывая обсуждение в комментариях:

вот так выглядит твит, когда он приходит из потокового API Twitter после его сохранения в mongodb, я удалил некоторые несущественные данныеДля упрощения примера: 

{
    "_id" : ObjectId("4f2849353ac01aebf231408a"),
    "place" : null,
    "text" : "tweet text",
    "created_at" : "Tue Jan 31 20:04:05 +0000 2012",
    "retweet_count" : 0,
    "favorited" : false,
    "source" : "<a href=\"http://mobile.twitter.com\" rel=\"nofollow\">Mobile Web</a>",
    "in_reply_to_screen_name" : null,
    "in_reply_to_user_id" : null,
    "retweeted" : false,
    "in_reply_to_status_id" : null,
    "in_reply_to_status_id_str" : null,
    "id_str" : "123456767800304",
    "user" : {
    },
    "truncated" : false,
    "id" : NumberLong("1234567890"),
    "in_reply_to_user_id_str" : null,
    "entities" : {
        "hashtags" : [ ],
        "user_mentions" : [ ],
        "urls" : [ ]
    }
}

Как видите, каждый твит сохраняется как новый твит.Если бы это был повторный твит, для него был бы установлен ретвитированный флаг, равный true, и идентификатор публикации, на которую он отвечал, а также пользователя, на который он отвечал в ссылках в полях верхнего уровня.

...