楼主: fan0124

[精华] 再谈大数据量的数据表设计

[复制链接]
论坛徽章:
11
2010新春纪念徽章
日期:2010-03-01 11:19:072014年新春福章
日期:2014-02-18 16:42:02优秀写手
日期:2014-02-09 06:00:122011新春纪念徽章
日期:2011-02-18 11:43:34数据库板块每日发贴之星
日期:2010-12-22 01:01:01数据库板块每日发贴之星
日期:2010-11-26 01:01:012010广州亚运会纪念徽章:拳击
日期:2010-11-22 15:26:49ITPUB9周年纪念徽章
日期:2010-10-08 09:28:51数据库板块每日发贴之星
日期:2010-07-10 01:01:04数据库板块每日发贴之星
日期:2010-07-07 01:01:01
61#
 楼主| 发表于 2010-4-14 20:03 | 只看该作者
原帖由 newkid 于 2010-3-11 00:10 发表
1.1. 之前你给出了:select t1.pv_pageurl,MAX(t1.pv_siteid) from pd_pv1 t1 GROUP BY pv_pageurl

      确实用这个可以首先得到去重后的pageurl后,同时取得对应的siteid

      但是我尝试着改写成:select t1.pv_pageurl,t1.pv_siteid from pd_pv1 t1 GROUP BY pv_pageurl,pv_siteid
      
    这样执行,结果居然也是正确的,用group by + select的字段这样就可以了吗?虽然结果正确,但是不清楚是为什么呢?

如果一个pv_pageurl对应一个pv_siteid,那么GROUP BY pv_pageurl和GROUP BY pv_pageurl,pv_siteid分组结果就是一样的。GROUP BY就是把相同的键值归为一组。你如果还不清楚就得在SQL方面补补课了。

1.2. “注意你的pd_pv1必须是高度规范化的,不该保存的冗余尽量去掉。”  是不是对这个基础PV表(1000W记录/日)要保证3NF的设计?
是的。

这些冗余算合理不?还有关于地区ID,我冗余上了地区名称,这个有必要吗?

你仅仅是打算节省表连接的时间吗?付出的代价就是存储空间。试验一下两种表结构效率有什么不同?是否值得保存这些冗余?
FACT表的设计应该规范化,里面仅仅保存DIMENSION ID. 而DIMENSION表可以逆规范化。我觉得你要尽量减少冗余。无非就是生成统计表的时候连接的表更多些。


1.3. 来路统计分析中的过滤问题
  解决:需要把其中1个的独立访客显示为0,因为都是同一个访客,这样按照访问的时间先后顺序来说,有一个来路页面的独立访客数需要是0。

我认为你的解决并不合理。因为这个指标在不同粒度上是不可累加的。必须设计不同粒度的统计表,分别保存自己的结果。
你的例子中恰好7个访客的pv_siteid都不同。如果同一个访客访问了两个pv_siteid你要怎么办?把其中的一个算0?


  问题:要达到这样的效果,SQL应该怎么改写呢?
