TiDB

TiDB

TiDB Weekly [2017.02.13]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 283 次浏览 • 2017-02-18 13:54 • 来自相关话题

Weekly update in TiDB

Last two weeks, we landed 查看全部

Weekly update in TiDB


Last two weeks, we landed 25 PRs in the TiDB repositories.


Added



Fixed



Improved



Weekly update in TiKV


Last week, We landed 14 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2017.02.05]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 240 次浏览 • 2017-02-18 13:52 • 来自相关话题

Weekly update in TiDB

Last two weeks, we landed 查看全部

Weekly update in TiDB


Last two weeks, we landed 43 PRs in the TiDB repositories.


Added



Fixed



Improved



Weekly update in TiKV


Last two weeks, we landed 20 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

【PingCAP】SRE & Tools Engineer

招聘应聘qiuyesuifeng 发表了文章 • 0 个评论 • 397 次浏览 • 2017-02-18 13:45 • 来自相关话题

岗位职责:

  • 维护 TiDB 在生产系统中平稳运行,包括产品部署、监控和线上调试,及时应对并处理关键服务模块相关的问题
  • 构建各种自动化流程和工具,以自动化的手段应对任何发生过和预料会发生的情况和问题
  • <... 查看全部

岗位职责:



  • 维护 TiDB 在生产系统中平稳运行,包括产品部署、监控和线上调试,及时应对并处理关键服务模块相关的问题

  • 构建各种自动化流程和工具,以自动化的手段应对任何发生过和预料会发生的情况和问题

  • 针对系统能力和需求进行评估,软件性能分析和系统调优

  • 构建自动化测试系统,模拟各种灾难场景验证 TiDB 的可靠性,以测试驱动开发

  • 负责内部的 DevOps 平台建设,提升团队生产效率

  • TiDB 商业工具开发,包含自动化部署,数据迁移和同步工具,备份恢复工具,诊断和调试工具,系统监控工具等开发工作


职位要求:



  • 2 年以上在运维开发相关领域经验

  • 扎实的编程能力,熟悉 C/C++/Go/Rust/Python 一种编程语言,以及 shell/Perl 一种脚本语言

  • 具备大型分布式系统的监控、分析和故障排除等相关经验

  • 熟悉常用算法和数据结构,对操作系统和网络有深入的理解和应用经验

  • 良好的沟通能力和技巧


加分项:



  • 从事过 SRE 相关职位,具备 on-call 经历

  • 爱折腾,强烈的 Hack 精神

  • 熟悉 k8s 容器编排系统


待遇:


20K-40K + 期权, 13 薪 + 奖金, 优秀者可面议


联系方式:


hire@pingcap.com


地址:


北京市海淀区西小口路 66 号东升科技园 D-3 号楼 413


Or Remote

【PingCAP】Database Storage Engineer

招聘应聘qiuyesuifeng 发表了文章 • 0 个评论 • 353 次浏览 • 2017-02-18 13:43 • 来自相关话题

岗位职责:

  • 负责分布式数据库 TiKV 相关的设计,开发
  • 负责构建分布式压力测试框架,稳定性测试框架

职位要求:

  • 3 年以上相关领域开发经验,扎实的编程能力... 查看全部

岗位职责:



  • 负责分布式数据库 TiKV 相关的设计,开发

  • 负责构建分布式压力测试框架,稳定性测试框架


职位要求:



  • 3 年以上相关领域开发经验,扎实的编程能力,精通 C/C++/Go/Rust 中的一种

  • 对分布式系统的架构和原理有比较深入的了解

  • 优秀的发现和解决问题能力,良好的沟通能力,具备团队合作精神


加分项:



  • 拥抱开源,对前沿技术有浓厚的热情和探索欲望,有开源项目经历

  • 熟悉 Paxos/Raft 等分布式一致性算法

  • 熟悉分布式事务模型

  • 熟悉操作系统底层知识,有 TCP/IP, IO 等系统调优经验


待遇:


20K-40K + 期权, 13 薪 + 奖金, 优秀者可面议


联系方式:


hire@pingcap.com


地址:


北京市海淀区西小口路 66 号东升科技园 D-3 号楼 413
Or Remote

【PingCAP】Database Kernel Engineer

招聘应聘qiuyesuifeng 发表了文章 • 0 个评论 • 304 次浏览 • 2017-02-18 13:40 • 来自相关话题

岗位职责:

  • 负责分布式数据库查询优化器相关的设计,开发,文档撰写和新人指导
  • 负责分布式数据库 SQL 层的设计,开发和性能优化
  • 参与分布式数据库底层系统存储系统的设计
<... 查看全部

