TiDB_PingCAP-CSDN博客

原创 TiDB 组件 GC 原理及常见问题

实现的了解，我们知道 TiDB 集群具体的数据存储在 TiKV 上，集群的元数据信息存在 PD 上，TiDB 要做数据旧版本的回收，则需要有个类似 GC worker 的角色从 PD 拿到元数据信息然后对 TiKV 中的数据做垃圾回收工作。假设我们直接删除，删除之后，如果用户要读 t4 这个快照里面 B 的值，发现 B 上有个指向 (A，t1) 的这个 lock, 我们开始从 A 上确认事务 t1 的状态，但是在 TiKV 中找不到（A，t1) 这个事务，也就无法确认其状态。

2024-04-07 02:12:06 1176

原创 TiDB 慢查询日志分析

二是早期版本的 statements_summary_history 是纯内存表，可能由于 TiDB Server OOM 重启而导致数据丢失，而慢查询日志是存储在文件中的，因此 TiDB Server OOM 重启不会导致慢查询日志丢失。TiDB 中的慢查询日志是一项关键的性能监控工具，其主要作用在于协助数据库管理员追踪执行时间较长的 SQL 查询语句。通过记录那些超过设定阈值的查询，慢查询日志为性能优化提供了关键的线索，有助于发现潜在的性能瓶颈，优化索引以及重构查询语句，从而提升数据库的整体性能。

2024-04-07 02:11:29 986

原创 TiDB MVCC 版本堆积相关原理及排查手段

本文介绍了 TiDB 中 MVCC（多版本并发控制）机制的原理和相关排查手段。TiDB 使用 MVCC 机制实现事务，在写入新数据时不会直接替换旧数据，而是保留旧数据的同时以时间戳区分版本。当历史版本堆积过多时，会导致读写性能下降。为了解决这个问题，TiDB 使用 Garbage Collection（GC）定期清理不再需要的旧数据。文章从 TiDB 中 MVCC 版本的生成原理、数据写入过程和 TiDB 版本堆积常见排查手段等方面进行了详细介绍。

2024-04-07 02:10:32 1071

原创唐刘：关于产品质量的思考 - 如何评估质量

这里稍微解释一下 bug 收敛，关于 bug，一般会有两条曲线，一条是 open 的 bug 数量，另一条是 closed 的 bug 数量，通常对于一个快速迭代的系统来说，open bug 的数量是大于 closed bug 的数量的，随着时间的推移，如果这个差值不断增大，没有显示出收敛的趋势，或者差值控制在一个很小的范围内，我们就会认为产品的整体质量存在风险。也就是说，我们在下一个发布的版本里面，是要尽量的去修复上一个版本漏出的 bug 的，如果不做这些事情，质量很容易就失控了。

2024-04-07 02:09:59 2811 4

原创月活超 1.1 亿，用户超 4 亿，你也在用的「知乎」是如何在超大规模 TiDB 集群上玩转多云多活的？来听听知乎代晓磊的答案！

导读代晓磊，知乎数据库负责人，同时也是 TiDB 社区北京地区组织者，一位有着 13 年数据库从业经验的数据库老兵，对数据库运维及 TiDB 有着丰富的实践经验。在“2024 新年围炉茶会”中，他分享了《TiDB 在知乎实践的那些事》话题，回顾了最近两年知乎 TiDB 实践的最新进展，以及对数据库未来发展方向的个人观点，本文根据代晓磊老师的演讲实录进行整理。视频链接：https://www.bilibili.com/video/BV1FT4y1n7fn/知乎应用 TiDB 历史非常

2024-04-06 23:19:29 629

原创金融企业区域集中库的设计构想和测试验证

