【 TiDB 使用环境】测试环境 kubernetes环境 opertator为1.5.4版本
【 TiDB 版本】企业版7.1.0
【需求】支持业务端ap、tp分流
【问题】在k8s环境中tidb支不支持业务端ap、tp分流，如果支持该怎么实现
【当前思路】
ap、tp分流主要体现在存储层分离、计算层分流，存储层的分离可以采用tikv、tiflash实现，计算层的分流主要通过建立多组tidb服务通过不同的service对外提供访问，但后期的维护管理不是太方便
我们是直接分两个集群，应用端分流。
嗯，这也是个办法，我们现在的环境不太允许这种架构
最好的办法是通过强制mpp分流tp，ap业务。
ap业务大部分是聚合计算，这部分强制mpp。少量的扫描，可以继续从tikv上取。
tp业务基本不涉及聚合计算，这部分就不强制mpp，甚至可以通过tidb_isolation_read_engines 参数，直接隔离掉这部分业务对tiflash的访问。
我们这边比较尴尬的就是ap业务也要查明细，不全是聚合。所以最后搞了俩集群。
1 个赞
这个架构跟我们想象的一样，就是在k8s环境中不好通过tc进行落地，目前我们的计划是通过创建statefulset资源扩充tidb服务。实现ap业务，并对这部分tidb pod进行单独配置
1 个赞
operator搭建的集群好运维吗
还可以，目前没遇到什么大的挑战
是的。
我觉得就tidb而言，用ap，tp来划分tikv和tiflash目前还是不合适的。
用是不是聚合计算来划分更合适，有些扫描任务在tiflash上执行的效果不好，因为不像主流的ap类的dbms，可以在列存上建立索引。
这就不可避免的导致有一些ap的业务需要访问tikv，这个现象也是合理的。
1 个赞
关键是对tiflash mpp模式的理解，在这个模式下，聚合计算效率很高，对tidb节点的负载很少/几乎没有。聚合计算存算可以说全在tiflash上。
问题在于，如同我上一条回复所说的。ap业务目前大部分情况下不可能只有聚合。所以ap业务大部分情况下，既能访问tiflash也能访问tikv才是最优解决方案。
负载更合理的划分方式是按照是不是聚合计算，来分配在tikv/tiflash节点上。