2008-10-23 136 views
6

我应该如何管理引用网站“活动”的表格。即用户在我用于跟踪的网站上完成的某些活动。我希望能够在用户的不同活动和他们所做的事情之间进行各种数据挖掘和关联。管理网站“活动”数据库

仅今天我就向我的SiteEvent表添加了107,000行。我不认为这是可持续的!

数据库是SQL Server。我主要是指关于管理大量数据的最佳实践活动。

例如:

  • 我应该把这些表中的所有自己的数据库?如果我需要加入其他表格,这可能是一个问题。目前,我只有一个数据库的一切。
  • 我应该如何清除旧记录。我想确保我的db文件不会不断增长。
  • 备份和截断日志的最佳做法
  • 添加其他索引是否会显着增加具有如此多记录的数据库的大小?
  • 任何其他的事情,我需要在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)), 

回答

0

重新思考这个问题可能是医生给你开。每天能记录10万条记录真的有用吗?似乎信息超载给我。也许从减少使用率跟踪的粒度开始吧?

+0

是的!我绝对想要这样做!这仅仅是每个访问者大约9个事件,尽管它不是完全矫枉过正。加上我们预计会有更多流量来临 – Simon 2008-10-23 07:13:10

0

就重新思考问题而言,您可能会探索其中的一个Web统计软件包。示例表中只有几个字段不属于WebTrends或Google Analytics或其他许多开箱即用的实现的一部分。您桌子上的其他项目也可以设置,但请多加思考,并研究哪些套餐可以满足您的所有需求。现在,大多数现成的东西可以处理广告系列跟踪等。

另一个选择是将普通内容卸载到标准web-stats包中,然后用带外自定义数据将其解析回SQL Server。

我不知道你有多少其他数据,但是如果107K +每天记录大量数据,那么最终可能会花费你的时间来处理保持网络统计信息的工作状态,而不是应用程序的实际功能。

+0

我们没有使用一些现成的跟踪功能的主要原因是该网站是基于Flash/Flex的。我也特别希望能够加入其他域特定的表。它做得不错,但我只是想开始听取建议!谢谢 – Simon 2008-10-23 08:12:12

0

我会让他们在同一个数据库中,除非您可以安全地清除/存储OLAP查询的旧记录,然后保留主数据库的OLTP目的。

确保为数据库设置了较大的初始大小并设置了较大的自动增长值,并确保不会耗尽磁盘空间。无论您如何存储它,每天107k个记录将占用空间。

至于备份,这完全取决于您的要求。只要IO子系统能够应付它,每周完整的每日差异和一个/两个小时的差异应该可以正常工作。

其他索引会占用空间,但同样取决于您添加的列。如果你有10^6行,并且你添加一个非聚集索引,它将占用10^6 * 4 * 2。对于实际索引列,这是10^6,并且对于每个主键也是4个字节索引条目。因此,对于每百万条记录,int列中的非聚簇索引将占用大约8MB。

当表增长时,您可以添加服务器并在表上进行水平分区,以便将数据分散到多个服务器上。

至于IO可能会是最大的障碍,请确保您有足够的主轴来处理负载,最好是索引位于其自己的磁盘集/ LUN上,并且实际数据位于其自己的一组磁盘上/ LUN。

1

个人而言,我会保持绝对保持主数据库以外的日志记录。你的应用程序的性能会因不断写入而受到巨大打击。

我认为要走的路是在另一台机器上创建一个辅助数据库,发布一个与底层数据库模式无关的SOAP API,并将应用程序报告给它。我还建议,如果您可能会失去一些这些信息,那么可能写的语义(不要等待确认响应)可以为您做。

在辅助DB上,您可以让API调用触发某种数据库修剪或分离/备份/重新创建维护过程。如果你需要一个日志,那么你不应该放弃它将来有用的可能性。

如果您需要某种分析服务,最好的方法是SQL Server。否则MySQL或PostGRE将会更便宜地完成这项工作。

2

你说了两件彼此冲突的事情。

  1. 我希望能够做各种不同的用户活动和他们所做的事情之间的数据挖掘和关联。
  2. 我想确保我的db文件不会增长。

我也是数据挖掘的忠实粉丝,但您需要挖掘数据。在我看来,创建一个可扩展的数据库设计并为其规划增长做出巨大贡献。然后,抓住你所有的数据。最后,您将能够完成您梦寐以求的所有酷数据挖掘。