Выбор базы данных для системы достижений
Что нужно сделать:
- Система достижений для игры, которая поддерживает несколько игроков (онлайн).
- Он должен поддерживать различные типы триггеров: от простых, таких как "Собрать X элементов", до сложных, таких как "Пользователь, достигший 5-го уровня, собрал элемент A в понедельник и элемент B во вторник".
- Поддержка до 5 событий / сек, собранных от пользователя и сохраненных для дальнейшего использования.
Поэтому, насколько я вижу, для реализации поддержки сложных достижений необходимо сохранять все связанные пользовательские взаимодействия в базе данных, а затем выполнять некоторые запросы агрегации, чтобы решить, получит ли пользователь достижение или нет.
Варианты типов БД:
- традиционные реляционные СУБД, такие как PostgreSQL, например.
- ориентированные на столбцы СУБД, такие как ClickHouse
- некоторая база данных NOSQL.
Нет ничего особенного в использовании традиционных реляционных СУБД. Но меня интересует производительность запросов, потому что данных будет много, и запросу нужно будет сканировать много данных.
В отличие от традиционных баз данных, ориентированных на столбцы, они ориентированы на аналитические запросы, которые соответствуют модели достижений, потому что для того, чтобы решить, давать или не давать пользователю достижение, нам нужно проанализировать некоторую часть данных. Однако колоночные базы данных хороши с большими наборами данных, но не с большим количеством одновременных запросов. А большое количество игроков означает, что будет много одновременных запросов.
С базами данных NOSQL это тоже не очень понятно. Map-Reduce предлагает множество вариантов, но я также заинтересован в его производительности. Но, с другой стороны, процесс масштабирования баз данных NOSQL менее "болезненный", поэтому некоторые проблемы с производительностью будут решаться аппаратно.
Какой тип БД или какая-то конкретная БД даст наилучшую производительность? Любые рекомендации и предложения очень ценятся. Благодарю.
2 ответа
Хорошо, я не собираюсь отвечать на ваш вопрос, но я постараюсь помочь вам ответить на ваш вопрос.
Это решение основано на нескольких ограничениях, но самое важное - это вы. Как вы думаете, что вы могли бы сделать лучше. Вы понимаете нормализацию базы данных и SQL больше или меньше, чем NoSQL / MapReduce? Вы чувствуете, что можете сопоставить свой домен с единственной таблицей? Или вам удобнее описывать это как отдельные таблицы?
Ваш домен по своей сути не подталкивает вас так или иначе, вы не выполняете массивные временные ряды (столбчатые), обрабатываете большое количество неструктурированных / полуструктурированных данных (nosql) или учетные транзакции (реляционные), так что вы можете придумать разумное решение с любым подходом. Какой из них вы выберете, должен больше зависеть от ваших знаний и возможностей, чем от предметной области.
Лично я вырос на разработке реляционных баз данных, поэтому в отсутствие веской причины использовать другую структуру данных это приводит к созданию реляционной базы данных. Вот как мой мозг по умолчанию. Все остальное - предварительная оптимизация, которая, как мы все знаем, является корнем всего зла.
Похоже, вы собираетесь реализовать множество сложных "достижений" со сложными триггерами.
Прежде всего вы должны решить, как вы собираетесь записывать основные события. Если их структура известна и они могут храниться в фиксированной схеме (например, user_id, event_name, created_at), тогда реляционная БД может быть самой легкой ставкой. Однако при большом количестве вставок задание агрегации может снизить производительность (вы не хотите блокировать чтение таблицы с большим количеством конфликтов записи).
Мне кажется, что вы, вероятно, очень быстро перерастете простую фиксированную схему. События могут иметь очень разные метаданные.
Графическая база данных может быть хорошим выбором здесь: вы можете хранить события в виде ребер (с произвольными прикрепленными данными значения ключа) и быстро и эффективно запрашивать произвольные отношения в своем агрегаторе.
Кроме того: стоит подумать, как вы будете сохранять результаты агрегации и что делать с ними, если ваши правила игры изменятся.