比如用户报了一个 Bug,然后他开始 fix。第一件事是花两周左右的时间去理解 20 个不同的 flag,看看有没有可能因为内部乱七八糟的原因来造成这个 Bug。大家可能不知道 MySQL 有多少变数,我刚做 TiDB 的时候也不知道,当时我觉得自己是懂资料库的,后来去看了一下 MySQL 的 flag 的变数数就惊呆了,但看到 Oracle 的 flag 变数数,那不是惊呆了,是绝望了。大家可能知道开启 1 个 flag 的时候会对什么东西有影响,但是要去理解 20 个 flag 开启时和另外几个 flag 组合的时候都有什么影响,可能会崩溃。所以其实精通 Oracle 这件事情,实际上可能比精通 C++ 这件事情更困难的。一个 Oracle 开发者在内部处理这件事情都这么复杂,更何况是外面的用户。但 Oracle 确实是功能很强大。
说回这位前 Oracle 员工的描述,他接著添加了更多的 flag 处理一个新的用户场景的问题,然后加强代码,最后改完以后会提交一个测试。先在 100 到 200 台机器上面把这个 Oracle 给 build 出来,然后再对这个 Oracle 去做新的测试。他应该对 Oracle 的测试用例的实际数量了解不深刻,我猜他可能不知道 Oracle 有多少个测试,所以写的是 「millions of tests」,这显然太低估了 Oracle 的测试数量。通常情况下,只会看到挂了的测试,看不到全部的测试数量。
下面的步骤更有意思了:Go home,因为整个测试需要 20-30 个小时,跑完之后测试系统反馈了一个报告:挂了 200 多个 test,更茫然的是这 200 tests 他以前都没见过,这也是 Oracle 非常强大的一个地方,如果一个开发者的代码提交过去挂掉一两百个测试,是很正常的事情,因为 Oracle 的测试能 Cover 东西非常多,是这么多年来非常强大的积累,不停的堆功能的同时就不停的堆测试,当然也不停的堆 flag。所以从另一个角度来看,限制一个系统的功能数量,对于维护来说是非常重要的。
随著 TiDB 有用户开始上线,用户的数量和规模越来越大,这时候就出现了一个很有意思的事情,一部分用户把 TiDB 当成了可以支持事务、拥有良好实时性的数据仓库在用,和我们说:我们把公司 Hadoop 换了,数据量十几 T。
我们就一下开始陷入了深深的思考,因为 TiDB 本来设计的目的不是这个方向,我们想做一个分散式 OLTP 资料库,并没有想说我们要做一个 Data Warehouse。但是用户的理由让我们觉得也很有道理,无法反驳——TiDB 兼容 MySQL,会 MySQL 的人很多,更好招人,最重要的是 Hadoop 跑得还不够快。
虽然我们自己也很吃惊,但这体现了 TiDB 另一方面的价值,所以我们继续问用户还有什么痛点。用户表示还有一部分查询不够快,数据没办法做到 shuffle,而且以前用 Spark,TiDB 好像没有 Spark 的支持。
我们想了想,TiDB 直接连 Spark 也是可以的,但这样 Spark 对底下没有感知,事务跑得巨慢,就跟 Spark 接 MySQL 没什么差别。我们研究了一下,做出了一个新的东西——TiSpark。TiSpark 就开始能够同时在 TiDB 上去跑 OLAP 和 OLTP。