架构师必看!现代应用架构发展趋势与数据库选型建议丨TiDB vs MySQL 专题(一)

导读

在当今数智化飞速发展的时代,现代应用架构正经历着一场深刻的变革。云原生、微服务、大数据等新兴技术与架构模式不断涌现,推动着应用向更高效、更灵活、更智能的方向演进。然而,数据量的爆发式增长、并发访问的急剧增加、多租户与混合负载的需求,以及企业对智能化运维和数据安全性的更高期望,都使得数据库在性能、扩展性、可靠性等方面面临严峻考验。 TiDB 作为分布式数据库,在高扩展性、高可用性、性能卓越等方面为现代应用架构提供了全新的解决方案。

本文将深入探讨现代应用架构的发展趋势,分析数据库的挑战与需求,并为架构师们提供数据库的选型建议,助力企业在数字化浪潮中稳健前行。

本文作者:蓝功儒 & 李仲舒 & 童童


现代应用架构的技术演变趋势:从 LAMP 到分布式智能化

随着互联网、移动互联网、AI 等技术的大爆发背景下,现代企业主要面临六大挑战:AI 驱动下数据量的爆炸性增长;对高并发和高吞吐需求的应对;高可用以及业务连续性保障;多租户和资源隔离能力实现降本增效;IT 架构向云方向的演进以及与云基础设施的无缝集成;现代应用架构下诸多技术挑战等。

现代应用架构在业务需求与技术进步双轮驱动下,依托于开源技术,经历了高速的发展,成熟度也在不断提升。回顾往昔,Linux、Apache、MySQL 以及 PHP 的简单组合(LAMP)曾是搭建应用网站的主流框架。而随着互联网、移动互联网用户规模的几何级膨胀、业务场景的复杂化,以及企业对系统性能、扩展性、稳定性要求的不断提高,传统的 LAMP 架构逐渐暴露出诸多瓶颈。为突破这些限制,无论是应用还是数据库都向着分布式的大方向演进。整体来看,现代应用技术整体向 分布式化、技术精细化、功能模块化、智能化、可视化、需求多样化 等方向演进。

现代应用架构下数据库演变趋势

数据库经过近 60 年的发展历程看,1980 年代的大型机占主导,关系型模型与 SQL 成为主流。1990 年代,随着互联网的快速发展,小型机兴起,开源数据库逐步兴起。2000 年代,互联网技术的推动下,数据量暴增,虚拟化技术、分布式崛起。2010 年代,移动互联网让联网人数又有了指数级的增长,驱动了大数据与云技术的发展,在此背景下,应用以及数据库又朝着云原生方向进一步发展。2020 年代,实时数据分析以及 AI 需求驱动下,应用以及数据库又有了进一步的迭代发展。

从全球数据库技术的发展趋势中,我们可以看到几个关键要素:

1. 数据库技术不断进步,进入多元化发展阶段

2. 分布式和云原生重新塑造数据库形态

3. 数据库技术与大数据应用深度融合发展

4. 存算分离已成为数据库发展的主流方向

5. HTAP 成为新的关注方向

天下合久必分,分久必合。从数据库发展趋势中,我们看到 原生分布式已经是数据库发展的主流方向、是新质生产力的代表、是防止技术断代的核心技术。分库分表模式是过渡性技术,集中式数据库会越来越边缘化 。我们也可以预测,数据库的技术栈将逐渐收敛,以此为企业提供扎实的数据底座、敏捷的开发体验、极简的技术栈,帮助企业应对现代企业的六大挑战。

现代应用架构下数据库演变趋势

MySQL 演变趋势

MySQL 的发展起步于 3.23 版本,当时崭露头角,以 MyISAM 作为存储引擎,完善了基础 SQL 功能,并支持多用户多线程处理。到了 4.0 版本,引入 InnoDB 引擎,构建起关系型事务模型,同时增加了存储过程和触发器等功能。5.7 版本则标志着 MySQL 迈向企业级应用,存储引擎变得可插拔,具备外键约束、主从复制以及分区表等特性。8.1 版本进一步提升,达到金融级标准,增强了安全性、数据分析能力、Cluster 能力和资源控制。最新的 9.1 版本构建起现代架构,引入 Vector 数据类型,更加面向云原生,并增强了可观测性。

