Получайте данные быстрее из больших таблиц, используя материализованные представления

Question

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

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

Требования

1. Данные должны загружаться быстро.
2. Данные должны не устареть.

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

Подход 1 : Нашей первоначальной мыслью было использование материализованного представления.

Проблема этого подхода заключается в том, что по мере увеличения данных в таблице user_login_log запрос на обновление sh материализованного представления будет выполняться медленнее, в результате чего выполняются команды INSERT, UPDATE и УДАЛИТЬ операции медленнее.

Подход 2 : Другая идея заключалась в том, чтобы использовать выделенную таблицу снимков для хранения последних данных входа в систему.

И тогда данные будут извлекаться непосредственно из таблицы снимков. Недостатки этого подхода в том, что мы будем поддерживать одни и те же данные в двух таблицах, а функция триггера будет отвечать за поддержание целостности данных.

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

Answer 1

Ваш первый подход не имеет большого смысла. Зачем создавать триггер, который содержит именно ту информацию, которая вам нужна, только чтобы выбросить эту информацию и заставить ее восстановить всю таблицу с нуля? Да, конечно, это будет медленно.

В вашем втором подходе, зачем создавать 2-ю таблицу только для хранения одного столбца информации? Разве у вас уже нет таблицы "app_user", в которую вы можете добавить столбец?

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

Я не вижу проблемы с этим. Разве не для этого нужны триггеры? Просто закодируйте его правильно и убедитесь, что событие входа пользователя в систему выполнено в его собственной транзакции, чтобы избежать блокировки записи на неоправданное количество времени.

Другой вариант - кодировать рекурсивный CTE для выполнения свободный просмотр индекса поверх существующей таблицы user_login_log. Это может быть достаточно быстро, чтобы избежать необходимости делать что-то особенное при записи.

Answer 2

Кажется, у вас есть 2 проблемы. Самый простой, как хранить данные. Это обсуждаемый вопрос. Самым простым, как предлагается, является просто столбец в вашей пользовательской таблице, но возникает вопрос, нужна ли вам история входа. Если это так, то также создайте таблицу login_hist и заполните ее триггером в вашей user_table. Что-то еще, чтобы рассмотреть, могут ли другие приложения (сейчас или в будущем) совместно использовать ту же базу данных. Более сложный вопрос может быть: как вы собираете данные в первую очередь? Вы предложили триггер, но триггер на что. К сожалению, Postgres не предоставляет триггер входа в систему . Возможно, с расширением login_hook . Но это, кажется, нестандартное расширение, многие установки не позволяют его установить. Удачи!