調研 | 李喆 王琦
撰寫 | 李喆
即使將範圍從大資料縮小到資料庫這個細分領域， 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研發的一個參考。
產品同時支援TP和AP， 強一致性和擴展性是主要特點
最初， TiDB只是解決TP問題， 但在實際應用過程中， 直接讓客戶用新資料庫替代原先的MySQL資料庫難度很大， 尤其當資料庫廠商是一家名不見經傳的初創公司。
多數企業客戶的做法是前端仍然保留傳統MySQL資料庫， 將TiDB資料庫作為背後的資料集市， 與前端資料庫相連， 但這個資料集市的即時性要遠好於Hadoop架構的資料集市， 可以運行在實際生產系統。
當按照這種方式運行一段時間，
當客戶將TiDB資料庫作為資料集市來使用時， 因為前端資料庫要從這個資料集市中查詢資料， 因此， 對TiDB資料庫的查詢功能提出更高要求。 TiDB調整了自己的資料庫執行器， 進行AP功能的拓展。
這樣一來， TiDB同時支援TP和AP功能， 成為分散式HTAP（Hybrid Transaction 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的關係。雲廠商可能也會做資料庫，但更多的應該是一種合作關係。
現階段，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的關係。雲廠商可能也會做資料庫，但更多的應該是一種合作關係。