When TiDB Meets Spark

本文整理自 TiSpark 项目发起人马晓宇在 Strata Data Conference 上分享的《When TiDB Meets Spark》演讲实录。

Linearizability 一致性验证

上篇文章介绍了 TiDB 如何使用 Jepsen 来进行一致性验证,并且介绍了具体的测试案例,但是并没有对 Jepsen 背后的一致性验证算法做过多介绍。这篇文章将会深入 Jepsen 的核心库 knossos,介绍 knossos 库所涉及的 Linearizability(线性化)一致性验证算法。

当 TiDB 遇上 Jepsen

本篇文章主要介绍 TiDB 是如何使用分布式一致性验证框架进行一致性验证的。

TiSpark (Beta) 用户指南

TiSpark 是 PingCAP 推出的为了解决用户复杂 OLAP 需求的产品。借助 Spark 平台本身的优势,同时融合 TiKV 分布式集群的优势,和 TiDB 一起为用户一站式解决 HTAP (Hybrid Transactional/Analytical Processing)需求。 TiSpark 依赖 TiKV 集群和 PD 的存在。当然,TiSpark 也需要你搭建一个 Spark 集群。本文简单介绍如何部署和使用 TiSpark。

PAX:一个 Cache 友好高效的行列混存方案

今年,Spanner 终于发了另一篇 Paper,Spanner - Becoming a SQL System,里面提到 Spanner 使用了一种新的存储格式 - Ressi,用来支持 OLTP 和 OLAP。在 Ressi 里面,使用了 PAX 来组织数据。因为 TiDB 定位就是一个 HTAP 系统,所以我也一直在思考在 TiKV 这层如何更好的存储数据,用来满足 HTAP 的需要,既然 Spanner 使用了 PAX,那么就有研究的必要了。

gRPC-rs:从 C 到 Rust

上篇文章中,我们讲到 TiKV 为了支持 gRPC,我们造了个轮子 gRPC-rs,本篇文章会简要地介绍一下这个库。

十分钟成为 Contributor 系列 | 重构内建函数进度报告

为了方便社区同学更好地参与 TiDB 项目,本文一方面对继上一篇文章发布后参考社区的反馈对表达式计算框架所做的修改进行详细介绍,另一方面对尚未重写的 built-in 函数进行陈列。

TiDB Best Practice

本文档用于总结在使用 TiDB 时候的一些最佳实践,主要涉及 SQL 使用、OLAP/OLTP 优化技巧,特别是一些 TiDB 专有的优化开关。建议先阅读讲解 TiDB 原理的三篇文章(讲存储,说计算,谈调度),再来看这篇文章。

工欲性能调优,必先利其器(2)- 火焰图

本篇文章将介绍一下,我们在 TiKV 性能调优上面用的最多的工具 - 火焰图。

十分钟成为 Contributor 系列 | 为 TiDB 重构 built-in 函数

为了加速表达式计算速度,最近我们对表达式的计算框架进行了重构,这篇教程为大家分享如何利用新的计算框架为 TiDB 重写或新增 built-in 函数。

深入了解 gRPC:协议

经过很长一段时间的开发,TiDB 终于发了 RC3。RC3 版本对于 TiKV 来说最重要的功能就是支持了 gRPC,也就意味着后面大家可以非常方便的使用自己喜欢的语言对接 TiKV 了。gRPC 是基于 HTTP/2 协议的,要深刻理解 gRPC,理解下 HTTP/2 是必要的,这里先简单介绍一下 HTTP/2 相关的知识,然后在介绍下 gRPC 是如何基于 HTTP/2 构建的。

来自 PingCAP CEO 的信:说在 B 轮融资完成之际

平时技术说得多,今天说点走心的。

使用 Ansible 安装部署 TiDB

