Схема схемы базы данных MongoDB

Question

У меня есть сайт с пользователями 500 тыс. (Работает на SQL Server 2008). Теперь я хочу включить потоки активности пользователей и их друзей. После тестирования нескольких вещей на SQL Server становится очевидным, что RDMS не является хорошим выбором для этой функции. он медленный (даже когда я сильно де-нормализовал свои данные). Поэтому, посмотрев на другие решения NoSQL, я понял, что могу использовать MongoDB для этого. Я буду следить за структурой данных на основе activitystrea.ms json specifications for activity stream Итак, мой вопрос: какой был бы лучший дизайн схемы для потока активности в MongoDB (с помощью этого множества пользователей вы можете в значительной степени предсказать, что он будет очень тяжелым на записи, поэтому мой выбор MongoDB - это отличная «запись» производительности. Я подумал о трех типах структур, скажите, пожалуйста, если это имеет смысл или я должен использовать другие схемы.

1 - Хранить каждый деятельность со всеми друзьями/последователями по этой схеме:

 

    { 
    _id:'activ123', 
    actor:{ 
      id:person1 
      }, 
    verb:'follow', 
    object:{ 
      objecttype:'person', 
      id:'person2' 
      }, 
    updatedon:Date(), 
    consumers:[ 
      person3, person4, person5, person6, ... so on 
      ] 

    } 

2 - Второй проект: Collectio п поименных activity_stream_fanout

 

    { 
    _id:'activ_fanout_123', 
    personId:person3, 
    activities:[ 
    { 
    _id:'activ123', 
    actor:{ 
      id:person1 
      }, 
    verb:'follow', 
    object:{ 
      objecttype:'person', 
      id:'person2' 
      }, 
    updatedon:Date(), 
    } 

    ],[ 
    //activity feed 2 
    ] 

    } 

3 - Такой подход будет хранить элементы деятельности в одной коллекции, а также потребитель в другом. В деятельности, вы можете иметь документ, как:

 

    { _id: "123", 
     actor: { person: "UserABC" }, 
     verb: "follow", 
     object: { person: "someone_else" }, 
     updatedOn: Date(...) 

    } 

А потом, для последователей, я бы следующие «уведомления» документы:

 

    { activityId: "123", consumer: "someguy", updatedOn: Date(...) } 
    { activityId: "123", consumer: "otherguy", updatedOn: Date(...) } 
    { activityId: "123", consumer: "thirdguy", updatedOn: Date(...) } 

Ваши ответы очень ценятся.

Answer 1

Я бы со следующей структурой:

1. Используйте один сбор для всех действий, которые СЛУЧИЛОСЬ, Actions

2. Используйте другую коллекцию для тех, кто за кем, Subscribers

3. Используйте третью коллекцию, Newsfeed для определенного пользователя n ews feed, элементы выходят из коллекции Actions.

Newsfeed коллекция будет заполняться рабочим процессом, который асинхронно обрабатывает новый Actions. Поэтому новостные ленты не будут заполняться в режиме реального времени. Я не согласен с Geert-Jan в том, что в реальном времени важно; Я считаю, что большинство пользователей не заботятся даже о небольшой задержке в самых (не для всех) приложений (для реального времени я бы выбрал совершенно другую архитектуру).

Если у вас очень большое количество consumers, то вентилятор может занять некоторое время, правда. С другой стороны, включение потребителей прямо в объект не будет работать с очень большим количеством следящих элементов, и это создаст слишком большие объекты, которые занимают много индексного пространства.

Самое главное, однако, вентилятор-аут дизайн гораздо более гибким и позволяет релевантность скоринг, фильтрации и т.д. Я только недавно написал сообщение в блоге о news feed schema design with MongoDB где я объяснить некоторые из этой гибкости более подробно.

Говоря об гибкости, я был бы осторожен в отношении этой activitystrea.ms spec. Кажется, это имеет смысл как спецификация взаимодействия между разными провайдерами, но я не буду хранить всю эту подробную информацию в своей базе данных, если вы не собираетесь собирать действия из разных приложений.

Answer 2

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

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

С этой точки зрения (я не думал об этом) идти с 1, так как 2. кажется, что пакетные действия для определенного пользователя перед их обработкой? Таким образом, если не удается «немедленная» необходимость обновления. Более того, я не вижу преимущества 3. более 1 для этого случая использования.

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

по некоторой связанной заметке: в зависимости от того, как вы, возможно, захотите реализовать уведомления в реальном времени для этих потоков активности, стоит обратить внимание на Pusher - http://pusher.com/ и аналогичные решения.

НТН