先发起 test_rg1 资源组中用户的压测，RU 使用达到了 293000 左右，体现 burstable 参数在集群空闲状态下的配置效果，再发起另外两个资源组的压测，test_rg1 逐步回落到资源组配置上限 160000 左右（见图八）。区域集中库是将数据库整合落地在数据库层，通过标准化部署和细粒度资源配置，得到更高的服务可用性、规格弹性和资源利用率。多业务整合的场景中，不仅需要关注资源开销，还需要关注数据库的业务管理特性，比如 SQL 黑名单、细粒度监控、连接标识等，提升管理员的运维效率。

2024-04-06 23:18:25 966

原创以一当十丨TiDB 在东吴证券秀财 APP 的应用实践

因此，东吴证券计划引入 TiDB 新版本的资源管控功能，结合 TiDB 的可伸缩特性，通过构建 TiDB 统一集群的方式对通用服务资源进行分配和隔离，实现对存量 MySQL 实例的归集和统一管理，提升资源利用率，降低运维投入，同时解决不同业务之间的资源争抢问题。TiDB 提供灵活的可伸缩性，除了实现大容量之外，还带来了高性能。使用 TiDB 的 HTAP 特性后，相关业务的交付效率大幅提升，整个处理流程都在 TiDB 和单一应用内完成，数据链路短，排障难度也大幅降低，极大地节省了人力和时间成本。

2024-04-06 23:17:32 700

原创夯实智慧新能源数据底座，TiDB Serverless 在 Sandisolar+ 的应用实践

在该 SaaS 系统中，SandiSolar+ 最核心的部分是打造了一个“数据中台”，系统中所有数据的搜索查询都通过“数据中台”实现。综上所述，SandisSolar+ 的 SaaS 平台对数据的实时性处理要求较高，传统的大数据、离线数仓无法满足这种实时性需求，经过对主流数据库进行选型，SandiSsolar+ 最终选择了具备 HTAP 能力的 TiDB Serverless 数据库来作为数据底座，为相关业务系统的智能化、可靠性、实时性提供了全面保障，承载了 SaaS 平台的实时数据存储、计算需求。

2024-04-06 23:15:08 896

原创数据库性能优化入门：数据库分片初探

文章解释了数据库分片是如何通过将数据切分、分散存储在多个服务器上来提升性能，并对数据库分片与传统数据库的区别进行了详细对比，探讨了何时应该考虑进行数据库分片。文章介绍了几种常见的分片策略，包括基于键、基于范围、垂直和基于目录的分片，并分析了它们的优缺点。在我们探讨了数据库分片的复杂性和策略后，明显的结论是，尽管分片提供了一种强大的方法来处理大规模数据和高事务量，但它并不是一劳永逸的解决方案。换句话说，你可以手动分片你的数据库，或者你可以使用中间件层或可以有效自动分片数据的数据库。

2024-04-05 22:49:42 641

原创 TiDB 社区智慧合集丨解码 TiDB 性能谜题：让你的数据库发挥最强动力!

来自社区，回归社区。】()里提供的各种性能优化方法。这篇帖子收集整理了大家推荐的各个方面的 TiDB 数据库性能优化方法，欢迎各位 TiDBer 持续补充更新～贡献者：@kongdom开启 Raid 卡缓存，使机械硬盘的 I/O 性能直线提升。MegaCli64 -LDInfo -Lall -aALL #查看MegaCli64 -LDSetProp -WB -Lall -aAll #有电池启用缓存。

2024-04-05 22:31:53 382

原创 TiDB 实战分享丨第三方支付企业的核心数据库升级之路

目前整个计费数据库的 99 平均延迟稳定在 4ms 左右，峰值 QPS 10K，TPS 5 K，TiDB 完美的在一套系统中同时满足了高频的交易请求和实时的分析业务需求，有效保证了计费的时效和准确性。TiDB 用一个数据平台满足实时交易与实时分析的场景需求，通过丰富的技术生态实现与 Oracle、DB2 等传统数据库的打通，实现与 Hadoop、Spark、Flink、Kafka 等大数据技术栈的广泛融合，为上层业务提供统一数据服务，在简化企业数据栈的同时大幅降低维护成本。

2024-04-05 22:29:25 783