作为一个分布式系统,在多个节点分别配置安装服务会相当繁琐。Ansible 是基于 Python 的自动化运维工具,糅合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能,而且使用简单,仅需在管理工作站上安装 Ansible 程序配置被管控主机的 IP 信息,被管控的主机无客户端。选用自动化工具 Ansible 来批量的安装、配置、部署 TiDB 。本文介绍如何通过 Ansible 工具来批量安装,使整个过程简单化。

三篇文章了解 TiDB 技术内幕 - 谈调度

任何一个复杂的系统,用户感知到的都只是冰山一角,数据库也不例外。前两篇文章介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理,这两个组件一个负责 KV 存储,一个负责 SQL 引擎,都是大家看得见的东西。在这两个组件的后面,还有一个叫做 PD(Placement Driver)的组件,虽然不直接和业务接触,但是这个组件是整个集群的核心,负责全局元信息的存储以及 TiKV 集群负载均衡调度。本篇文章介绍一下这个神秘的模块。这部分比较复杂,很多东西大家平时不会想到,也很少在其他文章中见到类似的东西的描述。我们还是按照前两篇的思路,先讲我们需要什么样的功能,再讲我们如何实现,大家带着需求去看实现,会更容易的理解我们做这些设计时背后的考量。

工欲性能调优,必先利其器(1)

最近在排查 TiDB 性能问题的时候,通过工具发现了一些问题,觉得有必要记录一下,让自己继续深刻的去理解相关工具的使用,也同时让同学们对类似问题的时候别再踩坑。

三篇文章了解 TiDB 技术内幕 - 说计算

上一篇介绍了 TiDB 如何存储数据,也就是 TiKV 的一些基本概念。本篇将介绍 TiDB 如何利用底层的 KV 存储,将关系模型映射为 Key-Value 模型,以及如何进行 SQL 计算。

三篇文章了解 TiDB 技术内幕 - 说存储

数据库、操作系统和编译器并称为三大系统,可以说是整个计算机软件的基石。其中数据库更靠近应用层,是很多业务的支撑。这一领域经过了几十年的发展,不断的有新的进展。很多人用过数据库,但是很少有人实现过一个数据库,特别是实现一个分布式数据库。了解数据库的实现原理和细节,一方面可以提高个人技术,对构建其他系统有帮助,另一方面也有利于用好数据库。研究一门技术最好的方法是研究其中一个开源项目,数据库也不例外。单机数据库领域有很多很好的开源项目,其中 MySQL 和 PostgreSQL 是其中知名度最高的两个,不少同学都看过这两个项目的代码。但是分布式数据库方面,好的开源项目并不多。 TiDB 目前获得了广泛的关注,特别是一些技术爱好者,希望能够参与这个项目。由于分布式数据库自身的复杂性,很多人并不能很好的理解整个项目,所以我希望能写一些文章,自顶向上,由浅入深,讲述 TiDB 的一些技术原理,包括用户可见的技术以及大量隐藏在 SQL 界面后用户不可见的技术点。

基于 Tile 连接 Row-Store 和 Column-Store

在之前的 Kudu 的文章里面已经提到过,行列混存是一个非常有意思的研究方向,因为不同的存储方式有不同的针对应用场景,但作为技术人员,折腾是天性,所以大家都在研究如何融合行存和列存,让一个服务能尽量满足大部分应用需求,而这也是 TiDB 在努力的方向。

Kudu - 一个融合低延迟写入和高性能分析的存储系统

Kudu 是一个基于 Raft 的分布式存储系统,它致力于融合低延迟写入和高性能分析这两种场景,并且能很好的嵌入到 Hadoop 生态系统里面,跟其他系统譬如 Cloudera Impala,Apache Spark 等对接。

演讲实录|黄东旭:Cloud-Native 的分布式数据库架构与实践

4 月 19 日,我司 CTO 黄东旭同学在全球云计算开源大会上,发表了《Cloud-Native 的分布式数据库架构与实践》主题演讲,以下为演讲实录。

如何从零开始参与大型开源项目

