PingCAP 劉奇：數(shù)據(jù)庫市場呈現(xiàn)多樣化趨勢，20% 傳統(tǒng)數(shù)據(jù)庫在未來兩年會被替代

調(diào)研| 李喆 王琦

撰寫| 李喆

即使將范圍從大數(shù)據(jù)縮小到數(shù)據(jù)庫這個細(xì)分領(lǐng)域，PingCAP 依然是家非常特殊的公司，其產(chǎn)品 TiDB 是市面上為數(shù)不多面向 HTAP 場景的數(shù)據(jù)庫。

傳統(tǒng)意義上，數(shù)據(jù)庫分成事務(wù)性數(shù)據(jù)庫(TP)和分析性數(shù)據(jù)庫(AP)。

近幾年興起的NoSQL 數(shù)據(jù)庫、如 MongoDB、基于 Hadoop 的 Hbase，更多都是分析性數(shù)據(jù)庫，通過分布式架構(gòu)解決大規(guī)模的數(shù)據(jù)查詢、分析問題。

然而，承載生產(chǎn)系統(tǒng)的事務(wù)性數(shù)據(jù)庫卻始終被傳統(tǒng)數(shù)據(jù)庫廠商所把持，Oracle、IBM 等占據(jù)傳統(tǒng)大型企業(yè)市場，中小企業(yè)及互聯(lián)網(wǎng)公司則大多數(shù)采用開源技術(shù) MySQL，鮮有新技術(shù)、新公司能夠進入這個市場。

2012 年，Google 的 Spanner 橫空出世，這是一款基于分布式架構(gòu)的事務(wù)性數(shù)據(jù)庫。受到 Google 的啟發(fā)，國外出現(xiàn)了 CockroachDB(蟑螂數(shù)據(jù)庫)等一系列解決 TP 問題的新興數(shù)據(jù)庫廠商，但國內(nèi)市場幾乎還是空白，找不到研發(fā)這類數(shù)據(jù)庫的創(chuàng)業(yè)公司。

2015 年，PingCAP 成立，填補了國內(nèi)的空白。

互聯(lián)網(wǎng)背景的團隊，用開源模式做數(shù)據(jù)庫

與市面上其他數(shù)據(jù)庫廠商不同的是，PingCAP 創(chuàng)始團隊大多數(shù)來自大型互聯(lián)網(wǎng)公司，如豌豆莢、京東等，幾乎沒有來自傳統(tǒng)IT或者數(shù)據(jù)庫廠商。

互聯(lián)網(wǎng)的背景，創(chuàng)始團隊每名成員都經(jīng)歷過數(shù)據(jù)指數(shù)級增長的時期，具備處理海量數(shù)據(jù)的經(jīng)驗，做數(shù)據(jù)庫產(chǎn)品會優(yōu)先考慮擴展性。

同時，因為互聯(lián)網(wǎng)公司大多會采取MySQL 技術(shù)，因此 TiDB 最先兼容的是 MySQL 協(xié)議，這使得 PingCAP 更容易獲取客戶。

互聯(lián)網(wǎng)還有個特點是開源為先，PingCAP 從第一天就確立了用開源方式做數(shù)據(jù)庫的打法。但與其他團隊不同的是，PingCAP 的創(chuàng)始人劉奇等人，曾經(jīng)是分布式緩存項目 Codis 的作者，具備開源社區(qū)運營的能力，懂得如何借助社區(qū)力量發(fā)展產(chǎn)品。

開源社區(qū)一方面會擴大PingCAP 產(chǎn)品的覆蓋面，帶來潛在的客戶;另一方面，通過開源社區(qū)的運營，PingCAP 將更多精力放在核心產(chǎn)品 TiDB 的研發(fā)，其他功能可以一部分由開源社區(qū)用戶來實現(xiàn)。

此外，通過用戶反饋，PingCAP 可以了解用戶的潛在需求，作為 TiDB 研發(fā)的一個參考。

