0
0
0
0
博客/.../

MySQL数据库 VS TiDB 精华入门版-平凯数据库敏捷模式试用体验

 awker  发表于  2025-10-13

一、前言

1.1 行业介绍

城商行在数据库的选用上,正从过去依赖国外商业数据库(如Oracle、DB2)向国产化、分布式、多类型适配的方向快速演进,以满足数字化转型中对高并发、弹性扩展和数据安全的核心需求。

1.2 目前遇到的数据库挑战

金融业务对稳定性要求极高。因此,无论哪种国产信创数据库,无论是利用可高用架构,还是双中心双活架构,前提条件都是将故障恢复时间降至秒级,根本目标都是确保服务不中断,业务不中断。

城商银行将采用分步实施的策略,先在B类、C类系统上验证国产数据库的稳定性,再逐步推广至A类核心系统,稳健推进国产化替代。

另外,城商银行的非结构化数据量越来越大,这对管理也带来了新的挑战和机遇。伴随着无纸化业务的发展,需要管理的影像、文档等非结构化数据激增。能够统一存储结构化和非结构化数据,满足海量数据下的高并发、低延迟查询需求,也与日具增,这也将是国产数据库面临的一个重大挑战。

1.3 参加活动的原因

深入和解平凯数据库的产品功能,对数据库选型做出指导。

1.4 TiDB 平凯数据库敏捷模式的体验总结

平凯数据库的敏捷模式是一种轻量级部署方案,它以更低的成本和更简化的运维,享受到TiDB核心的分布式数据库能力。支持1个节点(单机) 或3个节点(集群) 部署,将TiDB、PD、TiKV等核心组件融合部署在一起。起步门槛极低,单机即可运行,资源需求小,成本可控。采用单机分布式一体架构,可随业务增长,一键平滑升级至标准分布式集群,无需业务改造,轻松应对从GB到PB级的数据增长,避免后续架构重构的烦恼。

1.5 TiDB 平凯数据库敏捷模式是否能应对该挑战

对于替换复杂且难以维护的MySQL分库分表架构,或者需要从Oracle等传统数据库进行国产化迁移,平凯数据库敏捷模式提供了一套简洁的解决方案和丰富的迁移工具链,降低技术门槛和周期,完全适应存量数据库向 Tidb 的迁移及使用。但是迁移后的性能及稳定性,尚需进一步验证。

二、使用 tiup 部署平凯数据库敏捷模式

2.1 环境准备

平凯数据库敏捷模式支持 1-3个节点 的部署方式,将TiDB、PD、TiKV等核心组件融合部署在一起,实现轻量级起步。

推荐配置

  • 操作系统:CentOS 7.6+、Rocky Linux 8.10+等主流Linux发行版
  • 硬件配置:8核CPU、16GB内存(最低要求)
  • 磁盘空间:至少40GB可用空间(建议分配更多)

2.2 操作系统配置

# 关闭防火墙
systemctl stop firewalld.service
systemctl disable firewalld.service

# 关闭SELinux
sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config
setenforce 0

# 创建专用用户和目录
useradd tidb
passwd tidb
mkdir /tidb-deploy
mkdir /tidb-data
chown -R tidb:tidb /tidb-deploy
chown -R tidb:tidb /tidb-data

2.3 配置 SSH 互信

su - tidb
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub 目标服务器IP

2.4 安装TiUP及依赖组件

2.4.1 解压软件包

unzip amd64.zip
cd amd64/
tar -xvf tidb-ee-server-v7.1.8-5.2-20250630-linux-amd64.tar.gz
tar -xvf tidb-ee-toolkit-v7.1.8-5.2-20250630-linux-amd64.tar.gz

2.4.2 部署 Tiup

# 执行本地安装脚本
sh tidb-ee-server-v7.1.8-5.2-20250630-linux-amd64/local_install.sh

# 配置环境变量
source /root/.bash_profile

# 复制密钥文件
cp -rp tidb-ee-server-v7.1.8-5.2-20250630-linux-amd64/keys/ ~/.tiup/

# 合并工具包镜像
tiup mirror merge tidb-ee-toolkit-v7.1.8-5.2-20250630-linux-amd64

2.4.3 编写集群拓扑文件

修改拓扑配置文件 topology.yaml

global:
  kind: fusion
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"
  
