文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

不要分库分表了,快试试 TiDB 吧,兼容MySQL,1500 家企业都在用

2024-11-30 02:38

关注

为什么不建议分库分表呢?

分库分表以后,会面临以下问题

以上只是列举了一部分问题,为了避免这些问题,可以使用分布式数据库TiDB来处理

TiDB介绍

TiDB 是 PingCAP 公司研发的一款开源分布式关系型数据库,从 2015年 9 月开源,至今已经有9 年时间,可以说已经非常成熟,它是一款同时支持OLTP(在线事务处理)和OLAP(在线分析处理)的融合型分布式数据库产品,具备水平扩缩容,金融级高可用、实时 HTAP(Hybrid Transactional and Analytical Processing)、云原生的分布式数据库,兼容 MySQL 5.7 协议和 MySQL 生态等重要特性,它适合高可用、强一致要求较高、数据规模较大等各种应用场景。

核心特性

应用场景

案例

TiDB 有1500 多家不同行业的企业应用在了生产环境,以下是一些有代表性企业,要想查看更多案例,可以访问TiDB 官网查询

图片

系统架构

图片

TIDB Server

SQL 层,对外暴露 MySQL 协议的连接 endpoint,负责接收SQL请求,处理SQL相关的逻辑,并通过PD找到存储计算所需数据的TiKV地址,与TiKV交互获取数据,最终返回结果。TiDB Server 是无状态的,其本身并不存储数据,只负责计算,可以无限水平扩展,可以通过负载均衡组件(LVS、HAProxy或F5)对外提供统一的接入地址,客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。

PD Server

整个集群的管理模块,其主要工作有三个:

  1. 存储集群的元信息(某个Key存储在那个TiKV节点);
  2. 对TiKV集群进行调度和负载均衡、Leader选举;
  3. 分配全局唯一且递增的事务ID。

PD 是一个集群,需要部署奇数个节点,一般线上推荐至少部署3个节点。PD在选举的过程中无法对外提供服务,这个时间大约是3秒。

TIKV Server

图片

TiDB 现在同时支持OLTP 和 OLAP,而TiKV负责存储OLTP数据,从外部看TiKV是一个分布式的提供事务的Key-Value存储引擎。存储数据的基本单位是Region,每个Region负责存储一个Key Range(从StartKey到EndKey的左闭右开区间)的数据,每个TiKV节点会负责多个Region。

TiKV如何做到数据不丢失?

图片

简单理解,就是把数据复制到多台机器上,这样一个节点down 机,其他节点上的副本还能继续提供服务;复杂理解,需要这个数据可靠并且高效复制到其他节点,并且能处理副本失效的情况,那怎么做呢,就是使用 Raft一致性算法

Region 与副本之间通过 Raft 协议来维持数据一致性,任何写请求都只能在 Leader 上写入,并且需要写入多数副本后(默认配置为 3 副本,即所有请求必须至少写入两个副本成功)才会返回客户端写入成功。

分布式事务支持

TiKV 支持分布式事务,我们可以一次性写入多个 key-value 而不必关心这些 key-value 是否处于同一个数据切片 (Region) 上,TiKV 的分布式事务参考了Google 在 BigTable 中使用的事务模型Percolator,具体可以访问论文了解

与MySQL的对比

支持的特性

不支持的功能特性

资源使用情况

以下内容参考:https://pingcap.medium.com/an-8x-system-performance-boost-why-we-migrated-from-mysql-to-a-newsql-database-a42570ab765a

TiDB 具有很高的数据压缩比,MySQL 中的 10.8 TB 数据在 TiDB 中变成了 3.2 TB,还是三副本的总数据量。因此,MySQL 与 TiDB 的空间使用比例为 3.4:1。

图片

同等量级,使用2 年以后,资源使用情况

图片

图片

性能测试

测试报告 1

来源:https://www.percona.com/blog/a-quick-look-into-tidb-performance-on-a-single-server/

五个 ecs 实例,使用了不同配置,以此测试

MySQL 中的数据库大小为 70Gb,TiDB 中的数据库大小为 30Gb(压缩)。该表没有二级索引(主键除外)。

测试用例

  1. 简单计数(*):
select count(*) from ontime;
  1. 简单分组依据
select count(*), year from ontime group by year order by year;
  1. 用于全表扫描的复杂过滤器
select * from ontime where UniqueCarrier = 'DL' and TailNum = 'N317NB' and FlightNum = '2' and Origin = 'JFK' and Dest = 'FLL' limit 10;
  1. 复杂的分组依据和排序依据查询
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)(内存限制:无磁盘读取)。结果在这里。条形代表每秒的交易数量,越多越好:

图片

系统测试报告 2

来源:https://www.dcits.com/show-269-4103-1.html

硬件配置

图片

图片

测试场景

图片

测试分两阶段进行,第一阶段测试数据为100万单,第二阶段测试数据为1300万单。在此基础上,使用Jmeter压力测试10万单结果如下:

图片

图片

从测试结果来看,在小数据量mysql性能是好于TiDB,因为 TiDB 是分布式架构,如果小数据量,在网络通讯节点分发一致性等方面花的时间就很多,然后各个节点执行完还要汇总返回,所以开销是比较大的,但是数据量一上来TiDB 优势就体现出来了,因此数据量比较小,没必要使用 TiDB

总结

以上介绍了 TiDB架构,以及它的一些特性,同时也与 mysql 进行了对比,如果贵司的数据量比较大,正在考虑要分库分表,那么完全可以使用它,来避免分库分表,分库分表是一个过渡方案,使用分布式数据库才是终极方案。

来源:架构成长指南内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