原创唐刘：关于产品质量的思考 - 我的基本认知

这其实也是我的教训。在之前的 TiDB 版本里面，我们有时候太放飞自我，做了太多的功能，而功能越多的版本，质量在一开始就是不稳定，所以我们耗费了大量的精力去提升质量。一个好的产品必须要有大量的用户，用的多了，骂的自然也多了，当然最终的结果是越变越好，这可能就是产品成长的必然经历吧。当我们投入更多的研发带宽去研发新的功能时候，自然会挤占质量改进的带宽，所以无论是新的功能引入的 bug，还是累积的未修复的 bug，都会降低产品的质量。当然，我也不指望我的认知是正确的，也可能不久之后，我的认知又会刷新。

2024-04-05 22:28:47 592

原创 AmzTrends x TiDB Serverless：通过云原生改造实现全局成本降低 80%

AmzTrends 的数据主要以大单表的形式进行存储，最大的表数据量超过 22 亿，字段较多且某些字段很长的大宽表，单表中存在结构化与非结构化的数据结构，因此需要建立大量的索引，占用大量存储空间，而且过期数据还需要定期清理，经常使用 BATCH 进行批量操作，一旦遇到异常无法无法事务的一致性，因此数据维护压力巨大。TiDB Serverless 提供全托管的服务模式，充分发挥了 TiDB 数据库的原有特点和优势，简化了 Amztrends 的整体架构，提升了性能和系统健壮性，同时降低了总体成本。

2024-03-03 20:18:51 1035

原创为什么说 TiDB 在线扩容对业务几乎没有影响

TiDB Server 节点不持久化数据，每个节点也是完全对等的，当 TiDB Server 计算资源不够了，只需要增加 TiDB Server 节点，然后修改上层的负载均衡组件将客户端连接均衡分发到新的 TiDB Server 节点即可（目前大多数负载均衡组件都支持动态修改配置）。集中式数据库因为其架构本身的限制，一般来说想要实现在线扩容是比较困难的，这里暂且不予讨论，我们主要了解一下一般分布式数据库的扩容是如何进行的。比如下图中增加节点 4 ，影响的数据只有节点 1 到节点 4 之间的这部分数据。

2024-03-03 20:18:21 596

原创内含资料下载丨黄东旭：2024 现代应用开发关键趋势——降低成本、简化架构

它不仅能够自动化生成、测试、部署代码，还能帮助我们更迅速地捕捉到代码中的错误，提升用户的满意度，让代码的“质”和“量”都得到了提升，让我们的应用更聪明，体验更加流畅。此外，JavaScript 友好的 Serverless 托管平台的出现，为开发者提供了快速开发部署，以及实时预览的功能，大大提升了应用开发的体验。根据当下的情况，我总结了三个关键的趋势，希望能够帮助正在创业的应用开发者实现“降本增效”：如何通过最小的成本，获取最大的可扩展性。AI 像一个聪明过人的助手，帮你在休息的时候编写、测试、部署代码。

2024-03-03 20:17:48 766

原创 TiDB 社区智慧合集丨TiDB 相关 SQL 脚本大全

里提供的各种常用脚本。在这篇文章中，我们整理了社区同学提供的一系列 TiDB 相关 SQL 脚本，希望能为大家在 TiDB 的使用过程中提供一些帮助和参考。这些脚本涵盖了常见场景下的 SQL 操作，欢迎各位 TiDBer 持续补充更新～未来，我们也将整理更多 TiDB 相关实用指南，帮助大家更好地了解、运用 TiDB，敬请期待！贡献者：@ShawnYan贡献者：@我是咖啡哥方法一：使用函数 TIDB_PARSE_TSO方法二：使用 pd-ctl贡献者：@我是咖啡哥。

2024-02-23 17:57:12 1063 1

原创数据价值在线化丨TiDB 在企查查数据中台的应用及 v7.1 版本升级体验

