CouchDB для сохранения истории чатов и статистики пользователей - PullRequest
2 голосов
/ 14 июня 2011

Подходит ли CouchDB или CouchBase в качестве постоянного решения на основе NoSQL для хранения истории и статистики чатов пользователей?Поскольку история чата, скорее всего, потребует записи, а не чтения, какова должна быть структура документа для истории одного пользователя с некоторой статистикой - единая сущность, представляющая пользователя со встроенными или отдельными документами для данных истории (множество небольших документов) и некоторая статистика (небольшое количестводокументы)?

1 Ответ

3 голосов
/ 15 июня 2011

Да, 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 Conflict с, поскольку никто не борется за обновление этого документа.

...