不管如何,你的需求可以用如下SQL来实现,我只是告诉你有这么个技巧:

  select pv_referurl AS 来路页面
      ,pv_referdomain AS 来路域名
      ,pv_siteid AS 网站ID
      ,pv_pagetitle AS 页面标题
      ,pv_source AS 来路分类
      ,COUNT(pv_id) AS PV
      ,COUNT(DISTINCT pv_visitorid) AS 独立访客
      ,COUNT(DISTINCT pv_ip) AS IP
      ,COUNT(DISTINCT pv_visitid) AS 访问次数
  from (SELECT pv_referurl,pv_referdomain,pv_siteid,pv_pagetitle,pv_source,pv_id
              ,DECODE(ROW_NUMBER() OVER(ORDER BY page_visittime),1,pv_visitorid,NULL) AS pv_visitorid
              ,DECODE(ROW_NUMBER() OVER(ORDER BY page_visittime),1,pv_ip       ,NULL) AS pv_ip
              ,DECODE(ROW_NUMBER() OVER(ORDER BY page_visittime),1,pv_visitid  ,NULL) AS pv_visitid
        pandian.pd_pv1
       )t1
  --where page_visittime >= TRUNC(SYSDATE)
  group by pv_referurl,pv_referdomain,pv_siteid,pv_pagetitle,pv_source
  order by pv_siteid;


  1.4. “你举个例子说明为什么要写多个SELECT? 当然你如果要的是多个独立的输出,那当然要写多个SELECT.”

  我举个访客环境的例子,之前说到聚合记录时,按分辨率来统计,这样可以同时将访客统计出来,后来我仔细考证了下,貌似是不行的。
  得到的结果是

  分辨率     网站ID   PV    独立访客    IP数   访问次数
     这个是按照分辨率进行的统计,如果我按浏览器,按操作系统这样来统计,得到的PV,独立访客,IP数,访问次数都不会一样的。因此

  只能分开写Select了,没办法聚合到一条记录中实现,或者是在已聚合的数据记录基础上再聚合统计。

   
  这样的貌似只能分开select了不?如果这样分开,类似的分开统计还有几个,比如受访页面的统计,要按URL来统计一次,要按标题来统计,

  只能分开统计。同时多个select进行,很耗性能的吧,有什么可以提高性能的办法不?(我觉得这样是必须要分开统计的了)

你可以先聚合到最细的粒度,比如GROUP BY 分辨率,浏览器,操作系统
这样,当你只需要分辨率时,可以在此基础上再聚合。
这个前提是一个访客对应一组固定的分辨率,浏览器,操作系统。有这个前提则统计指标是可累加的。

如果不可累加,你只能够在不同粒度上设计不同的统计结果表来存放。



1.5. 同1.4,对这个访客环境进行分类统计的话,我是不是要建立多个中间表,比如分辨率的,操作系统的,浏览器的,这样分开统计后放到

各自对应的中间统计表中,而不是统一放到一张表中,哪种设计方式更好呢?

如果不可累加你就得分开不同的表来设计。


1.6. “即使你分开统计、分开保存,一个SELECT(一个视图)完全可以把它们整合到一起”  这个还不是很明白,视图不是把多个表连接在一起

时可以做个视图呢?

视图就是一个SQL嘛,你爱怎么JOIN都可以。


2、架构方案

  2.1. “是不是指单独一个库作为统计库,把每个分库的统计数据再汇总到这个库中,最后程序取数据展示只需要读取这个统计库的统计结果即可。而这个统计库跨库仅仅只是从多个分库中读取各自库中的统计数据汇总到一起,不进行任何别的操作,是这样的吗?

是的。

  问题: 那这个统计库要专门设置个JOB触发定时从其他分库中读取统计数据了是吧,但是如果分库中假设统计时间较长,或其它延时,而统计库的JOB是定时触发的,去统计但是统计数据还没到中间表,拿不到数据怎么办?

拿到的将是旧数据,有什么关系?下次就会刷新了。ORACLE保证你读到的是提交过的数据而且版本一致。


         如果统计库的JOB出现了问题,那不也就取不到数据了?
任何环节都可能出问题,你既然预料到了就得有监控机制。

         分库的各个JOB的时间是30分钟执行一次,那这个统计库的JOB设置时间多长时间触发一次好呢?
看需求,如果不要求实时,间隔越长越好。不过我猜想应该和子库的间隔一致,否则频繁计算子库没有意义。

         从分库取数据,再放到统计库中的统计表中,这个过程延时啊什么的影响大不?
子库的统计结果都不大的话,延迟没什么要紧的。你还是得做测试然后问是否满足业务需求。
  
  2.2. “不用STANDBY. 现在你只需要把统计结果汇总,用STREAM, 高级复制都可以。”

  是针对如果用读写分离这种思路,那就这样实现是吗?

不能算是读写分离,而是负载均分吧。

  
  2.3. “万一主库DOWN了看看业务上允许停机几分钟切换,那么不用RAC也可以。”  

  这个跟RAC的采用有什么关系吗,不是很懂