这样，我们将不同类型的业务整合到一个 TiDB 集群中，提升了资源利用率，降低了 30% 的投入成本。目前，我们正在调研 TiFlash 的功能，计划今年将部分复杂的离线查询从 Hive 迁移到 TiDB 中，直接从 TiDB 中查询，以减少数据在多个数据栈中流转，进一步提升数据的实时性。在出口端，TiDB 既可以通过 TiCDC 将数据分发到下游的 Kafka，并通过 CommitTS 特性保证业务数据的一致性，也可以通过标准接口将数据同步到下游的大数据平台，提高了企业数据的流转效率，盘活了数据资产。

2024-02-23 17:56:27 1337

原创 Runaway Queries 管理：提升 TiDB 稳定性的智能引擎

○ 上述例子里，我们向配置里加入了 WATCH 规则，那么和被识别成 Runaway Query 查询类似的查询（比如只有过滤值不同），在接下来的 10 分钟里，会直接执行对应操作，而不会再等待 5 秒。自动筛选规则并不能精确的识别出所有有问题的查询，因此我们加入了对监控列表的人工管理。在上述示例中，即使没有设置资源组对查询的自动识别，在出现 SQL 性能问题时，我们仍可以通过“慢日志”或者系统表找出问题查询的“特征”，用 QUERY WATCH 手工将查询加入监视列表，达到设置黑名单的效果。

2024-02-23 17:55:54 1159

原创 TiDB 7.5.0 LTS 高性能数据批处理方案

b. 在简单的数据导出场景，使用导出 csv 替换原本 limit 处理逻辑，应用将查询结果导出到一个共享 NFS/S3 对象存储中，再读取 NFS/S3 对象存储中的 CSV，进行结果的处理，极大的降低了数据库的压力，同时性能将比之前使用 limit 分批处理更高。如果使用 LOAD DATA 要获得比较高的性能，建议对单个文件进行拆分，同时 csv 中文件的顺序建议与目标表主键顺序一致，如一个 CSV 文件存储 20000 行，再通过多线程并行来写入，此时写入性能也比较高。

2024-02-19 21:32:36 1333

原创作业帮 x TiDB丨多元化海量数据业务的支撑

同时，在人工智能爆发的背景下，越来越多的探索性业务天然需要存储海量的数据，TiDB 自然成为首选方案。相较于 TiDB v3.x，v4.0.9 在性能、管理、易用性等方面都有了质的提升，同时 TiDB 的生态组件以及社区也都达到了非常完善的程度，可以说是一个标志性的版本。经过半年左右时间的使用，在对 TiDB 有一定了解的基础上，我们开始在公司内部进行 TiDB 相关的技术分享，向研发人员介绍 TiDB 的一些特性和在大数据量场景下的优势，并主动接触各个业务线去寻找合适的使用场景。

2024-02-17 22:26:41 2822

原创从 20 多套 MySQL 到 1 套 TiDB丨骏伯网络综合运营管理平台应用实践

为满足多元化的业务发展需求，降低系统间交互链路的复杂性，提升业务连续性，以及实现降本增效的整体规划，骏伯网络选择将 TiDB 作为综合运营管理平台的底层数据库。广州骏伯网络是一家以数据驱动的科技公司，聚焦移动互联网营销服务，坚持以客户为中心，深耕 APP、运营商、金融保险等行业，以解决客户营销痛点为目标，为客户提供全链路营销服务。在 2024 年的计划中，我们旨在构建一套以 TiDB 为底座的数据实时分析平台，以实现对数据的实时加工和统一服务能力。TiDB 内置的数据实时压缩能力，保障数据三副本的高可用。

2024-02-17 22:24:53 1173

原创使用 Coze 搭建 TiDB 助手

