TiDB_PingCAP-CSDN博客

原创多点 Dmall x TiDB：出海多云多活架构下的 TiDB 运维实战

作者：多点，唐万民时隔 2 年，在 TiDB 社区成都地区组织者冯光普老师的协助下，TiDB 社区线下地区活动再次来到成都。来自多点 Dmall 的国内数据库负责人唐万民老师，在《出海多云架构，多点 TiDB 运维实战》的主题分享中，介绍了多点在出海业务场景部署和使用 TiDB 的经历。本文根据唐万民老师的演讲实录进行整理，你可以从中了解到多点从无到有，使用 TiDB 的业务场景，多云架构的实践经验，以及版本升级遇到问题的解决方案。

2024-05-15 02:11:11 762

原创 PingCAP 黄东旭参与 CCF 秀湖会议，共探开源教育未来

PingCAP 相信，通过持续的努力和合作，开源教育将为技术创新和人才培养提供更广阔的平台，推动整个行业的发展。每个研讨会均针对某一个具体的前沿问题讨论交流为主，仅限发起人邀请的一线专家参与，不对外开放，会期 3 天，要求参会者全程参会，不能中途离会，引导科学家、企业技术专家及教育专家在浮躁的社会中沉下心来钻研学术。经过三天的会议，嘉宾们围绕开源教育的核心内涵、开源教育的需求与难点、开源课程资源建设、高校等科研机构的人才培养模式优化、开源通识和普及教育的开展等方面形成了初步的共识。

2024-05-15 02:10:16 380

原创银行核心背后的落地工程体系丨混沌测试的场景设计与实战演练

混沌工程是一种全面的测试方法，它覆盖了从应用层前端到底层硬件环境的所有环节，确保整个系统在面对各种异常和故障时的稳定性和弹性。本文将聚焦于与 TiDB 分布式数据库相关的混沌工程场景。混沌工程和普通测试在软件系统工程中都扮演着重要的角色，但它们关注的质量属性和测试实施的方式存在明显差异。混沌工程更侧重于系统的健壮性和在面对异常情况时的响应能力，而普通测试则侧重于验证系统的功能正确性和性能指标。两者的差异详见下表：在着手进行混沌测试的场景设计和实施之前，有几个关键问题需要我们深思熟虑：

2024-05-15 02:08:53 385

原创 PingCAP 戴涛：构建面向未来的金融核心系统

作者：戴涛近日，平凯星辰解决方案技术部总经理戴涛在 2024 数据技术嘉年华活动中，做了主题为“构建面向未来的金融核心系统”的分享，本文为戴涛演讲实录的全文。文章分析了中国金融行业的发展趋势，并且基于这些趋势对数据库选择从架构、运维和开发三个视角进行展开。通过平凯星辰多年的金融行业实施经验和丰富案例，基于 TiDB 构建金融核心系统是一条可重复、可复制、具备先天技术优势的路径。随着金融科技的兴起，银行业正面临着深刻的变革。

2024-05-13 01:14:07 901

原创从 Oracle 到 TiDB，国有大行打造本地生活 APP 新体验

本文介绍了某国有大行推出的本地生活服务类 APP 在数字时代的创新应用实践。为缓解生活 APP 业务的高 TPS 并发访问以及海量数据带来的性能压力，经过对市场主流分布式数据库的调研，并结合自身业务场景实践，最终决定采用新一代 HTAP 数据库 TiDB 替换原系统中的 Oracle RAC，从而提升整个系统的处理能力、扩展能力和服务能力。面对如此迅猛的业务发展和数据量增长，原有的技术架构（主要采用集中式数据库以及抢券服务的分库分表的技术架构）已经无法满足业务需求，无法做到对应用透明的快速弹性扩展。

2024-05-13 01:13:16 286 2

原创 TiDB + ES：转转业财系统亿级数据存储优化实践

目前，业财系统已成功完成底层数据存储的切换，可以看到近几年来不再担心数据量存储的问题，并且成功接入了更多的业务数据。随着引入了 Elasticsearch（ES），业务人员也不再反馈报表页面超时等问题。这次针对数据存储的优化实质上是对系统的重构，选择方案时考虑了对系统影响范围较小且不影响业务人员使用的因素，这也是优化的核心所在。由于历史原因，业财系统仍存在许多需要优化的方面，如慢 SQL 的持续治理、定时任务优化等。因此，我们需要保持此优化的核心理念，并在后续的重构中继续完善，以使业财系统更加稳定。

