PingCAP
  • PingCAP University
  • 文档
  • 案例
  • 社区
  • 博客
  • 关于
  • 问答
  • 联系我们
PingCAP
  • 文档
  • 案例
  • 社区
  • 博客
  • 关于
  • 问答
  • 联系我们
  • PingCAP University

Contact

  • Wechat qrCode

    微信扫一扫
    微信ID:pingcap2015

English
热门标签
ALL (173)
Contributor (9) DM-源码阅读 (10) Go (2) HTAP (2) Hackathon (4) K8s (2) MVCC (2) MySQL (2) PD (5) Percolator (2) Prometheus (3) Raft (11) RocksDB (3) Rust (3) SQL (5) Spanner (2) TiDB (56) TiDB-Binlog (4) TiDB-Binlog-源码阅读 (6) TiDB-Ecosystem-Tools (3) TiDB-Operator (5) TiDB-源码阅读 (24) TiKV (26) TiKV-源码解析 (16) TiSpark (2) WebAssembly (2) gRPC (2) 事务 (4) 优化器 (2) 分布式系统测试 (3) 工具 (4) 性能 (4) 数据同步 (2) 最佳实践 (6) 架构 (5) 社区 (83) 社区动态 (13) 集群调度 (2)

当我们在谈论 TiDB DevCon2018 时我们在谈论什么

  • Date iconMon, Jan 22, 2018
  • Pen iconPingCAP

上周六,小伙伴们期待已久的 TiDB DevCon 终于在北京·车库咖啡和大家见面啦~尽管是寒冷的冬天,但丝毫没有影响小伙伴们的参会热情。

在本次活动上,我们为大家分享了 TiDB 最新的项目进展以及 2018 年的 Roadmap。

在过去 2017 年,我们从公司、到社区、再到产品特性,都发生了很大的变化。

2016 年的 PingCAP 只有 35 个小伙伴,到现在PingCAP 团队有 91 人。从人员的规模上面来讲,我们增加了 2.6 倍。

但是其它方面的指标增加了更多~

社区

  • GitHub 的 Star 数从 2017 年 1 月的 7149 到现在的 14000 多,由下图可见整体呈非常稳定的线性增长;

  • Contributor 的数量由 2017 年的 95 个增加到 2018 年的 213 个,总体上增加 126%;

  • 实际的用户数量,从 2017 年初的 4 个线上的用户增加到现在可统计到的 200 +,数据增加了 50 倍。

如今,随着 TiDB Community 的不断完善,committer 的晋升机制也在不断优化中,在本次活动上,特设置了 committer 授予环节,3 位新晋 committer 也正式与大家见面啦~

>左二至右一:李雨来、吴镝、李凯

合作

目前,PingCAP 已与多家云厂商达成合作,2018 年预计还会增加 2 到 3 个 Cloud 合作伙伴。

活动现场,我们也邀请了来自 Mobike、今日头条、SpeedyCloud、去哪儿、饿了么的小伙伴,为大家分享他们对 TiDB 的实践经验。

>李凯(知乎 ID:郁白),现任摩拜数据库团队资深经理

>吴镝,今日头条数据库中间件/分布式数据库负责人

>李雨来,SpeedyCloud 架构师

>蒲聪 ,去哪儿网资深 DBA

>陈东明,饿了么北京技术中心架构组负责人

产品

在产品技术方面,TiDB 整体的性能和延迟也做了非常大的改进。就在活动的前一天,TiDB 发布了 1.1 Alpha 版,在这个版本中:

  • QPS 增加了 50%;

  • 能够很好的支持 auto-increment id,增速在 16 倍以上;

  • TiKV 读的性能,在极限压力下提升了 2 倍;

  • 如果我们去 counting 一个 table ,整体的方案提升大概是 60%;

  • Hash Join 提升在 3 倍以上;

  • 一些复杂 query ,根据现有用户的反馈,在 30T 左右的数据场景下面,一个复杂的查询,如果是使用到更好的 index 算法的话,提升大概在 30 倍左右;

  • 同时,在 TiDB 1.1 里,我们完全重写了整个优化器,现在优化器变得更加智能。

