劉奇：數據庫市場呈現多樣化趨勢，20% 傳統數據庫在將來兩年會被替代

日前，我司 CEO 劉奇接受了「愛分析 ifenxi」的採訪，分析了目前數據庫市場的發展趨勢、TiDB 的特性及應用場景，並透露了公司將來發展布局。如下爲愛分析報道及訪談實錄，信息量很大，enjoy :) 

調研 | 李喆  王琦

撰寫 | 李喆

即便將範圍從大數據縮小到數據庫這個細分領域，PingCAP 依然是家很是特殊的公司，其產品 TiDB 是市面上爲數很少面向 HTAP 場景的數據庫。

傳統意義上，數據庫分紅事務性數據庫（TP）和分析性數據庫（AP）。

近幾年興起的 NoSQL 數據庫、如 MongoDB、基於 Hadoop 的 Hbase，更多都是分析性數據庫，經過分佈式架構解決大規模的數據查詢、分析問題。

然而，承載生產系統的事務性數據庫卻始終被傳統數據庫廠商所把持，Oracle、IBM 等佔據傳統大型企業市場，中小企業及互聯網公司則大多數採用開源技術 MySQL，鮮有新技術、新公司可以進入這個市場。

2012 年，Google 的 Spanner 橫空出世，這是一款基於分佈式架構的事務性數據庫。受到 Google 的啓發，國外出現了 CockroachDB（蟑螂數據庫）等一系列解決 TP 問題的新興數據庫廠商，但國內市場幾乎仍是空白，找不到研發這類數據庫的創業公司。

2015 年，PingCAP 成立，填補了國內的空白。 

互聯網背景的團隊，用開源模式作數據庫

與市面上其餘數據庫廠商不一樣的是，PingCAP 創始團隊大多數來自大型互聯網公司，如豌豆莢、京東等，幾乎沒有來自傳統IT或者數據庫廠商。

互聯網的背景，創始團隊每名成員都經歷過數據指數級增加的時期，具有處理海量數據的經驗，作數據庫產品會優先考慮擴展性。

同時，由於互聯網公司大多會採起 MySQL 技術，所以 TiDB 最早兼容的是 MySQL 協議，這使得 PingCAP 更容易獲取客戶。 

互聯網還有個特色是開源爲先，PingCAP 從第一天就確立了用開源方式作數據庫的打法。但與其餘團隊不一樣的是，PingCAP 的創始人劉奇等人，曾經是分佈式緩存項目 Codis 的做者，具有開源社區運營的能力，懂得如何藉助社區力量發展產品。

開源社區一方面會擴大 PingCAP 產品的覆蓋面，帶來潛在的客戶；另外一方面，經過開源社區的運營，PingCAP 將更多精力放在覈心產品 TiDB 的研發，其餘功能能夠一部分由開源社區用戶來實現。

此外，經過用戶反饋，PingCAP 能夠了解用戶的潛在需求，做爲 TiDB 研發的一個參考。

產品同時支持 TP 和 AP，強一致性和擴展性是主要特色

最初，TiDB 只是解決 TP 問題，但在實際應用過程當中，直接讓客戶用新數據庫替代原先的 MySQL 數據庫難度很大，尤爲當數據庫廠商是一家名不見經傳的初創公司。

多數企業客戶的作法是前端仍然保留傳統 MySQL 數據庫，將 TiDB 數據庫做爲背後的數據集市，與前端數據庫相連，但這個數據集市的實時性要遠好於 Hadoop 架構的數據集市，能夠運行在實際生產系統。 

當按照這種方式運行一段時間，客戶承認 PingCAP 的產品後，會逐步替換掉 MySQL 數據庫，將 TiDB 做爲前端數據庫。

當客戶將 TiDB 數據庫做爲數據集市來使用時，由於前端數據庫要從這個數據集市中查詢數據，所以，對 TiDB 數據庫的查詢功能提出更高要求。TiDB 調整了本身的數據庫執行器，進行 AP 功能的拓展。 

