分布式 NewSQL 对比

一、TiDB：

说明：

PingCAP 公司基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库。

 

开源分布式 NewSQL 关系型数据库 TiDB 是新一代开源分布式 NewSQL 数据库，模型受 Google Spanner / F1 论文的启发，实现了自动的水平伸缩，强一致性的分布式事务，基于 Raft 算法的多副本复制等重要 NewSQL 特性。TiDB 结合了 RDBMS 和 NoSQL 的优势，部署简单，在线弹性扩容和异步表结构变动不影响业务， 真正的异地多活及自动故障恢复保障数据安全，同时兼容 MySQL 协议，使迁移使用成本降到极低

 

特性：

SQL支持（TiDB 是 MySQL 兼容的） 水平弹性扩展（吞吐可线性扩展） 分布式事务 跨数据中心数据强一致性保证 故障自恢复的高可用 海量数据高并发实时写入与实时查询（HTAP 混合负载） TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析能够经过 TiSpark 项目来完成。

 

---

二、CockroachDB：

说明：

构建于事务处理及强一致性KV存储上的分布式SQL数据库，支持水平扩展、自动容错处理、强一致性事务，而且提供SQL接口用于数据处理，是Google Spanner/F1的开源实现。 CockroachDB适用于应用对数据要求精确、可靠、彻底正确的场景，支持自动复制、均匀分布、基于极小配置的数据恢复，可用于分布式的、可复制的联机事务处理（OLTP），多数据中心的部署，私有云的基础构建，它不适用于读少写多的场景，能够用内存数据库来代替，也不适用于复杂的join查询，重量级的数据分析及联机分析处理（OLAP）。

 

特性：

支持PostgreSQL

对标准SQL支持较完善

较稳定

 

---

TiDB和Cockroach之间存在一些关键差别。

1.用户界面和生态系统尽管TiDB和CockroachDB都支持SQL，但TiDB与MySQL协议兼容，而Cockroach选择PostgreSQL。您可使用任何MySQL客户端直接链接到TiDB服务器。

2.体系结构整个TiDB项目在逻辑上分为两部分：无状态SQL层（TiDB）和分布式存储层（TiKV）。因为TiDB创建在TiKV之上，开发人员能够根据本身的业务自由选择使用TiDB或TiKV。若是您只须要分布式键值数据库，则能够单独使用TiKV以得到更高的性能和更低的延迟。

总之，咱们的系统是高度分层和模块化的，而CockroachDB是一个P2P系统。咱们系统的设计致使咱们使用两种编程语言：Go for TiDB和Rust for TiKV以提升存储性能。

而且受益于高度分层的架构，咱们构建了另外一个项目[1]，以便在TiDB / TiKV之上运行Apache Spark来回答复杂的OLAP查询。它利用了Spark平台和分布式TiKV集群的优点。

3.事务模型尽管CockroachDB和TiDB都支持ACID事务，但TiDB使用了Google的Percolator引入的模型。该模型的关键特性是它须要一个独立的时间戳分配器。与Spanner同样，TiDB中的每一个事务都有一个时间戳来隔离不一样的事务。

CockroachDB使用的模型相似于Google在其论文中描述的TrueTime API。然而，与Google不一样，CockroachDB没有构建原子钟和GPS接收器来保持不一样数据中心的时间一致。相反，它使用NTP进行时钟同步，这致使了不肯定错误的问题。为了解决这个问题，CockroachDB采用了混合逻辑时钟（HLC）算法。

4.编程语言TiDB使用Go做为SQL层，使用Rust做为存储引擎层。因为Go具备垃圾收集器（GC）和运行时，咱们认为调整性能将花费咱们几天的时间。所以，咱们对TiKV使用Rust，一种静态语言。它的表现要好得多。CockroachDB只使用Go。

 

---

三、FoundationDB：

2018-4 从新开源，资料较少

根据FoundationDB的官方文档，FoundationDB有一系列的局限性：

1. 单个事务数据量不能超过10MB
2. 键的长度不能超过10KB, 值的长度不能超过100KB
3. 系统针对而且只针对SSD优化，使用传统HHD既不保证性能也不保证数据库可用性
4. FoundationDB对于须要读比较大的主键值范围的查询性能很差
5. 该系统没有实现任何的安全和权限管理，任何人均可以去读和写任意一个主键
6. 系统不支持长时间运行的事务 ，具体来讲，一个事务的第一个操做后超过5秒若是事务尚未结束，系统就会报错。
7. 系统只在＜500个Core的状况下仔细测过，有性能保证
8. 数据库的数据大小不能超过100TB
9. 系统对每一个分区都作3份拷贝，而不会自动对热点增长更多的拷贝，因此读的性能有上限。

 

---

四、商用NewSQL：

Spanner、F1：谷歌

OceanBase：阿里

TDSQL：腾讯

UDDB：UCloud

 

RadonDB：青云中间件

 

---

五、总结：

对比一番后，TiDB须要SSD及多台服务器，CockRoachDB 更友好，优先尝试。

---

2018-11-30 更新：

找到tidb的二进制文件，能够简单部署单机或集群版：

https://www.pkold.com/a/TiDB_Binary__bu_shu_fang_an_xiang_jie_(_bei_fen_)

 

因为cockroachDB支持的是postgreSQL，若是要承接mysql，须要修改为本，并且很差估算；

tidb则几乎彻底兼容mysql，承接mysql成本很是低，故对tidb进行了测试。

在一台服上分别启动mysql和tidb单机版集群，对其进行OLTP压力测试：

debian服务器一台（4核cpu+8G内存）

	QPS	TPS
MySQL	16000	800
TiDB	4100	200

可见单机状况下mysql的吞吐量比tidb高几倍，在集群状况下tidb表现会好点；

此处应该是没有配置ssd硬盘致使结果没有tidb官网所述好。

 

---

参考：

http://www.javashuo.com/article/p-rnfgjnxo-cg.html

https://blog.csdn.net/erlib/article/details/78442934

https://groups.google.com/forum/#!topic/tidb-user/k_nMQWPmK-Q

https://github.com/ixiongdi/NewSQLBenchmark

https://hn.svelte.technology/item/15499404