通过考证深入了解 TiDB
作者: vincentLi 原文来源:https://tidb.net/blog/5d8c8116
选型结缘
近年美国在高科技领域频地利用其先发优势对我国进行发展拦击和断供打击。从可持续经营的角度出发,很多公司都开始考虑如何从供应链上摆脱对美国技术的依赖。即便无法做到马上替换,也需要做好相关的应急预案和技术储备。正是在这种技术领域“保家卫国”的背景下,我与 TiDB 结下了缘分。
开始的时候并不知道 TiDB 是个什么样的数据库。以为它跟阿里和腾讯开发的分布式数据库一样,利用现有的 Mysql(MariaDB)或者 PostgreSQL 数据库增加分布式中间件进行封装,实现单机到分布式数据库的飞跃。然而当我对 TiDB 数据库的技术有了深入了解后,发现我大错特错。TiDB 居然是一款云原生的分布式数据库。虽然最底层利用了 rocksdb 作为存储引擎,但是内核基本上都是自研,自研的成分很高。是一款不可多得的数据库产品。
基于中国特色的开源项目质量让人担忧,即便初步了解了 TiDB 的产品特点,我们对于选择 TiDB 作为生产主要数据库还是心大心小。毕竟所处在的行业是一个以稳定为主的行业。于是上摩天轮和 PingCAP 网站进行了认真的调研。发现 TiDB 在摩天轮的排名前茅,而且已经有非常多的大公司在使用这款产品,还有不少成功的案例。又发现 PingCAP 公司在数据库生态打造方面也是不遗余力。有非常活跃的技术支持论坛,有丰富的课程体系,有严谨的技术认证体系,有持续稳定的版本升级计划。这些让我们对 TiDB 这个数据库产品有了信心。
为了更深入的理解这个数据库的机制,我决定有机会必定把 PCTA,PTCP 和 PCSD 几个证书考一下。恰好这个时候,PingCAP 搞积分兑换认证考试资格的活动啦。
认证考试准备
在微信群的指引下,我完成了 PTCA 认证报名。认证的介绍为:“平凯数据库认证 TiDB 数据库专员(简称 PCTA)是平凯星辰对于数据库从业者安装部署及日常运维分布式关系型数据库能力的认证,要求数据库从业者熟练掌握 TiDB Open Core 架构原理、安装部署、周边工具等基础知识。”有一个介绍考试范围的页面:PingCAP 认证 TiDB 数据库专员(PCTA)认证考试范围指引 - TiDB 的问答社区 (asktug.com) 。从这个页面我们大概能够看到大体需要学习哪些课程。有一点遗憾是没有考试大纲和考试分数占比的划分,这样我就无法按照考试占比分配有限的学习时间。虽然如此,我的目标并不是考证,而是通过考证帮助我理解这个数据库的特点,该如何使用,功能有无,架构设计的优缺点。因此,我的学习策略是尽量多的看,尽量广的学习!
为了系统的学习 tidb,我先开始看官方的 101 课程视频,看完 101 课程视频后再看 301 课程视频。101 课程偏向于讲 TiDB 的整体架构和设计理念。301 课程则偏向于讲解安装和开发运维相关的工具。我建议 101 课程需要看 2 遍。开始看一遍,后续使用一下数据库有一定感觉后,再回头看一遍。否则里面讲的很多东西会没感觉,什么 write stall,什么 WAL 之类的。当然,如果你在 DB、缓存(rocksdb)和分布式微服务系统上有比较深的造诣,当我没说。另外,对于没有数据库基础和微服务基础的人群,可能需要对课程中碰到的每个陌生的概念都要搞清楚,可以通过百度或者查找官方技术文档了解,不然基础不扎实后续很多问题都无法理解。301 课程介绍了很多 toolkit,每部分都是先介绍概念,场景,然后再进行实验展示,非常容易上手,对于实际应用也非常有用。如果时间不够,可以先不进行实验操作,因为我当天的试卷这部分内容占比不高(没实操类型题目)。据其他考友说考 PTCP 会有用。当然如果时间充足,还是建议按照课程实验手册一步一步的做完实验,毕竟大部分人都需要感性认识来充实记忆。况且我们考证的目的是把东西用起来。
官方培训视频好是好,但是不利于查阅和复习记忆。我又找了 tidb in action 这本书看。因为版本(应该是基于 TiDB 4.0 的)比较老,可能有些内容不够新。但是大体还是没变。这本书看起来还是很不错。碰到没看明白的,再查阅官方的文档。这里想说,官方文档和这本书很多内容都雷同,当然官方文档一直有维护,所以推荐看官方文档。但是官方文档内容太多,可能作为手边问题解决手册会更好。
考试通过后
考试全部都是选择题,而且多选题会说明选几个,如果是选择错误的,还会黑体提醒。可以说考试相当是人性化的。最终考试结果分数不高,反映出自身对知识点的学习不够深入,存在囫囵吞枣的情况。印象比较深刻的是内存悲观锁,考了 3 题,感觉都拿不定主意。考试后到技术文档(manual 重新看内存悲观锁),发现实际上原理非常简单,原本悲观锁信息需要存储到 TiKV 里面,这样大量的网络请求和 IO 会大大降低事务执行效率,于是 tidb 先用 pipelined 悲观锁来减少上锁时间,6.0 又进一步提出干脆就直接把悲观锁只放到 leader 内存的内存悲观锁。当然,这么做问题很明显,leader 任期过期怎么办?leader 崩了怎么办?可能这种模式是 6.0 新出的,所以重点考查了。这里也说明了一点,我们应该多关注对应版本的新特性,这可能是考试的重点。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/561e1b6080d37ee4c17f82d09】。文章转载请联系作者。
评论