我们可以看到,MySQL 产品及生态近几年主要是围绕着 云原生、HTAP、高可用、AI、可观测性、Resource Control、安全性 等方面进行迭代演进。

MySQL 数据库发展历程

  • 数据量承载: 早期,MySQL 主要以单体机架构运行,适用于 GB 级别的数据量。随着业务发展,数据量增长,开始采用分库分表的方式承载 PB 级数据。但这种方式带来了业务和运维的高复杂度,因此,许多企业选择切换到 TiDB 这种原生分布式数据库,它能在保证性能的同时,更便捷地处理大规模数据。
  • 云原生部署: MySQL 最初以单体机架构部署,后来发展到 RDS(关系型数据库服务)。随后,出现了以 Auraro、PolarDB 为代表的基于共享分布式存储的云原生架构。然而,这些架构在吞吐扩展和数据承载能力上存在局限。为满足更高需求,用户逐渐转向 TiDB Cloud,它们具备更强大的云原生能力,能更好地适应复杂多变的云计算环境。

MySQL 生态演进

现代应用架构下 MySQL 体系面临的七大挑战

1. 数据强一致: 读写分离架构或者分库分表架构的引入,数据的强一致性保障成为重点关注问题,保证强一致性便需极大的牺牲性能,这是 MySQL 体系一直以来困扰诸多 MySQL 使用者的问题。

2. 业务无侵入: 随着业务系统数据量的增长,早起只能无奈采取分库分表方案以及架构,这不单为运维带 来了极高的复杂度,同时对业务开发也带来的极大的入侵,SQL 只能限定按照 shard key 维度进行编写,无法任意维度的进行 SQL 查询,开发不得不牺牲业务需求,业务的发展也不得不受限,同时又需投入大量的高精尖人才进行开发维护。

3. TB~PB 级别数据承载能力: 随着互联网、移动互联网、AI 的爆发,各个企业的业务系统数据量都在向着 TB 级别、百 TB 级别,甚至我们发现也有很多用户数量在向着 PB 级别增长。这对数据库的承载能力提出了极高的挑战,不但需要承载大数据量,又需要保障业务读写性能的稳定性,而在数据的承载能力上,MySQL 的极限,是 TiDB 的起点。

4. 高吞吐能力 & 多点读写能力: 对于数据库多点读写是一个稀缺的能力,而基于 MySQL 二次开发的生态下的产品很难实现业务无侵入的需求下数据库的多点读写能力,以适应高吞吐场景。

5. 高可用: 尽管 MySQL 提供了多种高可用架构(如主从复制、主主复制、MHA、InnoDB Cluster 等),但这些方案仍存在一些不足,如配置复杂、运维困难、性能损耗、一致性保障困难等。

6. 横向扩展能力: MySQL 的读写分离架构提供了弱一致性读能力的扩展,分库分表架构必须成倍的扩容且需要业务停机,数据重分布又极其复杂,这对架构师、DBA、开发者都提供了极大的复杂度和挑战。

7. 复杂 SQL 查询能力强: MySQL 的复杂查询能力一直被大家所诟病,在 MySQL 的版本迭代中,我们也可以看到一直在做优化器的增强,提升 MySQL 对复杂 SQL 的处理能力,但相对 Oracle,目前仍存在一定差距。

现代应用架构新选择:原生分布式数据库,一键解决七大挑战

与传统的 MySQL 架构相比,原生分布式数据库凭借完全分布式架构、数据透明分布、原生高可用、数据强一致、HTAP 等能力特点,极大简化读写分离和分库分表的复杂度,减少了中间件的使用,大幅降低运维复杂性并提高了系统的稳定性和性能;具备为现代应用架构提供一个强大、灵活、高效、敏捷的数据底座能力。

