行列混存—肴杂负载的正确打开方式
现在，各行业数据中心都迫切寻找一栈式解决方案，通过屏蔽大数据技能底层组件的差异，寻找“All Data In One”的解决方案，只有如此才能降本增效。
TP与AP的巨大差异，在于行存与列存在不同使用场景下的效能表现。在计算机世界中，数据吞吐速率往往受数据访问局部性原理支配。我们知道，现代硬盘、内存工作原理是当用户读某一地区的数据时，其邻接的数据也会被调入上一级高速缓存，读1KB数据和连续的64MB数据的代价根本相同，用户在读取连续的磁盘大概内存信息时，其速度往往比随机读取快一个数量级。因此，行存储大多用在SQL的TP场景，而列存储根本用在NoSQL的AP场景。
这背后的原因也很简单，照旧以银行业作为案例，在联机交易的TP场景下，比如当客户取款时，会校验用户、账号、密码、余额等信息，这些信息都是以“行”为单位存储的，联机交易中的数据经常是以“行”为单位访问的，把数据放在一行就会有访问速度的上风。但在统计、分析营业报表，举行数据发掘等AP场景下，往往只需要关注交易金额、账户余额等少量维度的信息，而不需要用户、账号、密码等数据，在这种场景下，将同一维度信息放在一起的列存储方案就有很大的速度上风了。
将行、列举行混存，综合两者的上风，这方面业界也有不少尝试，但往往都不是很成功，最大的题目照旧在于性能。对于联机TP交易场景来说，列式存储的写入性能太低了。所以一般来说，传统的方案往往照旧退化成为行式存储TP数据库，在交易量少的日终结算时刻，将数据吐给列式存储AP数据库举行数据发掘。
如图1所示，逻辑上，业务场景主要分为两类：联机交易OLTP和数据分析OLAP。HTAP数据库不仅支持使用SQL举行传统的关系模子计算，更是将图计算和AI建模纳入了逻辑筹划中，可举行高阶计算。在数据存储层，通过行列肴杂的方式，按需支持OLAP和OLTP场景，这样就做到了一种存储架构兼容所有场景。
图1 HTAP数据库架构图
这种逻辑筹划及存储融合，也称“All Data In One”，是对数据库底子底座的重新界说。在资源调度层，通过AI-Native的方式探查出需要使用的调度引擎，并在现实计算时，做好资源隔离。这种架构可以更有效地支撑数据计算，最终实现一个数据库融合所有场景的终极目标。相信未来的国产HTAP数据库，还将继续朝着“All Data In One”的道路前进，发展特色不停创新，降低系统运维资本，发挥数据的最大价值。