TiDB

PD

• 如何保证同一个 Region 的多个 Replica 分布在不同的节点上？更进一步，如果在一台机器上启动多个 TiKV 实例，会有什么问题？

• TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？

• 添加一个节点进入 TiKV 集群之后，如何将集群中其他节点上的数据搬过来?

• 当一个节点掉线时，会出现什么问题？整个集群需要做什么事情？如果节点只是短暂掉线（重启服务），那么如何处理？如果节点是长时间掉线（磁盘故障，数据全部丢失），需要如何处理？

• 假设集群需要每个 Raft Group 有 N 个副本，那么对于单个 Raft Group 来说，Replica 数量可能会不够多（例如节点掉线，失去副本），也可能会过于多（例如掉线的节点又回复正常，自动加入集群）。那么如何调节 Replica 个数？

• 读/写都是通过 Leader 进行，如果 Leader 只集中在少量节点上，会对集群有什么影响？

• 并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，这个时候我们需要做什么？

• 集群在做负载均衡的时候，往往需要搬迁数据，这种数据的迁移会不会占用大量的网络带宽、磁盘 IO 以及 CPU？进而影响在线服务？

• 作为一个分布式高可用存储系统，必须满足的需求，包括四种：

  • 副本数量不能多也不能少
  • 副本需要分布在不同的机器上
  • 新加节点后，可以将其他节点上的副本迁移过来
  • 节点下线后，需要将该节点的数据迁移走
  • 整个系统将具备多副本容错、动态扩容/缩容、容忍节点掉线以及自动错误恢复的功能。

• 作为一个良好的分布式系统，需要优化的地方，包括：

  • 维持整个集群的 Leader 分布均匀
  • 维持每个节点的储存容量均匀
  • 维持访问热点分布均匀
  • 控制 Balance 的速度，避免影响在线服务
  • 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点
  • 使得整体系统的负载更加均匀、且可以方便的管理。

分布式 SQL 运算

1. 在扫描数据的时候，每一行都要通过 KV 操作同 TiKV 中读取出来，至少有一次 RPC 开销，如果需要扫描的数据很多，那么这个开销会非常大
2. 并不是所有的行都有用，如果不满足条件，其实可以不读取出来
3. 符合要求的行的值并没有什么意义，实际上这里只需要有几行数据这个信息就行
   如何避免上述缺陷也是显而易见的，首先我们需要将计算尽量靠近存储节点，以避免大量的 RPC 调用。其次，我们需要将 Filter 也下推到存储节点进行计算，这样只需要返回有效的行，避免无意义的网络传输。最后，我们可以将聚合函数、GroupBy 也下推到存储节点，进行预聚合，每个节点只需要返回一个 Count 值即可，再由 tidb-server 将 Count 值 Sum 起来。

NewSQL

Sharding

但是 sharding 之后会损失，比如说你不能跨节点做 Join，没有跨节点事务等

Links

• Bitcask