Блог

В настоящее время у меня есть приложение для социальных игр, использующее mongodb для своей базы данных. Мой вопрос в том, какие есть предложения, если я хочу создать систему баллов и маркировок. Бизнес-логика для достижений / значков может стать довольно сложной и очень разовой, поэтому присвоение значков в режиме реального времени не будет эффективным. Я представляю, как добавляю отслеживаемые действия куда-нибудь в очередь, например, Amazon SQS, или просто использую ленту активности пользователя в качестве очереди, и у меня есть другой автономный рабочий процесс, проходящий и просто обрабатывающий эффекты каждого действия / activity, чтобы увидеть, пересечен ли порог для какого-либо конкретного значка.

Меня беспокоит этот метод в том, что, похоже, запросы на значки могут стать довольно интенсивными, и мне также придется отслеживать очень большое количество действий. Я могу представить достижения, начиная от таких вещей, как значок для кого-то, кто занимал 2-е место каждую неделю в течение последних 4 недель, или значок для кого-то, у кого есть друг в каждом из 50 штатов … и т.д…

Существуют ли более элегантные или проверенные методы для такого рода вещей? Имеет ли смысл использовать другую базу данных для достижений / ленты активности / списков лидеров, помимо mongo, создавая гибридную среду mongo / other db?

Являются ли такие варианты, как Redis, Neo4J или просто старый SQL Server, хорошим выбором для гибридного решения? Мне нравится Mongo, поэтому он останется нашей основной базой данных, но любопытно посмотреть, поможет ли добавление другой базы данных в микс.

Это хороший кандидат для запуска map reduce в базе данных. вы можете запускать их на менее регулярной основе, используя их для автономного вычисления нужных вам данных.

http://www.mongodb.org/display/DOCS/MapReduce

Вы могли бы использовать другие инструменты для этого, но в вашем резюме я не вижу никаких веских причин для усложнения на данном этапе. Я бы изучил map reduce, попробовал его, а затем, если он не соответствует вашим потребностям, расширил ваши возможности. но в то время вы, по крайней мере, определили бы конкретные узкие места, если таковые имеются.

Просто несколько замечаний по использованию graph-db, такого как Neo4j. Как всегда информация о вашем бейджике? запрашиваемые для конкретного пользователя, это локальные, а не глобальные запросы.

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

Проще всего создать PoC с временными рамками, чтобы посмотреть, работает ли это для вас. Перекрестное соединение двух хранилищ путем сохранения вашего идентификатора пользователя в индексе graph-db и в качестве свойства на узле должно работать довольно легко. Вы можете синхронизировать базы данных с помощью перехватов фиксации / сохранения или асинхронно. Возможно, было бы разумно перенести и другие данные «социальной сети» в график и сохранить данные игры документы в mongodb.