DB2 10.5列式表存储技术
DB2 10.5引入列式存储表技术，做为DW数据应用的特性，对性能具备很大的提高，同时对SQL基本不作索引优化，查询时直接能够按照列存储格式查询相关列便可，能够说管理很简单了。做为一个新特性，DB2 LUW V10.5的列式组织表功能依然做为一个可选择功能项，用户能够按照本身数据库业务的特色，选择是否启用该功能，对于升级到DB2 LUW V10.5的数据库环境来讲，须要通过一样的参数配置，也能够支持这个功能。数据库
在建立数据库前，在DB2 V10.5实例提供了注册变量选项值，即DB2_WORK_LOAD新增可配置值ANALYTICS，配置改参数值后，DB2会为新建立的分析性工做负载数据库创建最佳缺省配置，启用改参数后，数据库会自动配置以下参数，也是支持和影响列式存储环境的几个关键参数：缓存
dft_table_org该参数指定建立表的默认类型，一般设定为row,启用ANALYTICS注册变量值后，系统会自动配置为columnide
dft_degree 指定分区内SQL语句的并行度，该参数会被自动配置为any工具
dft_extent_sz 缺省表空间的扩张块大小，该参数会自动被设置为4（默认值为32）性能
catalogcache_sz 即目录高速缓存，该参数会被自动设置为比一般数据库类型的默认值更大的值测试
util_heap_sz 即实用程序堆大小，该参数会被自动配置为一个用于装载列组织表时所需额外内存的大小优化
auto_reorg 即自动重组操做，该参数会被配置为onspa
sortheap（排序堆）和sheapthres_shr须要根据实际计算配置对象
固然，若是在已经建立好的数据库库后才对DB2_WORK_LOAD注册变量参数配置analytics，当数据库运行autoconfigure也具备相同效果排序
建立列组织表
那么如何建立DB2列组织表呢？其实建立列组织表和建立普通行式组织表的语句大致相同，只是列式组织表在creat table后添加了ORGANIZE BY COLUMN的语句。固然若是你当前的数据库级的配置参数dft_table_org设置为column的话，也能够不使用organize by column语句选项，由于在启用该参数值的数据库中，建立的表默认就是列组织表类型，以下是一个建立列组织表的示例DDL：
CREATE TABLE "DB2INST1"."EMPLOYEE" (
"EMPNO" CHAR(6 OCTETS) NOT NULL ,
"FIRSTNME" VARCHAR(12 OCTETS) NOT NULL ,
"MIDINIT" CHAR(1 OCTETS) ,
"LASTNAME" VARCHAR(15 OCTETS) NOT NULL ,
"WORKDEPT" CHAR(3 OCTETS) ,
"PHONENO" CHAR(4 OCTETS) ,
"HIREDATE" DATE ,
"JOB" CHAR(8 OCTETS) ,
"EDLEVEL" SMALLINT NOT NULL ,
"SEX" CHAR(1 OCTETS) ,
"BIRTHDATE" DATE ,
"SALARY" DECIMAL(9,2) ,
"BONUS" DECIMAL(9,2) ,
"COMM" DECIMAL(9,2) )
IN "USERSPACE1"
ORGANIZE BY COLUMN;
行组织表与列组织表的转换
那么对于建立时没有指定列式组织或者由低版本升级的数据库中的行式组织表，如何将其转换成列式组织表呢？DB2 V10.5充分考虑了用户需求，提供了一个新的实用程序工具db2convert，用于将行式组织表转换为列式组织表，以下依然以db2inst2.employee表为例，将其转换为列式组织表，获取到的原始表的DDL语句以下：
CREATE TABLE"DB2INST2"."EMPLOYEE" (
"EMPNO" CHAR(6 OCTETS) NOT NULL ,
"FIRSTNME" VARCHAR(12 OCTETS) NOT NULL ,
"MIDINIT" CHAR(1 OCTETS) ,
"LASTNAME" VARCHAR(15 OCTETS) NOT NULL ,
"WORKDEPT" CHAR(3 OCTETS) ,
"PHONENO" CHAR(4 OCTETS) ,
"HIREDATE" DATE ,
"JOB" CHAR(8 OCTETS) ,
"EDLEVEL" SMALLINT NOT NULL ,
"SEX" CHAR(1 OCTETS) ,
"BIRTHDATE" DATE ,
"SALARY" DECIMAL(9,2) ,
"BONUS" DECIMAL(9,2) ,
"COMM" DECIMAL(9,2) )
IN "USERSPACE1"
ORGANIZE BY ROW;
为了便于观察过程，咱们最好为其导入数据，有必定的数据量，以便于观察转换过程，此测试数据来源都是DB2示例数据库sample中相关表中获取的，在此就很少讲，读者能够本身自行测试效果。
如此，咱们就能够对其进行转换，其实db2convert工具的用法相对简单，能够进行整库转换，也能够指定单表，须要提供表的schema和tablename，具体用法能够参阅相关使用说明：
[db2inst1@dblab test]$ db2convert -d sample -z db2inst2 -t employee
Proceeding with the conversion...
Table RowsNum RowsComm Status Progress (%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 UNSTARTED 0.00
Table RowsNum RowsComm Status Progress (%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 UNSTARTED 0.00 Table RowsNum RowsComm Status Progress (%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 INIT 0.00 Table RowsNum RowsComm Status Progress (%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 INIT 100.00 Table RowsNum RowsComm Status Progress (%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 INIT 100.00 Table RowsNum RowsComm Status Progress(%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 COPY 0.00 Table RowsNum RowsComm Status Progress(%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 COPY 0.00 Table RowsNum RowsComm Status Progress(%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 COPY 0.00
Table RowsNum RowsComm Status Progress(%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 COPY 100.00
Table RowsNum RowsComm Status Progress(%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0 COPY 100.00 Table RowsNum RowsComm Status Progress (%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 0 0 REPLAY 100.00
Table RowsNum RowsComm Status Progress (%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 0 0 REPLAY 100.00
Table RowsNum RowsComm Status Progress(%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 0 0 SWAP 0.00
Table RowsNum RowsComm Status Progress(%)
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 0 0 SWAP 100.00
Final Summary:
Table RowsNum InitSize(MB) FinalSize (MB) CompRate (%) State
--------------------------------------- --------------- ---------------
"DB2INST2"."EMPLOYEE" 42 0.50 10.25 -1950.00 Completed
Pre-Conversion Size (MB): 0.50
Post-Conversion Size (MB): 10.25
Compression Rate (Percent): -1950.00
SQL2446I The db2convert command completed successfully. Allrow-organized tables that satisfy the specified matching criteria have beenconverted to column-organized tables.
能够看到db2convert整个过程实际上是基于admin_move_table的原理实现,整个过程也是对表在线作的类型转换。另外注意的是，范围分区表，MDC表和ITC表默认是不能被转换成列式组织表的，须要在上面的命令中使用-force选项才能够执行该命令进行转换。在转换前表存在的依赖对象最好可以删掉，外键约束会影响转换的时间，最重要的一点就是表的类型转换操做在线是不可逆的，因此建议最好在转换成列式组织表前对相关表或者对转换库作完整的备份。
db2convert -d sample
能够将数据库sample中全部的行式组织表转换成列式组织表。
重组列式组织表
在平常维护和使用列式组织表也须要按期对数据量增删操做比较频繁的表进行重组，以便于提升运程序的查询的执行性能，固然若是启用了auto_reorg参数，数据库会自动对相关列组织表进行重组操做，若是手动重组列组织表只须要在reorg table命令后面加上RECLAIM EXTENTS选项便可，以下演示了列式表的重组操做：
[db2inst1@dblab test]$ db2 reorgtable db2inst2.employee RECLAIM EXTENTS
DB20000I The REORG command completedsuccessfully.
若是不加该选项的手动重组的话，对于列式组织表的重组会有以下报错信息：
[db2inst1@dblab test]$ db2 reorgtable db2inst2.employee
SQL2216N SQL error "-1667"occurred while reorganizing a database table or its indexes.
解释执行计划
列式组织表的统计信息收集方法与普通的行式组织表相同，在此就不介绍。对于列式组织表的访问，经过以下的示例SQL，能够看到执行计划也会发生相应：
示例SQL：
SELECT
EMPNO,
ACTNO,
CHAR(EMSTDATE, USA),
CHAR(EMENDATE, USA)
FROM
DB2inst1.EMPPROJACT
WHERE
EMPNO IN
(SELECT
EMPNO
FROM
db2inst1.EMPLOYEE
WHERE
WORKDEPT='E11'
)
新的 CTQ 计划运算符表示列组织数据处理与行组织数据处理之间的转变，捕获列组织表说明信息的步骤与用于针对行组织表运行性能查询的步骤相同。
db2 set current explain mode explain
执行测试SQL语句
db2exfmt -d sample -1 -o output.exfmt
获取的执行计划信息以下：
Access Plan:
-----------
Total Cost: 71.9656
Query Degree: 1
Rows
RETURN
( 1)
Cost
I/O
|
12.1667
CTQ
( 2)
71.9656
10.5689
|
12.1667
HSJOIN
( 3)
71.9606
10.5689
/-------+-------\
73 7
TBSCAN TBSCAN
( 4) ( 5)
40.1348 31.8243
5.89474 4.67416
| |
73 42
CO-TABLE: DB2INST1 CO-TABLE:DB2INST1
EMPPROJACT EMPLOYEE
Q2 Q1
能够看到,对列式组织表访问多了一个叫CTQ的访问计划，表示将数据从按行组织的数据处理传递至按列组织的数据处理的按列组织的表队列。而且从CO-TABLE信息能够断定，两表均为列组织表，以上是一个简单的执行计划，固然实际应用SQL比较复杂，可是经过这些信息仍是能够判断的，在此就不作详细的案例分析。
- 1. DB2 10.5 BLU列式存储技术初试
- 2. 存储技术
- 3. 储存技术
- 4. 列数据库存储技术笔记
- 5. 存储阵列技术及应用
- 6. 云存储技术
- 7. Web 存储技术
- 8. 列式存储
- 9. 深入解析：DB2 V10.5新特性列式存储表的优点与缺点
- 10. 技术列表
- 更多相关文章...
- • XML 相关技术 - XML 教程
- • Hibernate的快照技术 - Hibernate教程
- • 三篇文章了解 TiDB 技术内幕——说存储
- • Docker容器实战(一) - 封神Server端技术
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Appium入门
- 2. Spring WebFlux 源码分析(2)-Netty 服务器启动服务流程 --TBD
- 3. wxpython入门第六步（高级组件）
- 4. CentOS7.5安装SVN和可视化管理工具iF.SVNAdmin
- 5. jedis 3.0.1中JedisPoolConfig对象缺少setMaxIdle、setMaxWaitMillis等方法，问题记录
- 6. 一步一图一代码，一定要让你真正彻底明白红黑树
- 7. 2018-04-12—（重点）源码角度分析Handler运行原理
- 8. Spring AOP源码详细解析
- 9. Spring Cloud（1）
- 10. python简单爬去油价信息发送到公众号
- 1. DB2 10.5 BLU列式存储技术初试
- 2. 存储技术
- 3. 储存技术
- 4. 列数据库存储技术笔记
- 5. 存储阵列技术及应用
- 6. 云存储技术
- 7. Web 存储技术
- 8. 列式存储
- 9. 深入解析：DB2 V10.5新特性列式存储表的优点与缺点
- 10. 技术列表