產(chǎn)品同時支持TP 和 AP，強一致性和擴展性是主要特點

最初，TiDB 只是解決 TP 問題，但在實際應(yīng)用過程中，直接讓客戶用新數(shù)據(jù)庫替代原先的 MySQL 數(shù)據(jù)庫難度很大，尤其當(dāng)數(shù)據(jù)庫廠商是一家名不見經(jīng)傳的初創(chuàng)公司。

多數(shù)企業(yè)客戶的做法是前端仍然保留傳統(tǒng)MySQL 數(shù)據(jù)庫，將 TiDB 數(shù)據(jù)庫作為背后的數(shù)據(jù)集市，與前端數(shù)據(jù)庫相連，但這個數(shù)據(jù)集市的實時性要遠(yuǎn)好于 Hadoop 架構(gòu)的數(shù)據(jù)集市，可以運行在實際生產(chǎn)系統(tǒng)。

當(dāng)按照這種方式運行一段時間，客戶認(rèn)可PingCAP 的產(chǎn)品后，會逐步替換掉 MySQL 數(shù)據(jù)庫，將 TiDB 作為前端數(shù)據(jù)庫。

當(dāng)客戶將TiDB 數(shù)據(jù)庫作為數(shù)據(jù)集市來使用時，因為前端數(shù)據(jù)庫要從這個數(shù)據(jù)集市中查詢數(shù)據(jù)，因此，對 TiDB 數(shù)據(jù)庫的查詢功能提出更高要求。TiDB 調(diào)整了自己的數(shù)據(jù)庫執(zhí)行器，進行 AP 功能的拓展。

這樣一來，TiDB 同時支持 TP 和 AP 功能，成為分布式 HTAP(Hybrid Transactional/Analytical Processing)數(shù)據(jù)庫產(chǎn)品。

TP 場景下，TiDB 具備強一致性的特點，可以承載金融等對數(shù)據(jù)一致性敏感度很高的行業(yè)。與傳統(tǒng)數(shù)據(jù)庫相比，TiDB 可擴展性是最大優(yōu)勢。TiDB 可以通過不斷增加機器來提升性能。

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

現(xiàn)階段主要覆蓋互聯(lián)網(wǎng)金融、游戲等互聯(lián)網(wǎng)領(lǐng)域，銷售線索主要來自開源社區(qū)

與傳統(tǒng)企業(yè)相比，互聯(lián)網(wǎng)公司更加容易嘗試新技術(shù)，互聯(lián)網(wǎng)背景出身的團隊也更加能夠清楚互聯(lián)網(wǎng)公司的業(yè)務(wù)特點。

同時，互聯(lián)網(wǎng)公司的發(fā)展速度大多遠(yuǎn)超傳統(tǒng)企業(yè)，數(shù)據(jù)量增長速度極快，對改善底層技術(shù)架構(gòu)、提升數(shù)據(jù)庫性能的需求更加強烈，特別是在游戲行業(yè)、互聯(lián)網(wǎng)金融行業(yè)。

這些因素促使PingCAP 早期客戶大多數(shù)來自互聯(lián)網(wǎng)企業(yè)，同程旅游、360 金融、摩拜單車等都陸續(xù)成為 PingCAP 的客戶。

截至2017 年底，PingCAP 整體團隊規(guī)模達到 100 人左右，其中超過 80% 是研發(fā)，只有一名全職銷售。

一名銷售的獲客能力非常有限，PingCAP 主要還是通過開源社區(qū)的方式獲客，銷售人員只負(fù)責(zé)跟進有意向的企業(yè)。2017 年，應(yīng)用在實際生產(chǎn)環(huán)境的用戶達到 200 家，最終產(chǎn)生十幾家付費客戶。

