转载

分布式低成本分析型数据库HiStore介绍

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介绍

HiStore的价值

• 节约设计开销，没有复杂的数据仓库模型设计要求(比如星状模型、雪花模型)，无需要物化视图、数据分区、索引建立；

• 节省存储资源，高压缩比率通常是10：1，某些应用可能达到40：1;

• 集成利用广泛，和众多的BI套件相容，比如Pentaho的，Cognos公司，Jaspersof;

• 降低运维成本，随着数据库的逐渐增大，查询和装载性能持续保持稳定，实施和管理简单，需要极少的管理；

• 分库分表支持，结合TDDL/DRDS，可实现无缝的横向扩展功能和处理能力的线性提升；

HiStore适用场景

• 日志/事件管理系统：调用链路日志跟踪，消息轨迹分析，系统/网络安全审计记录;

• 通信行业：话单分析，用户行为分析等;

• 大数据量的分析应用：网页/在线分析，移动分析，客户行为分析，营销和广告数据;

• 数据仓库/数据集市：实时展示统计分析后数据，便于用户根据统计结果做决策;

• 对数据存储成本敏感，查询有实时性要求的场景应考虑HiStore;

• 物联网：保存大量物理节点的采集上报，状态等信息，用于后期统计处理;

• 历史评价数据，历史订单数据等;

HiStore全局功能模块图

分布式低成本分析型数据库HiStore介绍

HiStore引擎架构图

分布式低成本分析型数据库HiStore介绍

HiStore引擎架构图（与MySQL和Postgres的）

分布式低成本分析型数据库HiStore介绍

Knowledge Grid（知识网格） - 高性能的重要原因

分布式低成本分析型数据库HiStore介绍

HiStore负载流程

分布式低成本分析型数据库HiStore介绍

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 -- 分页

No.	Column	Type	Desc
1	seller_id	bigint	卖家ID
2	feed_id	bigint	主评ID
3	feedback	varchar(4000)	主评内容
4	gmt_modify	datetime	修改时间

案例分析

SELECT COUNT(*) FROM employees WHERE salary > 100000 AND age < 35 AND job = 'it' AND city = 'hangzhou';

分布式低成本分析型数据库HiStore介绍

1.  查找包含salary>100000的数据包
2.  查找包含age<35的数据包
3.  查找包含job = 'it' 的数据包
4.  查找包含city = 'hangzhou' 的数据包
5.  去除所有与检索条件不相干的标记
6.  最后在确定的数据包内解压缩相关数据
7.  执行检索

不同数据类型的压缩比率

分布式低成本分析型数据库HiStore介绍

数据压缩比率除了和数据类型有关之外，还和数据的差异性有特别大关系，比如posFlag只有0，1，-1三种可能，这种数据显然不可能取得很好的压缩比率。再看看act字段，act字段使用了comment lookup，比简单的char类型具有更佳的压缩比率和查询性能。comment lookup的原理其实比较像位图索引。在所有的字段当中date字段的压缩比率是最高的，最后数据的大小只有0.1M。varchar的压缩比率就比较差了，所以除非必要，不然不建议使用varchar。数据的压缩不只是和数据类型有关，数据的差异程度起了特别大的作用。比如上面表中一些字段的选择就可以优化，ip可以改为bigint类型，date甚至可以根据需要拆分成year/month/day三列。

原文 http://jm.taobao.org/2016/06/16/histore-intro/

正文到此结束