TiKV读取和Coprocessor

  • 1、数据的读取
  • 1.1、ReadIndex Read
  • 1.2、Follower Read
  • 协同处理器(Coprocessor)


1、数据的读取

1.1、ReadIndex Read

例如此时要读取 key =1 的内容，它不能直接去kv中读取，因为它是分布式的，它经过TiDB Server 收到读取请求，然后到PD 当中，找到这个key = 1 再哪个region，在哪个leader上，例如查到了在TiKV node 2上。 然后经过层层路径，终于到了rocksdb kv。 从这个TiDB Server 一直到kv 的数据返回，假设有50ms，则在这50ms 有可能会变更leader，（例如leader 热点平衡，将这个leader切换到其他节点）

006、体系结构之TiKV读取和Coprocessor_分布式数据库


如何保证数据返回过程中，节点不切换

读取的时候。leader会向其他flower发送心跳，告知我在读取的时候，就是读leader

006、体系结构之TiKV读取和Coprocessor_TiDB_02


006、体系结构之TiKV读取和Coprocessor_TiDB_03

1.2、Follower Read

也就是读取的数据，是最新提交的数据。

006、体系结构之TiKV读取和Coprocessor_分布式数据库_04


注意一点：现在不考虑MVCC 读旧版本数据的情况。

读肯定是需要提交完成之后(1-95). 由于raft log 都是排好序的，读取的动作是在 raft 提交动作之后，它肯定是大于(1_95) 当前的raft_log (1_97) 一定实在之后，这这个1_97就是ReadIndex .这个值就会记录下来。

简而言之，事务开始时间能读取的内容，是已经提交的数据。

006、体系结构之TiKV读取和Coprocessor_TiDB_05


006、体系结构之TiKV读取和Coprocessor_数据_06


006、体系结构之TiKV读取和Coprocessor_分布式数据库_07


006、体系结构之TiKV读取和Coprocessor_分布式数据库_08

协同处理器(Coprocessor)

006、体系结构之TiKV读取和Coprocessor_数据库_09


问题1： region散落在不同节点，大量数据需要通过网络汇聚到TiDB上，TiKV上都要返回到TiDB网络开销太大。问题2：所有计算都需要在TiDB上操作，CPU消耗太大

006、体系结构之TiKV读取和Coprocessor_TiDB_10


006、体系结构之TiKV读取和Coprocessor_分布式数据库_11


006、体系结构之TiKV读取和Coprocessor_tidb_12


Coprocessor： 作用将计算下推到TiKV上。