這樣一來，TiDB 同時支持 TP 和 AP 功能，成爲分佈式 HTAP（Hybrid Transactional/Analytical Processing）數據庫產品。 

TP 場景下，TiDB 具有強一致性的特色，能夠承載金融等對數據一致性敏感度很高的行業。與傳統數據庫相比，TiDB 可擴展性是最大優點。TiDB 能夠經過不斷增長機器來提高性能。 

AP 場景下，與 Hbase 等相比，PingCAP 的實時性更好，處理數據的速度更快。

現階段主要覆蓋互聯網金融、遊戲等互聯網領域，銷售線索主要來自開源社區

與傳統企業相比，互聯網公司更加容易嘗試新技術，互聯網背景出身的團隊也更加可以清楚互聯網公司的業務特色。

同時，互聯網公司的發展速度大多遠超傳統企業，數據量增加速度極快，對改善底層技術架構、提高數據庫性能的需求更增強烈，特別是在遊戲行業、互聯網金融行業。

這些因素促使 PingCAP 早期客戶大多數來自互聯網企業，同程旅遊、360 金融、摩拜單車等都陸續成爲 PingCAP 的客戶。

截至 2017 年末，PingCAP 總體團隊規模達到 100 人左右，其中超過 80% 是研發，只有一名全職銷售。

一名銷售的獲客能力很是有限，PingCAP 主要仍是經過開源社區的方式獲客，銷售人員只負責跟進有意向的企業。2017 年，應用在實際生產環境的用戶達到 200 家，最終產生十幾家付費客戶。 

現階段，PingCAP 重點仍然放在產品打磨和社區運營上，還沒有進入到產品大範圍推廣階段，所以，2018 年 PingCAP 會考慮進入金融、醫療、物流等傳統行業，但不會大範圍增長銷售團隊，仍然會採起較爲謹慎的市場策略。

近期，愛分析對 PingCAP 創始人劉奇進行訪談，他對 PingCAP 的業務模式、將來戰略，以及數據庫行業將來發展趨勢等方面，進行闡述，現將部分訪談內容分享。

基於解決數據庫擴展性問題的初衷，產品可同時知足 TP 和 AP 業務需求

愛分析：您創立 PingCAP 的初衷是什麼？

劉奇：我在京東工做的時候就已經有這個想法，當時沒有一個能夠很好實現擴展的數據庫，最廣泛的作法是分庫分表。但這種方式存在缺點，第一它的彈性擴展能力比較差，第二是易用性比較差，第三是編程的心智負擔比較大，第四是表達力比較弱。

當時我在作一個項目，也須要分佈式數據庫，可是市面上沒有使人滿意的產品。

因此，最開始的定位是想解決本身的問題，中間咱們還開發了一個分佈式緩存，以後咱們開始着手解決數據庫擴展性的問題，就出來創業了。

愛分析：數據庫做爲底層技術，客戶選擇供應商會很是謹慎，最初是如何獲取客戶的？

劉奇：2016 年，咱們拿到了雲啓資本的 A 輪融資以後，開始考慮怎麼去獲取第一批用戶。的確，用戶將一個新的數據庫應用到線上是存在風險的，誰願意拿本身線上的業務去冒險嘗試一個全新的數據庫？

蓋婭互娛是咱們第一個用戶。那個時候，他們的 MySQL 數據庫出現了問題，線上查詢速度特別慢，整個系統已經卡頓到沒法使用，不嘗試使用新的技術已經很難開展業務。咱們當時的產品還在測試階段，他們就開始推進這個數據庫上線。 

由於採用新的數據庫到線上確實是存在風險的，所以不少用戶採用另外一個方式來作。線上有一堆 MySQL 在運行，他們在後面搭建一個大的數據集羣，把全部的數據所有匯到這裏，看起來有點像數倉。由於咱們自己是兼容協議的，咱們能夠把數據複製過來，他們來進行實時查詢。

在遊戲行業或者是實時性要求比較高的風控管理，他們就急須要這種技術來解決問題。