用原生分布式数据库一栈式解决应用架构挑战

原生分布式数据库一站式应对:

1. 数据强一致: 原生分布式数据库采用多数派协议,默认的三副本配置,数据强一致同步,彻底的解决了数据强一致性的问题。

2. 业务无侵入: 在原生分布式数据库中,业务开发者完全回归 MySQL 单机开发体验,数据可以任意维度分析,无需牺牲任何也许需求或引入更多技术栈。

3. TB~PB 级别数据承载能力: 原生数据库凭借着细粒度的数据存储单位,强大的数据管理及调度能力,充分利用大数据下多点计算的能力,具备支撑PB级别数据量承载以及业务稳定性保障能力。

4. 高吞吐能力 & 多点读写能力: 对于数据库多点读写是一个稀缺的能力,采用存算分离的原生分布式数据库以更小的单位为存储单位,可充分发挥数据库多点读写能力,以适应高吞吐场景。尤其在 DTC 场景,如互联网、零售、公共事业这类直接面向最终用户的场景下,原生分布式数据库可以充分利用分布式的多点写入能力来满足业务极高吞吐的要求。

5. 高可用: 原生分布式数据库采用的多数派协议,原生具备故障自愈、故障转移、数据副本自动补充等能力,对用户提供了更友好更可靠的高可用能力。

6. 横向扩展能力: 原生分布式数据库可按需针对计算或存储去扩容,且可随意数量的扩展,比如一次只扩展一个 8c16G 配置的存储实例。一行命令完成扩展,无需任何的人工干预。

7. 复杂 SQL 查询能力强: 原生分布式数据库充分利用分布式的架构以及能力,将行列双引擎物理隔离,列引擎具备 MPP 计算能力,让数据库拥有了接近传统 OLAP 数据库的复杂 SQL 处理效率和能力。

现代应用架构的数据库选型建议

(一)企业实力

1. 代码自主可控率: 核心自主可控率,生态工具自主可控率,是否能真正掌握产品核心代码

2. 企业资本规模: 企业的资产规模,企业的背景

3. 研发力量投入: 研发实力,数据库产品投入力度

4. 原厂工程师数量: 原厂售前售后工程师数量

(二)市场认可

1. 产品下载量、装机量、市场关注度

2. 同业案例: 同业核心系统案例数量,市场认可度

3. 同业调研: 同业一般系统案例数量,同业调研认可度

4. 三方评估: 权威的评估机构,中立的第三方评估网站

5. 在行业内横向对比情况做参考

(三)生态环境

1. 工具完善性: 监控巡检工具的关键指标完善性,数据迁移工具、数据同步工具支持情况

2. 文档完善性: 官方文档准确性、完普性,问题知识库的完备性

3. 认证完善性: 培训体系的完整性,获得证书人员的数量

4. 软硬件兼容性: 支 持国产操作系统数量,支持国产芯片服务器数量

5. 备份恢复的便捷性,安装部署的方便性

6. 社区支持: 是否自己构建开源社区,是否与国内外开源社区合作

7. 社区活跃度: 社区注册人数,企业数量等

(四)产品实力

1. 架构先进性: 可靠性、可用性、可横向扩展性、云原生,多地多中心架构支持情况

2. 语法兼容性: 兼容 MySQL、PostgreSQL、Oracle 语法其中一种或多种语法

3. 采购维保成本: 软件 License 成本,每年维保服务成本相同架构基础设施成本

4. 性能: 选定业务系统进行 QPS/TPS 对比、横向扩展性的性能提升

5. 产品生命力: 产品是否具备不断迭代提升能力,产品成长能力是否足够,是否具备长期做好一款数据库的决心和实力

TiDB:原生分布式+强 MySQL 兼容,轻松解决应用架构难题

选择 TiDB 的理由

存算分离的云原生架构,用户投票的结果

