400-800-0824
info@ymatrix.cn
在 HTAP 场景中，针对分析（AP）负载，不少分布式数据都有不错的性能表现，而要支撑性能、并发要求严苛的交易（TP）型负载才是真正的难点。
目前，YMatrix 的 HTAP 能力已成功落地于多个大型客户的核心业务中，在高峰期 10万+ TPS 的高压下，依然能稳定运行。那 YMatrix 究竟是如何做到的？我们曾在YMatrix 的 HTAP 能力和其他数据库有何不同？与分布式里套单机？YMatrix HTAP “神技”搞定 10w+ TPS两篇文章中进行了初步解读。
今天，我们将继续深入，拆解 YMatrix 背后支撑 TP 性能飞跃的关键技术矩阵。
非平衡部署：我们可以在指定主机上仅部署 1 个实例，实现资源独占，满足和 AP 负载的资源隔离需求；
定域分布：同时，可以将 TP 负载涉及的主要的表统一分布在一个节点上，使得绝大部分 TP 类查询都能由单实例完成，从而避免分布式架构的额外开销。
✏️ 相关使用文档：https://ymatrix.cn/doc/6.3/sql_ref/create_segment_set
在 YMatrix 中，通常的，查询的执行分为两部分：
生成计划：由主节点上的 QD （Query Dispatcher) 进程完成
执行查询：由所有数据节点上的 QE （Query Executor) 进程完成
分布式架构下，这种通用的查询执行方式，在 TP 场景中存在两类问题：
小查询空转损耗：一些小查询，特别是点查，数据是分布在某个或某几个特定数据节点上，其他数据节点则不会被触及，这些与查询结果无关的数据节点参与并行计算，会在计划生成、结果处理、网络等待等方面产生额外的时间消耗，从而影响相应速度
主节点资源瓶颈：在分布式数据库中，由于涉及多个数据节点以及大量分区表，查询计划所消耗的内存会远多于单机数据库，而由于计划都需要主节点上 QD 进程负责，当并发较高时，主节点的内存可能成为瓶颈，影响集群的并发能力。
YMatrix 的查询直推技术针对 TP 场景下的小查询 + 高并发的特点，分情况进行了两阶段深度优化。
从图中可以看到，当主节点上的 QD 通过查询计划和分布规律判断数据仅涉及个别节点时，会仅仅将查询计划下发至相关节点和实例执行，从而避免与查询不相关的数据节点上的资源占用，更重要的是减少了主节点上 QD 收集、处理无关数据节点返回的空数据的时间，从而提升了 TP 型查询的处理速度。
从图中可以看到，针对数据只存在于单一节点上的查询，原本由主节点的 QD 负责的生成计划工作，直接下发给了对应的数据节点上的 QE 执行，大大降低了主节点的内存消耗，从而实现了并发能力的提升。
✏️ 在使用时，YMatrix 会根据查询和表的特征，自动判断查询是否能够进行“单机化”处理，无需额外操作。
在涉及 JOIN 的查询中，由于分布式架构本身的特点，一个数据点可能需要从其他数据节点拉取数据，在数据拉取、传输等方面都会造成额外的开销。
通过将数据量较小的维度表设置为复制表，可以让该表在每一个数据节点上都保留一个完整的副本，这样在发生 JOIN 操作时，在本地即可读取数据执行计算，减少数据分布在不同主机上导致的传输的开销，从而提升相关查询的性能表现。
例如明细数据表有亿级数据，用户权限表却只有几百条数据：当查询将明细数据表与用户权限表关联时，若使用传统的分布表，则可能需要将权限表数据在所有数据节点间搬运；而通过将用户权限表设置为复制表，JOIN 时就可以在原地进行，就可以避免降低用户权限表中的数据在各个节点间的传输，从而提升查询性能。
✏️ 复制和普通的表仅分布方式不同，可用同样的方式插入、修改、删除数据，并由数据库保障多个副本间的强一致性。
除了复制表，YMatrix 还支持 Master-only，即将数据存储于主节点上。其好处是彻底避免了分布式的开销，查询在主节点上即可完成执行，速度自然能够得到提升。
但如果主节点参与查询计算，自然会占用主节点大量资源；同时，对于分析型查询，无法利用分布式架构的并行计算优势，因此，在具体使用时，还需要更多的仔细的权衡。
提升 TP 场景性能是一项系统性工程，需要大量技术投入。除了以上技术创新，YMatrix 还在内核很多细节上做了大量的优化，最终才能保障在客户生产环境中平稳支持 10万 + TPS 负载的效果。
