【www.shanpow.com--自我介绍】
第一篇列式数据库:列式数据库在大型机上前景如何？
今年七月，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年代出现的对象和对象数据库技术不一样，随着岁月的流逝，其重要性和成本优势将会越来越突出，我相信大型机迟早会反映出这个重要性，即使不行，做一些预见性的研究也是没有害处的，如果行得通，那现在就是大型机证明自身价值的绝好机会。
第二篇列式数据库:海量高性能列式数据库HiStore介绍
架构师（JiaGouX）我们都是架构师！
HiStore是阿里中间件技术团队研发的数据库产品，是一款基于独特的知识网格技术的列式数据库，定位于海量数据高压缩比列式存储，是低存储成本，低维护成本，海量数据OLAP存储引擎；有效的解决了海量数据存储的成本问题，以及在百亿数据场景下支持实时高效的多维度自由组合的检索。
HiStore的优势
· 存储数据量大：TB级数据大小，百亿条记录。数据量存储主要依赖自己提供的高速数据加载工具（2TB/小时）和高数据压缩比（>10:1）；· 高压缩比：平均压缩比>10:1，远高于常规压缩算法，甚至可以达到40:1，极大地节省了数据存储空间。高数据压缩比主要依赖列式存储和patent-pending的灵活压缩算法;· 基于列存储：无需建索引，无需分区。即使数据量十分巨大，查询速度也很快。用于数据仓库。不需要建索引，就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放，每块有知识网格节点记录块内的统计信息，代替索引，加速搜索；· 大数据量查询性能强劲、稳定：亿级记录数条件下，同等的SELECT查询语句，速度比MyISAM、InnoDB等普通的MySQL存储引擎快30倍。高效查询主要依赖特殊设计的存储结构对查询的优化，但这里优化的效果还取决于数据库结构和查询语句的设计；· 并行导入：基于MySQL的协议的并行导入，以及专门的入库工具;· 高并发：实时性的多维数据检索；实时数据导入，海量数据秒级检索；为实时业务提供保障；· 线性扩展：结合TDDL / DRDS，可实现存储容量和处理能力的线性提升;· 系统易用：迁移成本低，无其它依赖独立部署，mysql工具及应用可直接无缝运行其上；· 快速响应复杂的聚合类查询：适合复杂的分析性的SQL查询，如SUM，COUNT，AVG，GROUP BY;
HiStore的价值
· 节约设计开销，没有复杂的数据仓库模型设计要求(比如星状模型、雪花模型)，无需要物化视图、数据分区、索引建立；· 节省存储资源，高压缩比率通常是10：1，某些应用可能达到40：1;· 集成利用广泛，和众多的BI套件相容，比如Pentaho的，Cognos公司，Jaspersof;· 降低运维成本，随着数据库的逐渐增大，查询和装载性能持续保持稳定，实施和管理简单，需要极少的管理；· 分库分表支持，结合TDDL/DRDS，可实现无缝的横向扩展功能和处理能力的线性提升；
HiStore适用场景
· 日志/事件管理系统：调用链路日志跟踪，消息轨迹分析，系统/网络安全审计记录;· 通信行业：话单分析，用户行为分析等;· 大数据量的分析应用：网页/在线分析，移动分析，客户行为分析，营销和广告数据;· 数据仓库/数据集市：实时展示统计分析后数据，便于用户根据统计结果做决策;· 对数据存储成本敏感，查询有实时性要求的场景应考虑HiStore;· 物联网：保存大量物理节点的采集上报，状态等信息，用于后期统计处理;· 历史评价数据，历史订单数据等;
HiStore全局功能模块图
HiStore引擎架构图
HiStore引擎架构图（与MySQL和Postgres的）
Knowledge Grid（知识网格） - 高性能的重要原因
HiStore负载流程
HiStore字符串查询
粗糙集（Rough集）
HiStore的核心技术之一，HiStore在执行查询的时候会根据知识网络（知识网格）把DN分成三类：· 相关的DN（相关节点），满足查询条件限制的DN· 不相关的DN（无关节点），不满足查询条件限制的DN· 可疑的DN（可疑节点），DN里面的数据部分满足查询条件的限制
案例（商品评价管理） - 获取评价标识（按时）
SELECT COUNT(feed_id)
FROM feed_item_subscribe
WHERE seller_id = 12345 AND (gmt_modify BETWEEN str_to_date("start", "%Y%m%d%H") AND str_to_date("end", "%Y%m%d%H")) -- [start, end)
LIMIT start+1, num -- 分页
案例分析
SELECT COUNT(*) FROM employees WHERE salary > 100000 AND age
1. 查找包含salary>100000的数据包2. 查找包含age35的数据包3. 查找包含job = "it" 的数据包4. 查找包含city = "hangzhou" 的数据包5. 去除所有与检索条件不相干的标记6. 最后在确定的数据包内解压缩相关数据7. 执行检索
同类产品
○Infobright
○InfiniDB
○Pivotal Greenplum
○Amazon RedShift
○Teradata DB
○HP Vertica
○SAP HANA
○IBM Netezza
○神舟通用，kstore
○华为高斯DB
○达梦数据库DM7
不同数据类型的压缩比率
数据压缩比率除了和数据类型有关之外，还和数据的差异性有特别大关系，比如posFlag只有0，1，-1三种可能，这种数据显然不可能取得很好的压缩比率。
再看看act字段，act字段使用了comment lookup，比简单的char类型具有更佳的压缩比率和查询性能。comment lookup的原理其实比较像位图索引。在所有的字段当中date字段的压缩比率是最高的，最后数据的大小只有0.1M。varchar的压缩比率就比较差了，所以除非必要，不然不建议使用varchar。数据的压缩不只是和数据类型有关，数据的差异程度起了特别大的作用。比如上面表中一些字段的选择就可以优化，ip可以改为bigint类型，date甚至可以根据需要拆分成year/month/day三列。
来源：阿里中间件团队博客
第三篇列式数据库:列式数据库受关注 Sybase CTO 遭"围堵" - IT168 技术开发专区
列式数据库受关注 Sybase CTO 遭"围堵"
