TiDB数据库是PingCAP开发一款国产开源数据库，活跃度比较高。TiDB的组件主要有：

• PD Server：Placement Driver Server，是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。
• TiDB Server：负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。
• TiKV：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，以 Region 为单位。TiKV底层使用RocksDB存储数据。
• TiSpark：解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。
• TiFlash：是一个解决 HTAP 需求的产品，可和TiKV实现存储分离，即存储2份数据。TiFlash用于分析，TiKV用于事务。列存副本通过 Raft Learner 协议异步复制，但是在读取的时候通过 Raft 校对索引配合 MVCC 的方式获得 Snapshot Isolation 的一致性隔离级别。这个架构很好地解决了 HTAP 场景的隔离性以及列存同步的问题。TiFlash 可以兼容 TiDB 与 TiSpark，用户可以选择使用不同的计算引擎。
  TiFlash 提供与 TiKV 一样的快照隔离支持，且保证读取数据最新（确保之前写入的数据能被读取）。这个一致性是通过对数据进行复制进度校验做到的。每次收到读取请求，TiFlash 中的 Region 副本会向 Leader 副本发起进度校对（一个非常轻的 RPC 请求），只有当进度确保至少所包含读取请求时间戳所覆盖的数据之后才响应读取。
• TiDB Operator：提供在主流云基础设施（Kubernetes）上部署管理 TiDB 集群的能力。它结合云原生社区的容器编排最佳实践与 TiDB 的专业运维知识，集成一键部署、多集群混部、自动运维、故障自愈等能力，极大地降低了用户使用和管理 TiDB 的门槛与成本。

TiDB的优点主要有：

1. 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容。
2. 兼容MySQL的OLTP场景，能解决80%左右的OLAP场景，超大表的Join性能不太好，可借助TiSpark。
3. 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL。
4. 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明。
5. 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账。
6. 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景。

TiDB的缺点主要有：

1. 存储成本高：由于 TiDB 采用分布式架构，需要多个节点进行数据存储和计算，同时实现高可用，需要数据副本。
2. 配置和调优复杂：配置和调优相对复杂，需要深入了解系统和硬件性能，以获得最佳的性能和稳定性。
3. 不适用于大规模数据仓库：设计目标是在线事务处理 (OLTP)，对于大规模数据仓库和复杂分析查询的性能可能不如专门的分析型数据库。