MongoDB chat best way?

Question

[Damir Makhmutov]

Мой первый опыт с mongodb. Я пока еще не одуплился, чтобы стать джедаем, и поэтому хочу спросить совета.
Необходимо сделать чат юзер-юзер, используя именно монгу. Сопутствующие технологии - nodejs, socket.io, но это не столь важно.
Начал думать над схемой документа, и над самими коллекциями. Гугл почему-то мне не помог. Может я просто плохо пытался, но кажется что нет.
Прикинув на листочке как это может быть выглядеть, накалякал такое:

collections:

users: {
    _id: login,
    userId: int
    name: str,
    avatar: str
}

userId - идентификатор в основной базе (mysql) юзера. Почему то в качестве _id моё нутро подсказало использовать именно login, а он уникальный. Может быть я ошибся ?

Далее:

dialogs: {
    precedents: [userId, userId],
    messages: [{
       date: ...,
       text: ...,
       sender: userId
    }]
}

И тут встал вопрос: правильно ли хранить сообщения в поле-массиве документа ? Как обстоят дела с производительностью при такой схеме ?
Вообще хотелось бы услышать советов, как лучше организовать хранение таких данных в mongo.

Answer 1

[Андрей]

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

1. Размер записи в монге ограничен - сейчас это 16 мег.
2. В конкурентной среде достичь атомарности при такой записи у вас не получится. Будет race.

И да, я знаю, что вы скажете - 16 мег хватит всем, и такого интенсивного обмена, чтобы случился race, не возникнет. Я вам тогда напомню про 640 килобайт, и про закон Мерфи - если какая-нибудь неприятность может случиться - она обязательно случится.

Резюме - не делайте так.

Comments

[Damir Makhmutov]

Согласен, с 16мб я прогадал, не дочитал видимо. Но мне совершенно непонятно почему вы так категорично не рекомендуете использовать монгу для данной цели. Как бы сделали вы, будь у вас основная бд монга?

[Андрей]

Будь у меня основная БД монга (а это так и есть), я бы использовал монгу. Я бы не делал лог общения в одной записи - делал бы каждый месседж отдельной записью (как собственно и делаю). Я бы уж точно не трогал бы _id - можно добавить к полю login уникальный индекс, или вязать пользователей по _id прям (как я и сделал). И я бы сделал очередь, в которую бы буферизировал ввод (потому что очередь тупо быстрее работает, чем мускуль или монга), c тем, чтобы улучшить отзывчивость приложения (ведь для чата эта запись вовсе не нужна, лучше делать ее асинхронно, возможно даже - вообще на другом сервере).

[Damir Makhmutov]

Именно такого совета я и ждал, задав вопрос "как лучше организовать хранение таких данные в монго". Спасибо)

Answer 2

[Vit]

Лучше каждое сообщение отдельной записью в коллекции делать.

Comments

[Damir Makhmutov]

Спасибо, я в принципе так и сделал, пока что работает :-)

Answer 3

[Андрей]

Вы ошиблись c выбором БД для своих целей. Совершенно непонятно, зачем тут нужна монга, какова цель. Чат юзер-юзер замечательно работает вообще без базы данных, я могу на nginx поднять чат юзер-юзер вообще без бэкенда. Если БД нужна, чтобы просто хранить логи общения, подойдет любая БД с буффером в виде быстрой очереди (если планируете высокую нагрузку) или вообще без буферизации дополнительной.

Ну и, да _id монге лучше дать делать самой.

Comments

[Damir Makhmutov]

Дело в том, что nodejs на бекенде уже используется для некоторых задач. Было решено использовать его же и для чата. В интернетах по ключевым словам "nodejs chat" почти везде (а точнее ничего кроме) предлагают использовать монгу. Почитав про неё - показалось интересным решить задачу, исползуя монгу. "подойдет любая БД с буффером в виде быстрой очереди" - а чем монга не "любая быстрая бд" ?)

[Андрей]

Тем, что вы написали ранее, что основная база у вас MySQL, а к монге вы явно не c той стороны подходите. Лягнет. Лучше использовать привычные интерфейсы. Прям сейчас я помогаю одному студенту проектировать курсовик про масс-чат. И так выходит, что БД нужна по сути только для хранения логов. Вы напишите сначала чат, а потом уж допишете хранение логов, это будет правильным решением. И тогда, поверьте, вам будет совершенно по барабану, в какой БД хранить эти логи. И даже больше скажу - монга не покажется вам наилучшей БД для этого.