对MongoDB和TiDB的系统比较

一、MongoDB

1、简介

MongoDB 是一个基于分布式文件存储的文档数据库，属于NoSQL数据库，是非关系数据库当中功能最丰富，最像关系数据库的。支持多种查询语言，支持对数据建立任何属性的索引，使用高效的二进制数据存储，自动处理碎片，高性能、易部署、易使用，存储数据非常方便。

2、设计与使用原理

“面向集合”和“模式自由”：

数据分组被储存在数据集中，称为而一个集合，每个集合都有一个唯一的标识名，并且可以包含无数数目的文档，集合类似于数据库的表，但不需要定义任何模式。储存在mongoDB内的文件，不需要知到它的任何结构定义，即可以把不同结构的文件存储在同一个数据库里。（即在存储的过程中存储的是文件，不需要计较存储的文件属于什么格式）

分布式文件系统：

文件系统管理的物理存储资源通过计算机网络与节点相连，可包括多个供多用户访问的服务器。是一个分布式、面向列的开源数据库，一个结构化数据的分布式存储系统，将服务器集群内所有节点上存储的文件统一管理和存储。

水平扩展，分片集群

Driver连接多个Mongos，Mongos连接多个Shard，每个Shard都是一个Primary和多个Secondary。（相互连接，呈下图方式水平分布）

3、优点和缺点

优点

（1）高可用，复制集，提供自动故障转移。

（2）数据格式自由，面向Collection和Document，以JSON格式保存数据， 支持二进制数据和大型对象。

（3）第三方支持丰富。开源的文档数据库MongoDB背后有商业公司为它提供商业培训和支持。

（4）充分利用计算机内存。对千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出，基于具有完整的索引支持，支持快速查询。

（5）强大的索引支持 地理位置索引可用于构建 各种 O2O 应用、文本索引解决搜索的需求、TTL索引解决历史数据自动过期的需求。

缺点

（1）mongoDB是Nosql，关系能力薄弱，不能用join、union进行来拟合查找。

（2）占用空间过大。空间的预分配，在空间不足时会申请生成大块的硬盘空间。

（3）没有MySQL那样成熟的维护工具，在开发过程中需要尤其注意。

（4）在集群分片中的数据分布不均匀，大数据量插入时，写入性能会有较大波动。

4、适用与不适用场景

适用场景

（1）网站实时数据处理。适合适时的插入、更新和查询，具备网站实时数据存储所需的可复制性与高度伸缩性。

（2）适合数十台或数百台组成的数据库，路线图已经包含对MaoReduce引擎的内置支持。

（3）适合对大尺寸、低价值数据的存储。

（4）地理位置信息存储，通过2d和2dsphere索引，可以方便的查询出具体的位置信息。

不适应场景

（1）高度事务性的系统。需要大量原子复杂事物的应用程序。

（2）涉及到SQL的问题。

5、选择标准

（1）新应用，需求会变，数据模型无法确定，想快速迭代开发，应用发展迅速，需要能快速水平扩展。

（2）需要TB甚至PB级别数据存储，并且要求存储的数据不丢失。

（3）需要大量的地理位置查询、文本查询。

二、TiDB

1、简介

TiDB是 PingCAP公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，支持高可用无限的水平扩展，具备强一致性和高可用性，兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。

2、设计与使用原理

高度兼容MySQL