上世纪 70 年代,IBM 发明了关系型数据库。但是随着现在移动互联网的发展,接入设备越来越多,数据量越来越大,业务越来越复杂,传统的数据库显然已经不能满足海量数据存储的需求。虽然目前市场上也不乏分布式数据库模型,但没有品位的文艺青年不是好工程师,我们觉得,不,这些方案都不是我们想要的,它们不够美,鲜少能够把分布式事务与弹性扩展做到完美。

十分钟成为 TiDB Contributor 系列 | 添加內建函数

最近我们对 TiDB 代码做了些改进,大幅度简化了添加內建函数的流程,这篇教程描述如何为 TiDB 新增 builtin 函数。首先介绍一些必需的背景知识,然后介绍增加 builtin 函数的流程,最后会以一个函数作为示例。

TiKV 源码解析系列 - Raft 的优化

在分布式领域,为了保证数据的一致性,通常都会使用 Paxos 或者 Raft 来实现。但 Paxos 以其复杂难懂著称,相反 Raft 则是非常简单易懂,所以现在很多新兴的数据库都采用 Raft 作为其底层一致性算法,包括我们的 TiKV。

TiDB 的正确使用姿势

最近这几个月,特别是 TiDB RC1 发布后,越来越多的用户已经开始测试起来,也有很多朋友已经在生产环境中使用,我们这边也陆续的收到了很多用户的测试和使用反馈。非常感谢各位小伙伴和早期用户的厚爱,而且看了这么多场景后,也总结出了一些 TiDB 的使用实践 (其实 Spanner 的最佳实践大部分在 TiDB 中也是适用的,MySQL 最佳实践也是),也是借着 Google Cloud Spanner 发布的东风,看了一下 Spanner 官方的一些最佳实践文档,写篇文章讲讲 TiDB 以及分布式关系型数据库的一些正确的使用姿势,当然,时代也在一直发展,TiDB 也在不停的进化,这篇文章基本上只代表近期的一些观察。

TiKV 源码解析系列 - Lease Read

在 TiKV 里面,从最开始的 Raft log read,到后面的 Lease Read,我们一步一步的在保证线性一致性的情况下面改进着性能。后面,我们会引入更多的一致性测试 case 来验证整个系统的安全性,当然,也会持续的提升性能。

Spanner - CAP, TrueTime and Transaction

最近大家非常关注的一件事情就是 Google Spanner Cloud 的发布,这应该算是 NewSQL 又一个里程碑的事件。在本篇文章中,唐刘同学与大家分享了他自己对 Spanner 的理解,Spanner 的一些关键技术的实现以及与 TiDB 的相关对比。

TiKV 源码浅析 - PD Scheduler

在前面的文章里面,我们介绍了 PD 一些常用功能,以及它是如何跟 TiKV 进行交互的,这里,我们重点来介绍一下 PD 是如何调度 TiKV 的。

TiKV 源码解析系列 - Placement Driver

Placement Driver (后续以 PD 简称) 是 TiDB 里面全局中心总控节点,它负责整个集群的调度,负责全局 ID 的生成,以及全局时间戳 TSO 的生成等。PD 还保存着整个集群 TiKV 的元信息,负责给 client 提供路由功能。

TiKV 源码解析系列 - multi-raft 设计与实现

本文档主要面向 TiKV 社区开发者,主要介绍 TiKV 的系统架构,源码结构,流程解析。目的是使得开发者阅读文档之后,能对 TiKV 项目有一个初步了解,更好的参与进入 TiKV 的开发中。

TiKV 源码解析系列 - 如何使用 Raft

本系列文章主要面向 TiKV 社区开发者,重点介绍 TiKV 的系统架构,源码结构,流程解析。目的是使得开发者阅读之后,能对 TiKV 项目有一个初步了解,更好的参与进入 TiKV 的开发中。需要注意,TiKV 使用 Rust 语言编写,用户需要对 Rust 语言有一个大概的了解。另外,本系列文章并不会涉及到 TiKV 中心控制服务 Placement Driver(PD) 的详细介绍,但是会说明一些重要流程 TiKV 是如何与 PD 交互的。TiKV 是一个分布式的 KV 系统,它采用 Raft 协议保证数据的强一致性,同时使用 MVCC + 2PC 的方式实现了分布式事务的支持。

