[转帖]Data warehouse和OLTP系统的对比_MQ, Tuxedo及OLTP讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MQ, Tuxedo及OLTP讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4555 | 回复: 0   主题: [转帖]Data warehouse和OLTP系统的对比        下一篇 
ilikeorcl
注册用户
等级:中尉
经验:431
发帖:32
精华:1
注册:2012-12-17
状态:离线
发送短消息息给ilikeorcl 加好友    发送短消息息给ilikeorcl 发消息
发表于: IP:您无权察看 2012-12-21 11:31:01 | [全部帖] [楼主帖] 楼主

Data warehouse和OLTP系统的对比

OLTP系统不同,数据仓库的主要目的是集中统一的存放业务的历史数据,以便用于查询和分析。

数据仓库理论的鼻祖William Inmon给数据仓库的特性归纳为一下四点:

    面向主题(Subject Oriented)
    集成(Inegrated)
    不可修改(Nonvolatile)
    时间相关(Time Variant)

数据仓库和OLTP是基于不同的需求而得出的解决方案。下面是数据仓库和OLTP系统的一些主要方面的对比:

1.负载
数据仓库主要设计为适合即席查询(Ad hoc query),我们无法预先知道数据仓库的负荷,所以,数据仓库需要设计为能够适应各种可能的查询
OLTP系统一般执行的操作是可以预先确定的,可以按照估计出的系统负荷来设计OLTP系统.

2.数据修改
数据仓库一般是通过ETL,周期性的将新的数据批量装载。数据进入数据仓库后,一般是不可修改的,所以数据仓库当中一般会建较多的索引用于优化查询。而OLTP系统,终端用户可以修改其对应的某些数据,所有OLTP系统一般即时体现着当前最新的数据。

3.架构设计
数据仓库一般采用非规范化或者部分非规范化的设计,以优化查询性能,典型的设计如星型模型和雪花模型。因为非规范化设计,可以只需要join较少的表就得到更多的数据。而OLTP系统一般采用规范化的设计,以避免出现update/insert/delete异常,并保证数据的一致性。

4.典型操作
数据仓库中,一条查询可能需要访问上千,甚至几百万行数据,所以查询的性能相当重要。在oracle中,dimensionmaterialized viewbitmap index等技术,都在数据仓库中大量使用以优化查询性能。OLTP中,一个操作一般只需要访问有限的几条数据。

5.历史数据
数据仓库中需要大量的历史数据,以便从历史数据中分析所需要的信息OLTP系统则一般会将历史数据删除,以保证当前事务处理的性能。

二.数据仓库建模

目前来说,数据仓库的数据存储载体还是关系数据库。对于数据仓库的建模,自然也要遵循关系数据库的一般设计准则。从数据仓库诞生以来,主要有两种建模方式。一种是Inmon推荐的关系模型,遵循规范化理论。另外一种是kimpall提出的多维模型,这是目前项目实践中的主流建模方式。多维模型中,最基本用的最多的就是星型模型(star schema)

Star schema主要的思想在于将我们关心的数据和用于描述数据的属性分隔开来。实际的数据存放于Fact table中,从不同角度来描述数据的属性放到不同的dimension table中。比如,一个sales数据仓库可以这样设计,每一笔销售记录,应该会包含销售的产品,销售的客户,销售的供货商,销售的时间,销售的数量和获得的收入等。当我们要分析整个公司的所有销售记录时,毫无疑问,我们最关心的是一共销售了多少?

一共获得了多少收入?然后更进一步,在某个时间段内销售了多少?来自哪家供货商的产品的销售额最大?面向哪种客户的销售额最大?哪种产品的销售额最大?等等。

从上面我们关心的这些问题我们可以看到,对于销售的数量和金额这类具体的数字型的数据,通常是我们分析的对象,而对于像时间,产品,客户,供货商,我们希望从这些不同的角度来得到数字型数据的一个统计结果。所以,我们将数字型的数据存放在fact table中,将时间,产品,客户,供货商存放在不同的dimension table中,自然,在fact tabledimension table之间存在一个主-外键的关联,各个dimension table之间则没有关系。由此我们可以得到如下的一个star schema:


star schema之所以叫star schema,就是由于上面这个图形的形状来的,fact table处于中间的位置,dimension table围成一圈,每个dimension tablefact table关联。Fact table中除了区分每条记录的主键(fact table的主键很有可能是所有dimension table的外键组合起来的一个组合主键),连接每个dimension table的外键外,就只有我们关心的数字型数据,所以fact table中的每条记录,有个专门的术语称之为度量(measurement),因为我们利用数据仓库做统计分析的时候,这些数据就是统计分析的一个个基本单位,也就是度量值。

显然,star schema是反规范化的。如果将dimension table按照规范化拆开,则star schema演化成了雪花模型(snowflake schema).规范化减少了数据的冗余,但是由于查询的时候要连接更多的表,性能就会受到影响。由于数据仓库主要用于查询的特性,除非你有非常特别的原因,一般推荐此采用star schema来进行数据仓库的架构设计。

三.RELY constraint

数据仓库中的数据,一般是通过ETL定期load进来的。在做ETL的时候,一般会对load的数据的一致性做检查。所以,我们有理由认为,数据仓库中的数据都是符合一致性要求的。

既然我们已经可以确定数据仓库中的数据是一致的,那么就可以不在表上建constraintconstraintDML或者load操作是有性能影响的,能不用当然不用的好。但是,虽然表中的数据实际上一致了,oracle自己却不知道,优化器也不知道。在利用物化视图查询重写(query rewrite)时,constraintdimension的作用是很大的(一般在数据仓库环境中,query_rewrite_integrity参数设置为trusted),查询重写对数据仓库的性能影响相当大。

为了告诉oracle,数据应该符合某种一致性条件了,而又不想创建的constraint其作用,就可以创建类型为RELYconstraint,也就是一种可以让oracle知道这些数据是符合这些约束的,但这个约束本身却是没有其实际作用的约束。

文档中给出了一个例子:

ALTER TABLE sales ADD CONSTRAINT sales_time_fk
FOREIGN KEY (time_id) REFERENCES times (time_id)
RELY DISABLE NOVALIDATE;


另外,视图只能创建RELY constraint,不能创建普通的constraint。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论