Подходит ли CouchDB или CouchBase в качестве сохраняемого решения на основе NoSQL для хранения истории и статистики чатов пользователей? Поскольку история чата, вероятно, потребует записи, а не чтения, какой должна быть структура документа для одной пользовательской истории с некоторой статистикой — один объект, представляющий пользователя со встроенными или отдельными документами для данных истории (множество небольших документов) и некоторые статистические данные (небольшое количество документы)?
CouchDB для сохранения истории чата и пользовательской статистики
Ответы (1)
Да, CouchDB или Couchbase подходят.
Поскольку история чата требует много записей, я думаю о чем-то, что упрощает запись: просто бросьте документ и позвольте CouchDB позаботиться о его агрегировании. В одном быстром POST вы можете описать сообщение чата, кто его отправил, отметку времени, какой чат и т. д.
сопоставление представления CouchDB создаст единую сущность, представляющую пользователя с его историческими данными. Например, если вы хотите узнать количество пользовательских сообщений, ваша функция карты выдаст такой ключ:
emit([doc.username, doc.year, doc.month, doc.day, doc.hour, doc.minute], 1);
А функция сокращения суммирует все значения. Теперь вы можете запросить годовой объем пользователя,
group_level=3&startkey=["somebody",2011,null]&endkey=["somebody",2011,{}]
или (увеличивая уровень группы) месячный объем, дневной объем, часовой объем и т. д.
Соображения
Этот метод имеет свои издержки и преимущества. Основной компромисс заключается в том, что обновления должны быть простыми, а отчеты должны быть обоснованными. В вашем примере с 10 000 обновлений в день я нервничаю, думая о 409 Conflict отклонениях, или поддерживая код разрешения конфликтов, или заставляя клиента изящно восстанавливаться после ошибки, когда накапливается больше сообщений!
Предлагаемая методика помогает. Каждое обновление изолировано от других, обновления могут происходить не по порядку, восстановление после ошибок не так уж плохо. Просто повторите попытку несколько раз в фоновом режиме. (Обратите внимание, я лично выступаю за то, чтобы обновления были простымиможет быть, я предвзят.)
Стоимость заключается в «пустой трате» дискового пространства, а извлечение данных требует (относительно) больше работы. CouchDB медлительна и расточительна, как грузовики медленны и расточительны. На самом деле грузовики распространены в богатых странах и редко встречаются в бедных, потому что они являются более выгодной долгосрочной сделкой. Эмоционально мы видим, как грузовики ковыляют и извергают черный дым, но рационально мы знаем, что они более эффективны.
Большая часть статистики может быть прямой картой/уменьшением просмотров. Однако вы также можете вести «сводные» документы с агрегированными или независимыми результатами или с чем-либо еще, что вам нужно. Частые обновления не проблема (в этом масштабе: 86 400 обновлений в день — это всего лишь 1 раз в секунду). Но вам может понадобиться специальный клиент «обновления» для этих документов. Если только один клиент работает над обновлением специальных документов, вы не получите 409 Conflicts, поскольку никто другой не борется за обновление того же документа.
person
JasonSmith
schedule
15.06.2011
Если каждое сообщение чата будет представлено в виде отдельного документа, не будет ли место на диске быстро заполняться этими документами (скажем, речь идет о ~10k сообщений в день)? Также может ли пользовательская статистика храниться в одном документе со встроенными документами, представляющими конкретную статистику, которая будет часто обновляться?
- person yojimbo87; 15.06.2011
CouchDB не очень эффективен на диске. Причина в том, чтобы использовать дополнительное дисковое пространство для облегчения разработки. Кого волнует ГБ, когда разработчики стоят $x? Во всяком случае, у меня есть две базы данных с примерно 10 000 документов, одна 44,5 МБ, другая 5,9 МБ. Если подумать, 100 МБ в день для данных плюс просмотры — это 36,5 ГБ в год для хранения. Для меня даже 100 или 200 ГБ в год хранения не проблема, iff база данных расслабляется.
- person JasonSmith; 15.06.2011
Я понимаю вашу точку зрения, и она приемлема. Что касается единого документа, в котором хранится статистика, ориентированная на пользователя, с небольшим количеством встроенных документов - хорошая ли идея дизайна, если этот документ будет часто обновляться в режиме реального времени?
- person yojimbo87; 15.06.2011
Я отредактирую ответ, чтобы обсудить это; надеюсь, это будет более понятно, чем комментарии.
- person JasonSmith; 16.06.2011