RAC保证一个节点失败了其他点还能工作,真正的高可用;STANDBY需要一个切换时间,中间至少有几分钟是不可用的。
如果你愿意做复杂点,前台应用在分库插入失败时,可以考虑先把数据插入到其他库,然后恢复后再倒回来。那么你的应用就会强壮些,也可不用RAC, 代价就是增加复杂度。
  
  2.4. “每个库各自有自己的备份。汇总和备份没关系。”

  由于每个库都只是部分数据,那自己有自己的备份后,要不要把这些分开的备份数据再统一备份到某一台备份服务器上呢?

不能。备份就是为了恢复,就是单独为那个库服务。

  
  2.5. “一个表不能放到多台服务器上。可以放到多个数据文件,不同数据文件可在不同盘上。”

  不是建表空间的时候或建表的时候就设置了对应的数据文件,怎么把表放到多个数据文件?这个怎么设置?
表空间可以对应多个数据文件,随时可以增加的。你的表只考虑让它呆在哪个表空间,不要操心哪个数据文件。
  
  而且我的基础表是分区了的,分区了也可以放多个数据文件上吗,怎么设置呢?
分区可以放在不同的表空间。

  不同的数据文件放不同的盘上,指的是同一台服务器上吧,如果是放多个服务器上呢?
是同一台服务器,不能在多台服务器。

  
  2.6.  不用RAC的架构的话,也可以使用共享存储不?共享存储的成本是不是很高,搭建的话比较复杂?(想尝试下,在测试环境)
可以,但是IO就成了瓶颈。
  
  不知道共享存储是为了起到一个什么作用,就是集中式架构吗?
可以被RAC的多个节点共享。



   
    现在开始优化基础PV表及整体修改时,回过头来,发现了些自己还没注意到的问题


1. “注意你的pd_pv1必须是高度规范化的,不该保存的冗余尽量去掉。”  

  这个你就提过了的,newkid。我的基础PV表里的字段数据(大多数就是从代码获取后插入表中,没有任何加工或者比较计算的原始数据),但是

  放了这样几个字段:

  搜索引擎编号、在搜索引擎表里(比如1-百度  2-谷歌  3-必应)

  搜索引擎名称、比如百度,谷歌

  浏览器编号、有张浏览器的表(里面比如IE-1 FireFox-2)
  
  浏览器名称、在浏览器表里(IE、FireFox)

  浏览器版本编号、在浏览器表里(具体的,比如1-IE6.0  2-IE7.0  3-IE8.0)

  操作系统编号、在操作系统表里(比如1-Windows 2-Linux)

  操作系统版本编号、在操作系统表里(比如1-WindowsXP 2-Windows2003 3-Windows7)

  地区编号  在地区表里(比如1-北京  2-上海  3-杭州  4-广州)

  
  问题:要不要放这些字段呢,还是就放最原始的数据,也就是你说的高度规范的?如果是最原始的数据,那么基础PV表放的搜索引擎就是域名

  浏览器就是个比如IE7.0,操作系统就是比如Windows7,就是这样的。


  说明:我自己开始放这些字段,是为了进行聚合统计的时候,有个编号,方便以后进行明细的查询,比较,有个ID比较更快捷一些,比字符串

        效率总要高。但是因为这两天才发现,如果加了这些编号,实际上前台代码进行数据插入时,由于是不知道这些字段的值的,需要先到

        数据库中对应的表中进行查询比较,然后得到上述这些字段的值(浏览器表,操作系统表,搜索引擎表,地区表这些表),最后再把得

        到的值放到基础PV表里,这样每一次插入数据就要查询几次其他表,感觉肯定影响效率的。本来每天基础数据是500W(分库后),这样

        插入数据那不是效率很低了?


2. 假设如果去掉这些字段了,那在之后的聚合统计时得到这些编号是不是会很麻烦呢,比如我按浏览器进行一个统计

    select pv_siteid as sid,
           pv_brw  as brw,  -- 浏览器
           count(*) as pv,
           count(distinct pv_visitid) as visits
    from pd_pv t1
    group pv_siteid, pv_brw


    这里得到的brw只是比如IE7.0  IE6.0  IE8.0这样的值,如果我要得到ID需要再查浏览器表得到,那怎么写呢?获得ID编号?

    浏览器表pd_brw  编号 pd_brwid(比如IE6.0-1 IE7.0-2 IE8.0-3)  父级浏览器编号  pd_pbrwid (比如IE-1  2-FireFox)

    每个浏览器编号都有一个对应的父级浏览器编号   

   
   
