Как Делают меня агрегированные данные Днем и Все еще Часовой пояс Уважения?
Мы в настоящее время используем сводную таблицу, которая агрегировала информацию для наших пользователей на почасовой основе во время UTC. Проблема, которую мы имеем, состоит в том, что эта таблица становится слишком большой и замедляет нашу систему очень. Мы сделали все настраивающиеся методы, рекомендуемые для PostgreSQL, и мы все еще испытываем замедление.
Наша идея состояла в том, чтобы начать агрегироваться днем, а не к часу, но проблема состоит в том, что мы позволяем нашим клиентам изменять часовой пояс, который повторно вычисляет данные на тот день.
Кто-либо знает о способе сохранить ежедневную сводку, но все еще уважать числа и общие количества, когда они переключают часовые пояса?
2 ответа
Суммируйте данные в таблицах со столбцом временного смещения и полем «день» (дата), которое является днем для этой конкретной итоговой строки. Индексируйте (смещение времени, день, другие соответствующие поля), если возможно, сгруппируйте их (предположительно, в PostgresSQL есть кластерные индексы?), И все должно быть в порядке.
Я предполагаю, что вы рассмотрели все аспекты разбиения на разделы, например, разбиение по пользователям.
Я вижу несколько решений вашей проблемы в зависимости от модели использования.
Суммарные данные за день по выбору пользователя. В случае изменения часового пояса программно пересчитайте совокупное значение для этого партнера. Это правдоподобно, если изменение часового пояса происходит нечасто и если при изменении часового пояса пользователем может возникнуть определенная задержка в данных.
Если у вас относительно мало показателей, вы можете поддерживать 24 столбца для каждого показателя, каждый из которых описывает ежедневный агрегированный показатель для показателя в другом часовом поясе.
Если часовые пояса меняются часто и существует множество мер, то кажется, что 24 различных агрегированных таблицы - это лучший вариант.