岗位职责:



  • 负责分布式数据库查询优化器相关的设计,开发,文档撰写和新人指导

  • 负责分布式数据库 SQL 层的设计,开发和性能优化

  • 参与分布式数据库底层系统存储系统的设计


职位要求:



  • 3 年以上相关领域开发经验,扎实的编程能力,熟悉 C/C++/Go/Java/Python 中的一种

  • 对分布式系统的架构和原理有比较深入的了解

  • 熟悉 MapReduce/Spark/Hive 等分布式计算框架中的一种或多种

  • 熟悉 MySQL/PostgreSQL/Greenplum 等数据库系统实现原理

  • 优秀的发现和解决问题能力,良好的沟通能力,具备团队合作精神


加分项:



  • 拥抱开源,对前沿技术有浓厚的热情和探索欲望,有开源项目经历

  • 熟悉 Spark 内核,并阅读过其中的源码

  • 熟悉 MySQL/PostgreSQL/Greenplum 的查询引擎,并阅读过其中的源码


待遇:


20K-40K + 期权, 13 薪 + 奖金, 优秀者可面议


联系方式:


hire@pingcap.com


地址:


北京市海淀区西小口路 66 号东升科技园 D-3 号楼 413
Or Remote

TiDB Weekly [2017.01.24]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 333 次浏览 • 2017-02-04 11:43 • 来自相关话题

Weekly update in TiDB

Last two weeks, we landed 查看全部

Weekly update in TiDB


Last two weeks, we landed 87 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last two weeks, We landed 50 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2017.01.08]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 253 次浏览 • 2017-02-04 11:42 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 38 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, We landed 15 PRs in the TiKV repositories.


Added



Fixed



  • Check cluseter ID to avoid PD joining different cluster.


Improved



原文链接

TiDB Weekly [2017.01.01]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 303 次浏览 • 2017-01-07 13:13 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 28 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, We landed 19 PRs in the TiKV repositories.


Added




  • Move raw_get to thread pool.




  • Add ResourceKind for operator and don't resend duplicated AddPeer response when the peer is still pending, see #449.



  • Add member command for pd-ctl.


Fixed



Improved



原文链接

TiDB Weekly [2016.12.26]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 265 次浏览 • 2017-01-07 13:12 • 来自相关话题

New Release

TiDB RC1 is released!

Weekly updat... 查看全部

New Release


TiDB RC1 is released!


Weekly update in TiDB


Last week, we landed 34 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, We landed 14 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2016.12.19]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 310 次浏览 • 2016-12-25 13:46 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 32 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, we landed 11 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2016.12.12]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 350 次浏览 • 2016-12-17 14:14 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 41 PRs in the TiDB repositories.


Added



Fixed



Improved



Weekly update in TiKV


Last week, we landed 34 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2016.12.05]

文章分享qiuyesuifeng 发表了文章 • 0 个评论 • 339 次浏览 • 2016-12-07 11:42 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 48 PRs in the TiDB repositories, 6 PRs in the TiDB docs repositories.


Added



Fixed



Improved



Document change


The following guides are updated:



Weekly update in TiKV


Last week, we landed 22 PRs in the TiKV repositories.


Added



Fixed



Improved




  • Replace the score type with resource kind to calculate the scores more easily.




  • Replace origin concept balance with schedule and simplify configurations.



  • Use coordinator to control the speed of different schedulers.


原文链接

TiDB Weekly [2016.11.28]

文章分享qiuyesuifeng 发表了文章 • 0 个评论 • 312 次浏览 • 2016-11-30 12:12 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 44 PRs in the TiDB repositories, 3 PRs in the TiDB docs repositories.


Added



Fixed



+ Add sequence number in binlog to preserve the original mutation order.



Improved



Document change


Add the following new guides:



Weekly update in TiKV


Last week, we landed 20 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

Percolator 和 TiDB 事务算法

文章分享qiuyesuifeng 发表了文章 • 1 个评论 • 789 次浏览 • 2016-11-24 11:24 • 来自相关话题

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

本文先概括的讲一下 Google Percolator 的大致流程。Percolator 是 Google 的上一代分布式事务解决方案,构建在 BigTable 之上,在 Google 内部 用于网页索引更新的业务,原始的论文在此。原理比较简单,总体来说就是一个经过优化的二阶段提交的实现,进行了一个二级锁的优化。TiDB 的事务模型沿用了 Percolator 的事务模型。
总体的流程如下:


读写事务


1) 事务提交前,在客户端 buffer 所有的 update/delete 操作。
2) Prewrite 阶段:


首先在所有行的写操作中选出一个作为 primary,其他的为 secondaries。