延伸:

2.1.  设了什么浏览器表,只是为了有个标明的浏览器编号,这样进行聚合统计时用ID来进行连接表啊,比较啊,查询啊会比较方便

      有没有必要要这个浏览器表呢,还是说聚合统计时就按IE7.0  IE6.0这样值来进行分组聚合,不必用什么ID编号

2.2.  搜索引擎是必须需要对应的搜索引擎编号的,也就是回到2中,像这样的要求,又要得到对应的ID编号,SQL怎么写呢(如同2中的聚合

      SQL,只是还要得到一个对应的ID编号)


3.  关于物化视图刷新

我仔细思考研究了下,好像所有的中间表都换成物化视图吧?(也就是不需要中间表,就用物化视图)

因为就是在基础表的基础上进行聚合统计,定时统计的

这样的话

问题:

1、 同时很多物化视图基于一个主表进行刷新,效率会低不,数据是有500W的每天,虽然物化视图也可以分区,是不是要对物化视图也分区?

2、 有的聚合统计是在物化视图上再刷新,那能不能一个物化视图在另一个物化视图基础上再刷新,在数据一更新后,就马上更新

    如果存在这样的依赖关系的物化视图,是不是要设置成on commit方式

3、 这么多视图同时刷新,是走快速刷新还是全部刷新呢?用什么策略刷新呢?快速刷新我怕MV LOG会过大

4、 由于我的数据是要一直存放的,那这个物化视图能不能像中间表一样可以一样存放数据(多长时间都行)?虽然物化视图就是一个物理表,

    而且不仅仅是一张物理表。

5、 对于从基础表中聚合统计数据到物化视图中,是要用查询重写吗?

6、 同时刷新很多物化视图,要用刷新组的不?效率与用多个存储过程进行统计,然后将数据统计到不同的中间表里  相比,效率是更高还是

    不相伯仲呢?



4.  我定时统计要触发JOB执行存储过程,是采用同时触发多个JOB并行执行,每个JOB执行个存储过程好呢还是用1个JOB触发,然后调用多个存储
    过程好呢?

使用道具 举报

回复
论坛徽章:
520
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
62#
发表于 2010-4-14 23:14 | 只看该作者
1. 原始数据必须保留;一般维度表的ID应该是在ETL的过程中生成的,你没有这个ETL过程,就在插入的时候生成。也就是说你即有ID又有名称,因为你的数据是没有经过ETL转换的。

使用道具 举报

回复
论坛徽章:
520
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
63#
发表于 2010-4-14 23:21 | 只看该作者
论坛有问题,我只能通过手机版访问,后面内容都被截掉了。

使用道具 举报

回复
论坛徽章:
407
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
64#
发表于 2010-4-14 23:26 | 只看该作者

回复 #63 newkid 的帖子

手机版有问题,计算机版挺好的

使用道具 举报

回复
论坛徽章:
520
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
65#
发表于 2010-4-15 00:09 | 只看该作者
凭运气发贴:

1. 原始数据必须保留;一般维度表的ID应该是在ETL的过程中生成的,你没有这个ETL过程,就在插入的时候生成。也就是说你即有ID又有名称,因为你的数据是没有经过ETL转换的。
   用INSERT...SELECT....其中SELECT的部分把维度表(浏览器,搜索引擎等)连接上去,用这些维度名称做连接键。

2. 如果你要利用浏览器表里面的其他字段做统计,就必须把浏览器表连接上去。

2.1 浏览器表还是必须的,你可能不仅仅按名称来聚合,比如按父浏览器类别来聚合。
2.2 见2的说明,是否连接上维度表根据你的查询需求来确定。

3.  关于物化视图刷新

1、 同时很多物化视图基于一个主表进行刷新,效率会低不,数据是有500W的每天,虽然物化视图也可以分区,是不是要对物化视图也分区?
这跟分区没有关系,如果你物化视图也很大才有必要刷新。