現(xiàn)階段，PingCAP 重點仍然放在產(chǎn)品打磨和社區(qū)運營上，尚未進入到產(chǎn)品大范圍推廣階段，因此，2018 年 PingCAP 會考慮進入金融、醫(yī)療、物流等傳統(tǒng)行業(yè)，但不會大范圍增加銷售團隊，仍然會采取較為謹(jǐn)慎的市場策略。

近期，愛分析對PingCAP 創(chuàng)始人劉奇進行訪談，他對 PingCAP 的業(yè)務(wù)模式、未來戰(zhàn)略，以及數(shù)據(jù)庫行業(yè)未來發(fā)展趨勢等方面，進行闡述，現(xiàn)將部分訪談內(nèi)容分享。

基于解決數(shù)據(jù)庫擴展性問題的初衷，產(chǎn)品可同時滿足TP 和 AP 業(yè)務(wù)需求

愛分析：您創(chuàng)立PingCAP 的初衷是什么？

劉奇：我在京東工作的時候就已經(jīng)有這個想法，當(dāng)時沒有一個可以很好實現(xiàn)擴展的數(shù)據(jù)庫，最普遍的做法是分庫分表。但這種方式存在缺點，第一它的彈性擴展能力比較差，第二是易用性比較差，第三是編程的心智負(fù)擔(dān)比較大，第四是表達力比較弱。

當(dāng)時我在做一個項目，也需要分布式數(shù)據(jù)庫，但是市面上沒有令人滿意的產(chǎn)品。

所以，最開始的定位是想解決自己的問題，中間我們還開發(fā)了一個分布式緩存，之后我們開始著手解決數(shù)據(jù)庫擴展性的問題，就出來創(chuàng)業(yè)了。

愛分析：數(shù)據(jù)庫作為底層技術(shù)，客戶選擇供應(yīng)商會非常謹(jǐn)慎，最初是如何獲取客戶的？

劉奇：2016 年，我們拿到了云啟資本的 A 輪融資之后，開始考慮怎么去獲取第一批用戶。的確，用戶將一個新的數(shù)據(jù)庫應(yīng)用到線上是存在風(fēng)險的，誰愿意拿自己線上的業(yè)務(wù)去冒險嘗試一個全新的數(shù)據(jù)庫?

蓋婭互娛是我們第一個用戶。那個時候，他們的MySQL 數(shù)據(jù)庫出現(xiàn)了問題，線上查詢速度特別慢，整個系統(tǒng)已經(jīng)卡頓到無法使用，不嘗試使用新的技術(shù)已經(jīng)很難開展業(yè)務(wù)。我們當(dāng)時的產(chǎn)品還在測試階段，他們就開始推動這個數(shù)據(jù)庫上線。

因為采用新的數(shù)據(jù)庫到線上確實是存在風(fēng)險的，因此很多用戶采用另一個方式來做。線上有一堆MySQL 在運行，他們在后面搭建一個大的數(shù)據(jù)集群，把所有的數(shù)據(jù)全部匯到這里，看起來有點像數(shù)倉。因為我們本身是兼容協(xié)議的，我們可以把數(shù)據(jù)復(fù)制過來，他們來進行實時查詢。

在游戲行業(yè)或者是實時性要求比較高的風(fēng)控管理，他們就急需要這種技術(shù)來解決問題。

我們目前披露了很多金融案例，有相當(dāng)一部分都是用在實時風(fēng)控這個場景。好處是不直接針對線上業(yè)務(wù)，風(fēng)險相比線上MySQL 要小，而又剛好解決了他們的痛點。

這個階段之后，客戶如果覺得技術(shù)足夠穩(wěn)定，他會把線上撤下來，再把我們的產(chǎn)品推到最前面去，來支撐所有業(yè)務(wù)。

當(dāng)客戶把我們的數(shù)據(jù)庫當(dāng)作數(shù)倉的時候，其實查詢的復(fù)雜程度很高，我們的數(shù)據(jù)庫能幫助客戶做一些以前不敢做的事情，一個SQL 查詢語句甚至好幾頁紙那么長。