TiDB 在架构上选择存算分离的云原生架构,对开发者提供了极致的敏捷开发体验,对业务提供了多点读写能力应对高吞吐场景,采用多数派协议默认三副本配置,原生的具备高可用以及故障自动转移能力。同时,采用业界领先的行列双引擎物理隔离的 HTAP 架构,为用户的实时数据分析简化架构,提升实时性。其实,TiDB 的整体架构演变是基于用户需求投票出来的结果。

那么,TiDB 对于现代企业具备什么价值呢?企业利用 TiDB 的横向扩展联机能力能应对绝大多数联机业务场景,再借助 TiDB 的列存引擎以及大数据库计算引擎的能力,应对大数据实时以及离线的数据分析需求。可极大的简化技术栈,提升敏捷开发体验,为企业诸多业务提供扎实的数据底座。彻底摆脱数据强一致性、业务侵入、扩展能力、高可用、数据分析等常面临的挑战。

TiDB 怎么定义 NewSQL ?

强 MySQL 生态兼容,实现低成本迁移

TiDB 提供了强 MySQL 生态。无论是开发语言、ORM、连接池,客户端工具,基本都保持强兼容。同时也提供了最高效的数据导出导入、备份恢复工具,进一步加强了 TiDB 的生态。另一方面,TiDB 和常见的国产操作系统、CPU 芯片都是 100% 兼容,且有生产案例。

了解更多数据库选型资料

TiDB vs MySQL Meetup 第一期 PPT 下载

TiDB vs MySQL Meetup 第一期 PPT 下载

相关推荐

TiDB 可观测性解读(二)丨算子执行信息性能诊断案例分享

通常我们可以用 explain analyze 语句获得算子执行信息。explain analyze 会实际执行对应的 SQL 语句,同时记录其运行时信息,和执行计划一并返回出来,记录的信息包括: actRows 、 execution info 、 memory 、 disk。不同算子的 execution info 可以通过 TiDB 文档 ( https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain-analyze )了解。

TiDB_PingCAP 的博客 1012

TiDB × AI :DeepSeek 时代你需要什么样的数据基座

AutoFlow 是一套 GraphRAG 框架,不仅提供了类似于 LlamaIndex 的能力,而且还内置语义化的知识图谱构建和召回,以及我们在 AutoFlow 上实践得出的一系列行之有效的领先的 RAG 能力(这些接下来会介绍)。不过需要强调的是,Dify 是一个开箱即用的非常易用的界面,而 AutoFlow 虽然功能更强却则具有比较高的使用门槛,所以这两个选择其实面向了不同的群体,用户需要依据自己的实际需求进行选择。它并非传统的基于规则的优化工具,而是利用大模型的知识来优化不同类型的数据库。

TiDB_PingCAP 的博客 1409

TiDB 观测性解读(一)丨索引观测:快速识别无用索引与低效索

通过识别并优化未使用或低效的索引,可以减少资源浪费,并提高系统的响应速度和稳定性。在 TiDB 中,TIDB_INDEX_USAGE 系统表提供了相对丰富的索引使用统计数据,帮助 DBA 快速发现低效索引,并通过优化或删除它们来提升数据库效率。尽管删除索引的操作相对简单,但在实施时仍需注意潜在的限制和风险,尤其是在大数据量和高并发环境下。定期检查索引使用情况,尤其是对于大规模数据库。确保用于决策的统计数据涵盖足够长的业务周期,避免误判。

TiDB_PingCAP 的博客 967

海量数据融合互通丨TiDB 在安徽省住房公积金监管服务平台的应用实践

目前安徽省住房公积金监管服务平台已具备一系列功能模块,包括首页、运营分析、统计报表、智慧大屏、数据治理、风险检查和系统管理。其中,运营分析主要用于从不同维度分析公积金业务指标,统计报表则负责生成、填报和查询住建部规定的报表,同时也支持省级用户的报表导入、核对和更新。智慧大屏提供了综合和业务两大类可视化展示,而数据治理模块则涵盖了传数统计、数据检核和人工数据核对等功能,以确保数据的质量。风险检查方面,平台不仅支持公积金中心的自我检查,也支持省厅的检查,并可以根据需要添加新的检查模型。

