我应该如何管理引用网站“事件”的表格。即用户在我用于跟踪的网站上进行的某些活动。我希望能够在用户的不同活动和他们所做的事情之间进行各种数据挖掘和关联。
仅在今天,我就在我的SiteEvent表中添加了107,000行。我不认为这是可持续的!
数据库是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 :(得分:2)
你说过两件相互冲突的事情。
我也是数据挖掘的忠实粉丝,但你需要挖掘数据。在我看来,创建一个可扩展的数据库设计并计划它的成长。然后,抓住你可以获得的所有数据。然后,最后,您将能够完成您梦寐以求的所有酷数据挖掘。
答案 1 :(得分:1)
就个人而言,我会保留绝对保留主数据库之外的日志记录。您的应用程序的性能将因必须不断进行写入而受到巨大打击。
我认为要采用的方法是在不同的机器上创建辅助数据库,发布与底层数据库架构无关的SOAP API,并为其提供应用程序报告。我还建议,如果你可能冒失去这些信息的风险,也许 - 写语义(不要等待确认响应)可以为你做。
在辅助数据库上,您可以让API调用触发某种数据库修剪或分离/备份/重新创建维护过程。如果您需要日志,那么您不应该放弃将来有用的可能性。
如果您需要某种分析服务,最好的方法是SQL Server。否则MySQL或PostGRE将更便宜地完成这项工作。
答案 2 :(得分:0)
重新思考问题可能正是医生所要求的。每天100k的记录真的有用吗?好像信息过载对我来说。也许首先要减少使用情况跟踪的粒度?
答案 3 :(得分:0)
在重新思考问题方面,您可能会探索其中一个网络统计数据包。您的示例表中只有少数字段不属于WebTrends或Google Analytics或其他许多内容的开箱即用实现。您的表中的其他项目也可以设置,但需要更多的思考和一些研究,以满足您的所有需求。如今,大多数现成的东西都可以处理广告系列跟踪等。
另一个选择是将常用内容卸载到标准的web-stats包,然后使用带外自定义数据将其解析回SQL Server。
我不知道你有多少其他数据,但如果每天107K +记录代表其中的大部分数据,你最终可能会花时间处理保持网络统计工作而不是应用程序的实际功能。 / p>
答案 4 :(得分:0)
我会将它们保存在同一个数据库中,除非您可以安全地清除/存储旧记录以进行OLAP查询,然后将主数据库保留为OLTP用途。
确保为数据库设置较大的初始大小并设置较大的自动增长值,并确保不会耗尽磁盘空间。每天107k记录 将占用空间,无论您如何存储它。
至于备份,这完全取决于您的要求。只要IO子系统可以处理它,每周完整的每日差异和一/两小时差异应该可以正常工作。
其他索引会占用空间,但同样取决于您添加的列。如果你有10 ^ 6行,你添加一个非聚集索引,它将占用10 ^ 6 * 4 * 2.对于实际的索引列,这是10 ^ 6,对于每个主键,还有4个字节。索引条目。因此,对于每100万条记录,int列上的非聚簇索引将占用大约8MB。
当表增长时,您可以添加服务器并在表上执行水平分区,以便在多个服务器上分布数据。
至于IO,这可能是最大的障碍,请确保您有足够的主轴来处理负载,最好是索引在他们自己的磁盘集/ LUN上,而实际数据在他们自己的磁盘集上/ LUN。