MongoDB Структура для приложения сообщений

Я раздумываю над идеей о хорошей структуре документа для обработки приложения сообщений.MongoDB Структура для приложения сообщений

Я в основном нужны три (или четыре) типа объектов:

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

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

1. Пользователь

{ 
    username: 'dev.puS', 
    usernameCanonical: 'dev.pus', // used for unique constraints 
    email: '[email protected], 
    emailCanonical: '[email protected], 
    salt: 'some hash', 
    password: 'hash with salt', 
    logs: { last_login: 12.06.2008, last_password_reset: 04.03.2007 }, 
    state: { online: true, available: false }, 
    contacts: [ user_id1, user_id2, user_id3 ] 
}

2. Диалог

{ 
    members: [ user_id1, user_id2 ], 
    messages: [ 
     { author: user_2, body: 'Hi what's up' }, 
     { author: user_1, body: 'Nothing out here :(' }, 
     { author: user_2, body: 'Whanna ask some question on stackoverflow' }, 
     { author: user_1, body: 'Okay, lets go' } 
    ] 
}

Что вы думаете об этой схеме?

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

С уважением

источник

2012-06-27 dev.pus

MongoDB схема никогда не «хорошо» или «плохо» само по себе. Вам нужно подробно рассказать о запросах и обновлениях, которые вы собираетесь сделать. Только тогда вы сможете оценить, подходит ли данная схема для этих шаблонов операций. –

Вам также необходимо оценить распределение размеров данных, например: сколько сообщений будет содержать беседа в среднем максимум? Это может быть важно, если вы хотите вставить. –

Хорошо, я буду помнить об этом. Является ли это распространенным подходом к кешу, например сообщения с redis, и сохранять их все в монго, когда заканчивается сеанс? Я немного не уверен в том, что вы выполняете много действий с записью на «неструктурированный» объект. –

Ваш вопрос действительно один из дизайна схемы. Я предлагаю взглянуть на эту страницу на схему схемы MongoDB, чтобы понять смысл выбора и компромиссы: http://www.mongodb.org/display/DOCS/Schema+Design

Кроме того, вы должны, вероятно, просмотреть ссылки в разделе «Смотрите также» этого документа. Я особенно рекомендую видео-презентации.

Наконец, вы, вероятно, следует взглянуть на этот документ для обсуждения трех возможных схем для обмена сообщениями/комментирование базы данных, в том числе и компромиссах для каждой конструкции: http://docs.mongodb.org/manual/use-cases/storing-comments/

источник

2012-06-27 18:23:43

Я вижу, что этот вопрос старый, но для тех, кто заинтересован, подобный вопрос был задан вопрос и один ответ выглядит жизнеспособного https://stackoverflow.com/a/30830429/132610

Conversation : { 
id: 123, 
members: [ user_id1, user_id2 ] 
} 
Message { conversationId: 123, author: user_2, body: 'Hi what's up' } 
Message { conversationId: 123, author: user_1, body: 'Whanna ask some question on stackoverflow' }

источник

2016-05-25 01:31:01

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

MongoDB Структура для приложения сообщений

ответ

Смежные вопросы