TiDB和OceanBase功能比较

TiDB和OceanBase都是近几年流行度很高的国产数据库引擎，两者都是基于LSM tree的分布式数据库，有很多相同和不同点。这里针对我对两者的了解，简单介绍下两者的异同。

	TiDB	OceanBase
是否存算分离	存储计算分离；缺点是故障排查的方向和点太多，会加大排查的难度 tidb-pd-tikv各个组件（这也是存算分离存在的普遍问题）；优点是弹性扩缩容能力较强	存储计算一体；缺点是扩缩容需要同时涉及计算和存储，导致license费用增加
管控运维	tidb没有管控页面，一切操作需要黑屏命令行（tiup工具）	OCP作为OB的云管控，提供较为丰富的运维接口
监控告警	tidb除了第三方的prometheus和alert组件，又引入了自带的dashboard，监控类型较为丰富详细，但也比较杂乱	OCP也提供监控和告警功能
备份恢复	tidb物理备份使用tidb-tookit带的br工具,类似percona-toolkit的xtrabackup，可以进行表级、schema级、full的备份和恢复	OB备份的最低粒度为集群级，恢复最低粒度为租户级
容灾实现	使用TiCDC将binlog同步到容灾	使用类似oracle dataguard的方式，将容灾节点作为learner加入到pasxo组，不参与投票，只进行同步
支持语法	只支持MySQL语法和协议	支持MySQL语法和协议，支持oracle语法
迁移方式	可使用TiDB Data Migration从MySQL迁移到TiDB	使用OMS或者DATAX从oracle、MySQL迁移到OB
官方文档	tidb官网教材更详细，操作和运维文档更易操作，但不支持搜索	ob则是概念性介绍性文档较多，当然现在OB也在改进中，3.2的文档也是较为详细了
多数派协议	TiDB使用raft协议，类似的有etcd	OB使用paxos协议，类似的有mgr
region/partition分布	region是副本的最小粒度，大小为96M，大于的话会自动分裂，小于的话可能产生合并	partition是副本的最小粒度，使用分区策略，并引入表组（tablegroup）的概念，减少分布式事务
region/partition数量限制	由于TiKV上的region需要与PD心跳交互，消耗CPU，每个TiKV上region的数量建议不多于5w，超过建议扩容	OB的主备副本partition之间需要探测心跳，32C配置的主机，partition数不建议超过8w
存储容量	tidb由于rocksdb的空间放大效应和索引占用额外的空间，需要的存储容量为源库的2倍	ob使用压缩算法，能保证为源库的1/2以下
HTAP实现方式	tidb的HTAP的实现是引入列存的tiflash，tiflash是一个learner型的从副本，分析型sql会自动被识别并路由到tiflash，不会对tikv负载产生影响，且引入mpp加速分析	OB的HTAP是通过弱读实现的，hint或者jdbc加weak_read参数，obproxy路由读请求到从副本。但是OB的压缩存储属于行列混合模式，逻辑上仍然是一组行的数据存在微块里，但微块会按列对数据进行编码，编码后的定长数据存储在微块内部的列存区，部分变长数据还是按行存储在变长区。
region键/分区键的限制	tidb分区键必须是每个唯一键的一部分（分区表的每个唯一键，必须包含分区表达式中用到的所有列）	ob分区键必须是主键的一部分