咱們目前披露了不少金融案例，有至關一部分都是用在實時風控這個場景。好處是不直接針對線上業務，風險相比線上 MySQL 要小，而又恰好解決了他們的痛點。 

這個階段以後，客戶若是以爲技術足夠穩定，他會把線上撤下來，再把咱們的產品推到最前面去，來支撐全部業務。

當客戶把咱們的數據庫看成數倉的時候，其實查詢的複雜程度很高，咱們的數據庫能幫助客戶作一些之前不敢作的事情，一個 SQL 查詢語句甚至好幾頁紙那麼長。

那麼問題來了，咱們的設計自己並非爲了 AP 業務，而查詢這個功能是側重 AP 的，所以咱們在優化執行器的時候，也作了相應的調整，作了 AP 功能的拓展。

這樣一來，咱們的產品能同時支持線上 TP 和 AP 業務，咱們的產品就變成 HTAP。

當把這個產品作好以後，咱們發現產品的特色十分明顯，在這個領域沒有一個強有力的競爭對手，並且這個產品是知足用戶需求的。不少時候用戶的需求並不能簡單的分爲 TP 仍是 AP，其實是沒有明肯定義的，甚至客戶並不關心這些，只但願可以解決自身的問題。

愛分析：從數據寫入和查詢上看，存在行與列的差異，TiDB 如何在一個表裏實現的？

劉奇：行列只是一個存儲的形式，從技術角度來說仍是能夠作行列變化的。

好比說把冷數據慢慢的後臺轉成列存，而後最新寫入的數據仍然使用行存。前臺仍是一個標準的行存，根據數據的冷熱，轉換成行存仍是列存。 

其實，最新的論文已經提出了新的觀點，數據的存儲並不純粹的是行存或者列存，而是根據訪問頻率，常常訪問的數據使用行存，並不須要掃整個表，實現的方式仍是不少樣的。 

愛分析：谷歌在作 Spanner 的時候強調其擴展性，在算力上要求是否是比較低？

劉奇：這是之前谷歌的一個理念，但這樣的話，若是去作一些相對比較複雜的運算的時候，數據庫的反應時間會比較長，這是存儲格式決定的。

不過，谷歌 2017 年的論文當中，已經把存儲格式改爲了偏混存的形式。咱們跟谷歌的迭代路線是同樣的，並且咱們的存儲格式改的更早，由於咱們更早的遇到了用戶的實際需求。

愛分析：算法和擴展性是否存在必定的矛盾，複雜的算法會不會影響其擴展性能？

劉奇：算法和擴展性沒有什麼關係，算法主要影響執行的效率。

好比，若是是列存的話，執行效率更高，好比說銀行對全部帳戶的金額進行求和，若是是列存的話會很簡單，可是行存的話要掃描每一行中的金額數據，執行效率很低，但在下層的計算層面並不會有太大的差異。

愛分析：在推到前臺的時候，數據庫要作哪方面的調整？

劉奇：要根據整個系統的負載，來決定使用多少併發度，會作一些優化。

假設有 100 臺機器，有這樣一個數據集羣，均勻地推到每一臺機器上計算，併發度很高的狀況下，每臺機器人可能都很忙，這個時候再給它增長任務是沒有用的，機器會崩潰的。

但若是有一個「聰明」的調度器，對指令進行控制，在保持高併發的狀態下，調度不一樣的機器進行不一樣運算，這樣機器不至於很忙，不過帶來的問題是，會帶來比較長的延遲。

固然，一樣的數據可能不必定要運用 CPU 來運算，能夠用 GPU 或者 FPGA，這對調度器的要求就更高了，按照發展趨勢來看，調度器的能力是衡量一個數據庫性能的重要指標。

愛分析：TiDB 是如何實現實時性的？

劉奇：由於他自己就是一個分佈式的結構，性能是能夠繼續擴展的，前面有多少數據的輸入都無所謂。若是如今以爲算的不夠快，經過加機器就能夠實現計算。

