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(分区容错性)