关于 TiFlush 的 「读取一致性」和 「智能选择」,OLAP 场景下是否有些矛盾?

关于 TiFlash 我还没有实际使用,仅仅是看了些文档,很抱歉在此泛泛的问一下

https://docs.pingcap.com/zh/tidb/stable/tiflash-overview

关于一致性

文档提到 TiFlash 具有读取「一致性」,读取TiFlash 时会根据查询的时间戳来验证所需 region 是否复制完毕。
如果还没复制完毕,则会暂时不响应。

这是否意味着用 TiFlash 查询时,可能会有等待复制产生的阻塞和延迟?

关于 「智能选择」

不管是实例还是会话的设置, tidb_isolation_read_engines 如果包含了 tiflash 的话,查询分析器就可能会命中 TiFlash ,那么在上述情况下,是不是用 TiFlash 有可能不如只用 TiDB/TiKV 来得快?

在 OLTP 场景下

假设在高频读写的 OLTP 场景下,我们引入 TiFlash 想要隔离 AP 和 TP 的话,是否应该这样设置:

  • tidb : 默认 tidb_isolation_read_engines=tidb,tikv , 以避免 TP 受 TiFlash 的复制延迟的影响 ?
  • AP 下加特殊 session 设置,把 tidb_isolation_read_engines 设置成 tidb,tiflash ?

以上只是看文档的感受,欢迎有实践经验的同学来指教。

抛个砖

这是否意味着用 TiFlash 查询时,可能会有等待复制产生的阻塞和延迟?
是的,在某些情况下,TiFlash无法及时同步到数据,读取的SQL是会受到影响的。

关于智能选择
如果使用的引擎包含TiFlash和TiKV的时候,查询分析器选择了不合适的引擎,确实会出现命中不合适的引擎,速度不如只用某个引擎快,通常出现这种问题是因为查询分析器的优化有问题,可以向官方报Bug

在实际使用中,通常TiFlash的同步是很快的,所以更多时候的我会担心AP类的请求本来应该走TiFlash的走到了TiKV上,对TiKV产生压力,可能对TP类的请求产生影响,这时候我会把分析类的非实时请求的引擎限制到TiFlash

1 个赞