Как спроектировать достижения и пропуски с помощью nosql
В настоящее время у меня есть приложение для социальной игры, использующее mongodb для своей базы данных. Мой вопрос: каковы некоторые предложения, если я хочу создать систему баллов и бейджей. Бизнес-логика для достижений / значков может стать довольно сложной и нерегулярной, поэтому присуждение значков в режиме реального времени не представляется эффективным. Я представляю себе, что добавляю отслеживаемые действия в очередь где-то, например Amazon SQS, или просто использую фид активности пользователя в качестве очереди, и у меня есть другой работающий в автономном режиме рабочий процесс, который просто обрабатывает эффекты каждого действия / действия, чтобы определить, является ли порог для любой конкретный значок пересекается.
Меня беспокоит этот метод: кажется, что запросы к значкам могут стать довольно интенсивными, и мне также придется отслеживать очень большое количество действий. Я могу представить себе достижения, начиная от таких вещей, как значок для кого-то, кто занял 2-е место каждую неделю в течение последних 4 недель, или значок для кого-то, у кого есть друг в каждом из 50 штатов... и т.д....
Есть ли более элегантные или проверенные методы для такого рода вещей? Имеет ли смысл использовать другую базу данных для достижений / каналов активности / таблиц лидеров, кроме mongo, для создания гибридной среды dong / mongo?
Являются ли такие варианты, как Redis, Neo4J или просто старый SQL Server хорошим выбором для гибридного решения? Мне нравится Mongo, так что он останется нашим основным БД, но любопытно посмотреть, поможет ли добавление еще одного БД в микс.
2 ответа
Это хороший кандидат для запуска карты в базе данных. вы можете запускать их на менее регулярной основе, используя их для автономного вычисления нужных вам данных.
http://www.mongodb.org/display/DOCS/MapReduce
Вы можете использовать другие инструменты, чтобы сделать это, но в вашем резюме я не вижу никаких веских причин, чтобы добавить сложность на этом этапе. Я хотел бы изучить карту уменьшения, попробовать ее, а затем, если она не соответствует вашим потребностям, расширить ваши возможности. но в то время вы бы по крайней мере определили конкретные узкие места, если таковые имеются.
Несколько замечаний по использованию graph-db, например Neo4j. Как ваш значок информации всегда? для конкретного пользователя это локальные, а не глобальные запросы.
Так что, если вы можете смоделировать свой домен как сеть объектов (как это, возможно, уже есть) и выразить свою логику значка в виде набора обходов или граф-запросов, начиная с пользователя, тогда он будет работать без сохранения, так как локальные графовые запросы выполняются достаточно быстро, независимо от размер набора данных.
Проще всего создать PoC с временными рамками, чтобы увидеть, работает ли он для вас. Перекрестное соединение двух хранилищ путем сохранения вашего идентификатора пользователя в индексе graph-db и в качестве свойства узла должно работать довольно легко. Вы можете синхронизировать БД на крючках commit/save или асинхронно. Возможно, было бы разумно перенести и другие данные "социальной сети" в график и сохранить данные игры + документы в mongodb.