PingCAP 联合创始人兼 CTO 黄东旭在 TiDB 5.0 发布会上进行了《What’s Next? 新一代数据库的构想》的精彩演讲,讲述了 TiDB 作为一款企业级数据库的成长史,并分享 PingCAP 对于企业级数据库的思考与内外功修炼。
本篇文章将介绍组件控制循环的编排设计。我们将会了解到完成 TiDB 集群的生命周期管理过程中,各种控制循环事件经过了怎样的编排,这些事件中又完成了哪些资源管理操作。
TiDB 5.0 的性能和稳定性得到显著提升,从而具备更强大的 OLTP 金融级核心场景的服务能力;在原有 HTAP 引擎 TiFlash 的基础上引入 MPP 架构,TiDB 使得众多企业的实时/交互式 BI 成为现实。
本篇文章的作者为龙姐姐说的都队的李晨曦,他们团队在本次Hackathon 比赛中构建了一个基于 TiKV 的分布式 POSIX 文件系统 TiFS,继承了 TiKV 强大的分区容错和严格一致性特性,为 TiKV 生态开辟了一个新的领域。
本文作为 TiDB Operator 源码阅读系列的开篇,介绍了 TiDB Operator 的应用场景和能力定位,并谈到了之后源码阅读系列文章的规划,我们希望能通过这一系列文章扫清 TiDB Operator 理解的障碍,让更多的创意在社区中萌发。
本篇文章的作者为 CAAS 团队的王相与于畅,他们在本次 Hackathon 比赛中基于 Chaos Engineering as a Service 的理念,对 Chaos Mesh 进行改造,以下就来看看他们的探索历程。
本文将会从 TiDB 现有的授时服务出发,一步步阐释新分布式授时服务的改造思路和本地事务的性能表现,最后会分享一个应用场景与上手步骤。
本篇文章将通过 Ti-Improve 团队与华创资本企业软件投资负责人谢佳的对话,揭秘团队赛前幕后的精彩故事。
本文将向大家介绍 TiDB 4.0.7 提供的一个新功能,可以将数据库各个内部流程的耗时监控按父子关系绘制为关系图,帮助用户快速以另一种维度了解集群状态。
随着 Chaos Mesh 1.0 的发布,提供了运行时注入文件系统错误的功能,使得 IOChaos 的使用和其他所有类型的 Chaos 一样简单方便。这篇文章将会介绍它的实现方式。
DM 2.0 版本已正式发布,新增高可用、乐观协调模式下的分库分表合并迁移等企业级特性,同时带来一系列易用性的提升,确保用户的原数据库可以平滑地切换到 TiDB,完全不用担心迁移带来的故障与数据丢失。
从开源到现在近一年的时间里,Chaos Mesh 在所有贡献者的共同努力下,在不断完善新功能的同时,在易用性和稳定性上也都取得了阶段性的成果,今天,我们自豪的宣布 Chaos Mesh 1.0 正式发布!
本文将向大家介绍 TiCDC,一个通过拉取 TiKV 日志实现的 TiDB 增量数据同步工具,具有还原数据到与上游任意 TSO 一致状态的能力,同时提供开放数据协议,支持其他系统订阅数据变更。
本文将向大家分享介绍 TiDB 在 K8s 上的运维管理系统 TiDB Operator,再从各类故障场景入手剖析 TiDB on K8s 如何实现高效的故障自愈并保障数据安全。
这篇文章尝试向大家较为完整的介绍下 TiKV 中的 Raft 读流程的实现,特别是 read index 和 lease read。
本文将介绍如何在 GitHub Actions 的 workflow 中使用 Chaos Mesh,从而将混沌工程集成到系统开发的 CI 中。
本篇文章概述了 BPF 的主要应用,重点描述了 libbpf-tools 解决了哪些 BCC 痛点以及在 PingCAP 内部的相关实践。
热点处理是分布式数据库亘古不变的话题,经过四个大版本的演进,目前 TiDB 4.0 通过 AutoRandom、新热点调度器、热点可视化这几个方面进行了大幅度的优化。这些变化将以润物细无声的方式影响用户的体验。
本文介绍了帮助我们在复杂的分布式系统环境下保证系统正常稳定运行的办法 —— Chaos Engineering,以及基于 Kubernetes 的云原生混沌工程平台 Chaos Mesh®。
本文介绍我们是如何在 Chaos Mesh 和 Argo 的基础上打造自己的自动化测试平台 TiPocket],实现完全自动化的混沌测试,构成混沌测试完整闭环。
2020 年 PingCAP 合作伙伴生态体系构建全面启动,基于 TiDB 社区,秉承开放平等的全新社区化合作伙伴生态理念,产业生态合作、解决方案合作、联合技术中心等众多计划百花齐放。
依托于整个工程研发团队、QA 测试团队,以及所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制,我们能够为银行、保险、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。
在部署易用性方面,TiDB 开发者经过诸多探索和尝试,经过了命令行时代、Ansible 时代,终于在 TiDB 4.0 发布了新一代具有里程碑意义的解决方案——TiUP。
TiDB 4.0 终于迎来 GA 版本,这是 TiDB「面向未来的数据库」道路上面的一个重要的里程碑。
三月初,围绕着这 20 个呼声最高的需求,我们在社区启动了 TiDB 易用性挑战赛。赛事开启后,大家可是百花齐放,百家争鸣。目前赛程已经过半,我们先来看看战绩吧!
上周六,我们开启了 The Future of Database 系列 的第一期直播,我司 CTO 黄东旭及 Engineering VP 申砾畅聊了“未来的数据库会是什么样?”这个颇具想象力的话题。这是第一期直播的部分文字&视频回顾。
raft-rs 实现了 Raft Leader election 和 Log replication 等核心功能,而消息的发送、接收、应用到状态机等操作则需要使用者自行实现,本文将要介绍的就是 TiKV 中这些部分的处理过程。
TiFlash 是配合 TiDB 体系的列存引擎,它和 TiDB 无缝结合,在线 DDL、无缝扩容、自动容错等等方便运维的特点也在 TiFlash 中得到继承,此外,TiFlash 可以实时与行存保持同步。
如果说在 TiDB 3.0 中,悲观锁是 “千呼万唤始出来,犹抱琵琶半遮面”。那么在 TiDB 4.0 中,悲观锁在经历了市场与时光的考验后,无论是性能还是稳定性都能够 “轻拢慢撚抹复挑,初为《霓裳》后《六幺》”。
“参与社区贡献,除了增加了 Rust 使用经验和真正用于生产的数据库开发经验,同时也认识了很多人,扩大了社交圈,让我学到了很多东西。”
从上周五晚 21:00 开始,历时 48 小时,共有 102 位来自社区的作者参与,截止周日 21:00,总计产生了 421 次 Commit,199 个 PR,最终开源电子书 <TiDB in Action> 第一版诞生。
Go 是一种简单、小巧、令人愉悦的语言。它也有一些犄角旮旯,但绝大部分是经过精心设计的。它的学习速度令人难以置信,并且规避了其他语言中一些不那么广为人知的特性。
和一群志同道合的朋友一起做酷且正确的事情,哪怕它是困难的、甚至曾被人认为是不可能的。但,让世界变得更美好,不正是我们踏入开源世界的初衷吗?
既然都是做分布式系统的,为什么不尝试下「分布式写书」?TiDB 的社区里有那么多身怀绝技的朋友,社区里也积赞了无数的内容,我们只是需要一个契机将这些内容串联起来。
TiDB 挑战赛第二季今天正式开启,赛程持续 3 个月,本赛季将围绕“提升 TiDB 的易用性”展开。考虑到用户们对 TiDB 落地实操中的“易用性”有深刻的体验,我们特地征求了一波 TiDB User Group(TUG)的意见。
TiDB 目前可以满足超大集群的备份恢复的需求,经过测试,10T 数据的备份恢复速度可以达到 GB/s 级别。这得益于我们研发的分布式备份恢复工具 Backup&Restore That Scales (BR)。
同步数据这一步重要操作由 Drainer 模块支持,它可以将 binlog 同步到 TiDB / MySQL / Kafka / File (增量备份)等下游组件
在 4.0 版本中 TiDB 也实现了 Key Visualizer 功能。现在,我们可以很轻松地给集群拍个 “CT”,快速直观地观察集群整体热点及流量分布情况。
性能挑战赛已经圆满落幕,最终的积分排行也新鲜出炉,选手们的参赛成果让人非常惊喜,让我们回顾一下选手们是如何在“TiDB 性能提升”之路上,过五关斩六将的吧~
借助 TiFlash 的一致性数据同步特型,用户可否以一个优异的速度直接对实时数据进行分析呢?
2019 年第四季度,PingCAP Special Week 的主题是 Tools matter,本篇文章将介绍本次 SW 都有哪些不错的成果。
我们将混沌相关实现从自动化测试平台中抽离出来,作为 Chaos Mesh 的最初原型,并经过重新设计和完善,最终于 Github 上开源。
基于 TiDB Binlog 的 Fast-PITR (Fast point in time recovery),即基于 TiDB Binlog 的快速时间点恢复,实现了基于 TiDB Binlog 的逐级 merge,以最小的代价实现快速 PITR,解决了现有 TiDB 原生备份恢复方案的一些痛点问题。
本文将介绍下推算子的执行流程并分析下推算子的部分实现细节,加深大家对 TiKV Coprocessor 的理解。
本文介绍了 Pump Storage 的两个重要组件 `valueLog`,`slowChaser` 的主要功能与具体实现。
“当你持续的认真投入到开源后,项目和社区就会产生双向的交流,不再只是你单向的投入,社区也会给予你反哺,这时就会形成正向循环,对项目发展会起到非常大的推动作用。”
TiKV Engine SIG 主要职责是对 TiKV 的存储引擎的未来发展进行讨论和规划,并进行相关开发和维护。期待社区伙伴们的支持和贡献~
我们将这个系列再向着数据库的核心前进一步,挑战一下「为 TiDB 的优化器增加优化规则」,带大家初步体验一下可以对查询的执行时间产生数量级影响的优化器的魅力。
TiDB Server 作为无限水平扩展的无状态计算节点,需要能提供稳定且高性能的负载均衡组件用对外统一的接口地址来提供服务,而 HAProxy 在负载均衡的生态中占有很大的市场。本文将介绍在 TiDB 下使用 HAProxy 的最佳实践。
Unified Thread Pool 项目实现了在 TiKV 中使用一个统一的自适应线程池处理读请求,能够显著提升性能,并可预测性地限制大查询对小请求的干扰,最终在 TiDB Hackathon 2019 中斩获一等奖。
TiDB-Wasm 项目实现了将 TiDB 编译成 Wasm 运行在浏览器里,让用户无需安装就可以使用 TiDB,最终获得了 TiDB Hackathon 2019 的二等奖。
本文以 TiKV 性能挑战赛 Easy 级别任务“PCP:Migrate functions from TiDB”为例,教大家如何快速又正确地完成这个任务。
本文将从 Java 数据库交互组件开发的角度出发,介绍各组件的推荐配置和推荐使用方式,希望能帮助 Java 开发者在使用 TiDB 时能更好的发挥数据库性能。
今天的 TiDB 可以直接运行在浏览器本地。打开浏览器,你可以直接创建数据库,对数据进行增删改查。关掉浏览器,一切都消失了,干净绿色环保。
本文将简要介绍 TiKV Coprocessor 的基本原理,面向想要了解 TiKV 数据读取执行过程的同学,同时也面向想对该模块贡献代码的同学。
今天是 1024 程序员节,我们正式成立 TiKV 项目的首个 SIG —— Coprocessor SIG,希望对 TiKV 项目感兴趣的小伙伴们都能加入进来,探索硬核的前沿技术,交流切磋,一起走上 Contributor 的进阶之路!
本文将介绍 TiKV 核心模块 Raftstore 的处理流程以使大家更好得理解海量 Region 导致性能问题的根源,以及针对这种情况的一些优化手段。
TiDB 社区已经逐渐成熟,但是随着社区的发展壮大,我们逐渐感受到了现在社区架构上的一些不足。经过一系列的思考和总结,我们决定升级和调整目前社区组织架构,引入更多的社区角色和社区组织,以便更好的激发社区活力,维护积极健康的社区环境。
本文我们将深入浅出介绍 TiDB 乐观事务原理,并给出多种场景下的最佳实践,希望大家能够从中受益。同时,也欢迎大家给我们提供相关的优化建议,参与到我们的优化工作中来。
如果有一个自动 tuning 的方案就可以大大减少调优的人力成本,同时也可能在调优的过程中,发现一些人工想不到的信息。我们从 AutoML 中得到启发,希望能用 Automated Hyper-parameter Tuning 中的一些方法来对数据库参数进行自动调优。
在上篇文章中,我们主要介绍了 Pump Server 的上线过程、gRPC API 实现、以及下线过程和相关辅助机制,其中反复提到了 Pump Storage 这个实体。本文就将介绍 Pump Storage 的实现。
在上篇文章中,我们介绍了 TiDB 如何实现表达式的向量化优化,以及社区同学如何参与这项工程。两周过去了,我们收到了很多来自社区小伙伴们的建议和反馈,今天在这里和大家分享一下活动进展和这些建议及反馈。
最近我将一个中小型的 crate 从 futures 库的 0.1 迁移至了 0.3 版本。过程本身不是特别麻烦,但还是有些地方或是微妙棘手,或是没有很好的文档说明。这篇文章里,我会把迁移经验总结分享给大家。
最近我们扩展了 TiDB 表达式计算框架,增加了向量化计算接口,初期的性能测试显示,多数表达式计算性能可大幅提升,部分甚至可提升 1~2 个数量级。为了让所有的表达式都能受益,我们需要为所有内建函数实现向量化计算。
“从前我们更多是站在使用者的角度从开源社区汲取养分,随着知乎技术架构和内部工程能力的成长,未来我们希望能够以更加积极主动的状态参与开源项目,回馈社区。”
使用 TiDB Ansible 部署 TiDB 集群,会同时部署一套 Grafana + Prometheus 的监控平台,这套监控用来收集和展示 TiDB 集群各个组件和机器的 metric 信息,这些 metric 信息非常丰富,可以帮助使用者分析 TiDB 集群的状态以及 Trouble shooting。
本文通过阐述一个高并发批量写入数据到 TiDB 的典型场景中,TiDB 中常见的问题,给出一个业务的最佳实践,避免业务在开发的时候陷入 TiDB 使用的 “反模式”。
本文将继续介绍 Pump server 的实现,对应的源码主要集中在 TiDB Binlog 仓库的 pump/server.go 文件中。
关注 TiDB 的同学,最近可能注意到 TiKV 这边合并了一个不大不小的 PR,支持了一个特性叫做 Follower Read,看到这个功能被合并进主干我确实有点百感交集,还发了条朋友圈庆祝,因为我实在很喜欢这个特性。
本次活动聚焦于语法兼容,提升 TiDB SQL Parser 对 MySQL 8.0 的语法支持。对于新的贡献者而言,除了能将理论知识运用到实践上以外,还可以从中体验参与一个开源项目的整体流程与规范。
开源后到现在的近一年内,我们一方面基于用户反馈不断打磨项目的易用性,另一方面通过严苛的稳定性测试持续提升可靠性。今天,我们自豪地宣布 TiDB Operator 1.0 GA 正式发布!
本文将为大家介绍 TiKV 源码中的 Storage 模块,它位于 Service 与底层 KV 存储引擎之间,主要负责事务的并发控制。TiKV 端事务相关的实现都在 Storage 模块中。
在本篇文章中,我们将对 shard DDL 同步机制以及 checkpoint 机制等进行详细的介绍,内容包括 shard group 的定义、shard DDL 的同步协调处理流程、checkpoint 机制以及与之相关的 safe mode 机制。
之前的 TiKV 源码解析系列文章介绍了 TiKV 依赖的周边库,从本篇文章开始,我们将开始介绍 TiKV 自身的代码。本文重点介绍 TiKV 最外面的一层——Service 层。
本文介绍了 TiDB Binlog 相关源码仓库:tidb-tools 和 tidb-binlog,以及其中的目录,并且展示了如何启动测试集群。
本篇文章将会以 gh-ost 为例,详细地介绍 DM 是如何支持一些 MySQL 上的第三方 online schema change 方案迁移,内容包括 online schema change 方案的简单介绍,online schema change 迁移方案,以及迁移实现细节。
TiDB Binlog 组件用于收集 TiDB 的 binlog,并准实时同步给下游,如 TiDB、MySQL 等。该组件在功能上类似于 MySQL 的主从复制,会收集各个 TiDB 实例产生的 binlog,并按事务提交的时间排序,全局有序的将数据同步至下游。
本篇将带大家深入到 grpc-rs 这个库里,查看 RPC 请求是如何被封装和派发的,以及它是怎么和 Rust Future 进行结合的。
本篇文章介绍了 DM 的定制化数据同步功能中库表路由(Table routing)、黑白名单(Black & white table lists)、列值转化(Column mapping)、binlog 过滤(Binlog event filter)四个主要功能的实现。
我们在 K8s 中测试 TiDB Operator 时发现了两个 Linux 内核错误,这些错误已经困扰我们很长一段时间,并没有在整个 K8s 社区中彻底修复。经过广泛的调查和诊断,我们已经确定了处理这些问题的方法。
本篇 TiKV 源码解析将为大家介绍 TiKV 的另一周边组件—— grpc-rs。grpc-rs 是 PingCAP 实现的一个 gRPC 的 Rust 绑定,其 Server/Client 端的代码框架都基于 Future,事件驱动的 EventLoop 被隐藏在了库的内部,所以非常易于使用。
2019 年 5 月 10 日,TiDB 3.0.0-rc.1 版本正式推出,该版本对系统稳定性,性能,安全性,易用性等做了较多的改进,本文会逐一介绍。
本篇文章将会详细地介绍 DM 核心处理单元 Binlog replication,内容包含 binlog 读取、过滤、路由、转换,以及执行等逻辑。
为方便用户和开发者更加深入理解和使用 TiDB Binlog 组件,以及基于 TiDB Binlog 组件做二次开发用于更多的业务场景, TiDB 团队决定于 2019 年 5 月 6 日正式开源 TiDB Binlog 组件。
Failpoint 项目是 FreeBSD Failpoints 的 Golang 实现,允许在代码中注入错误或异常行为,并由环境变量或代码动态激活来触发这些异常行为。Failpoint 能用于各种复杂系统中模拟错误处理来提高系统的容错性、正确性和稳定性。
本文将详细介绍 dump 和 load 两个数据同步处理单元的设计实现,重点关注数据同步处理单元 interface 的实现,数据导入并发模型的设计,以及导入任务在暂停或出现异常后如何恢复。
本篇文章将详细地介绍 DM 数据同步处理单元(DM-worker 内部用来同步数据的逻辑单元),包括数据同步处理单元实现了什么功能,数据同步流程、运行逻辑,以及数据同步处理单元的 interface 设计。
今年 1 月份,我们发布了 TiDB 3.0.0 Beta 版本,DevCon 上也对这个版本做了介绍,经过两个月的努力,今天推出了下一个 Beta 版本 3.0.0 Beta.1。
本篇文章主要介绍 TiDB Data Migration (TiDB DM) 的整体架构,包括 TiDB DM 有哪些组件、各组件分别实现什么功能、组件之间交互的数据模型和 RPC 实现。
本文将以 raft-rs 的公共 API 作为切入点,介绍一般 proposal 过程的实现原理,让用户可以深刻理解并掌握 raft-rs API 的使用,以便用户开发自己的分布式应用,或者优化、定制 TiKV。
Titan 是由 PinCAP 研发的一个基于 RocksDB 的高性能单机 key-value 存储引擎。我们的基准测试结果显示,当 value 较大的时候,Titan 在写、更新和点读等场景下性能都优于 RocksDB。
本文将为大家介绍 TiDB 在执行 DML/DDL 语句过程中,如何将 binlog 数据发送给 TiDB Binlog 集群的 Pump 组件。
在《(三)SQL 的一生》中,我们介绍了 TiDB 在收到客户端请求包时,最常见的 `Command --- COM_QUERY` 的请求处理流程。本文我们将介绍另外一种大家经常使用的 `Command --- Prepare/Execute` 请求在 TiDB 中的处理过程。
TiDB Data Migration 是用于将数据从 MySQL/MariaDB 迁移到 TiDB 的工具。该工具既支持以全量备份文件的方式将 MySQL/MariaDB 的数据导入到 TiDB,也支持通过解析执行 MySQL/MariaDB binlog 的方式将数据增量同步到 TiDB。
为了实现一些新特性,我们需要为 AST 实现可以还原为 SQL 文本的功能,这篇教程描述如何为 AST 节点添加该功能。首先介绍一些必需的背景知识,然后介绍实现 Restore() 函数的流程,最后会展示一个例子。
TiDB-Lightning Toolset 是一套快速全量导入 SQL dump 文件到 TiDB 集群的工具集,适合在上线前用作迁移现有的大型数据库到全新的 TiDB 集群。
TiDB Binlog 组件用于收集 TiDB 的 binlog,并提供实时备份和同步功能。本文主要介绍了 TiDB Binlog 的架构演进之路和实现原理。
TiDB 是由 PingCAP 开发的分布式关系型数据库,今天我们很高兴地推出 TiDB 2.1 正式版,提供更丰富的功能、更好的性能以及更高的可靠性。
PingCAP University 正式启动 TiDB DBA 官方培训认证计划。通过该计划,大家可以深度理解 TiDB 架构、原理及最佳实践,具备独立部署、运维和调优 TiDB 的能力;提升分布式计算和存储领域的技术前沿视野;获得来自 PingCAP 官方的认可,提升个人技术竞争力。
本文将继续介绍 tikv-client 里的两个主要的模块——负责处理分布式计算的 copIterator 和执行二阶段提交的 twoPhaseCommitter。
本文首先会介绍 TiDB DDL 组件的总体设计,以及如何在分布式场景下支持无锁 schema 变更,并描述这套算法的大致流程,然后详细介绍一些常见的 DDL 语句的源码实现。Enjoy~
TiDB Operator 已经正式开源,本文将详细介绍 TiDB Operator 开源的细节,希望大家深入了解这个新的开源项目之后,能够速来贡献代码、成为 Contributor!Enjoy~
本文将首先介绍在 TiDB 中的 INSERT 语句的分类,以及各语句的语法和语义,然后分别介绍五种 INSERT 语句的源码实现,enjoy~
本篇文章将介绍统计信息基本概念、TiDB 的统计信息收集/更新机制以及如何用统计信息来估计算子代价。上篇侧重于介绍原理,下篇会结合原理介绍 TiDB 的源码实现。
前两篇文章中介绍了 Chunk 和 Hash Join,本篇将继续介绍 TiDB 中 Index Lookup Join 具体实现方法和执行流程。Enjoy~
这篇文章是关于 TiDB 代表性“为什么”的 TOP 10,希望大家在了解了我们这些背后的选择之后,能更加纯熟的使用 TiDB,让它在适合的环境里更好的发挥价值。
本文分享了 TiDB 应用混沌工程的方法,介绍基于 K8s 自研的自动化测试平台 Schrodinger,并通过实际例子说明如何在 Schrodinger 里应用混沌来测试系统。
本文是 TiDB 源码阅读系列文章的第八篇。内文会先简单介绍制定查询计划以及优化的过程,然后用较大篇幅详述在得到逻辑计划后的 Cost-Based Optimization(CBO)过程。
本文是 TiDB 源码阅读系列文章的第七篇。在 TiDB 中,SQL 优化的过程可以分为逻辑优化和物理优化两个部分。本篇将主要关注逻辑优化。Enjoy ~
在先前的 TiDB 源码阅读系列文章(四)中,我们介绍了 Insert 语句,想必大家已经了解了 TiDB 是如何写入数据,本篇文章介绍一下 Select 语句是如何执行的。Enjoy~
本文为今年年初 PingCAP 商业产品团队负责人刘寅在 TiDB DevCon2018 上分享的 《 TiDB 工具链和生态》实录内容,文内详细介绍了 TiDB 的周边工具以及生态系统。enjoy~
本文为 TiDB 源码阅读系列文章的第五篇,主要对 SQL Parser 功能的实现进行了讲解。内容来自社区小伙伴——马震(GitHub ID:mz1999 )的投稿。
本文为 TiDB 源码阅读系列文章的第三篇。本篇文章从 SQL 处理流程出发,介绍哪里是入口,对 SQL 需要做哪些操作,知道一个 SQL 是从哪里进来的,在哪里处理,并从哪里返回。
在 TiDB DevCon2018 上,我们对外宣布了 TiDB 源码阅读分享活动,承诺对外发布一系列文章以及视频帮助大家理解 TiDB 源码。本文为本系列文章第一篇。
2018 年 2 月 24 日,TiDB 发布 1.1 Beta 版。该版本在 1.1 Alpha 版的基础上,对 MySQL 兼容性、系统稳定性做了很多改进。
构建一个分布式 Key-Value Store 并不是一件容易的事情,我们需要考虑很多的问题,首先就是我们的系统到底需要提供什么样的功能。本文将以我们开发的分布式 Key-Value TiKV 作为实际例子,来说明下我们是如何取舍并实现的。
很多人的『开源』是一个比较时髦且有情怀的词汇,不少公司也把开源当做 KPI 或者是技术宣传的手段。但是在我们看来,大多数人开源做的并不好,大多数开源项目也没有被很好的维护。比如前一段时间微博上流传关于 Tengine 的讨论,一个优秀的开源项目不止是公布源代码就 OK 了,还需要后续大量的精力去维护,包括制定 RoadMap、开发新功能、和社区交流、推动项目在社区中的使用、对使用者提供一定程度的支持,等等。
本文整理自 TiSpark 项目发起人马晓宇在 Strata Data Conference 上分享的《When TiDB Meets Spark》演讲实录。
上篇文章介绍了 TiDB 如何使用 Jepsen 来进行一致性验证,并且介绍了具体的测试案例,但是并没有对 Jepsen 背后的一致性验证算法做过多介绍。这篇文章将会深入 Jepsen 的核心库 knossos,介绍 knossos 库所涉及的 Linearizability(线性化)一致性验证算法。
TiSpark 是 PingCAP 推出的为了解决用户复杂 OLAP 需求的产品。借助 Spark 平台本身的优势,同时融合 TiKV 分布式集群的优势,和 TiDB 一起为用户一站式解决 HTAP (Hybrid Transactional/Analytical Processing)需求。 TiSpark 依赖 TiKV 集群和 PD 的存在。当然,TiSpark 也需要你搭建一个 Spark 集群。本文简单介绍如何部署和使用 TiSpark。
今年,Spanner 终于发了另一篇 Paper,Spanner - Becoming a SQL System,里面提到 Spanner 使用了一种新的存储格式 - Ressi,用来支持 OLTP 和 OLAP。在 Ressi 里面,使用了 PAX 来组织数据。因为 TiDB 定位就是一个 HTAP 系统,所以我也一直在思考在 TiKV 这层如何更好的存储数据,用来满足 HTAP 的需要,既然 Spanner 使用了 PAX,那么就有研究的必要了。
为了方便社区同学更好地参与 TiDB 项目,本文一方面对继上一篇文章发布后参考社区的反馈对表达式计算框架所做的修改进行详细介绍,另一方面对尚未重写的 built-in 函数进行陈列。
本文档用于总结在使用 TiDB 时候的一些最佳实践,主要涉及 SQL 使用、OLAP/OLTP 优化技巧,特别是一些 TiDB 专有的优化开关。建议先阅读讲解 TiDB 原理的三篇文章(讲存储,说计算,谈调度),再来看这篇文章。
为了加速表达式计算速度,最近我们对表达式的计算框架进行了重构,这篇教程为大家分享如何利用新的计算框架为 TiDB 重写或新增 built-in 函数。
经过很长一段时间的开发,TiDB 终于发了 RC3。RC3 版本对于 TiKV 来说最重要的功能就是支持了 gRPC,也就意味着后面大家可以非常方便的使用自己喜欢的语言对接 TiKV 了。gRPC 是基于 HTTP/2 协议的,要深刻理解 gRPC,理解下 HTTP/2 是必要的,这里先简单介绍一下 HTTP/2 相关的知识,然后再介绍下 gRPC 是如何基于 HTTP/2 构建的。
作为一个分布式系统,在多个节点分别配置安装服务会相当繁琐。Ansible 是基于 Python 的自动化运维工具,糅合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能,而且使用简单,仅需在管理工作站上安装 Ansible 程序配置被管控主机的 IP 信息,被管控的主机无客户端。选用自动化工具 Ansible 来批量的安装、配置、部署 TiDB 。本文介绍如何通过 Ansible 工具来批量安装,使整个过程简单化。
任何一个复杂的系统,用户感知到的都只是冰山一角,数据库也不例外。前两篇文章介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理,这两个组件一个负责 KV 存储,一个负责 SQL 引擎,都是大家看得见的东西。在这两个组件的后面,还有一个叫做 PD(Placement Driver)的组件,虽然不直接和业务接触,但是这个组件是整个集群的核心,负责全局元信息的存储以及 TiKV 集群负载均衡调度。本篇文章介绍一下这个神秘的模块。这部分比较复杂,很多东西大家平时不会想到,也很少在其他文章中见到类似的东西的描述。我们还是按照前两篇的思路,先讲我们需要什么样的功能,再讲我们如何实现,大家带着需求去看实现,会更容易的理解我们做这些设计时背后的考量。
上一篇介绍了 TiDB 如何存储数据,也就是 TiKV 的一些基本概念。本篇将介绍 TiDB 如何利用底层的 KV 存储,将关系模型映射为 Key-Value 模型,以及如何进行 SQL 计算。
数据库、操作系统和编译器并称为三大系统,可以说是整个计算机软件的基石。其中数据库更靠近应用层,是很多业务的支撑。这一领域经过了几十年的发展,不断的有新的进展。很多人用过数据库,但是很少有人实现过一个数据库,特别是实现一个分布式数据库。了解数据库的实现原理和细节,一方面可以提高个人技术,对构建其他系统有帮助,另一方面也有利于用好数据库。研究一门技术最好的方法是研究其中一个开源项目,数据库也不例外。单机数据库领域有很多很好的开源项目,其中 MySQL 和 PostgreSQL 是其中知名度最高的两个,不少同学都看过这两个项目的代码。但是分布式数据库方面,好的开源项目并不多。 TiDB 目前获得了广泛的关注,特别是一些技术爱好者,希望能够参与这个项目。由于分布式数据库自身的复杂性,很多人并不能很好的理解整个项目,所以我希望能写一些文章,自顶向下,由浅入深,讲述 TiDB 的一些技术原理,包括用户可见的技术以及大量隐藏在 SQL 界面后用户不可见的技术点。
在之前的 Kudu 的文章里面已经提到过,行列混存是一个非常有意思的研究方向,因为不同的存储方式有不同的针对应用场景,但作为技术人员,折腾是天性,所以大家都在研究如何融合行存和列存,让一个服务能尽量满足大部分应用需求,而这也是 TiDB 在努力的方向。
Kudu 是一个基于 Raft 的分布式存储系统,它致力于融合低延迟写入和高性能分析这两种场景,并且能很好的嵌入到 Hadoop 生态系统里面,跟其他系统譬如 Cloudera Impala,Apache Spark 等对接。
4 月 19 日,我司 CTO 黄东旭同学在全球云计算开源大会上,发表了《Cloud-Native 的分布式数据库架构与实践》主题演讲,以下为演讲实录。
最近我们对 TiDB 代码做了些改进,大幅度简化了添加內建函数的流程,这篇教程描述如何为 TiDB 新增 builtin 函数。首先介绍一些必需的背景知识,然后介绍增加 builtin 函数的流程,最后会以一个函数作为示例。
在分布式领域,为了保证数据的一致性,通常都会使用 Paxos 或者 Raft 来实现。但 Paxos 以其复杂难懂著称,相反 Raft 则是非常简单易懂,所以现在很多新兴的数据库都采用 Raft 作为其底层一致性算法,包括我们的 TiKV。
最近这几个月,特别是 TiDB RC1 发布后,越来越多的用户已经开始测试起来,也有很多朋友已经在生产环境中使用,我们这边也陆续的收到了很多用户的测试和使用反馈。非常感谢各位小伙伴和早期用户的厚爱,而且看了这么多场景后,也总结出了一些 TiDB 的使用实践 (其实 Spanner 的最佳实践大部分在 TiDB 中也是适用的,MySQL 最佳实践也是),也是借着 Google Cloud Spanner 发布的东风,看了一下 Spanner 官方的一些最佳实践文档,写篇文章讲讲 TiDB 以及分布式关系型数据库的一些正确的使用姿势,当然,时代也在一直发展,TiDB 也在不停的进化,这篇文章基本上只代表近期的一些观察。
在 TiKV 里面,从最开始的 Raft log read,到后面的 Lease Read,我们一步一步的在保证线性一致性的情况下面改进着性能。后面,我们会引入更多的一致性测试 case 来验证整个系统的安全性,当然,也会持续的提升性能。
最近大家非常关注的一件事情就是 Google Spanner Cloud 的发布,这应该算是 NewSQL 又一个里程碑的事件。在本篇文章中,唐刘同学与大家分享了他自己对 Spanner 的理解,Spanner 的一些关键技术的实现以及与 TiDB 的相关对比。
Placement Driver (后续以 PD 简称) 是 TiDB 里面全局中心总控节点,它负责整个集群的调度,负责全局 ID 的生成,以及全局时间戳 TSO 的生成等。PD 还保存着整个集群 TiKV 的元信息,负责给 client 提供路由功能。
本文档主要面向 TiKV 社区开发者,主要介绍 TiKV 的系统架构,源码结构,流程解析。目的是使得开发者阅读文档之后,能对 TiKV 项目有一个初步了解,更好的参与进入 TiKV 的开发中。
本系列文章主要面向 TiKV 社区开发者,重点介绍 TiKV 的系统架构,源码结构,流程解析。目的是使得开发者阅读之后,能对 TiKV 项目有一个初步了解,更好的参与进入 TiKV 的开发中。需要注意,TiKV 使用 Rust 语言编写,用户需要对 Rust 语言有一个大概的了解。另外,本系列文章并不会涉及到 TiKV 中心控制服务 Placement Driver(PD) 的详细介绍,但是会说明一些重要流程 TiKV 是如何与 PD 交互的。TiKV 是一个分布式的 KV 系统,它采用 Raft 协议保证数据的强一致性,同时使用 MVCC + 2PC 的方式实现了分布式事务的支持。
本话题系列文章整理自 PingCAP Infra Meetup 第 26 期刘奇分享的《深度探索分布式系统测试》议题现场实录。文章较长,为方便大家阅读,会分为上中下三篇,本文为下篇。
事务隔离在数据库系统中有着非常重要的作用,因为对于用户来说数据库必须提供这样一个“假象”:当前只有这么一个用户连接到了数据库中,这样可以减轻应用层的开发难度。但是,对于数据库系统来说,因为同一时间可能会存在很多用户连接,那么许多并发问题,比如数据竞争(data race),就必须解决。在这样的背景下,数据库管理系统(简称 DBMS)就必须保证并发操作产生的结果是安全的,通过可串行化(serializability)来保证。
本文先概括的讲一下 Google Percolator 的大致流程。Percolator 是 Google 的上一代分布式事务解决方案,构建在 BigTable 之上,在 Google 内部用于网页索引更新的业务。TiDB 的事务模型沿用了 Percolator 的事务模型。
TiDB 是一个完全分布式的关系型数据库,从诞生的第一天起,我们就想让它来兼容 MySQL 语法,希望让原有的 MySQL 用户 (不管是单机的 MySQL,还是多机的 MySQL Sharding) 都可以在基本不修改代码的情况下,除了可以保留原有的 SQL 和 ACID 事务之外,还可以享受到分布式带来的高并发,高吞吐和 MPP 的高性能。
本话题系列文章整理自 PingCAP Infra Meetup 第 26 期刘奇分享的《深度探索分布式系统测试》议题现场实录。文章较长,为方便大家阅读,会分为上中下三篇,本文为中篇。
由于 TiDB 本身兼容绝大多数的 MySQL 语法,所以对于绝大多数业务来说,最安全的切换数据库方式就是将 TiDB 作为现有数据库的从库接在主 MySQL 库的后方,这样对业务方实现完全没有侵入性下使用 TiDB 对现有的业务进行备份,应对未来数据量或者并发量增长带来的单点故障风险,如需上线 TiDB,也只需要简单的将业务的主 MySQL 地址指向 TiDB 即可。
本话题系列文章整理自 PingCAP Infra Meetup 第 26 期刘奇分享的《深度探索分布式系统测试》议题现场实录。文章较长,为方便大家阅读,会分为上中下三篇,本文为上篇。
日前,PingCAP Engineering VP 申砾受邀参加 2016 中国开源年会,并发表了《Building a Reliable Large-Scale Distributed Database - Principles and Practice》主题演讲。本文为演讲实录。
数据作为业务的核心,关系着整个业务的生死,所以对于数据库来说,数据的安全性是放在首位的,从宏观角度来看,安全性不仅仅在于的数据库本身足够稳定不会主动的丢失数据,有的时候更是对业务本身甚至人为失误造成损失是否有足够且便捷的应对方案,例如在游戏行业中经常遇到的反作弊(作弊玩家回档)问题,对于金融业务的审计需求等等,如果在数据库层面上提供相关机制,会让业务开发的工作量和复杂度减少很多。
首先我们聊聊 Database 的历史,在已经有这么多种数据库的背景下我们为什么要创建另外一个数据库;以及说一下现在方案遇到的困境,说一下 Google Spanner 和 F1,TiKV 和 TiDB,说一下架构的事情,在这里我们会重点聊一下 TiKV。因为我们产品的很多特性是 TiKV 提供的,比如说跨数据中心的复制,Transaction,auto-scale...
日前,PingCAP 联合创始人兼 CTO 黄东旭在「2016中国数据分析师行业峰会(CDAS)」 “数据库与技术实战”分论坛上,分享了《分布式数据库模式与反模式》的主题演讲。本文为演讲实录。
随着时代的发展,应用和数据的规模越来越大。然而在这个一切都可以水平扩展的时代,你会发现,大多数应用的最下层的关系型数据库,竟然难以找到一个优雅易用的水平扩展解决方案,一直以来不得不依赖静态 Sharding ,牺牲掉事务,然后在业务层各种 Workarounds。作为后端开发者应该深有体会。
最近几年来,越来越多的文章介绍了 Raft 或者 Paxos 这样的分布式一致性算法,且主要集中在算法细节和日志同步方面的应用。但是呢,这些算法的潜力并不仅限于此,基于这样的分布式一致性算法构建一个完整的可弹性伸缩的高可用的大规模存储系统,是一个很新的课题,我结合我们这一年多以来在 TiKV 这样一个大规模分布式数据库上的实践,谈谈其中的一些设计和挑战。
最近几年,随着云计算相关技术的发展,各种不同类型的云层出不穷,服务越来越多不同类型的企业业务,传统企业也渐渐开始探索上云的道路。在云上,作为业务最核心的数据库,相比之前的传统方案会有哪些变化呢?在正式聊云时代的数据库特点之前,我们需要了解一下目前云时代架构发生的变化
子查询优化一直是 SQL 查询优化中非常难的一部分,尤其是关联子查询的改写。TiDB 为了兼容 MySQL,允许用户在任何位置编写子查询。对于非关联子查询,TiDB 会对其进行提前求值,对于关联子查询,TiDB 会尽可能的对其进行去关联化,例如改写成 SemiJoin。本文会重点介绍 TiDB 对关联子查询的优化手段。
TiDB 集群的架构分为上层的 SQL 层和底层的 KV 层,SQL 层通过调用 KV 层的 API 读写数据,由于 SQL 层的节点和 KV 层节点通常不在一台机器上,所以,每次调用 KV 的 API 都是一次 RPC, 而往往一个普通的 Select 语句的执行,需要调用几十到几十万次 KV 的接口,这样的结果就是性能非常差,绝大部分时间都消耗在 RPC 上。为了解决这个问题,TiDB 实现了下推 API,把一部分简单的 SQL 层的执行逻辑下推到 KV 层执行,让 KV 层可以理解 Table 和 Column,可以批量读取多行结果,可以用 Where 里的 Expression 对结果进行过滤, 可以计算聚合函数,大幅减少了 RPC 次数和数据的传输量。