Представления страниц журнала SQL Server - PullRequest
Новая
       8

Представления страниц журнала SQL Server

0 голосов
/ 06 декабря 2010

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

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 06 декабря 2010

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

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

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

...