分布式系统测试那些事儿 - 信心的毁灭与重建

本话题系列文章整理自 PingCAP Infra Meetup 第 26 期刘奇分享的《深度探索分布式系统测试》议题现场实录。文章较长,为方便大家阅读,会分为上中下三篇,本文为下篇。

Percolator 和 TiDB 事务算法

本文先概括的讲一下 Google Percolator 的大致流程。Percolator 是 Google 的上一代分布式事务解决方案,构建在 BigTable 之上,在 Google 内部用于网页索引更新的业务。TiDB 的事务模型沿用了 Percolator 的事务模型。

TiKV 的 MVCC(Multi-Version Concurrency Control)机制

事务隔离在数据库系统中有着非常重要的作用,因为对于用户来说数据库必须提供这样一个“假象”:当前只有这么一个用户连接到了数据库中,这样可以减轻应用层的开发难度。但是,对于数据库系统来说,因为同一时间可能会存在很多用户连接,那么许多并发问题,比如数据竞争(data race),就必须解决。在这样的背景下,数据库管理系统(简称 DBMS)就必须保证并发操作产生的结果是安全的,通过可串行化(serializability)来保证。

解析 TiDB 在线数据同步工具 Syncer

TiDB 是一个完全分布式的关系型数据库,从诞生的第一天起,我们就想让它来兼容 MySQL 语法,希望让原有的 MySQL 用户 (不管是单机的 MySQL,还是多机的 MySQL Sharding) 都可以在基本不修改代码的情况下,除了可以保留原有的 SQL 和 ACID 事务之外,还可以享受到分布式带来的高并发,高吞吐和 MPP 的高性能。

通过 raft 的 leader lease 来解决集群脑裂时的 stale read 问题

当 raft group 发生脑裂的情况下,老的 raft leader 可能在一段时间内并不知道新的 leader 已经被选举出来,这时候客户端在老的 leader 上可能会读取出陈旧的数据(stale read)。TiDB 为 raft 引入 leader lease 机制解决这一问题。

MPP and SMP in TiDB

本篇文章整理自第 21 期 PingCAP Infra Meetup 上申砾分享的《MPP and SMP in TiDB》内容。

分布式系统测试那些事儿 - 错误注入

本话题系列文章整理自 PingCAP Infra Meetup 第 26 期刘奇分享的《深度探索分布式系统测试》议题现场实录。文章较长,为方便大家阅读,会分为上中下三篇,本文为中篇。

TiDB 作为 MySQL Slave 实现实时数据同步

由于 TiDB 本身兼容绝大多数的 MySQL 语法,所以对于绝大多数业务来说,最安全的切换数据库方式就是将 TiDB 作为现有数据库的从库接在主 MySQL 库的后方,这样对业务方实现完全没有侵入性下使用 TiDB 对现有的业务进行备份,应对未来数据量或者并发量增长带来的单点故障风险,如需上线 TiDB,也只需要简单的将业务的主 MySQL 地址指向 TiDB 即可。

分布式系统测试那些事儿 - 理念

本话题系列文章整理自 PingCAP Infra Meetup 第 26 期刘奇分享的《深度探索分布式系统测试》议题现场实录。文章较长,为方便大家阅读,会分为上中下三篇,本文为上篇。

Building a Reliable Large-Scale Distributed Database - Principles and Practice

日前,PingCAP Engineering VP 申砾受邀参加 2016 中国开源年会,并发表了《Building a Reliable Large-Scale Distributed Database - Principles and Practice》主题演讲。本文为演讲实录。

回到过去,找回遗失的珍宝 - TiDB 的历史读功能

