今年七月，IBM发布新一代大型机 zEnterprise时，随同附带了智能分析优化器（Smart Analytics Optimizer，SAO），它是一个分析工作负载加速装置，IBM将之称为列式设备，关于SAO的技术细节已经有很多文章介绍了，所有证据表明列式数 据库在大型机上有着美好的未来，现在大型机用户是时候考虑列式数据库的优缺点了。
列式数据库介绍
对于大多数企业而言，商务智能类数据管理的成本太高了，并且效果也不见得有多好，由于法律法规和企业自身的要求，现有数据仓库的数据量每年以50%的速 度增长，企业对数据分析的时间要求也越来越苛刻，因此数据存储和工作负载的增长速度远远超过了硬件资源的性能极限。许多时候，列式数据库（按列存储数据， 传统数据库是按行存储数据的）被证明是解决大数据库的有力武器，究其原因是因为列式数据库可以压缩数据和索引，事务都是在压缩后的数据上完成的。
列式数据库和行式数据库对比
在数据仓库领域，列式数据库和传统的行式数据库有何差别呢？列式数据库和行式数据库的拥护者均认为结合这两种技术的混合数据库是个不错的想法。
行式数据库擅长随机读操作，列式数据库则更擅长跨大数据量查询，而混合数据库则试图同时包含这两种技术的优点，在灾难恢复环境中，数据要么按列式存储，要么按行式存储。
我认为未来将是列式数据库的天下，行数据库和混合型数据库都将渐渐消亡，原因如下：数据增长速度很快，对存储设备（主内存和SSD）的需求也将不断上 升，随着主内存和SSD中压缩列所占百分比的提高，列式数据库随机读的弱点反而变成了优点，这样列式数据库不管是应付联机事务处理，还是大批量更新或大型 报表需要执行的复杂查询都能应付自如。对于更新操作而言，列式数据库和行式数据库在这方面已经没有多大差距了，因为大部分更新操作只会影响到一行中的一到 三列（字段），同时，大部分更新操作影响的是最近的数据，因此主内存/SSD缓存中数据会越来越多。对于插入和删除操作而言，先在内存中快速更新索引，然 后再写入磁盘，这意味着在I/O密集型情况下也不会有明显的性能下降。对在线备份而言，按列存储方法压缩数据后备份时间窗口将会更短。
对今天的数据仓库而言，列式数据库的性能和传统行数据库相比，根本不在一个数量级上，列式数据库已经得到了广泛的认可和使用（Sybase IQ已经有十年历史，也出现了一些新兴列式数据库公司，如Vertica），数据库巨人Oracle也按捺不住，在其Exadata数据库机中也加入了按 列存储选择，IBM则提供了一个列式专用设备，它可以确定什么数据该按列存储，什么数据该按行存储，然后将事务分流到相应的设备。
列式数据库和大型机
咋一看，列式数据库似乎只适合松耦合分布式架构，如x86和System p，当然，每一个列式数据库厂商，从Vertica到Sybase IQ，再到VectorData，都会告诉你他们的产品适合x86，也适合三层和网格Unix/Linux架构，仔细调查后才发现，原来大型机对列式数据 库的支持已经有一段历史了，早在上世纪70年代，VectorData和1010data的原型就被当作是大型机上的列式存储解决方案，而Sybase IQ则流淌着美国计算机公司Model 204反向列表数据库的血液，Model 204是纯列式的，但没有关系。
此外，分布式体系架构方法不是必需的，大型机使用历史数据的缓存处理事件流，这个技术在越来越多的数据库上使用，大型机拥有更先进的流水线处理并发流， 在面对大规模（2TB/小时）的流式事务处理时，Pervasive DataRush技术显示了这种并发的性能优势。
总之，列式数据库技术在未来10年会得到迅速发展，在性能和扩展性方面都会带来极大的变化，IBM会借助大型机上的数据仓库作为跳板，转而寻求对列式存储技术的支持，因此，假设你的IBM大型机用户，现在是时候关注这一技术了。
列式技术注意事项
首先，智能分析优化器（SAO）对确定应用程序和工作负载提供了有力的帮助，大部分应用都将从列式存储技术受益，因此用户应该考虑使用SAO，而不仅限于依赖高端商务智能应用系统。
大型机用户现在要做的其它任务是熟悉列式存储管理和灾难恢复，理解IBM为什么要区分列式和行式存储，以及索引和缓存的工作原理，对今后真正管理列式数据库和Oracle Exadata中的混合列式压缩将会起到帮助作用。
我现在已经完全被列式存储技术折服，它和上世纪90年代出现的对象和对象数据库技术不一样，随着岁月的流逝，其重要性和成本优势将会越来越突出，我相信 大型机迟早会反映出这个重要性，即使不行，做一些预见性的研究也是没有害处的，如果行得通，那现在就是大型机证明自身价值的绝好机会。
评论