Просмотров страницы журнала SQL Server

Question

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

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

Вот пара идей, но я полностью открыт для любых советов. Мне понадобится конечный результат в SQL Server, с сохранением многих переменных сеанса.

1. Настроить журналы IIS для сохранения журналов с помощью переменных сеанса, а затем импортировать файлы журнала в SQL Server по ночам. Использование Response.AppendToLog в ASP. Я считаю, что недостатком здесь является то, что я ограничен в том, как я могу добавить.

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

3. Используйте стороннюю компанию, такую ​​как Google Analytics. Проблема здесь в том, что информация о сеансе пользователя чувствительна, и я не уверен, насколько много, если google позволяет мне передавать переменные им. И мне может потребоваться зашифровать данные перед отправкой, а затем расшифровать его, чтобы вернуть его на SQL Server.

4. Напишите прямо в текстовые файлы, а затем импортируйте их в ночное время. Я думаю, что DISK I/O будет таким же высоким с этим подходом.

Веб-сайты в основном написаны на классических ASP и ASP.net. Какой оптимальный подход?

Спасибо за помощь.

Answer 1

5 - Нормализовать таблицы регистрации SQL. Я уверен, что существует много информации, которую вы дублируете (т. Е. «Информация о сеансе»). Для каждого нового сеанса создайте новую запись в своей таблице «Сессии», а в таблице «SessionDetail» записывается конкретная информация о просмотренных страницах и т. Д.

Вы действительно не должны создавать взаимоблокировки.

Ваш вариант №2 должен работать нормально, если вы правильно его разработали, но это будет зависеть от того, как вы используете данные. Если вы НИКОГДА не обновляете свои исторические (то есть до сегодняшнего дня) журналы, я бы сделал для них отдельную БД, и ваши активные таблицы ведения журнала с интенсивной записью в отдельном БД на отдельном диске. Другой вариант, связанный с этим, заключается в создании нескольких протоколов регистрации для распределения дискового ввода-вывода. Если у вас есть несколько платформ/серверов, которые вы контролируете, вы можете иметь их всех в разных БД и использовать представление, чтобы просмотреть их все одновременно.