2024-05-13 01:12:35 392

原创为什么公共事业机构会偏爱 TiDB ：TiDB 数据库在某省妇幼健康管理系统的应用

在数据库合并后，表的数量分布如下：超过 10 万条数据的表数量为 792 张，超过 100 万条数据的表数量为 156 张，超过 1000 万条数据的表数量为 58 张，以及超过 1 亿条数据的表数量为 5 张。考虑到妇幼数据的重要性，在政务云实施搭建一地两中心，通过 TiCDC 实现主库集群实时将数据写入到从集群，同时从集群担负报表业务以及研发测试库环境，让我们初步实现了一地两中心的设想。在过去的架构下，如果 DBA 或业务人员不小心进行了危险操作，恢复起来非常困难，只能依托于备份恢复来实现。

2024-05-01 02:47:15 954

原创 TiDB Vector 太香啦：以图搜图初体验！

本文是来自 TiDB 社区用户对 TiDB Vector 功能初体验的详细分享，hey-hoho 介绍了他从申请体验到实际操作的全过程，包括创建 TiDB Vector 实例、进行向量检索的初体验，以及实现以图搜图和自然语言搜图的基础应用。在以往，想在关系型数据库中对非结构化数据实现搜索是一件不敢想象的事，哪怕是号称无所不能的 PostgreSQL 在向量插件的加持下也没有获得太多关注，这其中有场景、性能、生态等各方面的因素制约。没错，向量也能加索引，但这个索引和传统的 B+ Tree 索引有些区别。

2024-05-01 02:46:37 934

原创银行核心背后的落地工程体系丨Oracle - TiDB 数据迁移详解

本文作者：张显华，孟凡辉，庄培培数据库技术专家，Oracle ACE，PostgreSQL ACE Director当前，国内大量的关键行业的核心系统正在实现国产化替代，而与此同时，这些行业的数字化转型也正在进入深水区。在信息系统的升级换代过程中，夯实 IT 基础设施是极其关键的。从服务器、操作系统、中间件、数据库等基础软硬件选型到系统架构、应用架构的重新设计，再到数据迁移、系统迁移、系统优化、运维体系重构的一系列工作都是十分具有挑战性的。大多数工作中，都会遇到无法完全参考前人的探索和创新。

2024-05-01 02:45:52 819 1

原创巧用 TiCDC Syncpiont 构建银行实时交易和准实时计算一体化架构

因为落地数据计算量大，并且有准实时性的要求，为了不影响实时业务，落地计算是通过 TiDB 备集群 2 进行计算，该集群的数据来自 TiCDC 从实时集群同步过来的准实时数据。资格应用在实时集群完成一笔业务后，只需要记下业务完成时的时间戳，然后在备集群中去查询 tidb_cdc.syncpoint_v1 中 max(primary_ts)，如果获取到的 primary_ts 大于当时业务记录的完成时间戳，就代表该业务已经在备集群完成，应用就可以针对该笔业务，计算用户当前的资格。

2024-05-01 02:43:54 1081

原创 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 1196

原创 TiDB 慢查询日志分析

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

2024-04-07 02:11:29 997

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

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

2024-04-07 02:10:32 1091

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

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

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

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

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

2024-04-06 23:19:29 644

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

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

2024-04-06 23:18:25 978

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

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

2024-04-06 23:17:32 711

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

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

2024-04-06 23:15:08 912

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

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

2024-04-05 22:49:42 669

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

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

2024-04-05 22:31:53 395

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

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

2024-04-05 22:29:25 795

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

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

2024-04-05 22:28:47 605

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

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

2024-03-03 20:18:51 1048

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

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

2024-03-03 20:18:21 604

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

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

2024-03-03 20:17:48 781

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

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

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

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

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

2024-02-23 17:56:27 1359

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

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

2024-02-23 17:55:54 1181

原创 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 1351

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

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

2024-02-17 22:26:41 2870

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

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

2024-02-17 22:24:53 1180

原创使用 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 1355

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

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

2024-02-16 15:55:23 1274

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

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

2024-02-16 15:54:29 1190

原创一篇文章彻底搞懂 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 810

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

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

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

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

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

2024-02-15 03:21:21 1282

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

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

2024-02-15 03:20:48 1023

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

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

2024-01-12 03:30:46 926

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

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

2024-01-12 03:29:40 457

tidb-in-action-20200611.pdf

空空如也