一、简介
1.1、五大核心特性
1.2、四大核心应用场景
1.3、TiDB适用和不适用场景
1.4、关于 PingCAP
1.5、TiDB怎么来的?
1.6、分布式数据库使用背景
1.7、OLTP和OLAP区别
1.7.1、OLTP
1.7.2、OLAP
二、TiDB 整体架构
三、FAQ
3.1、TiDB 是什么?
3.2、TiDB 是基于 MySQL 开发的吗?
3.3、TiDB、TiKV、Placement Driver (PD) 主要作用?
3.4、TiDB 易用性如何?
3.5、TiDB 和 MySQL 兼容性如何?
3.6、TiDB 支持分布式事务吗?
3.7、TiDB 支持哪些编程语言?
3.8、TiDB 是否支持其他存储引擎?
3.9、TiDB 用户名长度限制?
3.10、TiDB 是否支持 XA?
四、版本发布
TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP)的融合型分布式数据库产品,具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
TiDB 是 PingCAP 公司基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库。TiDB 具备如下 NewSQL 核心特性:
TiDB 对业务没有任何侵入性,能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题,专注于业务开发,极大的提升研发的生产力。
TiDB is an open source distributed HTAP database compatible with the MySQL protocol。
官网:https://pingcap.com/ GitHub:https://github.com/pingcap 社区版下载:https://pingcap.com/download-cn/community/ 文档:https://docs.pingcap.com/zh/tidb/stable
TiDB 的典型的应用场景是: (1) 原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时,可以考虑使用 TiDB 无 缝替换 MySQL。TiDB 可以提供如下特性:
(2) 大数据量下,MySQL 复杂查询很慢。 (3) 大数据量下,数据增长很快,接近单机处理的极限,不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案。 (4) 大数据量下,有高并发实时写入、实时查询、实时统计分析的需求。 (5) 有分布式事务、多数据中心的数据 100% 强一致性、auto-failover 的高可用的需求。
TiDB 不适合的场景: (1) 单机 MySQL 能满足的场景也用不到 TiDB。 (2) 数据条数少于 5000w 的场景下通常用不到 TiDB,TiDB 是为大规模的数据场景设计的。 (3)如果你的应用数据量小(所有数据千万级别行以下),且没有高可用、强一致性或者多数据中心复制等要求,那么就不适合使用 TiDB。
大家要注意,目前TiDB还不是一个SQL功能像传统数据库一样完备的数据库,他也不是解决所有问题的灵丹妙药。要结合你的应用情况,对于新开发的面向互联网业务的应用场景可能是比较合适的;对于已有应用系统的数据库迁移到TiDB这类情况,可能会涉及到应用改造,需要综合评估考虑。
PingCAP 成立于 2015 年,是一家企业级开源分布式数据库厂商,提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务,致力于为全球行业用户提供稳定高效、安全可靠、开放兼容的新型数据基础设施,解放企业生产力,加速企业数字化转型升级。 TiDB 作为通用分布式数据库,已被全球超过 1500 家企业用于线上生产环境,包括中国银行、光大银行、浦发银行、浙商银行、北京银行、微众银行、亿联银行、百信银行、中国银联、中国人寿、平安人寿、平安财险、国泰君安、华泰证券、陆金所、马上消费、拉卡拉、中国移动、中国联通、中国电信、新华财经、人民在线、吉林祥云、中体骏彩、国家电网、新奥燃气、北大人民医院、北京友谊医院、格力电器、理想汽车、小鹏汽车、VIVO、OPPO、麦当劳、百胜中国、中国邮政、顺丰速运、中通快递、腾讯、美团、京东、拼多多、小米、新浪微博、58同城、360、知乎、爱奇艺、哔哩哔哩、喜马拉雅、新东方、伴鱼、小红书、汽车之家、网易游戏、盖娅互娱、游族网络、Square(美国)、PayPay(日本)、Dailymotion(法国)、Shopee(新加坡)、ZaloPay(越南)、BookMyShow(印度)等,涉及金融、电信、政府、能源、公共事业、高端制造、高科技、新零售、物流、互联网、游戏等多个行业。
PingCAP 是国内开源的新型分布式数据库公司,秉承开源是基础软件的未来这一理念,PingCAP 持续扩大社区影响力,致力于前沿技术领域的创新实现。其研发的分布式关系型数据库 TiDB 项目,具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性,是大数据时代理想的数据库集群和云数据库解决方案。目前准生产测试用户 1000 余家,并已被 200 余家不同行业的领先企业应用在实际生产环境,涉及互联网、游戏、金融、政府、电信、制造业等多个领域。
著名的开源分布式缓存服务 Codis 的作者,PingCAP联合创始人& CTO ,资深 infrastructure 工程师的黄东旭,擅长分布式存储系统的设计与实现,开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天,在数据库这片边界模糊且不确定地带,他还在努力寻找确定性的实践方向。
直到 2012 年底,他看到 Google 发布的两篇论文,如同棱镜般,折射出他自己内心微烁的光彩。这两篇论文描述了 Google 内部使用的一个海量关系型数据库 F1/Spanner ,解决了关系型数据库、弹性扩展以及全球分布的问题,并在生产中大规模使用。“如果这个能实现,对数据存储领域来说将是颠覆性的”,黄东旭为完美方案的出现而兴奋, PingCAP 的 TiDB 在此基础上诞生了。
随着互联网的飞速发展,业务量可能在短短的时间内爆发式地增长,对应的数据量可能快速地从几百 GB 涨到几百个 TB,传统的单机数据库提供的服务,在系统的可扩展性、性价比方面已经不再适用。比如MySQL数据库,缺点是没法做到水平扩展。MySQL 要想能做到水平扩展,唯一的方法就业务层的分库分表或者使用中间件等方案。但是,这些中间层方案也有很大局限性,执行计划不是最优,分布式事务,跨节点 join,扩容复杂等。
与传统的单机数据库相比,TiDB 具有以下优势:
在内核设计上,TiDB 分布式数据库将整体架构拆分成了多个模块,各模块之间互相通信,组成完整的 TiDB 系统。对应的架构图如下:
TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议,具有数据强一致的高可用特性,是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。
不是,虽然 TiDB 支持 MySQL 语法和协议,但是 TiDB 是由 PingCAP 团队完全自主开发的产品。
TiDB 使用起来很简单,可以将 TiDB 集群当成 MySQL 来用,你可以将 TiDB 用在任何以 MySQL 作为后台存储服务的应用中,并且基本上不需要修改应用代码,同时你可以用大部分流行的 MySQL 管理工具来管理 TiDB。
TiDB 目前还不支持触发器、存储过程、自定义函数、事件、外键,除此之外,TiDB 支持绝大部分 MySQL 5.7 的语法。
详情参见与 MySQL 兼容性对比。连接:https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility/
支持。无论是一个地方的几个节点,还是跨多个数据中心的多个节点,TiDB 均支持 ACID 分布式事务。
TiDB 事务模型灵感源自 Google Percolator 模型,主体是一个两阶段提交协议,并进行了一些实用的优化。该模型依赖于一个时间戳分配器,为每个事务分配单调递增的时间戳,这样就检测到事务冲突。在 TiDB 集群中,PD 承担时间戳分配器的角色。
只要支持 MySQL Client/Driver 的编程语言,都可以直接使用 TiDB。
是的,除了 TiKV 之外,TiDB 还支持一些流行的单机存储引擎,比如 GolevelDB、RocksDB、BoltDB 等。如果一个存储引擎是支持事务的 KV 引擎,并且能提供一个满足 TiDB 接口要求的 Client,即可接入 TiDB。
在 TiDB 中用户名最长为 32 字符。
虽然 TiDB 的 JDBC 驱动用的就是 MySQL JDBC(Connector / J),但是当使用 Atomikos 的时候,数据源要配置成类似这样的配置:type="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource"
。MySQL JDBC XADataSource 连接 TiDB 的模式目前是不支持的。MySQL JDBC 中配置好的 XADataSource 模式,只对 MySQL 数据库起作用(DML 去修改 redo 等)。
Atomikos 配好两个数据源后,JDBC 驱动都要设置成 XA 模式,然后 Atomikos 在操作 TM 和 RM(DB)的时候,会通过数据源的配置,发起带有 XA 指令到 JDBC 层,JDBC 层 XA 模式启用的情况下,会对 InnoDB(如果是 MySQL 的话)下发操作一连串 XA 逻辑的动作,包括 DML 去变更 redo log 等,就是两阶段递交的那些操作。TiDB 目前的引擎版本中,没有对上层应用层 JTA / XA 的支持,不解析这些 Atomikos 发过来的 XA 类型的操作。
MySQL 是单机数据库,只能通过 XA 来满足跨数据库事务,而 TiDB 本身就通过 Google 的 Percolator 事务模型支持分布式事务,性能稳定性比 XA 要高出很多,所以不会也不需要支持 XA。
2017 年 10 月 16 日,TiDB 发布 GA 版(TiDB 1.0)。该版本对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量的工作。
2019 年 1 月 3 日,TiDB 发布 2.0.11 版,TiDB Ansible 相应发布 2.0.11 版本。该版本在 2.0.10 版的基础上,对系统兼容性、稳定性做出了改进。
2020 年 5 月 28 日,TiDB 发布4.0.0版。
2021 年 04 月 07 日,TiDB 发布 5.0.0版,在5.0 版本中,专注于帮助企业基于 TiDB 数据库快速构建应用程序,使企业在构建过程中无需担心数据库的性能、性能抖动、安全、高可用、容灾、SQL 语句的性能问题排查等问题。
本文结束。
• 微信公众号:DB宝,作者:小麦苗 • 作者博客地址:http://blog.itpub.net/26736162/ • 作者微信:db_bao • 作者QQ:646634621,QQ群:230161599、618766405 • 提供Oracle OCP、OCM、高可用(rac+dg+ogg)和MySQL DBA培训 • 版权所有,欢迎分享本文,转载请保留出处 • 若有侵权请联系小麦苗删除