PrewritePrimary: 对 primaryRow 写入 L 列(上锁),L 列中记录本次事务的开始时间戳。写入 L 列前会检查:



  1. 是否已经有别的客户端已经上锁 (Locking)。

  2. 是否在本次事务开始时间之后,检查 W 列,是否有更新 [startTs, +Inf) 的写操作已经提交 (Conflict)。


在这两种种情况下会返回事务冲突。否则,就成功上锁。将行的内容写入 row 中,时间戳设置为 startTs。


将 primaryRow 的锁上好了以后,进行 secondaries 的 prewrite 流程:



  1. 类似 primaryRow 的上锁流程,只不过锁的内容为事务开始时间及 primaryRow 的 Lock 的信息。

  2. 检查的事项同 primaryRow 的一致。


当锁成功写入后,写入 row,时间戳设置为 startTs。


3) 以上 Prewrite 流程任何一步发生错误,都会进行回滚:删除 Lock,删除版本为 startTs 的数据。


4) 当 Prewrite 完成以后,进入 Commit 阶段,当前时间戳为 commitTs,且 commitTs> startTs :



  1. commit primary:写入 W 列新数据,时间戳为 commitTs,内容为 startTs,表明数据的最新版本是 startTs 对应的数据。

  2. 删除L列。


如果 primary row 提交失败的话,全事务回滚,回滚逻辑同 prewrite。如果 commit primary 成功,则可以异步的 commit secondaries, 流程和 commit primary 一致, 失败了也无所谓。


事务中的读操作



  1. 检查该行是否有 L 列,时间戳为 [0, startTs],如果有,表示目前有其他事务正占用此行,如果这个锁已经超时则尝试清除,否则等待超时或者其他事务主动解锁。注意此时不能直接返回老版本的数据,否则会发生幻读的问题。

  2. 读取至 startTs 时该行最新的数据,方法是:读取 W 列,时间戳为 [0, startTs], 获取这一列的值,转化成时间戳 t, 然后读取此列于 t 版本的数据内容。


由于锁是分两级的,primary 和 seconary,只要 primary 的行锁去掉,就表示该事务已经成功 提交,这样的好处是 secondary 的 commit 是可以异步进行的,只是在异步提交进行的过程中 ,如果此时有读请求,可能会需要做一下锁的清理工作。


原文链接

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

文章分享qiuyesuifeng 发表了文章 • 0 个评论 • 448 次浏览 • 2016-11-24 11:20 • 来自相关话题

并发控制简介

事务隔离在数据库系统中有着非常重要的作用,因为对于用户来说数据库必须提供这样一个“假象”:当前只有这么一个用户连接到了数据库中,这样可以减轻应用层的开发难度。但是,对于数据库系统来说,因为同一时间可能会存在很多用户连接,那... 查看全部

并发控制简介


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


虽然 Serilizability 是一个非常棒的概念,但是很难能够有效的实现。一个经典的方法就是使用一种两段锁(2PL)。通过 2PL,DBMS 可以维护读写锁来保证可能产生冲突的事务按照一个良好的次序(well-defined) 执行,这样就可以保证 Serializability。但是,这种通过锁的方式也有一些缺点:



  1. 读锁和写锁会相互阻滞(block)。

  2. 大部分事务都是只读(read-only)的,所以从事务序列(transaction-ordering)的角度来看是无害的。如果使用基于锁的隔离机制,而且如果有一段很长的读事务的话,在这段时间内这个对象就无法被改写,后面的事务就会被阻塞直到这个事务完成。这种机制对于并发性能来说影响很大。


多版本并发控制(Multi-Version Concurrency Control, 以下简称 MVCC)以一种优雅的方式来解决这个问题。在 MVCC 中,每当想要更改或者删除某个数据对象时,DBMS 不会在原地去删除或这修改这个已有的数据对象本身,而是创建一个该数据对象的新的版本,这样的话同时并发的读取操作仍旧可以读取老版本的数据,而写操作就可以同时进行。这个模式的好处在于,可以让读取操作不再阻塞,事实上根本就不需要锁。这是一种非常诱人的特型,以至于在很多主流的数据库中都采用了 MVCC 的实现,比如说 PostgreSQL,Oracle,Microsoft SQL Server 等。


TiKV 中的 MVCC


让我们深入到 TiKV 中的 MVCC,了解 MVCC 在 TiKV 中是如何实现的。


Timestamp Oracle(TSO)


因为TiKV 是一个分布式的储存系统,它需要一个全球性的授时服务,下文都称作 TSO(Timestamp Oracle),来分配一个单调递增的时间戳。 这样的功能在 TiKV 中是由 PD 提供的,在 Google 的 Spanner 中是由多个原子钟和 GPS 来提供的。


Storage