现在我们知道了，OPENAI 会通过我们事先定义好的 function 来做判断，如果需要 function 提供的能力，大模型会给我们一个回调请求，以 Github-searchRepositories 为例，具体的执行实际是调用 Github 的 OpenAPI (这里给出两种模式：知识库和 function call。前面提到，Coze 平台的 Plugins 是采用了 function call 的能力，下面以 Github plugin 为例，尝试用 OPENAI 定义的 function (

2024-02-17 22:23:14 1265

原创通过 Prometheus 编写 TiDB 巡检脚本（脚本已开源，内附链接）

该函数将目标分位数 (0 ≤ φ ≤ 1) 和直方图指标作为输入，就是大家平时讲的 pxx，p50 就是中位数，参数 b 一定是包含 le 这个标签的瞬时向量，不包含就无从计算分位数了，但是计算的分位数是一个预估值，并不完全准确，因为这个函数是假定每个区间内的样本分布是线性分布来计算结果值的，预估的准确度取决于 bucket 区间划分的粒度，粒度越大，准确度越低。这是笔者和同事共同编写的一部分巡检脚本，最重要的是 tasks 中的 PromQL ，在脚本执行之前要写好 PromQL，其他部分可以随意更改。

2024-02-16 15:55:23 1264

原创 “分布式透明化”在杭州银行核心系统上线之思考

韩锋频道》公众号作者。同时，银行核心在整个银行 IT 系统架构中是其他业务子系统的基础，处于承上启下的关键位置。未来，希望广大金融 IT 从业者，在面临国产化升级的整体规划上，既需要考虑企业当前现状，也能充分瞄准未来架构的延伸性，以创新的思维推动银行核心系统的整体升级，共同助力中国金融的数字化转型。杭州银行核心系统升级，正是从架构、研发、运维多角度出发，在充分考虑新型分布式数据库能力的同时，结合自身技术发展现状及长远规划，最终选择 TiDB 作为核心系统的数据库，并通过近两年与厂商的通力协作成功上线。

2024-02-16 15:54:29 1181

原创一篇文章彻底搞懂 TiDB 集群各种容量计算方式

本文只讨论的 TiKV 的容量计算细节，TiFlash 的计算方式也类似，我对比了 Ti F lash 的数据目录大小和监控显示已用大小 10 多 G 的差距，应该也是只计算了部分目录，但是总容量还是算的整块盘。不太熟悉 c++，留给其他大佬去探索吧。○ TiKV 实例容量统计的是 TiKV 所在磁盘的整体大小与 raftstore.capacity 参数较小的值，同时监控用的 bytes(SI) 标准显示，就是说不是用 1024 做的转换而是 1000，所以和 df -h 输出的盘大小有差距。

2024-02-16 15:51:24 807

原创黄东旭：“向量数据库”还是“向量搜索插件 + SQL 数据库”？丨我对 2024 年数据库发展趋势的思考

如果数据访问倾斜是一个业务的天然属性的话，对等的假设就不再是合理的，更合理的方式是将更好的硬件资源倾斜给热点的数据，而冷数据库使用更廉价的存储，例如，TiDB 从一开始将存储节点（TiKV）/ 计算节点（TiDB）/ 元信息（PD）分离，以及在后来 TiDB 5.0 中引入自定义 Placement Rule 让用户能够尽可能决定数据摆放策略，就是为了尽可能弱化节点对等假设。GenAI 时代的到来，就像一股不可抗拒的潮流，推动着数据技术的每一朵浪花，朝着更智能化、更灵活化的巨浪之海奔流。

2024-02-15 03:22:03 3440 2

原创 TiDB in 2023，一次简单的回顾丨PingCAP 唐刘

，直到我们一个北美的客户真的进行了这样的操作。这个工作非常的重要，在没开始之前，如果我们在本地单纯的跑 TiDB 的 UT 测试，不出意外，大概率会跑挂，即使通过，耗时也接近 50 分钟，而这个工作开始一段时间之后，我们当前跑完 UT 只需要 15 分钟（后面还会继续优化），这个对于我们自身的测试效率是一个极大的提升，当效率提升之后，我们就能有更多的时间写代码，加测试了。坦白的说，直到现在，我也没找到一系列很好的指标来评估我们发出去的一个版本质量到底好不好，无论我们做了多少的测试，我总认为是不够的。

2024-02-15 03:21:21 1273

原创 TiDB 在医疗保障信息平台的应用实践

医疗保障平台的设计要求实现跨区域、跨层级、跨业务、跨部门、跨系统的信息共享、业务协同和服务融通，以实现医保业务的“一网通办”和“一窗办结”。做为实时数据服务的平台，关系型数据库需要支持海量业务数据的存储、计算和实时展示，具备数据集成与传输的能力，需要面向各种数据应用，例如，报表平台、自助分析平台（BI）、历史明细查询平台、数据挖掘、AI 平台等提供多种服务能力，包括可伸缩的数据扩展能力、并发读写能力、实时更新能力、复杂查询分析能力，以及对事务和标准 SQL 的支持能力等。医疗保障平台架构示意图。

2024-02-15 03:20:48 1020

原创首个云原生、分布式、全栈国产化银行核心业务系统投产上线丨TiDB × 杭州银行

新核心系统采用全新的技术和工艺，在继承杭州银行原有核心业务系统的设计特点和服务能力的基础上，基于云原生、分布式、全栈国产化的技术架构，持续提升数据集成、客户经营、业务创新、风险侦测和精细运营的能力，构建面向客户、内核成熟、灵活扩展、稳定高效、自主可控的核心银行体系。在数据库层面，杭州银行充分利用 TiDB 分布式数据库的原生分布式架构优势，提供金融级的强一致性、高吞吐和低延时能力，有效解决了传统集中式核心的并发瓶颈，提升了核心系统的高可用性和动态扩容能力。24 小时延迟抖动控制在 2% 以内的目标。

2024-01-12 03:30:46 919

原创神州数码集团荣获“TiDB 社区最佳贡献企业”

神州数码在 TiDB 开源社区表现出非常积极和热情的态度，已有 90 人积极参与到社区的互动中，发布了 504 个主题贴，累计发布 76 篇优质文章，帮助他人回复帖子 4861 次，并有 33 人获得了 PCTA 认证，20 人获得 PCTP 认证。神州数码一直以开源作为重要方向，积极参与 TiDB 项目的开发和 TiDB 开源社区的运营，不仅在技术领域上帮助 TiDB 开源社区不断发展，还通过推广等手段增强社区力量和影响力，与 PingCAP 共同构建一个活跃的开源生态，为企业数字化转型做出了突出贡献。

2024-01-12 03:29:40 452

原创 TiDB 在全球头部物流企业计费管理系统的应用实践

TiDB 原生分布式架构支持线性水平扩展，很好地解决了系统的性能瓶颈问题，在业务不断发展的情况下，系统可以随时按需进行扩容和缩容，从而满足更高并发和更复杂的业务需求。此外，TiDB 具备热点数据打散和负载自动均衡的能力，对热点数据的处理更加高效，保障了系统资源的合理利用，降低系统出现性能问题的风险。这种实现方式带来了系统架构的复杂性，使得数据流转周期延长，流程变得更加复杂，数据同步和计算过程容易出现问题，需要系统管理员进行定期的优化和维护，以支持更高的并发量和更复杂的业务场景。

2024-01-12 03:28:54 943

原创 PingCAP 受邀参加 FICC 2023，获 Open100 世纪全球开源贡献奖

工作负载方面，同时涵盖了读写请求，其中读根据 Transaction、Online-Serveing、Analytics 三种场景设计了不同的查询，写入涵盖了插入、更新、删除，且考虑了单点写入和批量写入等多种情况。FICC 的使命是通过搜索和推进芯片、人工智能、开源系统、基准和评估等领域的最新技术和实践，提供开创性的技术地图。”分会场中，PingCAP 研发工程师张原嘉发表了以“TiDB: 面向弹性扩展和实时分析的云原生、分布式、兼容 MySQL 的数据库”为主题的分享。

2024-01-12 03:27:37 696

原创 PingCAP上榜工信微报年度回顾《2023 年工业和信息化发展情况》三大具有国际影响力的开源社区之一

PingCAP 成立于 2015 年，是一家企业级开源分布式数据库厂商，由 PingCAP 创立的分布式关系型数据库 TiDB，为企业关键业务打造，具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等企业级核心特性，帮助企业最大化发挥数据价值，解放企业生产力，加速企业数字化转型升级。PingCAP 在帮助企业释放增长空间的同时，也提供了一份具有高度可参考性的开源建设实践样本。》报告，回顾了 2023 年度软件产业的高质量发展，及其对数字经济规模增长、新型工业化推进的重要作用。

2024-01-12 03:26:42 435

原创 2023 Gartner® 云数据库管理系统魔力象限发布 PingCAP 入选“荣誉提及”

目前已在亚马逊云科技、谷歌云、阿里云等全球主流云平台上提供服务。企业可以按照实际提交的 SQL 请求和使用的存储来付费，同时可根据自身需求自动扩展，消除了预设集群规模、资源负载平衡和资源闲置造成的挑战和浪费，在帮助客户降低系统的复杂度的同时，实现成本节约，带来更便捷的云端体验，赋能全球企业和开发者。全球云数据库管理系统魔力象限报告对云数据库的发展趋势、市场需求进行了详细阐述，围绕“愿景完整性”和“执行能力”两大维度共 15 个核心指标，评估了全球领先的云数据库产品，并以此评选出魔力象限和荣誉提及的厂商。

2024-01-12 03:25:51 449

原创打造创新的金融数据平台，加速数字化和智能化转型丨PingCAP 官网金融行业专区上线

作为金融级分布式数据库，TiDB 在国有大行 PB 级别的数据服务平台、头部城商行的核心交易系统、头部保险公司的核心保单系统、头部证券公司的核心交易系统，成功完成了对经典数据库和 MySQL 数据库的替换。自诞生以来，TiDB 的原生分布式架构在强一致性、高可用性和可扩展性等方面与金融级业务需求高度契合，早期版本即为包括北京银行在内的金融用户提供服务。金融行业专区沉淀了 TiDB 服务中国和全球金融机构的经验，旨在为更多金融机构的数据库选型和应用提供深入的洞察和可靠的参考路径。

2024-01-12 03:25:15 549

原创 TiDB 入选 2023 年中国云原生数据库十大厂商推荐

报告认为，传统数据库的使用理念为“以数据库为中心”，主要集中在对数据库的管理和维护，如硬件资源的配置、数据存储的优化和查询性能的调整。《2023 年中国云原生数据库十大厂商推荐》市场报告聚焦 2023 年中国云原生数据库市场，以云原生数据库、AI4DB、DB4AI、HTAP 等技术为核心研究对象，以 2022 年下半年至 2023 年上半年为研究周期，对云原生数据库在金融、互联网、交通、制造、政务等行业的市场动向、前沿技术、企业需求、竞争态势等信息进行重点梳理，对市场发展前景做出推测或预判。

2023-12-28 15:44:10 466

原创平凯数据库亮相 2023 信息技术应用创新论坛

TMS 提供了一套全流程的迁移工具和解决方案，涵盖了从数据库对象、SQL 兼容性分析、迁移前后 SQL 执行性能对比，再到存量数据迁移的全面支持，以帮助企业用户最大程度地降低迁移风险和成本。新版平凯数据库推出了企业级运维管理平台（TEM），帮助用户通过图形化的统一运营管理平台，一体化管理几十套集群，甚至上千个平凯数据库服务器，提供数据库集群的部署、配置、升级、备份恢复、监控告警等功能。随着数据使用场景的多元化，对于高并发读写、海量数据快速增长、实时分析需求较高的业务系统而言，传统商业数据库支撑乏力。

2023-12-28 15:43:40 528

tidb-in-action-20200611.pdf

空空如也