共计 4270 个字符，预计需要花费 11 分钟才能阅读完成。
只有天空才是你的极限，咱们酷爱摸索的过程并沉迷其中
Hackathon 自身带给咱们的是一次全新的摸索，并不只是一队人有一个明确的指标，花几天工夫写代码，那其实是很无聊的。摸索的自身让咱们发现，越摸索越能找到更新、更好、更优雅的解决办法，咱们酷爱这个摸索的过程并沉迷其中…… —— TiMatch 赛队
战队成员之一柏佳辰是一个爱画画、爱摩托车、喜爱读《理想国》，建筑学出身的程序员。
在 TiDB Hackathon 2020 赛事中，[TiGraph]()我的项目在 TiDB 中实现了一套新的 Key-Value 编码来引入图模式，解决传统关系型数据库难以笼罩的图数据分析场景，实现了 TiDB 在四度人脉的计算性能大幅晋升，夺得了二等奖。
在刚刚收官的 TiDB Hackathon 2021 赛事中，TiMatch 在去年我的项目的根底上做了一次进化降级，构建了基于 TiDB 和 TiKV 的语法齐备的分布式图数据库，摸索出一条在 TiDB 之上构建一个成熟且易于应用的图数据库的门路。我的项目取得了现场评委的统一必定，拿下本届赛事的二等奖。
TiMatch – 语法齐备的分布式图数据库，去年 TiGraph 曾经让大家惊艳，往年 TiMatch 更让人期待了。这次易用性更好，而且对于老集群也能间接降级应用。因为 TiMatch 只是外部建设了一套 graph index，而后通过 TiDB 分布式事务机制，跟原先关系表的数据对立更新。语法下面，借鉴了 Oracle graph 的语法，所以曾经是关系齐备的了，不过我感觉前面的挑战在于性能下面，心愿后续这块能给大家展现相干的数据。
——评委唐刘
点评十分惊艳，借助 TiKV 的扩大能力 + TiFlash 的剖析能力，设想空间很大，心愿能尽快 GA！
——评委冯光普
为什么抉择图数据库这个方向？
图技术已成为古代数据和剖析能力的根底，可能在不同的数据资产中发现人、地点、事物、事件和地位之间的关系。依附图技术能够疾速答复以往须要理解状况并了解多个实体之间的分割和劣势之后能力答复的简单业务问题。
图数据库始终是业界的热门话题。它具备用于语义查问的图形构造，应用顶点、边和属性来示意和存储数据，反对对在关系数据库系统中难以建模的简单层次结构进行简略疾速的检索，优雅地解决了传统关系数据库在针对简单关系或多表 JOIN 状况运行后果时经常出现的性能或故障问题。咱们身边有很多图利用的案例，比方 Google PageRank 算法；LinkedIn 用图治理社交关系，实现好友举荐；Amazon 用图实现实时的商品举荐；银行用图做风控，实现反欺诈和反洗钱等等。从 DB Engine 的统计数据能够看到，在寰球范畴内，从 2014 年开始，图数据库的受欢迎水平始终出现迅猛的回升态势，超过了其余各种类型的数据库。据 Gartner 预测，到 2025 年图技术在数据和剖析翻新中的占比将从 2021 年的 10% 回升到 80%，该技术将促成整个企业机构的疾速决策。
从去年的 TiGraph 到 TiMatch
我的项目实现了哪些晋升？
去年的 TiGraph 我的项目留下了一些遗憾，比方图查询语言不齐备，没有接入 TiKV 存储引擎等。这次 Hackathon 赛事中 TiMatch 的工作就是基于 TiDB 和 TiKV 设计语法齐备的分布式图数据库雏形，持续摸索在 TiDB 之上构建一个成熟且易于应用的图数据库的门路，TiMatch 实现了三大方面的晋升。
晋升语法的齐备性，语言下面引入了 Oracle PGQL 语法
通过在 WHERE 子句后引入 TRAVERSE 子句来进行图遍历，次要是摸索看看是否能进行无效整合，是否能够无缝算子复用，语法是否足够简略，子查问是否能够敌对地互相嵌套。尽管最终是达到了验证的目标，然而因为数据起源须要依赖底层的 SELECTION 算子，所以进行图计算时不能进行多个边匹配，在子图匹配和最短门路等其余图算法场景中难以结构对应的查问，实质上是语法的齐备性存在问题。
好在 2021 年 Oracle 的 PGQL 也在对图查询语言和 SQL 语言的兼容联合进行摸索，并且公布了 1.0 的标准。咱们间接参考了 PGQL 语法，在 TiDB 中实现了残缺的 PGQL parser 晋升了查问的齐备性，在语法上反对图遍历、子图匹配、TopK、最短门路等图算法，算法的具体实现除了图遍历，往年也实现了最短门路查问。
升高零碎复杂度和学习老本
简化和齐备性的晋升直觉上是相悖的，这次的计划在读取门路和写入门路上区别对待，读取门路尝试通过 PGQL 图查询语言来晋升查问的齐备性，须要引入新的语法规定。在写入门路上，摸索出一个全新的计划，去年的计划咱们引入了很多新的语法，比方：
- CREATE EDGE/TAG
- SHOW EDGES/TAGS
- SHOW CREATE TAG/EDGE
- DROP TAG/EDGE
- ALTER TAG/EDGE
- …
这些语法对已有的应用程序和 ORM 生态都会有比拟大的兼容性冲击，须要进行大量的利用批改和生态兼容。
往年咱们在不停的探讨和尝试中找出了一个全新的形式，尽量少地侵入用户层接口，齐全在数据库外部实现兼容，将内部兼容问题转换为数据库外部图模式的兼容性问题，部分看工作质变大了，然而更加合乎全局最优解。
- 顶点的 DDL 语法齐全不变动。
- 变的语法退出了 SOURCE/DESTINATION KEY Column Option，写法和 FOREIGN KEY 是一样的，所以对于开发者和 DBA 都不会有新的学习累赘，MySQL 的 Column Option 有靠近 20 个，所以新增的只有 Column Option 的 2/20，而 Column Option 的作用域及其小，相干去年的新增几十个语句级别的语法，往年能够说是相当轻量。
是否有可能齐全打消新语法？是能够的，比方应用以下的形式：
CREATE TABLE (
a bigint /*T! SOURCE KEY REFERENCES students */,
b bigint /*T! DESTINATION KEY REFERENCES students */
)应用正文的形式能够齐全打消对上下游的影响，然而正文在语法解析阶段不容易很早就通过 parser 发现错误，并且很多人会疏忽正文，所以这里没有齐全谋求 100% 的兼容性。
主动构建图拓扑 通过引入 SOURCE/DESTINATION KEY 之后，数据库外部就有足够的信息主动构建图拓扑，其实从图数据库的角度来说，次要是实现三局部工作：
- 图数据存储
- 图拓扑的保护
- 图算 fan
图数据（顶点）的存储和传统数据存储并不需要引入过来的差异性，大多是外部存储细节和 Key-Value 设计的差异，如何保护图拓扑和已有数据，如何新增图拓扑是一个新的问题，在本次 Hackathon 咱们提出了一个新的计划，能够对已有数据通过 ALTER 语句和 SOURCE/DESTINATION KEY 信息主动构建已有数据的图拓扑，免去任何的数据迁徙和业务革新过程。
从单机存储 unistore 到 TiKV+TiFlash，晋升数据集反对规模
Hackathon 2020 因为工夫所限应用了用于跑单元测试的 unistore，而往年引入 TiKV 存储引擎，运算性能也极大的晋升，在 Demo 演示中能够看到，100 万点的单源 6 度人脉查问只须要 200 毫秒，相比去年在 unistore 上 10 万数据须要 6 秒来说，性能晋升极为显著。将来还能够引入 TiFlash，利用 TiFlash 的 MPP 能力进行大规模图计算。
通过两届 Hackathon 的迭代
在 TiDB 上实现图数据库
TiMatch 摸索出了一条怎么的门路？
- 首先是兼容 TiDB 已有的性能、已有的数据和已有的生态（DM/CDC/Lightning/ORM/ 等）
- 思考自适应图 DDL 和已有数据主动兼容，从而主动构建图拓扑
- 反对 TiKV 存储引擎，进行残缺的 Parser 实现
- 欠缺图查问：遍历、门路过滤、最短门路、谓词下推、Coprocessor 下推等
- 事务、索引、嵌套子查问等方面的考量
在 Hackathon 上取得二等奖的好问题
最次要的起因是什么？
最次要的起因是这个我的项目站在了“三层”伟人的肩膀下面，能力出现在大家的背后 \
一层：思考上连续了 TiGraph，实现和语法上是一个垫付，语法上齐备了许多二层：在 TiDB 和 TiKV 既有框架上进行实现，扩大图数据库，拓展 TiDB 的场景三层：引入了全新的语法，实现对图数据库查问的万备汛，从 Oracle PGQL 延长过去，原版的语言有些中央比拟啰嗦，不是很讲究，对其进行了肯定的批改，变得更加优雅
其次，团队的明确分工，队员之间的彼此信赖和无缝合作
- 龙恒、夏雨杰、刘东坡：着重实现 TiDB 侧的语法分析、AST、Parser、写入门路等
- 柏佳辰：负责 TiKV 侧算子下推，并承当队宣的角色（制作宣传视频 + PRC PPT 等）
作为一名北美的选手
首次加入 TiDB Hackathon 有什么感触？
柏佳辰
GitHub ID：JeepYiheihou
哈佛硕士毕业，现就职于 AWS 温哥华，从事 ElasticCache 缓存数据库外围研发工作，利用假期参加了此次 Hackathon。整个 Hackathon 的过程对我来说是一次开心的体验。赛队全情投入，竞争特地强烈，赛制给足了工夫让咱们进行思考和创意，很多我的项目的完成度很高，也涌现了不少实用的我的项目。评委们提了不少犀利的问题，能够看出他们不止看到当下我的项目的闪光点，更会以久远的眼光去挖掘这些我的项目在将来的方向和价值，我感觉评委们也是十分 enjoy 这个过程。
全栈程序员是怎么炼成的？
因为酷爱。赛队的视频以及 RFC 的 PPT 都是出自柏佳辰之手。之前学过八年的建筑学，做精美的 PPT 是必修课，做视频也是自学的。这次赛队的宣传视频，借鉴了黑客帝国的主题，有一些帧用的是 processing 进行编程的可视化，用了 pathon 语言出现了图、网格和网络。在转行做程序员之前，对编程很感兴趣，自学学编程，接触过应用可视化工具来制作视频，刚好这次用上了。
不论做转行前或者转行后的任何事件，做职业决定的时候，要确定你是真的酷爱它。酷爱它，你就会对这件事件全神贯注，投入精力进去。转行做程序员大家都晓得怎么去做筹备，重要的不是第一步你怎么跨入这个行业，重要的是怎么把前面的每一步都做好。
工作之外，柏佳辰的喜好十分宽泛：喜爱画画，画了一系列油画棒的画；喜爱摩托车；喜爱去健身房锻炼身体；喜爱看书，最近在看哲学的书，比方《理想国》。最大的喜好还是写代码和看论文，这也是为什么转行做程序员，想要尝试一些有挑战的事件，去解决一些问题，并且享受解决问题的过程以及收到的反馈。
