HTAP 数据库模型设计：从架构演进看现代数据栈的融合之道
那种业务系统常常会用，MySQL、Oracle 或者 PostgreSQL 作为关键的那个交易库，去应对高并发情形下的增删改查；然而数据分析以及报表需求却是要依靠 HBase 或者数据仓库产品，借助复杂的 ETL 过程来达成数据同步。
这种采用分而治之的模式带来了严峻挑战，数据一致性难以得到保障，数据新鲜度存在延迟状况，并且要维护两套独立系统以及它们之间的数据管道，以至于使得运维成本显著增加，故障风险也明显上升。
HTAP数据库得以问世，恰恰是为了破除这般壁垒，于一套引擎当中同步支撑TP以及AP负载。
Primary Row Store + InMemory Column Store
Distributed Row Store + Column Store Replica
Disk Row Store + Distributed Column Store
Primary Column Store + Delta Row Store行存与列存的博弈：HTAP 底层存储架构解析
Transaction Processing
Analytical Processing
Data Synchronization
Query Optimization
Resource Scheduling为了对两类业务予以兼顾，于数据库模型设计方面，HTAP 数据库展现出多样化的演进路径。
为主的是第一类架构中的内存行存，为辅的是列存，比如说把基于行的缓冲区跟基于列的压缩单元相联合，所有的工作负载都于内存里进行处理，以此达成高吞吐。
另外一种占据主流地位的架构，采用的是主列存储，并且配合着增量行存，具有典型代表性的比如SQL Server的列存储索引那样，它是在传统的行引擎之上，叠加了列式索引，进而以此来启用实时分析。
在分布式的那种场景之下，TiDB选定了那更加彻底的资源隔离方案，借助行存储引擎TiKV去满足OLTP的高频写入需求，与此同时维护列存储引擎TiFlash的独特副本，采用Raft协议达成数据在行、列副本之间的强一致复制，进而在物理层面实现TP与AP负载的隔离。
增量同步与查询优化：HTAP 关键技术的实战应用
于数据同步技术这一层面而言，怎样去处理增量数据，乃是决定数据新鲜度的关键核心所在呀，是吗？
主流方案涵盖内存增量合并，包含基于磁盘的增量合并，还有从主行存储进行重建。
比如说，于类 LSM-Tree 结构里，刚写入的新数据会首先进入到内存进行增量储存，紧接着需要借助 B+树 实现索引加速，之后会按照一定周期合并到主列存储当中。
在TDSQL的列存引擎当中，这种设计也是有所体现的，它会先把数据写入本地CSV文件，从而作为delta文件，然后再追加到对象存储之上，以此来实现低成本、高吞吐的数据流转。
查询优化技术是释放 HTAP 性能的关键。
对于OLAP查询而言，现代数据库大规模引入了向量化执行，以及SIMD指令集来进行加速。
与广泛运用 SIMD 并行计算的华为 Taurus MySQL 列存引擎，在大宽度的数据表进行聚合分析这类情形之下，其性能有着相当显著的提高。
在分布式这个层面，TDSQL的MPP这种架构，面对着复杂SQL被接收到的情况时，会由MPP SQL引擎去解析，以此生成分布式执行计划，然后下推至各列存节点，还要并行计算。
SelectDB 会借助 CBO 优化器，以智能方式去识别 AP 请求，接着把该请求导入到 MPP 优化阶段，随后将其下发至只读计算集群，依靠 只读副本的一致性读 这一能力，达成了物理隔离这件事情，并且确保了强一致读。
高并发场景下的 HTAP 运维与故障排查
在实际进行生产的环境当中，HTAP数据库被引入，这一行为使得主从复制的复杂性得到了简化，同时，读写分离的复杂性也因之而获简化。
例如，名为TiDB的行列混合架构，以其天然的特性达成了读写之区分隔离：针对像TP类型的增加、删去、修改以及查询样式这么一回事的操作，它就直接对属于行存储器的TiKV去施加作用，然而，那拥有复杂样式样式的AP查询，居然会以一种不被察觉的方式给导向归入列存储器的TiFlash，并且，根本不需要业务层面去维护带有复杂性质的数据同步方面的那套逻辑规则。
于运维故障排查范畴之内，鉴于 HTAP 数据库一般有着资源隔离能力，一旦出现分析查询致使在线业务变缓的情况时，DBA 能够动态地去调整资源组，从而为 OLTP 预留充足的 CPU 以及 IO 资源，以此来确保核心交易链路的稳定性。
对使用 MySQL 的用户来讲，当从单机库转战到 HTAP 集群之际，要留意分布式事务 ID 的监测情况，还要关注列存索引的命中比率，以及增量数据合并时的延迟状况。对使用 PostgreSQL 的用户说来，在从单机库迁移至 HTAP 集群之时，需关注分布式事务 ID 的监控态势，以及列存索引的命中率情形，还有增量数据合并的延迟情况。
在碰到性能瓶颈之际，排查的思路要从以往的 SQL 索引优化，延伸至分布式执行计划的剖析，还有 MPP 并行度的调节，以及跨节点数据 shuffl e 的代价估量。
让运维人员真正释放 HTAP 架构于高并发、大数据场景下的技术红利，这种从单一引擎至混合负载的转变，需运维人员深入领会行存与列存的互补特性。
Comments NOTHING