速度的快慢還跟計算有關係，有的計算是推不到全部的節點上去的。好比，我要把全部的數據拿回來作排序，這就沒有辦法讓全部節點來作。

這種狀況，優化器的做用比較重要，它會識別哪些計算須要推到下面作並行運算，哪些只要作出決定就能夠。 

愛分析：MySQL 構架，數據遷移到 TiDB 可否作到無感遷移？

劉奇：咱們從一開始設計的時候就考慮到了這個問題，針對 MySQL 能夠作到無感遷移，若是是 Oracle 或者 DB2 的其它協議的話，可能涉及到改代碼的問題。

愛分析：面向其它協議，遷移的週期有多長？

劉奇：這個還要考慮業務的複雜度，好比，原來的業務有 10 萬條 SQL，只要都要驗證一遍，若是自己業務比較複雜，那就會比較快。MySQL 協議這邊，咱們很快就能夠作 POC。

愛分析：下一步有沒有考慮去支持 Oracle 或 DB2 的快速遷移？

劉奇：咱們沒有這方面的打算，由於新的業務已經不用這些技術了。若是考慮這些的話，目的就是切入老項目。在切入老項目時兼容性存在一個問題，用戶須要知道新技術的兼容性究竟是多少？我能不能放心的使用新技術替換？

兼容性不只是功能的兼容，Bug 也要兼容，真正作到 100% 兼容是很難的，企業原來的程序員可能也離職了，若是去替換老的業務，工做量、風險都會很大。

現階段互聯網金融、遊戲等偏互聯網行業是重點行業，適用於數據量大、業務複雜性高的場景

愛分析：產品主要針對哪些行業的客戶？

劉奇：咱們在商業化的過程當中，最重要的是把產品作出來，而後根據客戶的需求去完善它的功能。 

另外，咱們的產品是開源的。開源的好處是當用戶在使用過程當中會及時反饋他們的使用體驗和遇到的問題，在這個過程當中會發現咱們的潛在用戶是誰。

咱們的第一個用戶是遊戲公司，這實際上是超出了咱們的預計的，咱們認爲多是互聯網優先，由於互聯網對新技術比較激進。

遊戲行業也有其特色，遊戲公司最賺錢的確定是爆款遊戲的運營，一天的流水可能就有幾千萬。他們但願本身的基礎設施是足夠穩定、強大的，一旦遇到瓶頸再去停機改造，那形成的損失就會很大，所以，他們也但願經過新的技術來解決問題。

再一個就是互聯網以及傳統行業，互聯網企業在使用咱們的新產品的時候，表現得仍是很保守的 ，由於前面已經有那麼多的 MySQL 在使用，忽然換新的技術他們會以爲風險很高。

不過，像互聯網金融這類企業對實時性要求仍是很高的，要經過實時的信息進行風控管理，之前的方案是沒法知足的，因此會選擇使用咱們的產品。

愛分析：TiDB 的應用場景有哪些？

劉奇：咱們的數據庫通用性比較強，通常是面向新的業務需求，咱們自身並無將數據庫設計成面向某一行業的產品。 

說到咱們產品的優點，客戶的數據量必須達到億級別以上，若是數據量比較小，就沒有必要上分佈式數據庫；另外，就是業務的複雜性要比較高，這樣咱們的優點更加明顯。

愛分析：下一步會重點側重哪幾個行業？

劉奇：從營收的角度來說，金融應該會是咱們重點佈局的一個行業，像物流、醫療等其餘領域數據增速也比較快。

團隊主要來自互聯網公司，銷售人員極少

愛分析：2017 年 PingCAP 的用戶推廣進展？

劉奇：咱們在 2017 年運行在生產環境的用戶達到 200 個，產品客單價比較高，付費用戶要少一些。

愛分析：TiDB 是一個開源技術，在提供企業級產品時會作哪些強化？

劉奇：雖然咱們提供一個開源技術，但仍是有部分是閉源的，好比監控運維組件，備份工具，安全性工具等。

