数据仓库中如何使用索引

数据仓库的索引是个棘手的问题。如果索引太多,数据插入很快但是查询响应就会很慢。如果太多索引,数据导入就很慢并且数据存储空间更大,但是查询响应更快。数据库中索引的作用就是加快查询速度,不论是传统数据库还是数据仓库。尤其是对于大数据量的表以及设计边连接的复杂查询。之前接触数据仓库比较少,这里只是介绍一点小的经验。

当然,在创建数据仓库索引的时候需要考虑一些参数比如数据仓库类型、维度表和事实表大小、是否分区、是否AD hoc等等。这些参数决定了你的索引结构。本篇主要介绍如何对数据仓库中的关系表建立索引,注意是在关系数据库中的关系表,而不是SSAS中的数据表。

维度索引

如果打算在维度表的主键上建立索引,而该键是一个代理键,不是一个自然或者业务键(例如用户名称或者ID)。注意不要在维度表的代理键或者变现渐变的列上建立聚集索引

维度表包含一个自然或者业务键(例如交易编码或者ID),我们称之为业务键,这些事来自业务系统地。尽管业务键可能不是唯一的,但是对于缓慢渐变的维度表而言,在标示列上建立索引是比较好的(如用户ID等),如下图:

用户和产品的维度表中聚集索引建立在业务键上,通过这样的索引,能强化查询速度尤其是where语句中使用了这些键的。通常where 表达式中经常会使用这个键值来查询维度数据。

通过业务键建立聚集索引可以避免锁升级(例如,行锁到表锁,意图排它到排它),因为在ETL过程中如果代理键上有非聚集索引并且所有的行都被添加到文件末尾就有可能发生锁升级,如果排它锁从行锁升级到表锁,那么就会引起其他读取或者ETL或者通用操作的阻塞甚至死锁,最终程序timeout。

在上图中,Date维度和Time维度有没外部的数据源或者业务键。考虑使用YYYYMMDD 和HHMMSSSSS 格式作为两个表的主键,并建立聚集索引。这个值保证了索引顺序,在事实表中也简化了查询范围,并且这个键值也包含了日期或者时间,不再需要具体时间。

对于大型的缓慢渐变维度表(例如这里需要键入新的数据),或许可以创建一个由四部分组成的非聚集索引包括业务键、记录开始时间、记录结束时间和代理键。为了效率并且阻止存储增大,使用Include来包含记录结束时间和代理键,如下所示:

                              CREATE NONCLUSTERED INDEX MyDim_CoveringIndex  ON (NaturalKEY, RecordStartDate)                             

                              INCLUDE ( RecordEndDate, SurrogateKEY);

这个索引在ETL的过程中对于历史数据的查询和操作是很有效的,通过非聚集索引减少列从而减少了没必要的存储空间。关系数据库引擎能直接从索引获取数据而不需要直接访问维度数据,减少了IO提高了查询速度。

如果在维度表中有其他用于查询、排序、分组的列,也可以创建非聚集索引,就如同你在事务性数据库中一样。如果在维度表中有一个嵌入层级,例如类-子类-产品ID的层级关系在产品维度表中,考虑在层次结构的键值上建立索引,会显著提高数据查询并且不会影响数据导入。

在事实表上建立索引

与在维度表建索引相似,当然需要考虑分区等条件。可以在日期列或者混合日期+时间的列上建立聚集索引。因为BI分析总是会使用日期/时间组件,事实表包含date或者datetime列,并且这里使用聚集索引会帮助构建cube。也因为这个原因,数据记录也是按照date或者datetime的顺序存储。对于历史的查询是有其优势的。如果事实表有多个这样的列,那就需要在查询或者构建cube最为频繁的列上建立索引。

如果在date列上分区,可以使用聚集索引在该列上。当发现用来创建分区和聚集索引在同一列上并且在保存分区事实表的文件组上创建了索引,那么SQLServer 将自动用事实表分区来分区索引(例如,索引会有和事实表相同的的分区函数和列)。当索引按照事实表分区后,这个表和他的索引自动对齐,尤其当你创建分区或者频繁切换分区开关时,这样就方便的多了。

下一步,创建非聚集索引在每个事实表的外键上,并且考虑混合外键和日期键,如图1所示可以见建立类似用CustomerKEY + DateKEY 的索引。使用相同的外键值查询将带有时间排序,这回提高查询速度。注意,处理外键时要考虑保持关系完整性。

改善索引架构

随着时间变化,数据仓库会发生改变来适应组织结构的变化,并且必须要改变索引结构。大多数数据仓库或者BI系统是直接连接关系表的,因此可以使用经过关系表调优的业务方法,例如评估查询和数据混合来相应的调整索引。如果关系数据仓库只用来表现SSAS结构,那么可能不需要我们之前讨论的索引。SSAS更倾向于反复使用相同的查询,因此可以使用索引优化向导或者对查询进行精确调优。开始单纯严禁彻底的评估以便在数据仓库中建立索引。

总结