那么問題來了，我們的設(shè)計本身并不是為了AP 業(yè)務(wù)，而查詢這個功能是側(cè)重 AP 的，因此我們在優(yōu)化執(zhí)行器的時候，也做了相應(yīng)的調(diào)整，做了 AP 功能的拓展。

這樣一來，我們的產(chǎn)品能同時支持線上TP 和 AP 業(yè)務(wù)，我們的產(chǎn)品就變成 HTAP。

當(dāng)把這個產(chǎn)品做好之后，我們發(fā)現(xiàn)產(chǎn)品的特點十分明顯，在這個領(lǐng)域沒有一個強有力的競爭對手，而且這個產(chǎn)品是滿足用戶需求的。很多時候用戶的需求并不能簡單的分為TP 還是 AP，實際上是沒有明確定義的，甚至客戶并不關(guān)心這些，只希望能夠解決自身的問題。

愛分析：從數(shù)據(jù)寫入和查詢上看，存在行與列的差別，TiDB 如何在一個表里實現(xiàn)的？

劉奇：行列只是一個存儲的形式，從技術(shù)角度來講還是可以做行列變化的。

比如說把冷數(shù)據(jù)慢慢的后臺轉(zhuǎn)成列存，然后最新寫入的數(shù)據(jù)仍然使用行存。前臺還是一個標(biāo)準(zhǔn)的行存，根據(jù)數(shù)據(jù)的冷熱，轉(zhuǎn)換成行存還是列存。

其實，最新的論文已經(jīng)提出了新的觀點，數(shù)據(jù)的存儲并不純粹的是行存或者列存，而是根據(jù)訪問頻率，經(jīng)常訪問的數(shù)據(jù)使用行存，并不需要掃整個表，實現(xiàn)的方式還是很多樣的。

愛分析：谷歌在做Spanner 的時候強調(diào)其擴展性，在算力上要求是不是比較低？

劉奇：這是以前谷歌的一個理念，但這樣的話，如果去做一些相對比較復(fù)雜的運算的時候，數(shù)據(jù)庫的反應(yīng)時間會比較長，這是存儲格式?jīng)Q定的。

不過，谷歌2017 年的論文當(dāng)中，已經(jīng)把存儲格式改成了偏混存的形式。我們跟谷歌的迭代路線是一樣的，而且我們的存儲格式改的更早，因為我們更早的遇到了用戶的實際需求。

愛分析：算法和擴展性是否存在一定的矛盾，復(fù)雜的算法會不會影響其擴展性能？

劉奇：算法和擴展性沒有什么關(guān)系，算法主要影響執(zhí)行的效率。

比如，如果是列存的話，執(zhí)行效率更高，比如說銀行對所有賬戶的金額進行求和，如果是列存的話會很簡單，但是行存的話要掃描每一行中的金額數(shù)據(jù)，執(zhí)行效率很低，但在下層的計算層面并不會有太大的差別。

愛分析：在推到前臺的時候，數(shù)據(jù)庫要做哪方面的調(diào)整？

劉奇：要根據(jù)整個系統(tǒng)的負(fù)載，來決定使用多少并發(fā)度，會做一些優(yōu)化。

假設(shè)有100 臺機器，有這樣一個數(shù)據(jù)集群，均勻地推到每一臺機器上計算，并發(fā)度很高的情況下，每臺機器人可能都很忙，這個時候再給它增加任務(wù)是沒有用的，機器會崩潰的。

但如果有一個“聰明”的調(diào)度器，對指令進行控制，在保持高并發(fā)的狀態(tài)下，調(diào)度不同的機器進行不同運算，這樣機器不至于很忙，不過帶來的問題是，會帶來比較長的延遲。

當(dāng)然，同樣的數(shù)據(jù)可能不一定要運用CPU 來運算，可以用 GPU 或者 FPGA，這對調(diào)度器的要求就更高了，按照發(fā)展趨勢來看，調(diào)度器的能力是衡量一個數(shù)據(jù)庫性能的重要指標(biāo)。

