企业网站.net,网站设计的企业,苏州旅游攻略,html网页设计代码作业正能量文章目录 1 TiDB1.1 引言1.2 TiDB介绍1.3 系统架构1.3.1 TIDB Server1.3.2 PD Server1.3.3 TIKV Server1.3.4 TiKV如何不丢失数据1.3.5 分布式事务支持 1.4 与MySQL的对比1.5 性能测试1.5.1 测试一1.5.2 系统测试报告 2 1 TiDB
1.1 引言
当我们使用 Mysql 数据库到达一定量级… 文章目录 1 TiDB1.1 引言1.2 TiDB介绍1.3 系统架构1.3.1 TIDB Server1.3.2 PD Server1.3.3 TIKV Server1.3.4 TiKV如何不丢失数据1.3.5 分布式事务支持 1.4 与MySQL的对比1.5 性能测试1.5.1 测试一1.5.2 系统测试报告 2 1 TiDB
1.1 引言
当我们使用 Mysql 数据库到达一定量级以后性能就会逐步下降而解决此类问题常用的手段就是引入数据库中间件进行分库分表处理比如使用 Mycat、ShadingShpere、tddl但是这种都是过去式了现在使用分布式数据库可以避免分库分表 点击了解数据库之Sharding分库分表操作详解
那么为什么不建议分库分表呢分库分表以后会面临以下问题
分页问题例如使用传统写法随着页数过大性能会急剧下降分布式事务问题数据迁移问题例如需要把现有数据通过分配算法导入到所有的分库中数据扩容问题分库分表的数据总有一天也会到达极限需要增大分片开发模式变化比如在请求数据时需要带分片键否则就会导致所有节点执行跨库跨表查询问题业务需要进行一定取舍由于分库分表的局限性有些场景下需要业务进行取舍
以上只是列举了一部分问题为了避免这些问题可以使用分布式数据库TiDB来处理
1.2 TiDB介绍
TiDB 是 PingCAP 公司研发的一款开源分布式关系型数据库从 2015年 9 月开源至今已经有9 年时间可以说已经非常成熟它是一款同时支持OLTP在线事务处理和OLAP在线分析处理的融合型分布式数据库产品具备水平扩缩容金融级高可用、实时 HTAPHybrid Transactional and Analytical Processing、云原生的分布式数据库兼容 MySQL 5.7 协议和 MySQL 生态等重要特性它适合高可用、强一致要求较高、数据规模较大等各种应用场景。
核心特性
金融级高可用在线水平扩容或者缩容并且存算分离云原生的分布式数据库支持部署在公有云私有云混合云中实时HTAP提供TIKV行存储引擎和TiFlash列存储引擎兼容MySQL协议和MySQL生态分布式事务强一致性从 MySQL 无缝切换到 TiDB几乎无需修改代码迁移成本极低PD在分布式理论CAP方面满足CP是强一致性的
应用场景
对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景对存储容量、可扩展性、并发要求较高的海量数据及高并发的OLTP场景数据汇聚、二次加工处理的场景
1.3 系统架构 1.3.1 TIDB Server
SQL 层对外暴露 MySQL 协议的连接 endpoint负责接收SQL请求处理SQL相关的逻辑并通过PD找到存储计算所需数据的TiKV地址与TiKV交互获取数据最终返回结果。TiDB Server 是无状态的其本身并不存储数据只负责计算可以无限水平扩展可以通过负载均衡组件LVS、HAProxy或F5对外提供统一的接入地址客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。
1.3.2 PD Server
整个集群的管理模块其主要工作有三个
存储集群的元信息某个Key存储在哪个TiKV节点对TiKV集群进行调度和负载均衡、Leader选举分配全局唯一且递增的事务ID。
PD 是一个集群需要部署奇数个节点一般线上推荐至少部署3个节点。PD在选举的过程中无法对外提供服务这个时间大约是3秒。
1.3.3 TIKV Server TiDB 现在同时支持OLTP 和 OLAP而TiKV负责存储OLTP数据从外部看TiKV是一个分布式的提供事务的Key-Value存储引擎。存储数据的基本单位是Region每个Region负责存储一个Key Range从StartKey到EndKey的左闭右开区间的数据每个TiKV节点会负责多个Region。
1.3.4 TiKV如何不丢失数据 简单理解就是把数据复制到多台机器上这样一个节点down 机其他节点上的副本还能继续提供服务复杂理解需要这个数据可靠并且高效复制到其他节点并且能处理副本失效的情况那怎么做呢就是使用 Raft一致性算法
Region 与副本之间通过 Raft 协议来维持数据一致性任何写请求都只能在 Leader 上写入并且需要写入多数副本后默认配置为 3 副本即所有请求必须至少写入两个副本成功才会返回客户端写入成功。
1.3.5 分布式事务支持
TiKV 支持分布式事务我们可以一次性写入多个 key-value 而不必关心这些 key-value 是否处于同一个数据切片 (Region) 上TiKV 的分布式事务参考了Google 在 BigTable 中使用的事务模型Percolator
1.4 与MySQL的对比
支持的特性
支持分布式事务原理是基于Google PercolatorPercolator是基于Bigtable的所以数据结构直接使用了Bigtable的Tablet。支持锁TIDB是乐观锁 MVCC MySQL是悲观锁MVCC要注意TIDB执行Update、Insert、Delete时不会检查冲突只有在提交时才会检查写写冲突所以在业务端执行SQL语句后要注意检查返回值即使执行没有出错提交的时候也可能出错。
不支持的功能特性
不支持存储过程、函数、触发器自增id只支持在单个TIDB Server的自增不支持多个TIDB Server的自增。外键约束临时表Mysql追踪优化器XA 语法TiDB 内部使用两阶段提交但并没有通过 SQL 接口公开
资源使用情况 TiDB 具有很高的数据压缩比MySQL 中的 10.8 TB 数据在 TiDB 中变成了 3.2 TB还是三副本的总数据量。因此MySQL 与 TiDB 的空间使用比例为 3.4:1。 同等量级使用2 年以后资源使用情况 MySQL使用32 个节点而 TiDB 只有 14 个 MySql 用了 512 个 CPU 核心而 TiDB 将仅使用 224 个不到 MySQL 的一半。 MySQL 使用 48 TB 存储空间而 TiDB 将使用 16 TB仅为 MySQL 的 1/3。 1.5 性能测试
1.5.1 测试一
五个 ecs 实例使用了不同配置以此测试
t2.medium2 个 CPU 核心x1e.xlarge4 个 CPU 核心r4.4xlarge16 个 CPU 核心m4.16xlarge64 个 CPU 核心m5.24xlarge96 个 CPU 核心
MySQL 中的数据库大小为 70GbTiDB 中的数据库大小为 30Gb压缩。该表没有二级索引主键除外。
测试用例
简单计数 select count(*) from ontime;简单分组依据select count(*), year from ontime group by year order by year;用于全表扫描的复杂过滤器select * from ontime where UniqueCarrier DL and TailNum N317NB and FlightNum 2 and Origin JFK and Dest FLL limit 10;复杂的分组依据和排序依据查询
select SQL_CALC_FOUND_ROWS
FlightDate, UniqueCarrier as carrier,
FlightNum,
Origin,
Dest
FROM ontime
WHERE
DestState not in (AK, HI, PR, VI)
and OriginState not in (AK, HI, PR, VI)
and flightdate 2015-01-01
and ArrDelay 15
and cancelled 0 and Diverted 0
and DivAirportLandings 0
ORDER by DepDelay DESC
LIMIT 10;下图表示结果条形表示查询响应时间越小越好
系统基准测试 在 m4.16xlarge 实例上使用 Sysbench 进行点选择意味着通过主键选择一行线程范围从 1 到 128内存限制无磁盘读取。结果在这里。条形代表每秒的交易数量越多越好 1.5.2 系统测试报告 2
硬件配置
测试场景
测试分两阶段进行第一阶段测试数据为100万单第二阶段测试数据为1300万单。在此基础上使用Jmeter压力测试10万单结果如下 从测试结果来看在小数据量mysql性能是好于TiDB因为 TiDB 是分布式架构如果小数据量在网络通讯节点分发一致性等方面花的时间就很多然后各个节点执行完还要汇总返回所以开销是比较大的但是数据量一上来TiDB 优势就体现出来了因此数据量比较小没必要使用 TiDB
