На текущем примере нет. Но я исхожу из того, что работа с БД тяжелее, чем работа в оперативной памяти
А зачем тебе нормализовать данные в бд? Какие у тебя кейсы для этого? Пока похоже что достаточно просто snapshot и база не нужна
Я упростил пример и опустил детали, чтобы как-то проще всё описать. В игре много комнат, игроки могут переходить из одной в другую. Все комнаты в памяти хранить невозможно, поэтому там хранятся только активные комнаты (где присутствуют игроки). Т.е. в памяти хранятся активные комнаты и ДАННЫЕ из этих комнат. После того, как комнату покидают все игроки, данные ЗАНОСЯТСЯ в БД и освобождаются из памяти. (и, напротив, если кто-то зашёл в неактивную комнату, данные выводятся из бд). Если комната, куда зашёл новый игрок уже активна, то данные берём из памяти. В БД сохраняется промежуточные результаты действий игроков в комнате. По сути, если игрок просто зашёл в комнату и ничего не делая вышел, то сохранять в бд ничего и не нужно. Но как понять, что он поменял или добавил что-то новое в комнату, если этап сохранения данных это выход игрока из комнаты - пока не понял. Появилась мысль добавить к сущностям из комнаты поля, которые будут это указывать. Либо вести отдельный лог событий в комнате и после занесения данных в бд - очищать
А сколько данных в комнате? Не проще весь Стейт комнаты как одним неструктурированным объектом дампить в бд/диск?
Как вариант, просто писать на каждое действие событие в БД. Если комнату покинули, то ничего делать не надо. Если в комнату зашли, то из лога ивентов по данной комнате собираем стейт. Можно с промежуточными снэпшотами, если данных слишком много и конечный стейт собирать из логов долго. В таком случае получаем и fault tolerance т.к. если сервак упадет, то стейт комнат в памяти пропадет и поднимать будет неоткуда. Можно даже в файл писать.
Это похоже на то, что нужно. Падение, в целом, не проблема. Там на пару минут откат будет всего
Обсуждают сегодня