从源码结构上来看,想要深入理解 TiKV 中的 MVCC 部分,src/storage 是一个非常好的入手点。 Storage 是实际上接受外部命令的结构体。


pub struct Storage {
engine: Box<Engine>,
sendch: SendCh<Msg>,
handle: Arc<Mutex<StorageHandle>>,
}

impl Storage {
pub fn start(&mut self, config: &Config) -> Result<()> {
let mut handle = self.handle.lock().unwrap();
if handle.handle.is_some() {
return Err(box_err!("scheduler is already running"));
}

let engine = self.engine.clone();
let builder = thread::Builder::new().name(thd_name!("storage-scheduler"));
let mut el = handle.event_loop.take().unwrap();
let sched_concurrency = config.sched_concurrency;
let sched_worker_pool_size = config.sched_worker_pool_size;
let sched_too_busy_threshold = config.sched_too_busy_threshold;
let ch = self.sendch.clone();
let h = try!(builder.spawn(move || {
let mut sched = Scheduler::new(engine,
ch,
sched_concurrency,
sched_worker_pool_size,
sched_too_busy_threshold);
if let Err(e) = el.run(&mut sched) {
panic!("scheduler run err:{:?}", e);
}
info!("scheduler stopped");
}));
handle.handle = Some(h);

Ok(())
}
}

start 这个函数很好的解释了一个 storage 是怎么跑起来的。


Engine


首先是 EngineEngine 是一个描述了在储存系统中接入的的实际上的数据库的接口,raftkvEnginerocksdb 分别实现了这个接口。


StorageHandle


StorageHanle 是处理从sench 接受到指令,通过 mio 来处理 IO。


接下来在Storage中实现了async_getasync_batch_get等异步函数,这些函数中将对应的指令送到通道中,然后被调度器(scheduler)接收到并异步执行。


Ok,了解完Storage 结构体是如何实现的之后,我们终于可以接触到在Scheduler 被调用的 MVCC 层了。


当 storage 接收到从客户端来的指令后会将其传送到调度器中。然后调度器执行相应的过程或者调用相应的异步函数。在调度器中有两种操作类型,读和写。读操作在 MvccReader 中实现,这一部分很容易理解,暂且不表。写操作的部分是MVCC的核心。


MVCC


Ok,两段提交(2-Phase Commit,2PC)是在 MVCC 中实现的,整个 TiKV 事务模型的核心。在一段事务中,由两个阶段组成。


Prewrite

选择一个 row 作为 primary row, 余下的作为 secondary row。
对primary row 上锁. 在上锁之前,会检查是否有其他同步的锁已经上到了这个 row 上 或者是是否经有在 startTS 之后的提交操作。这两种情况都会导致冲突,一旦都冲突发生,就会回滚(rollback)
对于 secondary row 重复以上操作。


Commit

RollbackPrewrite 过程中出现冲突的话就会被调用。


Garbage Collector

很容易发现,如果没有垃圾收集器(Gabage Collector) 来移除无效的版本的话,数据库中就会存有越来越多的 MVCC 版本。但是我们又不能仅仅移除某个 safe point 之前的所有版本。因为对于某个 key 来说,有可能只存在一个版本,那么这个版本就必须被保存下来。在TiKV中,如果在 safe point 前存在Put 或者Delete,那么说明之后所有的 writes 都是可以被移除的,不然的话只有DeleteRollbackLock 会被删除。


TiKV-Ctl for MVCC


在开发和 debug 的过程中,我们发现查询 MVCC 的版本信息是一件非常频繁并且重要的操作。因此我们开发了新的工具来查询 MVCC 信息。TiKV 将 Key-Value,Locks 和Writes 分别储存在CF_DEFAULTCF_LOCKCF_WRITE中。它们以这样的格式进行编码

























default lock write
key z{encoded_key}{start_ts(desc)} z{encoded_key} z{encoded_key}{commit_ts(desc)}
value {value} {flag}{primary_key}{start_ts(varint)} {flag}{start_ts(varint)}

Details can be found here.


因为所有的 MVCC 信息在 Rocksdb 中都是储存在 CF Key-Value 中,所以想要查询一个 Key 的版本信息,我们只需要将这些信息以不同的方式编码,随后在对应的 CF 中查询即可。CF Key-Values 的表示形式


原文链接

[校招][实习] PingCAP 招前端开发工程师

回复

招聘应聘qiuyesuifeng 发起了问题 • 1 人关注 • 0 个回复 • 835 次浏览 • 2016-10-11 14:30 • 来自相关话题

[校招][实习] PingCAP 招后端开发工程师

回复

招聘应聘qiuyesuifeng 发起了问题 • 1 人关注 • 0 个回复 • 902 次浏览 • 2016-10-11 14:27 • 来自相关话题

