Когда можно хранить производные данные в базе данных?

Question

В настоящее время у меня есть таблица GAME с двумя полями

user_id, win

win = 1 для выигрыша, 0 для проигрыша

Предположим, я хочу отобразить процент выигрыша.Это довольно тривиально с операцией подсчета.Однако предположим, что я хочу отображать тысячи пользователей на одной странице с процентом выигрыша для каждого.У меня есть некоторые проблемы с масштабируемостью по этому сценарию.Не слишком ли много хака для создания отдельной таблицы кеша со следующими полями

user_id, win_percentage

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

Answer 1

Люди из хранилища данных говорят, что всегда целесообразно хранить производные данные в базе данных. Пока это не обновлено.

Вопрос один из обновлений.

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

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

В этом проблема хранения производных данных. Стоимость обновления может фактически перевесить стоимость вычислений. Вы не знаете без фактической статистики использования.

Таким образом.

Не сохраняйте производные данные, пока не сможете доказать (с фактическими измерениями), что его эффективнее хранить.

Answer 2

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

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

Вы измерили и определили, что это проблема, а не просто думаете, это может быть проблемой, верно?

Помните, и я перефразирую:

преждевременная оптимизация без профилирования - корень зла!

Изменение структуры данных может быть лучшим решением.

user_id, wins, loses, percentage

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