調研| 李喆 王琦
撰寫| 李喆
即使將范圍從大數(shù)據(jù)縮小到數(shù)據(jù)庫這個細分領域，PingCAP 依然是家非常特殊的公司，其產品 TiDB 是市面上為數(shù)不多面向 HTAP 場景的數(shù)據(jù)庫。
傳統(tǒng)意義上，數(shù)據(jù)庫分成事務性數(shù)據(jù)庫(TP)和分析性數(shù)據(jù)庫(AP)。
近幾年興起的NoSQL 數(shù)據(jù)庫、如 MongoDB、基于 Hadoop 的 Hbase，更多都是分析性數(shù)據(jù)庫，通過分布式架構解決大規(guī)模的數(shù)據(jù)查詢、分析問題。
然而，承載生產系統(tǒng)的事務性數(shù)據(jù)庫卻始終被傳統(tǒng)數(shù)據(jù)庫廠商所把持，Oracle、IBM 等占據(jù)傳統(tǒng)大型企業(yè)市場，中小企業(yè)及互聯(lián)網公司則大多數(shù)采用開源技術 MySQL，鮮有新技術、新公司能夠進入這個市場。
2012 年，Google 的 Spanner 橫空出世，這是一款基于分布式架構的事務性數(shù)據(jù)庫。受到 Google 的啟發(fā)，國外出現(xiàn)了 CockroachDB(蟑螂數(shù)據(jù)庫)等一系列解決 TP 問題的新興數(shù)據(jù)庫廠商，但國內市場幾乎還是空白，找不到研發(fā)這類數(shù)據(jù)庫的創(chuàng)業(yè)公司。
2015 年，PingCAP 成立，填補了國內的空白。
互聯(lián)網背景的團隊，用開源模式做數(shù)據(jù)庫
與市面上其他數(shù)據(jù)庫廠商不同的是，PingCAP 創(chuàng)始團隊大多數(shù)來自大型互聯(lián)網公司，如豌豆莢、京東等，幾乎沒有來自傳統(tǒng)IT或者數(shù)據(jù)庫廠商。
互聯(lián)網的背景，創(chuàng)始團隊每名成員都經歷過數(shù)據(jù)指數(shù)級增長的時期，具備處理海量數(shù)據(jù)的經驗，做數(shù)據(jù)庫產品會優(yōu)先考慮擴展性。
同時，因為互聯(lián)網公司大多會采取MySQL 技術，因此 TiDB 最先兼容的是 MySQL 協(xié)議，這使得 PingCAP 更容易獲取客戶。
互聯(lián)網還有個特點是開源為先，PingCAP 從第一天就確立了用開源方式做數(shù)據(jù)庫的打法。但與其他團隊不同的是，PingCAP 的創(chuàng)始人劉奇等人，曾經是分布式緩存項目 Codis 的作者，具備開源社區(qū)運營的能力，懂得如何借助社區(qū)力量發(fā)展產品。
開源社區(qū)一方面會擴大PingCAP 產品的覆蓋面，帶來潛在的客戶;另一方面，通過開源社區(qū)的運營，PingCAP 將更多精力放在核心產品 TiDB 的研發(fā)，其他功能可以一部分由開源社區(qū)用戶來實現(xiàn)。
此外，通過用戶反饋，PingCAP 可以了解用戶的潛在需求，作為 TiDB 研發(fā)的一個參考。
產品同時支持TP 和 AP，強一致性和擴展性是主要特點
最初，TiDB 只是解決 TP 問題，但在實際應用過程中，直接讓客戶用新數(shù)據(jù)庫替代原先的 MySQL 數(shù)據(jù)庫難度很大，尤其當數(shù)據(jù)庫廠商是一家名不見經傳的初創(chuàng)公司。
多數(shù)企業(yè)客戶的做法是前端仍然保留傳統(tǒng)MySQL 數(shù)據(jù)庫，將 TiDB 數(shù)據(jù)庫作為背后的數(shù)據(jù)集市，與前端數(shù)據(jù)庫相連，但這個數(shù)據(jù)集市的實時性要遠好于 Hadoop 架構的數(shù)據(jù)集市，可以運行在實際生產系統(tǒng)。
當按照這種方式運行一段時間，客戶認可PingCAP 的產品后，會逐步替換掉 MySQL 數(shù)據(jù)庫，將 TiDB 作為前端數(shù)據(jù)庫。
當客戶將TiDB 數(shù)據(jù)庫作為數(shù)據(jù)集市來使用時，因為前端數(shù)據(jù)庫要從這個數(shù)據(jù)集市中查詢數(shù)據(jù)，因此，對 TiDB 數(shù)據(jù)庫的查詢功能提出更高要求。TiDB 調整了自己的數(shù)據(jù)庫執(zhí)行器，進行 AP 功能的拓展。
這樣一來，TiDB 同時支持 TP 和 AP 功能，成為分布式 HTAP(Hybrid Transactional/Analytical Processing)數(shù)據(jù)庫產品。
TP 場景下，TiDB 具備強一致性的特點，可以承載金融等對數(shù)據(jù)一致性敏感度很高的行業(yè)。與傳統(tǒng)數(shù)據(jù)庫相比，TiDB 可擴展性是最大優(yōu)勢。TiDB 可以通過不斷增加機器來提升性能。
AP 場景下，與 Hbase 等相比，PingCAP 的實時性更好，處理數(shù)據(jù)的速度更快。
現(xiàn)階段主要覆蓋互聯(lián)網金融、游戲等互聯(lián)網領域，銷售線索主要來自開源社區(qū)
與傳統(tǒng)企業(yè)相比，互聯(lián)網公司更加容易嘗試新技術，互聯(lián)網背景出身的團隊也更加能夠清楚互聯(lián)網公司的業(yè)務特點。
同時，互聯(lián)網公司的發(fā)展速度大多遠超傳統(tǒng)企業(yè)，數(shù)據(jù)量增長速度極快，對改善底層技術架構、提升數(shù)據(jù)庫性能的需求更加強烈，特別是在游戲行業(yè)、互聯(lián)網金融行業(yè)。
這些因素促使PingCAP 早期客戶大多數(shù)來自互聯(lián)網企業(yè)，同程旅游、360 金融、摩拜單車等都陸續(xù)成為 PingCAP 的客戶。
截至2017 年底，PingCAP 整體團隊規(guī)模達到 100 人左右，其中超過 80% 是研發(fā)，只有一名全職銷售。
一名銷售的獲客能力非常有限，PingCAP 主要還是通過開源社區(qū)的方式獲客，銷售人員只負責跟進有意向的企業(yè)。2017 年，應用在實際生產環(huán)境的用戶達到 200 家，最終產生十幾家付費客戶。
現(xiàn)階段，PingCAP 重點仍然放在產品打磨和社區(qū)運營上，尚未進入到產品大范圍推廣階段，因此，2018 年 PingCAP 會考慮進入金融、醫(yī)療、物流等傳統(tǒng)行業(yè)，但不會大范圍增加銷售團隊，仍然會采取較為謹慎的市場策略。
近期，愛分析對PingCAP 創(chuàng)始人劉奇進行訪談，他對 PingCAP 的業(yè)務模式、未來戰(zhàn)略，以及數(shù)據(jù)庫行業(yè)未來發(fā)展趨勢等方面，進行闡述，現(xiàn)將部分訪談內容分享。
基于解決數(shù)據(jù)庫擴展性問題的初衷，產品可同時滿足TP 和 AP 業(yè)務需求
愛分析：您創(chuàng)立PingCAP 的初衷是什么？
劉奇：我在京東工作的時候就已經有這個想法，當時沒有一個可以很好實現(xiàn)擴展的數(shù)據(jù)庫，最普遍的做法是分庫分表。但這種方式存在缺點，第一它的彈性擴展能力比較差，第二是易用性比較差，第三是編程的心智負擔比較大，第四是表達力比較弱。
當時我在做一個項目，也需要分布式數(shù)據(jù)庫，但是市面上沒有令人滿意的產品。
所以，最開始的定位是想解決自己的問題，中間我們還開發(fā)了一個分布式緩存，之后我們開始著手解決數(shù)據(jù)庫擴展性的問題，就出來創(chuàng)業(yè)了。
愛分析：數(shù)據(jù)庫作為底層技術，客戶選擇供應商會非常謹慎，最初是如何獲取客戶的？
劉奇：2016 年，我們拿到了云啟資本的 A 輪融資之后，開始考慮怎么去獲取第一批用戶。的確，用戶將一個新的數(shù)據(jù)庫應用到線上是存在風險的，誰愿意拿自己線上的業(yè)務去冒險嘗試一個全新的數(shù)據(jù)庫?
蓋婭互娛是我們第一個用戶。那個時候，他們的MySQL 數(shù)據(jù)庫出現(xiàn)了問題，線上查詢速度特別慢，整個系統(tǒng)已經卡頓到無法使用，不嘗試使用新的技術已經很難開展業(yè)務。我們當時的產品還在測試階段，他們就開始推動這個數(shù)據(jù)庫上線。
因為采用新的數(shù)據(jù)庫到線上確實是存在風險的，因此很多用戶采用另一個方式來做。線上有一堆MySQL 在運行，他們在后面搭建一個大的數(shù)據(jù)集群，把所有的數(shù)據(jù)全部匯到這里，看起來有點像數(shù)倉。因為我們本身是兼容協(xié)議的，我們可以把數(shù)據(jù)復制過來，他們來進行實時查詢。
在游戲行業(yè)或者是實時性要求比較高的風控管理，他們就急需要這種技術來解決問題。
我們目前披露了很多金融案例，有相當一部分都是用在實時風控這個場景。好處是不直接針對線上業(yè)務，風險相比線上MySQL 要小，而又剛好解決了他們的痛點。
這個階段之后，客戶如果覺得技術足夠穩(wěn)定，他會把線上撤下來，再把我們的產品推到最前面去，來支撐所有業(yè)務。
當客戶把我們的數(shù)據(jù)庫當作數(shù)倉的時候，其實查詢的復雜程度很高，我們的數(shù)據(jù)庫能幫助客戶做一些以前不敢做的事情，一個SQL 查詢語句甚至好幾頁紙那么長。
那么問題來了，我們的設計本身并不是為了AP 業(yè)務，而查詢這個功能是側重 AP 的，因此我們在優(yōu)化執(zhí)行器的時候，也做了相應的調整，做了 AP 功能的拓展。
這樣一來，我們的產品能同時支持線上TP 和 AP 業(yè)務，我們的產品就變成 HTAP。
當把這個產品做好之后，我們發(fā)現(xiàn)產品的特點十分明顯，在這個領域沒有一個強有力的競爭對手，而且這個產品是滿足用戶需求的。很多時候用戶的需求并不能簡單的分為TP 還是 AP，實際上是沒有明確定義的，甚至客戶并不關心這些，只希望能夠解決自身的問題。
愛分析：從數(shù)據(jù)寫入和查詢上看，存在行與列的差別，TiDB 如何在一個表里實現(xiàn)的？
劉奇：行列只是一個存儲的形式，從技術角度來講還是可以做行列變化的。
比如說把冷數(shù)據(jù)慢慢的后臺轉成列存，然后最新寫入的數(shù)據(jù)仍然使用行存。前臺還是一個標準的行存，根據(jù)數(shù)據(jù)的冷熱，轉換成行存還是列存。
其實，最新的論文已經提出了新的觀點，數(shù)據(jù)的存儲并不純粹的是行存或者列存，而是根據(jù)訪問頻率，經常訪問的數(shù)據(jù)使用行存，并不需要掃整個表，實現(xiàn)的方式還是很多樣的。
愛分析：谷歌在做Spanner 的時候強調其擴展性，在算力上要求是不是比較低？
劉奇：這是以前谷歌的一個理念，但這樣的話，如果去做一些相對比較復雜的運算的時候，數(shù)據(jù)庫的反應時間會比較長，這是存儲格式決定的。
不過，谷歌2017 年的論文當中，已經把存儲格式改成了偏混存的形式。我們跟谷歌的迭代路線是一樣的，而且我們的存儲格式改的更早，因為我們更早的遇到了用戶的實際需求。
愛分析：算法和擴展性是否存在一定的矛盾，復雜的算法會不會影響其擴展性能？
劉奇：算法和擴展性沒有什么關系，算法主要影響執(zhí)行的效率。
比如，如果是列存的話，執(zhí)行效率更高，比如說銀行對所有賬戶的金額進行求和，如果是列存的話會很簡單，但是行存的話要掃描每一行中的金額數(shù)據(jù)，執(zhí)行效率很低，但在下層的計算層面并不會有太大的差別。
愛分析：在推到前臺的時候，數(shù)據(jù)庫要做哪方面的調整？
劉奇：要根據(jù)整個系統(tǒng)的負載，來決定使用多少并發(fā)度，會做一些優(yōu)化。
假設有100 臺機器，有這樣一個數(shù)據(jù)集群，均勻地推到每一臺機器上計算，并發(fā)度很高的情況下，每臺機器人可能都很忙，這個時候再給它增加任務是沒有用的，機器會崩潰的。
但如果有一個“聰明”的調度器，對指令進行控制，在保持高并發(fā)的狀態(tài)下，調度不同的機器進行不同運算，這樣機器不至于很忙，不過帶來的問題是，會帶來比較長的延遲。
當然，同樣的數(shù)據(jù)可能不一定要運用CPU 來運算，可以用 GPU 或者 FPGA，這對調度器的要求就更高了，按照發(fā)展趨勢來看，調度器的能力是衡量一個數(shù)據(jù)庫性能的重要指標。
愛分析：TiDB 是如何實現(xiàn)實時性的？
劉奇：因為他本身就是一個分布式的結構，性能是可以繼續(xù)擴展的，前面有多少數(shù)據(jù)的輸入都無所謂。如果現(xiàn)在覺得算的不夠快，通過加機器就可以實現(xiàn)計算。
速度的快慢還跟計算有關系，有的計算是推不到所有的節(jié)點上去的。比如，我要把所有的數(shù)據(jù)拿回來做排序，這就沒有辦法讓所有節(jié)點來做。
這種情況，優(yōu)化器的作用比較重要，它會識別哪些計算需要推到下面做并行運算，哪些只要做出決定就可以。
愛分析：MySQL 構架，數(shù)據(jù)遷移到 TiDB 能否做到無感遷移？
劉奇：我們從一開始設計的時候就考慮到了這個問題，針對MySQL 可以做到無感遷移，如果是 Oracle 或者 DB2 的其它協(xié)議的話，可能涉及到改代碼的問題。
愛分析：面向其它協(xié)議，遷移的周期有多長？
劉奇：這個還要考慮業(yè)務的復雜度，比如，原來的業(yè)務有10 萬條 SQL，只要都要驗證一遍，如果本身業(yè)務比較復雜，那就會比較快。MySQL 協(xié)議這邊，我們很快就可以做 POC。
愛分析：下一步有沒有考慮去支持Oracle 或 DB2 的快速遷移？
劉奇：我們沒有這方面的打算，因為新的業(yè)務已經不用這些技術了。如果考慮這些的話，目的就是切入老項目。在切入老項目時兼容性存在一個問題，用戶需要知道新技術的兼容性到底是多少?我能不能放心的使用新技術替換?
兼容性不僅是功能的兼容，Bug 也要兼容，真正做到 100% 兼容是很難的，企業(yè)原來的程序員可能也離職了，如果去替換老的業(yè)務，工作量、風險都會很大。
現(xiàn)階段互聯(lián)網金融、游戲等偏互聯(lián)網行業(yè)是重點行業(yè)，適用于數(shù)據(jù)量大、業(yè)務復雜性高的場景
愛分析：產品主要針對哪些行業(yè)的客戶？
劉奇：我們在商業(yè)化的過程中，最重要的是把產品做出來，然后根據(jù)客戶的需求去完善它的功能。
另外，我們的產品是開源的。開源的好處是當用戶在使用過程中會及時反饋他們的使用體驗和遇到的問題，在這個過程中會發(fā)現(xiàn)我們的潛在用戶是誰。
我們的第一個用戶是游戲公司，這其實是超出了我們的預計的，我們認為可能是互聯(lián)網優(yōu)先，因為互聯(lián)網對新技術比較激進。
游戲行業(yè)也有其特點，游戲公司最賺錢的肯定是爆款游戲的運營，一天的流水可能就有幾千萬。他們希望自己的基礎設施是足夠穩(wěn)定、強大的，一旦遇到瓶頸再去停機改造，那造成的損失就會很大，因此，他們也希望通過新的技術來解決問題。
再一個就是互聯(lián)網以及傳統(tǒng)行業(yè)，互聯(lián)網企業(yè)在使用我們的新產品的時候，表現(xiàn)得還是很保守的，因為前面已經有那么多的MySQL 在使用，突然換新的技術他們會覺得風險很高。
不過，像互聯(lián)網金融這類企業(yè)對實時性要求還是很高的，要通過實時的信息進行風控管理，以前的方案是無法滿足的，所以會選擇使用我們的產品。
愛分析：TiDB 的應用場景有哪些？
劉奇：我們的數(shù)據(jù)庫通用性比較強，一般是面向新的業(yè)務需求，我們自身并沒有將數(shù)據(jù)庫設計成面向某一行業(yè)的產品。
說到我們產品的優(yōu)勢，客戶的數(shù)據(jù)量必須達到億級別以上，如果數(shù)據(jù)量比較小，就沒有必要上分布式數(shù)據(jù)庫;另外，就是業(yè)務的復雜性要比較高，這樣我們的優(yōu)勢更加明顯。
愛分析：下一步會重點側重哪幾個行業(yè)？
劉奇：從營收的角度來講，金融應該會是我們重點布局的一個行業(yè)，像物流、醫(yī)療等其他領域數(shù)據(jù)增速也比較快。
團隊主要來自互聯(lián)網公司，銷售人員極少
愛分析：2017 年 PingCAP 的用戶推廣進展？
劉奇：我們在2017 年運行在生產環(huán)境的用戶達到 200 個，產品客單價比較高，付費用戶要少一些。
愛分析：TiDB 是一個開源技術，在提供企業(yè)級產品時會做哪些強化？
劉奇：雖然我們提供一個開源技術，但還是有部分是閉源的，比如監(jiān)控運維組件，備份工具，安全性工具等。
對于企業(yè)應用來說，它必須具備很漂亮的用戶界面、很方面的操作工具，這是我們企業(yè)版提供的方式。
還有一部分，我們叫做Database & Service，我們提供的不僅是一個數(shù)據(jù)庫，而是一個數(shù)據(jù)庫平臺，企業(yè)用戶可以申請 TiDB 數(shù)據(jù)集群。如果沒有這個東西，可能就需要管理員手動處理，使用體驗差別是很大的。
愛分析：TiDB 是如何收費的？
劉奇：我們現(xiàn)在有兩方面考慮：一方面可以利用云部署，我們可以看到騰訊云的數(shù)據(jù)庫入口，這個商業(yè)模式比較簡單，與云上的其它產品一樣，按照租賃的方式進行收費。
另一方面，可以買我們的subscription，也可以買我們的 license，按照節(jié)點數(shù)來計算。
愛分析：公司的團隊規(guī)模？
劉奇：現(xiàn)在公司大概100 個人，研發(fā)占比比較高，有 82 個。銷售人員只有 1 個，銷售比較少是因為用戶都是自己找過來的，我們在這方面沒有太大的投入。
我們對研發(fā)的要求還是很高的，包括研發(fā)人員對外面的支持、響應的速度等。雖然看上去不會像Oracle 那么夸張，但有很多外部公司在給我們做貢獻。
比如，調度器方面的代碼很多是摩拜貢獻的，很多場景下的優(yōu)化是今日頭條貢獻的，包括韓國三星研究院等，還有很多人在幫我們做測試，這也體現(xiàn)了開源技術的一個好處。
愛分析：研發(fā)人員會承擔一部分售前的工作嗎？
劉奇：在17 年的時候還存在一些研發(fā)人員做售前工作的情況，但 18 年我們會做出一些調整，這也是我們一個很重要的任務。
人員結構的建設要形成一個完整的體系，售前、實施、研發(fā)各司其職，根據(jù)不同階段的問題安排不同的人去解決。
愛分析：銷售人員比較少的情況下，是不是對社區(qū)的運營提出更高的要求？
劉奇：我認為研發(fā)人員比較多，跟社區(qū)的交流就會比較快。社區(qū)中最主要的用戶是開發(fā)者，與開發(fā)者的交流肯定是研發(fā)人員更加順暢，銷售人員沒法替代這個角色。比如，用戶提出有部分代碼存在問題，研發(fā)的響應速度會很快。
像今日頭條、摩拜、同程這些規(guī)模比較大的用戶，都是因為存在痛點主動聯(lián)系到我們，不需要銷售去做額外的工作。
當然，社區(qū)中還存在許多規(guī)模比較小的用戶，小的用戶雖然沒有那么大的付費能力，但對社區(qū)來說也是有直接作用的。
他們會用自己的場景進行測試，發(fā)現(xiàn)很多我們從來沒有遇見過的問題，他們所提供的這些信息對我們來說也是十分重要的，因此我們會花費比較大的力氣來運營社區(qū)。
愛分析：PingCAP 的團隊背景以互聯(lián)網居多？
劉奇：對，互聯(lián)網出身的多一些，都是規(guī)模比較大的互聯(lián)網公司，都體會過數(shù)據(jù)量大了之后帶來的痛苦。
另外，還有來自傳統(tǒng)行業(yè)的，售前有來自金融行業(yè)的，他對金融行業(yè)的使用場景更加清楚一些。
愛分析：切入傳統(tǒng)行業(yè)的話，是不是對人員結構的要求有變化？
劉奇：目前我們還不是這么想的，我們希望通過產品就能夠直接拿下客戶，能夠體現(xiàn)我們產品的優(yōu)勢。如果是用誰的數(shù)據(jù)庫都一樣的客戶，我們是不會去爭取的，這也不是我們的強項。
愛分析：產品的研發(fā)和社區(qū)的維護，精力如何平衡？
劉奇：我們肯定會先做好一個基礎版，才會在社區(qū)中推廣，當遇到Bug 的時候一定要去修復，不然會影響到很多人的使用，兩者共同推進，并不沖突。
內部研發(fā)方面，我們會快速的開發(fā)很多新的功能，這些不會馬上就應用到穩(wěn)定版本，而是先在社區(qū)發(fā)布一個Beta 版本，通過用戶測試發(fā)現(xiàn) Bug，我們來進行修復，在不斷的溝通之后，我們才會發(fā)布穩(wěn)定版。
在這個過程當中，我們需要通過社區(qū)讓用戶不斷的進行測試來跟我們反饋。因為產品行不行并不是我們自己說了算的，而是用戶來判斷的。
TP 和 AP 融合是未來趨勢，數(shù)據(jù)庫市場未來會更加多樣化
愛分析：CAP 原理中的一致性和可用性存在一定的矛盾，怎么進行優(yōu)化？
劉奇：我們在未來會提供一個選項，用戶可以根據(jù)自己的需求自己選擇，高一致性或者高可用性。比如銀行的數(shù)據(jù)就要求高一致性，而互聯(lián)網應用就更側重高可用性，我們會都提供給用戶，讓用戶來選。
愛分析：NewSQL 技術與之前的技術有什么不同？
劉奇：歷史上最開始應用的是SQL，后來為什么會出現(xiàn) NoSQL，是因為 SQL 不能擴展，雖然 NoSQL 具備了擴展的能力，但表達力比較差，可能還不支持事務處理，不具備 SQL 的傳統(tǒng)優(yōu)勢。
NewSQL 就相當于同時具備了兩個優(yōu)勢，既能很好的擴展，又能具備 SQL 的事務處理能力和表達力。
愛分析：下一步TP 和 AP 是有融合的趨勢嗎？
劉奇：我們認為是這樣的，用戶是不關心是TP 還是 AP 的，解決問題就是硬道理，也不管是線上還是線下，能實時實現(xiàn)我肯定不愿意等一天。
TP 和 AP 分開這是歷史原因造成的，在數(shù)據(jù)庫剛誕生的時候并沒有去區(qū)分?，F(xiàn)在技術能做得到，肯定還是希望融合在一塊。數(shù)據(jù)分析比較復雜的情況可能還會存在單獨的 AP，但我們的產品還在快速的迭代，最后還是要看誰的性能更勝一籌。
愛分析：分布式數(shù)據(jù)庫平臺領域將來會不會產生另一個Oracle？
劉奇：因為歷史原因，短時間內Oracle 的地位是不可替代的，但新的數(shù)據(jù)庫構架興起的也很快，現(xiàn)在 Oracle 遇到了前所未有的挑戰(zhàn)，我認為在未來兩年，將會有 20% 的傳統(tǒng)數(shù)據(jù)庫被新的數(shù)據(jù)庫取代。
看現(xiàn)在我們的用戶增速，這個趨勢還是相當明顯的。
愛分析：未來市場的格局會發(fā)生哪些變化？
劉奇：我覺得市場會變得更加多樣化。
首先，現(xiàn)在的需求非常碎片化，傳統(tǒng)數(shù)據(jù)庫不能很好的表達，例如對Streaming 要求越來越高。
關系型數(shù)據(jù)庫的優(yōu)勢是通用性比較強，也比較均衡。但有些場景用現(xiàn)在的數(shù)據(jù)庫框架是很難適應的，肯定不會比專門的設計的數(shù)據(jù)庫用起來順暢，如圖數(shù)據(jù)庫等。
從發(fā)展趨勢來看，當NoSQL 出來的時候，大家會考慮它能替代什么樣的場景，后來發(fā)現(xiàn) NoSQL 還是存在很多約束的。NewSQL 的出現(xiàn)確實會改變市場格局，應該以后會有兩三家比較大體量的公司吃掉大部分市場，但小公司依然存在。
愛分析：開源技術的發(fā)展會不會影響到數(shù)據(jù)庫公司的業(yè)務？
劉奇：其實開源技術已經存在很長時間了，像MySQL 已經有二十幾年的歷史，但企業(yè)級應用畢竟不是那么簡單，還存在很多問題需要團隊去解決。
未來不會有完全免費的數(shù)據(jù)庫，就算是開源的也是要收費的。
愛分析：互聯(lián)網公司一般會自己開發(fā)基礎設施，會不會對PingCAP 造成影響？
劉奇：這個事情要分國內和國外來看，國內的公司喜歡建設私有云，國外差別就比較大，很多國外公司都把自己的私有云給拆掉了，原因也很簡單，自己部署私有云的效率并不如直接使用成熟的公有云。
現(xiàn)在很多互聯(lián)網公司不想再像過去那樣被Oracle 這樣的公司 Lock in，我既要用你的數(shù)據(jù)庫，又必須具備一定的掌控力。因為互聯(lián)網公司成長是很快的，需求的變化也更加明顯，他們希望對數(shù)據(jù)庫具有一定的理解力和掌控力，以方便互聯(lián)網企業(yè)修改數(shù)據(jù)代碼，滿足自身定制化的需求。
愛分析：云廠商最后會不會成為數(shù)據(jù)庫企業(yè)的競爭對手？
劉奇：數(shù)據(jù)庫跟云的關系，有點像APP 和 APP Store 的關系。云廠商可能也會做數(shù)據(jù)庫，但更多的應該是一種合作關系。
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