TiDB Weekly [2017.02.13]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 283 次浏览 • 2017-02-18 13:54 • 来自相关话题

Weekly update in TiDB

Last two weeks, we landed 查看全部

Weekly update in TiDB


Last two weeks, we landed 25 PRs in the TiDB repositories.


Added



Fixed



Improved



Weekly update in TiKV


Last week, We landed 14 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2017.02.05]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 240 次浏览 • 2017-02-18 13:52 • 来自相关话题

Weekly update in TiDB

Last two weeks, we landed 查看全部

Weekly update in TiDB


Last two weeks, we landed 43 PRs in the TiDB repositories.


Added



Fixed



Improved



Weekly update in TiKV


Last two weeks, we landed 20 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

【PingCAP】SRE & Tools Engineer

招聘应聘qiuyesuifeng 发表了文章 • 0 个评论 • 397 次浏览 • 2017-02-18 13:45 • 来自相关话题

岗位职责:

  • 维护 TiDB 在生产系统中平稳运行,包括产品部署、监控和线上调试,及时应对并处理关键服务模块相关的问题
  • 构建各种自动化流程和工具,以自动化的手段应对任何发生过和预料会发生的情况和问题
  • <... 查看全部

岗位职责:



  • 维护 TiDB 在生产系统中平稳运行,包括产品部署、监控和线上调试,及时应对并处理关键服务模块相关的问题

  • 构建各种自动化流程和工具,以自动化的手段应对任何发生过和预料会发生的情况和问题

  • 针对系统能力和需求进行评估,软件性能分析和系统调优

  • 构建自动化测试系统,模拟各种灾难场景验证 TiDB 的可靠性,以测试驱动开发

  • 负责内部的 DevOps 平台建设,提升团队生产效率

  • TiDB 商业工具开发,包含自动化部署,数据迁移和同步工具,备份恢复工具,诊断和调试工具,系统监控工具等开发工作


职位要求:



  • 2 年以上在运维开发相关领域经验

  • 扎实的编程能力,熟悉 C/C++/Go/Rust/Python 一种编程语言,以及 shell/Perl 一种脚本语言

  • 具备大型分布式系统的监控、分析和故障排除等相关经验

  • 熟悉常用算法和数据结构,对操作系统和网络有深入的理解和应用经验

  • 良好的沟通能力和技巧


加分项:



  • 从事过 SRE 相关职位,具备 on-call 经历

  • 爱折腾,强烈的 Hack 精神

  • 熟悉 k8s 容器编排系统


待遇:


20K-40K + 期权, 13 薪 + 奖金, 优秀者可面议


联系方式:


hire@pingcap.com


地址:


北京市海淀区西小口路 66 号东升科技园 D-3 号楼 413


Or Remote

【PingCAP】Database Storage Engineer

招聘应聘qiuyesuifeng 发表了文章 • 0 个评论 • 353 次浏览 • 2017-02-18 13:43 • 来自相关话题

岗位职责:

  • 负责分布式数据库 TiKV 相关的设计,开发
  • 负责构建分布式压力测试框架,稳定性测试框架

职位要求:

  • 3 年以上相关领域开发经验,扎实的编程能力... 查看全部

岗位职责:



  • 负责分布式数据库 TiKV 相关的设计,开发

  • 负责构建分布式压力测试框架,稳定性测试框架


职位要求:



  • 3 年以上相关领域开发经验,扎实的编程能力,精通 C/C++/Go/Rust 中的一种

  • 对分布式系统的架构和原理有比较深入的了解

  • 优秀的发现和解决问题能力,良好的沟通能力,具备团队合作精神


加分项:



  • 拥抱开源,对前沿技术有浓厚的热情和探索欲望,有开源项目经历

  • 熟悉 Paxos/Raft 等分布式一致性算法

  • 熟悉分布式事务模型

  • 熟悉操作系统底层知识,有 TCP/IP, IO 等系统调优经验


待遇:


20K-40K + 期权, 13 薪 + 奖金, 优秀者可面议


联系方式:


hire@pingcap.com


地址:


北京市海淀区西小口路 66 号东升科技园 D-3 号楼 413
Or Remote

【PingCAP】Database Kernel Engineer

招聘应聘qiuyesuifeng 发表了文章 • 0 个评论 • 304 次浏览 • 2017-02-18 13:40 • 来自相关话题

岗位职责:

  • 负责分布式数据库查询优化器相关的设计,开发,文档撰写和新人指导
  • 负责分布式数据库 SQL 层的设计,开发和性能优化
  • 参与分布式数据库底层系统存储系统的设计
<... 查看全部