愛分析：TiDB 是如何實現(xiàn)實時性的？

劉奇：因為他本身就是一個分布式的結(jié)構(gòu)，性能是可以繼續(xù)擴展的，前面有多少數(shù)據(jù)的輸入都無所謂。如果現(xiàn)在覺得算的不夠快，通過加機器就可以實現(xiàn)計算。

速度的快慢還跟計算有關(guān)系，有的計算是推不到所有的節(jié)點上去的。比如，我要把所有的數(shù)據(jù)拿回來做排序，這就沒有辦法讓所有節(jié)點來做。

這種情況，優(yōu)化器的作用比較重要，它會識別哪些計算需要推到下面做并行運算，哪些只要做出決定就可以。

愛分析：MySQL 構(gòu)架，數(shù)據(jù)遷移到 TiDB 能否做到無感遷移？

劉奇：我們從一開始設(shè)計的時候就考慮到了這個問題，針對MySQL 可以做到無感遷移，如果是 Oracle 或者 DB2 的其它協(xié)議的話，可能涉及到改代碼的問題。

愛分析：面向其它協(xié)議，遷移的周期有多長？

劉奇：這個還要考慮業(yè)務(wù)的復(fù)雜度，比如，原來的業(yè)務(wù)有10 萬條 SQL，只要都要驗證一遍，如果本身業(yè)務(wù)比較復(fù)雜，那就會比較快。MySQL 協(xié)議這邊，我們很快就可以做 POC。

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

劉奇：我們沒有這方面的打算，因為新的業(yè)務(wù)已經(jīng)不用這些技術(shù)了。如果考慮這些的話，目的就是切入老項目。在切入老項目時兼容性存在一個問題，用戶需要知道新技術(shù)的兼容性到底是多少?我能不能放心的使用新技術(shù)替換?

兼容性不僅是功能的兼容，Bug 也要兼容，真正做到 100% 兼容是很難的，企業(yè)原來的程序員可能也離職了，如果去替換老的業(yè)務(wù)，工作量、風(fēng)險都會很大。

現(xiàn)階段互聯(lián)網(wǎng)金融、游戲等偏互聯(lián)網(wǎng)行業(yè)是重點行業(yè)，適用于數(shù)據(jù)量大、業(yè)務(wù)復(fù)雜性高的場景

愛分析：產(chǎn)品主要針對哪些行業(yè)的客戶？

劉奇：我們在商業(yè)化的過程中，最重要的是把產(chǎn)品做出來，然后根據(jù)客戶的需求去完善它的功能。

另外，我們的產(chǎn)品是開源的。開源的好處是當(dāng)用戶在使用過程中會及時反饋他們的使用體驗和遇到的問題，在這個過程中會發(fā)現(xiàn)我們的潛在用戶是誰。

我們的第一個用戶是游戲公司，這其實是超出了我們的預(yù)計的，我們認(rèn)為可能是互聯(lián)網(wǎng)優(yōu)先，因為互聯(lián)網(wǎng)對新技術(shù)比較激進。

游戲行業(yè)也有其特點，游戲公司最賺錢的肯定是爆款游戲的運營，一天的流水可能就有幾千萬。他們希望自己的基礎(chǔ)設(shè)施是足夠穩(wěn)定、強大的，一旦遇到瓶頸再去停機改造，那造成的損失就會很大，因此，他們也希望通過新的技術(shù)來解決問題。

再一個就是互聯(lián)網(wǎng)以及傳統(tǒng)行業(yè)，互聯(lián)網(wǎng)企業(yè)在使用我們的新產(chǎn)品的時候，表現(xiàn)得還是很保守的，因為前面已經(jīng)有那么多的MySQL 在使用，突然換新的技術(shù)他們會覺得風(fēng)險很高。