monitored:
  node_exporter_port: 9700
  blackbox_exporter_port: 9715

server_configs:
  pd:
    replication.max-replicas: 1
    replication.enable-placement-rules: false

tidb_servers:
  - host: 10.10.10.181

monitoring_servers:
  - host: 10.10.10.181

grafana_servers:
  - host: 10.10.10.181

2.4.3 部署和启动集群

tiup cluster deploy tidbx-test v7.1.8-5.2-20250630 ~/topology.yaml --user root -p
tiup cluster start tidbx-test --init

注意:启动时会生成随机密码,请妥善记录

2.4.4 检查集群状态

tiup cluster display tidbx-test

2.4.5 数据库连接测试

mysql -u root -h 10.10.10.181 -P 4000 -p

# 查看版本信息
select tidb_version()\G

# 检查存储状态
select STORE_ID,ADDRESS,STORE_STATE,STORE_STATE_NAME,CAPACITY,AVAILABLE,UPTIME 
from INFORMATION_SCHEMA.TIKV_STORE_STATUS

三、平凯数据库敏捷模式:对比 MySQL

对比维度 MySQL TiDB 敏捷模式
架构本质 传统单机/主从架构,计算与存储紧密耦合 原生分布式架构,计算与存储分离,支持弹性水平扩展
扩展方式 垂直扩展(Scale-Up)或复杂的分库分表 无感水平扩展(Scale-Out),通过增加节点实现
高可用性 依赖主从复制,故障切换可能丢数据,RTO分钟级 基于Raft协议多副本,自动故障转移,秒级恢复,数据零丢失
适用数据量 TB级以内,单表千万级以下表现良好 PB级,单表千万级以上优势明显
核心适用场景 低并发、简单查询、对瞬时响应要求高的OLTP 高并发复杂SQL大数据量、HTAP混合负载

3.1 简单查询与高并发写

  • 场景:一个用户登录系统,需要高频执行类似 SELECT * FROM users WHERE user_id = ? 的简单查询。或者是一个秒杀场景,需要瞬间处理大量库存更新(如 UPDATE stock SET quantity = quantity - 1 WHERE item_id = ?)。
  • 对比:在数据量不大、但并发极高的纯点查点写场景下,MySQL 的延迟可能更低。因为 TiDB 的分布式架构在处理这类请求时,需要经过额外的网络路由和协议解析,会引入微小的网络开销。而 MySQL 的架构相对简单,查询路径更短。

3.2 复杂查询与大数据量分析

  • 场景:涉及多张大表的关联查询和聚合操作。
  • 对比:在这种场景下,TiDB 的优势非常明显。测试表明,MySQL 中可能需要数百秒才能跑出的复杂报表 SQL,在 TiDB 中可以被下推到多个存储节点并行执行,性能可以提升至秒级,一个业务用例测试,Tidb整体性能提升了 8 倍。

3.3 数据压缩与存储成本

  • 场景:原有 MySQL 数据库的数据量已达 500GB,且存储成本随着数据膨胀快速上升。
  • 对比TiDB 在数据压缩方面表现卓越。将约 500GB 的 MySQL 数据迁移至 TiDB 敏捷模式并执行压缩后,磁盘空间占用降至约 180GB,压缩比接近 3:1。总体存储成本节省了 64%。

四、平凯数据库试用总结

总而言之,平凯数据库的敏捷模式可以理解为 TiDB 的“精华入门版”或“可成长型”部署方案。它成功地在低入门成本简易运维强大的可扩展性之间取得了出色平衡。

使用平凯数据库敏捷模式,用户能够以低成本享受分布式数据库的核心能力,支持从GB 到 PB 级的数据扩展。这种部署方式特别适合中小规模数据量场景,为业务初期提供轻量级起步方案,同时保留未来无缝升级到标准分布式集群的能力。

当业务面临大数据量(单表千万级乃至更多)、高并发读写(如秒杀、实时交易)、复杂查询分析的挑战时,TiDB 敏捷模式更能发挥其分布式架构的优势,请拥抱 TiDB 敏捷模式

它尤其适合:

  • 业务快速增长,希望避免未来复杂的分库分表带来的开发和运维负担。
  • 需要 HTAP 能力,希望在同一套数据库中同时进行在线事务处理和实时数据分析。
  • 对存储成本敏感,希望利用其高效压缩技术降低成本。

0
0
0
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论