大多数情况下(不兼容的情况在TiDB官网有明确标注），无需修改代码即可从 MySQL 轻松迁移至 TiDB，并且结构化的MySQL集群在后续可通过TiDB进行实时转移。

无限的水平扩展

通过简单地增加新节点即可实现 TiDB 的水平扩展（通过对TiDB数据库的部署），按需扩展吞吐或存储，能够应对在存储过程中的大数据问题。

整体架构

TiDB的水平扩展和高可用性特点取决于TiDB的整体架构。TiDB集群包主要包括的核心组件：TiDB Server，PD Server 和 TiKV Server，此外，还有解决用户复杂需求的TiSpark。

TiDB Server

SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB Server 是无状态的，实践可以启动多个TiDB实例，其本身并不存储数据，只负责计算，可以无限水平扩展，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。

PD Server

Placement Driver (简称 PD) ，是整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，是整个集群的”大脑“，PD 通过 Raft 协议保证数据的安全性。（根据实施状况分布TiKV节点，力求保障运行速度）

TiKV Server

TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。

TiSpark

TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。

3、对OLTP和OLAP的解析（两者对比来看）

OLTP

OLTP(Online Transactional Processing)，OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，对实时性要求高，数据量不大，面向操作人员，用于日常事物的操作和处理，对数据的读取量小，设计面向的是应用。

OLAP

OLAP(Online Analytical Processing) ,是数据仓库的核心部心，支持复杂的分析操作，侧重决策支持，在使用过程中能够提供直观的查询结果，对实时性要求不高，支持的是动态查询，对数据的处理量大，面向决策人员，用于分析决策，在设计上面向的是主题。

结论

OLTP在使用过程中，用户是低层的操作人员，用于对数据进行日常操作处理，OLAP在使用过程中，用户是高级的管理人员，用于在大方向上分析决策，OLTP和OLAP共同存在的价值在于能够更好地

4、TiDB的优缺点

优点

（1）高度兼容 MySQL，零成本迁移。

（2）水平弹性无限制扩展。

（3）故障自恢复及异地多活。TiDB 使用多副本进行数据存储，并依赖业界最先进的 Raft 多数派选举算法确保数据100% 强一致性和高可用。副本可跨地域部署在不同的数据中心，主副本故障时自动切换，无需人工介入，自动保障业务的连续性。更优的性能优势

（4）TiDB 根据存储、网络、距离等因素，动态进行负载均衡调整，以保证更优的读写性能。

缺点

（1）TiDB对生产环境硬件的要求还是蛮高的，对于存储节点来说，SSD 或者 NVMe 或者 Optane 是刚需，另外对 CPU 及内存的使用要求也很高。（在TiDB官网有最低的配置要求，如果达不到最低要求，根本无法实施部署）。
（2）作为一个分布式集群，TiDB 对时间的要求还是比较高的，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。2 块网卡可以做 bond，保证数据传输的稳定，只有万兆可以保证数据传输的速度。

5、适用场景与不适应场景

适用场景

（1）在适用MySQL的业务遇到单机容量或性能瓶颈。

（2）大数据量下，数据增长很快，接近单机处理的极限，不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案。

（3）有高并发实时写入、实时查询、实时统计分析的需求。

不适用场景

（1）单机MySQL能满足的场景。

（2）数据量少于5000w，没有高可用性、多数据中心复制要求的。

三、MongoDB和TiDB多方面对比

1、分片集群架构

在整体架构上，TiDB与MongoDB有很多相似之处，如TiDB Server和mongos，PD Server和config server，TiKV Server和replica set，Region和chunk，两个数据库的核心组件都有相互对应关系，存储格式与存储的数据的单位都有相互对应。（在核心特性上会一一介绍对应关系）

2、核心特性

水平扩展

TiDB与MongoDB相比，业务负载更均衡，数据存储的更均匀，不会出现一个节点负载过多而另一个节点几乎不负载的问题。

高可用

TiDB Server和mongos相比，TiDB至少需要部署两个实例，单个实例失效后，可重启或部署另外一个实例，而mongos通过Driver实现负载均衡，不需要单独部署负载均衡文件。

PD Server和config server相比，PD Server在Raft失效后，服务完全不受影响，如果使leader Raft，则会重新选举，选举过程的3s内不会提供服务，而config server的选主时间会超过10s。

TiKV Server和replica set相比，TiKV Server单个节点失效，会影响节点的所有Region，如果是leader节点，会中断服务，但在一段时间内无法恢复时，PD会将其上数据迁移到其他TiKV节点上，MongoDB分片集群的数据高可用依赖shard的配置，如果shard是单一的mongod进程，其上的数据都不可用或丢失，如果shard是复制集，则数据是安全的，但副本数会减少，需要人工处理故障节点。

3、选择

面对的问题：对百亿级甚至千亿级的小型文件存储情况

MongoDB是一个开源，高性能，无模式的文档型数据库，由于其本身文档型数据库的特性，其对文件独有的存储优点与特性：存储数据非常方便，存取速度快，方便对数据的存入与取出，决定了其对大尺寸、低价值数据的存储是TiDB比不了的，因此，对百亿级甚至千亿级的小型文件，用MongoDB存储更好。（不用担心数据会丢失这一问题，数据是否会丢失永远不是选择数据库的依据，并且MongoDB出现丢失数据情况可以人员操作找回）

档型数据库，由于其本身文档型数据库的特性，其对文件独有的存储优点与特性：存储数据非常方便，存取速度快，方便对数据的存入与取出，决定了其对大尺寸、低价值数据的存储是TiDB比不了的，因此，对百亿级甚至千亿级的小型文件，用MongoDB存储更好。（不用担心数据会丢失这一问题，数据是否会丢失永远不是选择数据库的依据，并且MongoDB出现丢失数据情况可以人员操作找回）

注：本文在MongoDB官网和TiDB官网查询资料，对比资料和询问数据库官方运营人员，旨在企业或者组织团队在使用数据库时能够更好地取舍。
如有侵权，请联系作者修改和删除。