Управление базой данных событий

Question

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

Только сегодня я добавил 107 000 строк в свою таблицу SiteEvent. Я не думаю, что это устойчиво!

База данных - SQL Server. Я в основном имею в виду лучшие практики в отношении управления большими объемами данных.

Например:

• Должен ли я хранить эти таблицы в базе данных самостоятельно? Если мне нужно объединиться с другими таблицами, это может быть проблемой. В настоящее время у меня есть только одна база данных со всем.
• Как я должен очистить старые записи. Я хочу убедиться, что мой файл базы данных не продолжает расти.
• Рекомендации по резервному копированию и усечению журналов
• Значительно ли добавление дополнительных индексов увеличит размер БД с таким количеством записей?
• Есть ли еще какие-то вещи, которые мне нужны в SQL Server, которые могут вернуться позже, чтобы укусить меня?

К вашему сведению: это таблицы

CREATE TABLE [dbo].[SiteEvent](
    [SiteEventId] [int] IDENTITY(1,1) NOT NULL,
    [SiteEventTypeId] [int] NOT NULL,
    [SiteVisitId] [int] NOT NULL,
    [SiteId] [int] NOT NULL,
    [Date] [datetime] NULL,
    [Data] [varchar](255) NULL,
    [Data2] [varchar](255) NULL,
    [Duration] [int] NULL,
    [StageSize] [varchar](10) NULL,

и

CREATE TABLE [dbo].[SiteVisit](
    [SiteVisitId] [int] IDENTITY(1,1) NOT NULL,
    [SiteUserId] [int] NULL,
    [ClientGUID] [uniqueidentifier] ROWGUIDCOL  NULL CONSTRAINT [DF_SiteVisit_ClientGUID]  DEFAULT (newid()),
    [ServerGUID] [uniqueidentifier] NULL,
    [UserGUID] [uniqueidentifier] NULL,
    [SiteId] [int] NOT NULL,
    [EntryURL] [varchar](100) NULL,
    [CampaignId] [varchar](50) NULL,
    [Date] [datetime] NOT NULL,
    [Cookie] [varchar](50) NULL,
    [UserAgent] [varchar](255) NULL,
    [Platform] [int] NULL,
    [Referer] [varchar](255) NULL,
    [RegisteredReferer] [int] NULL,
    [FlashVersion] [varchar](20) NULL,
    [SiteURL] [varchar](100) NULL,
    [Email] [varchar](50) NULL,
    [FlexSWZVersion] [varchar](20) NULL,
    [HostAddress] [varchar](20) NULL,
    [HostName] [varchar](100) NULL,
    [InitialStageSize] [varchar](20) NULL,
    [OrderId] [varchar](50) NULL,
    [ScreenResolution] [varchar](50) NULL,
    [TotalTimeOnSite] [int] NULL,
    [CumulativeVisitCount] [int] NULL CONSTRAINT [DF_SiteVisit_CumulativeVisitCount]  DEFAULT ((0)),
    [ContentActivatedTime] [int] NULL CONSTRAINT [DF_SiteVisit_ContentActivatedTime]  DEFAULT ((0)),
    [ContentCompleteTime] [int] NULL,
    [MasterVersion] [int] NULL CONSTRAINT [DF_SiteVisit_MasterVersion]  DEFAULT ((0)),

Answer 1

Вы сказали две вещи, которые находятся в конфликте друг с другом.

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

Я также большой поклонник интеллектуального анализа данных, но вам нужны мои данные. На мой взгляд, создайте масштабируемую структуру базы данных и планируйте ее БЫСТРЫЙ рост. Затем возьмите все данные, которые вы можете. Тогда, наконец, вы сможете заниматься всеми интересными данными, о которых мечтали.

Answer 2

Лично я хотел бы хранить записи журнала вне основной базы данных. Производительность вашего приложения сильно пострадала бы от постоянной записи.

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

На вторичной БД вы можете сделать так, чтобы ваши вызовы API вызывали какую-то процедуру удаления базы данных или отсоединения / резервного копирования / повторного создания процедуры обслуживания. Если вам нужен журнал, не стоит отказываться от возможности его использования в будущем.

Если вам нужна какая-то аналитическая служба, лучшим вариантом будет SQL Server. В противном случае MySQL или PostGRE сделают работу намного дешевле.

Answer 3

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

Еще один вариант - выгрузить общий материал в стандартный пакет веб-статистики, а затем проанализировать его обратно в SQL Server с вашими пользовательскими данными вне диапазона.

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

Answer 4

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

Убедитесь, что вы установили большой начальный размер для базы данных и задали большое значение автоматического увеличения, и убедитесь, что у вас не осталось свободного места на диске. 107 тыс. Записей в день будет занимать место независимо от того, как вы его храните.

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

Дополнительные индексы займут место, но опять же, это зависит от того, какие столбцы вы добавите. Если у вас есть 10 ^ 6 строк и вы добавляете некластеризованный индекс, это займет 10 ^ 6 * 4 * 2. Это 10 ^ 6 для фактического индексированного столбца, а также дополнительные 4 байта для первичного ключа, для каждого индексная запись. Таким образом, для каждого 1 миллиона записей некластеризованный индекс в столбце int займет примерно 8 МБ.

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

Что касается ввода-вывода, который, вероятно, будет самым большим препятствием, убедитесь, что у вас достаточно шпинделей, чтобы справиться с нагрузкой, предпочтительно с индексами на их собственном наборе дисков / LUN и фактическими данными на их собственном наборе дисков / ЛУН.

Answer 5

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