Сбор аудиторских и статистических данных - PullRequest
Новая
       13

Сбор аудиторских и статистических данных

2 голосов
/ 22 марта 2011

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

Одним из решений было бы создать таблицу в БД для каждого типа события и зарегистрировать ее там.например, пароль изменен, введите дату, пользователя, IP-адрес и т. д. Это предоставит мне необходимую аудиторскую информацию, а также возможность запускать отчеты по таблице, чтобы увидеть, как часто эта функция используется.Недостатком является то, что мне нужно было бы создать новую таблицу для каждого типа события, которое я хочу записать.

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

Итак, мой вопрос: есть ли хорошо используемый (популярный) шаблон, который решает мою проблему?

Ответы [ 2 ]

2 голосов
/ 23 марта 2011

Насколько велико ваше большое веб-приложение?

Регистрация событий в виде блобов XML должна работать, а некоторые базы данных (например, SQL Server) позволяют напрямую запрашивать этот XML.Однако производительность этих запросов ужасна.

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

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

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

Конкретные предложения:

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

Если вы решили зарегистрировать событие как XML, подумайте, есть ли смысл использовать реляционную базу данных для этой цели - если вы можетеЕсли вы будете делать эффективные запросы, тогда простые файлы журналов будут намного проще.Конечно, позже вам придется выяснить, как обрабатывать эти данные журнала, но для нечастых / простых запросов написание некоторых скриптов с использованием grep, awk и т. Д. Займет удивительно долгий путь.

Метод, который обычно используется в настоящее время (очень) крупномасштабными приложениями, - это запись в файлы, а затем выполнение анализа (агрегации) с использованием map-Reduction, например, на Hadoop.

1 голос
/ 22 марта 2011

Промежуточный путь между одной таблицей на событие и одной таблицей (при условии, что разница между событиями - это параметры / данные, переносимые с событием): 

Event Type
  Event Type Id (PK)
  Name
  Number of parameters (useful - not essential)

Event
  Event Id (PK)
  Event Type Id (FK)
  Timestamp

Event Attribute
  Event Attribute Id (PK)
  Event Id (FK)
  Name 
  Value (as string in all cases)
  Sequence Number (within Event. this may well not be needed, but can be a convenience)

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

Я думаю, что это дает вам всю необходимую информацию без необходимости хранить XML.

...