vertica列式分析数据库
TABLE OF CONTENTS
1vertica简介 (3)
2vertica试用 (4)
2.1数据装载 (4)
2.2DML操纵 (4)
2.3查询分析 (5)
2.4集群 (6)
2.5增量加载案例测试 (6)
3小结与心得 (9)
?vertica简介
?vertica试用
o数据装载
o DML操纵
o查询分析
o集群
o增量加载案例测试?小结与心得
1VERTICA简介
1. vertica是一种整合了MapReduce能力的商业化数据库
2. 基于列的存储架构，高效的数据压缩能力
3. 基于Shared nothing架构，高度灵活的扩展能力
4. 集成的高可用性，采用分布式集群，支持大规模并行处理
5. 支持混合存储模型，高速装载和高速查询可同时进行
6. 与主流db和bi工具无缝集成，是dw的超级加速器
7. 符合工业标准，支持SQL，ACID，JDBC，ODBC，可与流行的ETL工具集成
2VERTICA试用
在一台普通的赛扬d单核、内存2g的pc机上对oracle10g和vertica5进行了一些简单的对比测试，测试数据量约500w+
2.1数据装载
两者在平面文件导入方面看，有明显的差距，vertica的效率大约是oracle 的4倍左右，并且vertica
在cpu的使用上已经满负荷了，测试机上的cpu性能可能也限制了vertica的发挥，按照官方公布的
数据，早在2008年12月，HP 和Vertica 一起工作打破了一下数据仓库数据加载的世界记录，在57分钟21秒的情况下加载了5.4TB的数据进入Vertica数据库，系统运行在HP的C7000刀片机架上。所以我们完全可以相信vertica在数据装载方面的性能是非常出色的，只要cpu足够强劲。需要注意
的是，vertica和oracle都不支持增量装载，一个平面文件只能全量装载。
ps：oracle在数据传输上，效率最高的是表空间传输技术，其次是数据泵+外部表（数据格式为二进制）技术，最后才是sqlload，不过由于前2种技术依赖的文件格式是oracle独占性的，并不具备通
用性。
2.2DML操纵
在dml语句使用上，vertica和oracle表现出的性能与数据装载测试中的效果恰好相反，这是列式存储的架构决定的，行存储架构下，一行记录存储在连续的数据块上，而列架构则是在连续的数据块上存储多行的同一列，这就造成了在列存储架构下一行记录不能顺序写而只能离散写。sybaseiq同样存在这样的效率问题，如果存在较复杂的ETL时，那T环节的实现方案可能需要仔细考虑。
2.3查询分析
案例1sql如下：
select count(*) as B5
from Cfcs_B1_All a
left join DIM_T_HY1 b
on (a.HY_DM=b.HYW_DM)
where (b.HYML_DM = '02')
案例2sql如下：
select sum(a.zb1) as B2,'1' as A2
from Cfcs_B1_All a
where (a.HY_DM LIKE 'A%')
从两个查询案例的测试结果来看，vertica在测试中表现出的效率大约高出oracle一倍，当然oracle 通过创建索引也能将查询时间缩短到与vertica相差无几，不过我们也要考虑到测试的台式机cpu已经是vertcia发挥的瓶颈。测试的目的不是为了证明vertcia的速度是oracle的2倍。而是有助于我们想象当数据量上升到tb甚至pb级时，当cpu性能或者集群性能足够好时，基于Shared nothing 架构可无限扩展集群节点的vertica所表现出来的性能。
2.4集群
测试环境不具备，缺少vertica安装程序（rpm包），未做测试
不过从vertica的文档和试用感受来看，它的集群部署应该比较简单（比oracle简单得多）
2.5增量加载案例测试
模拟一个增量加载的例子，假设一张事实表为月度主题表，里面已存有3年的历史数据，总计约500w+，每天跑批量增量加载当月的最新数据，加载前先删除当月的旧数据，再加载新数据。我们来看看在oracle和vertica下的测试结果
然后，我们将数据区间拉大到一年，增量加载一年的数据，再来看看结果：
我的结论如下：
1. 不论是delete还是load，vertica的效率都比oracle高出好几倍
2. 对于delete删除操作，vertica表现出来的性能不但稳定，效率也高，耗时浮动很小，而oracle
的delete耗时随数据量的增大而增加
3. 完全可以预测在面对海量数据时，vertica在增量加载上的性能优势会更加突出
PS：vertica在删除操作上表现出来的效率是我完全没有预料到的，我觉得有必要对两个db再进行一次update操作的测试，来看看他们有何区别。
测试语句如下：
UPDATE cfcs_b1_all t SET t.zb1=zb1-1 WHERE t.bbq_ LIKE '2007%'
这个update语句影响行数大约180w，以下是结果：
没有想到vertica在update操作上也有如此好的表现，之前比较担忧在vertica上如何ETL，现在来看，这种担忧可能有点多余了。尽管insert操作，vertica的性能不是特别好，但这个环节可以通过平面文件加载的方进行替代，然后在数据库内执行update等数据清洗工作。
3小结与心得
1. vertica有着高效数据压缩能力，数据量越大，磁盘越省
2. 数据装载具有巨大的优势
3. 专门针对数据仓库和统计分析环境，擅长聚集汇总类查询，尤其是大数据量甚至是海量数据
4. 不存储物理表，仅存储列，每一列都是一个索引，而传统数据库需要存储表，然后根据查询维护
相应的索引，不仅磁盘开销增加，同时维护与优化难度加大
5. 基于Shared nothing架构的集群技术，通过简单增加一些廉价的计算机可获取几乎无限的扩展，
且数据分布在各个节点上，而传统数据库则不行，以oracle为例，通常采用rac或者dataguard 技术，rac需要各节点都在同一个本地环境内，且节点过多共享锁竞争更严重，通常node都不超过2个，dg可以异地，但是各节点数据完全一致，都是全局数据，且只有主节点提供服务。
oracle11g开始推出exadata，不过价格不便宜。
6. 部署维护简单，无需专职dba，oracle则不行，离不开dba的维护
7. 使用vertica的解决方案会更加便宜
8. ETL可在vertica中实现，只要运用合理，了解vertica特性，对于效率不高的dml，寻找替代方
法，一样可以保证etl的效率