不過，像互聯(lián)網(wǎng)金融這類企業(yè)對實時性要求還是很高的，要通過實時的信息進行風(fēng)控管理，以前的方案是無法滿足的，所以會選擇使用我們的產(chǎn)品。

愛分析：TiDB 的應(yīng)用場景有哪些？

劉奇：我們的數(shù)據(jù)庫通用性比較強，一般是面向新的業(yè)務(wù)需求，我們自身并沒有將數(shù)據(jù)庫設(shè)計成面向某一行業(yè)的產(chǎn)品。

說到我們產(chǎn)品的優(yōu)勢，客戶的數(shù)據(jù)量必須達到億級別以上，如果數(shù)據(jù)量比較小，就沒有必要上分布式數(shù)據(jù)庫;另外，就是業(yè)務(wù)的復(fù)雜性要比較高，這樣我們的優(yōu)勢更加明顯。

愛分析：下一步會重點側(cè)重哪幾個行業(yè)？

劉奇：從營收的角度來講，金融應(yīng)該會是我們重點布局的一個行業(yè)，像物流、醫(yī)療等其他領(lǐng)域數(shù)據(jù)增速也比較快。

團隊主要來自互聯(lián)網(wǎng)公司，銷售人員極少

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

劉奇：我們在2017 年運行在生產(chǎn)環(huán)境的用戶達到 200 個，產(chǎn)品客單價比較高，付費用戶要少一些。

愛分析：TiDB 是一個開源技術(shù)，在提供企業(yè)級產(chǎn)品時會做哪些強化？

劉奇：雖然我們提供一個開源技術(shù)，但還是有部分是閉源的，比如監(jiān)控運維組件，備份工具，安全性工具等。

對于企業(yè)應(yīng)用來說，它必須具備很漂亮的用戶界面、很方面的操作工具，這是我們企業(yè)版提供的方式。

還有一部分，我們叫做Database & Service，我們提供的不僅是一個數(shù)據(jù)庫，而是一個數(shù)據(jù)庫平臺，企業(yè)用戶可以申請 TiDB 數(shù)據(jù)集群。如果沒有這個東西，可能就需要管理員手動處理，使用體驗差別是很大的。

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

劉奇：我們現(xiàn)在有兩方面考慮：一方面可以利用云部署，我們可以看到騰訊云的數(shù)據(jù)庫入口，這個商業(yè)模式比較簡單，與云上的其它產(chǎn)品一樣，按照租賃的方式進行收費。

另一方面，可以買我們的subscription，也可以買我們的 license，按照節(jié)點數(shù)來計算。

愛分析：公司的團隊規(guī)模？

劉奇：現(xiàn)在公司大概100 個人，研發(fā)占比比較高，有 82 個。銷售人員只有 1 個，銷售比較少是因為用戶都是自己找過來的，我們在這方面沒有太大的投入。

我們對研發(fā)的要求還是很高的，包括研發(fā)人員對外面的支持、響應(yīng)的速度等。雖然看上去不會像Oracle 那么夸張，但有很多外部公司在給我們做貢獻。

比如，調(diào)度器方面的代碼很多是摩拜貢獻的，很多場景下的優(yōu)化是今日頭條貢獻的，包括韓國三星研究院等，還有很多人在幫我們做測試，這也體現(xiàn)了開源技術(shù)的一個好處。

愛分析：研發(fā)人員會承擔(dān)一部分售前的工作嗎？

劉奇：在17 年的時候還存在一些研發(fā)人員做售前工作的情況，但 18 年我們會做出一些調(diào)整，這也是我們一個很重要的任務(wù)。

人員結(jié)構(gòu)的建設(shè)要形成一個完整的體系，售前、實施、研發(fā)各司其職，根據(jù)不同階段的問題安排不同的人去解決。

愛分析：銷售人員比較少的情況下，是不是對社區(qū)的運營提出更高的要求？

