TiDBvsCockroachDB

CockroachDB

• 去中心化设计, 数据可以直接存放到本地磁盘
• 水平弹性扩容，可自动 Rebalancing
• 各个节点之间完全对等，前端可挂负载均衡
• 高可用遵循多数原则，默认数据保存三份副本(至少三台机器)，可以允许一台机器挂掉
• 一台机器挂掉后，会被标记成suspect，超过一定时间，将被标记成dead，此时会自动将其上面的副本转移到其它机器上去
• 默认三个副本，如果有两台机器同时挂掉(这个"同时"时间可以配置)，部分数据将不可用
• CockroachDB 部署简单，只需要一个二进制文件，内置完善的图形界面
• CockroachDB上层支持兼容PostgreSQL语法，下层调用分布式KV存储API

TiDB

• TiDB 是PingCAP国产企业设计开发的开源分布式关系型数据库，其设计思想源于google spanner
• TiDB 是中心化设计，其元数据信息存放在PD组建上
• TiDB 同时支持行存储引擎TiKV、列存储引擎TiFlash，提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)解决方案
• TiDB 兼容MySQL 5.7协议，支持mysql原生客户端、mysqldump、navicat等诸多mysql原生工具
• TiDB 支持一键水平扩容或者缩容
• TiDB 是存储与计算分离的架构，基于Raft协议保证强一致性，支持高可用，机房容灾

TiDB系统架构图

• TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件对外提供统一的接入地址

• PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。作为中心总控节点，PD 通过集成 etcd ，自动的支持 auto failover，无需担心单点故障问题。同时，PD 也通过 etcd 的 raft，保证了数据的强一致性，不用担心数据丢失的问题。

• TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。TiKV基于RocksDB开发，基于Raft强一致性协议保证高可用，默
  认三个副本，一个Leader，两个Follower

• TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

TiDB存储架构图

TiDB计算层架构图

引入TiDB调度节点能够解决的问题

• 如何保证同一个 Region 的多个 Replica 分布在不同的节点上？更进一步，如果在一台机器上启动多个 TiKV 实例，会有什么问题？
• TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？
• 添加一个节点进入 TiKV 集群之后，如何将集群中其他节点上的数据搬过来?
• 当一个节点掉线时，会出现什么问题？整个集群需要做什么事情？如果节点只是短暂掉线（重启服务），那么如何处理？如果节点是长时间掉线（磁盘故障，数据全部丢失），需要如何处理？
• 假设集群需要每个 Raft Group 有 N 个副本，那么对于单个 Raft Group 来说，Replica 数量可能会不够多（例如节点掉线，失去副本），也可能会过于多（例如掉线的节点又回复正常，自动加入集群）。那么如何调节 Replica 个数？
• 读/写都是通过 Leader 进行，如果 Leader 只集中在少量节点上，会对集群有什么影响？
• 并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，这个时候我们需要做什么？
• 集群在做负载均衡的时候，往往需要搬迁数据，这种数据的迁移会不会占用大量的网络带宽、磁盘 IO 以及 CPU？进而影响在线服务？

TiDB vs CockroachDB

表格对比

区别概览

• 两者均为开源分布式数据库，TiDB由于是国产，中文文档支持非常好
• TiDB目前不支持外键
• TiDB是MySQL协议兼容，CockroachDB是PostgreSQL语法兼容，明显TiDB对MySQL兼容更好
• CockroachDB部署极其简单，仅需单个二进制文件，因为部署简单，相应的扩所容、维护CockroachDB都比TiDB要简单
• TiDB可以通过TiSpark扩展支持OLAP场景，而CockroachDB官方说明，不建议用在OLAP场景下
• 两者均为CP系统，部分节点挂掉会短暂(几秒)影响可用性，不会影响一致性

参考资料

TiDB和CockroachDB同为Spanner/F1的开源实现，有哪些重大差异？
https://www.zhihu.com/question/60686555
https://rocksdb.org.cn/doc/getting-started.html
RocksDB是使用C++编写的嵌入式kv存储引擎，其键值均允许使用二进制流。由Facebook基于levelDB开发， 提供向后兼容的levelDB API。
RocksDB针对Flash存储进行优化，延迟极小。RocksDB使用LSM存储引擎，纯C++编写。
NewSQL TiDB vs CockroachDB
https://blog.csdn.net/vkingnew/article/details/88559050
CAP理论表明了对于一个分布式的系统在以下3种保证中同时实现超过两种是不可能的：
Consistency（一致性）
Availability（可用性）
Partition Tolerance（分区容错性）