岗位职责:



  • 负责分布式数据库查询优化器相关的设计,开发,文档撰写和新人指导

  • 负责分布式数据库 SQL 层的设计,开发和性能优化

  • 参与分布式数据库底层系统存储系统的设计


职位要求:



  • 3 年以上相关领域开发经验,扎实的编程能力,熟悉 C/C++/Go/Java/Python 中的一种

  • 对分布式系统的架构和原理有比较深入的了解

  • 熟悉 MapReduce/Spark/Hive 等分布式计算框架中的一种或多种

  • 熟悉 MySQL/PostgreSQL/Greenplum 等数据库系统实现原理

  • 优秀的发现和解决问题能力,良好的沟通能力,具备团队合作精神


加分项:



  • 拥抱开源,对前沿技术有浓厚的热情和探索欲望,有开源项目经历

  • 熟悉 Spark 内核,并阅读过其中的源码

  • 熟悉 MySQL/PostgreSQL/Greenplum 的查询引擎,并阅读过其中的源码


待遇:


20K-40K + 期权, 13 薪 + 奖金, 优秀者可面议


联系方式:


hire@pingcap.com


地址:


北京市海淀区西小口路 66 号东升科技园 D-3 号楼 413
Or Remote

TiDB Weekly [2017.01.24]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 333 次浏览 • 2017-02-04 11:43 • 来自相关话题

Weekly update in TiDB

Last two weeks, we landed 查看全部

Weekly update in TiDB


Last two weeks, we landed 87 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last two weeks, We landed 50 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2017.01.08]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 253 次浏览 • 2017-02-04 11:42 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 38 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, We landed 15 PRs in the TiKV repositories.


Added



Fixed



  • Check cluseter ID to avoid PD joining different cluster.


Improved



原文链接

TiDB Weekly [2017.01.01]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 303 次浏览 • 2017-01-07 13:13 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 28 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, We landed 19 PRs in the TiKV repositories.


Added




  • Move raw_get to thread pool.




  • Add ResourceKind for operator and don't resend duplicated AddPeer response when the peer is still pending, see #449.



  • Add member command for pd-ctl.


Fixed



Improved



原文链接

TiDB Weekly [2016.12.26]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 265 次浏览 • 2017-01-07 13:12 • 来自相关话题

New Release

TiDB RC1 is released!

Weekly updat... 查看全部

New Release


TiDB RC1 is released!


Weekly update in TiDB


Last week, we landed 34 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, We landed 14 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2016.12.19]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 310 次浏览 • 2016-12-25 13:46 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 32 PRs in the TiDB repositories.


Added



Fixed



Improved



New contributor



Weekly update in TiKV


Last week, we landed 11 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2016.12.12]

Go开源项目qiuyesuifeng 发表了文章 • 0 个评论 • 350 次浏览 • 2016-12-17 14:14 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 41 PRs in the TiDB repositories.


Added



Fixed



Improved



Weekly update in TiKV


Last week, we landed 34 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

TiDB Weekly [2016.12.05]

文章分享qiuyesuifeng 发表了文章 • 0 个评论 • 339 次浏览 • 2016-12-07 11:42 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 48 PRs in the TiDB repositories, 6 PRs in the TiDB docs repositories.


Added



Fixed



Improved



Document change


The following guides are updated:



Weekly update in TiKV


Last week, we landed 22 PRs in the TiKV repositories.


Added



Fixed



Improved




  • Replace the score type with resource kind to calculate the scores more easily.




  • Replace origin concept balance with schedule and simplify configurations.



  • Use coordinator to control the speed of different schedulers.


原文链接

TiDB Weekly [2016.11.28]

文章分享qiuyesuifeng 发表了文章 • 0 个评论 • 312 次浏览 • 2016-11-30 12:12 • 来自相关话题

Weekly update in TiDB

Last week, we landed 查看全部

Weekly update in TiDB


Last week, we landed 44 PRs in the TiDB repositories, 3 PRs in the TiDB docs repositories.


Added



Fixed



+ Add sequence number in binlog to preserve the original mutation order.



Improved



Document change


Add the following new guides:



Weekly update in TiKV


Last week, we landed 20 PRs in the TiKV repositories.


Added



Fixed



Improved



原文链接

Percolator 和 TiDB 事务算法

文章分享qiuyesuifeng 发表了文章 • 1 个评论 • 789 次浏览 • 2016-11-24 11:24 • 来自相关话题

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

本文先概括的讲一下 Google Percolator 的大致流程。Percolator 是 Google 的上一代分布式事务解决方案,构建在 BigTable 之上,在 Google 内部 用于网页索引更新的业务,原始的论文在此。原理比较简单,总体来说就是一个经过优化的二阶段提交的实现,进行了一个二级锁的优化。TiDB 的事务模型沿用了 Percolator 的事务模型。
总体的流程如下:


读写事务


1) 事务提交前,在客户端 buffer 所有的 update/delete 操作。
2) Prewrite 阶段:


首先在所有行的写操作中选出一个作为 primary,其他的为 secondaries。


PrewritePrimary: 对 primaryRow 写入 L 列(上锁),L 列中记录本次事务的开始时间戳。写入 L 列前会检查:



  1. 是否已经有别的客户端已经上锁 (Locking)。

  2. 是否在本次事务开始时间之后,检查 W 列,是否有更新 [startTs, +Inf) 的写操作已经提交 (Conflict)。


在这两种种情况下会返回事务冲突。否则,就成功上锁。将行的内容写入 row 中,时间戳设置为 startTs。


将 primaryRow 的锁上好了以后,进行 secondaries 的 prewrite 流程:



  1. 类似 primaryRow 的上锁流程,只不过锁的内容为事务开始时间及 primaryRow 的 Lock 的信息。

  2. 检查的事项同 primaryRow 的一致。


当锁成功写入后,写入 row,时间戳设置为 startTs。


3) 以上 Prewrite 流程任何一步发生错误,都会进行回滚:删除 Lock,删除版本为 startTs 的数据。


4) 当 Prewrite 完成以后,进入 Commit 阶段,当前时间戳为 commitTs,且 commitTs> startTs :



  1. commit primary:写入 W 列新数据,时间戳为 commitTs,内容为 startTs,表明数据的最新版本是 startTs 对应的数据。

  2. 删除L列。


如果 primary row 提交失败的话,全事务回滚,回滚逻辑同 prewrite。如果 commit primary 成功,则可以异步的 commit secondaries, 流程和 commit primary 一致, 失败了也无所谓。


事务中的读操作



  1. 检查该行是否有 L 列,时间戳为 [0, startTs],如果有,表示目前有其他事务正占用此行,如果这个锁已经超时则尝试清除,否则等待超时或者其他事务主动解锁。注意此时不能直接返回老版本的数据,否则会发生幻读的问题。

  2. 读取至 startTs 时该行最新的数据,方法是:读取 W 列,时间戳为 [0, startTs], 获取这一列的值,转化成时间戳 t, 然后读取此列于 t 版本的数据内容。


由于锁是分两级的,primary 和 seconary,只要 primary 的行锁去掉,就表示该事务已经成功 提交,这样的好处是 secondary 的 commit 是可以异步进行的,只是在异步提交进行的过程中 ,如果此时有读请求,可能会需要做一下锁的清理工作。


原文链接

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

文章分享qiuyesuifeng 发表了文章 • 0 个评论 • 448 次浏览 • 2016-11-24 11:20 • 来自相关话题

并发控制简介

事务隔离在数据库系统中有着非常重要的作用,因为对于用户来说数据库必须提供这样一个“假象”:当前只有这么一个用户连接到了数据库中,这样可以减轻应用层的开发难度。但是,对于数据库系统来说,因为同一时间可能会存在很多用户连接,那... 查看全部

并发控制简介


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


虽然 Serilizability 是一个非常棒的概念,但是很难能够有效的实现。一个经典的方法就是使用一种两段锁(2PL)。通过 2PL,DBMS 可以维护读写锁来保证可能产生冲突的事务按照一个良好的次序(well-defined) 执行,这样就可以保证 Serializability。但是,这种通过锁的方式也有一些缺点:



  1. 读锁和写锁会相互阻滞(block)。

  2. 大部分事务都是只读(read-only)的,所以从事务序列(transaction-ordering)的角度来看是无害的。如果使用基于锁的隔离机制,而且如果有一段很长的读事务的话,在这段时间内这个对象就无法被改写,后面的事务就会被阻塞直到这个事务完成。这种机制对于并发性能来说影响很大。


多版本并发控制(Multi-Version Concurrency Control, 以下简称 MVCC)以一种优雅的方式来解决这个问题。在 MVCC 中,每当想要更改或者删除某个数据对象时,DBMS 不会在原地去删除或这修改这个已有的数据对象本身,而是创建一个该数据对象的新的版本,这样的话同时并发的读取操作仍旧可以读取老版本的数据,而写操作就可以同时进行。这个模式的好处在于,可以让读取操作不再阻塞,事实上根本就不需要锁。这是一种非常诱人的特型,以至于在很多主流的数据库中都采用了 MVCC 的实现,比如说 PostgreSQL,Oracle,Microsoft SQL Server 等。


TiKV 中的 MVCC


让我们深入到 TiKV 中的 MVCC,了解 MVCC 在 TiKV 中是如何实现的。