劉奇：我認(rèn)為研發(fā)人員比較多，跟社區(qū)的交流就會比較快。社區(qū)中最主要的用戶是開發(fā)者，與開發(fā)者的交流肯定是研發(fā)人員更加順暢，銷售人員沒法替代這個角色。比如，用戶提出有部分代碼存在問題，研發(fā)的響應(yīng)速度會很快。

像今日頭條、摩拜、同程這些規(guī)模比較大的用戶，都是因為存在痛點主動聯(lián)系到我們，不需要銷售去做額外的工作。

當(dāng)然，社區(qū)中還存在許多規(guī)模比較小的用戶，小的用戶雖然沒有那么大的付費能力，但對社區(qū)來說也是有直接作用的。

他們會用自己的場景進行測試，發(fā)現(xiàn)很多我們從來沒有遇見過的問題，他們所提供的這些信息對我們來說也是十分重要的，因此我們會花費比較大的力氣來運營社區(qū)。

愛分析：PingCAP 的團隊背景以互聯(lián)網(wǎng)居多？

劉奇：對，互聯(lián)網(wǎng)出身的多一些，都是規(guī)模比較大的互聯(lián)網(wǎng)公司，都體會過數(shù)據(jù)量大了之后帶來的痛苦。

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

愛分析：切入傳統(tǒng)行業(yè)的話，是不是對人員結(jié)構(gòu)的要求有變化？

劉奇：目前我們還不是這么想的，我們希望通過產(chǎn)品就能夠直接拿下客戶，能夠體現(xiàn)我們產(chǎn)品的優(yōu)勢。如果是用誰的數(shù)據(jù)庫都一樣的客戶，我們是不會去爭取的，這也不是我們的強項。

愛分析：產(chǎn)品的研發(fā)和社區(qū)的維護，精力如何平衡？

劉奇：我們肯定會先做好一個基礎(chǔ)版，才會在社區(qū)中推廣，當(dāng)遇到Bug 的時候一定要去修復(fù)，不然會影響到很多人的使用，兩者共同推進，并不沖突。

內(nèi)部研發(fā)方面，我們會快速的開發(fā)很多新的功能，這些不會馬上就應(yīng)用到穩(wěn)定版本，而是先在社區(qū)發(fā)布一個Beta 版本，通過用戶測試發(fā)現(xiàn) Bug，我們來進行修復(fù)，在不斷的溝通之后，我們才會發(fā)布穩(wěn)定版。

在這個過程當(dāng)中，我們需要通過社區(qū)讓用戶不斷的進行測試來跟我們反饋。因為產(chǎn)品行不行并不是我們自己說了算的，而是用戶來判斷的。

TP 和 AP 融合是未來趨勢，數(shù)據(jù)庫市場未來會更加多樣化

愛分析：CAP 原理中的一致性和可用性存在一定的矛盾，怎么進行優(yōu)化？

劉奇：我們在未來會提供一個選項，用戶可以根據(jù)自己的需求自己選擇，高一致性或者高可用性。比如銀行的數(shù)據(jù)就要求高一致性，而互聯(lián)網(wǎng)應(yīng)用就更側(cè)重高可用性，我們會都提供給用戶，讓用戶來選。

愛分析：NewSQL 技術(shù)與之前的技術(shù)有什么不同？

劉奇：歷史上最開始應(yīng)用的是SQL，后來為什么會出現(xiàn) NoSQL，是因為 SQL 不能擴展，雖然 NoSQL 具備了擴展的能力，但表達力比較差，可能還不支持事務(wù)處理，不具備 SQL 的傳統(tǒng)優(yōu)勢。

NewSQL 就相當(dāng)于同時具備了兩個優(yōu)勢，既能很好的擴展，又能具備 SQL 的事務(wù)處理能力和表達力。

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

劉奇：我們認(rèn)為是這樣的，用戶是不關(guān)心是TP 還是 AP 的，解決問題就是硬道理，也不管是線上還是線下，能實時實現(xiàn)我肯定不愿意等一天。