2、 有的聚合统计是在物化视图上再刷新,那能不能一个物化视图在另一个物化视图基础上再刷新,在数据一更新后,就马上更新

    如果存在这样的依赖关系的物化视图,是不是要设置成on commit方式

可以,你可以把第一层的物化视图看作第二层的基础表。如果你要求两层数据是同时生成的,则第二层做成on commit方式。


3、 这么多视图同时刷新,是走快速刷新还是全部刷新呢?用什么策略刷新呢?快速刷新我怕MV LOG会过大
确实LOG会很大。
而且我怀疑能否快速刷新,特别是那些有DISTINCT的。你先试试再说。
自己写表可以根据时间戳来增量统计。


4、 由于我的数据是要一直存放的,那这个物化视图能不能像中间表一样可以一样存放数据(多长时间都行)?虽然物化视图就是一个物理表,

    而且不仅仅是一张物理表。

可以一直保存。


5、 对于从基础表中聚合统计数据到物化视图中,是要用查询重写吗?
不是,查询重写是指你在基础表上运行带聚合的SQL, ORACLE会自动改写为从物化视图查询。

6、 同时刷新很多物化视图,要用刷新组的不?效率与用多个存储过程进行统计,然后将数据统计到不同的中间表里  相比,效率是更高还是

    不相伯仲呢?

刷新组可以保证数据在同一个事务里,即版本一致。至于和存储过程比较,你得做试验,我怀疑其中有些是无法快速刷新的。


4.  我定时统计要触发JOB执行存储过程,是采用同时触发多个JOB并行执行,每个JOB执行个存储过程好呢还是用1个JOB触发,然后调用多个存储
    过程好呢?

如果你有先后依赖关系,就用一个JOB顺序执行多个过程;多个JOB并行执行效率高,前提是你有足够资源,不会发生统计的时候前台无法插入数据。

使用道具 举报

回复
论坛徽章:
11
2010新春纪念徽章
日期:2010-03-01 11:19:072014年新春福章
日期:2014-02-18 16:42:02优秀写手
日期:2014-02-09 06:00:122011新春纪念徽章
日期:2011-02-18 11:43:34数据库板块每日发贴之星
日期:2010-12-22 01:01:01数据库板块每日发贴之星
日期:2010-11-26 01:01:012010广州亚运会纪念徽章:拳击
日期:2010-11-22 15:26:49ITPUB9周年纪念徽章
日期:2010-10-08 09:28:51数据库板块每日发贴之星
日期:2010-07-10 01:01:04数据库板块每日发贴之星
日期:2010-07-07 01:01:01
66#
 楼主| 发表于 2010-4-15 18:03 | 只看该作者
原帖由 newkid 于 2010-4-15 00:09 发表
凭运气发贴:

1. 原始数据必须保留;一般维度表的ID应该是在ETL的过程中生成的,你没有这个ETL过程,就在插入的时候生成。也就是说你即有ID又有名称,因为你的数据是没有经过ETL转换的。
   用INSERT...SELECT....其中SELECT的部分把维度表(浏览器,搜索引擎等)连接上去,用这些维度名称做连接键。

2. 如果你要利用浏览器表里面的其他字段做统计,就必须把浏览器表连接上去。

2.1 浏览器表还是必须的,你可能不仅仅按名称来聚合,比如按父浏览器类别来聚合。
2.2 见2的说明,是否连接上维度表根据你的查询需求来确定。

3.  关于物化视图刷新

1、 同时很多物化视图基于一个主表进行刷新,效率会低不,数据是有500W的每天,虽然物化视图也可以分区,是不是要对物化视图也分区?
这跟分区没有关系,如果你物化视图也很大才有必要刷新。


2、 有的聚合统计是在物化视图上再刷新,那能不能一个物化视图在另一个物化视图基础上再刷新,在数据一更新后,就马上更新

    如果存在这样的依赖关系的物化视图,是不是要设置成on commit方式

可以,你可以把第一层的物化视图看作第二层的基础表。如果你要求两层数据是同时生成的,则第二层做成on commit方式。


3、 这么多视图同时刷新,是走快速刷新还是全部刷新呢?用什么策略刷新呢?快速刷新我怕MV LOG会过大
确实LOG会很大。
而且我怀疑能否快速刷新,特别是那些有DISTINCT的。你先试试再说。
自己写表可以根据时间戳来增量统计。