對於企業應用來講，它必須具有很漂亮的用戶界面、很方面的操做工具，這是咱們企業版提供的方式。 

還有一部分，咱們叫作 Database & Service，咱們提供的不只是一個數據庫，而是一個數據庫平臺，企業用戶能夠申請 TiDB 數據集羣。若是沒有這個東西，可能就須要管理員手動處理，使用體驗差異是很大的。

愛分析：TiDB 是如何收費的？

劉奇：咱們如今有兩方面考慮：一方面能夠利用雲部署，咱們能夠看到騰訊雲的數據庫入口，這個商業模式比較簡單，與雲上的其它產品同樣，按照租賃的方式進行收費。

另外一方面，能夠買咱們的 subscription，也能夠買咱們的 license，按照節點數來計算。

愛分析：公司的團隊規模？

劉奇：如今公司大概 100 我的，研發佔比比較高，有 82 個。銷售人員只有 1 個，銷售比較少是由於用戶都是本身找過來的，咱們在這方面沒有太大的投入。

咱們對研發的要求仍是很高的，包括研發人員對外面的支持、響應的速度等。雖然看上去不會像 Oracle 那麼誇張，但有不少外部公司在給咱們作貢獻。

好比，調度器方面的代碼不少是摩拜貢獻的，不少場景下的優化是今日頭條貢獻的，包括韓國三星研究院等，還有不少人在幫咱們作測試，這也體現了開源技術的一個好處。

愛分析：研發人員會承擔一部分售前的工做嗎？

劉奇：在 17 年的時候還存在一些研發人員作售前工做的狀況，但 18 年咱們會作出一些調整，這也是咱們一個很重要的任務。

人員結構的建設要造成一個完整的體系，售前、實施、研發各司其職，根據不一樣階段的問題安排不一樣的人去解決。 

愛分析：銷售人員比較少的狀況下，是否是對社區的運營提出更高的要求？

劉奇：我認爲研發人員比較多，跟社區的交流就會比較快。社區中最主要的用戶是開發者，與開發者的交流確定是研發人員更加順暢，銷售人員無法替代這個角色。好比，用戶提出有部分代碼存在問題，研發的響應速度會很快。

像今日頭條、摩拜、同程這些規模比較大的用戶，都是由於存在痛點主動聯繫到咱們，不須要銷售去作額外的工做。 

固然，社區中還存在許多規模比較小的用戶，小的用戶雖然沒有那麼大的付費能力，但對社區來講也是有直接做用的。 

他們會用本身的場景進行測試，發現不少咱們歷來沒有碰見過的問題，他們所提供的這些信息對咱們來講也是十分重要的，所以咱們會花費比較大的力氣來運營社區。

愛分析：PingCAP 的團隊背景以互聯網居多？

劉奇：對，互聯網出身的多一些，都是規模比較大的互聯網公司，都體會過數據量大了以後帶來的痛苦。

另外，還有來自傳統行業的，售前有來自金融行業的，他對金融行業的使用場景更加清楚一些。

愛分析：切入傳統行業的話，是否是對人員結構的要求有變化？

劉奇：目前咱們還不是這麼想的，咱們但願經過產品就可以直接拿下客戶，可以體現咱們產品的優點。若是是用誰的數據庫都同樣的客戶，咱們是不會去爭取的，這也不是咱們的強項。

愛分析：產品的研發和社區的維護，精力如何平衡？

劉奇：咱們確定會先作好一個基礎版，纔會在社區中推廣，當遇到 Bug 的時候必定要去修復，否則會影響到不少人的使用，二者共同推動，並不衝突。

內部研發方面，咱們會快速的開發不少新的功能，這些不會立刻就應用到穩定版本，而是先在社區發佈一個 Beta 版本，經過用戶測試發現 Bug，咱們來進行修復，在不斷的溝通以後，咱們纔會發佈穩定版。 

在這個過程中，咱們須要經過社區讓用戶不斷的進行測試來跟咱們反饋。由於產品行不行並非咱們本身說了算的，而是用戶來判斷的。