Timestamp Oracle(TSO)


因为TiKV 是一个分布式的储存系统,它需要一个全球性的授时服务,下文都称作 TSO(Timestamp Oracle),来分配一个单调递增的时间戳。 这样的功能在 TiKV 中是由 PD 提供的,在 Google 的 Spanner 中是由多个原子钟和 GPS 来提供的。


Storage


从源码结构上来看,想要深入理解 TiKV 中的 MVCC 部分,src/storage 是一个非常好的入手点。 Storage 是实际上接受外部命令的结构体。


pub struct Storage {
engine: Box<Engine>,
sendch: SendCh<Msg>,
handle: Arc<Mutex<StorageHandle>>,
}

impl Storage {
pub fn start(&mut self, config: &Config) -> Result<()> {
let mut handle = self.handle.lock().unwrap();
if handle.handle.is_some() {
return Err(box_err!("scheduler is already running"));
}

let engine = self.engine.clone();
let builder = thread::Builder::new().name(thd_name!("storage-scheduler"));
let mut el = handle.event_loop.take().unwrap();
let sched_concurrency = config.sched_concurrency;
let sched_worker_pool_size = config.sched_worker_pool_size;
let sched_too_busy_threshold = config.sched_too_busy_threshold;
let ch = self.sendch.clone();
let h = try!(builder.spawn(move || {
let mut sched = Scheduler::new(engine,
ch,
sched_concurrency,
sched_worker_pool_size,
sched_too_busy_threshold);
if let Err(e) = el.run(&mut sched) {
panic!("scheduler run err:{:?}", e);
}
info!("scheduler stopped");
}));
handle.handle = Some(h);

Ok(())
}
}

start 这个函数很好的解释了一个 storage 是怎么跑起来的。


Engine


首先是 EngineEngine 是一个描述了在储存系统中接入的的实际上的数据库的接口,raftkvEnginerocksdb 分别实现了这个接口。


StorageHandle


StorageHanle 是处理从sench 接受到指令,通过 mio 来处理 IO。


接下来在Storage中实现了async_getasync_batch_get等异步函数,这些函数中将对应的指令送到通道中,然后被调度器(scheduler)接收到并异步执行。


Ok,了解完Storage 结构体是如何实现的之后,我们终于可以接触到在Scheduler 被调用的 MVCC 层了。


当 storage 接收到从客户端来的指令后会将其传送到调度器中。然后调度器执行相应的过程或者调用相应的异步函数。在调度器中有两种操作类型,读和写。读操作在 MvccReader 中实现,这一部分很容易理解,暂且不表。写操作的部分是MVCC的核心。


MVCC


Ok,两段提交(2-Phase Commit,2PC)是在 MVCC 中实现的,整个 TiKV 事务模型的核心。在一段事务中,由两个阶段组成。


Prewrite

选择一个 row 作为 primary row, 余下的作为 secondary row。
对primary row 上锁. 在上锁之前,会检查是否有其他同步的锁已经上到了这个 row 上 或者是是否经有在 startTS 之后的提交操作。这两种情况都会导致冲突,一旦都冲突发生,就会回滚(rollback)
对于 secondary row 重复以上操作。


Commit

RollbackPrewrite 过程中出现冲突的话就会被调用。


Garbage Collector

很容易发现,如果没有垃圾收集器(Gabage Collector) 来移除无效的版本的话,数据库中就会存有越来越多的 MVCC 版本。但是我们又不能仅仅移除某个 safe point 之前的所有版本。因为对于某个 key 来说,有可能只存在一个版本,那么这个版本就必须被保存下来。在TiKV中,如果在 safe point 前存在Put 或者Delete,那么说明之后所有的 writes 都是可以被移除的,不然的话只有DeleteRollbackLock 会被删除。


TiKV-Ctl for MVCC


在开发和 debug 的过程中,我们发现查询 MVCC 的版本信息是一件非常频繁并且重要的操作。因此我们开发了新的工具来查询 MVCC 信息。TiKV 将 Key-Value,Locks 和Writes 分别储存在CF_DEFAULTCF_LOCKCF_WRITE中。它们以这样的格式进行编码

























default lock write
key z{encoded_key}{start_ts(desc)} z{encoded_key} z{encoded_key}{commit_ts(desc)}
value {value} {flag}{primary_key}{start_ts(varint)} {flag}{start_ts(varint)}

Details can be found here.


因为所有的 MVCC 信息在 Rocksdb 中都是储存在 CF Key-Value 中,所以想要查询一个 Key 的版本信息,我们只需要将这些信息以不同的方式编码,随后在对应的 CF 中查询即可。CF Key-Values 的表示形式


原文链接