Tidb

本文介绍了厦门笛卡尔数据（AmzTrends）在面临数据存储挑战时，抉择将其数据分析服务迁徙到 TiDB Serverless 的思路和实际。通过全托管的数据库服务，AmzTrends 实现了全局老本升高 80% 的成果，同时也充沛展现了 TiDB Serverless 在简化架构、晋升性能和降低成本方面的劣势。将来，AmzTrends 打算持续利用 TiDB Serverless 的劣势，扩大业务并晋升竞争力。 厦门笛卡尔数据是一家专一于跨境电商数据分析的 SaaS 公司，AmzTrends 为亚马逊卖家提供品牌剖析(ABA)、商机探测以及广告数据的可视化剖析。目前，AmzTrends 次要以 SAAS 和 Chrome、紫鸟浏览器的插件模式为客户提供数据服务，以订阅模式为美国、日本、中国数万计的跨境电商卖家进步数据服务，帮忙卖家在选品、经营、广告等经营环节提供业余的数据分析决策价值 。 业务挑战AmzTrends 的数据次要以大单表的模式进行存储，最大的表数据量超过 22 亿，字段较多且某些字段很长的大宽表，单表中存在结构化与非结构化的数据结构，因而须要建设大量的索引，占用大量存储空间，而且过期数据还须要定期清理，常常应用 BATCH 进行批量操作，一旦遇到异样无奈无奈事务的一致性，因而数据保护压力微小。 技术痛点在业务初期，AmzTrends 抉择了在百度云上自建 TiDB 集群，资源按月付费。集群规模蕴含 1 个 TiDB 节点、1 个 PD 节点（此种部署形式会侵害 PD 的高可用性，为了节约老本的部署形式，是官网不举荐的高风险计划）、3 个 TiKV 节点，技术人员通过将亚马逊下载的原始 CSV 格局的数据批量写入到 TiDB 中进行数据分析。此外还独自配置了 3 台服务器部署 Spark，进行全量简单的数据计算剖析。但 Spark SQL 与关系型数据库不同，须要专人运维，简单的业务架构造成了资源冗余，使得运维老本较高。 因为集群配置不够加上业余运维团队的缺失，弃用了 Spark，大量简单且数据计算量微小的工作由 Spark 转到 TiDB 间接运行，集群越来越不稳固，数据安全面临重大挑战。在这种状况下，AmzTrends 不得不寻找对技术要求更低且更平安的运维解决方案。在接触到 TiDB Serverless 后，AmzTrends 认为因为都是 TiDB 产品体系，全托管的一栈式数据库服务 TiDB Serverless 不仅能够充分发挥 TiDB 数据库原有的个性和劣势，还能够帮忙公司简化架构，晋升零碎的整体性能和健壮性。所以，AmzTrends 决定将整体利用从百度云部署计划迁入 TIDB Serverless，不仅危险更低且兼容性和性能都能失去无效保障，另外通过数据容量与申请量的老本预估，AmzTrends 发现迁徙后老本能比现有的云服务器部署更低，因而有了这样一次充斥挑战的数据迁徙过程。 ...

导读 本文探讨了分布式数据库在在线扩容方面的挑战， 具体解释了个别分布式数据库和 TiDB 在扩容机制上的不同。 个别分布式数据库在进行在线扩容时，须要从新均衡数据分布，可能会影响零碎的可用性和 IO 耗费。 相比之下，TiDB 的存算拆散架构使得扩容对业务影响较小。 作者：爱喝自来水的猫 起源公众号：数据源的技术后花园。 昨天和他人交换 PingCAP TiDB 时，这位同学对“ TiDB 在线扩容对业务简直没有影响 ” 这一点示意不太了解，诧异 TiDB 到底是怎么做到的。 细聊下来，发现这位同学是一位次要负责集中式和晚期分布式架构数据库的 DBA 人员，比拟相熟 Oracle、Greenplum。 于是我有点了解他的诧异了，因为 Oracle 和 Greenplum 我也是有一点点教训，本文简略针对个别分布式数据库和 TiDB 在扩容机制上谈一点集体的了解。 个别分布式数据库在线扩容是怎么做的集中式数据库因为其架构自身的限度，一般来说想要实现在线扩容是比拟艰难的，这里暂且不予探讨，咱们次要理解一下个别分布式数据库的扩容是如何进行的。不论是 Greenplum 这种 MPP 数据库，还是其它的分库分表数据库，为了实现数据的平衡散布，通常须要在表上定义相干的散布键。通过散布键，再联合哈希算法，能够把数据哈希散列到不同的数据节点中，相似于 hash （ key ） % N （ key 代表散布键， N 代表数据节点编号） 。举个例子，如果一个分布式数据库有 3 个数据节点，表的散布键为 ID （ ID 是一个递增序列），那么基于哈希算法散列后数据的散布大抵如下图所示： 当初咱们须要扩容一个节点，从原来的 3 节点扩容到 4 节点。为了保障原来哈希散列后果的一致性数据须要从新均衡，均衡后的数据分布应该如上面图中所示。能够发现，这个时候大部分的数据根本都搬迁了一遍。先不说数据的迁徙是否对业务造成阻塞，光是这现有的大面积数据平衡足以导致整个零碎的 IO 耗费极高， 重大影响整个零碎的可用性。 Greenplum 在官网文档中还明确指出“ 正在被从新散布的表或者分区会被锁定并且不可读写。当其从新散布实现后，惯例操作才会持续 ”。能够明确的说， Greenplum 晚期版本外面基本就不 反对所谓的“ 在线 ”扩容。 ...

作为一名工程师和创业者，开办 PingCAP 是我进入翻新世界的一次深潜。这段旅程既有令人振奋的发现，也充斥令人生畏的不确定性。作为这次探险之旅见证的 TiDB ，当初已在寰球服务超过 3000 家企业，其中有曾经实现了商业胜利的大公司，也有很多初创企业。 无论是从我本人守业的教训来看，还是从 TiDB 用户的故事中总结，我发现公司倒退初期技术决策远比咱们设想得更加重要，对公司将来的倒退成败的影响微小。领有一个开创性的想法诚然重要，把握产品开发的艺术：预测用户需要、抉择满足业务增长需要的技术才是要害。 在 2024 年及将来倒退的环境中，是否了解和利用正确的技术可能是导致公司业务飞速发展与停滞的关键因素。在这篇文章中，我将分享我对于要害利用开发趋势的察看：对于企业而言，怎样才能建设老本效益高、简化而弱小的数据基础设施。 2024 年值得关注的前三大趋势 首先来回顾一下过来几年的状况。在 2022 年，利用开发被划分为前端技术如 JavaScript、HTML 和 CSS，以及后端技术如 Java、Python 和 Golang。而与此同时，像 Vercel、Next.js 和 Netlify 这样的新兴的平台迅速扭转了这个格局。2022 年下半年，前后端开发的界线开始含糊，交融、并演变成了一个连贯、麻利的体验。 我认为，对于看重简化操作、器重升高“复杂性”的企业来说，麻利仍是影响将来利用开发最重要的因素。依据当下的状况，我总结了三个要害的趋势，心愿可能帮忙正在守业的利用开发者实现“降本增效”：如何通过最小的老本，获取最大的可扩展性。 在当下这个老本优先的技术环境中，置信这些洞察能无效地帮忙大家找到适合本人的路线。 趋势 1 所有皆可服务化，包含 Serverless 自身还记得过来，咱们已经为了让一个“Hello World”上线而与基础设施纠缠不清的日子吗？ 当初那个时代曾经离咱们远去了。 当下的软件开发，从开发阶段就曾经正在迅速地转向服务化——从经典的 IaaS/PaaS/SaaS 到明天的 Serverless 和 API。 “即插即用”才是咱们当下更相熟的体验，因为所有都曾经“服务化”。 Serverless 和 API 技术让咱们能够齐全无需关怀服务器的配置，帮忙开发者更疾速、更不便地构建和交付利用。Serverless 让开发者能够专一于业务逻辑，而不必放心底层基础设施。API 不便了数据交换和资源共享，减速了利用的集成和合作，从而实现了零碎效率和品质的晋升。 趋势 2 JavaScript 的崛起JavaScript 的倒退进入了一个漫长且要害的阶段，它不再仅仅是前端技术的的一个噱头。 全栈 JavaScript 的崛起，特地是 Node.js，曾经含糊了前后端开发的界线，当初开发者通过一种语言就能够实现利用前后端的所有开发工作。 Node.js 的非阻塞 I/O 和事件驱动个性在高并发、I/O 密集型利用中表现出色。 在 Stack Overflow 公布的 2023 年开发者考察中，JavaScript 间断第十一年成为最罕用的编程语言。 ...

非常感谢各位 TiDBer 在之前 【TiDBer 唠嗑茶话会 48】非正式 TiDB 相干 SQL 脚本征集大赛！( https://asktug.com/t/topic/996635 )里提供的各种罕用脚本。 在这篇文章中，咱们整顿了社区同学提供的一系列 TiDB 相干 SQL 脚本，心愿能为大家在 TiDB 的应用过程中提供一些帮忙和参考。这些脚本涵盖了常见场景下的 SQL 操作， 欢送各位 TiDBer 继续补充更新～ 将来，咱们也将整顿更多 TiDB 相干实用指南，帮忙大家更好地理解、使用 TiDB，敬请期待！ 1 缓存表贡献者：@ShawnYan alter table xxx cache|nocache;2 TSO 工夫转换贡献者：@我是咖啡哥 ● 办法一：应用函数 TIDB_PARSE_TSO SELECT TIDB_PARSE_TSO(437447897305317376);+------------------------------------+| TIDB_PARSE_TSO(437447897305317376) |+------------------------------------+| 2022-11-18 08:28:17.704000 |+------------------------------------+1 row in set (0.25 sec)● 办法二：应用 pd-ctl ~$ tiup ctl:v6.4.0 pd -i -u http://pdip:2379Starting component `ctl`: /Users/xxx/.tiup/components/ctl/v6.4.0/ctl pd -i -u http://pdip:2379» tso 437447897305317376system: 2022-11-18 08:28:17.704 +0800 CSTlogic: 03 读取历史数据贡献者：@我是咖啡哥 ...

本文介绍了企查查在数据中台建设中应用 TiDB 的教训和利用。通过从 MySQL 到 TiDB 的迁徙，企查查构建了基于 TiDB+ Flink 的实时数仓框架 ，充分利用了 TiDB 的分布式架构、MySQL 兼容性和欠缺的周边工具等个性，实现了数据的在线化解决。2023 年 9 月，企查查的 TiDB 数据库已降级至 v7.1.1 版本。文章还分享了企查查在应用 TiDB 过程中的一些好用个性和版本升级教训，包含 TiDB 开源社区的沉闷以及 TiDB 的稳定性对其决策的重要性。 本文作者赵河、王云鹤， 企查查大数据架构部 DBA 团队。 企查查是一家专一于企业信用信息服务的科技公司，依靠大数据、人工智能等技术，为企业提供全面、精确、及时的企业信用信息，助力企业降本增效、危险防控。2023 年 5 月，企查查正式公布寰球首款商查大模型——“知彼阿尔法”。该模型基于企查查笼罩的寰球企业信用数据进行训练，能够为司法、金融、风控、政务等人士提供多维度数据服务。 从 MySQL 到 TiDB 的降级之路数据是企查查业务的外围，须要对海量数据进行荡涤、剖析、开掘，能力充沛开释数据价值。在引入 TiDB 之前，企查查应用 MySQL 数据库。MySQL 是一款受欢迎的开源关系型数据库，但存在单机性能瓶颈。当数据量达到肯定规模后，垂直扩容只能无限晋升性能，在高并发写入和简单 SQL 查问等场景下，性能会受到单机性能的限度。 因为 MySQL 是单机数据库，在业务不中断的状况下，只能采纳热备。然而，随着数据量的增长，MySQL 的热备操作会变得越来越慢，对数据库的性能产生较大影响。此外，热备数据的复原速度也较慢。在企查查的数据流向中，爬虫采集到的数据须要先存储到数据库中，而后再由 Flink 进行荡涤。因为 MySQL 不反对将数据间接投递到 Flink，因而须要通过 Flink 来读写数据库，这对 MySQL 库产生了较大的压力。 2019 年底，咱们通过 TiDB 社区接触到 TiDB，并对其产生了浓重的趣味。通过比照选型测试，咱们抉择了 TiDB 数据库，联合 Flink 场景的需要，构建了 Flink+TiDB 的实时数仓框架，利用于企查查数据中台。咱们抉择 TiDB 的次要起因有： ...

在数字化零碎表演重要角色的明天，数据库稳定性成为企业关注的外围问题。对于重要计算机系统而言，突发的性能降落可能对业务造成不可估量的损失。为了稳固数据库性能，用户能够从治理流程动手标准变更的测试，或者利用产品伎俩缩小预期外的变动。然而，这仍旧无奈齐全躲避突发的SQL性能问题，其中的起因包含但不仅限于： 数据量和数据分布激烈变动，从前被验证过的执行打算可能变得效率更低。数据库中的查问变得越来越简单，优化器对执行打算的抉择存在不可控因素。频繁的业务更新给测试带来微小压力，未经充沛验证的 SQL 有潜在的性能问题 。对于一些对提早十分敏感的利用而言，这些潜在问题有可能对业务造成不可估量的损失。 如何升高这类不可控的突发问题对业务的影响，是摆在每个管理者背后的难题。 做为资源管控的一部分，TiDB 在 7.2.0 引入 Runaway Queries 治理，并继续加强，旨在通过系统化的伎俩缓解上述难题。 本文将从从实用场景、实现原理等角度具体介绍 TiDB 的 Runaway Queries 治理性能，并通过一个示例展现其在零碎中的作用。 什么是 Runaway QueriesRunaway Queries 是指执行工夫或耗费资源超出预期的查问，在运行工夫和资源耗费上有显著特色。 Runaway Queries 治理旨在提供一种高效、可控、自动化的资源辨认和管控机制，以升高突发 SQL 性能问题带来的负面影响，爱护简单工作负载下零碎的稳定性，让 TiDB 更加牢靠。 Runaway Queries 治理实用哪些场景● 为了保障重要零碎的服务质量，须要可能自动识别并解决异样 SQL 性能问题。 ● 当遇到突发 SQL 性能问题，但又没有立刻无效的修复伎俩时，心愿长期缓解其影响。 ● 当已知个别 SQL 有平安或性能问题，心愿退出黑名单或对其进行限流。 Runaway Queries 治理能做什么Runaway Queries 治理次要提供两个重要能力，即对查问的 “辨认” 和 “处理” 。 3.1 查问的辨认TiDB 资源管控模块提供 两类 辨认形式 ● 动静辨认 - 依据运行时规定辨认 。指依据 SQL 理论运行指标自动识别 （通过 resource group 定义），目前反对利用 EXEC_ELAPSED 设置理论执行工夫，即当查问运行工夫超过 EXEC_ELAPSED 的定义时，这个查问会被辨认为 Runaway Query。比方： ...

过来，TiDB 因为不反对存储过程、大事务的应用也存在一些限度，使得在 TiDB 上进行一些简单的数据批量解决变得比较复杂。 TiDB 在面向这种超大规模数据的批处理场景，其能力也始终在演进，其复杂度也变得越来越低： ○ 从 TiDB 5.0 开始，TiFlash 反对 MPP 并行计算能力，在大批量数据上进行聚合、关联的查问性能有了极大的晋升 ○ 到了 TiDB 6.1 版本，引入了 BATCH DML ( https://docs.pingcap.com/zh/tidb/stable/non-transactional-dml ) 性能，该性能能够将一个大事务主动拆成多个批次去解决，在单表根底上进行大批量更新、删除、写入时可能大幅晋升解决效率，同时防止了大事务所产生的一些影响。 ○ 而到了 7.1 LTS 版本，正式 GA 了 TiFlash 查问后果物化 ( https://docs.pingcap.com/zh/tidb/stable/tiflash-results-mater...查问后果物化 ) 的性能，使得 insert/replace into ... select ... 这种操作中的简单 select 可能利用 TiFlash MPP 并行处理的能力，大幅晋升了这种操作的解决性能。 ○ 前不久刚公布的 7.5 LTS，正式 GA 了一个 IMPORT INTO ( https://docs.pingcap.com/zh/tidb/stable/sql-statement-import-... ) 的性能，该性能将本来 tidb-lightning 的物理导入能力集成到 TiDB 计算节点上，应用一条 SQL 语句就能够实现大批量数据的导入，大幅简化了超大规模数据写入时的复杂度。 TiDB 上之前有哪些批处理计划INSERT INTO ... SELECT 实现查问和写入● 现状：实用于小批量数据处理，性能较高 ...

版本日期备注1.02024.2.18文章首发本文的的源码剖析全副基于TiDB6.5来做剖析。1.引子如果让你做一个分布式数据库的优化器，面对以下的SQL，你会想到什么好的办法去执行他们呢？ SELECT id, name FROM person WHERE age >= 18 or height > 180 limit 100;：从条件上看，咱们看到条件其实是二选一的： age >= 18 or height > 180。基于这种状况，咱们必定会去抉择有索引的数据，如果都有索引or都没有，那么必定抉择扫描行数起码的数据。如果有一些算子在外面的话，则额定须要思考数据的就近准则——有些算子在局部架构下能够充分利用MPP的能力，而有些则不行。SELECT orders.order_id, customers.customer_name, orders.order_date FROM orders LEFT JOIN customers ON orders.customer_id=customers.customer_id;分布式数据库中的join，最优的形式就是小表播送到大表数据所在的中央。那么首先咱们得晓得谁是小表，谁是大表。2.统计信息收集依据后面的两个例子，咱们能够发现——如果咱们须要找到SQL对应的最佳打算，咱们会须要一些表的元数据，或者说是统计信息。从惯例的角度来说，以下统计信息是必须收集的： 表的总行数每列数据的均匀大小每列数据的基数：即NDV（distinct value）列的NULL值个数如果是事务型的（行式存储），那么还要思考索引均匀长度、值的散布等等。 如果是剖析型的（列式存储），那么还须要思考相干列的最大值、最小值等等。 而统计形式的收集，会有多种形式。次要是思考资源和准确性之间的Trade off。常见的有： TopN：相干数据呈现次数前 n 的值。直方图：用于形容数据分布图的工具。依照数据的值大小进行分桶，并用一些简略的数据来形容每个桶，比方落在桶里的值的个数。2D直方图：因为直方图无奈反馈列之间的关联，能够用2D直方图（联结散布）做到，但空间占用也比拟多。Count-Min Sketch：相似哈希表加上计算器的实现。能够用很少的数据来形容整体数据的个性。HyperLogLog：一种估算海量数据基数的办法。很多状况下，统计并不需要那么准确。工程方面要在应用资源和准确性里找均衡。因而有人提出用HLL，这是一种占用资源少，但能给出较为精确的近似后果的算法。TiDB收集的统计信息见：https://docs.pingcap.com/zh/tidb/v6.5/statistics#%E7%9B%B4%E6... 3.代价的评估一个SQL真正的物理执行打算可能是有多个的。在以统计信息为根底之上，咱们还须要退出相应的权重，举个例子： 如果可能在内存中计算实现，就不必去重复发动本地IO如果能在本地IO中实现，就不要去发动网络申请等等... 这在TiDB的代码中也有对应的默认值。 DefOptCPUFactor = 3.0DefOptCopCPUFactor = 3.0DefOptTiFlashConcurrencyFactor = 24.0DefOptNetworkFactor = 1.0DefOptScanFactor = 1.5DefOptDescScanFactor = 3.0DefOptSeekFactor = 20.0DefOptMemoryFactor = 0.001DefOptDiskFactor = 1.5DefOptConcurrencyFactor = 3.0var defaultVer2Factors = costVer2Factors{ TiDBTemp: costVer2Factor{"tidb_temp_table_factor", 0.00}, TiKVScan: costVer2Factor{"tikv_scan_factor", 40.70}, TiKVDescScan: costVer2Factor{"tikv_desc_scan_factor", 61.05}, TiFlashScan: costVer2Factor{"tiflash_scan_factor", 11.60}, TiDBCPU: costVer2Factor{"tidb_cpu_factor", 49.90}, TiKVCPU: costVer2Factor{"tikv_cpu_factor", 49.90}, TiFlashCPU: costVer2Factor{"tiflash_cpu_factor", 2.40}, TiDB2KVNet: costVer2Factor{"tidb_kv_net_factor", 3.96}, TiDB2FlashNet: costVer2Factor{"tidb_flash_net_factor", 2.20}, TiFlashMPPNet: costVer2Factor{"tiflash_mpp_net_factor", 1.00}, TiDBMem: costVer2Factor{"tidb_mem_factor", 0.20}, TiKVMem: costVer2Factor{"tikv_mem_factor", 0.20}, TiFlashMem: costVer2Factor{"tiflash_mem_factor", 0.05}, TiDBDisk: costVer2Factor{"tidb_disk_factor", 200.00}, TiDBRequest: costVer2Factor{"tidb_request_factor", 6000000.00},}4.执行打算枚举与择优当咱们能够评估出物理执行打算的代价时，将会枚举所有能够用上物理执行打算，并在其中抉择代价最小的物理执行打算。个别枚举分为两个流派： ...

导读 作业帮是一家成立于 2015 年的在线教育品牌，致力于用科技伎俩助力教育普惠。通过近十年的积攒，作业帮使用人工智能、大数据等技术，为学生、老师、家长提供学习、教育解决方案，智能硬件产品等。随着公司产品和业务场景越来越丰盛，数据量越来越大，业务方对数据库的应用需要也越来越多元化。本文介绍了作业帮对 TiDB 的摸索历程，以及逐步落地多个业务场景的应用实际。 TiDB 在作业帮的摸索和推广作业帮外部最开始接触的版本是 TiDB v4.0.9。相较于 TiDB v3.x，v4.0.9 在性能、治理、易用性等方面都有了质的晋升，同时 TiDB 的生态组件以及社区也都达到了十分欠缺的水平，能够说是一个标志性的版本。2020 年，咱们正式开始调研测试 TiDB v4.0.9, 以实现团队在分布式数据库的技术储备，从而更好地服务公司的业务需要。 1. 探索期: 应用 TiDB 隔离对在线 MySQL 集群有性能影响的查问申请 研发人员须要不定时查问线上实时数据，以此来确定业务数据的状况或者对局部业务数据做汇总剖析。 ● 引入 TiDB 之前：业务人员是直连到 MySQL 从库查问数据，如果扫描的数据量太大常常会引起线上 MySQL 节点性能抖动甚至机器的 io/cpu 资源瓶颈。 ● 引入 TiDB 之后：通过数据同步工具 DM 将 MySQL 的数据以全量+实时增量的形式同步到 TiDB 中，实现在线、离线申请的隔离性。 在这个摸索阶段，一方面满足了离线查问的隔离性的要求，另一方面也相熟了 TiDB 及其生态组件的个性以及应用办法。 2、推广期：外部分享+主动出击 通过半年左右工夫的应用，在对 TiDB 有肯定理解的根底上，咱们开始在公司外部进行 TiDB 相干的技术分享，向研发人员介绍 TiDB 的一些个性和在大数据量场景下的劣势，并被动接触各个业务线去寻找适合的应用场景。研发人员也陆续将一些业务 外部应用的报表服务 接入到离线 TiDB 集群中。 在线业务落地从 0-1在各个团队应用和相熟 TiDB 一段时间后，咱们开始针对已有业务的痛点或者将来新业务的布局，逐步将视线转移到 TiDB。通过配合业务一起测试验证，开始正式将在线业务迁徙到 TiDB 中。 ...

导读 骏伯网络是一家聚焦挪动互联网营销服务的公司，综合经营治理平台是其外围业务零碎，包含营销零碎、订单、领取以及与内部零碎的交互服务接口。为满足多元化的业务倒退需要，升高零碎间交互链路的复杂性，晋升业务连续性，以及实现降本增效的整体规划，骏伯网络抉择将 TiDB 作为综合经营治理平台的底层数据库。通过上线实践证明，TiDB 为骏伯在业务连续性、性能晋升、数据资源整合、降本增效等方面带来了显著价值。将来，骏伯将扩大 TiDB 在数据分析类业务场景中的利用，晋升数据实时剖析能力，放慢业务翻新的步调 。 本文作者：骏伯网络 唐帆，PingCAP 贺美存 骏伯网络简介 广州骏伯网络是一家以数据驱动的科技公司，聚焦挪动互联网营销服务，保持以客户为核心，深耕 APP、运营商、金融保险等行业，以解决客户营销痛点为指标，为客户提供全链路营销服务。骏伯网络于 2015 年挂牌新三板，间断 5 年入选广州将来独角兽企业，已累计为超过 1000 家企业、超过 1600 款产品提供推广服务，长期与头部 APP、三大运营商以及出名金融产品进行单干，具备丰盛的客户资源 。 业务痛点与数据库技术选型1 业务简介、现状和痛点 综合经营治理平台是骏伯最外围的业务零碎，次要笼罩营销、渠道、媒介、创意等业务部门，底层数据库蕴含 OLTP、OLAP 两种，业务零碎次要蕴含营销、订单和信息展示三局部。订单数据均会回流到订单服务模块，订单胜利后会推送到下单流程，同时能够在平台中及时查看订单信息。 综合经营治理平台利用架构图 整套利用由 40 多个微服务组成，底层数据库采纳 20 多套 MySQL 主备高可用架构，部署在 4 台物理服务器上，主备穿插部署的模式。大数据分析平台采纳 Hadoop 生态，数据分析模式为 T+1 的离线模式。 综合经营治理平台是一套面向互联网用户的实时交易系统，对可靠性和性能要求较高。物理服务器的硬件故障会对生产运维和业务连续性造成较大的挑战和影响，各套数据库绝对互相独立，须要实现跨库的数据实时共享。 2 技术选型要求 为了配合零碎革新，解决业务连续性、数据扩大能力、资源利用率和性能等生产环境面对的痛点，骏伯启动了对国内多家头部原生分布式数据库的测试选型，具体的要求包含： 业务连续性 任何硬件单点故障对数据库集群无影响，在无人工干预的状况下，业务可能继续对外提供失常服务。数据库应具备原生分布式高可用能力，可依据业务重要性灵便设定数据正本数，具备异地灾备能力，可满足机房级高可用要求。 数据扩大能力 满足企业疾速的业务变动需要，反对横向扩大能力，对业务无入侵性。数据库采纳松耦合的存算拆散架构，按需灵便扩大计算或存储能力，数据可主动重均衡，通过节点扩大实现性能的线性增长。 利用通明迁徙能力 数据库可兼容和连续现有的利用架构和代码，提供数据在线的通明迁徙能力，升高利用革新和迁徙难度。 数据实时压缩能力 数据库应具备库内实时在线的压缩能力，在性能不受影响的前提下，节俭数据存储的老本。 数据可恢复性 数据库需提供物理和逻辑备份，反对可选对象粒度的全量和增量备份，可将集群复原到任何工夫点。在数据误操作的状况下，提供闪回能力。 通过多轮比照测试和业务场景的验证，TiDB 满足了本次技术选型的所有指标。骏伯网络抉择将 TiDB 作为综合经营治理平台的底层数据库。 TiDB 在骏伯网络综合经营治理平台的利用从整体数据规模、业务拜访申请、资源高可用等维度思考，咱们制订了具体的部署计划。联合现有利用和数据库状况，咱们设计了分批业务迁徙打算，历时 3 个月胜利实现了所有利用的平滑迁徙和部署。在主核心部署一套蕴含 4 台物理服务器的 TiDB 集群，用于撑持综合经营治理平台。主核心集群通过 BR 实现数据库备份工作。MySQL 数据的迁徙工作由 DM 组件实现，以确保数据迁徙的顺利进行。将来，咱们打算在异地构建一套单正本的集群，通过 TiCDC 组件搭建数据容灾的演练环境，从而实现异地灾备。 ...

导读 本文介绍了应用 Coze 平台搭建 TiDB 文档助手的过程。通过比拟不同 AI Bot 平台，突出了 Coze 在插件能力和易用性方面的劣势。文章深刻探讨了实现原理，包含知识库、function call、embedding 模型等要害概念，最初胜利演示了如何在 Coze 平台上疾速创立 TiDB Help Bot 。 本文作者 Weaxs，TiDB 社区布道师。 引言目前市面上有很多搭建 AI Bot 的平台和利用，开源的有 langchain、flowise、dify、FastGPT 等等。字节之前也推出了 Coze，之前试过 Dify 和 FastGPT，目前感觉 Coze 的插件能力有很多，且易用性方面、搭建效率方面也强于其余平台（例如 langchain 或 flowise 须要搭建绝对简单的编排逻辑能力实现大模型调用互联网信息的拓展能力，然而 Coze 则是间接增加 plugin 且不指定任何参数就能实现）。 于是想尝试用 Coze 搭建一个 TiDB 文档助手，顺便钻研厘清 Coze 平台是如何形象一些大模型和其余能力来进步易用和搭建效率的。 实现原理首先咱们先抛开 Coze 平台，在大模型提供能力的根底上如何实现调用文档数据？ 这里给出两种模式：知识库 和 function call。知识库的长处在于对非实时数据有一个绝对精确的近似查问，function call 的长处在于能够实时取得最新的数据，当然也包含文档数据。 Coze 平台中的 plugins 实现了 function 模式，同时也提供了 knowledge 知识库能够治理本地和在线的文档。 1 embedding + 向量库 ...

作者丨 caiyfc 来自神州数码钛合金战队 神州数码钛合金战队是一支致力于为企业提供分布式数据库 TiDB 整体解决方案的业余技术团队。团队成员领有丰盛的数据库从业背景，全副领有 TiDB 高级资格证书，并沉闷于 TiDB 开源社区，是官网认证合作伙伴。目前已为 10+ 客户提供了业余的 TiDB 交付服务，涵盖金融、证券、物流、电力、政府、批发等重点行业。 背景笔者最近在驻场，发现这里的 tidb 集群是真的多，有将近 150 套集群。而且集群少则 6 个节点起步，多则有 200 多个节点。在这么宏大的集群体量下，巡检就变得十分的繁琐了。 那么有没有什么方法可能代替手动巡检，并且可能疾速精确的获取到集群相干信息的办法呢？答案是，有但不齐全有。其实能够利用 tidb 的 Prometheus 来获取集群相干的各项数据，比方告警就是一个很好的例子。惋惜了，告警只是获取了以后数据进行告警判断，而巡检须要应用一段时间的数据来作为判断的根据。而且，告警是曾经达到临界值了，巡检却是要排查集群的隐患，提前开始布局，防止出现异常。 那间接用 Prometheus 获取一段时间的数据，并且把告警值改低不就行了？ 意识 PromQL要应用 Prometheus ，那必须要先理解什么是 PromQL 。 PromQL 查询语言和日常应用的数据库 SQL 查询语言（SELECT * FROM ...）是不同的，PromQL 是一 种 嵌套的函数式语言 ，就是咱们要把需 要查找的数据形容成一组嵌套的表达式，每个表达式都会评估为一个两头值，每个两头值都会被用作它下层表达式中的参数，而查问的最外层表达式示意你能够在表格、图形中看到的最终返回值。比方上面的查问语句： histogram_quantile( # 查问的根，最终后果示意一个近似分位数。 0.9, # histogram_quantile() 的第一个参数，分位数的目标值 # histogram_quantile() 的第二个参数，聚合的直方图 sum by(le, method, path) ( # sum() 的参数，直方图过来5分钟每秒增量。 rate( # rate() 的参数，过来5分钟的原始直方图序列 demo_api_request_duration_seconds_bucket{job="demo"}[5m] ) ))而后还须要认识一下告警的 PromQL 中，经常出现的一些函数： ...

导读 随着金融行业数字化转型的需要，银行外围零碎的降级革新成为重要议题。杭州银行胜利上线以 TiDB 为底层数据库的新一代外围业务零碎，该实际采纳利用与基础设施解耦、分布式透明化的设计开发理念，推动银行外围零碎的整体降级。 本文聚焦银行外围零碎演进，联合 TiDB在杭州银行新一代外围的实际，深刻解析“分布式透明化”理念，心愿能为同行业的转型降级提供参考。 本文作者：韩锋 ，CCIA（中国计算机协会）常务理事，前 Oracle ACE、腾讯 TVP、阿里云 MVP。有着丰盛的一线数据库架构、软件研发、产品设计、团队治理教训。曾负责多家公司首席 DBA、数据库架构师等职。在云、电商、互金、互联网、银行等行业均有涉猎，精通多种关系型数据库，对 NoSQL 及大数据相干技术也有涉足，实践经验丰盛。曾著有数据库相干著述《SQL 优化最佳实际》、《数据库高效优化》。《韩锋频道》公众号作者。 作为国家支柱性行业，金融业在国民经济中施展着无足轻重的作用。近些年来金融业的经营模式和服务形式都产生了很大变动，这对于金融科技提出更高要求。与此同时，国内金融机构还面临国产化诉求，用以应答脱钩、断供等潜在危险。作为数据利用洼地，金融企业普遍存在业务简单、可用性要求低等特点，尤其是以银行外围零碎为代表。对银行外围零碎提供做架构降级、国产化革新是危险极大的一项工程。 近期，国内杭州银行新一代外围零碎胜利上线，引起业内广泛关注。行方从开始就秉承着利用与基础设施解耦架构思维、分布式透明化的设计开发理念，通过与国产分布式数据库 TiDB 的通力合作，实现此次外围零碎的胜利上线。这为国内宽广同类型银行降级，带来踊跃参考意义；其背地的实际过程也很值得思考。 银行外围零碎演进及察看银行外围零碎，也称为 Core Banking，是银行解决贷款、贷款业务为主的外围 IT 零碎。作为撑持业务营运的要害零碎和银行信息化的重要组成部分，被称作银行 IT 零碎的“心脏”。同时，银行外围在整个银行 IT 零碎架构中是其余业务子系统的根底，处于承前启后的要害地位。外围零碎在金融服务能力、解决性能等方面，对银行日常经营的业务与流程优化、晋升客户体验度、推动业务改革或翻新等方面起着决定性作用。 从历史演进来看，银行外围零碎经验了从手工时代到 PC 时代，到联网联机、数据大集中，再到以客户为核心的倒退历程。从上世纪九十年代开始，银行外围零碎技术架构从数据集中路线演进而来的 “胖外围” 期间；到本世纪头十年因外围零碎宏大且耦合重大，将辅助性能拆分后造成的 “瘦外围” 期间；再到近十年来互联网对银行业务产生影响，银行开始构建分布式外围，造成以稳态集中式架构与敏态分布式架构并存的状况。特地是在 2017 年，中国人民银行提出倒退布局，激励施行架构转型，包含采纳分布式架构，这一趋势推动了分布式外围零碎的倒退。分布式外围零碎的要害指标是冲破单机零碎的数据存储和解决能力下限，同时减小单点故障对整个零碎的影响。这通过多机分片解决数据库来实现，进步了银行零碎的健壮性和可用性。 在推动分布式外围倒退中，以“微服务、单元化”为代表的架构设计理念成为支流。 前者是一种软件架构格调，其应用程序被拆分为一组小型、松耦合的、自治的服务。每个服务都能够独立地进行开发、部署和扩大，并通过轻量级的通信机制（如 HTTP、音讯队列等）进行相互通信。其外围准则是将简单的单体应用程序拆分成更小、更可治理的部件，每个部件专一于实现一个特定的业务性能。后者则通过把一部分计算资源和一部分数据资源进行逻辑上的绑定，造成一个标准化的处理单元。每个处理单元具备残缺的业务能力，但只解决全量数据中的一部分，简略了解一个单元就相当于一个小分行。其外围准则是将业务拆分更为细小的处理单元，并可依据须要进行扩大。 无论采取两种架构之一或兼而有之，都对底层基础设施提出更高的要求，特地是数据的次要载体-数据库。 相对而言，单元化更偏向于通过数据拆分，将数据造成一个自蕴含的处理单元，对数据库的承载体量、解决能力能够通过单机或集中式数据库实现。但因为单元化架构学习、施行老本很高，比拟适宜于体量较大或有异地多活布局的银行。对以城商行为代表的宽广中小规模银行来说，因其技术底子绝对较薄、业务零碎多以外购或合作开发为主且财力投入绝对无限，上述起因都造成了单元化对于中小行不太适宜，那么中小行也更多采纳“微服务+分布式数据库”的路线。 随着近十年国产分布式数据库的疾速倒退，其成熟度、稳定性等已趋于欠缺，开始在金融外围零碎为代表的重要业务零碎中尝试应用。当然， 这一新架构产品对架构、开发、运维等都带来很多变动 。特地是架构、研发层面，之前业务零碎在设计上多是以集中式数据库能力为根底进行的，对于分布式架构存在诸多差别。如何升高这一差别，尽量复用之前架构设计，甚至做到将利用与底层基础架构解耦成为要害。这里提出一种新的观点-“分布式透明化”，即在分布式架构下依然可沿用单机或集中式数据库的开发设计习惯，做到齐全无感。这里不是简略的与某种数据库的语法、运维兼容的问题，而是从架构之初就能够通明解决。正是这种分布式透明化能力给城商行等中小银行的外围零碎国产化及降级革新，提供了一条平滑的翻新之路。 TiDB 在杭州银行新一代外围的实际近期，杭州银行以 TiDB 为底层数据库的新一代外围业务零碎胜利投产上线 ，也是业内首个理论投产的云原生、分布式、全栈国产化的银行外围零碎上线，是金融科技领域冲破要害核心技术利用的重大实际，标记着杭州银行外围业务零碎实现齐全自主可控和架构降级。这一实际中正是遵循了“分布式透明化”这一理念，为宽广同业建设外围零碎架构转型提供了参考。杭州银行此次外围系统升级，在布局之初就将业务与基础设施解耦放在首要因素，从多角度对底层数据库提出很高要求。 从架构角度来看， 首要问题就是解决所谓透明化问题，即对数据库建模、设计、开发过程仍可沿用之前的实际，尽量减少因引入分布式数据库所造成的差别。一方面业务零碎开发中很难防止人员的更迭，另一方面很多业务零碎也是采纳合作开发模式。透明化对于最大化保留原有开发积攒，有着重要意义。其次就是须要数据提供全面的兼容能力，对上能够兼容新型利用架构，包含微服务、云原生及可能会有单元化；向下可兼容具备自主创新能力的根底平台。第三则是心愿数据库提供规范而非定制化能力，这也是基于业内实际，很多国产数据库当面临性能有余时会提供定制开发已解决问题，但这是不利于用户长期技术策略的。 从研发角度来看， 针对数据分片后不可避免的分布式事务问题，在框架层尚无成熟欠缺的分布式事务解决方案下，充分利用底层数据库的分布式事务能力来解决，这样开发简化很多。弱化对数据库个性性能的依赖，将很多性能前置到框架层来解决。例如针对数据库中罕用的序列性能，即可在框架层提供分布式全局发号器来解决，不再依赖数据库实现。针对数据库常常需面对的热点问题，尽管分布式架构能在肯定水平上缓解这一问题，但在开发方面仍能够有多重伎俩去前置解决。例如，通过缓存与数据库的联合，升高对数据库热点对象的拜访。通过将业务解决异步化，将对数据库压力分散开来。这些措施都能够无效解决热点问题。 针对具备金融特点的跑批类业务，通过将解决工作打散并行能够无效进步吞吐量，打消批量热点，充分利用分布式数据库的丰盛算力。例如针对银行外围零碎日终及日间批量解决采纳带有业务属性的散布式调度器，充分发挥分布式数据库 TiDB 反对多会话及高并发解决个性，在原有作业流程根底上由调度器应用分段 SQL 语句或分片算法将工作平均分配，并将分片工作同时下发到多个执行器节点并行处理晋升批量解决性能；同时批量工作执行器节点和 TiDB 数据库节点均可实现弹性程度扩大，保障杭州银行在将来业务快速增长、数据规模急剧扩充的状况下，批量解决性能不降级。 从运维角度来看， 引入分布式数据库会带来不小的挑战，当然同时也有着显著收益。从数据完整性角度来看，以 TiDB 为代表的原生分布式架构产品提供的是基于共识协定的多正本机制，能保障数据的强一致性和完整性。从可行性来看，分布式数据库产品多通过三核心仲裁形式来提供整体高可用性，但这一形式老本较高。TiDB 在实现上提供了更为经济的强双核心计划，即当满足同城低提早的条件下，可通过两核心提供同样的可用性保障能力。通过同城强双核心与异地备份的联合，最终达到 RPO=0 的可用性规范。这也是很多金融行业用户最终抉择分布式数据库架构的起因，其不仅可提供高并发、高扩展性，其整体较高的可用性及容灾能力也是被抉择要害理由之一。同时这一架构还提供跨核心的多写多读能力，这对于业务侧实现业务同城多活具备重大意义。 ...

作者丨hey-hoho 来自神州数码钛合金战队 神州数码钛合金战队是一支致力于为企业提供分布式数据库 TiDB 整体解决方案的业余技术团队。团队成员领有丰盛的数据库从业背景，全副领有 TiDB 高级资格证书，并沉闷于 TiDB 开源社区，是官网认证合作伙伴。目前已为 10+ 客户提供了业余的 TiDB 交付服务，涵盖金融、证券、物流、电力、政府、批发等重点行业。 背景TiDB 集群的监控面板外面有两个十分重要、且十分罕用的指标，置信用了 TiDB 的都见过： ○ Storage capacity：集群的总容量 ○ Current storage size：集群以后曾经应用的空间大小 当你筹备了一堆服务器，通过各种思考设计部署了一个 TiDB 集群，有没有想过这两个指标和服务器磁盘之间到底是啥关系？ 反正咱们常常被客户问这个问题，以前尽管能说出个大略，总体方向上没错，然而深究一下其实并不谨严，这次翻了源码彻底把这个问题搞清楚。开始之前再卖一个关子，大家能够看看本人手上的集群监控有没有这种状况： TiKV 实例的已用空间（store size）+ 可用空间（available size） ≠ 总空间（capacity size） 盘越大越显著。 再认真点看，监控上显示的总容量大小和 TiKV 实例所在盘大小也不匹配。 是不是有“亿点”意外。 论断后行○ PD 监控下的 Storage capacity 和 Current storage size 来自各个 store 的累加，这里 store 蕴含了 TiKV 和 TiFlash ○ Current storage size 蕴含了多个数据正本（TiKV 和 TiFlash 的所有正本数），非实在数据大小 ○ TiKV 实例容量统计的是 TiKV 所在磁盘的整体大小与 raftstore.capacity 参数较小的值，同时监控用的 bytes(SI) 规范显示，就是说不是用 1024 做的转换而是 1000，所以和 df -h 输入的盘大小有差距 ...

<article class=“article fmt article-content”><p>2023 年曾经过来，TiDB 通过了一年的迭代，又往前提高了一点点，咱们十分骄傲的看到，TiDB 正在一直地帮忙咱们的客户胜利，包含但不限于：</p><p>○ 首个云原生、分布式、全栈国产化银行外围业务零碎投产上线丨TiDB × 杭州银行</p><p>○ 国产数据库的珠穆朗玛峰，到底在哪里？ </p><p>○ Scaling TiDB To 1 Million QPS ( https://blog.flipkart.tech/scaling-tidb-to-1-million-qps-d556… )</p><p>○ …… </p><p>要获得下面的问题并不容易，在 2023 年咱们也经验了很多，上面，我会简略的梳理回顾下，咱们在 2023 年一些有意思的事件。</p><p></p><h2>TiDB 6.5</h2><p>在 2022 年的年底，咱们公布 了 <strong>TiDB 6.5 LTS </strong>版本， 这个版本我是十分期待的。理论后果来看，到 2023 年截止，TiDB 6.5 曾经逐步成为客户最重度的应用版本。</p><p>在 TiDB 6.5 之前，用户高频吐槽咱们的一个问题就是 - 有时候来了一个大查问，间接把 TiDB Server 给弄 OOM 了，这样影响了一批其余的申请。所以咱们在 TiDB 6.5 重点解决了 OOM 问题，后果也是很令人满意的，下图是咱们理论在 TiDB Cloud 下面客户集群的报警状况，能够看到，TiDB OOM 的问题降落的非常明显。</p><p></p><p>不光在 TiDB Cloud 下面，我本人也从客户那边失去了十分多的间接反馈。 除了 OOM 问题的缓解，在 TiDB 6.5 外面，咱们还重点的优化了 DDL 的速度，加强了优化器的能力等等。 所以在 2023 年一开始，我是信念满满的，感觉 TiDB 6.5 版本曾经很不错。 当初想想，我那时候真的太天真了。</p><p>『不错』这个 flag 立了之后，立即被打脸。TiDB 6.5 解决了不少之前客户遗留的问题，不过当客户开始更大规模应用 TiDB， 把 TiDB 用到更 critical 或者更简单的场景的时候，新的问题又来了。</p><h2>TiDB 7.1</h2><p>在 2023 年有一段时间，我个别见到做数据库的敌人，都会问他们一个看起来比拟好玩的问题，『你的客户有试过一次性导入一张 50TB 大小的单表吗？』如果是做 TP 数据库的敌人，通常会来一句『哪有这样的场景？』</p><p>嗯，我原本也认为，『哪有这样的场景？』，直到咱们一个北美的客户真的进行了这样的操作。他们在 4 月份的时候开启了一次单表 50TB 的导入操作，开始的后果是悲催的 - 无论客户怎么操作，导入都遇到各种各样的问题，包含但不限于数据歪斜打满了一台 TiKV 的磁盘，PD 在 scatter region 的时候太慢导致的导入 timeout 等。原本咱们心愿帮忙客户去操作导入，这样咱们遇到问题之后能间接修复，而后持续，不过这个提议被客户间接回绝，因为他们就是要本人亲自验证，能一次性的导入胜利。</p><p>随着客户屡次导入失败，客户怄气的放下狠话，如果一周后还搞不定，那么就不必 TiDB 了。压力到了咱们这边，咱们开始了简直连轴转的导入加强工作，终于在一周后，客户间接一次性的单表 50TB 数据导入胜利。</p><p>这一次的导入优化经验，让咱们学习到了很多，如果有机会前面能够再开文章具体阐明。当然也有很大的播种，在北美这个客户导入胜利一周当前，咱们日本的一个客户进行了单表 100TB 的数据导入，后果当然是十分振奋人心的。</p><p>挑战还不仅仅限于此，又是北美的一个重要客户，他们将他们本人十分外围的一个元信息管理的业务放到了 TiDB 下面，而后这个业务大部分时候都只是波及到 meta 的简略操作，属于 TP workload，不过也有不少的时候，他们须要间接进行一些轻量级的简单查问，而且明确要求了当这样的简单查问过去的时候，简直齐全不能影响他们的 TP workload。这个在 TiDB 6.5 还是比拟有挑战的。而不光是这个客户，咱们也发现，越来越多的客户将多个负载跑在一个 TiDB 集群，负载之间的隔离就变得尤其重要。于是咱们跟这个客户一起开始了 resource control 的开发，也获得了十分不错的成果。</p><p></p><p>下面只是分 享了 <strong>TiDB 7.1 LTS </strong>两个功 能的开发经验，咱们也十分欣慰的看到，这些性能都失去了客户十分踊跃正向的反馈。也动摇了咱们 - 聚焦样板客户的业务场景，一直打磨 TiDB，反对好这些业务场景，复制到其余客户，助力客户胜利。</p><h2>TiDB 7.5</h2><p>随着越来越多的客户将 TiDB 用在十分外围的零碎下面，在公布 TiDB 7.1 之后，咱们决定，在 <strong>TiDB 7.5 LTS </strong>版本，咱们将专一于产品质量的晋升。产品质量是一个很大的话题，这里仅仅列一些咱们做的一点工作。</p><p>咱们认为，要管制版本品质，一个十分奢侈的逻辑就是少做 feature，当然咱们不可能不做 feature，所以这肯定是基于咱们以后团队带宽的一个均衡和折中。上面是咱们大略统计的不同 LTS 版本开发的 feature 个数，能够显著的看到，趋势是显著缩小的。因为做的 feature 少，多进去的带宽咱们就用到更多的品质加固的工作下面，所以我十分有理由置信，咱们的 TiDB 的品质会越来越好。</p><p></p><p>缩小 feature 个数对于研发工程师来说是一个极大的挑战，因为在很多研发的脑子外面，还是固有的认为我要通过做更多的 feature 来拿到更好的绩效，以及降职。所以在 2023，咱们花了大量的工夫来解释为啥咱们要管制 feature 个数，加固品质等，而且也会在绩效上面对相干工作的同学进行了歪斜。</p><p>这里大家可能会有另一个纳闷，就是咱们 feature 做的少，产品的竞争力是不是就不行了？之前我也是这样的认为，不过起初我发现，我本人做为程序员也一样，咱们太容易低估业务的复杂度，而高估本人的技术能力，所以总认为本人能开发很多 feature。不过起初我意识到，与其开发 10 个半吊子的 feature，真的还不如好好的开发 5 个或者更少的开箱即用的 feature，这样给客户的感触会更好。这也是咱们前面会继续致力的指标。</p><p>譬如在 7.5 外面，咱们花了大量的经验依然去欠缺和优化 resource control，譬如咱们引入了 runaway query 机制，给用户提供了对于 heavy query 的管制机制，更好的避免了一些突发 heavy query 引起的 TP 业务抖动问题，成果如下：</p><p></p><p>除了管制 feature 的个数，咱们还致力于晋升咱们本人的测试效率，2023 年一个十分大的工作就是将很多写在 unit test 文件外面的 integration tests 挪进来，让 UT 真的变成 UT，具体见这个 issue - Split integration tests(IT) and unit tests(UT) in TiDB repo ( https://github.com/pingcap/tidb/issues/45961 )。这个工作十分的重要，在没开始之前，如果咱们在本地单纯的跑 TiDB 的 UT 测试，不出意外，大概率会跑挂，即便通过，耗时也靠近 50 分钟，而这个工作开始一段时间之后，咱们以后跑完 UT 只须要 15 分钟（前面还会持续优化），这个对于咱们本身的测试效率是一个极大的晋升，当效率晋升之后，咱们就能有更多的工夫写代码，加测试了。</p><p>这里仅仅只是简略的列了一些咱们在品质下面做的事件，如果前面有机会，我能够专门写一篇文章讲讲 2023 年 TiDB 在品质下面做的工作。坦率的说，直到现在，我也没找到一系列很好的指标来评估咱们收回去的一个版本品质到底好不好，无论咱们做了多少的测试，我总认为是不够的。</p><h2>小结</h2><p>下面就是 TiDB 2023 的一个简略的回顾了，咱们在 2023 年真的获得了许多十分不错的问题。总结来说，就是咱们公布了一个不错的产品，以及明确了以稳定性为根底的研发策略。回顾 2023，咱们也有不少做错的中央，也走了一些弯路，这个有机会，前面再从新开一个新坑，讲讲『那些年咱们开发 TiDB 所踩过的坑 :-) 』。</p><p>对于 2024 年，在 TiDB 下面，咱们也会十分聚焦，首先依然会以稳定性为根底，在这个根底下面，咱们会投入带宽来改良 TiDB 的可观测性以及晋升一些场景上面的性能，具体的大家能够关注咱们 TiDB 的 roadmap，咱们会定期的刷新。</p><p>在 2023 年，咱们在 cloud 下面也获得了不错的停顿，在前面一篇文章中，我就会来讲讲 “TiDB Cloud in 2023”。</p></article> ...

<article class=“article fmt article-content”><p>文章介绍了 TiDB 在医疗保障信息平台中的利用。东软医保云利用治理平台通过与 TiDB 联结，胜利满足了医疗保障业务中高并发、实时性和简单查问的要求。在某地市医疗保障信息平台的实际中，TiDB 分布式数据库无效实现了在线交易和实时剖析服务，日均 QPS 达 22,000，总数据量靠近 30TB，升高了零碎开发和保护老本，推动医疗保障信息平台的数字化和智能化倒退。</p><h2>医疗保障信息平台简介</h2><p>医疗保障信息平台是波及国计民生的基础性工程。通过建设对立的规范体系、技术体系、数据体系和利用体系，充分发挥信息化在医保业务高效运行和模式继续翻新方面的反对作用，推动医疗保障朝着数字化和智能化方向倒退。</p><p>依据《医疗保障信息平台建设指南》，中央医疗信息化保障平台要依照国家对立标准规范建设云平台，其中必须蕴含 PaaS 层的能力，包含分布式服务、音讯队列服务、分布式缓存服务、分布式日志服务、分布式数据拜访服务、关系型数据库、非结构化存储服务、离线计算引擎、实时计算引擎、流计算引擎等。</p><p></p><p>医疗保障平台架构示意图</p><p>业务和数据中台的建设依靠国家业务中台利用标准，部署并应用国家对立下发的业务中台，以实现地市平台与国家平台之间平滑稳固的合作联通。通过中台架构将信息系统的外围能力积淀为共享服务中心，造成大中台、快前台的零碎支撑体系。借助大数据技术对海量数据进行采集、荡涤、计算、存储和加工，统一标准造成大数据资产层为前台提供高效服务。同时，通过对立基础设施为整个平台提供计算、存储、数据、网络、平安及虚拟化服务，保障新旧零碎失常切换及安稳运行，从而建成全国对立、互联互通的医疗信息化保障平台。</p><h2>业务中台对关系型数据库的能力要求</h2><p>业务中台是将医疗保障信息平台各子系统间可共享的业务能力抽取进去，造成不同的“业务核心”，提供共享业务服务，具备高内聚、低耦合特点。业务核心领有独立的数据资源，具备独立经营能力，能独立部署，可通过积淀撑持下层利用零碎的疾速迭代造成创新能力，实现业务的高效共享和复用，从而解决零碎扩展性能力差、业务性能反复建设、零碎稳定性差和无奈撑持高并发等问题。 </p><p>做为实时数据服务的平台，关系型数据库须要反对海量业务数据的存储、计算和实时展现，具备数据集成与传输的能力，须要面向各种数据利用，例如，报表平台、自助剖析平台（BI）、历史明细查问平台、数据挖掘、AI 平台等提供多种服务能力，包含可伸缩的数据扩大能力、并发读写能力、实时更新能力、简单查问剖析能力，以及对事务和规范 SQL 的反对能力等。场景的关键技术个性要求如下：</p><ul><li>对数据容量、写入吞吐和提早要求较高</li><li>须要隔离 OLTP 和 OLAP 负载</li><li>反对规模化计算、离线和实时在线数据的剖析和展示</li></ul><p></p><p>业务中台逻辑架构图</p><h2>东软医疗保障平台＋TiDB 联结解决方案</h2><p>东软医保云利用治理平台采纳分布式云架构设计。在基础设施层上，基于云平台提供分布式服务撑持。治理平台作为零碎运行的次要载体，承载业务利用，满足数据存储、传输、替换和利用的需要，以一站式的形式提供医保通用撑持服务和软件，为医疗保障利用框架及利用零碎提供标准化撑持，实现利用自动化、智能化部署与运维、通过先进、高效、便捷、平安的治理平台推动医保信息化建设。TiDB 分布式数据库做为整个治理平台的外围组件无缝反对了医保行业客户数据、交易数据的存储、解决和实时展现的需要。</p><p></p><p>联结解决方案架构示意图</p><p>联结解决方案合乎《医疗保障信息平台云计算平台标准》，满足了对分布式组件的适配要求。相较于大型云平台提供的泛滥服务，东软云利用治理平台旨在提供满足医保行业要求的 PaaS 层服务，更具专一性和实用性，在软硬件布局方面平台的透明度更高，布局更为正当。该平台提供软硬资源及云环境的对立监管能力，通过可视化页面实现对多个主机、虚拟机、云利用和分布式数据库的治理，极大地简化了治理流程。</p><h2>联结解决方案在某地市医保的利用实际</h2><p>某地市医疗保障信息平台的建设指标是依靠全国对立医疗保障信息平台，无效解决规范不对立、数据不互认以及区域关闭等问题，旨在实现医保业务编码标准的一致性、医保数据标准的一致性以及医保经办服务的整合，为全市千万级城镇居民提供更加智能、便捷和高效的医疗保障服务。</p><p>医疗保障平台的设计要求实现跨区域、跨层级、跨业务、跨部门、跨零碎的信息共享、业务协同和服务融通，以实现医保业务的“一网通办”和“一窗办结”。在业务架构设计中，对于数据品质、数据分析以及数据实时展现提出了更高的要求。采纳传统数据库会导致读写拆散、分库分表、分布式事务等须要在应用层实现，这可能带来业务侵入性高、扩展性弱和保护老本低等问题；应用现有的 ETL 数据抽取工具无奈保障医保交易库和剖析库数据的品质和实时性。因而，构建实时、秒级、解决海量数据平台的需要尤为迫切。</p><p>该地市医疗保障信息平台引入 TiDB 分布式数据库，在满足下层业务利用对高并发、高吞吐、弹性扩大与高可用要求的根底上，提供灵便麻利的运维体验。基于 TiDB 构建的一栈式数据服务底座，实现了在线事务处理和实时剖析的残缺闭环。</p><p></p><p>地市医疗保障平台数据流转架构示意图</p><p>自 2021 年 9 月上线以来，该地市医保已胜利将医保外围业务的流量切到 TiDB 分布式数据库，为门诊、药店、住院和结算等业务场景提供在线交易和实时剖析服务。目前，TiDB 数据库的日均 QPS 22,000，总数据量靠近 30 TB。</p><p></p><p>TiDB 集群业务顶峰时段的 QPS</p><p>TiDB 在技术倒退路线和架构上保持凋谢中立，最大水平爱护用户的技术路线自主，自主开源带来了产品的高速迭代，进一步放大各行业当先的数字化场景劣势。做为外围业务的交易库，TiDB 分布式数据库在反对海量并发联机交易的根底上，实现生产交易与剖析负载拆散，外部实现行列数据的强统一同步，提供 T+0 医保数据的实时剖析和展示，简化了整个医疗保障信息平台的数据架构，升高了开发难度和我的项目投入老本。此外，TiDB 与现有的大数据计算、流解决生态都能够集成，升高了二次适配的老本。</p></article>

在不久前完结的 TiDB Future App Hackath on 2023 上，来自寰球 88 个国家的 1492 名参赛者们借助 AI 和 TiDB Serverless 的能力，构建了许多令人印象粗浅的我的项目。 打造 Hackathon 的我的项目是一个从 0-1 的过程，真实世界中也涌现出了一批守业公司正在围绕 AI 打造翻新利用，并实现了规模化，获得了商业胜利，这可能就是一个从 0 - 1 甚至到 ultimate 的过程。 你是否曾经蠢蠢欲动，想打造本人的 AI Apps？ 打造一款优良的 AI Apps 须要怎么的能力？是令人印象粗浅的创意、过人的技术实力？或者也离不开牢靠的技术栈…… 本次线上 Meetup，咱们邀 请到了 2023 TiDB Future App 寰球黑客马拉松的 TOP AI 我的项目开发者 ，来给大 家分享他们 AI 利用创作故事，更有来 自新星 AI 守业公司 RealChar 的 CEO Shuan Wei、PingCAP 创始人黄东旭、PingCAP 社区经理 Raymond 来 与大家一起分享探讨：从 0 到 1，打造真实世界的 AI 利用须要怎么的技术栈？ ...

TiDB 7.1.0 LTS 在前段时间公布，置信很多同学都曾经领先应用了起来，甚至都未然通过一系列验证推向了生产环境。面对 TiDB 7.1 若干重要个性，新 GA 的资源管控 (Resource Control) 是必须要充沛了解、测试的一个重量级个性。对于长年奋斗在一线 DBA 岗位的我来说，学术方面的精进曾经力不从心，大部分的工夫都在强化“术”的方面，所以 TiDB 每更（新）必追，每个新 GA 的个性都要相熟，这样当生产环境 TiDB 降级到指标版本后，才不至于慌手慌脚，新建 TiDB 集群后能力对新个性轻车熟路。置信本文会给读者敌人们带来一些实质性的播种。言归正传，本文将围绕“资源管控”主题，具体说说对于 “资源管控” 您应该晓得的 6 件事。 从用户场景登程，看个性如何应用从 200+ 的国产数据库中怀才不遇，其无效、齐备的文档当属“功不可没”。在 TiDB 7.1 的文档中是这样形容 应用场景 的： 资源管控个性的引入对 TiDB 具备里程碑的意义。它可能将一个分布式数据库集群划分成多个逻辑单元，即便个别单元对资源适度应用，也不会挤占其余单元所需的资源。利用该个性： ○ 你能够将多个来自不同零碎的中小型利用合入一个 TiDB 集群中，个别利用的负载升高，不会影响其余业务的失常运行。而在零碎负载较低的时候，忙碌的利用即便超过设定的读写配额，也依然能够被调配到所需的系统资源，达到资源的最大化利用。 ○ 你能够抉择将所有测试环境合入一个集群，或者将耗费较大的批量工作编入一个独自的资源组，在保障重要利用取得必要资源的同时，晋升硬件利用率，升高运行老本。 ○ 当零碎中存在多种业务负载时，能够将不同的负载别离放入各自的资源组。利用资源管控技术，确保交易类业务的响应工夫不受数据分析或批量业务的影响。 ○ 当集群遇到突发的 SQL 性能问题，能够联合 SQL Binding 和资源组，长期限度某个 SQL 的资源耗费。 那么，从求实的 DBA 角度来看这段话，可能会是上面这个样子： 资源管控，这一新个性，将数据库中的用户、会话、SQL 等日常行为的性能指标做了更加粗疏的量化解决。引入了 “Request Unit (RU)” 这一量化概念，目前包含了 CPU, IOPS, IO 带宽 三个重要指标，将来还会减少内存、网络等指标。 ...

9 月 22 日 14:00-15:40，平凯数据库重装亮相，全解读流动将在线上进行 。本次发布会上，咱们邀请到了多位产业同仁、技术专家和银行用户，从 产业趋势、内核技术、利用实际 等角度全面解读平凯数据库，更有 企业级外围性能的实操演示 。 与此同时，观看直播即可参加有奖互动，超多惊喜礼品等你来 ！ 扫描下方二维码，立刻报名流动！ 对于平凯数据库 平凯数据库（TiDB 企业版）是平凯星辰公司自主研发的企业级原生分布式数据库产品，具备数据强统一、程度弹性扩缩容、金融级高可用、实时 HTAP 等个性，为企业客户提供安全可靠、性能全面、性能卓越的分布式数据库能力和服务反对，助力企业减速开释数据价值。

作者：李文杰 数据架构师，TUG 广州地区流动组织者 在日常业务应用或运维治理 TiDB 的过程中，每个开发人员或数据库管理员都或多或少遇到过 SQL 变慢的问题。这类问题大部分状况下都具备肯定的法则可循，通过教训的积攒能够疾速的定位和优化。 然而有些状况下不肯定很好排查，尤其波及到内核调优等方向时，如果当时没有对各个组件的互访关系、引擎存储原理等有肯定的理解，往往难以下手。 本文针对写 TiDB 集群的场景，总结业务 SQL 在写忽然变慢时的剖析和排查思路，旨在积淀教训、共享与社区。 写入原理业务对集群的数据写入流程会被 TiDB Server 封装为一个个的写事务，写事务的实现次要波及的组件是 TiDB Server 和 TiKV Server。如下所示，是 TiDB 集群写入流程的架构简图： 事务在写入的过程，别离会与 TiDB Server、PD 和 TiKV Server 进行交互： TiDB Server 用户提交的业务 SQL 通过 Protocol Layer 进行 SQL 协定转换后，外部 PD Client 向 PD Server 申请到一个 TSO，此 TSO 即为事务的开始工夫 txn_start_tso，同时也是事务在全局的惟一 ID 接着 TiDB Server 对 SQL 文本进行解析解决，转为形象语法树 AST 传给下一个解决模块 TiDB Server 对 AST 进行编译、SQL 等价改写等逻辑优化、参考零碎统计信息进行物理优化后，会生成真正能够执行的打算 可执行的打算通过分析判断，点查问操作转到KV模块、简单查问转到 DistSQL 模块（持续转为对单个表拜访的多个申请），再通过 TiKV Client 模块与 TiKV 进行交互，在 TiDB Server 这一侧实现对数据的拜访 ...

以下文章来源于 InfoQ 数字化经纬。 InfoQ 数字化经纬： InfoQ 极客传媒旗下官网账号。面向数字化管理者、从业者、洞察者，提供数字化企业案例、政策解读、钻研报告，做数字时代的「记录者」。 作者 | 赵钰莹 嘉宾 | 伍春兰 中欧财产技术总监 本文采访了中欧财产技术总监伍春兰，探讨了财产治理行业数字化转型面临的挑战，包含人才、平安和技术基础架构。在数据库迁徙中，中欧财产通过采纳分布式数据库 TiDB 解决了 MySQL 的旧有问题，强调了 HTAP 交融架构在性能和资源管理方面的重要性。文章指出，数字化转型须要跨足思维、组织、流程和平台等层面，以适应日益高效和翻新的需要。浏览全文约需 12 分钟。 本文要点： 财产治理畛域近几年受内外部环境的变动，对技术底座能力提出麻利高效、及时翻新等较高要求；数字化转型不是一个技术问题，波及思维、组织、流程、平台四大层面；财产治理畛域企业数字化转型次要面临人才，平安、基础架构（技术）三方面的挑战；人工智能技术在财产治理畛域企业外部大规模落地还须要工夫；在数据库选型之前，企业须要先定位分明需要；数据库迁徙前，旧有的 MySQL 体系次要遇到的问题是大表 DDL 耗时、分库分表消耗大量人力、单节点写入易呈现瓶颈等问题，最初通过分布式数据库 TiDB 解决了上述问题；在评估数据库迁徙前后的成果时留神运维、资源等隐形层面的老本；HTAP 交融架构在性能、资源精准耗费等层面都起到了重要作用；中欧财产数字化转型降级的思路、难点及实际InfoQ：财务管理公司和基金公司这几年节奏显著变快，其背地的推动力到底是什么？财务管理行业的数字化转型存在哪些痛点？ 伍春兰 ：最近几年，基金公司内外部环境都产生了比拟大的变动。自 2013 年随同着余额宝的衰亡，整个互联网业务疾速倒退，这对市场带来了几个显著的变动： 第一个变动是 用户根本盘迅速扩充，要想服务好用户，技术迭代速度须要更快。举例来说，一些互联网属性的公司数据刷新较快，中欧财产为了达到这个成果，整个公司做了比拟大的投入和配合，包含引入人工智能技术做一些自动化的事件； 第二个变动是 互联网业务比拟有特点且信息较为通明，用户能够迅速看到市场上呈现了哪些新的业务与渠道，这要求团队时刻放弃麻利和高效，包含与上下游业务的买通； 第三个变动是 业内开始呈现新的营销模式，比方通过直播的形式进行营销，或者经营新的平台，比方抖音等，这须要企业买通外部的经营流程和数据，这对技术团队提出的要求同样是及时翻新、麻利高效。 综上，公司须要抓住机会，迅速做出决策，以应答这些变动。比方，突破原来的数据孤岛，造成对立的、智能的数据中台，基于这个中台能够更好地开掘客户个性、绘制用户画像，从而让产品更好地满足客户需要；与上下游的机构和企业单干时须要具备弱小的研发能力，包含模型、算法、定制化能力等都必须与互联网大厂的研发实力相匹配。 纵观外部和内部，难点次要在于：一是人才方面，并不是每一家金融企业都匹配了弱小的且对技术趋势敏锐的研发团队；二是资源投入能力，比方产品层面的投入是否跟得上；三是数据安全，在适配互联网快节奏的业务更新和及时响应的前提下保障公司外部、与上下游企业单干全链路的数据安全是十分重要的；四是在旧有基础架构上做敏态降级，包含基础设施、运维、研发、产品等。 InfoQ：第二大变动中的“买通上下游”具体指什么？ 伍春兰： 数字化转型一是思维、二是组织、三是流程、四是平台。思维上，数字化转型不是某个部门的事件，过程中波及组织及流程上的变动，须要保障大家思维对立；组织和流程上，数据买通就波及跨部门共享，思维对齐的状况下还须要保障组织层面能够尽可能流程化，疾速推动相干决策。比方新业务上线，可能波及经营、产品、研发等多个部门，大家是否能够通明地理解整个执行链路，分明理解公司的决策背景，只有每个部门都参加其中能力真正做到流程提效，而不仅是实现工作。平台上，数据买通之后是否真正用起来，数据品质须要达到什么水平都是平台要重点优化的事件。 InfoQ：针对人才，平安、基础架构三大难题，中欧财产是如何解决的？ 伍春兰： 在人才方面，中欧财产于 2014 年左右开始筹备，招聘的大多数员工背景偏互联网和外围金融机构方向，这些员工不仅理解金融的业务状态，同时具备较高的技术能力和敏锐度，整个架构起初就适配了互联网时代的特点；平安层面，除了符合国家相干监管标准的要求，中欧财产自身也做了大量摸索，比方防 DDoS 攻打、流量荡涤、内网监控、数据安全和审计等，这些能力通过过来三四年的倒退逐步建设起来，但要做到齐全自动化还是比拟艰难的。基础架构层面，如前文言，初始架构曾经适配了互联网时代的特点，在过来多年的演进中，中欧财产又针对不同的模块进行了优化，包含分布式数据库体系建设、公有云体系优化等。 InfoQ：您不便举例说明中欧财产通过数字化转型获得了哪些成绩？ 伍春兰： 以投顾业务为例，首先该业务须要迅速了解客户需要，并基于数据驱动的逻辑做出疾速、麻利的反馈，这对底层的数据能力要求较高；其次，作为国家首批五家基金投顾业务试点公司，中欧财产次要劣势在于弱小的自主研发能力。过来五年，中欧财产针对整个基础架构进行了降级，底层基建与行业技术演进的大趋势相匹配，实现了软件定义及弹性部署，升高了计算和运维老本。目前，公司业务全面部署在基于 K8s 的公有云上，能够很好地反对投顾等业务的倒退。 InfoQ：如何对待人工智能技术在财产基金畛域数字化转型中施展的作用？ 伍春兰 ：对于人工智能技术的落地，我认为大规模落地还是有难度的。尽管目前很多公司在这方面都有动作，但更多的是尝试，比方智能客服、敏感词审核等。在理论业务中，人工智能更多是在表演辅助的角色，而不是代替很多人的劳动。 具体到金融畛域，因为该畛域强监管且对专业性要求较高，因而目前现有的、通用型的大模型可能无奈很好匹配需要，将来可能会呈现针对该畛域的大模型，只是还须要一些工夫。 面向未来，中欧财产如何联手 PingCAP 打造分布式数据库体系?迁徙前的旧有数据库体系基于 MySQL 搭建InfoQ：中欧财产在与 PingCAP 的 TiDB 数据库单干之前，外部的数据体系是什么状态？ ...

TiDB Hackathon 2023 刚刚完结，我认真地审阅了所有的我的项目。 在并未强调我的项目必须应用人工智能（AI）相干技术的状况下，引人注目的我的项目简直统一地都应用了 AI 来构建本人的利用。 大规模语言模型（LLM）的问世使得集体开发者可能在短短 5 分钟内为程序赋予推理能力，而这在以往，简直只有超大型团队能力胜任。 从利用开发者的角度来看，AI 时代也曾经到来了。 在这些 AI 利用中，向量数据库的身影是无处不在的。只管这些我的项目大多仍在应用关系型数据库，但它们仿佛不再施展一个不言而喻的作用。关系型数据库到底还值不值得取得利用开发者们的关注呢？ 为了解答分明这个问题，咱们须要理解一下向量数据库到底跟传统的关系型数据库有什么不同。 什么是向量数据库?为了搞清楚这个问题，我花了一些工夫钻研了一下向量数据库。接下来我讲用最简略的语言来解释什么是向量数据库。 这个世界上的大多数事件都是多特色的，比方你形容一个人能够用身高、体重、性情、性别、穿衣格调、兴趣爱好等等多种不同类型的维度。通常如果你违心的话，你能够有限扩大这个维度或者特色去形容一个物体，维度或者特色越多，对于一个物体或者事件的形容就是越精确的。 当初，如果开始用一个维度来表白 Emoji 表情的话，0 代表高兴，1 代表悲伤。从 0 - 1 的数字大小就能够表白对应表情的悲欢水平，如下 x 轴所示： 然而你会发现，如果只有一个维度来形容情绪 Emoji 的话，这是抽象的，也是不够精确的。例如开心，会有很多种类型的 Emoji 能够表白。那么这个时候咱们通常是退出新的维度来更好地形容它。例如咱们在这里退出 Y 轴，通过 0 示意黄色，1 示意红色。退出之后表白每个表情在坐标轴上的点变成了 (x, y) 的元组模式。 聪慧的你肯定发现了，即便咱们退出 Y 轴这个新的形容维度，仍然还有 Emoji 咱们是没方法辨别开的。比方 那么怎么办呢？解决这个方法仍然很简略，再加一个维度。在坐标系中就是退出 z 轴。咱们把新的维度简略设置为是否戴帽子（留神这里每个维度的取值尽可能地简略是为了论述，不代表真实世界也如此简略）。用 0 示意没戴，1 示意戴了。所以咱们当初就失去了一个 (x, y, z) 的三维坐标点来形容一个 Emoji 了。 当然在事实世界中，一个事物的性质不会那么少，所以咱们须要通过减少很多个维度来形容它，所以就呈现了相似高维数组这样的形容 （0.123, 0.295, 0.358, 0.222 ...）。到这里咱们曾经十分靠近向量数据库中的 “向量” 了，其实向量数据库中存的就是这样的一些数组，用以示意各种各样的数据，包含图片、视频、文字等等。这些事物都是通过咱们上述这种转换的形式，把它们变成了一个个高维的数组，而后保留下来。 ...

作者：李文杰 网易游戏计费 TiDB 负责人 在应用或运维治理 TiDB 的过程中，大家简直都遇到过 SQL 变慢的问题，尤其是查问相干的读变慢问题。读变慢的问题大部分状况下都遵循肯定的法则，通过教训的积攒能够疾速的定位和优化，不好排查的问题须要从读 TiDB 的每个过程一一排查和剖析解决。 本文针对读 TiDB 集群的场景，总结业务 SQL 在查问忽然变慢时的剖析和排查思路，旨在积淀教训、共享与社区。 一. 读原理业务 SQL 从客户端发送到 TiDB 集群后，次要经验解析、生成执行打算、执行查问、返回查问后果这几个流程。如下所示是 TiDB 读过程的架构简图： 来自客户端的每个读取数据的操作，TiDB 也会将其封装为读事务，通常状况下事务在执行的过程别离会与 TiDB Server、TiPD Server 和 TiKV Server 进行交互。 TiDB Server ● 用户提交的业务 SQL 通过 Protocol Layer 进行 SQL 协定转换后，外部 PD Client 向 TiPD Server 申请到一个 TSO，此 TSO 即为读事务的开始工夫 txn_start_tso，同时也是该读事务在全局的惟一 ID。 ● TiDB Server 在解析前会将 SQL 做分类，分为 KV 点查问（惟一键查问，Point Get）和 DistSQL 简单查问（非点查，Copprocessor ）。 ○ KV 点查问跳过执行打算优化阶段，间接到查问层，对于在线交易相干的 TP 场景，会大大降低响应提早。 ...

作者：张政俊 中欧财产数据库负责人 中欧财产是中欧基金控股的销售子公司，旗下 APP 实现业内基金种类全笼罩，提供基金交易、大数据选基、智慧定投、理财师征询等投资工具及服务。中欧财产致力为投资者及合作伙伴提供一站式互联网财产治理解决方案，自 2015 年成立以来业务持续保持持重的增长。 本文介绍了中欧财产在分布式数据库畛域的摸索历程，以及如何胜利将业务零碎迁徙到 TiDB 平台的实际。文章详述了中欧财产采纳 TiDB 的四个上线阶段，展示了 TiDB 在应答数据增长、解决 DDL 挑战以及优化写入性能等方面的卓越体现。此外，文章还特别强调了 TiDB 7.1 LTS 版本所带来的新个性，包含资源管控、Partitioned Raft KV 等，这些翻新极大地晋升了中欧财产的业务效益和性能程度。 分布式数据库的利用历程中欧财产从 2021 年开始调研分布式数据库，心愿通过应用分布式数据库来实现原有 MySQL 数据库不能满足的需要，从而解决业务层面遇到的技术难题。期间对 TiDB 做了全方位测试，证实了 TiDB 从架构角度是兼容的、从性能角度是达标的。2022 年，咱们洽购服务器开始部署 TiDB 集群，逐渐将一些周边零碎迁徙到 TiDB 上 。往年，咱们做了更具体的测试和验证，将更多更简单的业务零碎切换到 TiDB，上半年上线了四个零碎，下半年打算再上线六个零碎。 中欧财产的分布式数据库上线工作能够分为四个阶段： 第一阶段是业务的深度测试 。通过搭建和生产配置雷同的并行环境，应用生产数据进行深度的测试。每个业务零碎有各自的特点，场景都不一样。每次上线前，必须要保障测试是充沛的：业务层面的测试要保障所有的业务都能够跑通；性能方面，每个业务的性能指标不能低于其原先在 MySQL 上的性能指标。横向对实时业务和跑批工作的效率进行比照，找出慢 SQL 并进行优化。 第二阶段是进行数据的同步 。通过 TiDB 提供的 DM 工具，将数据从生产 MySQL 实时同步至 TiDB 集群。当数据实现实时同步之后，再将原架构中 MySQL 上游的同步链路（MySQL 原生同步、Canal、FlinkCDC 等）全副切至 TiDB（通过 TiCDC 输入） ，之后进行两到三周的数据同步察看，校验数据的一致性。 第三阶段是利用上线 。个别会找一个小的停机窗口，敞开 DM 同步，确保数据的一致性之后，把利用切到 TiDB 上。 ...

作者 | 王聪彬 编辑 | 舞春秋 起源 | 至顶网 本文介绍了漱玉平民大药房在药品批发畛域的数字化转型和倒退历程。通过技术创新， 漱玉平民 建设了笼罩医药全生命周期的大衰弱生态圈，采纳混合云架构和国产分布式数据库 TiDB，应答宏大的会员数据处理需要，实现了精准营销、高并发解决等指标。漱玉平民对于数字化建设非常重视，一步步通过技术创新，推动客户服务，构建起笼罩“医、药、康、养”全生命周期的大衰弱生态圈。 20 多年来，我国的批发药店倒退堪称迅猛，成为了社会基层提供药学服务、保障药品供给的终端。 2022 年是药品批发行业近年来增速最快的一年，据统计，2022 年中国批发药店市场销售额达到 5421 亿元，同比增长高达 10.2%。国家药品监督管理局信息中心数据显示，截至 2022 年底，我国药店总数为 62.33 万家，连锁门店数量为 36 万家，药店连锁化率为 57.76%。 其实在过来三年中，连锁门店在疫情防控药品供给保障中施展了踊跃作用。同样是 2022 年，正值疫情的高发阶段，作为批发药店的一员漱玉平民大药房做了一个决定，向济南市民收费赠送 600 万片布洛芬，共渡难关。也正是这一行动很大水平缓解了过后市民购药、囤药的焦虑。 20 年前，2002 年 5 月 18 日，漱玉平民大药房第一家门店在山东济南西门店正式停业，正式进军中国医药批发畛域。2021 年 7 月 5 日，漱玉平民大药房连锁股份有限公司在深圳证券交易所创业板胜利上市。 21 年后的明天，截至 2023 年 3 月，漱玉平民领有门店 6041 家，其中直营门店 3620 家，加盟门店 2421 家，营销网络覆盖山东省、辽宁省、福建省、河南省及甘肃省等地区。总会员人数已超过 2000 万人，2022 年度公司销售额已超过 83 亿元。 随着医药批发行业的一直倒退与成熟，批发药房比的已不是价格，而是专业化和多元化。业内人士也称，将来的药店将不再是简略交易药品的中央，而是以交易药品为引流伎俩和减少黏性服务，提供轻诊疗、心理咨询等简略医疗服务，满足衰弱生态和消费者衰弱新需要，一直晋升以顾客为核心的线上线下综合服务能力。 漱玉平民也在一直开发并欠缺基于全渠道、多元化、全家庭的商品体系，实现多元化商品布局。同时根据顾客需要，通过制订标准化的经营体系，增强不同商圈门店的商品精细化治理，晋升门店商品效益和门店精细化经营。 漱玉平民大药房连锁股份有限公司副总裁兼 CIO 颜正耀深有体会，他提到漱玉平民在业务上面临两个十分大的挑战，连锁企业有着直营、并购、加盟、联盟“四驾马车”，这是规模化的挑战，另一大挑战就是泛会员化带来的挑战。 这里就不得不提漱玉平民对于数字化建设的器重，一步步通过技术创新，推动客户服务，构建起笼罩“医、药、康、养”全生命周期的大衰弱生态圈。 从 CRM 到混合云再到数据库漱玉平民始终坚韧不拔地推广数字化策略转型，利用数智化管理工具晋升管理效率、优化业务布局，助力公司数字化根底建设。 ...

2023 年 7 月 10 日，TiDB Serverless 正式商用。这是一个齐全托管的数据库服务平台（DBaaS），提供灵便的集群配置和基于用量的付费模式。紧随其后，TiDB Serverless Branching 的测试版也公布了。 TiDB Serverless Branching 性能使用户可能为其 TiDB Serverless 集群创立分支。这些分支能够实现并行开发，促成新性能疾速迭代，排查故障，开发者无需中断生产数据库的运行。该性能不仅简化了开发和部署过程，还放弃了生产环境中数据库的稳定性和可靠性。 一. 分支是什么？对于集群而言，分支是一个独立的实例，其中蕴含一份原始集群的数据快照。它建设了一个隔离的环境，以便在不影响原始集群的状况下进行各种操作。 当为集群创立一个分支时，该分支中的数据与原始集群开始分叉，这意味着在原始集群或分支中进行的后续更改将不会被同步。 TiDB Serverless 采纳了写时复制 （copy-on-write ）技术，以实现疾速、安稳地创立分支。这种办法容许原始集群与其分支之间共享数据。这个操作个别在几分钟内就能实现，对用户来说是无感知的，对原始集群的性能也不会有影响。 二. 均衡软件开发速度和品质在软件开发中，疾速推出新性能和全面测试之间的奥妙均衡是一个挑战。找到正确的均衡能够实现麻利开发、更快的迭代，并及时收到贵重的客户反馈，同时不会影响软件的品质和可靠性。TiDB Serverless Branching 提供了一种形式来找到这个最佳均衡。 2.1 为开发人员提供独立环境 在日常开发和测试流动中应用数据库时，开发人员常常面临配额限度、高老本、资源限度和数据品质等挑战。所以通常在团队内共享数据库更理论。但共享数据库往往会导致环境的抵触，开发人员不得不破费额定的精力在利用中增加一些隔离的逻辑。 TiDB Serverless Branching 通过为每个开发人员提供独立的开发和测试环境来解决这些问题。通过打消资源共享和工作烦扰，进步生产效率并促成高效的团队合作。 2.2 通过相似生产的分支进行高效测试 为了 打消资源共享和工作 间烦扰带来的懊恼 ，开发人员通常会在进行开发工作时应用独自的数据库环境，比方在服务器上设置本人的数据库或在 Docker 上启动数据库容器。 然而，这些环境与生产环境存在显著差别，很难模拟出理论的性能和提早状态。 对于功能测试，则总是须要大量的数据筹备工作，可能却依然无奈与理论的生产环境相匹配。 为了确保数据品质，开发人员能够抉择生成生产数据库的快照，并在测试环境中还原它，或者费劲地构建模仿数据。 然而，这两种办法都很繁琐，会显著升高开发效率。 通过 TiDB Serverless Branching，开发人员将可能在几分钟内疾速创立与生产环境雷同的分支。这些分支有助于应用最新的生产数据进行测试，并疾速检测问题。此外，这些分支齐全与生产集群隔离，能够进行更平安的功能测试和故障排除。2.3 与继续集成和继续部署（CICD）流程无缝集成 自动化场景须要先进的环境治理和品质管制。TiDB Serverless Branching 能够轻松集成到自动化的 CICD 工作流中，通过分支整合， 代码品质的把控和测试流程都变得更加晦涩 。这确保了产品的品质，同时遵循了高效的软件开发实际。 三. 与 GitHub 集成的分支治理联合 TiDB Serverless Branching 性能，咱们推出了 TiDB Cloud 分支治理 GitHub App。如果开发人员应用 GitHub flow ( https://docs.github.com/en/get-started/quickstart/github-flow )，该利用可能极大水平地简化将分支集成到 CI 流水线中的工作。无关该 GitHub App 的更多详细信息，请参阅咱们的文档 ( https://docs.pingcap.com/tidbcloud/branch-github-integration )。 ...

1 概述TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时反对在线事务处理与在线剖析解决 (Hybrid Transactional and Analytical Processing, HTAP) 的交融型分布式数据库产品，具备程度扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协定和 MySQL 生态等重要个性。指标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适宜高可用、强统一要求较高、数据规模较大等各种利用场景。 总结一下，Tidb是个高度兼容MySQL的分布式数据库，并领有以下几个个性： 高度兼容 MySQL：把握MySQL，就能够零根底应用TIDB程度弹性扩大：自适应扩大，基于Raft协定分布式事务：乐观锁、乐观锁、因果一致性真正金融级高可用：基于Raft协定一站式 HTAP 解决方案：单个数据库同时反对 OLTP 和 OLAP，进行实时智能解决的能力其中TiDB的外围个性是：程度扩大、高可用。 本文次要从TiDB的各类组件为终点，理解它的基础架构，并重点剖析它在存储架构方面的设计，探索其如何组织数据，Table中的每行记录是如何在内存和磁盘中进行存储的。 2 组件先看一张Tidb的架构图，外面蕴含 TiDB、Storage(TiKV、TiFlash)、TiSpark、PD。其中的TiDB、TiKV、PD是外围组件；TIFlash、TiSpark是为了解决简单OLAP的组件。 TiDB是Mysql语法的交互入口，TiSpark是sparkSAL的交互入口。 []() 2.1 TiDB ServerSQL 层，对外裸露 MySQL 协定的连贯 endpoint，负责承受客户端的连贯，执行 SQL 解析和优化，最终生成分布式执行打算。 TiDB 层自身是无状态的，实际中能够启动多个 TiDB 实例，通过负载平衡组件（如 LVS、HAProxy 或 F5）对外提供对立的接入地址，客户端的连贯能够平均地摊派在多个 TiDB 实例上以达到负载平衡的成果。TiDB Server 自身并不存储数据，只是解析 SQL，将理论的数据读取申请转发给底层的存储节点 TiKV（或 TiFlash）。 2.2 PD (Placement Driver) Server整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布状况和集群的整体拓扑构造，提供 TiDB Dashboard 管控界面，并为分布式事务调配事务 ID。 ...

7 月 13 日，PingCAP 用户峰会 2023 将在北京市海淀区东北华邑酒店举办，线上线下同步。本届大会主题为“翻新涌动于先”，汇聚前沿数据科技与商业洞见，现场将有来自银行、保险、证券、政府、运营商、批发、制作、能源、物流、技术出海等畛域的代表客户汇聚一堂，探讨前沿数据技术的发展趋势与行业利用成绩，分享行业首领和专家智囊的实战经验与思维碰撞，构建多元的解决方案与生态单干。 在技术涌动的明天，PingCAP 始终走在技术的前沿，以当先的架构冲破壁垒，TiDB 正以稳定性、性能、高可用、易用性、工具生态为用户提供一贯性的体验。 AIGC 崛起驱动怎么的数据库架构改革，用户为什么抉择 TiDB，将来的 TiDB 还将带给用户哪些惊喜？本次大会将给你答案！ 大会全议程现已颁布，长按扫描二维码，立刻报名流动！

PingCAP 用户峰会 2023 报名现已开启，扫码立刻报名流动！ 数字经济时代，数据曾经成为了驱动企业业务倒退的要害生产因素，而 新技术的涌现为企业技术架构的跃迁提供了新契机。 AIGC 尽管还处于高度混沌的状态，但它的崛起正悄悄疏导一场改革，领有重塑软件行业的有限可能性；经济不确定性给每一个企业带来生存与效率的双重挑战，企业的首要任务是思考如何在保障生存平安的状况下摸索将来。 翻新涌动于先许多企业领导者和技术思考者都在思考如下问题： 如何在高度的不确定时代寻找某种确定性？AIGC 将如何扭转软件开发和数据库技术？数据技术如何演进能力迎接降本提效的挑战？在这样一个关键时刻，咱们首先会想到翻新，想到技术破局，想到在资源受限的条件下摸索将来。 PingCAP 始终在摸索数据库技术的边界， 咱们始终在寻找一种简略和弱小的形式来晋升数据服务体验 ，从 OLTP Scale 开始，连贯寰球极限场景，通过 HTAP 技术突破了 OLTP 与 OLAP 技术的界线，打造出前所未有的交融体验；再到云上的TiDB Cloud 和 TiDB Serverless，以及联合 AI 技术实现的 Chat2Query，这些不仅仅是技术的叠加，而是将技术与商业价值进行紧密结合，以翻新的形式，为用户带来涌现的可能性和有限的时机。 在 2023 年 5 月 Stackoverflow 公布的超过 9 万名寰球开发人员参加的 2023 年度考察中， TiDB 成为在数据库相干考察中被提及的惟一一家来自中国的数据库。 在将来技术涌现，架构跃迁的征途上，咱们深信，交融是力量的源泉，当 HTAP、Serverless 和 AI 这些畛域的精髓汇聚一堂，咱们便能发明出无奈意料的奇观。 PingCAP 用户峰会 20237 月 13 日，PingCAP 用户峰会 2023 将在北京市海淀区东北华邑酒店举办， 线上线下同步 。 本届大会主题为“翻新涌动于先”，汇聚前沿数据科技与商业洞见，中国工程院院士倪光南将为大会致辞，现场将有来自 银行、保险、证券、政府，运营商，批发，制作、能源，物流，技术出海 等畛域 的代表客户汇聚一堂，探讨前沿数据技术的发展趋势与行业利用成绩，分享行业首领和专家智囊的实战经验与思维碰撞，构建多元的解决方案与生态单干。 诚邀您加入 PingCAP 用户峰会 2023，扫描下方二维码，立刻报名流动！ ...

作者：京东批发 肖勇一、 前言导读TiDB作为NewSQL，其在对MySQL（SQL92协定）的兼容上做了很多，MySQL作为当下应用较广的事务型数据库，在IT界尤其是互联网间应用宽泛，那么对于开发人员来说，1）两个数据库产品在SQL开发及调优的过程中，都有哪些差别？在零碎迁徙前须要提前做哪些筹备？ 2）TiDB的执行打算如何查看，如何SQL调优？ 本文做了一个简要演绎，欢送查阅交换。 二、 建表SQL语法差别&优化倡议 三、 查问SQL语法差别&优化倡议 四、 SQL执行打算差别&优化倡议 五、 TiDB执行打算剖析简介1. 在开始理论案例剖析前，咱们先看下执行打算中每列的含意：引自：https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain和https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain-analyze 2. 执行打算优化的几个关键点：1) 重点察看算子类型，尽量管制优化器抉择性能较优的算子，读取磁盘记录的几个算子性能：TableFullScan>TableRangeScan>TableRowIDScan，IndexFullScan>IndexRangeScan 2) 尽量减小root层执行动作，下放至tikv或tiflash执行，执行打算中task属性包含root task和cop task，其中root标识动作由tidb聚合层执行（此操作除了须要期待各分片后果外，个别部署构造中tidb资源也较tikv或tiflash少），cop标识动作下放至tikv或tiflash各分片独自执行 3) 保障表剖析数据完整性，防止大批量数据短时间内新增/删除，estRows为执行引擎依据状况返回的预估记录条数，特地留神：若operator info呈现stats:pseudo，则标识表根本信息不欠缺（无奈提供精确执行打算评估），后续可通过analyze表从新收集剖析数据，或显示use index对sql显示优化 4) 依据理论业务（如：列模式数据统计），减少tiflash模块，通过空间换工夫，晋升结构化查问和实时剖析能力 3. 理论场景剖析上面咱们通过2个理论SQL说说TiDB的执行打算： l SQL1 1：IndexLookUp算子：依据索引获取后果记录 2 & 3：Build算子总是优先于Probe算子执行，*2 算子依据条件从索引中获取数据，*3算子在后果中匹配后果 4：TableRowIdScan：通过 *3 算子后果中的表主键id从TiKV获取行记录 5：cop【tikv】标识将计算逻辑从tidb下放到tikv执行，同理还会有cop【tiflash】 6：tikv通过范畴索引扫描出对应记录 7：依据id获取行记录后间接返回下层，无需排序 ------------------------------------------------------------------------------------------------------------------------------ l SQL2 优化前，两表间接join： explain analyze SELECT m.id AS id, m.order\_id AS orderId, s.status AS status,m.sendpay\_map as sendPayMap FROM tableA m LEFT JOIN tableB s on m.order\_id = s.order\_id WHERE m.id >= 100 AND m.id <= 100000000 and m.warehouse\_id in (111,222) and s.status in (100, 200, 300, 400) and m.is\_valid = 1 order by m.id desc limit 20,20; ...

TiDB 是一款分布式数据库，它反对 SQL 语言，提供了相似于 MySQL 的接口，但具备更高的可扩展性和高可用性。TiDB 反对横向扩大，可能通过减少节点来扩大性能和存储容量。同时，它还提供了强一致性保障，保障了数据的一致性和可靠性。 TiDB 的数据源是一个用于连贯 TiDB 数据库的接口，能够通过该接口对 TiDB 中的数据进行查问和批改。在 TiDB 中，数据源应用 JDBC 或 ODBC 协定来与客户端进行通信。这些协定使得 TiDB 能够与各种不同的客户端程序进行交互，包含 Java 应用程序、Python 应用程序、BI 工具等等。TiDB 数据源还提供了连接池和负载平衡等性能，以进步性能和可靠性。 目前码匠曾经实现了与 TiDB 数据源的连贯，反对对 TiDB 数据进行增、删、改、查， 同时还反对将数据绑定至各种组件，并通过简略的代码实现数据的可视化和计算等操作，能让您疾速、高效地搭建利用和外部零碎。 在码匠中集成 TiDB步骤一：新建数据源连贯，抉择 TiDB 数据源，并依据提醒填写相应配置。 步骤二：新建 TiDB 查问，码匠中反对 SQL 模式和 GUI 模式，让您可能更加灵便便捷地操作数据。 步骤三：书写/抉择查询方法并展现/应用查问后果。 在码匠中应用 TiDB操作数据：在码匠中能够对 TiDB 数据进行增、删、改、查的操作，在 SQL 模式下能够自定义查问语句，在 GUI 模式下则有以下操作，即便对 SQL 语法不相熟也能疾速上手： 插入插入，抵触后更新更新删除批量插入批量更新应用数据：这两种模式下，用户能够在左侧的查问面板内查看数据结构，并通过{{yourQueryName.data}}来援用查问后果：对于码匠码匠是面向开发者的低代码平台，在帮忙企业实现个性化零碎搭建的同时，还可能省去前端开发，可极大进步开发时效，为企业实现降本增效。 码匠次要性能： 开箱即用，50+ 弱小好用的前端组件，反对 JS 以实现灵便的交互逻辑；连贯所有数据源：REST API、MySQL、MongoDB、Microsoft SQL server、Redis、Oracle 等 20 种以上；欠缺的用户接入计划：反对飞书、企微、钉钉接入。反对 SSO，反对 OAuth2.0、CAS、JWT 等协定灵便的自定义性能：自定义款式、自定义 CSS、自定义插件 & npm 插件 ；扩展性强：Javascript 三方库；反对私有化部署；反对权限治理，反对组织架构主动同步。1000家企业都在用码匠实现疾速开发，快来体验吧！ ...

作者：京东批发 张宾一、OMS供应链零碎零碎简介抖快电商业务与京东电商供应链能力之间的连接器，用于承载抖、快京东官网店铺业务。 二、面临业务挑战我的项目初期为了疾速适配业务开发，数据都存储在MySQL中，应用京东数据库中间件团队提供JED弹性库依照店铺维度的做的数据库分片。随着业务疾速倒退，存储数据越来越多，咱们在MySQL面临这如下痛点： 1.数据库单分片热点随着达人直播场次和拉新流动的减少，呈现局部店铺订单量爆涨，因为以后数据库分片策略是依照店铺维度进行分片，存在数据歪斜，零碎吞吐量预估到2000 QPS即达到性能瓶颈。按以后的订单量增长速度，半年内局部店铺的订单量可能超千万级，单表数据量过大。 2.大表构造批改艰难业务模式变动快，为了疾速响应业务需要，表构造常常调整。在对一些数据在百万级别以上的大表做 DDL 的时候，批改的工夫较长，对存储空间、IO、业务有肯定的影响。 3.经营端订单列表查问常常超时随着订单量增长，局部店铺的订单量超过千万之后，经营端订单列表查问会超时，经营端经营人员常常应用查问近7天、近30天的订单列表数据超时景象增多，经营端查问体验变差，同时订单列表性能导出也耗时重大。 4.抖快历史订单查问问题抖音、快手订单明细数据超过6个后，历史订单不再反对查问，须要将抖音、快手订单明细数据落地存储。 5.零碎吞吐量优化要晋升零碎吞吐量，须要调整数据库分片策略，要调整分片策略，首先要先解决经营端列表业务人员查问问题，所以必须首先且迫切的抉择一种存储两头解决来解决列表查问问题。 三、为什么抉择TiDB面对以上痛点，咱们开始思考对订单数据存储的架构进行降级革新，咱们依据业务方的诉求和将来数据量的增长，将一些常见数据存储技术计划做来一些比照： TiDB 具备程度弹性扩大，高度兼容 MySQL，在线 DDL，一致性的分布式事务等个性，合乎以后零碎数据量大，业务变更频繁，数据保留周期长等场景。联合团队成员常识储备和在不影响业务需要迭代状况下，以较少人工成本实现数据异构和数据库分片键的切换，通过调研发现公司数据库团队提供已TiDB中间件能力和反对，咱们通过对 TiDB 的内部测试后，确认能够满足现有业务需要。咱们最终抉择了 TiDB 做为这类需要的数据存储，并通过数据同步中件件DRC平台实现MySQL异构到TiDB。 四、技术实施方案1.零碎架构 2. 零碎中多数据源反对除了引入一些分库分表组件，Spring本身提供了AbstractRoutingDataSource的形式，让少数数据源的治理成为可能。同时分库分表组件应用上限度很多，应用之前须要理解去学习应用办法和忍耐中间件对SQL的刻薄要求，比照中间件以及以后我的项目应用的Spring技术栈，反而应用Spring本身提供了AbstractRoutingDataSource的形式可能让代码的改变量尽量的缩小。 Spring提供的多数据源能进行动静切换的外围就是spring底层提供了AbstractRoutingDataSource类进行数据源路由。AbstractRoutingDataSource实现了DataSource接口，所以咱们能够将其间接注入到DataSource的属性上。 咱们次要继承这个类，实现外面的办法determineCurrentLookupKey()，而此办法只须要返回一个数据库的名称即可。 public class MultiDataSource extends AbstractRoutingDataSource { @Getter private final DataSourceHolder dataSourceHolder; public MultiDataSource(DataSource defaultTargetDataSource, Map<Object, Object> targetDataSources) { //设置默认数据源，在未指定数据源状况下，则应用默认的数据源拜访 super.setDefaultTargetDataSource(defaultTargetDataSource); //多数据源配置 super.setTargetDataSources(targetDataSources); this.dataSourceHolder = new DataSourceHolder(); } @Override protected Object determineCurrentLookupKey() { //获取数据源上下文对象持有的数据源 String dataSource = this.dataSourceHolder.getDataSource(); //如果为空，则应用默认数据源resolvedDefaultDataSource if (StringUtils.isBlank(dataSource)) { return null; } return dataSource; }数据源上下文切换存储，应用ThreadLocal绑定这个透传的属性，像Spring的嵌套事务等实现的原理，也是基于ThreadLocal去运行的。所以，DataSourceHolder.实质上是一个操作ThreadLocal的类。 ...

vivo 是一家全球性的挪动互联网智能终端公司，品牌产品包含智能手机、平板电脑、智能手表等 ，截至 2022 年 8 月，已进驻 60 多个国家和地区，寰球用户笼罩 4 亿多人。 vivo 为用户提供了在手机上备份联系人、短信、便签、书签等数据的能力，底层存储采纳 MySQL 数据库进行数据存储。 随着 vivo 业务倒退，用户量增长迅速，存储在云端的数据量越来越大，海量数据给后端存储和数据库带来了微小的挑战。云服务业务最大的痛点，就是如何解决用户海量数据的存储问题 。 本文介绍了 vivo 的数据库和存储系统，以及如何应用分布式数据库 TiDB 解决海量数据挑战。 具体介绍了 vivo 采纳 TiDB 过程中的实在体验，包含海量数据实时 OLAP 计划、云服务业务中的元数据管理计划，和基于自研的 NoSQL 数据库 TiKV 的实际。 分享了如何解决海量数据存储和治理的问题，以及进步业务效率和用户体验的实践经验。 vivo 数据库与存储体系 <center>vivo 数据库与存储体系产品矩阵</center> 在整个 vivo 云服务体系中，数据库与存储处于外围地位，从体系上能够分为两层，最下面一层是工具产品层，蕴含数据库存储对立管控平台、数据传输服务（反对数据同步、数据订阅、数据迁徙等）、运维白屏化工具等。上面一层是数据库产品层，这一层又分为三个局部：一部分是 MySQL、 TiDB 等关系型数据库；一部分是 Redis、ElasticSearch、MongoDB、磁盘 KV 等非关系型数据库；还有一部分是对象存储、文件存储、块存储等存储服务。 <center>vivo 数据库与存储经营治理</center> 为了治理这些泛滥的数据库与存储产品，vivo 打造了一个数据库与存储经营治理平台，次要分为三层架构： 最底层是撑持、治理所有数据库的工具产品，蕴含数据存储服务、关系型数据库、NoSQL 数据库，以及生态工具；两头是性能层，包含根底存储服务、数据管理服务，以及存储自治服务；最下面是经营层，包含权限账单、用户治理、工单服务等根底服务。同时还有一些平安相干服务，如数据脱敏、数据加密、权限管控、命令通道、数据审计等一系列性能。TiDB 在 vivo 的落地实际 此前，vivo 曾经用了很多年关系型数据库 MySQL。基于原生的 MySQL 数据库，vivo 联合集群高可用的治理与数据库代理的一体化架构，通过域名服务、名字服务进行接入，提供通用的关系型数据库服务。它次要具备三大外围能力： 第一，兼容 MySQL 协定与 SQL 语法；第二，加强 MySQL 集群管控能力。vivo 引入 MySQL 的工夫很早，在 MySQL 的一些集群管控能力上都有自研的能力；第三，平安加强能力，包含明码治理、数据脱敏、数据加密等能力。实质上 MySQL 架构还是一个主从架构，并没有分布式技术引入。针对数据量较大、流量较大的场景，或者剖析场景，给业务带来了微小挑战。基于以上起因，vivo 在比照了支流分布式数据后后思考引入分布式关系型数据库 TiDB，作为关系型数据库产品矩阵的一环，补充整个关系型数据库的能力。引入 TiDB 帮忙 vivo 解决了一些在 MySQL 生态中无奈解决的问题： ...

转转技术 转转研发核心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。 各种干货实际，欢送交换分享，如有问题可随时分割 waterystone ~ 莫善 转转 DBA。 负责 TiDB，MongoDB，MySQL 运维及转转数据库平台开发。 转转是 PingCAP 最早的一批用户之一，见证了 TiDB 的倒退，本身也积淀了不少教训。 从 1.0 GA 开始测试，到 2.0 GA 正式投产，而后降级到了 2.1，起初又降级到 4.0.13，最初建设自动化平台。其实转转 DBA 团队初建以来就开始投入肯定的资源进行平台建设，一步一步实现自动化运维，心愿所有需要都能实现工单化、所有操作都能实现平台化，进而升高人力老本。 本文将分享转转 DBA 团队实现 TiDB 自动化的历程。从遇到问题开始，到解决问题，以及平台做成什么样，也是对过来工作的总结和梳理。 运维痛点转转现有集群 30 多套，晚期都是 2.1.[5,7,8,17] 版本，近 500 个 TiKV 节点，总共差不多一百台机器供 TiKV 应用，集群新建、扩容、迁徙都须要人工找机器。也因为短少一个上帝的视角去治理集群，没法做到资源的正当调配，导致日常工作中有很大一部分工夫都是在做迁徙，都是反复工作，效率很低。2.1 版本的运维工作都是基于 Ansible 进行。如扩容、下线、启停、批改配置等日常操作，有时候会碰到 Ansible 执行超时的状况。批量操作集群时，基本不晓得到哪个节点了，这状况常常能遇到，在 reload 集群配置文件的时候遇到的概率就十分大，要多解体有多解体。2.1 版本的 TiDB 本身有很多问题，执行打算生效、读写热点问题（不能疾速定位问题）、TiDB 大查问 OOM、乐观事务、监控不欠缺、以及已知/未知的问题，就连集群状态都无奈疾速获取，当然备份也很苦楚，这对运维人员的工作加大了难度，也晋升了人力老本。4.0 应用乐观事务须要满足肯定的要求，具体请参考官网文档。机器资源应用不均衡，存在局部机器内存残余较多然而磁盘有余，还有局部机器内存不足，然而磁盘残余很多。导致的后果是老板感觉机器投入曾经很大，然而 DBA 理论应用中发现机器还是不够用。告警乐音比拟多，存在反复告警，相互冲刷问题，重大节约告警资源，对排查问题也带来很不敌对的体验。解决痛点元数据管理将所有节点信息保留到表里，定期采集节点状态及资源应用状况。 过来都是依附 Ansible 的配置文件进行治理，治理视角根本是停留在集群都有哪些节点，连一台机器都有哪些实例都不分明，更别谈资源管理了。 当初将所有组件保留到一个表中，定期采集组件服务状态，内存磁盘占有量等信息。这样就有了一个全局的视角进行治理，也很不便的查阅集群状态。 后续基于这份元数据进行我的项目成本核算。还有一个收益就是，组件信息的采集，能够很好的管制单个 TiKV 的容量，不会再呈现单个集群容量始终增长，而后触发机器的磁盘告警 DBA 才感知到。有了这个采集的数据后，能够设置一个 TiKV 容量下限，比方 500GB，达到这个阈值就发送告警给 DBA 筹备扩容。这样能很好的防止因机器磁盘告警而接管大量告警信息（单机多实例），也能提供一个很好的缓冲工夫让 DBA 来解决。 ...

本文整顿自网易互娱资深工程师, Flink Contributor, CDC Contributor 林佳，在 FFA 实时风控专场的分享。本篇内容次要分为五个局部： 实时风控业务会话会话关联的 Flink 实现HTAP 风控平台建设晋升风控后果数据能效倒退历程与展望未来 家喻户晓，网易互娱的外围业务之一是线上互动娱乐应用服务，比方大家耳熟能详的梦幻西游、阴阳师等都是网易互娱的产品。不论是游戏产品还是其余利用，都须要做出好的内容来吸引用户进行利用内购买，进而产生盈利。 当用户在商城里点击商品进行购买的时候，会弹出领取界面，进行验证、领取后，就能够收到道具了。这个过程对于用户来说往往都是一些非常简单的操作，但为了保障这个过程能够正确结算、发货，整个领取流程其实逾越了很多服务提供商和终端，走了一条相当简单的调用链路。这些不同的业务节点之间会产生很多互相的调用关系，进而产生一些异构的日志、数据、记录。 因为通过了网络，其中的数据可能会有肯定工夫水位线的不统一、提早，甚至数据失落的状况，且自身这些数据又很可能是异构的，就更增大了咱们对这些数据进行剖析和应用的难度。 如果咱们须要用这些数据进行高时效性的故障排查或者危险管制，就势必须要研制一套计划，来适配这样技术需要。为了解决以上的问题，咱们以 Flink 为计算引擎构建了一套实时风控平台，并为他起名为 Luna，上面我将为大家进行具体的介绍。 实时风控业务会话 常见的线上领取逻辑是，当用户在利用上点击商城的道具进行利用内购买的时候，用户的客户端终端就会到计费零碎进行下单，取得本次下单的订单信息。 而后咱们的客户端会弹出领取界面，用户进行渠道付款。 当领取实现后，咱们会把渠道返回给客户端的领取凭证回传给计费零碎，计费零碎会去渠道验证凭证是否无效。 如果是无效的，就会告诉游戏服务器发货，这个时候咱们的客户端才会收到道具。这就是从用户点击到最终收到道具的整个流程。 从这个曾经极度简化了的领取模型能够看到，不同的公司、服务提供商、部门、服务零碎会产生了一系列会话下的数据。如果咱们能把这些数据收集起来，进行肯定的解决后，还原过后用户操作的现场。这将对经营运维人员在定位故障、排查故障，甚至整个业务环境的宏观剖析都有着十分重要的价值。 而剖析的关键点是，咱们如何还原这个行为的现场，咱们把这个行为的现场叫风控业务会话，即由一次用户行为所引发的，须要多个零碎合作实现、同时触发多个申请、产生逾越多个服务提供方调用的全过程。 这里须要留神的是，业务会话逾越了多个互相独立的申请链路，且没有对立全局的 trace-id 能够被提前置入所有的数据中。 因为咱们的业务会话须要逾越多个申请链路，所以在数据关联剖析的时候就存在很多难题。比方 多服务、多申请产生的异构后果难以间接关联。调用程序简单，存在并发、异步的状况。时间跨度大、业务水位不同步。以前在解决领取丢单、领取一次反复发货等问题的时候，往往只能通过经营人员去解决，这就十分依赖于运维人员的教训了。并且在这些大量的数据里，会有十分多冗余和无用字段，还有可能会有一些非常复杂的嵌套关系。这些都有可能让运维人员在判断时产生错判和误判。此外，还会给运维人员带来十分多的重复性工作，从而使得人力能效低下，把工夫节约在反复的事件上。 前文也提到了开源 Tracing 计划，往往须要依赖全局的 trace-id。对于新的零碎，咱们能够提前设计 trace-id 打点。然而对于有历史包袱的零碎来说，他们往往不违心批改跟踪来跟踪打点，那么这个时候传统的计划就走不通了。 在这种状况下，如果咱们要进行业务会话还原，就须要设计一套新的计划。这套计划咱们心愿能够具备以下性能： 实时宏观业务会话检索与查错。实时宏观业务环境统计与风控。业务会话级数据能效开掘与晋升。 从还原业务会话到应用数据做 HTAP 实时风控平台的全过程，咱们应用 Flink 生产原始数据，依据平台上提前配置好的剖析模板，实时还原出业务会话。而后把业务会话的后果存储存起来，并为它打上咱们提前设置好的一些论断模型，产生的风控论断。 对于存储起来的这些宏观会话进一步被聚合，进而产生整个业务环境上的宏观统计量，以反对咱们在整个平台上的风控剖析需要。 会话关联的 Flink 实现Flink 是实时计算的施行规范，基于此咱们毫无疑问地抉择了它。 那么实时业务会话关联在 Flink 零碎上，咱们心愿能够做出怎么的成果呢？ 第一，零侵入。即无需对现有业务进行改变，也无需有全局的跟踪 ID，就能够做到业务会话的还原。第二，跨数据源。因为咱们的业务往往须要逾越 n 种数据源，所以咱们心愿这 n 种数据源都能够被这个零碎所反对，比方日志、维表、事实表、REST 接口等。第三，实时。实时产生后果，无需期待 T+1。第四，低代码。咱们心愿基于剖析需要，能够通过向导式的配置，来产生实时的剖析模板，并对宏观统计报表，能够配置式的进行多维度聚合。 上图展现的是 JFlink-SDK，它是网易自研的一套流治理平台以及它的开发手脚架 SDK。大家能够把它了解成是一套能够模块化配置式开发的流作业手脚架，实时关联剖析的引擎就是基于这套手脚架开发进去的。 ...

内容概要TiCDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 能够将数据解析为有序的行级变更数据输入到上游。 本文是 TiCDC 源码解读的第三篇，次要内容是讲述 TiCDC 集群的启动及根本工作过程，将从如下几个方面开展： TiCDC Server 启动过程，以及 Server / Capture / Owner / Processor Manager 概念和关系TiCDC Changefeed 创立过程Etcd 在 TiCDC 集群中的作用Owner 和 Processor Manager 概念介绍，以及 Owner 选举和切换过程Etcd Worker 在 TiCDC 中的作用残缺视频回顾 启动 TiCDC Server启动一个 TiCDC Server 时，应用的命令如下，须要传入以后上游 TiDB 集群的 PD 地址。 cdc server --pd=http://127.0.0.1:2379它会启动一个 TiCDC Server 运行实例，并且向 PD 的 ETCD Server 写入 TiCDC 相干的元数据，具体的 Key 如下： /tidb/cdc/default/__cdc_meta__/capture/${capture_id}/tidb/cdc/default/__cdc_meta__/owner/${session_id}第一个 Key 是 Capture Key，用于注册一个 TiCDC Server 上运行的 Capture 信息，每次启动一个 Capture 时都会写入相应的 Key 和 Value。 ...

近日，平凯星辰 TiDB 分布式数据库胜利中标杭州银行外围零碎数据库我的项目。平凯星辰凭借前瞻的产品技术计划、金融畛域的教训积攒、业余疾速的服务保障及高度沉闷的开源社区，在竞争中怀才不遇。此次中标再次印证了 TiDB 新一代分布式数据库在银行外围零碎建设、确保业务连续性以及反对业务麻利高效翻新等方面具备要害的服务能力。 外围零碎是银行交易和账户解决的核心，是银行信息系统的根底和外围，被誉为银行的“心脏”。在数字经济的倒退和新技术崛起的背景下，杭州银行保持自主研发、自主翻新的零碎建设思路，利用云原生、微服务等技术重构杭州银行技术架构和能力体系，打造满足将来业务倒退的新一代全栈式自主可控的分布式技术平台，构建稳固高效和灵便麻利兼备的外围零碎。 分布式数据库是外围零碎技术平台的要害组成部分，杭州银行 2019 年启动国产分布式数据库畛域的前沿技术钻研，有打算、分步骤地推动分布式数据库在业务场景的落地。围绕银行外围业务零碎：数据量大、交易数据变更频繁，交易热点集中；多渠道接入、交易并发量大；数据重要性高、安全等级要求高；零碎可用性、可靠性低等特点；在本次新一代分布式外围零碎数据库的选型上，秉持“SAPE”准则（即 Safe 高平安、Availability 高可用、Performance 高性能和 Ecology 多生态）；保持参照金融行业分布式数据库利用相干标准，联合杭州银行业务倒退和新一代分布式外围零碎整体架构的思路，发展适配新一代分布式外围零碎的金融级分布式数据库选型工作。 在本次外围零碎数据库选型过程中，杭州银行组织多方，共建“风洞实验室”从软件开发、建设部署、数据迁徙、业务交易、运维监控和容灾切换等多个维度，独特设计产品测试场景和用例，对 TiDB 进行了全面详尽的测试验证。测试结果表明，TiDB 在开发易用性、混沌故障注入稳定性测试、多核心多活、性能横向扩大、HTAP 个性上具备显著的先进性。从开放性上看，TiDB 在技术社区的活跃度、开发平台适配方面具备较显著的劣势，领有高度凋谢的数据技术生态。 基于后期选型成绩和互联网外围的成功实践，杭州银行在新一代分布式外围零碎中抉择 TiDB 用于数据底座。 TiDB 历经寰球 3000 多家行业用户海量数据的严苛场景打磨，稳固牢靠，具备金融要害外围业务的撑持能力。TiDB 分布式数据库胜利利用于中国银行、建信金科、浦发银行、北京银行、浙商银行、中国人寿、安全科技、微众银行等多家金融企业的联机交易、在线领取、信贷管理、实时风控等场景，帮忙金融机构将外围的业务及数据能力下沉和拓展到更多场景，减速数字化转型与降级。

作者：京东给物流 刘家存随着数据量的增大，传统关系型数据库越来越不能满足对于海量数据存储的需要。对于分布式关系型数据库，咱们理解其底层存储构造是十分重要的。本文将介绍下分布式关系型数据库 TiDB 所采纳的底层存储构造 LSM 树的原理。 []()1 LSM 树介绍LSM 树（Log-Structured-Merge-Tree) 日志构造合并树由 Patrick O’Neil 等人在论文《The Log-Structured Merge Tree》(https://www.cs.umb.edu/~poneil/lsmtree.pdf)中提出，它实际上不是一棵树，而是2个或者多个不同档次的树或相似树的构造的汇合。 LSM 树的外围特点是利用程序写来进步写性能，代价就是会略微升高读性能（读放大），写入量增大（写放大）和占用空间增大（空间放大）。 LSM 树次要被用于 NoSql 数据库中，如 HBase、RocksDB、LevelDB 等，出名的分布式关系型数据库 TiDB 的 kv 存储引擎 TiKV 底层存储就是用的下面所说的 RocksDB，也就是用的 LSM 树。 []()2 LSM 树算法大略思路LSM 树由两个或多个树状的构造组成。 这一节咱们以两个树状的构造形成的简略的双层 LSM 树举例，来简略说下 LSM 树大略思路，让大家对 LSM 树实现有个整体的意识。 原论文中的图 []()2.1 数据结构双层 LSM 树有一个较小的层，该层齐全驻留在内存中，作为 C0 树（或 C0 层），以及驻留在磁盘上的较大层，称为 C1 树。 只管 C1 层驻留在磁盘上，但 C1 中常常援用的节点将保留在内存缓冲区中，因而C1常常援用的节点也能够被视为内存驻留节点。 []()2.2 写入写入时，首先将记录行写入程序日志文件 WAL 中，而后再将此记录行的索引项插入到内存驻留的 C0 树中，而后通过异步工作及时迁徙到磁盘上的 C1 树中。 ...

同盾科技是中国当先的人工智能科技企业。为了确保服务的低提早和高可用性，同盾的技术团队一直寻找最佳的技术架构。通过长时间调研，他们最终抉择了新一代分布式数据库 TiDB 作为离线层的外围数据库，基于 TiDB 打造的实时数据架构为风控智能决策保驾护航。 同盾科技是中国当先的人工智能科技企业，专一决策智能畛域，致力于帮忙政企客户防备危险、晋升决策效率。同盾科技保持自主科技翻新，多项算法和软件系统已达寰球领先水平，并造成了“基于隐衷计算的共享智能平台-智邦”和“基于人工智能的决策智能平台-智策”两大平台，聚焦于金融风险、平安危险、政府治理危险三大场景，业务笼罩寰球数十个国家，为 22 大行业、118 个细分场景的上万家客户提供了当先且独具特色的决策智能解决方案。 风控业务场景对数据库的需要与挑战作为一家第三方风控公司，客户常常须要调用同盾的智能决策服务去做业务决策，如电商大促期间防备黑产薅羊毛，集体信贷杜绝多头借贷老赖行为等。因而，同盾服务调用经常呈现出十分大的 TPS 申请。同时，为了不影响客户调用服务的品质与体验，同盾对低提早和高可用有着硬性要求。 基于这样的特色，同盾日均过亿的决策服务调用，会产生包含非结构化/结构化多种数据结构类型在内的海量数据入库。丰盛的数据类型与多样的细分场景，使得同盾科技必须应用多种数据库去满足不同的业务场景需要，在同盾的数据架构中蕴含了 Cassandra、MySQL、HBase、Redis、Mongo 等数据库。 在同盾的数据架构中，大多数初始落库的数据还比拟原始，为了提供优质的数据服务用于智能决策，技术团队构建了成熟的大数据平台，用 T+1 离线数据分析的形式去进行日常的离线数据分析作业，利用数据二次加工赋能下层的风控智能决策。 但面对简单的数据基础架构，同盾在业务增长中也遭逢了如下挑战： 同盾领有在线数千个大大小小的 MySQL 工作实例，数据非常扩散，有一些是外围的风控业务零碎数据，有一些是后盾基础架构平台的数据，还有一些是团体 IT 零碎数据，同盾心愿通过集中化的形式对这些数据进行剖析治理；最开始同盾将上游 MySQL 数据同步到上游进行剖析，但整个过程中数据交换工作效率非常低，整体作业剖析的 SLA 无奈失去保障；因为上下游数据同步的阻塞问题，导致了离线数据同步实时性很差，上下游数据经常出现数据不统一的状况，十分影响提供给作业的数据品质。其实同盾科技的业务场景并不简单，只须要同步生产环境中数千个 MySQL 实例至上游的离线零碎，提供给作业开发人员通过大数据平台进行离线剖析加工。我的项目的外围指标是在海量数据落库下，保障在线到离线数据的数据库的准实时性和一致性，并提供优质的数据服务给外部的风控系统开发人员、算法模型工程师和经营人员加工数据。 为什么抉择 TiDB？通过长时间调研，同盾科技的技术团队最初抉择了新一代分布式数据库 TiDB 作为离线层的外围数据库。同盾科技数据库运维梁高升示意，次要有以下几点起因最终促成同盾抉择 TiDB ： 首先，TiDB 高度兼容 MySQL 协定，在 TiDB 的应用和运维过程中大大加重了运维和开发人员的应用老本； 第二，TiDB 作为分布式数据库，同盾能够把它看成一个大的数据库实例，能够汇聚上游所有的MySQL实例数据； 第三，TiDB 具备存算拆散的架构，能够让同盾非常灵活地管制硬件老本，而不必一味堆砌服务器； 最初，TiDB 领有十分沉闷的社区。即便在应用 TiDB 的过程中遇到一些问题也马上能在社区失去解决。 解决方案 最终，同盾科技数据库团队构建了一整套基于 TiDB 的数据流转架构，该架构共分为三层： 实时数据层同盾外部有 3000+ MySQL 实例，在实时数据库层通过 MySQL Cloud 管控上游数千个 MySQL。 传输层在传输层，从 MySQL Cloud 对接实时数据同步工作到外部 Otter，Otter 能够实现准实时同步 MySQL 数据，而后再由 Otter 实时同步数据到 TiDB。 ...

在 2023 伊始，咱们很快乐向大家发表，TiDB 6.5 LTS 版本曾经公布了。这是 TiDB V6 的第二个长期反对版（上一个是 TiDB 6.1），除了携带了诸多备受期待的新个性，同时也将失去 TiDB 开发社区的长期保护，是举荐企业级用户采纳的最新版本。 在这个版本中，TiDB 专一于如下几个主题： 产品易用性进一步晋升内核一直打磨，更加成熟多样化的灾备能力利用开发者生态构建置信长期关注咱们的敌人曾经发现，这些主题似曾相识。的确如此，TiDB 近年的倒退简直都围绕着它们发展。咱们冀望 TiDB 成为更易用，对开发者更敌对，且更成熟的企业级数据库，而这个谋求也并没有止境。 产品易用性进一步晋升大家兴许不止一次据说过，易用性之于 TiDB 是十分要害的理念。毕竟，TiDB 伊始是为了解决分库分表带来的麻烦，这也使得易用性在 TiDB 研发过程中贯通始终。在新版本中，咱们提供了更多的让用户解放心智的能力。 AND 运算下的索引归并读取对于数据服务和洞察场景，用户往往会基于诸多查问条件的组合进行数据筛选。例如在物流场景中，用户可能会依据下单日，仓库 ID，转运人，送达日，指标地址等等不同维度进行筛选再剖析。而这些条件独自来看，并不一定具备很好的选择性，只有组合起来能力将数据限定在一个小范畴。如果条件的组合不多，咱们尚可应用特定的组合索引笼罩，但很可能在这类场景中，组合以数十记，齐全无奈为每个组合都创立特定索引。在新版本中，TiDB 反对依据 AND 条件组合同时选中多组索引，并计算它们的交加再读取理论表数据。这种能力，使得用户能够仅仅为单列创立大量索引，以达到更好的选择性以及更优的性能。 集群闪回有时候，用户会心愿整个集群疾速复原到之前的某个工夫点。例如，因为游戏服务器新版本数据设定问题，将一把绝世好剑设定为 1 元，造成新版公布后一小时内人手一把。若仅仅如此也就算了，开发者能够很容易回收或这个道具，但这种事变还有次生灾祸，例如罕见 Boss 被滥杀，罕见掉落随之泛滥，整个游戏内容崩坏。这时候作为游戏设计师，你可能会心愿工夫能回到犯错之前的那一刻，让你修改那个令人追悔莫及的谬误。在新版本中，TiDB 就提供了这个能力，它反对用简略一条命令向 GC 工夫内的任意工夫点进行全集群闪回，就像上面这样。 FLASHBACK CLUSTER TO TIMESTAMP '2022-09-28 17:24:16'; 咱们当然心愿这不会是一个常见的情况，但这并不示意须要闪回的机会千年难遇：闪回能力也可用于日常操作，例如将测试环境复原到测试开始前的状态，以供重复应用。 残缺的大事务主动拆分反对在前序版本中，咱们反对了针对删除的大事务主动拆分反对。而在新版本中，TiDB 残缺反对了针对插入和批改的大事务拆分。在以往版本中，TiDB 用户常常要面对的一个问题就是，一些大规模的数据变更保护操作，例如过期数据删除，大范畴数据订正，或者依据查问后果回写数据等操作，会遇到超过 TiDB 单条事务下限的问题，这是因为 TiDB 繁多事务须要由繁多 TiDB Server 作为提交方而带来的限度，这时候用户往往不得不手动想方法拆小事务以绕过该限度。但在理论应用中，上述类型的数据变更未必真的须要作为繁多事务确保原子性，例如数据淘汰和数据订正，只有最终执行实现，哪怕事务被拆开屡次执行也并不会影响应用。在 TiDB 6.5 中，咱们提供了将大事务主动拆分的能力，例如依照 t1.id 以 10000 条为大小分批数据更新，能够简略应用如下语句实现： BATCH ON t1.id LIMIT 10000 update t1 join t2 on t1.a=t2.a set t1.a=t1.a*1000;更具体的阐明请参考文档。 ...

2022 年，咱们一起穿梭了许多荆棘时刻，面对着前所未有的不确定性。在这些挑战背后，咱们发现技术和开发者表演了重要角色。 技术为咱们提供了穿梭周期的桥梁，开发者帮忙咱们更好地应答挑战，解决问题并赋予这个世界更多创造力 。 PingCAP 也在过来一年迎来了新的进化，岁末年初，咱们想邀请你独特回顾属于 PingCAP 用户和开发者的 2022 年度记忆。 1用户信赖这一年中，用户的信赖对于咱们来说至关重要。“PingCAP 到明天曾经成立 7 年了， 在寰球领有 3,000 多家大中型用户 ，其中很多还参加到 TiDB 开源社区的建设中，这些状况如果放到守业之初很难设想。明天，咱们意识到做一个真正广泛应用的数据库，是一个须要以十年为工夫单位进行投入的根底工程。 这一路走来离不开关怀和反对 PingCAP、喜爱 TiDB 的每个人 。”——刘奇6 月，PingCAP 作为中国惟一数据库厂商入选 2022 Gartner 云数据库“客户之声”，获评“卓越表现者”最高分 ，这标记着寰球企业用户对 PingCAP 企业级能力的认可。在中国，国有大行、城商行、互联网银行、证券、保险、电商、新批发以及政府部门，都在更多地使用 TiDB HTAP 实现数据库架构的简化和实时数据分析，晋升终端用户体验：百胜中国 ：在业务中台中采纳 TiDB 技术，撑持肯德基、必胜客的手机点餐和数字领取。中国人寿财险 ：第一次在保险行业联机交易和批量业务场景引入 NewSQL 分布式数据库，实现了技术演进迭代和整体降本增效的指标。杭州银行 ：TiDB 胜利投产杭州银行“金融级云原生技术平台及分布式外围业务零碎”，印证了 TiDB 在银行外围零碎革新、确保业务连续性、反对业务麻利高效翻新等方面具备要害的服务能力。安信证券 ：客户资产核心零碎应用 TiDB 取代原有大数据技术栈，稳定性增强并晋升了数据服务效率，PingCAP 与华锐技术 ATP 团队联合推出的“全栈自主的分布式外围交易系统平台”解决方案进入要害验证阶段。龙湖团体 ：TiDB 为龙湖团体 CRM 售卖、鹅塘租赁、电子商城等业务提供高性能的 OLTP 在线交易撑持， HTAP 实时剖析为”千人千面”的服务翻新打造松软的数据底座。云盛海宏 ：TiDB 上线云海批发零碎，服务于 6,000 万会员和近万家线下门店的批发。9 月 22 日， 在 PingCAP 用户峰会上 ， 来自 建信金科、百胜中国、传音控股、老虎国内、安全科技、杭州银行、中国人寿财险、工商银行、 神州数码、 东软团体、中电金信、嘉和美康、云徙科技、天翼云等 多家 PingCAP 重量级客户、合作伙伴及产业大咖独特相聚在线下，分享数字化转型与数据价值翻新中的抉择，探讨如何通过面向未来的麻利数据服务平台实现业务的减速和翻新。 ...

近些年，因为互联网的疾速倒退以及线上需要的暴发，直播在国内曾经成为一个十分成熟的商业模式。在娱乐、教育、办公等场景中涌现出许多优良的视频直播产品。随着国内市场竞争日益白热化，加之企业出海渐成趋势，越来越多的直播公司抉择走进来，寻找新的海内直播市场，借鉴国内成熟的产品、经营以及商业模式，让寰球的用户都用上中国人发明的产品，LiveMe 便是胜利的出海直播产品之一。 LiveMe 是一个寰球直播和社交平台，于 2016 年 4 月推出。LiveMe 的产品性能包含 H2H、多人聊天、虚构形象直播、蹦迪房等，它使用户可能随时随地直播、并观看其余精彩的直播以及与世界各地的敌人进行视频聊天。目前 LiveMe 已在寰球积攒了超过 1 亿用户和超过 300 万的主播。它已成为美国最受欢迎的社交应用程序之一，并已在 200 多个国家和地区推出。 业务痛点与其余行业出海一样，直播产品的出海也面临着许多全球化挑战。如各地的合规监管、本地化经营、继续翻新、政治文化差异等，都为直播产品出海带来微小挑战。而在出海的过程中，底层的技术能力帮忙 LiveMe 在老本节约、用户增长、金融风控、晋升研发效率等方面一直实现精细化经营与业务翻新。 通过了多年的积淀，LiveMe 在业务上曾经造成了线上微服务主导，线下计算中心主导的技术架构。线上业务是通过 Go 语言开发的一套微服务架构，每个服务依据不同业务个性具备本人独立的存储。线下业务是由数据研发团队来保护，通过 sqoop 和 MySQL Binlog 同步等形式从数据库层面抓取数据到数据仓库，实现一系列业务相干的反对。 这套业务架构中线上业务次要面临着以下痛点： 第一，尽管实现了微服务分库的设计，每个服务都有本人独立的数据库，然而每个业务中又存在很多业务上的大表，都存在 MySQL 分表的景象。在典型的分表场景中，数据库表会依照用户的 UID 尾号通过 MD5 后分到 256 张表，然而与日俱增后又须要再依据工夫日期做一个垂直的分表，导致数据库表无奈实现聚合查问，再加上跨时间段的分表需要，很多场景无奈满足线上需要。 第二，对于剖析型业务数据而言，须要保证数据的实时性，并保留数据细节。实时的数据分析，能够在业务上更快做出决策，例如在一些流动经营场景中，业务团队须要疾速从各个数据维度来分组统计察看流动成果；在金融相干风控业务中，须要依据各个维度疾速聚合来判断各项数据是否达到风控模型的阈值。如果应用离线计算的形式，数据的实时性根本无法失去保障；此外，通过离线计算或者实时计算过的数据，如果用户反馈数据有问题，须要查看数据的细节也很难实现。 第三，各种精细化经营需要，例如举荐、个性化经营等场景一直减少，对于数据的实时要求越来越高。因而，LiveMe 急需一种更简略，同时让线上线下业务做好均衡的计划。 此时，如果 LiveMe 持续抉择大数据技术栈解决痛点就会面临以下挑战：1）大数据技术栈的架构非常复杂，中间件过多；2）须要额定的技术栈学习老本，比方如果应用数据同步，就须要 sqoop、scala、kafka 等中间件，会大幅减少整个业务的复杂性；3）心愿线上业务以及架构非常简单，可能简化到一般开发人员只有可能 CRUD（减少(Create)、读取(Read)、更新(Update)和删除(Delete)） 数据库就能够上手开发。 为什么抉择 TiDB ？基于以上业务挑战，LiveMe 通过一系列技术选型后最终抉择了 TiDB 数据库。TiDB 的以下个性能够帮忙 LiveMe 很好的应答挑战： TiDB 的性能大于等于 MySQL ；TiDB 的 HTAP 个性可能解决线上大表的问题，在后盾或者一些实时剖析场景中，其 OLAP 剖析能力可能保障实时数据报表；TiDB 引入的 MPP 架构剖析能力，使得 OLAP 查问速度十分快，这也是 OLAP 数据库架构上的技术方向；TiDB 团队有着欠缺和业余的技术支持，在过程中能够帮忙 LiveMe 解决很多问题，在线上大规模应用后也没有后顾之忧。如何利用 TiDB 实现实时聚合查问鉴于 LiveMe 的微服务架构，如果将数据源全副替换，工程量大且不能欲速不达，因而就须要一种兼容性的计划，在保障线上业务不受影响的同时也能应用 TiDB 的个性来解决 LiveMe 的业务痛点。因而，对于须要聚合查问的业务， LiveMe 通过音讯队列播送的形式，在业务层订阅相干事件再补充业务侧须要的宽表信息写入 TiDB，基于 TiFlash 就能够做到实时的经营报表。业务开发人员只须要编写对应的 SQL 查问，就能够轻松实现需要。没有了简单的 ETL 过程，大大简化了开发流程。 ...

在2023 伊始，咱们很快乐向大家发表，TiDB 6.5 LTS 版本曾经公布了。这是 TiDB V6 的第二个长期反对版（上一个是 TiDB 6.1），除了携带了诸多备受期待的新个性，同时也将失去 TiDB 开发社区的长期保护，是举荐企业级用户采纳的最新版本。 在这个版本中，TiDB 专一于如下几个主题： 产品易用性进一步晋升内核一直打磨，更加成熟多样化的灾备能力利用开发者生态构建置信长期关注咱们的敌人曾经发现，这些主题似曾相识。的确如此，TiDB 近年的倒退简直都围绕着它们发展。咱们冀望 TiDB 成为更易用，对开发者更敌对，且更成熟的企业级数据库，而这个谋求也并没有止境。 产品易用性进一步晋升大家兴许不止一次据说过，易用性之于 TiDB 是十分要害的理念。毕竟，TiDB 伊始是为了解决分库分表带来的麻烦，这也使得易用性在 TiDB 研发过程中贯通始终。在新版本中，咱们提供了更多的让用户解放心智的能力。 AND 运算下的索引归并读取对于数据服务和洞察场景，用户往往会基于诸多查问条件的组合进行数据筛选。例如在物流场景中，用户可能会依据下单日，仓库 ID，转运人，送达日，指标地址等等不同维度进行筛选再剖析。而这些条件独自来看，并不一定具备很好的选择性，只有组合起来能力将数据限定在一个小范畴。如果条件的组合不多，咱们尚可应用特定的组合索引笼罩，但很可能在这类场景中，组合以数十记，齐全无奈为每个组合都创立特定索引。在新版本中，TiDB 反对依据 AND 条件组合同时选中多组索引，并计算它们的交加再读取理论表数据。这种能力，使得用户能够仅仅为单列创立大量索引，以达到更好的选择性以及更优的性能。 集群闪回有时候，用户会心愿整个集群疾速复原到之前的某个工夫点。例如，因为游戏服务器新版本数据设定问题，将一把绝世好剑设定为 1 元，造成新版公布后一小时内人手一把。若仅仅如此也就算了，开发者能够很容易回收或这个道具，但这种事变还有次生灾祸，例如罕见 Boss 被滥杀，罕见掉落随之泛滥，整个游戏内容崩坏。这时候作为游戏设计师，你可能会心愿工夫能回到犯错之前的那一刻，让你修改那个令人追悔莫及的谬误。在新版本中，TiDB 就提供了这个能力，它反对用简略一条命令向 GC 工夫内的任意工夫点进行全集群闪回，就像上面这样。 FLASHBACK CLUSTER TO TIMESTAMP '2022-09-28 17:24:16'; 咱们当然心愿这不会是一个常见的情况，但这并不示意须要闪回的机会千年难遇：闪回能力也可用于日常操作，例如将测试环境复原到测试开始前的状态，以供重复应用。 残缺的大事务主动拆分反对在前序版本中，咱们反对了针对删除的大事务主动拆分反对。而在新版本中，TiDB 残缺反对了针对插入和批改的大事务拆分。在以往版本中，TiDB 用户常常要面对的一个问题就是，一些大规模的数据变更保护操作，例如过期数据删除，大范畴数据订正，或者依据查问后果回写数据等操作，会遇到超过 TiDB 单条事务下限的问题，这是因为 TiDB 繁多事务须要由繁多 TiDB Server 作为提交方而带来的限度，这时候用户往往不得不手动想方法拆小事务以绕过该限度。但在理论应用中，上述类型的数据变更未必真的须要作为繁多事务确保原子性，例如数据淘汰和数据订正，只有最终执行实现，哪怕事务被拆开屡次执行也并不会影响应用。在 TiDB 6.5 中，咱们提供了将大事务主动拆分的能力，例如依照 t1.id 以 10000 条为大小分批数据更新，能够简略应用如下语句实现： BATCH ON t1.id LIMIT 10000 update t1 join t2 on t1.a=t2.a set t1.a=t1.a*1000;更具体的阐明请参考文档。 ...

内容概要TiCDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 能够将数据解析为有序的行级变更数据输入到上游。 本文是 TiCDC 源码解读的第二篇，将于大家介绍 TiCDC 的重要组成部分，TiKV 中的 CDC 模块。咱们会围绕 4 个问题和 2 个指标开展。 TiKV 中的 CDC 模块是什么？TiKV 如何输入数据变更事件流？数据变更事件有哪些？如何确保残缺地捕获分布式事务的数据变更事件？心愿在答复完这4个问题之后，大家能： 理解数据从 TiDB 写入到 TiKV CDC 模块输入的流程。️ 理解如何残缺地捕获分布式事务的数据变更事件。在上面的内容中，咱们在和这两个指标相干的中央会标记上 和 ️，以便揭示读者注意本人感兴趣的中央。 TiKV 中的 CDC 模块是什么？CDC 模块的状态从代码上看，CDC 模块是 TiKV 源码的一部分，它是用 rust 写的，在 TiKV 代码库外面；从运行时上看，CDC 模块运行在 TiKV 过程中，是一个线程，专门解决 TiCDC 的申请和数据变更的捕获。 CDC 模块的作用CDC 模块的作用有两个： 它负责捕获实时写入和读取历史数据变更。这里提一下历史数据变更指曾经写到 rocksdb 外面的变更。它还负责计算 resolved ts。这个 resolved ts 是 CDC 模块外面特有的概念，模式上是一个 uint64 的 timestamp。它是 TiKV 事务变更流中的 perfect watermark，perfect watermark 的具体概念参考《Streaming System》的第三章，咱们能够用 resolved ts 来告知上游，也就是 TiCDC，在 tikv 上所有 commit ts 小于 resolved ts 事务都曾经残缺发送了，上游 TiCDC 能够残缺地解决这批事务了。CDC 模块的代码散布CDC 模块的代码在 TiKV 代码仓库的 compoenetns/cdc 和 components/resolved_ts 模块。咱们在下图中的黑框外面用红色标注了几个重点文件。 ...

制造业是一个古老而悠久的行业，它的起源最早可追溯到石器时代。从新石器时代简略的工具，到明天简单的智能工厂，制造业历经千年倒退，变质成了由技术驱动的翻新行业，充斥各种自动化流程、始终互连的设施和数据丰盛的流程。 本文将以数益工联数字化工厂为例，介绍“离散型”制造业面临的数据挑战，以及分布式 HTAP 数据库 TiDB 如何助力工业数据价值的开掘。 “离散型”制造业面临数据挑战在制造业中，通常有着“流程型”和“离散型”两种辨别。“流程型”是指被加工对象不间断地通过生产设施，通过一系列的加工安装使原材料进行化学或物理变化，最终失去产品。典型的流程生产制造业有医药、化工、石油化工、电力、钢铁制作、能源、水泥等畛域。“离散型”制作，则是指资料的生产过程通常被合成为多项加工工作。典型的离散制作行业次要包含机械制造、电子电器、航空制作、汽车制作等行业。 在整个离散制造业的现场有着太多的生产、物料、工艺以及人员数据。以前，离散制造业往往只能通过人工上报，手动填单等形式来进行数据收集。对于管理层而言，这些数据往往是不通明的、不精确的，或是滞后提早的。离散制作企业自身从业务到治理，都亟需通过数字化进行优化和晋升。 如何解决“离散型”制造业的数据挑战？工业数字化软件供应商数益工联，致力于打造基于“数据流 + 价值流”的离散制造业数字化软件。数益工联团队以 IE+IT 为外围能力，实现产品和技术的双轮驱动，已在十多个行业落成寰球当先的数字标杆工厂公司。公司至今已取得华创资本、高瓴创投、元生资本等出名机构的风险投资，累计融资额数亿元，在上海、苏州、广州三地设有子公司，打造跨区域全国服务平台。 数益工联数字工厂零碎（DFS，Digital Factory System）利用新一代的物联网技术与丰盛的现场交互伎俩，获取工厂现场最实时、最实在、最无效的数据，不仅蕴含设施状态、设施异样数据、设施生产数据等设施 IOT 数据，还蕴含人员的交互应用数据，如打算报工、工艺、仓储物流、质检等外围生产治理业务的数据等。对管理层而言，通过数益工联数字工厂零碎，能够直观看到清晰、间接的报表，从中发现数据的价值，继而深入分析并采取行动，优化制作现场。 数益工联数字化工厂架构面临的挑战 <center>数益工联数字化工厂架构图</center> 从架构上看，数益工联数字化工厂次要分为四层： 第一层为物联层，包含硬件和软件两局部。硬件次要为数益工联自研的智能终端，软件包含边缘利用和物联平台。其中利用次要具备设施参数的采集、人脸识别等性能，以上利用均运行于智能终端。物联平台则次要承当设施治理、配置和降级的相干工作。 第二层为应用层，包含 IOT 数据服务、外围服务、低代码平台。IOT 数据服务是承受物联上报数据，计算设施开机率，异样等设施相干的服务，同时也是其余业务的数据源头；外围服务包含了打算报工、品质等数字化工厂服务；低代码平台次要包含了报表的可视化平台、流程编排等性能。 第三层为大数据层，分成了大数据和算法两个局部。大数据利用包含了老本管制、APS、工艺大数据；算法包含了人脸识别、时序剖析等算法。 第四层为基础架构层，作为基础设施提供其余业务应用。次要包含了存储、数据库、中间件和云原生等局部。 数字工厂的数据源头次要包含两局部： 第一局部是 IOT 事件，包含了设施的开关机、物联采集、异样等数据，这部分数据通过 mqtt 上传到 IOT 服务进行解决，同时会推送到队列中，不便后续的计算和存储； 另一部分是业务产生的数据，包含了打算报工、上下班等产生业务数据，次要通过 http 进行上传和展现。业务数据会间接寄存到数据库中，同时将数据推送到队列中。 数据存储次要采纳了 TiDB 和 Starrocks 两个数据库，除了时序相干的数据，业务数据都寄存在了 TiDB 中。 随着数益工联业务规模的一直增长，数据量变得愈发宏大，对于数据库的稳定性也提出了更高的要求： 少数业务数据须要反对秒级延时，因而须要数据库具备很高的并发能力；随着业务的增长，数据量也会越来越大，须要数据库具备良好的拓展性；随着数据量的增大，报表制作老本和难度变大，无奈保障实时性。为解决业务零碎的性能瓶颈，进步数据库的性能问题，数益工联抉择了 TiDB 这一新型分布式数据库实现重构。 数益工联研发团队在实际过程发现，TiDB 许多劣势正好能够满足数益工联的需要： TiDB 兼容性强，在实际的过程中简直没有遇到过不兼容的问题，除了多数默认编码的问题。反对云原生部署，能够通过 Kubernetes Operator 来疾速部署 TiDB 集群，具备欠缺的配套监控性能。可能实现自动化程度扩容，反对高可用，运维无需手动接入，极大地升高了运维老本。反对 OLAP，TiDB 反对 TiFlash，升高部署复杂度，TiFlash 在亿级别数据的查问中，通常能达到 5 倍的减速。TiDB 如何助力数益工联开掘价值数据？那么，数益研发团队是如何应用 TiDB 实现对于工业数据的价值开掘的？以工厂运行效率的重要指标设施开机率为例，对于工厂而言，设施的开机率与生产效率非亲非故，是否实时获取开机率，机器是否实现了高效且正当的运行十分重要。数益工联团队通过 TiDB 实现了以下性能： ...

随着数字经济的疾速倒退，数据已成为重要生产因素，开掘数据价值成为了用户的广泛需要。HTAP（混合事务和剖析解决）是近年来提出的一种新型的数据库架构，旨在突破事务处理和剖析之间界线， 在一份数据上保障事务处理的同时反对实时剖析，并且能够灵便配置两种负载的资源占比，使得在线交易和剖析互不影响，并能够别离实现线性扩大，一站式地解决企业级利用的各种需要，从而大幅度降低老本，同时进步了企业决策的效率。以后，HTAP 已成为数据库倒退的前沿畛域。 2022 年 12 月 15 - 16 日，在中国信通院组织的第十五批数据库产品能力评测中，平凯星辰（北京）科技有限公司（以下简称平凯星辰）的分布式数据库 TiDB 成为国内首个实现并顺利通过 HTAP 数据库根底能力测评的产品。该测评根据《大数据 混合事务和剖析型数据库技术要求》进行，该规范共波及 6 个能力域 41 个能力项，包含 35 个必选项和 6 个可选项，全方位笼罩 HTAP 数据库的基本功能、可靠性、运维治理能力、扩展性、安全性和易用性。 本次参加测评的分布式数据库 TiDB 是平凯星辰研发的一款同时反对在线事务处理与在线剖析解决的交融型分布式数据库产品，具备程度扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协定和 MySQL 生态等重要个性。指标是为用户提供一站式 OLTP、OLAP、HTAP 解决方案。TiDB 适宜高可用、强统一要求较高、数据规模较大等各种利用场景。TiDB 数据库已成为寰球最沉闷的开源数据库我的项目之一，在“墨天轮中国数据库风行度排行榜”上长期排名第一。截至目前，TiDB 在寰球领有超过 3000 家企业用户，波及金融、运营商、制作、批发、互联网、政府等多个行业。 <center>TiDB 数据库 HTAP 架构图</center>

这一次 TiCDC 浏览系列文章将会从源码层面来解说 TiCDC 的基本原理，心愿可能帮忙读者深刻地理解 TiCDC 。本篇文章是这一系列文章的第一期，次要叙述了 TiCDC 的目标、架构和数据同步链路，旨在让读者可能初步理解 TiCDC，为浏览其余源码阅读文章起到一个引子的作用。 TiCDC 是什么？TiCDC 是 TiDB 生态中的一个数据同步工具，它可能将上游 TiDB集群中产生的增量数据实时的同步到上游目的地。除了能够将 TiDB 的数据同步至 MySQL 兼容的数据库之外，还提供了同步至 Kafka 和 s3 的能力，反对 canal 和 avro 等多种凋谢音讯协定供其余零碎订阅数据变更。 上图形容了 TiCDC 在整个 TiDB 生态系统中的地位，它处于一个上游 TiDB 集群和上游其它数据系统的两头，充当了一个数据传输管道的角色。 TiCDC 典型的利用场景为搭建多套 TiDB 集群间的主从复制，或者配合其余异构的零碎搭建数据集成服务。以下将从这两方面为大家介绍： 主从复制应用 TiCDC 来搭建主从复制的 TiDB 集群时，依据从集群的应用目标，可能会对主从集群的数据一致性有不同的要求。目前 TiCDC 提供了如下两种级别的数据一致性: 快照一致性：通过开启 Syncpoint 性能，可能在实时的同步过程中，保障上下游集群在某个 TSO 的具备快照一致性。具体内容能够参考文档：TiDB 主从集群的数据校验最终一致性：通过开启 Redo Log 性能，可能在上游集群产生故障的时候，保障上游集群的数据达到最终统一的状态。具体内容能够参考文档：应用 Redo Log 确保数据一致性数据集成 目前 TiCDC 提供将变更数据同步至 Kafka 和 S3 的能力，用户能够应用该性能将 TiDB 的数据集成进其余数据处理系统。在这种利用场景下，用户对数据采集的实时性和反对的音讯格局的多样性会由较高的要求。以后咱们提供了多种可供订阅的音讯格局(能够参考 配置 Kafka)，并在最近一段时间内对该场景的同步速度做了一系列优化，读者能够从之后的文章中理解相干内容。 ...

近日，企业级开源分布式数据库厂商 PingCAP 发表与美国驰名公立大学 Wisconsin-Madison 建设科研单干，PingCAP 将与威斯康辛-麦迪孙大学计算机、数据与信息科学学院院长 Remzi Aparci-Dusseau 传授就 Key-Value 存储系统中智能多级缓存治理，和运行中零碎主动衰弱调整开展单干钻研，摸索如何确保简单零碎长时间放弃最佳状态。 Key-Value 存储系统在不同的利用场景中对缓存的治理和应用有不同的形式，此次摸索的智能治理 + 主动调整将尝试为 Key-Value 存储系统带来更鲁棒的适应性和更好的性能。 PingCAP 联结创始人兼 CTO 黄东旭示意：TiDB 久经实战测验和行业认证，在技术畛域一直深耕的同时，PingCAP 也始终通过多种形式和寰球的开发者们独特探讨分布式存储技术。PingCAP 在根底钻研畛域高校单干布局已久，目前曾经同国内外 10 余所高校建设了单干，并已成立多个联结实验室，以期造就优良科技人才、做好长期的专业人才储备。 威斯康辛-麦迪逊大学是美国最驰名的公立大学之一、也是世界驰名研究性大学。其计算机科学系数据库系统组从 1976 年开始进行数据库相干的钻研，被认为是美国最好的数据库钻研团队之一。从事的研究课题包含：构建下一代数据库系统、数据集成、数据迷信、机器学习和数据库实践。 Remzi Aparci-Dusseau 传授是威斯康辛-麦迪孙大学计算机、数据与信息科学学院院长，美国 Grace Wahba 传授名称获得者。Remzi 传授所著的操作系统原理（OSTEP）一书在互联网上每年被下载上百万次，被寰球几百所高校应用。Remzi 传授是零碎、数据库方面的专家，在零碎钻研畛域他的论文有 15000 屡次的超高援用。 日前，PingCAP 联结创始人兼 CTO 黄东旭在威斯康辛麦迪逊作为客座讲师，向学生介绍了 TiDB 在云计算时代如何解决 OLTP/OLAP/HTAP 负载，并同学生进行了圆桌交换。12 月 16 日，PingCAP 将与威斯康辛麦迪逊大学联结举办在线 meetup，Remzi 传授将和 Yifan Dai 博士、PingCAP 研发工程师 Qi Xu 独特探讨共栖缓存技术如何优化分布式 KV 存储的性能。 <center>扫描下方二维码理解更多</center>

每隔一段时间，TiDB 会公布一些对于架构演进的大新闻。比方 2020 年的 TiFlash 和 HTAP，2021 年的 MPP，比方往年的 TiDB Cloud。在凑近年底时，咱们很快乐又有大新闻能够跟大家说： TiDB Serverless 内嵌下一代云原生架构上线了 。 面向经济实用场景始终以来 TiDB 都是面向大体量要害在线业务而设计的，这使得咱们的产品定位也偏差这类场景。 而实际上，作为一个通用型数据库，除了大体量要害业务之外，TiDB 也在有数用户的非关键或者中小规模场景施展着巨大作用。 例如历史数据查问，实时数据服务和洞察，温数据存储，SMB 场景等，这类场景无疑和要害在线业务的看点与需要都有相当大的不同：例如对老本更敏感，存储和计算资源比更大，更看重弹性以及按需伸缩等等。TiDB 繁多产品要兼顾这些不同的场景，会显得力有未逮且定位含糊。当初咱们新推出的 TiDB Serverless Tier 正是为了解决这个问题而设计的。 新云原生和 Serverless Tier云原生始终都是诸多数据库厂商发力指标，但非常少有人能解释分明何为云原生。作为数据库厂商之一， 咱们认为云原生意味着借助云上基础架构提供远强于公有部署的能力 。例如云原生架构的先驱之一 Snowflake， 借助云对象存储和虚拟机资源池，提供十分低成本的存储以及十分弹性的计算能力，这是任何公有部署的数据仓库平台齐全无奈企及的「超能力」 。将存储委托到云端对象存储使得数据库领有超高的可用性和持久性，但与此同时也须要认真解决随之而来的高提早。因而，重度依赖 S3 作为存储之前都是剖析型数据库的专属设计。但 TiDB 迈出了全新一步。 TiDB 在新的云原生架构下，原创性地借助由本地缓存辅以便宜牢靠的对象存储作为主存实现了更低成本，更具弹性，甚至更高性能的存储架构。 TiDB 在原有架构中，数据是别离存储在各个 TiKV 的 RocksDB 中，每次写入会通过 Raft Log 向各个正本同步。在新架构中，数据在保留原有的 Raft Log 传输机制确保疾速写入的根底上，将经由 S3 来同步不同正本的长久化数据，这种设计在不引入更高提早的前提下，取得了诸多云原生特有的劣势。 另外，计算资源则由池化的虚拟机提供资源，这使得计算节点（TiDB 和 TiFlash）随时能够依照负载弹性变动。 更少的耗费 在新的架构中，TiKV 的写入不须要在多个正本之间反复利用，而只需扭转主正本并经由对象存储向其余正本扩散，这使得写入的 CPU 耗费由三倍大幅减小到略高于一倍，整体存储层能够达到 30% 乃至 50% 的 CPU 效率晋升（或者了解为老本降落）。 ...

当初报名流动，有机会取得限定好礼哦！2022 年 5 月，TiDB 进入了 V6 时代。从 TiDB 第一个 Beta 版本开始，OLTP Scale、Real-time HTAP、TiDB Cloud，咱们一步步把理念变成事实。 当初，数据库技术已进入 Serveless 的新时代，TiDB 曾经走到了哪里，咱们又将如何打造一款真正的 ServerlessDB？12 月 1 日 PingCAP DevCon 2022 产品技术论坛，聚焦数据技术前沿趋势与利用，PingCAP 产研“最佳阵容”将重点围绕 Serverless、TiDB 新个性、性能调优、稳定性设计、技术生态、利用场景等畛域开展分享和探讨， 帮忙您疾速理解 TiDB 的硬核技术与最新倒退方向，助您晋升业务场景的服务与创新能力。 扫描下方二维码，立刻报名流动！流动亮点TiDB Roadmap 瞻望云时代的开发者面临更多的时机和挑战，TiDB 也在一直迭代，向更多开发者提供当先的数据服务。这个论坛中，PingCAP 研发副总裁唐刘将与大家分享 TiDB Roadmap，瞻望 TiDB 在 Serverless、DB 微服务化、云原生等方面的产品布局。TiDB 最新内核个性解读分布式数据库为企业级用户带来了高并发、高吞吐、近乎有限扩大的数据库解决方案，企业在享受技术红利的同时也要面对大数据规模下的集群稳定性、资源争抢、DDL 慢、调度稳定性等问题。TiDB 作为业界当先的分布式关系型数据库，在这些畛域的摸索上始终走在业界前沿。TiDB 内核产品经理团队负责人姜皓楠将为大家展现近半年 TiDB 在扩展性、资源管理、DDL 优化等诸多新增个性及其背地的技术创新。TiDB 产品能力深刻解析为了打造一款让用户省心的数据库，TiDB 产品设计有哪些巧思：计算层如何进行查问优化；存储层如何实现提早稳固、性能可预期；高可用和容灾的计划应该怎么选；分布式数据库的可观测性又有哪些新进展；TiDB Cloud 围绕用户体验如何一直地演进？本论坛中，TiDB Compute 团队负责人董宇、TiDB Storage 团队负责人张金鹏、PingCAP 数据平台产品经理团队负责人高斌、PingCAP 可观测性产品经理李粒、TiDB Cloud 产品经理周鹏等产研技术专家将为大家揭晓！TiDB Serverless 和技术生态全景PingCAP 致力于为开发者提供更简化的数据服务，在往年 11 月推出了寰球首款 Serverless HTAP 数据库 - TiDB Cloud Serverless Tier。论坛将首次向听众全方位展示 TiDB Serverless 的外围能力、云上架构的设计以及将来的倒退。 成为一款好用的数据库，除了产品本身的能力外，凋敝的技术生态体系也至关重要，既能够晋升应用体验，又能够升高应用门槛。 TiDB Cloud 生态服务团队负责人张翔将全面解析 TiDB 的技术生态全景，以及在生态构建中所做的致力。议程安顿……议程陆续更新中，更多精彩，敬请期待！扫描下方二维码，立刻报名流动报名有礼报名流动关注「TiDB Club」音讯推送参加流动，分享生成的海报，邀请 3 人报名胜利，即可取得 PingCAP 定制款飞盘一个， 数量无限，先到先得 ！ ...

1. 集群部署相干命令参考《TiDB 软件和硬件环境倡议配置》，以下操作Ubuntu LTS零碎上。 a.筹备ubuntu环境1: 磁盘分区,swap敞开参考：官网 磁盘格式化 # 实例：4t Nvme固态parted /dev/nvme0n1(parted) print(parted) mklabel gpt (parted) mkpart primary 0KB 4TB (parted) printmkfs.ext4 -F /dev/nvme0n1# 查看文件系统类型blkidvi /etc/fstabUUID="040c7a9c-1dd3-494c-b7b9-298ec2165b83" /DATA4T ext4 defaults,nodelalloc,noatime 0 2echo "vm.swappiness = 0">> /etc/sysctl.confswapoff -a && swapon -a# rebootb.零碎设置2: 工具装置、其余设置，免登陆ufw disableapt-get install ntp curl net-tools ifupdown network-scripts openssh-server mysql-client-core-8.0# 查看网卡名称ifconfig # 设置动态IPgedit /etc/network/interfaces# interfaces(5) file used by ifup(8) and ifdown(8)auto loiface lo inet loopback auto enp4s0iface enp4s0 inet staticaddress 192.168.1.11gateway 192.168.1.1netmask 255.255.255.0# SSH设置vi /etc/ssh/sshd_config++MaxSessions 20service sshd restart# 增加用户,免登陆adduser tidbpasswd tidbvi /etc/sudoers++tidb ALL=(ALL) NOPASSWD:ALLc.部署配置:参考：官网 应用 TiUP 部署（举荐） ...

2022 年 11 月 1 日，企业级开源分布式数据库厂商 PingCAP 在 HTAP Summit 上发表 TiDB Cloud Serverless Tier BETA 版正式公布 ，这是一种齐全托管的全自动 HTAP 数据库服务，使开发者可能以最经济的形式部署其基础设施。[图片]TiDB Cloud Serverless Tier 专为规模化交易、实时剖析和混合工作负载以及流量激增的应用程序而构建，能够主动扩缩容以满足实时需要 。开发人员只需点击几下，就能够部署和配置一个具备残缺性能的 Serverless TiDB 数据库。TiDB Cloud Serverless 与 MySQL 高度兼容，开发人员能够持续应用他们相熟的 MySQL 开发框架和工具。TiDB Cloud Serverless Tier 将取代原有的 Developer Tier。“ TiDB Cloud Serverless Tier 是一个永远在线的 HTAP 数据库服务，为利用开发人员提供足够的敏捷性和灵活性，在 TiDB Cloud 上构建和测试利用。 ”PingCAP 创始人兼 CEO 刘奇示意，“另外，对于须要更大规模资源的企业级用户，他们还能够通过 Dedicated Tier 从间歇性、不频繁和不可预测的工作负载始终无缝扩大到要害工作工作负载。”该服务无需预付费用，企业能够依照理论提交的 SQL 申请和理论应用的存储来付费，这种基于生产的定价模式为开发者发明了一个 “随时启动，随用随付“的生产模式 。 为什么抉择 TiDB Cloud？TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时反对在线事务处理与在线剖析解决 (Hybrid Transactional and Analytical Processing, HTAP) 的交融型分布式数据库产品， 具备程度扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协定和 MySQL 生态等重要个性 。TiDB Cloud 简化了部署和扩大。借助云原生分布式架构，无需手动分片。内置的 TiDB 正本机制防止了对简单故障迁徙计划的依赖。通过应用 TiDB，业务中断和手动复原成为过来，企业解放本人，能够更加专一于为用户开发更好的应用程序。TiDB Cloud 帮忙开发人员、经营和 DBA 团队，无需成为数据库专家，就能轻松解决已经被认为简单的工作，如基础设施治理和集群部署。通过扩大 TiDB Cloud 的计算或存储节点，能够优化数据库效率，而不用节约低廉的资源。 ...

TiDB Hackathon 2022 决赛刚好在 1024 程序员节前夜完满收官，48 小时的 Happy Hacking，参赛我的项目乏味、有料，精彩一直！退出全屏切换到横屏模式 点击观看视频http://mpvideo.qpic.cn/0bc3ve...本届大赛主题为「Possibility at Scale」， 规模创历史之最，共有 303 名选手报名 ，86 支队伍参赛 ，有来自 微软、蚂蚁团体、字节跳动、网易有道、浪潮、明朝万达、B 站、思科、太极图形等企业的选手 ，也有来自清华大学、北京邮电大学、华东师范大学、浙江理工大学、新加坡国立大学等高校的学生。选手们围绕着 TiDB 产品组和利用组两大赛道，开展了一场技术的比拼和创意的碰撞。Hackathon，即“黑客马拉松”，是程序员十分脍炙人口的赛事流动。它有着自在的模式：Hacker 们汇集在一起，严密单干，施展创意，继续编程，实现创想。编程马拉松的精华在于： 一群气味相投的搭档，在特定的工夫内，相聚在一起，去做他们想做的事件 ——整个编程的过程简直没有任何限度。作为一个曾经举办了 5 年的赛事，PingCAP 联结创始人兼 CTO 黄东旭总是焦虑上届曾经办得十分胜利，这届达不到上届水准怎么办？但当看到选手们的精彩展现后，咱们发现随着开发者们对 TiDB 的了解和应用越来越熟练，Hackathon 的品质也在一直进化。最终，在两天一夜的 Hacking Time 中， 有 16 支队伍瓜分了总计 35 万元的奖金，其中有 10 支队伍分获最佳创意奖、公益贡献奖、技术趋势奖、Cloud 利用生态奖、最佳人气奖、最佳校园奖、用户之选奖 。硕果累累，我的项目创意有限评委老师们认为本届参赛队的很多我的项目“很有野心”，并曾经具备落地的成熟度。例如「图一乐」 队通过 “Data Dance” 提供了一个容许你摸索、剖析、了解数据的在线服务；「12 只喵」队伍让所有人都能通过 TiUP 集体镜像向 TiDB 奉献组件，打造组件市场的雏形；「我垫你们蹲」队通过引入新的索引来实现 TiDB 的协同优化能力的“TiFlash Collocated Optimization”；「cdc-plg」队为 TiCDC 用户提供可扩大插件的“cdc sink plugin”我的项目；「Canopus」队的“TiDB 计算微服务”我的项目等等……还有太多我的项目就不一一列举了，大家能够通过以下链接理解全副我的项目。决赛问难我的项目： https://asktug.com/t/topic/99...（复制链接至浏览器即可查看）由北京、上海、广州、成都、新加坡多城分布式联动的决赛问难 & Demo Show 从下午 13:00 始终继续到深夜 20:30。尽管决赛时长将近 8 个小时，然而大家越看越兴奋。平时宛转内敛的技术大佬们一旦介绍起本人的产品，就变身为滔滔不绝的演说家。放几张现场图，大家轻易感触下： ...

testcontainers-java 已于近期新增了对 TiDB 容器的反对。当前，在 Java 的应用程序中，你能够间接应用 Java 代码管制并创立 Docker 容器来应用 TiDB，并治理它的生命周期，而无需编写内部脚本，这将极大地简化开发流程。本文介绍了如何通过 testcontainers-java 创立和治理 TiDB 实例。 testcontainers-java 是一个 Java 的 JUnit 测试库，为数据库（包含 MySQL、Postgres、DB2、Clickhouse、CockroachDB 等）、Selenium 浏览器以及其它能在 Docker 容器中运行的我的项目提供了轻量的，随用随弃的实例。 testcontainers-java 已于近期新增了对 TiDB 容器的反对。 在其官网文档中，也呈现了 TiDB 的模块阐明： 当前，在 Java 的应用程序中，你能够间接应用 Java 代码管制并创立 Docker 容器来应用 TiDB，并治理它的生命周期，而无需编写内部脚本，这将极大地简化开发流程。 示例代码能够这样创立一个 TiDBContainer 用于治理容器： @ContainerTiDBContainer tidb = new TiDBContainer("pingcap/tidb");随后，能够应用此代码启动该容器，这将在任何领有 Docker 的机器上运行胜利 tidb.start();随后，便可间接创立 Statement 并运行 SQL： MysqlDataSource ds = new MysqlDataSource();ds.setURL(tidb.getJdbcUrl());ds.setUser(tidb.getUsername());ds.setPassword(tidb.getPassword());ds.setUseSSL(false);Statement statement = ds.getConnection().createStatement();statement.execute(sql);示例仓库咱们编写了一个示例代码的仓库 tidb-test-container-example。你能够应用这个仓库中的 AppTest.java 源码进行大量的更改后便可间接应用在你本人的我的项目中。 如果你心愿进行这个仓库的测试，只须要应用 mvn clean test 便可运行。此我的项目依赖 JDK 11、Maven 3。运行的后果如下： ...

京东云TiDB SQL层的背景介绍从总体上概括 TiDB 和 MySQL 兼容策略，如下表： SQL层的架构用户的 SQL 申请会间接或者通过 Load Balancer 发送到 京东云TiDB Server，TiDB Server 会解析 MySQL Protocol Packet，获取申请内容，对 SQL 进行语法解析和语义剖析，制订和优化查问打算，执行查问打算并获取和解决数据。数据全副存储在 TiKV 集群中，所以在这个过程中 TiDB Server 须要和 TiKV 交互，获取数据。最初 TiDB Server 须要将查问后果返回给用户。 一条SQL的生命周期图 ●SQL优化流程的概览在 TiDB 中，从输出的查问文本到最终的执行打算执行后果的过程能够见下图： 在通过了 parser 对原始查问文本的解析以及一些简略的合法性验证后，TiDB 首先会对查问做一些逻辑上的等价变动，通过这些等价变动，使得这个查问在逻辑执行打算上能够变得更易于解决。在等价变动完结之后，TiDB 会失去一个与原始查问等价的查问打算构造，之后依据数据分布、以及一个算子具体的执行开销，来取得一个最终的执行打算，同时，TiDB 在执行 PREPARE 语句时，能够抉择开启缓存来升高 TiDB 生成执行打算的开销。 ●应用 EXPLAIN 语句查看执行打算执行打算由一系列的算子形成。和其余数据库一样，在 TiDB 中可通过 EXPLAIN 语句返回的后果查看某条 SQL 的执行打算。 目前 TiDB 的 EXPLAIN 会输入 5 列，别离是：id，estRows，task，access object， operator info。执行打算中每个算子都由这 5 列属性来形容，EXPLAIN后果中每一行形容一个算子。每个属性的具体含意如下： ...

单刷 3 届 Hackathon，朝着现实中的数据库登程丨TiDB Hackathon 选手访谈TiDB Hackathon 2022 正在炽热报名中，截止目前曾经收到 230+ 位参赛者报名，组队近 60 组。想必各位选手曾经跃跃欲试，开始筹备本人我的项目的 RFC 了。在期待较量日的这段时间，TiDB 社区采访了多位 Hackathon 参赛选手，通过访谈为大家分享一下他们对 Hackathon 的了解和感悟，同时探讨开源给他们的集体生存和工作带来了哪些扭转。当然，作为老选手，也会有极其宝贵的参赛教训分享。曾经报名加入本届 Hackathon 的选手或是对 Hackathon 感兴趣的小伙们，连忙看过去！明天与大家见面的参赛选手是目前在南京邮电大学读研三的陆涣冰同学，其实他的业余方向原本是卫星通信，但心田却非常酷爱计算机底层技术，业余时间根本 all in 在开源分布式数据库上。涣冰同学与 TiDB Hackathon 的缘分源自研一那年：过后看到较量的信息后就十分想加入，但苦于本人技术水平不够，同时也没找到人组队，差点错过。幸好过后社区的经营同学给了很多激励，并阐明集体参赛也是规定容许的，这才被引入了 Hackathon 这条路。之后涣冰就一发不可收拾，研一、研二、研三接连三届都加入了 TiDB Hackathon。以下为采访记录：Q1：为什么抉择单刷的形式加入 TiDB Hackathon？ 陆涣冰：其实单刷次要是因为本人想做的一些货色，对于很多人而言比拟形象，比拟艰难。举例来说，我去年做的题目就是用 eBPF 去减速 TiDB 的底层存储门路。这个我的项目可能须要比拟多的底层常识的铺垫，过后问了一圈发现没人对此感兴趣，最终还是本人一个人参赛。其实拿不拿奖无所谓，玩得开心就好。 加入 TiDB Hackathon 帮我整个研究生的三年开了一个头，之后我又加入了各种开源的较量，比方阿里的天池数据库大赛、 open Euler 高校开发者大赛等等。我能开启这条路要感激两个人。第一个人就是过后的社区经营 yanqing，她对我有某种程度上的知遇之恩，如果没有她我前面的这些经验应该都不存在。第二个人是过后在 P 社实习时的 mentor 施闻轩，他对于我在技术上了解的影响是比拟深远。 Q2：最早是在什么时候对编程感兴趣的？陆涣冰：我本科的业余是网络工程，研究生的业余是信息网络，乍一听起来如同都是计算机学科的分支。那时候其实走了一段弯路，过后整个人掉进了平安的圈里，感觉黑客好酷，什么病毒、逆向都感觉十分酷。然而在深刻学习了平安一段时间，就感觉做平安好玩归好玩，然而真的要把这个当做职业，心里感觉还是缺了一点什么。在 2019 年 2 月 1 日，那天是我的生日，所以我印象特地清晰，在跟敌人聊天时，我问本人当前确定要做平安了吗？还是想更深刻地写代码？因为过后身边很多做平安的敌人只是敲敲命令行跑跑脚本，感觉中国的平安的确青黄不接，厉害的的确十分厉害，但菜的切实是太菜了。那时候我这方面的技能，不谦虚地讲能够说是炉火纯青了，然而写代码的功底还是一塌糊涂。 和来自美团、百度的一些圈内敌人聊了聊，他们倡议能够考虑一下前端业务利用开发或编译器、数据库、操作系统等更底层的开发。过后也是年少无知，就说要不学个数据库吧。于是从那天就始终学到了明天，而后就发现一入数据库深似海，这外面的货色切实是太宏大了。不仅要有零碎常识，还要波及编译器的常识，分布式的常识。随同着这个学习过程，本人编码的程度也逐步上来了。 说实话，身边除了本人，再也找不到第二个人做软件开发或者数据库开发。平时在学校的教研室里根本清一色都是前端开发，这三年来，就我一个人坐电脑前自学了三年。在接触到 PingCAP 时，有一种忽然找到组织的感觉。Q3：开源带来的乐趣或收益是什么？陆涣冰：学习数据库的时候其实曾经对开源有了肯定的认知，基本上 99% 的常识全副来自于开源，无论对操作系统还是对计算机体系的了解，根本都是构建于开源软件之上的。 第一次接触 Linux，我发现这不就是我想要的操作系统？大家都能改，都能用，改完还能 push 进我的项目里，凋谢给他人用。某种程度上开源能够汇聚全人类的智慧去做一些事件。当然开源合作也会有很多问题，比方奉献的代码好不好，有没有破绽，能不能和他人达成统一协商等等。有些我的项目写一半甚至不写了，开发者跑了，撂挑子了，这都很常见。包含开源我的项目的商业化，哪些拿过去能够做出本人的货色，哪些能够二次开发拿去卖，哪些行为是违规的，都须要开源参与者去思考。但那时我还只是开源的使用者，到了读研之后，借由数据库才缓缓把手伸得更远一点，开始把本人的代码奉献给他人。Q4：TiDB Hackathon 与其余较量在体验上有什么区别？陆涣冰：那切实是太多了。第一还是人，PingCAP 这边的小助手切实是太激情了，工作做得十分好。我加入了三年，基本上会和每一届的小助手成为敌人。第二点是 Hackathon 的所有我的项目都构建在 TiDB 之上，TiDB 有十分多的文档，有对于内核、原理的解读，我认为这点在泛滥参加过的较量、我的项目中能够说是最优良的。这些工作大大减少了开发者想深刻理解 TiDB 所须要的工夫。举个例子，我在加入某个较量的时候，他们就水灵灵地放出赛题以及代码框架，剩下就全副交给你本人了，十分不容易上手，老手十分难做。而 TiDB 的源码与文档能够帮忙开发者在较量中缩小十分多的工夫。 ...

在刚刚完结的「 PingCAP 用户峰会」中，PingCAP 研发副总裁唐刘、PingCAP 中国区技术服务总经理李超群从 PingCAP 的 自主开源、工程研发体系、产品将来技术演进方向 等方面，分享了 PingCAP 如何 通过产品研发和服务体系将产品价值“又快又稳”地交付给客户，取得客户的信赖，并帮忙客户实现胜利 。以下为分享实录。服务对于数据库公司来说是一个沉甸甸的词汇。对于产研团队来说，只有做出产品，并把产品交付客户，才会有前面的服务。但 PingCAP 作为一家十分年老的公司，所做的是一个十分有挑战性的数据库产品，如何让客户抉择置信 PingCAP？如何让客户释怀地将他们的数据寄存到 TiDB 数据库？“通明”建设信赖开源是 PingCAP 的基因，PingCAP 从一开始就将源代码凋谢进去，让所有人都能看到 TiDB 到底是什么样子。但仅仅只有代码的开源是远远不够的，通过 7 年多的倒退， 咱们深知开源有着不同的阶段 。当把源代码凋谢后，客户和用户就可能自行下载 TiDB 源代码进行编译，公布到本人的生产环境中，服务于本人的客户；当他们遇到问题时，能够抉择本人修复 bug，或与 PingCAP 一起摸索，独特欠缺 TiDB 性能；有一些用户、企业甚至将 TiDB 作为本人的上游版本，通过 TiDB 构建本人的发行版，服务于客户。咱们也心愿能有越来越多的用户构建本人的 TiDB 发行版发明更多价值。面对不确定的经济环境，咱们如何从以后的简单环境中生存下来？ 开源是建设信赖的最佳路径，但只有开源也是远远不够的，PingCAP 认为唯有通明能力解决问题，通明所有能通明的事件。 为什么通明对 PingCAP 和用户都如此重要？一方面，PingCAP 到目前为止有 3000 家用户、 1800 多位开发者散布在寰球 45 个国家和地区，同时 PingCAP 外部有 300 多位研发工程师。PingCAP 和开发者、用户之间造成了一个十分多元的网状结构。所以咱们开源了源代码、设计文档。为了更加通明，咱们还将 TiDB 将来 1-3 个月的产品路线图凋谢，让大家理解 TiDB 行将公布的性能。有一些敌人可能会问：你们把所有货色都开源，都通明了，友商看到会有什么动作？其实比起放心这个问题， 咱们更心愿让客户分明地理解 PingCAP 到底在做什么以及 TiDB 将来的方向，并因而更加置信 PingCAP，独特走向将来 。让客户“又快又稳”感知到产品的价值作为一家做数据库产品的公司，仅仅只有开源与通明也是不够的，如果 TiDB 不能给客户带来价值，如果客户不能应用 TiDB，其实就建设不了任何信赖，咱们须要让客户又快又稳地感触到 TiDB 的价值。PingCAP 是一家十分年老的公司，一方面产品须要疾速地迭代，一直将产品价值疾速交付客户；另一方面，面对许多外围场景，咱们须要打磨一个更加稳固的产品，让客户十分高效十分释怀地应用。所以， PingCAP 采纳了一个“稳态+敏态”双轨并行的研发机制，保障产品更新对用户触手可及，同时在外围场景也能稳固释怀的应用 。那么，PingCAP 是如何实现“稳态+敏态”双轨并行的研发机制呢？一是开放式架构，拆散所有能拆散的，从物理上保障隔离性；二是 TiDB 有着十分丰盛的利用场景，用户在 TiDB 社区继续参加产品共创。上面通过几个小例子讲讲 PingCAP 如何与客户进行共创：第一个例子是中通快递。快递物流行业在双十一或者 618 时面临的挑战是十分微小的，中通快递实时数据业务须要将全国 3 万多网点产生的实时物流信息写入到数据库中，而后动态分析业务情况。双十一等物流顶峰期间，日写入 / 更新流量超 30 亿条，剖析库总量在百亿级。中通快递很早就拥抱了 HTAP ，通过理论业务场景的打磨， TiDB 帮忙中通快递抗住了双十一的流量顶峰，HTAP 剖析引擎配合分区表动静裁剪的高效数据过滤，反对了中通快递双十一 20 多个报表零碎秒级查问 。通过业务场景的深刻利用，中通快递将 HTAP 读写混合的极限负载能力晋升了 100% 以上。第二个例子是 OSS Insight。这是一个十分有代表性的业务场景，首先它是一个从 0 到 1 疾速打造的产品，适宜以后很多公司的敏态业务。这个产品的次要产品经理就是咱们的 CEO 刘奇， 需要天天变，明天提的需要今天就要交付，对于研发工程师来说是十分大的压力和挑战 。但 OSS Insight 有将近 50 亿条数据，很多查问条件非常复杂，面对这样高度简单的状况，一方面要实现疾速迭代，另一方面还要保障查问稳固高效运行。之前咱们通过加很多 HINT 的形式来保障查问打算的稳固，但当业务一直变动时会减少很多索引，调整 DDL ，导致之前的 HINT 生效，为了解决这样的问题咱们和 OSS Insight 研发工程师一起，不停打磨重构 TiDB 的优化器，当初不光研发工程师不再须要写 HINT ，咱们发现 TiDB 的智能优化程度比人工写 HINT 提速了 20-30%。第三个例子是某头部股份制银行。该行始终深信 TiDB 能利用到银行外围零碎上，与 PingCAP 协力继续打磨 TiDB 的内核能力，在 7×24 小时性能测试过程中，将整个提早抖动管制在 2% 以内。在互联网交易系统上，更将整个提早缩短了 4 倍，满足了互联网业务线上交易的外围述求。平滑降级，让客户又快又稳地感知到产品价值因为 TiDB 一直打磨，疾速公布新版本，许多用户会面临一个十分大的抉择问题：新产品是十分好，但我的数据库跑得好好的，为什么要降级？数据库在企业数字化零碎中是十分外围的组件，版本升级往往面临着着很大的危险，能不能不降级？咱们的答案是，要降级：一方面 客户通过降级到最新版本，在提早和性能方面都失去了大幅晋升，同时也更有信念将注意力聚焦于本人的业务逻辑开发上 ，另一方面，PingCAP 研发工程师与服务团队一起打造了一套 欠缺的数据库降级体系 ，反对客户的平滑降级。在技术、产品之外，PingCAP 还在产研外部专门成立了保障企业级客户胜利的组织，比方金融架构师团队。它由 PingCAP 的资深架构师组成，致力于重要金融客户的共创、性能研发和我的项目反对。将来，与客户继续户共创，携手成长很多企业级客户抉择 TiDB 的理由，就在于它的可成长性。 将来， TiDB 依然会在这方面一直地致力。首先，咱们会聚焦于 TiDB 的内核，一直打磨。咱们置信，无论怎么成长，如果没有坚硬的底座是不可能向外更好成长的。在这个根底之上，TiDB 会在 DB 微服务化、云原生、智能化上一直拓展产品的边界和能力，与各种各样的生态联合，为客户提供更多价值。这些年来，TiDB 始终继续一直地专一于 OLTP 外围能力晋升，以银行交易外围为抓手，在优化零碎、细粒度资源管制以及长尾提早等各方面实现了冲破，让 TiDB 变得更快更好用，在大表疾速增加索引方面性能晋升 10 倍， 在 Real-time HTAP 提速 1-2 倍。以后，无论国内还是在海内，云都是技术演变的将来 。而恰好云可能将整个 PB 级别的数据库服务平台价值有限放大，将来 PingCAP 会提供一种全新的数据处理和拜访模式—— Serverless。PingCAP 提供十分不便易用的 Data API，让企业级用户只需关注本人的业务，不必在意数据在哪里，底层长什么样。咱们有一个幻想，当 TiDB 具备 Serverless 能力的时候，每个开发者都能够领有本人的数据服务。 这个数据服务能做到秒级别的创立速度，亚秒级别的唤醒启动，毫秒级别的拜访提早。当一个数据库具备这样能力时，对于用户的价值其实是十分大的。一方面，所有开发者都领有数据库，对于 TiDB 人才培养再也不须要放心；另一方面，用户只须要关注于本人的业务逻辑开发，以及如何更快将业务推向市场。上图是 TiDB 整个产品的技术演进方向，蕴含 TiDB 内核、DB 微服务化、云原生、智能化以及生态。在智能化方面，TiDB 在一直打磨主动诊断服务 Clinic ，通过主动诊断服务能够让每个用户都领有一个 TiDB 性能调优专家，让每个用户都能够更好地应用 TiDB 。PingCAP 服务体系客户胜利这件事，不仅仅是产品研发团队的事件，也是整个 PingCAP 公司一起致力的后果。PingCAP 中国区技术服务总经理李超群在用户峰会上分享了 PingCAP 服务体系。目前为止， PingCAP 技术服务人员的总人数曾经占到了公司总人数的 25% ，成为继产研之后的第二大团队。能够说， PingCAP 既是一家产品型公司，也是一家服务型公司。PingCAP 服务体系蕴含三个方面—— 订阅服务、专家服务和培训认证 ：订阅服务： 过来一年，PingCAP 实现了用工单零碎做客户技术服务，能够非常容易地跟踪工单停顿；咱们开明了产研直通渠道，客户如有紧急问题能够第一工夫拉通产研；第三，基于宏大的社区，咱们把社区以及工单里的所有问题都整理出来，建设了 TiDB 知识库，在往年 12 月份会向所有企业客户凋谢。专家服务： PingCAP 依照利用构建的全生命周期构建了一张服务体系大图。TiDB 所面对的场景和遇到的挑战与其余数据库有所不同，有数据库替换场景，有大数据替换场景，如何帮忙客户在这些场景里用好 TiDB ，是 PingCAP 首要解决的问题。所以 PingCAP 推出了架构咨询服务，咱们心愿帮忙客户做真正的场景调研，做可行性剖析与架构设计。专家服务除了要有体系，还依赖于真正的教训积攒。咱们通过一套服务标准化的流程，把所有的实际，所有的教训汇聚起来变成一套能够复用的资产和工具体系。培训认证： TiDB 的培训认证体系进行了全新降级。咱们把高级课程的门槛升高，让更多人能够接触到 TiDB ，同时把高级课程变得多路并行，除了以前的数据库治理方向，还增加了性能调优、数据迁徙、故障排查和经营治理方向。此外，往年 PingCAP 还推出了 专门针对利用开发者的培训认证 ，帮忙利用开发者用好其实能让 TiDB 跑得更快也更稳固，这门课程曾经正式向所有商业客户和合作伙伴凋谢。最初，回到本文的主题， PingCAP 为什么可能服务好企业级用户 ？答案并不简单：PingCAP 以开源为根底，与客户建设了牢固的信赖体系；与此同时，PingCAP 继续引领技术趋势，打造面向未来的数据库产品；最要害的一点，PingCAP 从开始到当初，始终保持以 客户胜利为外围的企业文化， 从产品研发到技术服务， 与用户独特面 对不 确定性 的挑战。 扫描下方二维码或点击文末 「浏览原文」 ，立刻预约大会材料！ ...

TiDB Hackathon 2022 炽热报名中！你报名了吗（还没报名看这里）？你有 idea 了吗（没有 idea 看这里）？ 有了 idea，然而不够理解 TiDB，不晓得如何入手实际？本文将通过 step-by-step 的形式，介绍如何疾速给 TiDB 新增一个性能，让没有太多常识背景的人也能疾速上手。 ps：加入 TiDB 产品组的小伙伴，想给 TiDB 组件减少新性能的，快来围观！ 假如咱们想要将 SST 文件导入 TiDB 中，通过新增 LOAD SST FILE <file_path> 语法来实现。 TiDB 数据库在收到一条 SQL 申请后，大略的执行流程是 生成 AST 语法树 -> 生成执行打算 -> 结构 Executor 并执行。咱们先来实现语法。 语法实现要如何实现语法呢？咱们能够照葫芦画瓢，找一个相似的 LOAD DATA 语法作为葫芦，而后开始画瓢。 Step-1: 新增 AST 语法树LOAD DATA 语法是用 ast.LoadDataStmt 示意的，咱们照葫芦画瓢在 tidb/parser/ast/dml.go 中新增一个 LoadSSTFileStmt AST 语法树： // LoadSSTFileStmt is a statement to load sst file.type LoadSSTFileStmt struct { dmlNode Path string}// Restore implements Node interface.func (n *LoadSSTFileStmt) Restore(ctx *format.RestoreCtx) error { ctx.WriteKeyWord("LOAD SST FILE ") ctx.WriteString(n.Path) return nil}// Accept implements Node Accept interface.func (n *LoadSSTFileStmt) Accept(v Visitor) (Node, bool) { newNode, _ := v.Enter(n) return v.Leave(newNode)}Restore 办法用来依据 AST 语法树还原出对应的 SQL 语句。 Accept 办法是不便其余工具遍历这个 AST 语法树，例如 TiDB 在预处理是会通过 AST 语法树的 Accept 办法来遍历 AST 语法树中的所有节点。 ...

本文回顾了 PingCAP 创始人兼 CEO 刘奇在 9 月 22 日的 用户峰 会 上以《当初决定将来》为主题的演讲， 分享了 PingCAP 在技术演进、用户价值、数据库技术趋势、国际化、社会价值等方面的思考， 同时也记录了建信金科、百胜中国、传音控股、老虎国内等用户在刘奇的演讲中分享的最佳实际。全文字数约 8,800，预计浏览工夫 20 分钟。PingCAP 到明天曾经成立 7 年了，在寰球领有 3,000 多家大中型用户，其中很多还参加到 TiDB 开源社区的建设中，这些状况如果放到守业之初很难设想。明天，咱们意识到做一个真正广泛应用的数据库，是一个须要以十年为工夫单位进行投入的根底工程。 这一路走来离不开关怀和反对 PingCAP、喜爱 TiDB 的每个人。与客户对话，客户眼中的 TiDB过来一段时间，在和包含日本、美国、印度、欧洲等寰球客户交换时，咱们试图从更多不同客户的视角去理解他们到底是怎么对待 TiDB 的。在 TiDB 的设计里，有很多设计是从第一天就开始的，咱们甚至齐全不感觉这个设计有什么特别之处。直到我问一些专家型用户“你到底为什么抉择 TiDB ？”时，他们通知我： 因为 TiDB 的开放式架构能够治理复杂性。 我过后挺惊讶，因为这个货色第一天就是这样设计的，曾经融入 PingCAP 的血液当中，所以咱们本身曾经无感。但对这些专家来说，他们当中很多人在各个大公司自身就做过数据库，甚至是大型分布式系统，做过这些零碎的人都会产生一个心态，那就是对“复杂性”会无比敬畏。一个数据库，哪怕它是一个小型数据库，通常代码规模都会有几十万行，上百万行，如果是一个传统的成熟型商业数据库，那更是一个以千万行代码为单位的零碎。 面对如此 简单的零碎，用户在思考将来的迭代时，通常要做 3-5 年的布局。 如果用户须要花 3-5 年来替换一个 PB 级数据库，很大水平上意味着接下来 5-10 年的工夫他就不想再动了，这也是本次峰会的主题为什么是“当初决定将来”。明天咱们做一个数据库替换的决定，它的影响周期很可能是接下来的 10-20 年。 在这个较长的周期中，大家看零碎价值的时候就会看到齐全不一样的价值。比方最近我意外地发现 TiDB 在 CFO 眼里其实很受欢迎，他们示意，在现有实际中，TiDB 至多能够升高一半的老本，所以 CFO 很快就会批下来对 TiDB 的部署和利用。大家能够试想一下，如果用户有 PB 级的数据，用 TiDB 替换可能省一半的老本，是不是十分有吸引力？明天的世界充斥了不确定性，在此前提下如何能更好地生存上来？省钱天然会变成一个全世界都关注的话题。但所有这些价值的前提是接下来 5-10 年，甚至 10-20 年这个零碎不能死，能继续撑持业务。这时候问题就来了， 凭什么一个零碎在接下来 10-20 年间还可能撑持用户的业务？用户做架构抉择最重要的规范是什么？是整个设计团队是不是具备掌控复杂性的能力，是不是可能看到将来 10-20 年企业中的零碎复杂性会朝什么方向迭代，明天在零碎里做好设计，能够应答将来的高速演进和迭代，而不只是一个过渡计划，过两年还要再换。 尽管咱们在设计 TiDB 的过程中，曾经做了高度分离式架构，开放式 API ，但有些货色融入血液时就会无感，而在用户看来这恰好是他们最看重的，这给了咱们很大启发。一个专家型用户跟我说： “人类几千年来应答复杂性只学会了一个情理，就是分而治之”。 这听起来如同是一个很简略的情理，回忆一下会感觉他说得太对了，这也是人类几千年来应答复杂性的惟一方法。分而治之落在软件或者数据库的复杂性下面，应该是什么样的？这就是 TiDB 将来的演进方向，也是整个行业将来的演进方向。与专家型用户不同，应用型客户又是齐全不一样的观点。有些用户是做守业公司，能不能活过两三年本人也不晓得。 如果抉择一个货色须要花 2-3 年能力看到足够大的价值，必定等不起，他须要更快地兑现价值。 事实上，这些应用型客户不仅仅是那些守业公司，还有很多是大公司外面的新我的项目。大家晓得在一个大公司里经常出现一种状况，当做一个新业务时，每个人心里都分明工夫很无限，公司可能等不了用 5 年工夫来做一个翻新，所以怎么能力更快地开释数据价值才是他们关怀的话题。明天的数据库是一个百花齐放的状态，甚至在国内的一些场景呈现了数据库“四世同堂”的场面，同时跑着大型机、小型机、x86，接下来甚至还要引入分布式数据库、云数据库，对用户而言抉择一个数据库其实十分艰难。世界变动太快，很多时候用户可能是在我的项目进行的过程中忽然有了一个新的想法。 怎么用最快的速度把这个货色做进去，并且做进去之后不必操心它是不是能扛更高的并发？如果疾速把第一个原型推到线上，用户是不是能够不必操心前面的并发问题？当推到市场时立即就能取得新的反馈，新反馈作为新需要加进来后，能不能在当天就间接提供服务？这个时候十分依赖数据库的能力，特地是当咱们和越来越多的年轻人聊时，会发现他们明天曾经不再关怀数据库任何底层的货色。 他们只关怀你有没有能力让他用最快的速度将产品或服务推向市场，在推向市场后有没有能力反对业务高速倒退 ，有些用户甚至连 SQL 都不想写了。从新思考：如何以敏捷性应答将来所有这些对数据库的能力要求十分高，实质上咱们要用数据库的能力撑持业务的敏捷性：如果要反对一个麻利业务，那数据库自身的迭代能力是不是足够麻利？ 这让咱们对麻利产生了全新的思考。有两个用户让我感觉特地震撼，其中一个是区块链畛域的用户，通过应用区块链技术追踪区块链里的每一笔交易，如果是雷同的人还能够追踪跨链的交易。这个用户在不到一年的工夫里，单个集群数据量从几 TB 上涨到一百多 TB。因为 TiDB 太好用了，他会把更多的数据往 TiDB 里放，把 TiDB 作为在线服务。当你有这个想法时就会发现，你基本找不到一个其余数据库能满足这个需要；它须要在线服务、低提早，须要从不同角度查问数据，你能够用索引、HTAP 能力，还必须要有十分弱小的 SQL 能力，因为用户会不停往里面塞数据。前两天在 Hacker News 上有一个热帖，微软云的 CTO 发了一个推特，引起了轩然大波，他说当初 C 和 C++ 这类语言被标识为过期的语言，如果大家用 Java 或者其他软件，常常会把过期的不再反对的 API 标记成过期数据。他的倡议是咱们应该把 C++ 标记成过期，任何我的项目不再用 C++ 写，应该全面应用 Rust。可能有人有印象，TiDB 在 2015 年就开始用 Rust 写存储层。但对于新用户来说，当晓得咱们用 Rust 和 GO 作为编程语言时，他们就会说你们好时尚，实际上这是咱们 7 年前的决策。当初，Rust 还没有公布 1.0 版本，拿这个货色来写数据库几乎是开玩笑。很多时候，咱们的一点翻新，一点激进的动作，很可能在当初饱受非议，但在将来却可能成为支流。 PingCAP 在技术、架构下面始终会抉择十分踊跃的翻新，十分具备前瞻性的翻新，这些翻新甚至要在 5-7 年后能力感触到当初的抉择是十分正确的。总结来说，如果用几个词来形容 PingCAP 的胜利范式，那就是自主开源+继续引领+面向未来的翻新，都服务于客户胜利，不论是专家型的客户还是应用型的客户，TiDB 都可能很好地去反对他们的业务更好、更敏捷地迭代倒退。 TiDB 也因而成为泛滥行业头部用户的独特抉择，助力用户业务麻利增长。用户分享：建信金科为什么抉择与 TiDB 同行？建信金科根底技术核心副总裁邢磊分享了建信金科如何借助 TiDB 实现业务增长敏捷性。 建信金科自关注分布式数据库以来，PingCAP 始终未来到过其眼帘。与大多数用户不同，建信金科与 PingCAP 的接触不是从 TiDB 开始，而是 TiKV，为什么是这样的抉择？建信金科的微服务、分布式，要求对数据做拆分，须要在现有业务不做大调整的状况下，去开启业务应答将来不确定性的能力。在这个过程中有一个绕不过来的问题，这么多传统渠道、传统业务和交易，如何在不影响现有交易模式的前提下革新后端的服务能力？TiKV 在这样的场景下进入视线，以前建信金科用的是国外开源软件，整个历程中遇到的问题和挑战十分大，也给本人的平安稳固运行带来很大挑战。建信金科始终在思考怎么去找一个本人能掌控的技术，去解决后续将在这个畛域上面对的问题。从 2020 年开始接触 TiKV，做业务场景适配，包含晚期的技术、产品验证，以及单方在 TiKV 上投入研发的资源和精力，一起致力了差不多一年工夫。这是建信金科做过的所有案例里耗时最长、投入最大的我的项目。2021 年 10 月，建信金科第一次把 TiKV 5.0.4 版接入到全行分布式体系当中，顺利扛住 4 万多 TPS 压力稳固运行，开启 TiKV 在建信金科分布式体系中的重要作用。 随着外围业务的革新，建信金科去年底将整个外围业务在分布式平台上进行切换，TiKV 起到了十分要害的作用。自 2022 年开始，建信金科更进一步借助 TiKV 的高可用体系构建了跨地区、跨核心的灾备能力。HTAP 在金融场景的验证传统金融企业在交易业务线、数据分析业务线的解决其实都会离开，多维查问和治理类剖析业务偏向于用大数据业务解决，但随着本人的数字化转型逐渐深刻以及各种平台生态建设，所有的要害业务、外围业务都面临着新的挑战，这恰好就是 HTAP 要解决的问题。这个场景用传统的大数据技术很难在数据实时更新场景下同时提供多维的剖析和查问能力。在这个场景下，过后建信金科遇到十分大的挑战，留给 PingCAP 的工夫十分短，从 4 月底提出到 5 月底验证，只有一个月的工夫。去年 10 月正式投产进入稳固的迭代。当初，建信金科每个新的场景都会有 TiDB 的身影。以后，建信金科正在尝试将系统升级到最新的 TiDB 6.1 版本。同时，也在将更多的对立视图、全量资产、反洗钱业务在 HTAP 上做验证和迁徙。 将来，建信金科与 PingCAP 将进行联结技术创新攻关，在金融场景下更大规模业务模式的翻新以及将来数据库如何更好的适应云计算趋势等方面进行更多摸索。回顾来看，为什么 PingCAP 可能在泛滥分布式数据库厂商中受到建信金科的继续关注？次要有三点：第一，服务于客户胜利。 数据库是一个服务于利用的产品，只有关注客户的胜利，关注客户遇到的理论问题，才可能博得更好的倒退；第二，PingCAP 的开放性。 PingCAP 从出世开始就始终以开源凋谢的特色存在于数据库行业，正是这一点使得建信金科更偏向于抉择它，置信开源和凋谢的力量会成为将来企业技术重要的组成部分；第三，成长性。 所有的技术不能光看它在以后曾经获得的成就，以及以后体现进去的状态，更重要的是关注它的成长性。技术从以后的里程碑到下一个里程碑，加速度是不是足够快，如果有更快的加速度，当初所有存在的艰难和差距都会在短时间内失去冲破。与 PingCAP 一起，与优良的开发者和专家一起，将获得更大的成长。百胜中国：拥抱开源，减速翻新百胜中国首席技术官张雷分享到，百胜中国是中国最大的餐饮企业，致力于成为寰球最翻新的餐饮先锋。百胜中国获受肯德基、必胜客和塔可贝尔在中国边疆的独家经营和受权经营权，并齐全领有小肥羊、黄记煌和 COFFii & JOY 餐饮品牌，也和意大利咖啡企业 Lavazza 单干，在中国摸索和倒退 Lavazza 咖啡店品牌概念。截止 2022 年 6 月底，百胜中国在中国的脚印遍布除港、澳、台之外的所有省市自治区，在 1,700 多座城镇，有 40 多万员工经营着 12,000 多家餐厅，全年客流量超 20 亿次。2021 年，百胜中国正式启用了位于上海、南京、西安三地的数字化研发核心，这是公司打造一个充满活力的数字化生态系统的重要里程碑。由数字化研发核心、合资公司以及第三方合作伙伴组成的多层次研发体系，为公司品牌和业务进一步翻新倒退，减速扩张，抓住市场时机奠定了松软的根底。 在数字化一直倒退的明天，打造麻利高效的数字化能力，成为了餐饮企业的立身之本。百胜中国在业内率先推出了手机点餐业务，在全国范畴门店推出了数字领取，疫情期间也落地了大规模的无接触配送，百胜中国不仅继续地欠缺从线上点餐、外卖到会员打算、礼品卡等消费者场景，同时在餐厅内也构建了百胜自主研发的点餐和收银零碎，继续打造餐饮业当先的端到端的数字化生态。截止 2022 年 6 月底，百胜中国的线上会员数量超过了 3.85 亿，2022 年第二季度，数字化订单占比达到了 89%，会员营销额也约占到了零碎销售额的 62%。百胜中国也一直利用数字化能力赋能门店经营，例如基于数据和 AI 能力，构建了餐饮行业特有的营运大脑以及口袋经理，为门店经营效力的晋升提供了数据以及零碎撑持。同时也聚焦自动化、IoT 及智能餐厅等畛域，基于以后一直蓬勃发展的大数据、云计算等根底能力，借助于百胜中国本人的研发核心、合资公司以及第三方合作伙伴，独特为百胜中国两万家餐厅的指标夯实牢固的数字化根底。百胜的生态环境中领有丰盛的利用场景，让各种技术能力有生根落地的机会。 同时随着企业数字化转型进入了深水区，对于数字化基础设施的自主可控性和灵活性的要求也进一步在晋升。开源软件起到了越来越重要的作用，成为企业翻新实际的催化剂。基于开源根底软件体系，能够晋升企业 IT 技术的标准化；沉闷的开源社区，也能够无效帮忙企业升高试错老本。当企业投入肯定的资源帮助开源社区建设时，可能同步晋升自主的技术品牌和技术人才的能力以及影响力。TiDB 是业内开源分布式数据库的翘楚，百胜中国在 2019 年就开始了后期钻研，以尝试代替传统的商业数据库产品。 百胜中国十分看重外围数据的解决主权，开源数据库恰好可能帮忙把握这一主权，同时借助沉闷的开源社区，进行企业外部创新性的架构钻研以及落地。通过大略一年的摸索，TiDB 最终在百胜的业务中台，例如音讯中台、用户中台以及领取中台中得以落地施行，用于撑持百胜中国的线上交易。 TiDB 对于百胜中国的海量数据提供了稳固牢靠的零碎反对。家喻户晓，因为餐饮行业存在着显著的高下峰场景，目前像肯德基“疯狂星期四”，它的交易量是远超平时的，TiDB 的灵便程度扩大能力，使得百胜中国能够依据业务的需要进行计算资源实时调整，助力降本增效。同时，在社群营销、ERP 报表等典型剖析场景中 TiDB 的 HTAP 个性，也使得百胜中国能够以较小的代价进行海量数据的在线交融剖析，以实现麻利的业务撑持，百胜中国将 ERP 中的交易数据同步到 TiDB 中，再与 BI 工具进行集成，大幅缩短了企业外部的财务报表生成工夫，极大晋升了外部的工作效率。随着云原生和开源技术的继续倒退，百胜中国不断加强各种新型开源技术的深度摸索、利用以及交融，从而更无力地推动餐饮垂直行业云能力以及自我翻新的倒退。本次峰会中， PingCAP 与百胜中国强强联合，成立“百胜中国 ✖️ PingCAP 分布式数据库联结实验室”。 联结实验室立足于单方的技术和生态劣势，独特摸索前瞻技术的翻新和落地实际，晋升餐饮行业的数字化服务水平和能力。其实不只是建信金科与百胜中国，明天 TiDB 曾经撑持了很多人一天 24 小时各种各样的生存需要，融入了人们的日常生活中。在软件畛域有一句经典的话，“Make it work, make it right, make it fast”，TiDB 明天就在 make it fast 的阶段。随着 TiDB 架构自身的拆散做得越来越好，TiDB 架构的正确性会让性能晋升和改良十分惊人。一个正确的内核才有成长的可能和更高的成长性。在过来一年的工夫里，PingCAP 在外围场景 OLTP 畛域取得了显著的性能晋升。新物种：聊聊 HTAP我在和客户聊的时候发现，HTAP 是一个很难讲明确的技术，它和 Hadoop 有什么区别？原来的大数据十分重，像是一只大象，相较之下 OLTP 数据库就像一条蛇，很灵便很疾速，它不是加法，而是交融，是一个全新的物种。但对于 HTAP 的挑战并没有解决，到底什么叫 HTAP？有没有一个例子能让用户一下子明确？TiDB 能干什么他人干不了的事吗？咱们做了一个 DEMO，试图在 5 分钟内讲明确到底什么是 HTAP，到底 HTAP 能带来什么样的价值。一个好的 DEMO 应该具备什么特点？第一得难看，第二得好用，咱们的 DEMO 除了难看、好用，还得好玩。这个 DEMO 所有数据都是实在的，并且一秒就能体验。咱们也心愿将这个 DEMO 开源进去分享给其余搭档，这也十分合乎 PingCAP 开源的理念。有一位用户已经问咱们 “用 HTAP 前后有什么差异？”，有一个十分直观的体验：OSS Insight 第一版只用了两个人，一个周末就做进去了。如果是传统计划，通常要用 4-6 集体，花半年工夫。这个事件给了咱们另外一个启发， 每个人都有好奇心，每个人都有本人洞察的视角，每个好奇的灵魂都值得用 Insight 去激发。 这之前，咱们只能看十分寒冷的 TPCC、TPCH 等和业务看起来一点关系都没有的货色，对新一代程序员来说这几乎是上古语言。产品的价值能不能和用户的挑战联合起来？业务翻新的敏捷性又依赖于数据麻利。最近一段时间脱口秀比拟火，人人都能说 5 分钟的脱口秀。通过 OSS Insight ，咱们能够让人人都能在 5 秒钟内取得 Insight 。咱们构想每一个组织、每一个企业、每一个人都能够取得这个能力，都有这个好奇心去获取 Insight，像咱们 700 人的企业就有 700 个脑袋。OSS Insight 中都是开源数据，任何一个人去看都能提出本人的 idea。通常状况下，用户接下来的问题会是：到底有什么场景不是你的舒服区？咱们依据所有线上用户实在的状况，画了上面这张图，大抵形容了 TiDB 的舒服区到底在哪里。HTAP 已死？在咱们和用户聊的时候，常常有用户说 HTAP 这个概念曾经听了 8-9 年，为什么始终没有火？甚至认为 HTAP 曾经死了。 如果依照它原来的定义，HTAP 的确曾经死了 。HTAP 原来的状态基于两个根底假如：一个是内存即硬盘。十年前，“内存是新一代的磁盘”这一说法被炒得炽热，如果真是这样，每台机器上当初都能够领有 1 PB 以上的内存。但当初大家看到内存仍然很贵，这意味着过后 HTAP 的第一个假如，内存足够大足够便宜，被证实是不事实的；另外一个是摩尔定律，过来当 CPU 高速倒退的时候，咱们对摩尔定律充斥期待，而显然过来十年 CPU 倒退速度让咱们很悲观，所以过后的两个根底到明天都不存在了。但有一句话说得好， “迷信的每一次提高都是在葬礼上获得的”； 上一个 HTAP 曾经死了，为什么 PingCAP 还在保持 HTAP ？最近 HTAP 又很火的样子，这是为什么呢？实际上，对于足够大的内存和硬盘，足够多的 CPU 和算力，现在都能够通过云的形式来失去，在云上你能够领有近乎有限的内存。明天用户的应用习惯也产生了扭转，用户心愿在一个零碎外面能存储足够多的数据，足够快地处理事务。所以， 一个弱小的 OLTP 能力是 HTAP 的根底，凡是不具备这个根底就不能称之为 HTAP。在这个背景下，HTAP 新生了。 过来一年里， MySQL 公布了 HeatWave 作为 MySQL 的 HTAP 解决方案，Google 也在往年公布了 AlloyDB ，不久前 Snowflake 也公布了它的 HTAP 引擎 Unistore。咱们认为 HTAP 带给用户的体验就是简略 + 实时，同时还要求整个零碎具备十分强的隔离性。 共享一份资源会面临较大挑战，因为它会吃掉大量的 OLTP 资源，所以物理隔离是 HTAP 的根底。 TiDB 的架构很间接地展现了这个能力，当咱们齐全是物理隔离的时候，TiDB 的执行打算会很智能地从 OLTP 中抉择这部分数据。 TiDB 在过来倒退过程中，最早是作为一个业务数据库在用，随着外面数据越来越多，肯定水平上它就变成了一个实时数据服务层。 各种各样的业务零碎开始把 TiDB 作为中间层提供彼此交互的能力，比方 CRM 不能和 ERP 直接对话，但通过 TiDB 把数据汇集在一起，它们就能够直接对话了。继续引领数据服务的敏捷性TiDB 在继续引领数据库的演进方向，咱们置信在接下来 2-3 年的工夫里，会有越来越多的数据库退出这个队伍，朝着独特的方向去迭代和演进。将来的方向肯定是数据库微服务化。 这外表看起来有点奇怪，为什么数据库要微服务化？微服务和数据库有什么关系？咱们认为，明天的数据库不仅仅是数据库的一个内核，它曾经是一套简单零碎，后面提到的掌控复杂性的办法只有一个，那就是分而治之。微服务化实质上会达到一个成果，让规模化效应开始掌控所有，最初带来的后果和用户的价值，能够大幅压低用户应用老本。 目前，TiDB Cloud 在过来一年中通过继续孵化革新，老本曾经降到了原来的1/10。一个很简略的例子，明天每一个数据库都有一个能力叫 GC，如果每一台服务器都去 配这样一个能力，要么压力大的时候不够用，要么齐全节约了，然而这个性能又不得不配上。比拟好的方法是让这个 GC 也可能规模化，使它自身变成微服务。数据压缩、继续后盾优化都是这样，咱们不能用原来的系统资源去做，用户心愿花钱买的每一份计算资源都是为他服务，而不是用 1/3 来做后盾服务。连贯中国与世界 在寰球，TiDB 始终施展着连贯中国和全世界的作用。 为什么那么多的用户、合作伙伴会抉择咱们？开源、云中立以及寰球合规，就是 TiDB 起到的连贯作用。同时，PingCAP 有大量的利用场景也是连贯寰球的，上图能够看到明天 TiDB 曾经被用到了寰球各行各业。每一个场景里都有中国的用户，也有来自美国、日本、新加坡、欧洲和印度的用户。基于中国寰球当先的场景，基于开源十分高效通明的流传与合作模式，基于开源汇聚寰球的智慧，最终使得 PingCAP 失去寰球更多的客户与合作伙伴的信赖。用户分享：传音携手 PingCAP 打造全新数字化非洲土壤传音控股是一家致力于成为新兴市场消费者最青睐的智能终端产品和挪动互联服务提供商，在与 PingCAP 的单干中，将其挪动商店的整体服务架构迁徙到了 TiDB 上。传音控股挪动互联 CTO 史团委示意， PingCAP 使得传音控股能够将更多资源投入在业务的推动上，从中后盾工作中解放出来，大幅降低成本 。TiDB 的程度扩大、故障自复原、数据强一致性、高度兼容性等特点，帮忙传音控股实现了技术进阶，晋升了用户体验，减速了技术架构平台化与垂直化的演进。用户分享：老虎国内 - 只有真正的全球化公司 能力服务全球化客户老虎国内作为寰球出名的国际化券商，在新加坡、美国、中国香港、澳大利亚等地持有 59 张牌照或资质，在寰球多地开展业务。老虎国内技术副总裁柳锴示意，只有真正的全球化公司能力服务全球化客户。基于全球化的业务，老虎国内的数据架构、数据安全等也面临着全球化的挑战。 TiDB 能够解决零碎架构的复杂度，同时通过低提早、数据强一致性，解决业务挑战与数据安全挑战。技术人如何发明社会价值？作为一个技术人员，咱们始终在想一个问题， 作为一家企业怎么发明社会价值，怎么做更多的奉献？ PingCAP 最早从开源起家，把所有所有能开源的货色都开源了，开源始终融在咱们的基因里。作为数据库从业人员，作为数据库的开发者，我记得上大学时还没有一个十分好的数据库教程。那时数据库仍然没有方法做到足够的平民化，并不是每一个人、每一个开发者都能领有一个永远在线的数据库。所以过后我就有一个想法，当前肯定要让数据库变得触手可及，让每个人都能够领有本人的数据库。为了让 TiDB 触手可及，咱们做了很多事件，推出了本人的 Talent Plan，与 VLDB 单干，所有的一切都是心愿让数据库变得触手可及。同时这也帮咱们带来了十分凋敝、多样化的社区， 目前已有 1, 895 位 Contributor， 笼罩 45 个国家与地区。说到触手可及，最要紧的一件事件就是老本。随着 TiDB 的新一代分布式架构和规模化效应，明天咱们终于可能让每一个开发者都能够领有一个永远在线的收费的数据库，咱们能够随时去体验这个数据库，这就是新的架构带来的老本劣势。在过来的 7 年中，PingCAP 一路走来磕磕绊绊，我始终在想能不能把这些经验教训也都开源进去？明天咱们非常高兴地发表，通过半年多的集体创作，咱们将过来 7 年的那些经验、教训和教训，也开源进去，首发《与开源同行》这本书，心愿大家喜爱，持续与 PingCAP 同行。最初，TiDB Hackathon 是我最期待的一年一度的技术盛会，也期待你的退出。 ...

一年一度黑客们的狂欢——TiDB Hackathon 2022 报名已开启，万元奖金等你来拿，还有技术专家、顶级投资人全程坐镇，你的实力将被更多人看到。TiBD Hackathon 2022 ·「Possibility at Scale」 ，邀请你一起突破传统技术边界，冲破固有思维局限，用 TiDB 开释翻新的更多可能性。轻轻说：往年真的不卷，值得一试！两大赛道，任选：利用组举荐噢，因为特地奖项更多！以体现 TiDB 产品价值为主，应用 TiDB 构建代码开源的产品、工具、利用等均可。部署形式上，更举荐基于 Cloud 构建 TiDB 相干利用。常见应用领域：游戏、电商、金融科技、公益等。TiDB 产品组连续传统，放弃初心 为 TiDB 内核产品以及 TiCDC、TiDB Lightning、TiUP 等周边工具的性能、稳定性、易用性或性能等各方面做出晋升。扫描下方二维码立刻报名参加！据说你想加入 TiDB Hackathon，却没有 idea？别放心，脑洞达人东旭和他的架构师敌人们在创意脑暴会上分享的我的项目 idea 都整顿好啦，快来看看有没有你感兴趣的~ （ps：搭配视频查看 idea 具体介绍，成果更佳哦~）创意奉献嘉宾黄东旭 PingCAP 联结创始人兼 CTO姚维 PingCAP 寰球社区生态负责人张兴晔 多点零碎架构师Cheng Chen PingCAP Product Manager脑暴会视频（创意列表往后翻哦！）退出全屏切换到横屏模式 点击观看视频无奈获取音频链接视频详情残缺视频： https://www.bilibili.com/vide... （复制链接至浏览器即可查看，创意对应具体工夫点可点击文末【浏览原文】，返回 Hackathon 2022 创意库查看）利用组往年利用组的决赛参赛我的项目仅要求是 demo 级别的，例如以下我的项目示例：OSS Insight： https://ossinsight.io/（复制链接至浏览器即可查看，下同）这是一个基于 TiDB 实现的，数十亿 GitHub events 数据构建的洞察工具。只有你会写 SQL，就能够基于 Docusaurus、Apache ECharts 构建一个弱小、酷炫的数据洞察工具。TiDB & Snowflake Demo： https://tidb-snowflake-e-comm...这是一个基于 TiDB 和 Snowflake 构建的电子商务系统，该零碎应用了 TiDB 弱小的实时 HTAP 能力和 Snowflake 的离线剖析能力，来解决零碎中大量的数据。Ti-Click： http://ide.ti-click.com/这是 TiDB Hackathon 2021 的 20 强我的项目之一，我的项目通过在线 IDE 的形式，疾速搭建基于 TiDB 的 Example App 的开发和在线编译的实验室，可帮忙开发者疾速学习 TiDB。Bookshop这是一个基于 TiDB 搭建的在线书店利用，你能够通过它来学习如何导入表构造和数据，以及如何基于这些数据来编写 SQL。这篇文章也以 Bookshop 利用的数据表构造和数据为根底来编写示例 SQL，为你介绍如何导入该利用的表构造和数据，以及其数据表构造的定义。 https://docs.pingcap.com/zh/t...对于 TiDB 初学者，咱们基于 Gitpod，提供了一个云原生开发环境的应用帮忙，你能够间接从你的浏览器或桌面 IDE 启动一个近程的 TiDB 开发环境，疾速体验 TiDB 的能力。咱们编写了全新的 TiDB 开发者文档，这份文档能够帮忙利用开发者，在最短时间内上手 TiDB。TiDB 开发者文档： https://docs.pingcap.com/zh/t... 产品组彩蛋组彩蛋组不可更改 TiDB/TiKV 源码，仅可应用插件形式进行 Hack。心愿能够给你一些方向与灵感！ 更多我的项目 idea 也能够来 Hackathon 2022 创意库（ 扫描下方二维码 或点击文末 【浏览原文】 ，立刻返回！） 找灵感看到这么多 idea，你是否蠢蠢欲动了呢？酷爱编程，勇于探索，就能参赛你离万元大奖只有一个报名的间隔~ps： 扫码增加小助手微信号，回复 2022 入群，理解更多！ 点击文末 「浏览原文」 ，立刻返回 Hackathon 2022 创意库！ ...

一年一度的 TiDB Hackathon 又来啦！TiDB Hackathon 2022 主题为 「Possibility at Scale」 ，9 月 13 日正式开启，线下决赛将在 2022 年 10 月 22 - 23 日举办。期待与你一起突破传统技术边界，冲破固有思维局限，用 TiDB 开释翻新的更多可能性。本届 TiDB Hackathon 将面向更宽泛人群， 分为利用组与 TiDB 产品组两大赛道 。无论你是利用开发者、数据库开发者、数据库上下游生态从业人员，还是数据库使用者，都能够找到适宜本人的方向，一起“玩转” TiDB。TiDB Hackathon 报名通道于 2022 年 9 月 13 日正式开启， 选手们能够自行组队参赛，通过初赛甄选后，将在现场实现 Coding 及决赛问难，优胜队伍将取得奖金、技术和资源商的反对 。大赛评委阵容奢华，数据库畛域资深专家、社区技术大牛、顶级投资人代表将对我的项目进行深度点评。此外，还有顶级投资人全程参加评比，让你的实力被更多人看到。扫描下图二维码，立刻报名参赛！从 2017 年到 2022 年，TiDB Hackathon 一直降级，吸引了寰球 1000 + 技术爱好者参加，先后诞生了诸如 UDF 引擎、TiExec、TiMatch 等深受好评的硬核我的项目，也有 zh.md、TiDB 驾驶舱、pCloud 等新鲜乏味的我的项目。同时，局部优良我的项目还在海内外媒体平台取得了多重曝光，借助 TiDB 社区力量为我的项目提供更多生命力。PingCAP无奈获取视频链接TiDB Hackathon 2021 战队巡礼往届 TiDB Hackathon 精彩霎时在 TiDB Hackathon ，你能够纵情施展想象力与创造力，全情投入，实现本人的 idea。咱们心愿你能够永葆对技术的激情与好奇心，在代码的世界中怯懦摸索、裹足不前。咱们在 TiDB Hackathon 2022 等你，期待与你共赴这场技术盛宴！赛事亮点 奖金丰富大赛总奖金池高达 35 万元，奖项多达 10+ 个，涵盖各个方向，力求全方位开掘各参赛我的项目的价值。 各路大神同台竞技技术大神齐聚一堂，演出“神仙打架”，局面超燃。高手之间的巅峰对决，精彩纷呈，让人大开眼界。 高质量交换数据畛域出名专家、社区技术大牛负责大赛评委，对我的项目进行深刻点评，还有顶级投资人全程参加评比，你将不止播种硬核的技术反馈，还会取得前瞻性启发。 优 秀我的项目专题采访大赛完结后，咱们将对优良我的项目进行专题采访，在海内外技术圈多重曝光，晋升优良我的项目的知名度，借助 TiDB 社区力量为我的项目提供更多生命力。丰富奖金奖金池 35 万元， 10+ 奖项，20+ 获奖团队神秘定制社区周边参赛对象不论你是数据库内核工程师、数据库生态上下游开发者，还是利用开发者，只有你有 idea，都能够报名参赛，一展你的风采！赛道设置利用组以体现 TiDB 产品价值为主，基于 TiDB 之上实现代码开源的产品、工具、利用等均可。部署形式上，更举荐基于 Cloud 构建 TiDB 相干利用。举荐畛域：游戏、电商、金融科技、公益等。TiDB 产品组为 TiDB 内核产品以及 TiCDC、TiDB Lightning、TiUP 等周边工具的性能、稳定性、易用性或性能等各方面做出晋升。赛程安顿 报名即日起 - 10 月 17 日，开启报名组队9 月 17 日，加入「非正式谈判 — 创意脑暴会」，获取我的项目灵感（详见下方介绍）线上初赛报名后 - 10 月 17 日，提交 RFC 进入初赛环节名单颁布10 月 19 日，查看决赛入围名单现场 Coding & 决赛10 月 22 日 - 10 月 23 日，现场 Coding & 决赛问难评委阵容数据库畛域出名专家、社区技术大牛、顶级投资人代表等担当评委，还有顶级投资人全程坐镇，对比赛项目深刻点评。（评委按姓名首字母排序）较量有输赢，技术无高下。即使最终未能问鼎巅峰，朝着心之所向全力冲刺仍旧是一段值得回顾的旅程。秉承一直冲破和发明的黑客精力，来一场技术的狂欢盛宴吧。放码过去！报名赛事扫描下方二维码，立刻报名流动！创意脑暴会给你灵感TiDB Hackathon 2022 非正式谈判 —— 创意脑暴会 来啦，这里有超多 idea，特邀东旭以及资深架构师们在线脑暴，给你超丰盛我的项目灵感。 9月17日 本周六 10:30-12:00（GTM+8），线上见～合作伙伴 点击文末 「浏览原文」 ，理解 TiDB Hackathon 2022 更多精彩！ ...

本文次要介绍了数据库系统中罕用的算子 Join 和 Aggregation 在 TiFlash 中的执行状况，包含查问打算生成、编译阶段与执行阶段，以冀望读者对 TiFlash 的算子有初步的理解。 视频https://www.bilibili.com/video/BV1tt4y1875T 算子概要在浏览本文之前，举荐浏览本系列的前作：计算层 overview，以对 TiFlash 计算层、MPP 框架有肯定理解。 在数据库系统中，算子是执行 SQL 次要逻辑的中央。一条 SQL 会被 parser 解析为一棵算子树（查问打算），而后通过 optimizer 的优化，再交给对应的 executor 执行，如下图所示。 本文的次要内容包含 TiDB 如何生成与优化 MPP 算子与查问打算Join 算子在 TiFlash 中的编译（编译指的是将 TiDB-server 下发的执行打算片段生成可执行构造的过程，下同）与执行Aggregation 算子在 TiFlash 中的编译与执行构建查问打算一些背景常识： 逻辑打算与物理打算：能够简略了解为逻辑打算是指算子要做什么，物理打算是指算子怎么去做这件事。比方，“将数据从表 a 和表 b 中读取进去，而后做 join”形容的是逻辑打算；而“在 TiFlash 中做 shuffle hash join” 形容的是物理打算。更多信息能够参阅：TiDB 源码浏览系列文章MPP：大规模并行计算，个别用来形容节点间能够替换数据的并行计算，在以后版本（6.1.0，下同）的 TiDB 中，MPP 运算都产生在 TiFlash 节点上。举荐观看：源码解读 - TiFlash 计算层 overview。MPP 是物理打算级别的概念。MPP 打算在 TiDB 中，能够在 SQL 前加上 explain 来查看这条 SQL 的查问打算，如下图所示，是一棵由物理算子组成的树，能够查看 TiDB 执行打算概览 来对其有更多的理解。 ...

PingCAP 用户峰会 2022 全议程现已公开，本次大会汇聚前沿数据库技术、实在用户体验、凋敝生态搭档，分享他们面向未来的抉择；冀望与你独特见证 数据麻利 如何在充斥不确定性的当下，帮忙企业 实现逆势的业务增长。本届大会还有哪些亮点值得期待？剧透如下，不要错过！ 大会亮点领先看PingCAP 用户峰会 2022面向未来的抉择：以终为始，全球化的翻新之路 如何开发让工程师们不必熬夜，睡个好觉，让用户省心的数据库？一个简略而弱小的分布式数据库该是什么样子？TiDB 从 1.0 到 6.0 一直进化，从年老的我的项目到企业级产品，PingCAP 向用户提供的也从单纯的数据库产品进化为产品 + 服务的综合体。从中国到寰球，TiDB 的能力正在让更多工程师感触到“简化”的力量，以“数据麻利”赋能企业，让“洞察”成为新一代数据服务的标配。怎么做出面向未来的抉择？听听数字化转型中的“先行者”们怎么说。咱们邀请到了来自银行、保险、证劵、电信、政府、新批发、智能制作、智能交通、智慧医疗、SaaS 以及中国出海企业的 标杆用户 ， PingCAP 创始人兼 CEO 刘奇将携百胜中国、建信金科、传音挪动互联、老虎国内的嘉宾 与咱们分享基于 TiDB 的翻新实际。咱们如何服务企业用户：业余服务和技术支持体系TiDB 从研发端提供安全可靠的产品，以开源社区保障继续翻新的能力，打造了业余服务和技术支持体系：从云下到云上；从需要、资源、进度到服务治理的全周期服务反对保障；从软件层面的 TiUniManager、PingCAP Clinic 服务，到背地的产研体系……PingCAP 研发副总裁唐刘和中国区技术服务总经理李超群 将现场解析 PingCAP 服务体系。揭秘 PingCAP 如何实现最佳实际标准化，做到本地化疾速相应，把最佳体验带给终端用户。中国数据库倒退钻研：借力开源和云实现交融翻新数据库作为 IT 行业最重要的核心技术之一，近年来产生着微小改革。数据库开发方式从闭源逐渐走向开源，云数据库也突破了传统数据库长期稳固的霸主位置，特地是互联网厂商和垂直行业用户纷纷尝试解脱对经典数据库的技术依赖。海量数据急速增长和高并发、实时剖析解决等需要使传统数据库短板凸显，而新型数据库则推动行业利用实现跨越式倒退。云原生部署、存算拆散已成支流方向，技术交融与 HTAP 能力也成为重要竞争力。中国赛宝实验室李冬博士 将在大会现场解读《中国数据库倒退钻研》，回顾我国数据库产业多种技术路线疾速倒退的历程，实现知识产权自主与降级迭代可控；剖析开源生态和云技术如何助力技术凋敝，满足理论场景需要，实现交融翻新。连结产业与生态：深耕行业的实际和摸索海量数据的实时剖析和解决、多源数据异构、大数据技术栈蔓生成为了企业数字化转型倒退中面临的最大瓶颈。TiDB 通过 OLTP Scale 和齐备的 HTAP 能力，在满足实时化解决需要的同时简化技术栈。在 HTAP 曾经成为了新一代数据库根底要求的明天，用户为何抉择 TiDB，又如何实现平滑迁徙，建设起齐备的运维体系？PingCAP 副总裁陈煜琦将与来自安全科技、杭州银行、中国人寿财险、工商银行的用户 独特分享企业如何通过 TiDB 构建“应答当初，助力将来”的数据架构，以及 PingCAP 如何与用户共创，深耕行业，赋能产业生态。《与开源同行》新书首发：揭秘 PingCAP 七年守业实际2020 年，PingCAP 实现 D 轮融资，成为中国开源的独角兽公司，公司的明星产品 TiDB 数据库 32 个月在墨天轮国产数据库风行度排名首位……令人惊叹的成绩背地是公司怎么的思考和理念践行呢？在本次峰会上首发的 《与开源同行：揭秘 PingCAP 七年守业实际》 将残缺解读 PingCAP 公司七年来的摸索教训，论述开源技术和文化对新一代技术驱动型企业的生存和倒退意义。参加线上、线下互动有机会赢取首发幅员书。开源路上，感激有你同行！7 年的技术积攒、超过 3,000 家用户的教训积淀、云上云下的实际心得……超多精彩，不容错过！心动不如口头，扫描下方二维码或点击浏览原文立即报名！ ...

本文选自《TiDB 6.x in Action》，分为 TiDB 6.x 原理和个性、TiDB Developer 体验指南、TiDB 6.x 可管理性、TiDB 6.x 内核优化与性能晋升、TiDB 6.x 测评、TiDB 6.x 最佳实际 6 大内容模块，汇聚了 TiDB 6.x 新个性的原理、测评、试用心得等等干货。不论你是 DBA 运维还是利用开发者，如果你正在或有动向应用 TiDB 6.x，这本书都能够给你提供参考和实际指南。 TiFlash 是 TiDB 的剖析引擎，是 TiDB HTAP 状态的要害组件。TiFlash 源码浏览系列文章将从源码层面介绍 TiFlash 的外部实现。次要包含架构的演进，DAGRequest 协定、dag request 在 TiFlash 侧的解决流程以及 MPP 基本原理。本文作者：徐飞，PingCAP 资深研发工程师 背景上图是一个 TiDB 中 query 执行的示意图，能够看到在 TiDB 中一个 query 的执行会被分成两局部，一部分在 TiDB 执行，一部分下推给存储层（TiFlash/TiKV）执行。本文咱们次要关注在 TiFlash 执行的局部。这个是一个 TiDB 的查问 request 在 TiFlash 外部的根本解决流程，首先 Flash service 会承受到来自 TiDB 的 RPC 申请，而后会从申请里拿到 TiDB 的 plan，在 TiFlash 中咱们称之为 DAGRequest，拿到 TiDB 的 plan 之后，TiFlash 须要把 TiDB 的 plan 编译成能够在 TiFlash 中执行的 BlockInputStream，最初在失去 BlockInputStream 之后，TiFlash 就会进入向量化执行的阶段。本文要讲的 TiFlash 计算层实际上是蕴含以上四个阶段的狭义上的计算层。 ...

随着近期 TiFlash 开源，有更多的人想理解 TiFlash 是如何构建的。本次分享会让读者对 TiFlash 整体有初步认知，以及在 TiDB 的 HTAP 场景下，存储层 DeltaTree 引擎如何进行优化的设计思路以及其子模块。作者：黄俊深，PingCAP TiFlash 资深研发工程师 一、背景本系列会聚焦在 TiFlash 本身，读者须要有一些对 TiDB 根本的常识。能够通过这三篇文章理解 TiDB 体系里的一些概念《说存储》、《说计算》、《谈调度》。本文的配角 -- TiFlash 是 TiDB HTAP 状态的要害组件，它是 TiKV 的列存扩大，通过 Raft Learner 协定异步复制，但提供与 TiKV 一样的快照隔离反对。咱们用这个架构解决了 HTAP 场景的隔离性以及列存同步的问题。自 5.0 引入 MPP后，也进一步加强了 TiDB 在实时剖析场景下的计算减速能力。上图形容了 TiFlash 整体逻辑模块的划分。咱们能够对照着 TiKV 来看：TiFlash 整体通过 Raft Learner Proxy 接入到 TiDB 的 multi-Raft 体系中；计算层的 MPP 可能在 TiFlash 之间做数据交换，领有更强的剖析计算能力；作为列存引擎，咱们有一个 schema 的模块负责与 TiDB 的表构造进行同步，将 TiKV 同步过去的数据转换为列的模式，并写入到列存引擎中；最上面的一块，是稍后会介绍的列存引擎，咱们将它命名为 DeltaTree 引擎。有继续关注 TiDB 的用户可能之前浏览过 《TiDB 的列式存储引擎是如何实现的？》 这篇文章，随着 TiFlash 开源，也有新的用户想更多地理解 TiFlash 的外部实现。这篇文章会从更靠近代码层面，来介绍 TiFlash 外部实现的一些细节。上面是 TiFlash 内一些重要的模块划分以及它们对应在代码中的地位。在后续的源码解读系列里，会逐步对外面的模块发展介绍。 ...

往年，TiDB 曾经公布了 6.0 和 6.1 两个较大的版本更新，在 6.0 中大幅度增强了 TiDB 的可管理性和可运维性， 6.1 中又进一步晋升了 TiDB 产品的稳定性。为了帮忙更多的用户把新版本中这些“好用”的个性用起来，咱们集结社区的个体智慧，独特创作了《TiDB 6.x in Action》。明天，这本书正式公布啦！ TiDB 6.x in Action 内容概览《TiDB 6.x in Action》分为 TiDB 6.x 原理和个性、TiDB Developer 体验指南、TiDB 6.x 可管理性、TiDB 6.x 内核优化与性能晋升、TiDB 6.x 测评、TiDB 6.x 最佳实际 6 大内容模块，汇聚了 TiDB 6.x 新个性的原理、测评、试用心得等等干货。不论你是 DBA 运维还是利用开发者，如果你正在或有动向应用 TiDB 6.x，这本书都能够给你提供参考和实际指南。 针对 TiDB 6.x 中引入的十几个新个性，比方热点小表缓存，更多算子和函数反对，数据搁置框架（Placement Rules In SQL），TiUniManager ，PingCAP Clinic 等，《TiDB 6.x in Action》中都有独自的章节策动，每个章节都有用户实际文章的收录；针对 4 月份刚刚开源的 TiFlash，电子书专门策动了“TiFlash 源码浏览”章节，帮忙大家理解 TiFlash 背地的设计原理；另外值得关注的是，本书还专门针对利用开发者人群，策动了“TiDB Developer 体验指南”的章节，帮忙用户理解如何基于 TiDB 构建不同语言的应用程序。 ...

本篇文章为 TiDB 查问优化及调优系列的最终篇，次要会集了一些用户常见的 SQL 优化案例，从背景、剖析、影响、倡议、实操几个角度进行解析。对于 SQL 调优原理的介绍见后面章节。 相干浏览： TiDB 查问优化及调优系列（一）TiDB 优化器简介 TiDB 查问优化及调优系列（二）TiDB 查问打算简介 TiDB 查问优化及调优系列（三）慢查问诊断监控及排查 TiDB 查问优化及调优系列（四）查问执行打算的调整及优化原理 注：以下语句及后果根本为过后理论环境所记录的状况，因为版本更新起因，可能和现有格局略有差异，如 count 等价于当初的 estRows. 案例1: Delete 波及数据量过大导致 OOMMySQL [db_stat]> explain delete from t_stat where imp_date<='20200202';+---------------------+--------------+------+------------------------------------------------------+| id | count | task | operator info |+---------------------+--------------+------+------------------------------------------------------+| TableReader_6 | 220895815.00 | root | data:Selection_5 || └─Selection_5 | 220895815.00 | cop | le(db_stat.t_stat.imp_date, "20200202") || └─TableScan_4 | 220895815.00 | cop | table:t_stat, range:[-inf,+inf], keep order:false |+---------------------+--------------+------+------------------------------------------------------+3 rows in set (0.00 sec)MySQL [db_stat]> select count(*) from t_stat where imp_date<='20200202';+-----------+| count(*) |+-----------+| 184340473 |+-----------+1 row in set (17.88 sec)背景大批量清理数据时系统资源耗费高，在 TiDB 节点内存不足时可能导致 OOM ...

TiFlash 初期存在一个辣手的问题：对于简单的小查问，无论减少多少并发，TiFlash 的整机 CPU 使用率都远远不能打满。如下图： 对 TiFlash 和问题自身通过一段时间的理解后，认为方向应该在“公共组件”（全局锁、底层存储、下层服务等）上。在这个方向上做“地毯式”排查后， 终于定位到问题的一个重要起因：高并发下频繁的线程创立和开释， 这会引发线程在创立/开释过程呈现排队和阻塞景象。 因为 TiFlash 的工作模式依赖于启动大量长期新线程去做一些部分计算或者其余的事件， 大量线程创立/开释过程呈现了排队和阻塞景象，导致利用的计算工作也被阻塞了。而且并发越多， 这个问题越重大， 所以 CPU 使用率不再随着并发减少而减少。具体的排查过程， 因为篇幅无限， 本篇就不多赘述了。首先咱们能够结构个简略试验来复现这个问题： 试验复现、验证定义首先定义三种工作模式: wait、 work 、 workOnNewThread wait: while 循环，期待 condition_variable work: while 循环，每次 memcpy 20次(每次 memcpy copy 1000000 bytes)。 workOnNewThread: while 循环，每次申请新的 thread，新 thread 内 memcpy 20次， join 期待线程完结，反复这个过程。 接下来按不同的工作模式组合去做试验。 各试验试验 1：40 个 work 线程 试验 2：1000 个 wait 线程, 40 个 work 线程 试验 3：40 个 workOnNewThread 线程 ...

PingCAP 发表 TiDB Cloud 正式商用，助力寰球企业在云上构建新一代云原生利用。 企业用户能够借助 TiDB Cloud 全托管数据库服务轻松撑持各类翻新业务场景，将企业从后盾的基础设施运维和数据备份等简单工作中解放出来。 2022 年 5 月 11 日，企业级开源分布式数据库厂商 PingCAP 发表 TiDB Cloud 在寰球范畴正式商用。 通过一年多寰球用户和合作伙伴的宽泛测试，TiDB Cloud 明天开始正式面向寰球用户提供全托管的 DBaaS （Database-as-a-Service）服务，反对用户在全托管的数据库上运行要害业务交易和实时剖析工作，并充沛享受云上的性能劣势和业务连续性保障。随着数据驱动的数字化转型过程一直减速，企业的业务增长面临着大规模数据存取和数据孤岛的挑战。TiDB Cloud 提供下一代云原生数据库解决方案，帮忙用户在多云环境下疾速构建云原生的要害利用，无论这些利用是运行在 Amazon Web Services 还是 Google Cloud 下面。 传统数据库曾经无奈反对明天每秒百万级别的交易量，PingCAP 始终致力于解决海量、实时、在线的数据处理与剖析问题，为寰球企业提供新一代数据库，让企业用户在治理海量数据处理的同时激活实时数据分析的能力，TiDB Cloud 进一步升高了企业用户应用 HTAP 实时剖析能力的门槛。<p align="right">——PingCAP 联结创始人兼 CTO 黄东旭</p>TiDB Cloud 具备 TiDB 分布式数据库的所有能力，并针对云端的托管模式提供了很多新的企业级个性，企业用户能够用更低的基础设施老本，更简化的形式来解决简单的业务。 TiDB Cloud 面向企业用户的新个性次要包含以下几个方面： 通过审计日志进步安全性：使企业有能力监督所有用户的操作，以确保其数据的安全性；内置监控和报警核心：帮忙企业在新问题影响业务之前解决这些问题；对 Prometheus 和 Datadog 的反对和整合：为企业提供高效工具来监控和治理 TiDB 集群；继续减少新的区域节点：在 Amazon Web Services 上减少了对印度孟买节点的反对；进一步减少计算能力抉择：为 TiDB 和 TiKV 节点减少了新的 4vCPU 和 16vCPU 选项；通过 TiDB Cloud，PingCAP 正在帮忙用户整合和简化技术栈，让企业用户不再保护低廉而独立的数据库实例。TiDB Cloud 屏蔽了 TiDB 数据库部署、运维和性能调优的复杂性，设置只须要几分钟，从而大大简化了开发人员和 DBA 的工作工作，同时升高了企业的整体老本。 ...

对数据库而言，适合的字符集和规定可能大大晋升使用者运维和剖析的效率。TiDB 从 v4.0 开始反对新 collation 规定，并于 TiDB 6.0 版本进行了更新。本文将深刻解读 Collation 规定在 TiDB 6.0 中的变更和利用。 Ps. 本文已入选 TiDB 6.0 Book Rush，如果你也想分享 6.0 的应用体验，并取得丰富处分，欢送退出咱们！ 引这里的“引”，有两层含意，这第一层是“引言”，从 TiDB v6.0 发版阐明 中能够理解到，TiDB 6.0 引入了很多新个性，同时也引入了新的 发版模型，本文将对 TiDB 6.0 新个性一睹为快。 第二层含意是“抛砖引玉”，开源社区的力量是无穷尽的，心愿有更多人能够参加到开源中来，那么如何参加开源，其实路径远不止提交代码一种，比方，在 AskTUG 社区发问、答复、互动，再如，发现 TiDB 官网文档 有 Bug 或信息不残缺，提出 Issue 和解决方案，又如，参加 TiDB 6.0 Book Rush! 流动，做版本评测、案例文章等等。 默认启用新 Collation 规定TiDB 从 v4.0 开始反对新 collation 规定，在大小写不敏感、口音不敏感、padding 规定上与 MySQL 行为保持一致。TiDB 6.0 引入了新的 Collation 规定，并将默认启用新 Collation 框架。新 Collation 规定已在 TiDB 4.0 引入，但始终都是默认敞开项，只有集群初始化时能力变更。可通过零碎表看到该变量值的设定。 ...

作者：杨家鑫 多点⾼级 DBA ，擅⻓故障剖析与性能优化，喜爱摸索新技术，喜好摄影。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景提⾼ TiDB 可⽤性，须要把多点已有上百T TiDB集群拆分出2套 挑战现有须要拆分的12套TiDB集群的版本多(4.0.9、5.1.1、5.1.2都有)，每个版本拆分⽅法存在不⼀样其中5套TiDB，数据量均超过10T、最⼤的TiDB集群⽬前数据量62T、单TiDB集群备份集⼤，耗费⼤量磁盘空间和带宽资源空间最⼤3套集群 tidb使⽤⽅式多样（每种⽅式拆分⽅法不同），有间接读写tidb，也有mysql->tidb汇总剖析 查问，也有tidb->cdc->上游hive全量备份TiDB在业务⾼峰期是否会产⽣性能影响⼤数据量的拆分数据的⼀致性保障⽅案⽬前TiDB官⽅提供的同步⼯具备： DM全量+增量（该⽅法⽆法⽤于tidb->tidb，适⽤于MySQL->TiDB）BR全量物理备份+CDC增量同步（CDC同步在tidb、tikv节点OOM后修复老本⾼https://github.co m/pingcap/tiflow/issues/3061）BR全量物理备份+binlog增量（相似于MySQL记录所有变更的binlog⽇志，TiDB binlog由 Pump(记录变更⽇志)+Drainer(回放变更⽇志)组成，咱们采⽤该⽅法进⾏全量+增量同步拆分） 备份与复原⼯具BR：https://docs.pingcap.com/zh/t... TiDB Binlog：https://docs.pingcap.com/zh/t... 因TiDB拆分BR全量物理备份+binlog增量波及周期⻓，咱们分为4个阶段进⾏第⼀阶段1、清理现有TiDB集群⽆⽤数据 按⽉分表tidb库有⽆⽤的表，如3个⽉前的xxxx ⽇志表2、降级GZ现有15套TiDB集群（12套TiDB集群须要1分为2）版本⾄5.1.2 趁这次拆分统⼀GZ tidb版本，解决挑战1第⼆阶段1、新机器部署好雷同版本5.1.2TiDB集群 set @@global.tidb_analyze_version = 1;2、⽬的端，源端所有tikv tiflash挂载好NFS，pd节点上装置好BR Exteral storge采⽤腾讯云NFS⽹盘，保障tikv备份⽬的端和还原全量起源端都能在同⼀⽬录，NFS ⽹盘空间⾃动动静减少+限速备份以应答挑战23、独⽴3台机器部署好12套TiDB集群 pump收集binlog(端⼝辨别不同TiDB集群) pump，drainer采⽤独⽴16C, 32G机器保障增量同步最⼤性能 留神：为保障tidb计算节点的可⽤性，需设置ignore-error binlog要害参数（https://docs.pingcap.com/zh/t...） server_configs: tidb: binlog.enable: true binlog.ignore-error: true4、批改pump组件 GC工夫为7天 binlog保留7天保障全量备份->到增量同步过程能接上pump_servers: - host: xxxxx config: gc: 7 #需reload重启tidb节点使记录binlog⽣效5、备份TiDB集群全量数据⾄NFS Backup & Restore 常⻅问题 （https://docs.pingcap.com/zh/t...） 留神：每个TiDB集群在同⼀个NFS建不同备份⽬录 留神：源⽼TiDB集群别离限速(备份前后对读写延迟时间根本⽆影响)进⾏错峰全量备份(存在之前 多个TiDB集群同时备份把NFS 3Gbps⽹络带宽打满状况)以加重对现有TiDB读写、NFS的压⼒以应 对挑战 mkdir -p /tidbbr/0110_dfp chown -R tidb.tidb /tidbbr/0110_dfp #限速进⾏全业务应⽤库备份./br backup full \ --pd "xxxx:2379" \ --storage "local:///tidbbr/0110_dfp" \ --ratelimit 80 \ --log-file /data/dbatemp/0110_backupdfp.log #限速进⾏指定库备份 ./br backup db \ --pd "xxxx:2379" \ --db db_name \ --storage "local:///tidbbr/0110_dfp" \ --ratelimit 80 \ --log-file /data/dbatemp/0110_backupdfp.log 12.30号45T TiDB集群全量备份耗时19h，占⽤空间12T [2021/12/30 09:33:23.768 +08:00] [INFO] [collector.go:66] ["Full backup succes s summary"] [total-ranges=1596156] [ranges-succeed=1596156] [ranges-failed=0] [backup-checksum=3h55m39.743147403s] [backup-fast-checksum=409.352223ms] [bac kup-total-ranges=3137] [total-take=19h12m22.227906678s] [total-kv-size=65.13T B] [average-speed=941.9MB/s] ["backup data size(after compressed)"=12.46TB] [B ackupTS=430115090997182553] [total-kv=337461300978]6、每个新建TiDB集群独自同步⽼TiDB集群⽤⼾明码信息 ...

本章节介绍如何利用 TiDB 提供的系统监控诊断工具，对运行负载中的查问进行排查和诊断。除了上一章节介绍的通过 EXPLAIN 语句来查看诊断查问打算问题外，本章节次要会介绍通过 TiDB Slow Query 慢查问内存表，以及 TiDB Dashboard 的可视化 Statements 性能来监控和诊断慢查问。 Slow Query 慢查问内存表TiDB 默认会启用慢查问日志，并将执行工夫超过规定阈值的 SQL 保留到日志文件。慢查问日志罕用于定位慢查问语句，剖析和解决 SQL 的性能问题。通过零碎表information_schema.slow_query 也能够查看以后 TiDB 节点的慢查问日志，其字段与慢查问日志文件内容统一。TiDB 从 4.0 版本开始又新增了零碎表 information_schema.cluster_slow_query，能够用于查看全副 TiDB 节点的慢查问。 本节将首先简要介绍慢查问日志的格局和字段含意，而后针对上述两种慢查问零碎表给出一些常见的查问示例。 慢查问日志示例及字段阐明上面是一段典型的慢查问日志： # Time: 2019-08-14T09:26:59.487776265+08:00# Txn_start_ts: 410450924122144769# User: root@127.0.0.1# Conn_ID: 3086# Query_time: 1.527627037# Parse_time: 0.000054933# Compile_time: 0.000129729# Process_time: 0.07 Wait_time: 0.002 Backoff_time: 0.002 Request_count: 1 Total_keys: 131073 Process_keys: 131072 Prewrite_time: 0.335415029 Commit_time: 0.032175429 Get_commit_ts_time: 0.000177098 Local_latch_wait_time: 0.106869448 Write_keys: 131072 Write_size: 3538944 Prewrite_region: 1# DB: test# Is_internal: false# Digest: 50a2e32d2abbd6c1764b1b7f2058d428ef2712b029282b776beb9506a365c0f1# Stats: t:414652072816803841# Num_cop_tasks: 1# Cop_proc_avg: 0.07 Cop_proc_p90: 0.07 Cop_proc_max: 0.07 Cop_proc_addr: 172.16.5.87:20171# Cop_wait_avg: 0 Cop_wait_p90: 0 Cop_wait_max: 0 Cop_wait_addr: 172.16.5.87:20171# Mem_max: 525211# Succ: true# Plan_digest: e5f9d9746c756438a13c75ba3eedf601eecf555cdb7ad327d7092bdd041a83e7# Plan: tidb_decode_plan('ZJAwCTMyXzcJMAkyMAlkYXRhOlRhYmxlU2Nhbl82CjEJMTBfNgkxAR0AdAEY1Dp0LCByYW5nZTpbLWluZiwraW5mXSwga2VlcCBvcmRlcjpmYWxzZSwgc3RhdHM6cHNldWRvCg==')insert into t select * from t;以下逐个介绍慢查问日志中各个字段的含意。 ...

背景TiDB 的一键程度伸缩个性，帮忙用户辞别了分库分表查问和运维带来的复杂度，然而在从分库分表计划切换到 TiDB 的过程中，这个复杂度转移到了数据迁徙流程里。TiDB DM 工具为用户提供了分库分表合并迁徙性能。 本篇文章将介绍 DM 外围处理单元 Sync，内容蕴含 binlog 读取、过滤、路由、转换，优化以及执行等逻辑。本文仅形容 DML 的解决逻辑，DDL 相干内容可参考《DM 分库分表 DDL “乐观协调” 模式介绍》、《DM 分库分表 DDL “乐观协调” 模式介绍》。 解决流程 从上图能够大抵理解到 Binlog replication 的逻辑解决流程 1.从 MySQL/MariaDB 或者 relay log 读取 binlog events 2.对 binlog events 进行解决转换 Binlog Filter：依据 binlog 表达式过滤 binlog，通过 filters 配置Routing：依据“库/表”路由规定对“库/表”名进行转换，通过 routes 配置Expression Filter: 依据 SQL 表达式过滤 binlog，通过 expression-filter 配置3.对 DML 执行进行优化 Compactor：将对同一条记录（主键雷同）的多个操作合并成一个操作，通过 syncer.compact 开启Causality：将不同记录（主键不同）进行冲突检测，散发到不同的 group 并发解决Merger：将多条 binlog 合并成一条 DML，通过 syncer.multiple-rows 开启4.将 DML 执行到上游 ...

背景本系列会聚焦在 TiFlash 本身，读者须要有一些对 TiDB 根本的常识。能够通过这三篇文章理解 TiDB 体系里的一些概念《 说存储 》、《 说计算 》、《 谈调度 》。 明天的配角 -- TiFlash 是 TiDB HTAP 状态的要害组件，它是 TiKV 的列存扩大，通过 Raft Learner 协定异步复制，但提供与 TiKV 一样的快照隔离反对。咱们用这个架构解决了 HTAP 场景的隔离性以及列存同步的问题。自 5.0 引入 MPP 后，也进一步加强了 TiDB 在实时剖析场景下的计算减速能力。 上图形容了 TiFlash 整体逻辑模块的划分，通过 Raft Learner Proxy 接入到 TiDB 的 multi-raft 体系中。咱们能够对照着 TiKV 来看：计算层的 MPP 可能在 TiFlash 之间做数据交换，领有更强的剖析计算能力；作为列存引擎，咱们有一个 schema 的模块负责与 TiDB 的表构造进行同步，将 TiKV 同步过去的数据转换为列的模式，并写入到列存引擎中；最上面的一块，是稍后会介绍的列存引擎，咱们将它命名为 DeltaTree 引擎。 有继续关注 TiDB 的用户可能之前浏览过 《TiDB 的列式存储引擎是如何实现的？》 这篇文章，近期随着 TiFlash 开源 ，也有新的用户想更多地理解 TiFlash 的外部实现。这篇文章会从更靠近代码层面，来介绍 TiFlash 外部实现的一些细节。 ...

「TiDB 查问优化及调优」系列文章将通过一些具体的案例，向大家介绍 TiDB 查问及优化相干的原理和利用，在上一篇文章中咱们简要介绍了 TiDB 查问优化器的优化流程。 查问打算（execution plan）展示了数据库执行 SQL 语句的具体步骤，例如通过索引还是全表扫描拜访表中的数据，连贯查问的实现形式和连贯的程序等。查阅及了解 TiDB 的查问打算是查问调优的根底。本文为系列文章的第二篇，将着重介绍 TiDB 查问打算以及如何查看。 算子及 Task在上文的 TiDB 查问优化流程简介中有提到过，TiDB 的查问打算是由一系列的执行算子形成，这些算子是为返回查问后果而执行的特定步骤，例如表扫描算子，聚合算子，Join 算子等，上面以表扫描算子为例，其它算子的具体解释能够参看下文查看执行打算的小结。 执行表扫描（读盘或者读 TiKV Block Cache）操作的算子有如下几类： TableFullScan：全表扫描。TableRangeScan：带有范畴的表数据扫描。TableRowIDScan：依据下层传递下来的 RowID 扫描表数据。时常在索引读操作后检索符合条件的行。IndexFullScan：另一种“全表扫描”，扫的是索引数据，不是表数据。目前 TiDB 的计算工作分为两种不同的 task：cop task 和 root task。Cop task 是指应用 TiKV 中的 Coprocessor 执行的计算工作，root task 是指在 TiDB 中执行的计算工作。 SQL 优化的指标之一是将计算尽可能公开推到 TiKV 中执行。TiKV 中的 Coprocessor 能反对大部分 SQL 内建函数（包含聚合函数和标量函数）、SQL LIMIT 操作、索引扫描和表扫描。然而，所有的 Join 操作都只能作为 root task 在 TiDB 上执行。 利用 EXPLAIN 查看剖析查问打算与其它支流商业数据库一样，TiDB 中能够通过 EXPLAIN 语句返回的后果查看某条 SQL 的执行打算。 ...

Talent Plan 是 PingCAP 联结华东师范大学、华中科技大学、中国科学技术大学、武汉大学和神州数码面向高校和工程师的将来数据库内核人才培养打算。通过结业考核的学员将取得官网认证的证书，并具备进入 TiDB 生态企业交换、实习和工作的机会。 为了让更多学员不会对体系宏大、内容艰深的 Talent Plan 课程望而生畏，或是大功告成，Talent Plan 学习社区推出了 Talent Plan 学习营流动。学习营以线上自学为主，加入学习分享讲座为辅，邀请往届毕业的学员做导师，将本人学习过程中遇到的坑和必要的知识点分享给其余学员，帮忙学员们将工夫用在真正要害的学习上。 Talent Plan KV 2021 学习营学员来自福州大学、华东师范、清华大学、武汉大学、卡内基梅隆大学 、早稻田大学、纽约大学等高校，参加人数达到 400 人，可见大家对数据库常识学习的渴望。Talent Plan 课程有如下 5 个学习门路：Rust 编译原理和实现、实现一个 mini 版本分布式关系型数据库、实现一个 mini 版本分布式KV数据库、参加工业级开源分布式数据库 TiDB 开发、参加工业级开源分布式 KV 数据库 TiKV 开发。 从课程内容上讲，有如下3个系列： 系列 1: 开源合作 TP101: 开源软件简介TP102: 如何应用 Git 和 GithubTP103: 建设一个社区系列 2: Rust编程 TP201: Rust 网络编程TP202: Rust 分布式系统系列 3: 分布式数据库 TP301: 用 Go 语言实现 TinySQL 分布式数据库TP302: 用 Go 语言实现 TinyKV 分布式 KV 数据库学习内容涵盖了SQL 语句基础知识、编译原理前端、DDL 异步变更算法、SQL 优化原理与优化器实现、统计信息与代价估算、Join reorder、执行引擎、物理算子的实现、KV 单机存储引擎（LSM-Tree）、Raft 一致性协定、Percolator 分布式事务模型、 Go语言、 Rust 语言及开源协同工具等方面。 ...

我的项目背景什么是 Apache APISIX？API 网关作为微服务架构中的重要组件，是流量的外围出入口，用于对立解决和业务相干的申请，可无效解决海量申请、歹意拜访等问题，保障业务安全性与稳定性。 作为开源的云原生 API 网关，Apache APISIX 兼具动静、实时、高性能三大劣势，可提供负载平衡、动静上游、灰度公布、服务熔断、鉴权认证、可观测性等丰盛的流量治理性能，帮忙企业疾速、平安地解决 API 和微服务流量，可利用于网关、Kubernetes Ingress 和服务网格等场景。 同时，Apache APISIX 已通过宽泛的生态单干建设起丰盛的社区生态。Apache APISIX 也反对高度定制化，反对 Wasm，可用 Java、Go、Python 等支流计算机语言编写插件。 Apache APISIX 技术架构 Apache APISIX 采纳了数据立体与管制立体拆散的架构形式，通过配置核心接管、下发配置，使得数据立体不会受到管制立体影响。 在此架构中，数据立体负责接管并解决调用方申请，应用 Lua 与 Nginx 动态控制申请流量，可用于治理 API 申请的全生命周期。管制立体则蕴含了 Manager API 和默认配置核心 etcd，可用于治理 API 网关。管理员在拜访并操作控制台时，控制台将调用 Manager API 下发配置到 etcd，借助 etcd watch 机制，配置将在网关中实时失效。 配置核心默认为 etcd，也反对 Consul、Nacos、Eureka 等。etcd 人造反对分布式、高可用，反对集群，并且在 K8s 等畛域有大量的利用实际，使得 APISIX 能够轻松反对毫秒级配置更新、撑持数千网关节点，且网关节点无状态，可任意扩缩容。 etcd 的局限性1. 本身架构问题首先，etcd 基于 BoltDB，容量具备下限 。etcd 的默认存储下限为 2 GB，如果下限要求超过 2 GB，则能够通过 --quota-backend-bytes 标记配置存储，最大可调整至 8 GB。一个 etcd 集群如果有 8 GB 的存储量，则足以服务一个网关，但如果同时服务 N 个 APISIX 集群，容量可能不够用，有可能会带来一些麻烦。 ...

TiDB 有一些性能和其它性能不一样，这类性能能够作为构建其它性能的根底，组合出新的个性，这类性能称之为：Meta Feature。<p align="right">《对于根底软件产品价值的思考形式》 - 黄东旭</p>对一款分布式数据库而言，数据如何扩散存储在不同节点永远是个乏味的话题。你是否有时会冀望能具体控制数据具体存储在哪些节点？ 当你在同一个 TiDB 集群上反对多套业务以降低成本，但又放心混合存储后业务压力相互烦扰当你心愿减少重要数据的正本数，晋升要害业务的可用性和数据可靠性当你心愿把热点数据的 leader 放到高性能的 TiKV 实例上，晋升 OLTP 性能当你心愿实现热冷数据拆散（热数据寄存在高性能介质，冷数据反之），升高存储老本当你心愿在多核心部署下，将数据依照理论地区归属和数据中心地位来寄存，以缩小远距离拜访和传输你兴许曾经晓得，TiDB 应用 Placement Driver 组件来管制正本的调度，它领有基于热点，存储容量等多种调度策略。但这些逻辑以往对于用户都是近似不可控的存在，你无奈控制数据具体如何搁置。而这种控制能力就是 TiDB 6.0 的 Placement Rules in SQL 数据搁置框架心愿赋予用户的。 TiDB 6.0 版本正式提供了基于 SQL 接口的数据搁置框架（Placement Rules in SQL）。它反对针对任意数据提供正本数、角色类型、搁置地位等维度的灵便调度治理能力，这使得在多业务共享集群、跨 AZ 部署等场景下，TiDB 得以提供更灵便的数据管理能力，满足多样的业务诉求。 让咱们来看几个具体的例子。 跨地区部署升高提早设想下你是一个服务供应商，业务遍布寰球，晚期架构为中心化设计，随着业务跨地区发展后，业务拆分全球化部署，核心数据拜访提早高，跨地区流量老本高。随着业务演进，你着手推动数据跨地区部署，以贴近本地业务。你的数据架构有两种模式，本地治理的区域数据和全局拜访的全局配置数据。本地数据更新频次高，数据量大，然而简直没有跨地区拜访的状况。全局配置数据，数据量少，更新频率低，然而全局惟一，须要反对任意地区的拜访，传统的单机数据库或单地区部署数据库无奈满足以上业务诉求。 以下图为例，用户将 TiDB 以跨核心的形式部署在三个数据中心，别离笼罩华北，华东和华南的用户群，让不同区域的用户能够就近拜访本地数据。在以往的版本中，用户确实能够将以跨核心的形式部署 TiDB 集群，但无奈将归属不同用户群的数据寄存在不同的数据中心，只能依照热点和数据量均匀分布的逻辑将数据扩散在不同核心。在高频拜访的状况下，用户拜访很可能会频繁逾越地区接受较高的提早。 通过 Placement Rules In SQL 能力，你设置搁置策略将区域数据的所有正本指定到特定区域的特定机房内，所有的数据存储，治理在本地区内实现，缩小了数据跨地区复制提早，升高流量老本。你须要做的仅仅是，为不同数据中心的节点打上标签，并创立对应的搁置规定： CREATE PLACEMENT POLICY 'east_cn' CONSTRAINTS = "[+region=east_cn]";CREATE PLACEMENT POLICY 'north_cn' CONSTRAINTS = "[+region=north_cn]";并通过 SQL 语句控制数据的搁置，这里以不同城市分区为例： ALTER TABLE orders PARTITION p_hangzhou PLACEMENT POLICY = 'east_cn'；ALTER TABLE orders PARTITION p_beijing PLACEMENT POLICY = 'north_cn'；这样，归属不同城市的订单数据正本将会被「固定」在对应的数据中心。 ...

对于企业级和云数据库，除了性能、可用性和性能等惯例维度外，一个重要维度就是可管理性，可管理性维度会很深地影响用户理论应用数据库的隐性老本。在最新版本中，TiDB 引入了数据搁置框架（Placement Rules In SQL），减少了企业级集群治理组件 TiDB Enterprise Manager ，凋谢了智能诊断服务 PingCAP Clinic 的预览，大幅度增强了作为企业级产品的可管理性，与此同时也退出了诸多云原生数据库所需的基础设施。 温故而知新，本文次要介绍形成 TiDB 可管理性的重要组件之一：TiUP，一款从 TiDB 4.0 版本开始投入使用的 TiDB 部署工具。 TiUP 对于 TiDBer 来说是日常必备工具，所以这篇文章归类为“温故知新”系列，如果您刚接触 TiDB，请先参阅这篇文章：《从马车到电动车，TiDB 部署工具变形记》。 环境阐明本文所波及到的环境、组件版本信息如下： TiDB v5.4.0 TiUP v1.9.3 (2022-03-24 Release) CentOS 7.9 TiUP 简介在各种系统软件和应用软件的装置治理中，包管理器均有着宽泛的利用，包管理工具的呈现大大简化了软件的装置和降级保护工作。例如，简直所有应用 RPM 的 Linux 都会应用 Yum 来进行包治理，而 Anaconda 则能够十分不便地治理 python 的环境和相干软件包。 从 TiDB 4.0 版本开始，TiUP 作为新的工具，承当着包管理器的角色，治理着 TiDB 生态下泛滥的组件，如 TiDB、PD、TiKV 等。用户想要运行 TiDB 生态中任何组件时，只须要执行 TiUP 一行命令即可，相比以前，极大地升高了治理难度。 图 1-TiUP GitHub Commits 趋势 图 2-tiup 源码行数统计(2022-03-24) ...

与其它支流商业数据库一样，TiDB 的查问优化器负责用户及零碎查问的优化，生成无效且高效的执行打算由执行器来执行。而优化器生成的执行打算的优劣间接影响查问的执行效率和性能。「TiDB 查问优化及调优」系列文章将通过一些具体的案例，向大家介绍 TiDB 查问及优化相干的原理和利用。本文为系列文章的第一篇，将简要介绍 TiDB 的查问优化器的优化流程。 TiDB 中常见的逻辑优化规定优化器的优化过程能够简略的看成在一个搜寻问题，即针对一条查问，在由各种可能的执行打算形成的微小搜寻空间内寻找到该查问的最优执行打算。不同的数据库查问优化器依据架构不同，对应的优化流程也有所不同。TiDB 的查问优化流程次要分为逻辑优化和物理优化两局部。 在逻辑优化中，利用关系代数的变换规定进行查问语句表达式的等价变换，并在这个过程中一直减少或修剪可能的打算搜寻空间（例如不同的 join order），最初抉择生成最优的逻辑打算树。在之后的物理优化过程中，对逻辑打算树中的算子节点生成理论执行的物理打算，并评估不同物理打算的实现算法（例如不同的 join 办法）或对象（例如应用不同的索引）的代价，从中选取代价最小的物理打算。 上面别离对逻辑优化和物理优化做简介。 逻辑优化是针对逻辑打算中的逻辑算子进行的优化流程。在介绍逻辑优化规定之前，咱们先简介一下 TiDB 中的几种次要逻辑算子： DataSource：数据源，示意一个源表，如 select * from t 中的 t 。Selection：代表了相应的过滤条件，select * from t where a = 5 中的 where a = 5 。Projection：投影操作，也用于表达式计算， select c, a + b from t 外面的 c 和 a+b 就是投影和表达式计算操作。Join：两个表的连贯操作，select t1.b, t2.c from t1 join t2 on t1.a = t2.a 中的 t1 join t2 on t1.a = t2.a 就是两个表 t1 和 t2 的连贯操作。Join 有内连贯，左连贯，右连贯等多种连贯形式。Selection，Projection，Join（简称 SPJ） 是 3 种最根本的算子。 ...

对于很多现代人来说，在繁忙的工作中，一顿口味不错、能量满满、品质牢靠且疾速不便的汉堡、薯条、炸鸡确实是不错的抉择。更何况快餐中富含的盐、糖、脂肪和碳水化合物也更容易让人产生满足感。 但在享受快餐所带来的高兴时，你是否也曾想过，快餐企业在经营成千盈百家门店的同时是如何做到线上买券、线下提货，在家下单、快递上门，手机下单、门店取货等一系列高级别数字化操作的？ 疫情以来，餐饮行业总体的损失不堪称不惨重，但最先从打击中复原的却是门店数量最多、经营最简单的各大快餐巨头，或者更具体的说，是那些在 DTC 有着更多投入和积攒的快餐企业。以去年双十一为例，多家快餐顶流仅用不到 12 小时就冲破了去年双十一全天的销售额，业务涨势喜人。 那么这个能让泛滥快餐企业趋之若鹜的 DTC 又是何方神圣？DTC（Direct to Customer，即“间接面向消费者”），这是一种重心在线上的、以间接面对消费者为外围指标的经营模式。联合国内生产环境，DTC 强调利用 APP、小程序或其余线上渠道为所有消费者提供 360 度的全方位用户体验。与传统的经营模式相比，DTC 的劣势次要体现在更靠近消费者、关注消费行为、器重消费者生存状态。与此同时，通过逾越经营过程当中的各类中间环节，企业亦可能更简略、更间接的对消费者施加影响并评估成果，进而使企业经营的效率更高、老本更低、成果更间接。 面向海量用户的多渠道交易当然，与任何高级经营模式一样，DTC 策略同样有着不低的施行门槛。DTC 的外围劣势在于间接、高效，合乎互联网时代一般消费者的生产模式，但要实现这些成果，企业不仅要收集海量渠道汇总而来的用户行为信息，更要在实现各类业务操作的同时尽可能快的做到全量数据的实时剖析，并依据剖析后果造成千人千面且随需应变的营销或服务计划。 而对于用户数量数以千万计、每日订单动辄几千万的快餐企业来说，由此造成的数据压力可想而知。 以业务遍布寰球 100 多个国家，领有几万间门店，数亿注册用户，每日解决千万级订单数的某大型连锁快餐品牌为例，全新的 DTC 策略要求企业基于大数据揣测顾客最喜爱的服务，并将其置于小程序的入口地位，使顾客取得千人千面的服务菜单。同时，企业还需利用大数据对小程序或 APP 内不同模块的应用、停留状况进行剖析，实现利用的一直优化。通过对消费者行为的数据分析，企业还能更准确的理解消费者买了什么、花了多少钱、多久来一次、在哪天支付了优惠券、常在哪几家餐厅生产等一系列信息，由此，企业便可通过大数据和算法揣测各类营销流动在哪个地点可能吸引哪些消费者。 要实现这样的业务成果，已经以私有云为外围的整套数据基础架构无论在创新性、灵活性、可靠性和改革主动权等方面体现均不够现实。因而，该企业放弃了原先的私有云架构，从新构建了一套公有云架构。而通过一段时间的运行，这套架构不仅实现了比私有云更低的 TCO，更通过弱小的软件堆栈解决了海量利用的构建、疾速迭代、灰度公布等问题。而更加重要的是，企业通过全新架构的数据库解决了 DTC 策略下数亿用户和每日数千万订单所对应的在线联机交易和实时数据分析的宏大需要，且可能以更轻捷的身姿应答数据量快速增长。 数据平台逻辑架构其中，TiDB 数据库的 OLTP 性能服务于企业订单、领取和供应链等场景，而 HTAP 则对应了 DTC 策略中要害的实时报表和数据分析需要。另一方面，在用户行为一直累积、用户数和业务量一直增长的背景下，数据库中所要存储的数据量也必然快速增长，数据库则必须要在满足前两种性能需要的前提下为数据量的快速增长提供简便、无效、低成本的应答之道。要同时满足这些要求，对于数据库而言是个极大的挑战。 在以往的教训中，无论是以各类 MySQL 为代表的开源数据库还是传统商业数据库，亦或是各大 CSP 推出的云数据库，在数据量宏大且快速增长的状况下，都很难逃脱分库分表的命运。且不说分库分表操作自身所对应的宏大工作量和治理问题，单就跨表、跨区所带来的查问和剖析艰难就会让 DTC 的实际效果大打折扣。 因而，抉择一款可能以分布式、云原生形式运作的全新底层数据库，解脱分库分表所带来的性能、操作和治理弊病就成为了快餐企业践行数字化转型策略的要害一步。而在这家国内连锁快餐巨头的 DTC 策略实际过程中，TiDB 凭借多方面劣势最终担纲重任。 TiDB 是一款企业级开源分布式数据库，与云架构有着人造的高符合度，可能通过集群节点的减少满足企业一直增长的数据量与性能需求，防止分库分表所带来的宏大工作量、操作危险以及昂扬的后续运维老本。与此同时，TiDB 的开源个性和沉闷技术社区也让企业有能力依据需要和利用变动实现疾速、低成本的性能及业务翻新。 另一方面，作为一款反对 HTAP 性能的数据库，TiDB 可在满足在线联机交易需要的根底上提供高性能的实时剖析能力，帮忙企业用一套数据库架构满足 DTC 策略下对实时报表和大规模数据分析的刻薄需要。通过翻新的行列存隔离机制，TiDB 可能在不影响 OLTP 业务性能的前提下进行实时报表汇总和疾速剖析，让企业可能更加专一于 DTC 策略下的数据价值挖掘和业务翻新。 在该快餐企业实现公有云基础架构部署之后，PingCAP 业余服务团队与企业自有技术团队和 ISV 的严密协同下仅用 3 个月工夫便实现了云环境下两套 TiDB 集群的部署、数据迁徙及灰度上线工作。在海量业务零碎和宏大数据量背后仍能放弃如此部署速度，这显然传统数据库所难以企及的。 ...

dbt （data build tool）是一款风行的开源数据转换工具，可能通过 SQL 实现数据转化，将命令转化为表或者视图，晋升数据分析师的工作效率。TiDB 社区在近日推出了 dbt-tidb 插件，实现了 TiDB 和 dbt 的兼容适配。本文将通过一个简略的案例介绍如何通过 dbt 实现 TiDB 中数据的简略剖析。 dbt 次要性能在于转换数据库或数据仓库中的数据，在 E（Extract）、L（Load）、T（Transform） 的流程中，仅负责转换（transform）的过程。 通过 dbt-tidb 插件，数据分析师在应用 TiDB 的过程中，可能通过 SQL 间接建设表单并匹配数据，而无需关注创立 table 或 view 的过程，并且能够直观地看到数据的流动；同时可能使用 dbt 的 Jinja 编写 SQL、测试、包治理等性能，大大晋升工作效率。 （图片起源： https://blog.getdbt.com/what-...） 接下来，我将以 dbt 官网教程 为例，给大家介绍下 TiDB 与 dbt 的联合应用。 本例用到的相干软件及其版本要求： TiDB 5.3 或更高版本dbt 1.0.1 或更高版本dbt-tidb 1.0.0装置dbt 除了本地 CLI 工具外，还反对 dbt Cloud (目前，dbt Cloud 只反对 dbt-lab 官网保护的 adapter)，其中本地 CLI 工具有多种装置形式。咱们这里间接应用 pypi 装置 dbt 和 dbt-tidb 插件。 ...

概览咱们很快乐为大家带来 TiDB 最新版 6.0 的介绍。尽管是一个开源数据库，但 TiDB 的定位始终都是面向企业级和云的数据库，而 TiDB 6.0 也是围绕这个主题而研发的。在最新版本中，咱们大幅度增强了作为企业级产品的可管理性，与此同时也退出了诸多云原生数据库所需的基础设施。 对于企业级和云数据库，除了性能，可用性和性能等惯例维度外，一个重要维度就是可管理性。除了提供必备的「硬」能力以实现用户的技术及业务指标，是否「好用」，是用户做抉择时的重要考量，可管理性维度也会很深地影响用户理论应用数据库的隐性老本。而这点对于云数据库则更为显著，将数据库作为云服务提供，将使得可管理性的重要水平被放大：一个可运维性更好的数据库，在固定的运维和反对资源下，将为用户提供更好的服务。 针对这个方向，TiDB 6.0 引入数据搁置框架（Placement Rules In SQL），减少了企业级集群治理组件 TiDB Enterprise Manager ，凋谢了智能诊断服务 PingCAP Clinic 的预览，大幅增强了生态工具的可运维性，并针对热点问题为用户提供了更多的伎俩。这些致力加在一起，将使用户无论应用的是私有云服务，还是公有部署，都取得体验更平滑和近似的应用体验，让 TiDB 在成熟的企业级云数据库维度更向前迈进。 除此之外，在这一年的工夫内 TiDB 6.0 相较于前序版本也有了长足的提高，修复了 137 个 Issues，并融入了 77 个严苛的实在环境锻炼带来的加强。而社区始终冀望的 TiFlash 开源 也实现了，欢送宽广社区开发者一起参加。 实用于中国出海企业和开发者全面增强可管理性可管理性是数据库的一个重要能力维度：在满足业务需要的前提下，是否灵便易用，将决定了用户技术抉择背地的隐性老本。这种老本可大可小，能够是一句埋怨，也可能会联合人因带来灾难性结果。在最新版本研发过程中，咱们联合了客户和市场反馈，总结了以后的可管理性的问题仍存在的缺失，这蕴含了「简单且不直观的集群的日常治理」、「无奈控制数据的存储地位」、「数据生态套件难于应用」、「面对热点短少解决方案」等多个维度，而 TiDB 6.0 从内核、数据生态套件、加强组件多个方面针对这些问题进行了增强。 自主的数据调度框架让咱们先从内核局部开始。 TiDB 6.0 以 SQL 模式对用户裸露数据调度框架（Placement Rule In SQL）。以往，TiDB 的数据调度对于用户始终都是黑盒，TiDB 自行决定某一个数据块应该存在哪个节点，无论数据中心的物理边界和不同规格机器差别。这使得 TiDB 在多核心，冷热数据拆散和大量写入所需的缓冲隔离等场景下无奈提供灵便的应答。 咱们先看两个乏味的场景： 你有一个业务横跨多个城市，北京、上海和广州都设有数据中心。你心愿将 TiDB 以跨核心的形式部署在这三个数据中心，别离笼罩华北、华东和华南的用户群，让不同区域的用户能够就近拜访数据。在以往的版本中，用户确实能够跨核心的形式部署 TiDB 集群，但却无奈如上述冀望地将归属不同用户群的数据寄存在不同的数据中心，只能任由 TiDB 依照热点和数据量均匀分布的逻辑将数据扩散在不同核心。在高频拜访的状况下，用户拜访很可能会频繁逾越地区进而接受很高的提早。 你心愿用一组导入专用节点专门用于隔离导入数据所带来的性能抖动，而后再将导入完的数据迁回工作节点；或者你心愿用一组低配节点寄存冷数据，承受低频历史数据拜访。临时，还没有特地的伎俩反对这样的用况。 TiDB 6.0 凋谢的数据调度框架提供了针对分区 / 表 / 库级数据在不同标签节点之间的自在搁置接口，用户能够针对某张表、某个数据分区的存储地位做出自定义的抉择。在新版本中，用户能够将一组节点给与标签，并为这组标签定义搁置束缚。例如你将所有位于纽约机房的 TiDB 存储节点定义搁置策略： ...

作者：莫善 某互联网公司高级 DBA。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、前言线上tidb集群都是2.1.[5,7,8,17]，因版本太低，面临诸多问题，比方治理难度大，热点问题，执行打算生效，性能瓶颈，其余已知/未知且无奈解决的问题，当初须要降级至4.0.13版本。在调研后发现，如果原地降级将须要屡次降级【2.1--> 3.0 --> 4.0】，放心原地降级遇到不可逆的故障，更放心的是解决不掉而影响业务，所以通过测试和评估，最终采纳数据迁徙的形式进行降级。 因为应用2.1版本的用户自身比拟少，更别提降级了，所以可参考的迁徙降级文档简直没有，在降级中遇到了很多问题，也踩了很多坑，本文整顿了降级操作流程，并标记每个步骤容易遇到什么问题及解决方案，权当经验交流，避坑指南。本文所有内容/操作命令仅供参考。 因5.0基于MySQL 8.0协定，放心和业务不兼容，也因为5.0+的小版本都还比拟小，放心稳定性，所以就不思考了，过后4.0.13是4.0最新的版本，就选了这个版本。曾经有24套tidb集群实现了从2.1到4.0.13的降级。二、环境介绍1、旧集群环境介绍已有的组件角色数量端口pd35017tidb34000tikv320117alertmanager19093prometheus19100grafana13000vip192.168.1.1004000dnsold.tdb.com4000未列举的组件示意未启用该组件，因历史起因，集群并没有启用pump组件。端口布局也没什么法则预计减少的组件角色数量端口pump323001drainer1240012、旧集群访问信息dnsold.tdb.com vip192.168.1.100:4000rs : 192.168.1.1:4000192.168.1.2:4000192.168.1.3:40003、新集群环境介绍角色数量端口pd313002tidb315002tikv317002ticdc333002alertmanager121002prometheus119002grafana120002vip192.168.1.10015002dnsnew.tdb.com15002端口采纳2+3的格局，前两位是组件编号，后三位示意集群编号。即后三位一样的示意同一个集群，前两位一样示意同一个组件。4、新集群访问信息dnsnew.tdb.com vip192.168.1.100:15002rs : 192.168.1.1:15002192.168.1.2:15002192.168.1.3:15002三、流程介绍1、dba 打印以后连贯tidb的ip列表让主业务方确认是否存在非本业务的ip。确保所有应用该集群的业务都参加进来。2、dba 跟业务确认是否有重连机制。（开启binlog须要重启tidb组件）。3、dba 开启binlog，这步须要滚动重启tidb组件，须要跟业务协商一个工夫窗口。4、dba 部署4.0环境并导入全量数据。5、dba 同步增量数据。6、dba 校验新旧集群数据一致性。7、dba 交付新环境，提供新的域名 + 端口。8、dba 提供只读账户，业务测试，验证业务场景（仅限读，不能写）。9、dba 同步权限。10、切换流量。四、降级操作1、打印旧集群拜访列表ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb1 -P 4000 -ppasswordmysql> select distinct host from information_schema.processlist ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb2 -P 4000 -ppasswordmysql> select distinct host from information_schema.processlist ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb3 -P 4000 -ppasswordmysql> select distinct host from information_schema.processlist登录所有tidb节点，每个节点的输入后果追加到一个文件，而后排序去重进行统计客户端ip2、确认是否有重连机制略3、开启binlog并全量备份这步操作在ansible治理机执行（1）编辑配置文件 ...

Chaos Mesh 最后作为开源分布式数据库 TiDB 的测试平台而创立，是一个多功能混沌工程平台，通过混沌测试验证分布式系统的稳定性。本文以万里平安数据库软件 GreatDB 分布式部署模式为例，介绍了通过 Chaos Mesh 进行混沌测试的全流程。 1. 需要背景与万里平安数据库软件 GreatDB 分布式部署模式介绍1.1 需要背景混沌测试是检测分布式系统不确定性、建设零碎弹性信念的一种十分好的形式，因而咱们采纳开源工具 Chaos Mesh 来做 GreatDB 分布式集群的混沌测试。 1.2 万里平安数据库软件 GreatDB 分布式部署模式介绍万里平安数据库软件 GreatDB 是一款关系型数据库软件，同时反对集中式和分布式的部署形式，本文波及的是分布式部署形式。 分布式部署模式采纳 shared-nothing 架构；通过数据冗余与正本治理确保数据库无单点故障；数据 sharding 与分布式并行计算实现数据库系统高性能；可无限度动静扩大数据节点，满足业务须要。 整体架构如下图所示： 2. 环境筹备2.1 Chaos Mesh 装置在装置 Chaos Mesh 之前请确保曾经事后装置了 helm，docker，并筹备好了一个 kubernetes 环境。 应用 Helm 装置1）在 Helm 仓库中增加 Chaos Mesh 仓库： helm repo add chaos-mesh https://charts.chaos-mesh.org2）查看能够装置的 Chaos Mesh 版本： helm search repo chaos-mesh3）创立装置 Chaos Mesh 的命名空间： kubectl create ns chaos-testing4）在 docker 环境下装置 Chaos Mesh： ...

TiFlash 终于 开源 了，而且不再闭源：咱们选了这个特地的节日开源并做出承诺，心愿能显得更加真挚 :) PingCAP 始终以来对开源这件事件，是有信奉的。这种信奉植根于创始人的情怀，也深深影响了这个旗号下汇聚的所有人。开源自身并不是一种市场策略：远在咱们看清开源到底能带来什么的时候，咱们就有了开源的保持，这也使得咱们的开源精力绝对纯正。作为 TiDB 社区的一个重要力量，咱们和其余社区贡献者一起奉献代码，通过社区用户的应用、打磨，大家独特分享 TiDB 不断进步的红利，没有任何人为阻碍和边界。自在和共赢的理念，也是咱们对技术对开源的倔强。 TiDB 是一款 HTAP 分布式数据库，其中提供 HTAP 能力的重要组成部分是 TiFlash。从原型开发起，因为是一个摸索型的我的项目，一开始咱们并没有想好最终状态和架构（TiFlash 在 2018 年也确实经验了一次彻底翻新重做），为了不引起外界太多探讨，咱们抉择了让 TiFlash 临时闭源，等大体成型了再开源。尽管从一开始咱们就打算开源，但待到真正着手做的时候，咱们发现它曾经欠下了不少「开源债」，显得和 TiDB 骨干心心相印：公布流程没有齐全交融，开源所需的文档缺失，编译体验相当蹩脚，甚至局部代码格调有些俊俏。要还上这些债权，须要投入相当多的工夫和人力。与此同时，产品迭代的压力和无限的资源就成为束缚 TiFlash 开源的最大阻碍。作为将开源当成信奉的团队而言，TiFlash 闭源对咱们来说其实是如鲠在喉。因而，尽管仍有诸多缺失，咱们抉择投入工夫逐渐还债。毕竟，独自就这个引擎而言，咱们也从社区有所取，无论是 ClickHouse 绝佳的 Runtime 根底，还是诸多社区用户提供的实在场景和改良倡议，这些都让 TiFlash 获益无算，能够说没有这些助力，就不会有 TiFlash。 TiFlash 首先受害于开源社区的其余我的项目，除开咱们所应用的各类根底库，最重要的局部是：TiFlash 的框架代码是基于 ClickHouse 的。咱们应用 ClickHouse 的形式是将它当做一个单机的 Compute Runtime 和 Server 框架，并复用了 Storage Interface。针对在线事务数据分析的大指标，咱们退出了事务相干逻辑、MPP 能力和可实时更新的列存引擎，引入 Raft 协定和 MySQL 兼容以融入整个 TiDB 体系。很感激 ClickHouse 为社区提供了一套高性能的计算引擎，对咱们而言，一个好的根底大大减速了 TiFlash 的研发进度。值得一提的是，TiFlash 和 ClickHouse 领有齐全不同的善于场景：TiFlash 齐全偏重于事务性数据的剖析，咱们也并不心愿用户认为 TiFlash 是更好的 ClickHouse。 作为一个年老的引擎，在两年多的工夫里，受到天使用户们容纳和帮忙的同时，咱们也通过近距离聆听用户的声音高速迭代改良产品。这所有也反过来帮忙用户简化了剖析链路的架构，享受实时数据的红利。彼时 TiFlash 虽未开源，却已失去了 TiDB 社区的加持。咱们分明地记得，在晚期版本时，税务系统的敌人和咱们一起测试，尝试优化缴税流程的实时性，虽未胜利落地，但让咱们对系统设计在实在场景上的得失有了第一手体感，进而间接导致了一次重大重构：咱们齐全从新设计了存储层，引入了 Raft Learner 作为复制协定，且决定应用 TiDB-Server 作为对立入口而非 TiSpark，这也是大家今日所见的架构；而随着 TiDB 4.0 一起公布的正式版本，则能够说是齐全仰赖小红书在公布前数月就提供场景和咱们一起摸索，而这个尝试最终胜利落地电商实时看板场景，让交易数据得以实时展示；待到 5.0，从中通有惊无险却时有毛刺的 618，到流量倍增却平平稳稳的双十一，TiFlash 在低压实时场景的体现失去了晋升和验证。而这代表的不仅是寰球当先快递公司的外围业务落地，也不仅是数万 TPS 和数十亿订单的实时监控，更是用户的容纳，信赖和互助。至今咱们都常常会收到客户的私信，说本人某个场景因为 TiFlash 的能力而失去切实的业务收益。每次看到这些可恶的音讯，咱们都会在团队内分享喜悦。能帮忙大家，提供独特的价值，是咱们所谋求的；与此同时，社区的反对，也是产品倒退不可或缺的给养，推动它在更严苛更有价值的场景落地。能够说，没有社区的力量，咱们也无奈向更多人提供更好的产品。而时至今日，开源则是一个全新的渠道，让 TiFlash 能以更深刻的形式和社区互助共赢。 ...

无论在股市还是车市上，新能源汽车早已站在了舞台地方。在一台台爆款新车的背地，是造车新权势们产品力和技术力的强强联手，更是数字营销和直营的绝妙组合。早在 2021 年，造车新权势们就已根本实现了销量的“原始积累”。依据各品牌的官网数据，以“蔚小理”为代表的造车新权势 Top3 年销量均已冲破 9 万台，有限靠近于 10 万台的里程碑。一条汽车产线维持失常运行的盈亏线约在每年 5 万台，而每年近 10 万台的销量则意味着，这些造车新权势的头部企业大概率曾经跨过了产品盈亏线，可能开始在“生产-销售-研发”的正循环中实现自我倒退。当然，“蔚小理”们之所以被称为造车新权势，除了其能源模式之外，另一大重要起因便在于对直营模式的青眼。 新能源汽车，新的直营销售模式相较于传统的 4S 店模式，造车新权势偏爱的直营模式里没有经销商“赚差价”，可能在肯定水平上帮忙车企升高销售和服务老本，还能通过“直面消费者”（Direct To Customer）来疾速取得第一手的市场和用户声音。基于此，车企便可能依据市场反馈疾速调整策略，实现更精准、更灵便的营销，进而疾速关上和占领市场，取得造血能力。显然，在汽车这条成熟、拥挤且竞争者实力超群的赛道上，疾速扩张、疾速应变能力对造车新权势的生存和倒退至关重要。直营模式的劣势浅显易懂，但这并不意味着它的门槛低。相同，即使对于诞生在数字时代的造车新权势来说，直营带来营销能力大幅加强的同时，暴增的数据量也成为了数字化过程中的重大挑战，须要更新、更强的数据技术架构能力安稳应答。那么，造车新权势们如何做好直营之后的市场营销并获得辉煌战果的呢？ 直营背地的数据挑战直营的特点在于车企间接掌控产品销售、服务和社区保护环节，可能取得比传统模式更多维度、更精准的数据。但把握数据只是营销降级的前提，真正弱小的营销还要看车企怎么取得对海量数据的实时剖析能力。以某新权势车企为例，其营销零碎次要由三局部组成；面向门店经理及销售人员的实时报表剖析零碎，面向 C Level 的全新实时业务决策零碎，以及并行运行的原有 BI 零碎。三大零碎依据性能和服务的用户属性不同，别离进行不同维度的信息实时展现和剖析，其根底数据则蕴含全国销售网的销售数据、用户数据、社区数据以及车辆自身的车机数据等四大类。显然，在保障实时性的前提下，如何会集海量数据并实现无效的治理和剖析是整套零碎施展最大效力的难点所在。包含 MySQL、Oracle 在内的单机 OLTP 数据库尽管可能在分门别类的数据“收纳”工作中展现出很好的性能，但在面对多源数据汇聚、海量数据量下的实时剖析工作，他们却无奈无效胜任。传统计划通常采纳 Hadoop 、Hive 等大数据离线数据分析平台，不管从技术角度还是运维角度都比拟重，且剖析解决工夫往往无数小时甚至数天的提早，时效性较差，无奈应答日息万变的商业竞争环境。不过这所有都产生在引入 TiDB 之前。 实时数据分析平台的构建起初，该车企只是抱着技术摸索的心态在虚拟机上部署了一套 TiDB 数据库，并搭建了简略的前端、展现页面和 SQL 语句以实现局部数据的聚合、检索性能。通过简略试用之后，这套运行在虚机上的 TiDB 展现出了良好的稳定性和性能。由此，车企也积攒了对 TiDB 的良好印象和根底应用教训。以 HTAP 为特色的新一代数据库，可能充分发挥一栈式数据服务平台劣势，行存引擎 TiKV + 列存引擎 TiFlash 能够帮忙该企业在同一份数据源上同时反对 OLTP 与 OLAP 业务负载，简化数据服务架构，进步零碎灵活性。 2021 年中，该车企则迎来了销量暴发，单月销量冲破万台，数据分析系统压力陡增。对 TiDB 的良好印象和事实的业务压力最终让车企下定决心，将负责外围数据分析的大数据系统切换到 TiDB。新数据库运行在物理集群上，通过 DM 数据同步工具实现与各个分类 MySQL 数据库之间的高效数据同步。在全新的实时业务决策场景中，TiDB 可能反对简单 SQL 语句，最长的 SQL 甚至超过 1000 行，从而构建数据分析逻辑。而在面向销售人员的简略查问和剖析场景中，TiDB 则展现出了十分快的响应速度。当然，并行运行的原有 BI 零碎也可能从 TiDB 中高效取得数据；既迎新，也利旧。由此，新部署的 TiDB 集群成为了一个高性能的数据中台：同时反对了面向 C Level 的实时业务决策零碎和原有 BI 零碎，并且面向门店及销售提供实时的数据报表及查问性能。理论生产和运维过程中，TiDB 在性能、可靠性、易维护性、可扩展性等方面均展现出全面劣势。在体验到实时业务决策零碎带来的便利性后，该车企还将车辆生产环节中的数据也同步至 TiDB 集群中，通过实时剖析决策，大大缩短了从下单到提车的整个交付工夫，解决了汽车制作中最难的供应链效力问题。通过部署新一代 TiDB 分布式数据库，该车企应用本人编写的前端及 SQL 语句构建了一套性能弱小、可能服务多种角色的实时数据分析平台，圆满撑持了 2021 年的销量扩张和营销能力增长。而以往通过传统伎俩构建这样的实时数据分析平台，不仅价格不菲，零碎实现和前期运维也极为简单。因为 TiDB 齐全开源，车企既无需放心被繁多数据库绑定，也能够在沉闷的生态加持下开展对多样数据利用的积极探索。 ...

数据库最早能够追溯到上世纪 60 年代，和当代电子计算机属于同一时代的产物。从问世那一天起，数据库就承当着向上撑持应用软件，向下调动系统资源的性能，在 IT 架构中处于外围地位，被誉为“软件行业皇冠上的明珠”。但国内数据库畛域研发人才紧缺，重大影响着数据库产业倒退。 那么，数据库人才到底为什么会短缺？又该如何解决数据库人才面临的挑战？带着这些问题，咱们采访了 PingCAP 高校关系与人才生态负责人王岩广老师，请他分享 PingCAP 在数据库人才畛域的思考与尝试。 数据库的人才挑战 以国内的人才需求情况为例，高校毕业科班出身并投身于分布式数据库的开发者，每年只有 6000 — 7000 人。但对应到数据库行业，对人才的需求量到底有多大呢？王岩广老师给出了一个数字—— 10倍，也就是每年须要 60000 — 70000 人。这个缺口不容小觑，如果不加以器重的话，数据库开发者就会面临新鲜血液短缺，甚至不足继续能源，面临“后继无人”的地步。目前，国内高校中对于数据库的课程设置，还是以数据库应用及基于 SQL Server、MySQL 或 Oracle 等数据库做利用开发为主。从课程角度看，以关系型数据库为例，次要分为三类：一类是对于数据库表、数据的组织形式，如集合论、关系代数、关系范式、SQL 语言；一类是对于 DBMS 实现的课程；还有一类是工业界数据库的治理运维课程。然而，在近十几年中，中国互联网经济带来的对于数据管理复杂度的需要，曾经催生了对更简单 DBMS 内核实现人才的需要。但社会需要传导回高校教育尚需工夫。可能有人会问，除高校外，社会中也存在各种各样的的数据库技术培训机构，他们为什么不能填补这个人才空缺呢？这次要是因为绝对于数据库内核开发岗位而言，对数据库应用或治理运维的岗位需要总量更大，社会培训机构广泛瞄准的必定是更大空间的数据库运维市场，而对于 DBMS 开发这样常识门路很深，且须要把握编译原理、操作系统、分布式系统等基础知识，同时从整体人才需求量而言又不像前者这样大的课程不足投入能源。 PingCAP Talent Plan 的缘起 2018 年，PingCAP 创始人团队的刘奇和崔秋一起去美国湾区，加入了一个数据库行业会议。他们留神到一个令其印象粗浅的景象，那个会议里有很多讲师是从教育界和学术界来的，包含一些传授、讲师甚至博士生。他们发现，这些人的实践程度、科研程度、工程程度都很厉害，这件事件对他们触动很大，于是回国后他们敏锐地决定要与高校开启一些科研单干。这就是 Talent Plan 的缘起。为了解决数据库内核人才挑战，PingCAP 推出了开源数据库开发课程 ——Talent Plan 。通过联结优良高校和企业，面向全国各高校数据库开发人才培养打造最佳实际平台，通过结业考核的学员还将取得官网认证的结业证书。“分布式数据库和分布式系统都是比拟新的畛域，回想起当年刚学习这些内容时最大的艰难就是没有零碎的实践+循序渐进的实际联合的平台和课程，只能一边看零散的材料一边在工作中摸索，于是就有了做 Talent Plan 的想法，很快乐看到过后的初心当初变成了事实。” —— PingCAP 联结创始人兼 CTO 黄东旭与高校进行科研单干，须要学生可能了解工业界产品，Talent Plan 就成为将学术界与工业界连接起来的那座桥梁。与 PingCAP 有单干关系的学校学生都能通过 Talent Plan 疾速地理解 TiDB 等产品。2018 年，一个迷你的 Talent Plan 0.1 版本开设起来了。从 0.1、0.2 到 1.0、2.0， Talent Plan 的门路模块、资料一直减少，一直迭代降级，目前学员曾经累计超过 2000 多名。 ...

业务挑战在国内业务上，因为面临的市场多，产品和业务简单多样，投放渠道多，引流费用高，因而须要对业务和产品做出更精细化的治理和优化，满足市场投放和经营须要，升高整体老本，进步经营效率与转化率。为此，携程专门研发了国内业务动静实时标签化解决平台（以下简称 CDP ）。 携程旅行的数据具备起源宽泛、形式多样、离线数据处理与在线数据处理兼有等特点，如何通过系统对这些数据进行采集、治理、加工，造成满足业务零碎、经营、市场需求的数据和标签。解决好的数据须要立即使用到业务零碎、EMD、PUSH 等应用场景中，对数据处理系统的时效性、准确性、稳定性以及灵活性提出了更高要求。 为了解决以上问题，CDP 零碎必须晋升数据处理能力。过来传统计划是通过数仓进行 T+1 计算，再导入 ES 集群存储，前端通过传入查问条件，组装 ES 查问条件查问符合条件的数据。携程曾经上线的标签有上百个，有查问应用的超过 50% ，因为该计划是离线计算，所以数据时效性差，依赖底层离线平台计算和 ES 索引，查问响应速度较慢。 解决方案CDP 心愿在数据处理的过程中能晋升数据处理时效性，同时满足业务灵活性的要求，对于数据处理逻辑、数据更新逻辑，能够通过零碎动静配置规定的形式来生产音讯数据（Kafka 或 QMQ）动静更新标签，业务层只需关怀数据筛选逻辑及条件查问。 依据业务需要，业务数据标签筛选次要分为两大场景： 实时触发场景。依据业务须要，配置动静规定，实时订阅业务零碎的变更音讯，筛选出满足动静规定条件的数据，通过音讯的形式推送到上游业务方； 标签长久化场景。将业务零碎的实时业务变更音讯依照业务须要，加工成业务相干的特色数据，长久化存储到存储引擎。业务依据须要组装查问条件查问引擎数据，次要有 OLAP （剖析类）与 OLTP （在线查问）两大类查问。 基于以上需要，CDP 流式数据采纳类 Kappa 架构，标签长久化采纳类 Lambda 架构，如下图所示： 其中，标签长久化场景须要解决业务标签的长久化存储、更新、查问服务，携程采纳了 TiDB 来存储业务长久化的标签，并采纳实时触发场景中的动静规定配置形式生产业务零碎数据变更音讯，保障业务长久化标签的时效性，通过 TiDB 对 OLTP 和 OLAP 不同场景查问个性的反对，来满足不同业务场景中拜访业务特色数据的须要。 零碎借鉴了 Lambda 数据处理架构的思维，新增数据依据起源不同别离发送到不同的通道中，历史全量数据通过数据批处理引擎（如 Spark）转换完，批量写入到数据长久化存储引擎 TiDB 中。增量数据业务利用以音讯模式发送到 Kafka 或 QMQ 音讯队列，将数据依照标签长久化的逻辑规定解决实现，增量写入到长久化存储引擎 TiDB，以此解决数据的时效性问题。 TiDB 同时具备两大长久化存储形式，一种是行存 TiKV ，能够反对 OLTP 场景，另一种是列存 TiFlash ，能够反对 OLAP 场景。TiDB 数据存储外部主动解决这两个引擎的数据同步问题，客户端查问依据本身须要抉择查问形式。同时，TiDB 还能保障两种形式有着良好的隔离性，并兼顾数据强一致性，杰出地解决了 HTAP 场景的隔离性及列存同步问题。 ...

对于后端开发者来说，一款好用的框架可能大大晋升利用的开发效率。为了升高开发者应用 TiDB 的门槛，不便开发者疾速连贯到 TiDB，咱们也在和合作伙伴一起，逐步完善面向支流开发语言和框架的连贯反对。 近日，Facebook 开源的 Golang 实体框架 Ent 实现了对 TiDB 数据库的反对。Ent 是一款易于构建和保护应用程序与大数据模型的框架。具备以下特点： Schema 即代码：能将任何数据库表建模为 Go 对象；轻松地遍历任何图形 ：能够轻松地运行查问、聚合和遍历任何图形构造；动态类型和显式 API：应用代码生成动态类型和显式 API，查问数据更加便捷；多存储驱动程序：反对 MySQL、PostgreSQL、SQLite、Gremlin，当初也曾经反对了 TiDB；可扩大：易于扩大和应用 Go 模板自定义。上面通过一个 Hello World 的利用示例，来看下如何疾速实现一个基于 Ent + TiDB 的利用。 Hello World 利用示例1.用 Docker 在本地启动一个 TiDB Server docker run -p 4000:4000 pingcap/tidb当初你应该有一个运行的 TiDB 实例，凋谢了 4000 端口监听。 2.在本地拷贝 hello world 的示例 repo git clone https://github.com/hedwigz/tidb-hello-world.git在这个示例 repo 中咱们定义了一个简略的 User schema go title="ent/schema/user.go" func (User) Fields() []ent.Field { return []ent.Field{ field.Time("created_at"). Default(time.Now), field.String("name"), field.Int("age"), } }而后，连贯 Ent 和 TiDB： ...

嘀……“请问您有多点会员吗？” 对于常常去物美、麦德龙等大型连锁超市的人来说，扫码的嘀嘀声和随后的这句话应该是十分相熟的。但作为业余的商超数字化零碎供应商，多点所做的绝不只是收银这般简略。在全新业财一体策略的撑持下，多点的 Dmall OS 不仅是超市顾客每天都能用到的零碎，也是 CFO 和 CEO 每天都会关注的零碎。 业财一体为企业带来的美好图景多点是面向新批发的数字解决方案提供商，旗下的 Dmall OS 产品是统合了人、货、场的全场景云化解决方案，也是多点的拳头产品。以此为根底，多点的下一步则是为批发企业提供具备业财一体能力的经营大脑。 以往，企业须要通过大量基于场景和流程的业务利用来实现业务数字化，但与此同时，企业管理层更关怀的财务数据却由运行逻辑、统计口径、统计办法齐全不同的财务零碎产生。这种业务与财务的互相脱节也使得企业很难疾速把握当期经营数据，无奈通过及时的财务反馈来调整业务策略和经营方针。而所谓业财一体便是要突破两套零碎之间的重重隔膜，让业务层面的变动间接反馈在实时进行的财务统计当中，使企业在强烈的市场竞争中取得灵便的身段、矫健的本领。 从实现之后的成果来看，业财一体对于企业来说足够美好，但在理论的零碎构建过程中，业财一体的实现却充斥挑战。 以 Dmall OS 面向的零售商超行业为例，其业务端对应的是海量的交易笔数和宏大且扩散的门店数量。要为商品治理、收银、会员等根底业务提供反对，Dmall OS 须要装备一套弱小的 OLTP 数据库。而其财务端所需的各类剖析性能却是典型 OLAP 利用，因而，在理顺业务逻辑、实现零碎对接之前，大量数据还需实现从 OLTP 到 OLAP 的数据导入。而业财一体概念中要害的实时性要求则意味着，Dmall OS 一边要保障 OLTP 数据库的性能、可靠性，另一边还要实现数据的实时导入、实时同步、实时剖析，实现难度可想而知。 看懂了这层难点，咱们也就很容易了解为何很多企业的业财一体无奈实时，只能异步了。 不过 Dmall OS 曾经跨过了这些技术门槛并取得了物美、麦德龙等一系列行业顶尖用户的认可和青眼。而在底层帮忙 Dmall OS 实现业财一体这一要害转型的赋能工具正是 TiDB。 PingCAP 的 TiDB，多点的业财一体其实，多点所遇到的数据库挑战并不常见。 一方面，以收银、库存等为代表的根底业务对应了典型的 OLTP 数据库利用，而超市业态宏大的销售额则让这部分业务对性能、稳定性等有着颇高的要求。在满足这部分业务需要时，和大多数互联网企业一样，多点在开始之初抉择了开源的 MySQL，性能不错、生态丰盛、人才充分且二次开发不便是其最大劣势。但作为一种诞生自 90 年代的技术，MySQL 仍旧无奈在“数据量增长所导致的性能降落”和“通过简单且高风险的分库分表操作来保障性能”之间获得良好的均衡。 另一方面，为实现业财一体性能，多点 Dmall OS 还须要一套可能为报表合并及海量数据分析提供撑持的高性能 OLAP 数据库。并且，为了放弃软件堆栈的整体开源和业务人员的操作连贯性，新数据库同样须要是开源的，并且最好可能与 MySQL 有着相似的操作逻辑和语法。 当然，如果多点只是用另外一套 OLAP 数据库来满足财务剖析需要并承当双数据库所带来的运维老本升高的话，那么故事到此就完结了。但 TiDB 给多点提供的却是一条齐全不同的门路。 作为一款具备 HTAP 能力的数据库，TiDB 能够同时满足 OLTP 和 OLAP 两种不同利用的需要。在面对多点业财一体中的 OLAP 需要时，TiDB 可能提供高性能的剖析能力，满足业财一体在财务端的报表合并及剖析需要。借助弱小的 TiFlash 列式存储引擎，TiDB 在面对 6.8 亿行大表全表聚合查问时仅需 5 秒左右便能失去后果，40 亿行超大表全表聚合仅 38 秒左右，由此多点的 OLAP 业务也达到了实时级别。 ...

一、TiDB4PG的诞生在去年的时候，咱们开启了一个小我的项目，基于国内比拟火的开源分布式数据库TiDB进行革新。TiDB自身是高度兼容MySQL协定，你能够在应用TiDB的时候将其视作MySQL，根本的语法，性能，包含一些MySQL的生态工具都能够间接应用。所以咱们想将一些企业应用搬迁到TiDB上享受分布式数据库带来的劣势，然而企业级的利用上层数据库不仅仅只有MySQL，还有PgSQL和Oracle等其余数据库，这使得迁徙工作量非常宏大。为此咱们更心愿TiDB也可能兼容其余的罕用数据库协定，例如PgSQL，于是咱们创立了 TiDB4PG 的开源我的项目。TiDB for PostgreSQL 是咱们基于 TiDB 源码批改的一款满足 PostgreSQL 协定的数据库。为了让基于 PostgreSQL 的零碎可能在不批改自身业务代码的前提下，疾速的迁徙到分布式数据库上。对于TiDB4PG的具体背景文章可翻阅 https://zhuanlan.zhihu.com/p/...二、降级过程TiDB4PG 最后开始做的时候，抉择的是过后比拟新的版本4.0.11，也是咱们用的比较稳定的一版。然而万万没想到，TiDB版本迭代速度，远超乎咱们的设想，一年不到，TiDB版本就给推到5.3了。在5.3的版本，TiDB自身的性能和性能都有肯定的晋升，所以多方面考略后，所以多方面的思考下，咱们决定将TiDB4PG中的TiDB版本升级到5.3（刚降级完一天不到，TiDB推出了5.4版本）。 最早在改代码的时候就思考过降级的问题，基于TiDB对于PgSQL的协定兼容的开发，对于TiDB自身代码的入侵是十分大的，整个协定层都得替换掉，Session这一块做的改变较多，同时也会影响到打算的结构和执行。次要还是数据库系统自身的耦合非常的高，整个改变下来，并不是写几个包去替换一下就能解决的，所以被咱们批改后的分支，再想要去把TiDB主分支合过去，是十分困难的。当然，我也是尝试了一下，强行将5.3的代码Merge到TiDB4PG，从上面图中能够看到，有2959个文件的更改，其中存在抵触的文件有上百个，这要一个一个修复起来，工作量能够说是十分的大。 在衡量一段时间后，咱们最终决定用一个更为简略的办法来实现这一次的降级，那就是在TiDB 5.3.0 版本代码上将咱们TiDB4PG实现的代码再从新实现一次。这种办法的工作量就大大减小了，一是因为TiDB4PG中改变的代码都是一块一块的，能够间接复制搬运过来应用。二是TiDB代码尽管迭代快，常常重构，但就协定和较下层的代码改变要少很多，所以搬运时，简略看一下搬运地位的代码改变，解决抵触就能够胜利跑通。并且这一次降级，咱们把和PgSQL相干的代码都抽出来做了独自的文件进行寄存，不便前期代码的学习和保护。 三、性能测试对于降级之后的TiDB4PG 5.3.0 版本，咱们做了相干的性能比照测试，将TiDB 4.0.11，TiDB4PG 4.0.11，TiDB 5.3.0 和 TiDB4PG 5.3.0 四个版本再对立的集群配置与硬件环境进行Sysbench 压测，次要目标依然是确保，降级之后的TiDB4PG在性能上与TiDB 5.3.0保持一致，同时也顺带测试了TiDB 5.3.0版本比照4.0.11版本性能有多少的晋升。咱们拿了read, insert 和 update 蕴含读写的三种脚本简略的跑了四个版本的性能压测比照，色彩对应TiDB 4.0.11(蓝色)，TiDB 5.3.0(绿色)，TiDB4PG 4.0.11(黄色)，TiDB4PG 5.3.0(红色)。当然这个比照不是为了测试几个版本的性能极限等，重点是测试性能的比照和绝对的晋升，所以具体的QPS和TPS数据不具备任何意义。 通过比照图，可能很清晰的看进去，5.3.0版本整体较4.0.11的性能晋升有20%-40%，并且TiDB和TiDB4PG在雷同版本下性能都是差不多的，所以兼容的代码改变对于性能上简直没有影响。 四、数据迁徙实现了TiDB4PG 4.0.11 到 5.3.0 版本的降级，就存在一个问题，之前集群的数据，如何齐全迁徙到 5.3.0 版本的集群中？首先须要明确一点的是TiDB的整体架构，一共是有三个次要组件：TiDB-Server, PD-Server 和 TiKV-Server, 而TiDB4PG的革新仅仅只批改了TiDB-Server的代码逻辑，也就是SQL解决层逻辑。那么最重要的点在于，大家都理解 TiDB-Server 是无状态的，同理，TiDB4PG-Server 自身也是无状态的。依据这一点，在TiDB4PG的集群中，TiDB-Server和TiDB4PG-Server是能够共存的，你既能够应用TiDB4PG的PG协定和解决层反对，同样也能够应用TiDB的MySQL协定层。 所以在数据迁徙和备份的策略中，你能够应用TiDB本来就反对的逻辑备份工具和物理备份工具。例如 Dumpling&Lightning 和 Backuo&Restore。这两个工具是通过测试验证的，然而倡议应用逻辑备份，因为在测试BR的过程中，咱们遇到了版本问题，须要先用BR v4.0备份4.0.11的集群，再用BR v5.0复原到5.3的集群中，操作比较复杂。 通过咱们的迁徙教训，也如下面的剖析所言，TiDB4PG集群从某种意义上同样是一个TiDB集群，如果在TiDB4PG集群中启动一个TiDB-Server节点，就能够兼容很多TiDB生态工具。甚至如果某些生态工具是间接跳过TiDB-Server，拜访PD-Server 或者TiKV-Server，那么实践上都是能够间接应用的。所以像DM，Binlog和TiCDC这一类工具都是能够在TiDB4PG集群中应用的，当然这些目前还没有进行理论测试。 五、总结 通过下面剖析，整体在TiDB4PG 从v4.0.11 降级到 v5.3.0 一共有两个方面晋升，性能和性能，简略列举一下TiDB4PG v5.3.0 较 4.0.11晋升的几点： ...

数据库调优能够使数据库利用运行得更快，但对于很多人来说，对数据库内核进行调优是一项很有挑战的“技术活”，是只属于少部分内核研发们的“游戏”。但即便是他们，对数据库内核进行性能调优，也充斥了不确定性，它须要综合思考各种简单因素，如硬件层面的 CPU、 I/O、 内存和网络，以及软件层面对于操作系统、中间件、数据库参数等配置，还有运行在数据库上的各种查问和命令等。在本次 Hackathon 2021 较量中，TPC 战队就实现了这一项“挑战”，采纳 bottom-up 的设计思路，更好地利用硬件资源，应用 TPC (thread-per-core) 线程模型优化了 TiKV 的写入性能、性能稳定性和自适应能力。TPC 战队也凭借这一硬核我的项目一举斩获了三等奖与技术后劲奖。 “该我的项目是本届 Hackathon 中最硬核的我的项目，我给了十分高的分数。 TPC 在其中做了十分多的工作，我预感到后续落地的难度，他们用了 io uring，不过貌似也遇到了不少的坑，前面也能够抉择 AIO 或者独自的异步线程机制。因为用了新的 raft engine（这个会在 TiDB 5.4 GA），也很不便做 parallel log write，充分利用多队列 IO 个性。这个个性在 Cloud 下面也是很要害的，因为 EBS 这些盘单线程写入 IOPS 其实真不高。另外，我看他们前面还会去掉 KV RocksDB 的 WAL，这样几个线程池就真能合并，只做计算操作，IO 操作都齐全变成异步了。”——评委唐刘 TPC 战队由来自 TiDB 分布式事务研发团队的陈奕霖与赵磊组成，其中，陈奕霖从 2019 年就加入 TiDB Hackathon ，并凭借线程池我的项目拿了当年的一等奖，而彼时他还是一名刚刚进入 PingCAP 的实习生。现在已毕业的他，留在 PingCAP 持续做事务相干的研发工作，曾经是一名 TiDB Hackathon 老选手了。 TiDB Hackathon 的魅力 陈奕霖：其实对于 PingCAPer 而言， Hackathon 是一个发现更多可能性的机会。咱们平时工作中都有着很多紧迫的我的项目，没机会摸索 TiDB 更多新的可能性，Hackathon 就给予这样的机会。在平时的工作场景中，咱们常常会产生一些想法，但没机会去尝试。 在 Hackathon 中就能够将这些想法实际进去，并通过 DEMO 展现它的成果与后劲，如果实现得好，最初还有可能落地进入生产代码。 ...

在 TiDB Hackathon 2021 赛事中，没有错过任何一届赛事的元老级选手王鹏翰再次得奖，也是继滑滑蛋之后，又一支男女朋友并肩参赛的队伍。 王鹏翰目前工作于思科旗下做利用性能治理的公司 AppDynamics，次要从事日志搜索引擎的研发和可观测性相干的一些工作。陈思雨是 PingCAP Chaos Mesh 团队的研发。 这次的参赛我的项目 Collie Diagnosing Platform，是一个集故障场景信息收集、UI 在线察看剖析、机器学习辅助诊断于一身的故障诊断剖析解决平台。联合了两人在工作中的理论场景，摸索了将来 3-5 年 DBA 和运维人员的工作形式，评委们给予了十分高的评估和期待，拿下了本届 Hackathon 的三等奖。 我的项目意义重大，让 DBA 在剖析问题时，面对那么多 Metrics，不再那么头大。 ——多点 Dmall 数据库团队负责人冯光普点评 数据库自治是畛域的重要方向，参赛团队在实践和工程实际方面都做的比拟好，后续能够进一步对标阿里云的 DAS 产品进行改良欠缺，将补救这一畛域我的项目在开源方面的空白。 ——美团数据库研发核心负责人李凯点评 对于团队Q：这个队名的由来有什么故事？ 陈思雨： 队名来自于 Dota 的一个语音包，在游戏里如果队友做什么比拟蠢的操作的时候，播放下这条语音就达到成果了。 能够通过这条视频领会一下： https://www.bilibili.com/vide... Q：两位都是 Hackathon 的老选手了，Hackathon 对你们的吸引力是什么呢？ 王鹏翰： 对我来说 Hackathon 就是进行一个 deadline 的设置，逼着你在很短时间内学大量的货色。原本我很早就想去学习一下如何用机器学习做一些根因性剖析相干的货色。然而曾经想了一年，实际上只看了一点点。在 Hackathon 中，就能够在很短的工夫内理解它并且把它应用起来。有一个 deadline 就会逼迫你疾速去学习，这个时候学习效率十分高，睡觉的时候满脑子都在想着这个中央还能怎么优化一下，那个中央还怎么搞。当然，顺便还能拿到一点奖金。 陈思雨： 跟他差不多。另外，在 Hackathon 里还能看到很多不一样的 idea。 我的项目灵感Q：你们最后为什么会想到要做这样一个我的项目的？能分享下你们的灵感是什么吗？ 王鹏翰： 咱们前两年参赛基本上都是在做 FDW，就是给 TiDB 接一个通用的内部数据源，往年的一等奖我的项目从某种意义上来说也是内部数据源的一种。感觉曾经做得有点心神憔悴了，那些 Hard Code 的性能对于咱们这种老年人来说，无论是脑力还是膂力都曾经跟不上了，往年就只能在搞花活的方向去另辟蹊径。 我找我的项目灵感的一个外围点是去挖掘身边实在遇到的一些状况，试图抽取出一个通用性的问题，而后去想如何通过工具或者方法论把它高效地解决掉。包含去年的 idea 如何写出一份优雅的文档，往年的 idea 如何疾速地发现故障和诊断故障，都跟工作是非亲非故的。 ...

前言TiDB 从 4.0 开始推出 TiUP 对 TiDB 集群进行装置部署和运维操作，极大水平的升高了 TiDB 集群的管控复杂度。然而 TiUP 作为一款命令行工具依然无奈齐全满足很多人的需要，能不能再简略点呀？能不能有个UI界面操作下呀？能不能有个图片看看集群状况呀？能不能一键就实现部署啊？能不能点点点就能主动数据迁徙和备份还原等等等？ 甲方的需要总是那么的变态但又显得如同很正当的样子，终于 PingCAP 发表要推出一款 TiDB 治理的界面工具了 —— TiEM，上述的需要如同真的就实现了。 于是满怀好奇和期待的我，立马通过官网渠道收回了试用申请！很快啊，拉群，发安装包，手把手教学，几天不到，就实现了整个TiEM的试用体验。包含装置部署TiEM工具，导入配置，一键部署，集群操作，数据迁徙备份等等，体验还是相当不错滴！ 所以上面给大家分享一下 TiEM 工具的体验过程。 TiEM架构TiEM是反对在线和离线装置的，然而因为目前还没有凋谢相干的地址，所以试用版是发的gz压缩包，还包含配套文件。整个文件900M左右。   装置部署的具体过程这里就不一一截图详述了，间接看看部署后的EM架构。   TiEM尽管只是一个可视化TiDB集群管理工具，然而自身的架构和TiDB相似，蕴含十分多的组件，治理TiEM就感觉像在治理TiDB集群一样。能够看进去TiEM的指标可远远不只是一个管理工具这么简略，将来必定会依据需要，增加越来越多的组件和服务。 目前TiEM集群一共蕴含AlterManager，Cluster-Server，Elasticsearch，File-Server，Filebeat，OpenAPI-Server，Jaeger，Kibana，Nginx，Grafana和 Prometheus等11个组件，看名字都是十分眼生的一些组件。 能够将其划分成三个次要局部： Cluster-Server，File-Server和 OpenAPI-Server 组成的TIEM自身的主体服务，能够了解成用于对其余组件进行封装集成，对立治理的服务。Elasticsearch，Filebeat 和 Kibana 组成的一套日志文件收集和剖析的性能。监控告警三件套，Grafana，Prometheus 和 AlterManager。最初还有一个 Jaeger 是用于整体服务调用链路的追踪和剖析，毕竟服务太多了。对于这些组件如果感兴趣能够独自去理解一下，而由这些组件组成的TiEM整体架构大抵如下：   最上层是TiEM UI，可视化界面，通过OpenAPI-Server，和File-Server来获取数据，而两头Business Model 也就是实现TiEM治理层面，将上层的基础设施，进行对立封装和治理，当然这外面也包含本身的治理，例如用户，主机，集群的治理等等。TiEM同时也会封装TiUP的所有操作，能够简略了解成将TiUP操作可视化，而TiUP那一套这里也不做赘述了。 最上层的基础设施中除了咱们刚刚在下面看到的一些组件外，还蕴含有Sqlite（轻量级数据库）和一个ETCD（高可用数据库），代表上层也是会做肯定的高可用。其中Sqlite我了解是用于存一部分的辅助数据，目前还不分明具体是怎么进行数据的分类和寄存。 整个架构是十分清晰明了的四层架构，根底设置 —> 服务集成和封装 —> 公开接口 —> 前端展现。 TiEM功能模块来到大家最关怀的局部，就是TiEM的应用。在应用之前，因为目前TiEM的局部性能没有具体实现，所以在部署实现后，须要间接拜访OpenAPI来进行初始化，初始化的过程中有两步比拟重要。第一步导入主机的规格模板，不便于前期部署的时候，能够给每个TiDB节点抉择相应的规格，例如CPU和内存等。第二步是增加TiDB产品，配置每个组件的相干参数的范畴，同样是为了创立TiDB集群的时候能够抉择部署的组件。 实现初始化后，就能够应用内置默认的账号密码登录主页。整个页面格调相似 Dashboard，从右边的菜单栏，能够看到整个零碎一共具备四个功能模块：Resources Management， Clusters Management，Work Task Management 和 System Management. Resources Management主机资源管理，用于所有的虚拟机和物理机治理，能够视作为资源池。通过导入性能，将现有的机器资源导入到资源池中，那么前面在一键部署TiDB集群的时候，会通过现有的资源池中，抉择适合的机器用于部署相应的节点。 抉择适合的机器，次要依附的是导入主机时给每个主机所定义的标签（Purpose），有三种标签，别离是 Compute（TiDB-Server），Storage（TiKV or TiFlash），Schedule（PD）。 ...

TiDB 解决各种劫难故障堪称驾轻就熟，然而常言道“人祸易躲，人祸难防”，对于各种误操作、bug 写入谬误数据、甚至删库跑路，目前还没什么招。咱们我的项目最后也是为了解决这些“意料之外”的事变。我的项目最后的名字叫 TiDB Flashback，起初又感觉这个名字过于瘠薄，无奈体现我的项目内容的优越性，起初索性改成了“MVCC 时光机”。 ——渡渡鸟振兴会战队 在 TiDB Hackathon 2021 赛事中，渡渡鸟振兴会赛队的作品“MVCC 时光机”充分利用 MVCC 个性，增强 MVCC 数据的查问、整顿、复原的能力，进步问题解决的效率，摘得了赛事的 “三等奖” 。 一个十分 smart 和轻量级的实现，成果很不错，期待尽快公布上线。 ——评委冯光普 这个我的项目是给运维同学在某些时候救命的性能。它通过 SQL 很好地解决了运维的操作问题。更赞的是，该我的项目引入了多 Safepoint 机制，也就是能够给 TiDB 集群定期做一些全局 Snapshot，进行疾速轻量级的逻辑备份。 ——评委唐刘 对于我的项目人祸易躲，人祸难防作为一款分布式数据库，欠缺的高可用和容灾机制能够说是 TiDB 的外围个性。然而在生产中，实践上的劫难复原和实际上要面对的却可能天壤之别。不可预知的硬件故障、自然灾害导致的断网断电诚然可怕，而把生产环境当成测试环境的误操作、有破绽被黑客攻击、业务出 Bug 写坏数据反而可能是更高频的事变。 队员之一 @disking 已经就任于游戏公司，对这种“人为的失误”感触颇深：业务共事写的代码中出了一个 bug，在版本上线后的几个小时内被居心叵测玩家利用取得了许多不正当的收益，这时候就要进行回档操作，让游戏数据回到某个具体的工夫点，须要实现的就是相似“时光机”的性能。手动回档、数据失落造成的损失都会给团队带来很大的麻烦。 当初物理上的故障解决 TiDB 曾经给出了像 BR 工具、两地多核心计划等解决措施，而一句rm -rf /*，或者“实习生误操作”导致的谬误数据写入带来的危险却更加不可控，这也是 TiDB 缺失的一大块拼图。 Make MVCC Great Again！因为 TiDB 的事务是基于 MVCC 的，所以一段时间内的旧版本都在，实践上对于上述人祸，都是能够进行手动复原的。然而现有的性能和打算中的性能绝对较弱： 很可能须要排查数据损坏的状况，目前只能指定 ts 去读一个工夫点的数据，要查看某条记录的变动历史太麻烦RECOVER TABLE 只能复原 DROP/TRUNCATE 这种 DDL 操作，对 DML 没招GC Safepoint 之前的数据恢复不了，如果想保留长时间的数据，又太费空间了复原数据要先把数据 dump 进去再从新写入，太慢了因而充分利用 MVCC 个性，增强 MVCC 数据的查问、整顿、复原的能力，就能进步问题解决的效率。MVCC 不只是能够用来暂时性地处理事务隔离，也齐全能够做为冷备，相比于内部的备份，其长处是能够更省空间，复原数据也更不便更快。 ...

好久没写货色了, 正好趁着春节的节后综合症发生写写文章热身一下，记得前几年偶然会写一些对于 TiDB 产品性能解读的文章，TiDB 5.0 发了那么长时间了，也应该写一写了。我其实在多个场合里表白过我对于 5.0 的器重，这个版本可能是对于 TiDB 来说的 MySQL 5.x，相熟 MySQL 生态的敌人必定晓得我在说什么，MySQL 5.x，尤其是 5.5~5.7 这几个重要的版本基本上为 MySQL 的疾速扩张奠定了松软的根底，也造就了一大批 MySQL 的用户和人才。我认为 TiDB 5.x 尤其在 5.2 之后，也看到了进入快车道的趋势，开始展现出生态统治力。对我而言，TiDB 是一个绝佳的样本，在此之前，中国外乡很少有这样从零到一做进去的开源根底软件产品，少数工程师和产品经理都是这些软件的「使用者」，更多的是构建业务零碎，而 TiDB 让咱们第一次得以「设计者」的视角参加其中：每一个性能个性的设置背地的思考，对根底软件产品的价值出现，体验还是很不一样的，借着这篇文章写点感触，另外的这个文章是春节前我在 PingCAP 外部给 Presales 和 PM 培训上的分享整顿而成，不肯定正确，仅供参考。咱们做的事件，对于用户意味着什么？要讲好根底软件的产品价值，首先要克服的第一个关卡：学会换位思考。其实 TiDB 每个版本都带着数十个的个性和修复，然而少数时候咱们的 Release note 只是忠诚的反映了「咱们做了什么」：TiDB 4.0 GA 的 Release Note 截图 各位这里请不要了解错我的意思，这种类型的记录是很有必要存在的，然而仅有这个是远远不够的。例如在 TiDB 5.0~5.5 的版本外面，咱们引入了 n 多的新个性：聚簇索引，异步提交事务模型，优化了 SQL 优化器，反对了 CTE，引入了锁视图和继续性能诊断工具，改良了热点调度器，升高了获取 TSO 的提早，引入 Placement Rules SQL…这些名字在 TiDB 的开发者看来是没问题的，然而请留神，更重要的问题是：这些对于用户（客户）意味着什么？要答复这个问题的思路有两种，我别离讲讲： 通过一个假想的指标场景，而后通过产品去满足这个场景来展示价值。解决现有的计划（包含本人的老版本）那些最宜人的问题来展示价值。对于第一种思路，通常实用于比拟新的个性，尤其是一些过来素来没有的陈腐货色。用一个比拟好了解的例子：如果大家都在开马车的时候，你创造了一个汽车，这时候如果你以汽车解决了马儿要吃草的问题作为价值点显然是比拟荒诞的，更正当的是描述高速通勤的场景带来的便利性作为卖点。这种思路有两个关键点：首先这个场景最后是产品经理假想的（当然必定也会做过很多访谈和原野考察），所以如何确保这个场景是「高价值」且「具备普适性」的？对于一个胜利的根底软件，这点尤其重要，通常在我的项目晚期能抓到一个这样的点，就相当于胜利了一半，当然这个对产品经理的要求是十分高的，通常须要有很强的 vision 和推动力，这就是为什么很多产品型公司的 CEO 都是晚期的大号产品经理，因为在我的项目的晚期 CEO 须要同时领有这两样。当然更强的犹如乔布斯这种事实扭曲场，无中生有造出 iPod / iPhone 扭转了整个世界，这是何等的气魄和远见（我置信 Jobs 在构思 iPhone 的时候应该能设想到明天的世界）。这个没啥方法，根本就是靠人。你产品的价值是否在这个场景里有最间接的体现。最好的间接通常是直指人心的，是人间接能领会到的「感触」。对于开发者产品来说，我通常会抉择的锚点是「用户体验」，因为好的体验是不言自明的，汽车和马车比照在通勤舒适度和效率的时候，是完胜的；就像 TiDB 和 MySQL 分库分表的计划比弹性扩大能力时候也是一样，体验上也是完胜的。对于这一点倒是有很多办法去参考，有趣味的能够参考我那篇对于用户体验的文章。第一种思路实质上来说是 Storytelling，这种形式的益处在于：十分好验证，当你把故事想明确了，那天然典型的用户旅程就进去了，这时候你把本人作为一个假想的用户残缺的体验一遍即是验证，这也是我通常应用的测验咱们自家产品经理工作的形式。用户很好承受，情理很简略：人人都喜爱听故事，人人都喜爱看 Demo，人人都喜爱抄作业。对于第二种思路，通常实用于一些改进型的个性，其中的关键点在于：待解决的问题到底多痛？没有完满的软件，在重度用户那边肯定会有各种各样的问题，而且这类问题通常这个性能的开发者是难以领会到的，这时候要做的也很简略，就是弯下腰去理解，去应用，去感触。我常常会去和咱们的客户交付团队的一线同学聊天，在做这次分享之前也不例外，大抵的对话如下：我：对于咱们的 SQL 优化器，你感觉日常工作中，让你最头疼的问题是啥？Ta：执行打算渐变。我：对了，那是 hint 不太够用吗？而且 3.0 就引入了 SQL Binding？这些帮上忙了吗？Ta：对于一些疑难杂症来说你很难通过 hint 来指定的特定的执行打算（而后附上了一个实在的业务场景中的例子，一条百行的 SQL，的确无从下手），另外 SQL Binding 问题在于，我绑定了 SQL 执行打算当前，之后如果有更好打算，还须要从新来？我：咱们 4.0 不如引入了 SQL Plan Management 吗？外面的主动演进性能不正好是解决这个问题的吗？Ta：没错，然而咱们生产环境都不敢开，对于极端重要的 OLTP 场景，不能容忍执行打算主动变更带来的抖动危险。我：咱们的产品做什么事件，能让你感觉日子好过一点？Ta：1. 对于简单的 SQL 可能抉择指标执行打算，让我抉择 binding 就好，而不是通过 Hint 结构；2. SPM 发现更好的执行打算，只须要及时告诉我，我来做变更，而不是主动决策变更。 ...

TiDB 5.4 作为 2022 年开山之作，蕴含了许多有用无益的新性能和持续性的性能/稳定性晋升。本文着重介绍重要新增性能和个性所带给用户的新体验和价值，依照以下章节来组织： 根底性能优化和晋升 面向云环境的性能拓展 产品易用性和运维反对 新增实用性性能波及到的系统配置开关选项 次要的 bug 修复和稳定性晋升 更多具体内容还能够参照 Release Notes 和 用户手册 。 根底性能优化和晋升TiDB 5.4 在性能晋升方面实现了以下的重要改良：查问打算可利用多个列上的索引进行高效条件过滤相干的优化工作，即通过正式反对索引合并查问优化性能，使此类查问的性能取得数量级的晋升，并且具备响应工夫稳固不占系统资源的突出特点；对于数据量大、读写更新频繁的剖析场景， TiFlash 存储引擎的性能优化将使 CPU 占用率在现有根底上显著升高并间接帮忙晋升并发查问下的总体性能；最初，TiDB 5.4 在大规模数据同步场景下显著晋升了同步工具 Lightning 的性能使得大规模的数据同步工作更轻松快捷。 TiFlash 存储层大幅优化行存到列存转码效率用户场景与挑战HTAP 平台和利用中，数据更新和大量扫表行为交错在一起，存储系统的效力是影响性能和稳定性的关键因素，重度用户总是期待零碎能有更好的性能并承载更多的业务。特地是 TiDB HTAP 采纳了事务处理与剖析查问物理拆散的架构，同一份数据依据业务的须要，在后盾进行主动的行式存储到列式存储的转换以别离响应 OLTP 和 OLAP 两种类型的负载。存储层大幅优化了从 TiKV “行”存储到 TiFlash “列”存储格局的转换效率，在“行 - 列”转换环节的 CPU 效率大幅晋升，进而使得高负载状况下能够节约出更多的 CPU 资源用于其余环节的计算工作。 解决方案与成果TiDB 5.4 从新梳理了 TiFlash 中行存到列存转码模块的代码架构，大量简化了冗余的数据结构和判断逻辑，采纳 CPU 缓存和向量化敌对的数据结构和算法，从而大幅提高运行效率。另外，新版本还相应地优化了 TiFlash 的存储引擎 DeltaTree 的默认配置，综合成果的确认参见下文。 列式存储引擎写入性能验证：在不同并发状况下吞吐性能进步 60%～90% 验证环境： 6 TiKV（ 1 正本）、1 TiFlash（ 1 正本），每个节点 40 个 CPU 逻辑 core，CH-benCHmark (1500 warehouse)。 ...

引言TiCDC 作为 TiDB 的数据同步组件，负责间接从 TiKV 感知数据变更同步到上游。其中比拟外围的问题是数据解析正确性问题，具体而言就是如何应用正确的 schema 解析 TiKV 传递过去的 Key-Value 数据，从而还原成正确的 SQL 或者其余上游反对的模式。本文次要通过对 TiDB Online DDL 机制原理和实现的剖析，引出对以后 TiCDC 数据解析实现的探讨。 背景和问题数据同步组件是数据库生态中不可或缺的生态工具，比拟出名的开源单机数据库 MySQL 就将数据同步作为 Server 能力的一部分，并基于 MySQL binlog 实现异步/半同步/同步的主从复制。因为 MySQL 乐观事务模型和表元数据锁的存在，咱们总是能够认为 MySQL binlog 中存在因果关系的 data 和 schema 合乎工夫先后顺序的，即： New data commitTs > New schema commitTs 然而对于 TiDB 这种存储计算拆散的架构而言，schema 的变更在存储层长久化，服务层节点作为多缓存节点，总是存在一个 schema 状态不统一的时间段。为了保证数据一致性和实现在线 DDL 变更，现有的分布式数据库大都采纳或者借鉴了 Online, Asynchronous Schema Change in F1 机制。所以咱们要答复的问题变成了，在 TiDB Online DDL 机制下，TiCDC 如何正确处理 data 和 schema 的对应关系，存在因果关系的 data 和 schema 是否依然满足： ...

前言Relay log 相似 binary log，是指一组蕴含数据库变更事件的文件，加上相干的 index 和 mata 文件，具体细节参考 官网文档 。在 DM 中针对某个上游开启 relay log 后，相比不开启，有如下劣势： 不开启 relay log 时，每个 subtask 都会连贯上游数据库拉取 binlog 数据，会对上游数据库造成较大压力，而开启后，只需创立一个连贯拉取 binlog 数据到本地，各个 subtask 可读取本地的 relay log 数据。上游数据库对 binlog 个别会有一个生效工夫，或者会被动 purge binlog，以清理空间。在不开启 relay log 时，如果 DM 同步进度较为落后，一旦 binlog 被清理，会导致同步失败，只能从新进行全量迁徙；开启 relay log 后，binlog 数据会被实时拉取并写入到本地，与以后同步进度无关，可无效防止后面的问题。但在 DM 版本 <= v2.0.7 中，开启 relay log 后有如下问题： 数据同步提早相比不开启 relay log 有显著回升，上面的表格是一个单 task 的 benchmark 的测试后果，可看出均匀 latency 有显著的增长。下表中以“.”结尾的是提早的百分位数据。 开启 relay 后 CPU 耗费减少。（因为 latency 的增长，在一些简略场景下（比方只有 1 个 task）相比不开启 relay log，资源使用率反而是降落的。但当 task 增多时，开启 relay 的 CPU 耗费就减少了）。因为以上问题，在新的版本中，咱们对 DM 的 relay log 做了一些性能优化。 ...