Оптимизация SQL для определения уникальных просмотров страниц для пользователя

Question

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

Я уже реализовал кеш заголовков HTTP, но теперь мне нужно оптимизировать SQL-запросы.

Визит является уникальным, когда:

• пара: page_id + user_id находится в таблице visit
• или пара: page_id + session_id найдено
• или: page_id + [ip + useragent] - (это тема для другого обсуждения, будь то только ip или ip + useragent)

Итак, у меня есть таблица отслеживания посещений пользователей:

visit:
    page_id
    user_id
    session_id
    useragent
    ip
    created_at
    updated_at

Теперь при каждом посещении пользователя (которое не попадает в кэш) я буду обновлять строку, если она существует. Если есть какие-либо затронутые строки, я добавлю новое посещение таблицы.

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

Вопросы:

• как должна быть построена таблица visit (ключи, индексы, отношения к user и page_views таблицам). Некоторые из важных полей могут быть нулевыми (например, user_id), тогда как насчет индексов? Нужен ли многостолбцовый первичный ключ?
• Какой самый быстрый sql-запрос для поиска уникального пользователя?
• это здравый подход?

Я использую PostgreSQL и PDO (Doctrine ORM). Все мои сеансы хранятся в одной БД.

Answer 1

Лично я бы не поместил это в путь запрос-ответ. Я бы записывал необработанные данные в таблицу (или помещал их в очередь) и позволял справиться с этим фоновой задаче / потоку / cron.

Затем очередь (или таблица передачи сообщений) должна содержать только pageid, userip, sessionid, useragen, ip.

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

Answer 2

Просто некоторые случайные мысли:

Могу ли я проверить, что за уникальными типами посещений стоит следующая мысль:

1. pageid + userid = пользователь вошел в систему
2. pageid + sessionid = пользователь не идентифицирован, но файлы cookie включены
3. pageid + ip / useragent = пользователь не идентифицирован и файлы cookie не включены

Для необработанной производительности вы можете считать № 2избыточно, поскольку # 3 будет , вероятно, охватывать # 2 в большинстве случаев (или это важно # 2, например, если пользователь затем регистрируется, а затем # 2 можно сопоставить с # 1)?(имеется в виду, что идентификатор сеанса может все еще регистрироваться, но не использоваться при любом определении посещения)

IMHO IP всегда будет присутствовать (даже если подделан) и будет хорошим кандидатом для индекса.Пользовательский агент может быть скрыт и будет иметь только ограниченный диапазон (не очень выбираемый).

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

ИМХО ваша идея о сохранении ВСЕХ посещений, а затем обрезке дубликатов с помощью пакетной обработки является хорошей идеей для взвешивания (вместо проверки наличия обновлений и вставки новых)

• Так что PK = Суррогат
• Кластеризация = Не уверен - другой запрос / требование может улучшить это.
• Некластерный индекс = IP-адрес, идентификатор страницы (при условии, что IP-адреса более различны, чем идентификаторы страницы)