TP 和 AP 分開這是歷史原因造成的，在數(shù)據(jù)庫剛誕生的時候并沒有去區(qū)分?，F(xiàn)在技術(shù)能做得到，肯定還是希望融合在一塊。數(shù)據(jù)分析比較復(fù)雜的情況可能還會存在單獨的 AP，但我們的產(chǎn)品還在快速的迭代，最后還是要看誰的性能更勝一籌。

愛分析：分布式數(shù)據(jù)庫平臺領(lǐng)域?qū)頃粫a(chǎn)生另一個Oracle？

劉奇：因為歷史原因，短時間內(nèi)Oracle 的地位是不可替代的，但新的數(shù)據(jù)庫構(gòu)架興起的也很快，現(xiàn)在 Oracle 遇到了前所未有的挑戰(zhàn)，我認(rèn)為在未來兩年，將會有 20% 的傳統(tǒng)數(shù)據(jù)庫被新的數(shù)據(jù)庫取代。

看現(xiàn)在我們的用戶增速，這個趨勢還是相當(dāng)明顯的。

愛分析：未來市場的格局會發(fā)生哪些變化？

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

首先，現(xiàn)在的需求非常碎片化，傳統(tǒng)數(shù)據(jù)庫不能很好的表達，例如對Streaming 要求越來越高。

關(guān)系型數(shù)據(jù)庫的優(yōu)勢是通用性比較強，也比較均衡。但有些場景用現(xiàn)在的數(shù)據(jù)庫框架是很難適應(yīng)的，肯定不會比專門的設(shè)計的數(shù)據(jù)庫用起來順暢，如圖數(shù)據(jù)庫等。

從發(fā)展趨勢來看，當(dāng)NoSQL 出來的時候，大家會考慮它能替代什么樣的場景，后來發(fā)現(xiàn) NoSQL 還是存在很多約束的。NewSQL 的出現(xiàn)確實會改變市場格局，應(yīng)該以后會有兩三家比較大體量的公司吃掉大部分市場，但小公司依然存在。

愛分析：開源技術(shù)的發(fā)展會不會影響到數(shù)據(jù)庫公司的業(yè)務(wù)？

劉奇：其實開源技術(shù)已經(jīng)存在很長時間了，像MySQL 已經(jīng)有二十幾年的歷史，但企業(yè)級應(yīng)用畢竟不是那么簡單，還存在很多問題需要團隊去解決。

未來不會有完全免費的數(shù)據(jù)庫，就算是開源的也是要收費的。

愛分析：互聯(lián)網(wǎng)公司一般會自己開發(fā)基礎(chǔ)設(shè)施，會不會對PingCAP 造成影響？

劉奇：這個事情要分國內(nèi)和國外來看，國內(nèi)的公司喜歡建設(shè)私有云，國外差別就比較大，很多國外公司都把自己的私有云給拆掉了，原因也很簡單，自己部署私有云的效率并不如直接使用成熟的公有云。

現(xiàn)在很多互聯(lián)網(wǎng)公司不想再像過去那樣被Oracle 這樣的公司 Lock in，我既要用你的數(shù)據(jù)庫，又必須具備一定的掌控力。因為互聯(lián)網(wǎng)公司成長是很快的，需求的變化也更加明顯，他們希望對數(shù)據(jù)庫具有一定的理解力和掌控力，以方便互聯(lián)網(wǎng)企業(yè)修改數(shù)據(jù)代碼，滿足自身定制化的需求。

愛分析：云廠商最后會不會成為數(shù)據(jù)庫企業(yè)的競爭對手？

劉奇：數(shù)據(jù)庫跟云的關(guān)系，有點像APP 和 APP Store 的關(guān)系。云廠商可能也會做數(shù)據(jù)庫，但更多的應(yīng)該是一種合作關(guān)系。

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。