共计 3166 个字符，预计需要花费 8 分钟才能阅读完成。
导读
TP 与 AP 交融的 HTAP 数据库正成为业内的发展趋势。但因为大规模数据场景下 TP 与 AP 零碎自身的复杂性，要在一套数据库系统中交融两种应用场景的性能并不容易。浪潮推出的 HTAP 云溪数据库采纳多模存储引擎的计划实现 HTAP 个性，在 OLTP 的根底上引入列存引擎撑持 OLAP 场景。本文将着重介绍列存引擎技术在 HTAP 云溪数据库中表演的重要角色。
OLTP 与 OLAP
名词释义
OLTP，全称 On-Line Transaction Processing，翻译为联机事务处理
OLAP，全称 On-Line Analytical Processing，翻译为联机剖析解决
从上个世纪 60 年代开始，计算机系统就被人们用于执行薪资结算、会计和计费等畛域的工作。那时，用户输出数据，计算机系统再对数据进行解决，从而实现一系列的增删改查操作，这就是晚期的 OLTP。随着计算机技术与数据库技术的进一步倒退，OLTP 在政府、银行和企业信息系统中被广泛应用至今。现在，OLTP 被认为是一种低提早、高容量、高并发工作负载，通常用于开展业务，例如接订单和履行订单，进行装运，为客户开账单，收款等事务处理。
而 OLAP 被认为是剖析工作负载。OLAP 面对的场景是绝对较高的提早，较低的数量和较低的并发工作负载，这些负载通常用于通过剖析经营，历史和大数据，制订战略决策或采取措施来进步公司绩效，晋升产品质量，改善客户体验，进行市场预测等。随着近年来大数据技术的衰亡，企业对数据分析的场景在时效性方面有了更高的要求，大规模数据下的 OLAP 也开始成为泛滥企业的刚需。
在互联网流量暴发之后，在面对海量数据时，OLTP 和 OLAP 零碎的信息体系结构和根底构造各不相同，同时又具备各自的复杂性，因而这两种利用场景别离有不同的产品来满足用户需要。这一时期，企业通常采取“事务型数据库系统 + 剖析型数据库系统 +ETL 工具”的组合计划来实现大规模数据存储事务 + 剖析的业务需要。
HTAP 的呈现
这种采纳不同零碎来针对不同场景进行数据处理的计划也带来了相应的难题。因为 TP 和 AP 是跨平台的，所以在搭配应用时就会有数据传输的过程，这就带来了两个挑战：数据同步、数据冗余。
数据同步的外围是数据时效性问题，过期的数据往往会丢失价值。以往的做法是，OLTP 零碎中的数据变动，通过日志的模式裸露进去；通过音讯队列解耦传输；后端的 ETL 生产拉取，将数据同步到 OLAP 中，造成一套 TP 到 AP 的数据传输链条。因为整个链条较长，这就对时效性要求较高的场景提出了考验。
另一方面，数据在链条中流动，存在多份的数据冗余保留。在惯例的高可用环境下，数据会进一步保留多份。因而带来了更大的技术、人力老本以及数据同步老本。同时横跨如此多的技术栈、数据库产品，每个技术栈背地又须要独自的团队反对和保护，如 DBA、大数据、基础架构等，这些都带来了微小的人力、技术、工夫、运维老本。
2014 年，Gartner 提出了一种混合事务 / 剖析解决的新型数据库模型 HTAP，旨在突破 OLTP 与 OLAP 零碎间的隔膜，将二者交融到一个数据库系统中，防止 ETL 跨平台数据传输带来的昂扬老本。
随着软硬件基础设施和数据库技术一直倒退，兼顾 OLTP 和 OLAP 负载的 HTAP 数据库系统逐渐代替传统“事务型数据库系统 + 剖析型数据库系统 +ETL 工具”计划的趋势曾经造成。
云溪数据库和列存引擎
云溪数据库是由浪潮于近期开源的一款 HTAP 分布式数据库，也是首个行将被凋谢原子开源基金会接收的国产数据库我的项目。该数据库系统为应答日益剧增的混合负载场景研发，可能混合事务和剖析场景，实用更多数据利用需要。为实现 HTAP 的个性，该数据库系统中的列存引擎子系统在整个零碎架构中表演了重要的角色。
撑持云溪数据库的 HTAP 性能的是多模存储引擎，在其中结构化数据的解决上，存储能够分成行存和列存，是别离针对 OLTP 和 OLAP 场景的优化，而撑持 OLAP 场景的就是的列存引擎。
列存引擎是云溪数据库数据库系统 HTAP 状态的外围组件，用于存储和治理数据的列存正本，是行存引擎的扩大，列存引擎在提供良好隔离性的同时，也兼顾了读时强一致性。列存正本通过 Raft Learner 协定异步复制，然而在读取的时候通过 Raft 校对索引形式达到 Learner 和 Leader 的同步。这个架构很好地解决了 HTAP 场景的隔离性以及列存同步的问题。
列存引擎架构介绍
列存引擎逻辑架构
列存引擎逻辑架构蕴含四个局部：
1）DDL 模块；
2）SQL 层矢量计算模块；
3）正本层 Raft 协定模块；
4）存储层的通明拜访模块和列存数据库模块。
DDL 模块负责对表的列存正本进行治理，它驱动元数据模块、Raft 协定模块和列存数据库模型协同工作。
矢量计算模块负责从列存正本中读取数据并进行矢量计算，它读取元数据模块，从适合的列存正本中读取数据，实现计算并返回后果。
Raft 协定模块负责解决行列正本一致性问题。
通明拜访模块负责对下层提供对立存储拜访接口，并屏蔽上层异构存储引擎的差别，实现下层与存储引擎的解耦；列存数据库是列存引擎最底层存储组件，负责以列存格局理论存储列存正本数据。
列存引擎物理架构
列存引擎的物理架构分为三层：
1）应用层：包含所有调用数据库服务的客户端应用程序；
2）网关层：数据库网关负责通过优化 SQL 路由，晋升集群整体执行性能。数据库集群采纳全对等网络拓扑，集群中的任何一个节点实例都能够解决 SQL，数据库网关依据节点实例负载和数据分布状况对 SQL 路由进行优化，将 SQL 发送给较为适合的节点实例，例如将纯 OLAP 负载发送到某一组列存节点上。
3）集群层：集群由角色和作用雷同的多个节点实例组成，接管 SQL 的实例节点长期充当 Master 的角色，负责驱动 SQL 的执行流程，与其余节点实例交互，并返回计算结果。每个节点实例可领有多个 Store，每个 Store 能够被标记为不同的类型，目前可标记行存 Store 或列存 Store。列存 Store 底层采纳列存数据库，只能存储列存正本。如果节点实例领有的 Store 均为列存，则成为列存节点实例。从资源隔离的角度登程，能够将所有列存节点实例组成一个虚构 OLAP 数据库集群，专门负责解决 OLAP 负载，且不对其余行存节点实例造成过大影响。
列存引擎的性能个性
列存引擎有几大性能个性，矢量计算、计算下推、列式存储和异步复制。
在具体实现上，列存引擎采纳了 Clickhouse 并在其根底上进行排汇优化。ClickHouse 自身是一套高效的列式存储引擎，并且实现了数据有序存储、主键索引、稠密索引、数据 Sharding、数据 Partitioning、TTL 等丰盛性能。
总结
作为一款新型的 HTAP 分布式数据库系统，云溪数据库能够同时满足事务、剖析场景，防止繁琐且低廉的 ETL 操作。而列存引擎技术在这其中施展了重要的作用。
列存引擎作为实现 HTAP 的关键技术，其异步复制性能能够在保障事务处理性能的根底上，达到剖析场景准实时的成果，满足用户需要，优化用户体验。列存引擎植根于 云溪数据库中，继承其弱小的产品个性，使得其在原有高性能的 OLTP 能力根底上，加强了对 OLAP 场景的解决能力，丰盛了产品性能。
对于大部分数据库用户来说，最好的产品体验就是开箱即用，无论是 TP 还是 AP 场景，如果可能在同一个黑盒零碎中实现所有操作，就能升高用户心智累赘和运维老本。所以不难理解为何对立 TP 和 AP 解决的 HTAP 数据库可能成为受市场和用户追捧的产品趋势。
对于云溪数据库的更多详情能够查看：
官网代码仓库：https://gitee.com/ZNBase/zn-kvs
官网：http://www.znbase.com/
对相干技术或产品有任何问题欢送提 issue 或在社区中留言探讨。同时欢送宽广对分布式数据库感兴趣的开发者独特参加云溪数据库我的项目的建设。