TiDB_PingCAP 的博客 1125

TiDB 2024 年度报告:增长的故事

TiDB 2024 年度报告:增长的故事

TiDB_PingCAP 的博客 322

TiDB Chat2Query 深度解析:我们如何打造一款更高效、准确的智能 SQL 生成工具?

上个季度的销售额是多少?“哪个产品类别表现最佳?“本月客户投诉的趋势如何?相比其他工具,Chat2Query 能够对用户上传的大规模数据集进行理解和分析, 摒弃繁杂的专业术语和查询语句,Chat2Query 使得用户能够通过自然语言直接向数据库提问,并即时获得答案。

TiDB_PingCAP 的博客 1332

4.98 亿月活背后的国产数据库:咪咕视讯携手 TiDB 攻克内容分发核心系统挑战

咪咕大概是 2018 年左右正式开始对分布式数据库进行研究的,到现在为止我们看到和测试过太多的国内产品。但是在当时,敢用 LSM 树而不是 B+ 树做存储引擎,敢做分布式存算引擎分离的,能够行列副本共存、优化器路由分流做 MPP shuffle 的,市面上真的真的非常非常地不多见。比较多的是精致的分库分表外挂,或某些知名国外产品的模仿版。TiDB 的产品给我的印象是极具冲击性的,那么大胆、不随大流。验证和使用下来,效果也是切实的。

TiDB_PingCAP 的博客 1187

53 倍性能提升!TiDB 全局索引如何优化分区表查询?

在 TiDB 中,全局索引是一种定义在分区表上的索引类型,它允许索引分区与表分区之间建立一对多的映射关系,即一个索引分区可以对应多个表分区。这与 TiDB 早期版本中的本地索引(Local Index)不同,本地索引的索引分区与表分区之间是一对一的映射关系,即一个分区对应一个局部的索引块。全局索引能覆盖整个表的数据,使得主键和唯一键在不包含分区键的情况下仍能保持全局唯一性。此外,全局索引可以在一次操作中访问多个分区的索引数据,而无需对每个分区的本地索引逐一查找,显著提升了针对非分区键的查询性能。

TiDB_PingCAP 的博客 1347

一行代码不用写,用 Autoflow + Gitee AI 搭建本地知识库问答机器人

本文详解 AutoFlow 从部署到配置的完整流程,包括数据库连接、模型设置、知识库创建及聊天引擎配置,实现了一行代码不用写的问答机器人快速搭建。轻松上手,助力开发者探索智能问答解决方案。

TiDB_PingCAP 的博客 1044

TiDB 分布式数据库多业务资源隔离应用实践

本文将分享某客户在 TiDB 分布式数据库中实现多业务资源隔离的实践案例。

TiDB_PingCAP 的博客 1309

攻克多版本运维难题:爱奇艺百套 TiDB 集群升级至 v7.1.5 实战宝典来袭!

本文将深入探讨爱奇艺如何通过升级,成功将百套 TiDB 集群从多个旧版本升级至 v7.1.5,攻克多版本运维挑战,获得更稳更快的 TiDB 使用体验。

TiDB_PingCAP 的博客 1150

百亿大表的实时分析:华安基金 HTAP 数据库的选型历程与 TiDB 使用体验

明确需求:首先评估业务对 TP(事务处理)和 AP(分析处理)的需求比重,确定数据量、查询速度和响应时间,确保数据库能满足业务对实时性的要求。技术特性评估:考虑数据库的实时分析能力、可扩展性、高性能、安全性和灵活性,以支持业务人员实施的场景需求,特别是后台营销人员对数据实时性的需求。集成与兼容性:评估数据库与现有数据库、应用程序和其他关键系统的集成能力,确保数据同步策略的无缝实施。安全性与可靠性:重视数据库的安全性措施、容灾备份机制、数据恢复能力和错误处理机制,保障业务连续性和数据安全。

