Вопрос по mongodb – Разработка схемы базы данных MongoDB

12

У меня есть сайт с 500k пользователей (работает на SQL Server 2008). Теперь я хочу включить потоки активности пользователей и их друзей. После тестирования нескольких вещей на SQL Server становится очевидно, что RDMS не является хорошим выбором для такого рода функций. это медленно (даже когда я сильно нормализовал свои данные). Поэтому, посмотрев на другие решения NoSQL, я понял, что могу использовать MongoDB для этого. Я буду следовать структуре данных, основанной наactivitystrea.ms спецификации json для потока активности Поэтому мой вопрос: какой дизайн схемы для потока активности будет лучшим в 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 - Второй дизайн: название коллекции - 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(...) } 

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

Ваш Ответ

2   ответа
20

Я бы использовал следующую структуру:

  1. Use one collection for all actions that happend, Actions

  2. Use another collection for who follows whom, Subscribers

  3. Use a third collection, Newsfeed for a certain user's news feed, items are fanned-out from the Actions collection.

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

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

Самое главное, однако, дизайн разветвления оченьmore flexible и позволяет оценивать релевантность, фильтровать и т. д. Я только недавно написал сообщение в блоге оразработка схемы новостной ленты с MongoDB где я объясняю некоторые из этой гибкости более подробно.

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Michael Simmons
1

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

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

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

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

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

НТН

Похожие вопросы