数据作为业务的核心,关系着整个业务的生死,所以对于数据库来说,数据的安全性是放在首位的,从宏观角度来看,安全性不仅仅在于的数据库本身足够稳定不会主动的丢失数据,有的时候更是对业务本身甚至人为失误造成损失是否有足够且便捷的应对方案,例如在游戏行业中经常遇到的反作弊(作弊玩家回档)问题,对于金融业务的审计需求等等,如果在数据库层面上提供相关机制,会让业务开发的工作量和复杂度减少很多。

How do we build TiDB

首先我们聊聊 Database 的历史,在已经有这么多种数据库的背景下我们为什么要创建另外一个数据库;以及说一下现在方案遇到的困境,说一下 Google Spanner 和 F1,TiKV 和 TiDB,说一下架构的事情,在这里我们会重点聊一下 TiKV。因为我们产品的很多特性是 TiKV 提供的,比如说跨数据中心的复制,Transaction,auto-scale...

演讲实录|黄东旭:分布式数据库模式与反模式

日前,PingCAP 联合创始人兼 CTO 黄东旭在「2016中国数据分析师行业峰会(CDAS)」 “数据库与技术实战”分论坛上,分享了《分布式数据库模式与反模式》的主题演讲。本文为演讲实录。

TiKV 事务模型概览,Google Spanner 开源实现

随着时代的发展,应用和数据的规模越来越大。然而在这个一切都可以水平扩展的时代,你会发现,大多数应用的最下层的关系型数据库,竟然难以找到一个优雅易用的水平扩展解决方案,一直以来不得不依赖静态 Sharding ,牺牲掉事务,然后在业务层各种 Workarounds。作为后端开发者应该深有体会。

基于 Raft 构建弹性伸缩的存储系统的一些实践

最近几年来,越来越多的文章介绍了 Raft 或者 Paxos 这样的分布式一致性算法,且主要集中在算法细节和日志同步方面的应用。但是呢,这些算法的潜力并不仅限于此,基于这样的分布式一致性算法构建一个完整的可弹性伸缩的高可用的大规模存储系统,是一个很新的课题,我结合我们这一年多以来在 TiKV 这样一个大规模分布式数据库上的实践,谈谈其中的一些设计和挑战。

云时代数据库的核心特点

最近几年,随着云计算相关技术的发展,各种不同类型的云层出不穷,服务越来越多不同类型的企业业务,传统企业也渐渐开始探索上云的道路。在云上,作为业务最核心的数据库,相比之前的传统方案会有哪些变化呢?在正式聊云时代的数据库特点之前,我们需要了解一下目前云时代架构发生的变化

TiDB 中的子查询优化技术

子查询优化一直是 SQL 查询优化中非常难的一部分,尤其是关联子查询的改写。TiDB 为了兼容 MySQL,允许用户在任何位置编写子查询。对于非关联子查询,TiDB 会对其进行提前求值,对于关联子查询,TiDB 会尽可能的对其进行去关联化,例如改写成 SemiJoin。本文会重点介绍 TiDB 对关联子查询的优化手段。

TiDB 下推 API 实现细节 - Union Scan

TiDB 集群的架构分为上层的 SQL 层和底层的 KV 层,SQL 层通过调用 KV 层的 API 读写数据,由于 SQL 层的节点和 KV 层节点通常不在一台机器上,所以,每次调用 KV 的 API 都是一次 RPC, 而往往一个普通的 Select 语句的执行,需要调用几十到几十万次 KV 的接口,这样的结果就是性能非常差,绝大部分时间都消耗在 RPC 上。为了解决这个问题,TiDB 实现了下推 API,把一部分简单的 SQL 层的执行逻辑下推到 KV 层执行,让 KV 层可以理解 Table 和 Column,可以批量读取多行结果,可以用 Where 里的 Expression 对结果进行过滤, 可以计算聚合函数,大幅减少了 RPC 次数和数据的传输量。