杂乱事务查询关于传统的联系型数据库来说是一种检测，而经过 TiKV 行存与 TiFlash 的列存结合运用就能很好地应对。本文依据 TUG 用户边城元元在 TiDB 社区技术交流石家庄站的共享整理，详细介绍了 TiKV & TiFlash 加快杂乱事务查询的原理及实践计划。

布景

在互联网公司或传统公司的 CRM 体系中，最常用的功能之一客户的挑选。经过不同的视点、维度、标签的组合来框选客户，以便后续的事务操作。

这无疑是对传统联系型数据库，或者联系数据库加列存数据库的架构是一种检测，主要有下面几个痛点：

  • 传统的联系型数据库无法经过加索引来优化加快查询，事务无法正常展开；

  • 列存数据库需求把挑选相关数据放到列数据库，并且需求做好数据实时同步；

  • 无法从数据库层面做好数据的读取，往往需求从列数据库读取数据后再到联系数据库进行数据合并后输出，性能不容乐观。

TiDB 数据库的 TiKV 和 TiFlash 的组合理论上解决了上面的几个痛点。

TiKV 行存 与 TiFlash 列存混合运用

TiDB 中 query 履行的示意图，能够看到在 TiDB 中一个 query 的履行会被分成两部分，一部分在 TiDB 履行，一部分下推给存储层（ TiFlash/TiKV ）履行。

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

混用原理

  • TiDB 的队伍混合并不是传统设计上的行存列存二选一，而是 TiDB 能够在同一张表一起具有行存和列存，且两者永久保持数据强共同（而非终究共同）。

  • 多表查询分别运用不同的引擎 TiKV 或 TiFlash。

  • TiFlash 支持 MPP 形式的查询履行，即在核算中引入跨节点的数据交换（data shuffle 进程）。

混用优化

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

标签体系高级挑选

经过标签（从宽表里不确定字段）和窄表特定字段组合查询客户并分页

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

Read from TiKV

SELECT
/*+ READ_FROM_STORAGE(tikv[b], tikv[c],tikv[d]) */
	a.*,
	b.CUST_NAME,b.CERT_TYPE,b.CERT_NUM,b.CUST_TYPE,b.SEX,b.AGE,b.BIRTH_DT,
	c.ORG_ID,c.ORG_NAME,
	d.ASSET,d.ASSET_MON_AVG 
FROM
	(
	SELECT /*+ READ_FROM_STORAGE(tikv[m],tikv[n]) */
		m.cust_id 
	FROM
		m_cust_label m
		RIGHT JOIN m_cust_org n ON m.CUST_ID = n.CUST_ID 
	WHERE
		m.cat1 IN ( 516, 710, 230,3301 ) 
		AND n.ORG_ID IN ( '133','8716', '7162') ORDER BY	n.cust_id ASC 	LIMIT 100 
	) a
	LEFT JOIN m_cust_main b ON a.cust_id = b.cust_id
	LEFT JOIN m_cust_org c ON a.cust_id = c.cust_id
	LEFT JOIN m_cust_data d ON a.cust_id = d.cust_id ;

4G,2c 虚拟机 300 万数据，初次履行 48 s 二次履行 0.7s

Read From TiKV & TiFlash


 SELECT 
/*+ READ_FROM_STORAGE(tikv[b], tikv[c],tikv[d]) */
	a.*,
	b.CUST_NAME,b.CERT_TYPE,b.CERT_NUM,b.CUST_TYPE,b.SEX,b.AGE,b.BIRTH_DT,
	c.ORG_ID,c.ORG_NAME,
	d.ASSET,d.ASSET_MON_AVG 
FROM
	(
	SELECT /*+ READ_FROM_STORAGE(tiflash[m],tikv[n]) */
		m.cust_id 
	FROM
		m_cust_label m
		RIGHT JOIN m_cust_org n ON m.CUST_ID = n.CUST_ID 
	WHERE
		m.cat1 IN ( 516, 710, 230,3301 ) 
		AND n.ORG_ID IN ( '133','8716', '7162') ORDER BY	n.cust_id ASC 	LIMIT 100 
	) a
	LEFT JOIN m_cust_main b ON a.cust_id = b.cust_id
	LEFT JOIN m_cust_org c ON a.cust_id = c.cust_id
	LEFT JOIN m_cust_data d ON a.cust_id = d.cust_id

4G,2c 虚拟机 300 万数据，初次履行 3s 二次履行 0.3s

TiFlash & MPP

操控是否挑选 MPP 形式

变量tidb_allow_mpp操控 TiDB 能否挑选 MPP 形式履行查询。变量tidb_enforce_mpp操控是否疏忽优化器价值预算，强制运用 TiFlash 的 MPP 形式履行查询。

这两个变量所有取值对应的结果如下：

tidb_allow_mpp=off tidb_allow_mpp=on（默许）
tidb_enforce_mpp=off（默许） 不运用 MPP 形式。 优化器依据价值预算挑选。（默许）
tidb_enforce_mpp=on 不运用 MPP 形式。 TiDB 无视价值预算，挑选 MPP 形式。 
set @@session.tidb_allow_mpp=1;
set @@session.tidb_enforce_mpp=1;

SELECT
/*+ READ_FROM_STORAGE(tikv[b], tikv[c],tikv[d]) */
	a.*,
	b.CUST_NAME,b.CERT_TYPE,b.CERT_NUM,b.CUST_TYPE,b.SEX,b.AGE,b.BIRTH_DT,
	c.ORG_ID,c.ORG_NAME,
	d.ASSET,d.ASSET_MON_AVG 
FROM
	(
	SELECT /*+ READ_FROM_STORAGE(tiflash[m],tiflash[n]) */
		m.cust_id 
	FROM
		m_cust_label m
		RIGHT JOIN m_cust_org n ON m.CUST_ID = n.CUST_ID 
	WHERE
		m.cat1 IN ( 516, 710, 230,3301 ) 
		AND n.ORG_ID IN ( '133','8716', '7162') ORDER BY	n.cust_id ASC 	LIMIT 100 
	) a
	LEFT JOIN m_cust_main b ON a.cust_id = b.cust_id
	LEFT JOIN m_cust_org c ON a.cust_id = c.cust_id
	LEFT JOIN m_cust_data d ON a.cust_id = d.cust_id

运用 MPP 形式来履行查询后基本秒开，4G 2c 虚拟机 300 万数据，初次履行 1s 二次履行 0.15s

2.4 SPM 固定履行计划

CREATE GLOBAL|SESSION  BINDING for	<BindableStmt > USING <BindableStmt2>
SHOW GLOBAL|SESSION BINDINGS ; -- 检查绑定计划explain format = 'verbose' <BindableStmt2>;
show warnings; -- 经过履行 show warnings 了解该 SQL 句子运用了哪一条 binding

固定特定查询走 TiFlash 列存查询。

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

标签下价值组织排名

依据选中的属性（多值）

运用这些值最多的排名前 3 的组织，并统计出总额

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

履行计划

table:c 走 TiFlash ；table:a, table:b 走 TiKV ，一起运用了列存和行存的优势。

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

总结

运用 TiKV 和 TiFlash 能够加快杂乱查询，下面简略增加了运用运用场景。

组件 适用场景阐明
TiKV 检索条件固定，且有索引
TiFlash 检索条件不固定，无法加索引
TiKV + TiFlash 部分表检索条件不固定，部分表有索引

如果有描绘不当的当地欢迎评论纠正！

谢谢 PingCAP 社区的大力支持！