Рекомендации по БД, необходимые для выполнения таблицы 'SessionVisit'

Question

У меня есть таблица SessionVisit, которая собирает данные о посещениях пользователей. Сценарий для этой таблицы ниже. Может быть добавлено 25 000 строк в день.

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

Может кто-нибудь дать мне свой 2с совет по некоторым из этих вопросов:

• Нужно ли беспокоиться о ROWSIZE для этой схемы для SQL Server 2008. Я даже не уверен, как работает размер строки 8 КБ в 2008 году. Я даже не знаю, тратить ли я много места, не использует все 8 КБ?
• Как мне очистить старые записи, которые я не хочу. Будут ли новые строки заполнять пустые места из пропущенных строк?
• Любые советы по индексам

Я знаю, что это довольно общий характер. Любая «очевидная» или неочевидная информация приветствуется.

Вот таблица:

USE [MyDatabase]
GO
/****** Object:  Table [dbo].[SessionVisit]    Script Date: 06/06/2009 16:55:05 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[SessionVisit](
    [SessionGUID] [uniqueidentifier] NOT NULL,
    [SessionVisitId] [int] IDENTITY(1,1) NOT NULL,
    [timestamp] [timestamp] NOT NULL,
    [SessionDate] [datetime] NOT NULL CONSTRAINT [DF_SessionVisit_SessionDate]  DEFAULT (getdate()),
    [UserGUID] [uniqueidentifier] NOT NULL,
    [CumulativeVisitCount] [int] NOT NULL CONSTRAINT [DF_SessionVisit_CumulativeVisitCount]  DEFAULT ((0)),
    [SiteUserId] [int] NULL,
    [FullEntryURL] [varchar](255) NULL,
    [SiteCanonicalURL] [varchar](100) NULL,
    [StoreCanonicalURL] [varchar](100) NULL,
    [CampaignId] [int] NULL,
    [CampaignKey] [varchar](50) NULL,
    [AdKeyword] [varchar](50) NULL,
    [PartnerABVersion] [varchar](10) NULL,
    [ABVersion] [varchar](10) NULL,
    [UserAgent] [varchar](255) NULL,
    [Referer] [varchar](255) NULL,
    [KnownRefererId] [int] NULL,
    [HostAddress] [varchar](20) NULL,
    [HostName] [varchar](100) NULL,
    [Language] [varchar](50) NULL,
    [SessionLog] [xml] NULL,
    [OrderDate] [datetime] NULL,
    [OrderId] [varchar](50) NULL,
    [utmcc] [varchar](1024) NULL,
    [TestSession] [bit] NOT NULL CONSTRAINT [DF_SessionVisit_TestSession]  DEFAULT ((0)),
    [Bot] [bit] NULL,
 CONSTRAINT [PK_SessionVisit] PRIMARY KEY CLUSTERED 
(
    [SessionGUID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO
SET ANSI_PADDING OFF
GO
ALTER TABLE [dbo].[SessionVisit]  WITH CHECK ADD  CONSTRAINT [FK_SessionVisit_KnownReferer] FOREIGN KEY([KnownRefererId])
REFERENCES [dbo].[KnownReferer] ([KnownRefererId])
GO
ALTER TABLE [dbo].[SessionVisit] CHECK CONSTRAINT [FK_SessionVisit_KnownReferer]
GO
ALTER TABLE [dbo].[SessionVisit]  WITH CHECK ADD  CONSTRAINT [FK_SessionVisit_SiteUser] FOREIGN KEY([SiteUserId])
REFERENCES [dbo].[SiteUser] ([SiteUserId])
GO
ALTER TABLE [dbo].[SessionVisit] CHECK CONSTRAINT [FK_SessionVisit_SiteUser]

Answer 1

Я вижу SessionGUID и SessionVisitId, почему в одной и той же таблице есть и уникальный идентификатор, и идентификатор (1,1)? Кажется излишним для меня.

Я вижу referer и knownrefererid. Подумайте о том, чтобы получить реферера от известного rerererid, если это возможно. Это поможет уменьшить избыточные записи.

Я вижу ключ кампании и кампанию, если возможно, снова получаю из таблицы кампаний, если это возможно.

Я вижу orderid и orderdate. Я уверен, что вы можете получить дату заказа из таблицы заказов, верно?

Я вижу имя хоста и имя хоста, тебе действительно нужно имя? Обычно имя хоста не имеет большого значения и может легко ввести в заблуждение.

Я вижу несколько дат и отметок времени, есть ли в этом дубликаты?

Как насчет этого столбца SessionLog? Я вижу, что это XML. Это много данных, это те данные, которые у вас уже есть в других столбцах? Если это так, избавьтесь от XML или дублированных столбцов. Используя SQL 2008, вы можете анализировать данные из этого столбца XML при составлении отчетов и, возможно, исключить несколько дополнительных столбцов (таким образом, записывает). Будут ли у вас проблемы в будущем, когда разработчики добавят больше к этому XML? XML для меня просто кричит «много чрезмерного написания».

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

Удалите часть этой дубликата информации, и вы, вероятно, будете прекрасно писать строку при каждом посещении.

Answer 2

Ну, я бы рекомендовал НЕ вставлять несколько k данных с КАЖДОЙ страницей!

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

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

Answer 3

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

Answer 4

Согласитесь с Крисом, что вам, вероятно, будет лучше использовать анализ журналов (посмотрите бесплатный Microsoft Log Parser )

В противном случае я бы удалил ограничения внешнего ключа из вашей таблицы SessionVisit.

Вы упомянули размер строки; VARCHAR в вашей таблице не выделяют заранее их максимальную длину (больше 4 + 4 байта для пустого поля (прим.)). Но, говоря это, общее правило - сохранять строки как можно более «худыми».

Кроме того, я бы удалил первичный ключ из столбца SessionGUID (GUID). Это вам не сильно поможет.