本篇只是简单介绍了一般数据仓库的关系数据表如何建立索引,但是很多时候要根据实际请款来建立索引,甚至有时候不能使用索引。兼顾消耗和时间效率等多个方面,还是要不断通过生产环境的要求来变化的。

时间: 2024-10-16 17:42:43

数据仓库中如何使用索引的相关文章

深入浅出数据仓库中SQL性能优化之Hive篇

转自:http://www.csdn.net/article/2015-01-13/2823530 一个Hive查询生成多个Map Reduce Job,一个Map Reduce Job又有Map,Reduce,Spill,Shuffle,Sort等多个阶段,所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR Job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另

数据仓库中的 SQL 性能优化(Hive篇)

一个Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另外要说明的是,这个优化只是针对Hive 0.9版本,而不是后来Hortonwork发起Stinger

数据仓库中的几种模型

数据仓库中常见的模型有:范式建模,雪花模型,星型建模,事实星座模型. 星型模型 星型模型是数据集市维度建模中推荐的建模方法.星型模型是以事实表为中心,所有的维度表直接连接在事实表上,像星星一样.星型模型的特点是数据组织直观,执行效率高.因为在数据集市的建设过程中,数据经过了预处理,比如按照维度进行了汇总,排序等等,数据量减少,执行的效率就比较高. 雪花模型 雪花模型也是维度建模中的一种选择.雪花模型的维度表可以拥有其他维度表的,虽然这种模型相比星型模型更规范一些,但是由于这种模型不太容易理解,维

SQLSERVER中如何忽略索引提示

原文:SQLSERVER中如何忽略索引提示 SQLSERVER中如何忽略索引提示 当我们想让某条查询语句利用某个索引的时候,我们一般会在查询语句里加索引提示,就像这样 SELECT id,name from TB with (index(IX_xttrace_bal)) where bal<100 当在生产环境里面,由于这个索引提示的原因,优化器一般不会再去考虑其他的索引,那有时候这个索引提示可能会导致查询变慢 经过你的测试,发现确实是因为这个索引提示的关系导致查询变慢,但是SQL服务器已经缓存

统计elasticsearch中月每天索引量的脚本

随着业务量的不断上升,最近一段时间需要对生产环境中的elasticsearch集群中的历史索引数据做迁移,而在做迁移前需要对被迁移的elasticsearch索引数据做统计用于迁移后的验证统计,所以就写了一个脚本用于es数据中查询历史索引的量生成报表文件,而在其中有使用过jq工具用于取数,jq的介绍可以查看http://jim123.blog.51cto.com/4763600/1966964: #!/bin/bash #es_count_report.sh #used for elastics

MySQL中B+树索引的使用

1)         不同应用中B+树索引的使用 对于OLTP应用,由于数据量获取可能是其中一小部分,建立B+树索引是有异议时的 对OLAP应用,情况比较复杂,因为索引的添加应该是宏观的而不是微观的. 2)         联合索引 对表上多个列进行索引.联合索引的创建方法与多个索引创建的方法一样.不同之处在于有多个索引页 CREATE TABLE t( a INT, b INT, PRIMARY KEY(a), KEY idx_a_b(a,b) )ENGINE=INNODB 从本质上来说,联合

0103MySQL中的B-tree索引 USINGWHERE和USING INDEX同时出现

转自博客http://www.amogoo.com/article/4 前提1,为了与时俱进,文中数据库环境为MySQL5.6版本2,为了通用,更为了避免造数据的痛苦,文中所涉及表.数据,均来自于MySQL官网提供的示例库employees,可通过 https://launchpad.net/test-db/employees-db-1/1.0.6 自行下载. 基本概念Binary search(二分查找法,折半查找法):是一种在有序数组中查找某一特定元素的搜索算法.搜素过程从数组的中间元素开始

37. SQL -- 页分裂如何解决,在查询中强制使用索引

页分裂: 创建聚集索引时,表格内的数据会按照索引的顺序存储在数据库的数据页面中,当新的数据行插入到数据表中,或更新表中的数据时,SQLServer 必须刷新数据在数据库中的存储位置,这样,就导致索引页中的数据存储方式改变,当页中数据已满的情况下,就将会创建一个新页,并将原有页中的一半数据放入新页中,以挪出空间给新的记录行使用.注:当页分裂的次数较多时,会影响效率. 导致页分裂原因: 当一个数据页达到了8K容量,如果此时发生插入或更新数据的操作,将导致页的分裂(又名页拆分): 有聚集索引的情况下:

数据仓库中数据粒度

粒度问题是设计数据仓库的一个最重要方面.粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别.细化程度越高,粒度级就越小:相反,细化程度越低,粒度级就越大.确定粒度是数据仓库开发者需要面对的一个重要的设计问题.如果数据仓库的粒度确定合理,设计和实现中的其余方面就可以非常顺畅地进行:反之,如果粒度确定的不合理就会是其他所有方面都很难进行.粒度对于数据仓库体系结构设计人员来说,非常重要,因为粒度会影响到那些依赖于从中获取数据的数据仓库的所有环境. 粒度的主要问题是使其处于一个合适的级别,粒度的