TiDB_PingCAP 的博客 1013

TiDB 的高可用实践:一文了解代理组件 TiProxy 的原理与应用

TiDB 是一款典型的分布式存算分离架构的数据库,其中计算层由多个无状态的 TiDB Server 组成,这些 TiDB Server 同时对外承担连接请求。为了可以将连接分发到多个 TiDB Server 节点上,一般需要借助外部负载均衡组件如硬件负载均衡 F5、软件负载均衡 HAProxy 等。为了实现全链路的高可用架构,我们经常也需要考虑负载均衡组件本身的高可用性,比如通过 KeepAlived 来保证 HAProxy 的高可用。

TiDB_PingCAP 的博客 1250

你需要什么样的资源隔离?丨TiDB 资源隔离最佳实践

通过本文的学习,相信大家对 TiDB 的资源隔离能力有了更全面的理解;大家可以根据不同的场景需求,选择合适的资源隔离方案。如果您有新的资源隔离需求或场景,欢迎与我们联系。

TiDB_PingCAP 的博客 1240

狂飙 50 倍丨TiDB DDL 框架优化深度解析

前面我们介绍了 TiDB DDL 任务的整体执行流程。接下来,让我们聚焦到在线 Schema 变更的细节上。执行单步变更:Job Worker 会根据任务定义,执行一次在线 Schema 的变更。每一次变更都代表着 Schema 向目标状态迈进了一步,即进入下一个状态,可能的状态包括 write-only 和 delete-only 等。状态更新:完成单步变更后,Job Worker 会将当前的 Schema 状态更新到元数据中。

TiDB_PingCAP 的博客 1197

唐刘:TiDB 的 2024 - Cloud、SaaS 与 AI

最后再说下产品,在今年,我们发布了TiDB 8.1和8.5两个版本。在 2025 年,我们会有一个重大的改变,就是会持续的投入到 8.5 版本的质量加固,同时收敛新功能的开发,只会在 2025 年发布一个有更高质量的 LTS 版本。关于 TiDB 8 系列,我后面再写一篇文章详细的介绍一下吧。在 2024 年,我们交付了非常不错的成果,当然,能取得这样的成绩,来自于我们不断地交付优异的产品,满足客户的需求,赢得客户的信任。

TiDB_PingCAP 的博客 1051

PingCAP 连续两年入选 Gartner 云数据库管理系统魔力象限“荣誉提及”

TiDB 凭借领先的 HTAP 架构设计,支持用户在云上的数据库中同时运行关键业务交易和实时分析任务,充分享受云的弹性优势和业务连续性优势,助力企业实现数据敏捷。PingCAP 是业界领先的企业级开源分布式数据库企业,提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务,致力于为全球行业用户提供稳定高效、安全可靠、开放兼容的新型数据服务平台,解放企业生产力,加速企业数字化转型升级。

TiDB_PingCAP 的博客 692

TiDB 8.5 LTS 发版——支持无限扩展,开启 AI 就绪新时代

TiDB 8.5 扩展了Runaway Queries 的功能,新增“处理行数”和“用量(RU)”作为识别标准,实现更精确的识别,并允许将这些 Runaway Queries 放入一个资源可控的组中,确保在高负载环境下集群的稳定性。TiDB 8.5 通过实例级执行计划缓存功能,使得同一 TiDB 实例内的所有会话共享执行计划缓存,减少SQL编译时间,从而降低整体 SQL 运行时间,提高 OLTP 的性能和吞吐量,并有效地控制内存使用,提升数据库的稳定性。

TiDB_PingCAP 的博客 770

基于时间维度水平拆分的多 TiDB 集群统一数据路由/联邦查询技术的实践