TP 和 AP 融合是將來趨勢，數據庫市場將來會更加多樣化

愛分析：CAP 原理中的一致性和可用性存在必定的矛盾，怎麼進行優化？

劉奇：咱們在將來會提供一個選項，用戶能夠根據本身的需求本身選擇，高一致性或者高可用性。好比銀行的數據就要求高一致性，而互聯網應用就更側重高可用性，咱們會都提供給用戶，讓用戶來選。

愛分析：NewSQL 技術與以前的技術有什麼不一樣？

劉奇：歷史上最開始應用的是 SQL，後來爲何會出現 NoSQL，是由於 SQL 不能擴展，雖然 NoSQL 具有了擴展的能力，但表達力比較差，可能還不支持事務處理，不具有 SQL 的傳統優點。

 NewSQL 就至關於同時具有了兩個優點，既能很好的擴展，又能具有 SQL 的事務處理能力和表達力。

愛分析：下一步 TP 和 AP 是有融合的趨勢嗎？

劉奇：咱們認爲是這樣的，用戶是不關心是 TP 仍是 AP 的，解決問題就是硬道理，也無論是線上仍是線下，能實時實現我確定不肯意等一天。 

TP 和 AP 分開這是歷史緣由形成的，在數據庫剛誕生的時候並無去區分。如今技術能作獲得，確定仍是但願融合在一塊。數據分析比較複雜的狀況可能還會存在單獨的 AP，但咱們的產品還在快速的迭代，最後仍是要看誰的性能更勝一籌。

愛分析：分佈式數據庫平臺領域未來會不會產生另外一個 Oracle？

劉奇：由於歷史緣由，短期內 Oracle 的地位是不可替代的，但新的數據庫構架興起的也很快，如今 Oracle 遇到了史無前例的挑戰，我認爲在將來兩年，將會有 20% 的傳統數據庫被新的數據庫取代。

看如今咱們的用戶增速，這個趨勢仍是至關明顯的。

愛分析：將來市場的格局會發生哪些變化？

劉奇：我以爲市場會變得更加多樣化。 

首先，如今的需求很是碎片化，傳統數據庫不能很好的表達，例如對 Streaming 要求愈來愈高。

關係型數據庫的優點是通用性比較強，也比較均衡。但有些場景用如今的數據庫框架是很難適應的，確定不會比專門的設計的數據庫用起來順暢，如圖數據庫等。

從發展趨勢來看，當 NoSQL 出來的時候，你們會考慮它能替代什麼樣的場景，後來發現 NoSQL 仍是存在不少約束的。NewSQL 的出現確實會改變市場格局，應該之後會有兩三家比較大致量的公司吃掉大部分市場，但小公司依然存在。

愛分析：開源技術的發展會不會影響到數據庫公司的業務？

劉奇：其實開源技術已經存在很長時間了，像 MySQL 已經有二十幾年的歷史，但企業級應用畢竟不是那麼簡單，還存在不少問題須要團隊去解決。

將來不會有徹底免費的數據庫，就算是開源的也是要收費的。 

愛分析：互聯網公司通常會本身開發基礎設施，會不會對 PingCAP 形成影響？

劉奇：這個事情要分國內和國外來看，國內的公司喜歡建設私有云，國外差異就比較大，不少國外公司都把本身的私有云給拆掉了，緣由也很簡單，本身部署私有云的效率並不如直接使用成熟的公有云。

如今不少互聯網公司不想再像過去那樣被 Oracle 這樣的公司 Lock in，我既要用你的數據庫，又必須具有必定的掌控力。由於互聯網公司成長是很快的，需求的變化也更加明顯，他們但願對數據庫具備必定的理解力和掌控力，以方便互聯網企業修改數據代碼，知足自身定製化的需求。 

愛分析：雲廠商最後會不會成爲數據庫企業的競爭對手？

劉奇：數據庫跟雲的關係，有點像 APP 和 APP Store 的關係。雲廠商可能也會作數據庫，但更多的應該是一種合做關係。