比如用戶報了一個 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。