通过该组件与 TiDB 分布式数据库的有效结合,可以实现近乎无容量上限的超大规模数据管理,尤其是对于重要程度高、吞吐量大、业务敏捷性强、数据冷热特征明显的业务系统。不仅能够支撑面向内外部客户业务无损的多维度、不受分片键制约的灵活高效访问,还可以有效控制和平衡单集群的负载、容量、资源利用率、稳定性等关键指标,在不增加过多复杂性的前提下实现更强的整体扩展能力。当然,组件的现有功能更多是聚焦在当前的客户场景,未来可以按需在功能性、易用性、高性能等方面进一步优化和提升。

TiDB_PingCAP 的博客 908

Rakuten 乐天积分系统从 Cassandra 到 TiDB 的选型与实战

Rakuten 乐天是一家成立于 1997 年的日本公司,总部位于东京,员工总数超过 30,000 人,业务遍及 100 多个国家和地区。除了电商业务外,乐天还涉及电信、金融等多个行业。乐天的积分系统在日本非常普及,用户通过使用乐天的服务,如银行卡、手机卡等,可以获得积分,并在乐天商城中使用这些积分进行购物或抵扣,我们每个季度还会举办促销活动、会有大量用户高频访问积分系统,因此,乐天积分服务平台的性能、延迟和可用性要求极高。

TiDB_PingCAP 的博客 1348

平凯星辰亮相开放原子开发者大会,TiDB 荣获年度活跃开源项目奖项

12 月 20 - 21 日,以“一切为了开发者”为主题的 2024 开放原子开发者大会暨首届开源技术学术大会在武汉成功举办。平凯星辰亮相本次大会,出品 AI 时代的数据库技术发展论坛,获评“校源行”优质开源课程合作单位。由平凯星辰创立的开源分布式数据库 TiDB 获评“2024 年度数据库领域国内活跃开源项目”,7 位 TiDB 开发者获评“2024 年度数据库领域国内活跃开源开发者”,彰显了 TiDB 在开源数据库领域的卓越影响力和社区活力。

TiDB_PingCAP 的博客 602

B 站数据库负责人赵月顺:助力海内外业务增长,百套 TiDB 的选型与运维实战

B 站的 TiDB 集群规模已达到 100 多套,计算节点超过 2000 个,存储节点超过 800 个。TiDB 的应用场景非常广泛,包括视频观看、一键三连、发送弹幕、撰写评论、阅读漫画以及视频后端的存储等。B 站的 TiDB 部署采取了存算分离的策略,计算节点被部署在容器中,这种做法的优势在于能够充分发挥容器化管理无状态服务达到水平弹性拓展能力,允许根据需求随时对计算节点进行扩展或缩减,整个过程仅需一次服务发版,有效提升了效率与灵活性。存储节点则继续部署在物理机上。

TiDB_PingCAP 的博客 1224

微众银行携手平凯星辰荣膺金融科技创新奖,共同打造纳管千台服务器的大规模数据库运维平台

在过去的十年中,平凯数据库在金融行业积累了丰富的实践经验,已经在国有大型银行的 PB 级别数据服务平台、头部商业银行的核心交易系统、头部保险公司的核心保单系统、头部证券公司的核心交易系统等领域,成功完成了对国外商业数据库和 MySQL 数据库的替换升级,部署了超过 1,000 套关键业务系统,集群节点总数超过了 10,000 个。为了应对这些挑战,同时满足金融行业对高可用、高可靠、高性能数据库的需求,微众银行开发了一套完整的运维体系,打造了大规模信创原生分布式数据库智能运维平台。

TiDB_PingCAP 的博客 799

知乎 PB 级别 TiDB 数据库集群管控实践

知乎的数据库团队以“致力于提供稳定、高效和易用的数据库服务”为目标,为公司业务团队提供更好的 TiDB 存储服务来应对高并发、复杂查询和大数据存储的需求。本文详细介绍了 TiDB 的生态架构,包括核心组件、数据迁移与同步、运维与监控平台、备份与恢复、生态集成、K8s 支持、工具集和安全与审计等方面。同时探讨了知乎如何在云上和云下环境中管控 TiDB 集群,以及如何通过自研的天穹平台实现数据库平台化建设,提升业务研发团队数据库变更和 DBA 团队的资源管控效率。

