как спроектировать достижения и пропуски с помощью nosql

Question

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

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

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

Является ли выбор типа Redis, Neo4J или просто старого SQL Server хорошим выбором для гибридного решения? Мне нравится Монго, так что он останется нашим основным БД, но любопытно посмотреть, поможет ли добавление еще одного БД в микс.

Answer 1

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

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

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

Answer 2

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

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

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