4、 由于我的数据是要一直存放的,那这个物化视图能不能像中间表一样可以一样存放数据(多长时间都行)?虽然物化视图就是一个物理表,

    而且不仅仅是一张物理表。

可以一直保存。


5、 对于从基础表中聚合统计数据到物化视图中,是要用查询重写吗?
不是,查询重写是指你在基础表上运行带聚合的SQL, ORACLE会自动改写为从物化视图查询。

6、 同时刷新很多物化视图,要用刷新组的不?效率与用多个存储过程进行统计,然后将数据统计到不同的中间表里  相比,效率是更高还是

    不相伯仲呢?

刷新组可以保证数据在同一个事务里,即版本一致。至于和存储过程比较,你得做试验,我怀疑其中有些是无法快速刷新的。


4.  我定时统计要触发JOB执行存储过程,是采用同时触发多个JOB并行执行,每个JOB执行个存储过程好呢还是用1个JOB触发,然后调用多个存储
    过程好呢?

如果你有先后依赖关系,就用一个JOB顺序执行多个过程;多个JOB并行执行效率高,前提是你有足够资源,不会发生统计的时候前台无法插入数据。



newkid,你的意见是还是在插入基础PV表的时候,就把浏览器ID,搜索引擎ID,搜索引擎名称这样的值查询出来然后在放到基础表中不?

比如

insert into pd_pv(se_id,se_name)  由于只知道搜索引擎的域名比如www.baidu.com,那么要知道se_id,se_name要到数据库中去查询搜索引擎表得到se_id,se_name然后再插入

基础PV表,pd_pv中不。

这样弄的话,插入语句怎么写呢?目前我的插入语句是

create or replace procedure proc_pv_insert(m_id          number, --自增ID
                                           m_siteid      number, --网站ID
                                           m_visitorid   varchar2, --访客ID
                                           m_visitid     varchar2, --访问ID
                                           m_visitnum    number, --第几次访问
                                           m_referdomain varchar2, --来路域名
                                           m_referurl    varchar2, --来路页面
                                           m_pagedomain  varchar2, --受访域名
                                           m_pageurl     varchar2, --受访页面
                                           m_pagetitle   varchar2, --页面标题
                                           m_visittime   date, --访问时间
                                           m_interval    number, --访问时长
                                           m_uniquepv    number, --唯一浏览量
                                           m_prevpage    varchar2, --上一页
                                           m_nextpage    varchar2, --下一页
                                           m_enterflag   number, --进入标记
                                           m_jumpflag    number, --跳出标记
                                           m_exitflag    number, --退出标记
                                           m_source      number, --来路分类
                                           m_iscost      number, --付费流量标记
                                           m_seid        number, --搜索引擎ID
                                           m_se          varchar2, --搜索引擎名
                                           m_keyword     varchar2, --关键字
                                           m_isnew       number, --新访客标记
                                           m_ip          number, --IP地址
                                           m_isp         number, --网络接入商
                                           m_areaid      number, --地区ID
                                           m_brwpid      number, --浏览器ID
                                           m_brwpname    varchar2, --浏览器名
                                           m_brwid       number, --浏览器版本ID
                                           m_brw         varchar2, --浏览器版本名
                                           m_ospid       number, --操作系统ID
                                           m_ospname     varchar2, --操作系统名
                                           m_osid        number, --操作系统版本ID
                                           m_os          varchar2, --操作系统版本名
                                           m_pixel       varchar2, --分辨率
                                           m_lang        varchar2, --语言
                                           m_java        number, --是否支持Java
                                           m_flash       number, --是否支持Flash
                                           m_client      number, --终端类型
                                           m_createtime  date, --创建时间
                                           m_delflag     number, --删除标记
                                           m_verflag     number --版本标记
                                           ) is