TiDB_PingCAP 的博客 1174

TiDB 优化器 | 执行计划管理及实践

本文深入解析了 TiDB 优化器的执行计划生成过程及其局限性,介绍了如何通过 Hint、SQL Binding、执行计划缓存等技术手段进行执行计划管理,确保查询性能的稳定性和高效性。

TiDB_PingCAP 的博客 1307

商业银行基于容器云的分布式数据库架构设计与创新实践

本文介绍了某商业银行基于 TiDB 和 Kubernetes(简称 K8s) 构建的云化分布式数据库平台,重点解决了传统私有部署模式下的高成本、低资源利用率及运维复杂等问题。通过引入 TiDB Operator 自动化管理与容器化技术,银行能够实现多个业务系统的高可用、弹性扩展与自动化运维,极大提高了运营效率与资源利用率。本文还详细阐述了平台架构设计、面临的技术挑战及创新解决方案,展示了 TiDB 在金融行业数字化转型中的应用前景。

TiDB_PingCAP 的博客 1353

PingCAP 荣膺 2024 亚马逊云科技合作伙伴两项殊荣

近日,在 2024 亚马逊云科技 re:Invent 全球大会上,PingCAP 荣膺亚马逊云科技年度技术合作伙伴和年度亚马逊云科技 Marketplace 合作伙伴两项殊荣。这是 PingCAP 连续第二年获得亚马逊云科技年度合作伙伴奖项,彰显了 PingCAP 在与亚马逊云科技合作服务客户的过程中所展现的卓越技术实力和专业服务能力,共同推动全球用户业务取得成功。

TiDB_PingCAP 的博客 561

基于 AutoFlow 快速搭建基于 TiDB 向量搜索的本地知识库问答机器人

通过本篇文章介绍,相信大家对使用 PingCAP 开源项目 AutoFlow 实现快速搭建基于 TiDB 的本地知识库问答机器人会有一个完整的了解。如果提前准备好 Docker、TiDB 环境,整个搭建过程估计在 10 分钟左右即可完成,无须开发任何代码。文中使用一篇 TiDB 文档作为本地数据源作为示例,在实际情况中,您可以基于自己的企业环境用同样的方法快速构造企业内部知识库问答机器人。

TiDB_PingCAP 的博客 1278

TiDB 关联子查询及半连接的优化实践

TiDB 针对子查询语句会执行多种子查询相关的优化,以提升子查询的执行性能。半连接语句和关联子查询语句是常用的两类子查询,TiDB 优化器默认包含一些自动优化策略,同时 TiDB 也提供额外的 HINT 用于影响优化器在特定场景下可以选择更高效的执行计划。本文针对半连接及关联子查询语句在 TiDB 中的用法及优化技巧进行说明。

TiDB_PingCAP 的博客 1401

实战丨证券 HTAP 混合业务场景的难点问题应对

某领先的全国性大型综合证券公司,坚持以核心业务为发展重心,并积极投身于前沿科技的应用创新。本文将分享该证券公司债权开放信息平台的构建经验,深入探讨如何利用 TiDB 分布式数据库成功应对 HTAP 场景下的挑战,满足数据实时性、可靠性、资源隔离、可维护性等要求。通过这一实践案例,我们可以看到 TiDB 如何在金融服务领域发挥关键作用,以及它如何帮助企业在激烈的市场竞争中保持领先地位。

TiDB_PingCAP 的博客 855
上一篇: TiDB 观测性解读(一)丨索引观测:快速识别无用索引与低效索
下一篇: TiDB × AI :DeepSeek 时代你需要什么样的数据基座
TiDB_PingCAP
TiDB_PingCAP 企业官方账号 企业官方账号
博客等级 码龄10年 2724粉丝 780原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值