工具

当然,上面所有的这些优化只有使用上 TiDB 1.1 才能体验到,对于还未使用 TiDB 的用户来说,会面临的一个问题就是:怎样从已有的 MySQL 数据里面重新导入进 TiDB。针对这个问题,我们最近也提供了一个新的工具,用来提升大家在导入数据过程中的体验,速度整体的提升在实测中的表现大概有提升了 15 倍。

同时,我们也专门构建了一个数据导入工具,这个导入工具大概可以在五个小时内导入 1T 的原始数据。相对于大家以往用传统的方式来并发导入,它的速度提升大概是十倍。

为了让大家更好的观察到整个集群的运行状态,我们也做了一个非常炫的图形界面。

  • 视频 | PD 图形界面 Demo 1

  • 视频 | PD 图形界面 Demo 2

对于 2018 年 TiDB 项目的 Roadmap,重点在以下几个内容:

  • 首先是 Region level SQL query cache;

通常情况下面我们在整个集群里面假设有几十 T 的数据,实际上我们随着不断的写入,通常最近的一段时间的写入的数据量都是比较少的。此时,就没有必要用一个 query 把没有变化的数据也计算一遍,特别是没有变化的数据是不需要去查或者重新计算的。而这个特性的好处就是我们不需要去重算,已经算过的就直接把它 SQL 的 query 结果 cache 起来就可以了。这个 query 是以 Region 为基本单位,它在一些场景下面的提升会达到数十倍甚至更高。

  • 第二个特性就是 Region merging ;

在 TiDB 现在的版本里面,region 是会随着数据的增长不断分裂的,那么有的时候我们需要去删掉一些以前不再用的数据,这部分数据虽然会被删掉,但是它 region 的元信息还在。此时,如果大家的 SQL 语句没有很好的设定从哪里开始做扫描的话,那有可能会把这些已经删掉的 region 元信息重新过一遍,这是会降低我们查询速度。所以我们在最新的实现里面会把这些已经删掉的这些 region 的元信息重新 merge 到一起,降低我们管理元信息的复杂度,然后同时增加查询的速度。

  • 第三个特性就是 Partition table;

我们在很多实际使用场景里面可能会遇到一些特定的分区需求,比如说需要按月去做分区,那么通常查询就只需查询这一个月,其它数据就不碰,或者是按照按照地区等等分区方式,新的实现里面也会去支持 Partition table。

  • 第四点是 Full-text search;

大家可能很多用户会放弃到 ES,因为觉得用 MySQL 的界面已经很好用了,查询速度已经够快了,这时候可能唯一的牵绊就是还有没有一个 Full-text search,我们计划是在 2018 年的 Q4 做这个特性。

同时,会在 2018 Q2 提供 window function, 这一点目前社区的呼声也很高。2018 Q3 提供视图功能,另外我们也在和 RocksDB 团队一起开发推进 Blob storage 的实现,这个特性可以显著降低写放大,进一步提升写入性能,并降低写入过程中的 CPU 开销。

最后,就是大家有很多的地理位置相关的查询这种特性,我们计划是在 2018 年的 Q4 到 2019 年的 Q1 来提供。

分享到微信

打开微信,使用 “扫一扫” 即可将网页分享至朋友圈。

产品

  • TiDB
  • TiSpark
  • TiDB 路线图

文档

  • 快速入门
  • 最佳实践
  • 常见问题解答
  • TiDB 周边工具
  • 版本发布说明

资源

  • 博客
  • GitHub
  • 知乎专栏
  • PingCAP University
  • 联合解决方案
  • Ask TUG

公司

  • 关于我们
  • 招贤纳士
  • 新闻报道

联系我们

  • Twitter
  • LinkedIn
  • Reddit
  • Google Group
  • Stack Overflow
  • 微信公众号
    Wechat qrCode

    微信扫一扫
    微信ID:pingcap2015

© 2019 北京平凯星辰科技发展有限公司

English