begin
  insert into pd_pv
    (pv_id,
     pv_siteid,
     pv_visitorid,
     pv_visitid,
     pv_visitnum,
     pv_referdomain,
     pv_referurl,
     pv_pagedomain,
     pv_pageurl,
     pv_pagetitle,
     pv_visittime,
     pv_interval,
     pv_uniquepv,
     pv_prevpage,
     pv_nextpage,
     pv_enterflag,
     pv_jumpflag,
     pv_exitflag,
     pv_source,
     pv_iscost,
     pv_seid,
     pv_se,
     pv_keyword,
     pv_isnew,
     pv_ip,
     pv_isp,
     pv_areaid,
     pv_brwpid,
     pv_brwpname,

     pv_brwid,
     pv_brw,
     pv_ospid,
     pv_ospname,
     pv_osid,
     pv_os,

     pv_pixel,
     pv_lang,
     pv_java,
     pv_flash,
     pv_client,
     pv_createtime,
     pv_delflag,
     pv_verflag)
  values
    (m_id,
     m_siteid,
     m_visitorid,
     m_visitid,
     m_visitnum,
     m_referdomain,
     m_referurl,
     m_pagedomain,
     m_pageurl,
     m_pagetitle,
     m_visittime,
     m_interval,
     m_uniquepv,
     m_prevpage,
     m_nextpage,
     m_enterflag,
     m_jumpflag,
     m_exitflag,
     m_source,
     m_iscost,
     m_seid,
     m_se,
     m_keyword,
     m_isnew,
     m_ip,
     m_isp,
     m_areaid,
     m_brwpid,
     m_brwpname,
     m_brwid,
     m_brw,
     m_ospid,
     m_ospname,
     m_osid,
     m_os,
     m_pixel,
     m_lang,
     m_java,
     m_flash,
     m_client,
     m_createtime,
     m_delflag,
     m_verflag);
  commit;
end;

我打红色的就是要查别的表才能知道的值,这怎么改呢?

2.  关于IP地址的存放,是存放成192.168.18.1 这样字符串型的,还是经过转化,成为一个数字,存放为数字呢?因为数字好比较

   IP地址的存放形式哪样比较好呢?效率上    我用SQL写了个IP地址转换数字的函数

3.  物化视图的实验和存储过程的效率比较我还在做

使用道具 举报

回复
论坛徽章:
520
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
67#
发表于 2010-4-15 22:46 | 只看该作者
1. 不是告诉你了吗,用INSERT...SELECT

比如你有一个表叫 ALL_SE, 里面有 SEID 和 SE
又有一个表叫 ALL_BRW, 里面有BRWID 和 BRW

insert into pd_pv (pv_seid,pv_se,pv_brwid, pv_brw, XXXX 其他列)
SELECT seid,m_se,brwid,m_brw,m_XXXX 其他列
   FROM ALL_SE,ALL_BRW
WHERE ALL_SE.SE = m_se
            AND ALL_BRW.BRW = m_brw;

这是简化的例子,其他列你自己加上去。

前提是按名称可以在这些维度表中找到唯一一条记录。维度表中名称必须有唯一索引。
假设有可能在维度表中不存在,那么你用一个DUAL 表外连接所有的维度表。

使用道具 举报

回复
论坛徽章:
0
68#
发表于 2013-3-10 18:36 | 只看该作者
本帖最后由 xiangshifu 于 2013-3-10 18:37 编辑

这个帖子很老了, 不过技术很有挑战性, 难度最大的是很难做到实时统计。 我自己也谈谈如何确定处理思路。

项目分析:
1, 这个项目需要对很多网站做实时统计分析
2, 特征点:并不是所有的网站创建人都会实时登陆这个系统查看各项指标, 应该只是一小部分活跃客户才有经常登陆,  我们只要满足这部分创建者的实时统计要去即可
3, 大部分情况下, 实时性要求并不是很高, 延后5-10分钟应该是可以接受的。


实施策略:
基于以上的分析, 我们把网站分析分为3个级别:
1, 高实时统计。 这类用户基本上就是当前登录网站创建者, 数据刷新频度控制在5分钟以内。 若用户刚登录进来,需要立即在后台执行最常见的统计分析。
2, 准实时统计。 这类用基本上是近期活跃用户, 每个1个小时执行一次分析
3, 高延时统计。 所有的用户, 每天执行统计即可。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表