TiDB-vs-CockroachDB
作者：互联网
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
表格对比
| Name | CockroachDB | TiDB |
|---|---|---|
| Description | CockroachDB is a distributed database architected for modern cloud applications. It is wire compatible with PostgreSQL and backed by a Key-Value Store, which is either RocksDB or a purpose-built derivative, called Pebble. | TiDB is an open source distributed Hybrid Transactional/Analytical Processing (HTAP) database that supports MySQL and Spark SQL syntaxes. |
| Primary database model | Relational DBMS | Relational DBMS |
| Website | www.cockroachlabs.com | pingcap.com |
| Technical documentation | www.cockroachlabs.com/docs | docs.pingcap.com/tidb/stable |
| Developer | Cockroach Labs | PingCAP, Inc. |
| Initial release | 2015 | 2016 |
| Current release | 20.2, November 2020 | 4.0.10 , January 2021 |
| License | Open Source | Open Source |
| Cloud-based only | no | no |
| Implementation language | Go | Go, Rust |
| Server operating systems | Linux macOS Windows | Linux |
| Data scheme | dynamic schema | yes |
| Typing | yes | yes |
| XML support | no | no |
| Secondary indexes | yes | yes |
| SQL | yes, wire compatible with PostgreSQL | yes |
| APIs and other access methods | JDBC | JDBC ODBC Proprietary protocol |
| Supported programming languages | C# C++ Clojure Go Java JavaScript (Node.js) PHP Python Ruby Rust | Ada C C# C++ D Delphi Eiffel Erlang Haskell Java JavaScript (Node.js) Objective-C OCaml Perl PHP Python Ruby Scheme Tcl |
| Server-side scripts | no | no |
| Triggers | no | no |
| Partitioning methods | horizontal partitioning (by key range) | horizontal partitioning (by key range) |
| Replication methods | Multi-source replication using RAFT | Using Raft consensus algorithm to ensure data replication with strong consistency among multiple replicas. |
| MapReduce | no | yes |
| Consistency concepts | Immediate Consistency | Immediate Consistency |
| Foreign keys | yes | no |
| Transaction concepts | ACID | ACID |
| Concurrency | yes | yes |
| Durability | yes | yes |
| In-memory capabilities | no | no |
| User concepts | Role-based access control | Users with fine-grained authorization concept. No user groups or roles. |
区别概览
- 两者均为开源分布式数据库，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（分区容错性）
标签：存储,TiKV,vs,集群,TiDB,CockroachDB,节点 来源： https://blog.csdn.net/xys2015/article/details/114922443