TiDB 是一个分布式 NewSQL 数据库。支持水平扩展、高可用、ACID 事务、SQL 等特性。同时 TiDB 还支持 MySQL 语法和 MySQL 协议。
不是。虽然 TiDB 支持 MySQL 语法和协议,但是 TiDB 是由 PingCAP 团队完全自主开发的产品。
TiDB 是 SQL 层,主要负责 SQL 的解析、制定查询计划、生成执行器;TiKV 是分布式 Key-Value 存储引擎,用来存储真正的数据。简而言之,TiKV 是 TiDB 的存储引擎。
PD 是 TiDB 集群的管理组件,负责存储 TiKV 的元数据,同时也负责分配时间戳以及对 TiKV 做负载均衡调度。
是的,TiDB 用起来很简单。启动整套服务后,就可以将 TiDB 当做一个普通的 MySQL Server 来用,你可以将 TiDB 用在任何以 MySQL 作为后台存储服务的应用中,并且基本上不需要修改应用代码。同时你可以用大部分流行的 MySQL 管理工具来管理 TiDB。
原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时,可以考虑使用 TiDB 无缝替换 MySQL。TiDB 可以提供如下特性:
- 吞吐、存储和计算能力的水平扩展
- 水平伸缩时不停服务
- 强一致性
- 分布式 ACID 事务
如果你的应用数据量小 (所有数据千万级别行以下),且没有高可用、强一致性或者多数据中心复制等要求,那么就不适合使用 TiDB。
TiDB 遵循 MySQL 的权限管理体系,可以创建用户并授予权限。
在创建用户时,可以使用 MySQL 语法,如 "CREATE USER 'test'@'localhost' identified by '123';”,这样就添加了一个用户名为 test,密码为 123 的用户,这个用户只能从 localhost 登录。
在进行授权时,也可以使用 MySQL 语法,如 "GRANT SELECT ON . TO 'test'@'localhost';",将读权限授予 test 用户。
请注意,在创建用户和授权时,TiDB 有几个和 MySQL 有区别:
- 创建用户时,用户标识采用 user@hostname 这种语法,其中 hostname 支持精确匹配和全匹配,不支持前缀匹配,也就是只支持 "192.168.199.1" 以及 “%”,而不支持 “192.168.%”
- TiDB 支持对用户授权,这里只是支持授权语法,并且记录在系统表中。但是实际上只对 DropTable 语句进行权限检查,对其他的语句并不会做权限检查。实现用户授权主要是为了兼容已有的 MySQL 业务。
当您的业务不断增长时,数据库可能会面临三方面瓶颈,第一是存储资源不够,也就是磁盘空间不够;第二是计算资源不够用,如 CPU 占用较高, 第三是吞吐跟不上。这时可以对 TiDB 集群做水平扩展。
如果是存储资源不够,可以通过添加 TiKV Server 节点来解决。新节点启动后,PD 会自动将其他节点的部分数据迁移过去,无需人工介入。
如果是计算资源不够,可以查看 TiDB Server 和 TiKV Server 节点的 CPU 消耗情况,再考虑添加 TiDB Server 节点或者是 TiKV Server 节点来解决。如添加 TiDB Server 节点,将其配置在前端的 Load Balancer 之后即可。
如果是吞吐跟不上,一般可以考虑同时增加 TiDB Server 和 TiKV Server 节点。
高可用是 TiDB 的另一大特点,TiDB/TiKV/PD 这三个组件都能容忍部分实例失效,不影响整个集群的可用性。具体见 TiDB 高可用性
TiDB 使用 Raft 在多个副本之间做数据同步,从而保证数据的强一致。单个副本失效时,不影响数据的可靠性。
TiDB 支持 ACID 分布式事务。事务模型是以 Google 的 Percolator 模型为基础,并做了一些优化。这个模型需要一个时间戳分配器,分配唯一且递增的时间戳。在 TiDB 集群中,PD 承担时间戳分配器的角色。
可以用任何你喜欢的编程语言,只要该语言有 MySQL Client/Driver.
启动 TiDB Server 时,需要通过命令行参数设置 lease 参数(--lease=60),其值会影响 DDL 的速度(只会影响当前执行 DDL 的 session,其他的 session 不会受影响)。在测试阶段,lease 的值可以设为 1s,加快测试进度;在生产环境下,我们推荐这个值设为分钟级(一般可以设为 60),这样可以保证 DDL 操作的安全。
TiDB 实现了 Google F1 的在线 Schema 变更算法(具体参见 F1 论文 和我们的一篇 Blog)。 一般情况下,DDL 并不是一个频繁的操作,我们首先要保证的是数据的一致性以及线上业务不受影响。一个完整的 DDL 过程会有 2 到 5 个阶段(取决于语句类型),每个阶段至少会执行 2*lease 时间,假设 lease 设为 1分钟,对于 Drop Table 语句(需要两个阶段),会执行 2*2*1 = 4 分钟。除此之外,DDL 的时间还取决其他的条件,比如做 Add Index 操作时,表中已有的数据量是影响 DDL 时间的主要因素。我们也了解过 Google 内部在 F1 上是如何做 DDL,一般是提交给 DBA,DBA 再通过专用的工具执行,执行的时间会很长。
和这些数据库相比,TiDB 最大的特点是可以无限水平扩展,在此过程中不损失事务特性。
TiDB 在提供水平扩展特性的同时,还能提供 SQL 以及分布式事务。
TiDB 支持绝大多数 MySQL 语法,一般不需要修改代码。我们提供了一个检查工具,用于检查 MySQL 中的 Schema 是否和 TiDB 兼容。
是的。除了 TiKV 之外,TiDB 还支持一些流行的单机存储引擎,比如 GolevelDB, RocksDB, BoltDB 等。如果一个存储引擎是支持事务的 KV 引擎,并且能提供一个满足 TiDB 接口要求的 Client,即可接入 TiDB。