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（分区容错性）

新一代数据库TiDB在美团的实践
https://tech.meituan.com/2018/11/22/mysql-pingcap-practice.html

https://blog.csdn.net/xys2015/article/details/114922443