CockroachDB繼2015年5月融到第一筆$6.25M的A輪之后，今年3月底又融到$20M。對事務(wù)型數(shù)據(jù)庫的開發(fā)者們，這是個(gè)好消息。

有哪些東西值得思考呢？

首先CockroachDB也是個(gè)很棒的團(tuán)隊(duì)，位于紐約，去年A輪時(shí)只有6個(gè)人，到現(xiàn)在也就20來號人。小而精；和在大數(shù)據(jù)里站山頭創(chuàng)業(yè)里大多數(shù)妖魔鬼怪一樣，創(chuàng)始人有三個(gè)工程師，包括CEO Kimball，都來自大數(shù)據(jù)老巢-Google；第一位投資者：Benchmark的Peter Fenton。Benchmark投資過大名鼎鼎的Hortonworks和New Relic。 自然而然地，A1輪Google Venture，Hortonworks CEO Rob Bearden 和Cloudera創(chuàng)始人Jeff Hammerbacher也進(jìn)來了。所以，找對投資人很重要，根正苗紅的大數(shù)據(jù)投資者，帶來的不僅是$$。

這種數(shù)據(jù)庫一開始就是為互聯(lián)網(wǎng)定制的--線性擴(kuò)展、確保事務(wù)完整性，全局的數(shù)據(jù)一致、和極端情況下的生存能力，即使內(nèi)存、磁盤、節(jié)點(diǎn)、集群甚至是數(shù)據(jù)中心崩潰。而最對口的客戶之一，無疑是服務(wù)于世界500強(qiáng)的SAAS公司—5分鐘的事務(wù)型服務(wù)中斷，可能影響到重要的ERP、CRM等核心業(yè)務(wù)系統(tǒng)，而對于SAAS服務(wù)提供商而言，那就是自砸招牌。因此，強(qiáng)哥很聰明地選了SAAS作為重點(diǎn)用戶場景之一，而不僅靠互聯(lián)網(wǎng)公司。

開始的時(shí)候，他們幾個(gè)純粹是按開發(fā)者的路子，本來打算2015年夏天推出的Beta版，目標(biāo)是Transactional Key-Value Store.，所以最后還是決定把SQL加上去，這大概增加了2個(gè)季度的開發(fā)時(shí)間。不過，這樣的定位更清晰，不會(huì)半生不熟地做了個(gè)NoSQL, 讓用戶自己琢磨到底是自己做索引，還是等等看。等等，索引自己做？ 別忘了他們是從Google來的，Spanner和Web Index可是CockroachDB的童子功啊。加上SQL對于用戶來講更加方便。

他們放棄的東西，也值得大家思考：他們放棄了Join，放棄了并行執(zhí)行分布式查詢。有意思吧？ 實(shí)際上是放棄掉“關(guān)系型”。在濃濃的Redis里，加了SQL這個(gè)大料，就成了Fusion food了。6個(gè)人，兩個(gè)月完成，真不錯(cuò)。

互聯(lián)網(wǎng)公司對一致性的要求并不高，數(shù)據(jù)模型這種東西基本上不放在眼里，也確實(shí)用不上。Redis當(dāng)年連Int的類型都沒有，只有string，哪管你營收、銷售、現(xiàn)金流報(bào)表是否對得上？ 這也讓他們獲得了很多東西，比如響應(yīng)時(shí)間和并發(fā)。Twitter當(dāng)年開始的那種場景，就算用自己用Hash Table建索引，也沒啥不可能的，一張表滿了，就寫下一張。MySQL拿來當(dāng)Raid 0用，復(fù)制到20臺(tái)節(jié)點(diǎn)上就行，Partition信息交給根節(jié)點(diǎn)，用Ruby On Rails寫個(gè)搜索，搜個(gè)三天的內(nèi)容也挺好。

對今后的發(fā)展而言，要和大量的NoSQL競爭對手區(qū)別開，跨數(shù)據(jù)中心的數(shù)據(jù)一致性是個(gè)很棒的賣點(diǎn)，隨著FinTech的蓬勃發(fā)展，連花旗、大摩、德銀、Visa的舵手都加盟互聯(lián)網(wǎng)金融，CockRoachDB也把這個(gè)作為路線圖里的重點(diǎn)項(xiàng)目。

隨著Lucene的發(fā)展，和Java Future把大家從以Service為節(jié)點(diǎn)的DAG拓?fù)鋷У揭訤uture為節(jié)點(diǎn)的同、異步統(tǒng)一的網(wǎng)絡(luò)編程等等，助力了Twitter從2010年開始開發(fā)的的real-time indexing，2010年開始給大家?guī)砗芏嘞胂罂臻g，原來可以自己根據(jù)內(nèi)外不同的數(shù)據(jù)來源（不僅是用戶帖子，而且用戶資料，排名，第三方數(shù)據(jù)、地址等等）加好多東西到索引里。

也為了方便互聯(lián)網(wǎng)公司業(yè)務(wù)的發(fā)展—哪家的表結(jié)構(gòu)能保證不變?。?通過多版本和分階段授權(quán)等方式，Cockroach在Beta版本里加了一個(gè)Online Schema Change System，在服務(wù)不中斷和不鎖表的情況下，增加列，修改Index。你想想，像Stack overflow那樣的公司，一個(gè)五六千萬行的表，做Alter table操作，起碼要五六個(gè)小時(shí)吧？如果用Amazon RDS服務(wù)，能否在Slave上做好再Promote到主服務(wù)器上，還另說。

這功能也挺有意思：改變表結(jié)構(gòu)schema不是一蹴而就的事，畢竟有那么多節(jié)點(diǎn)，都有各自的cache和TTL。要保證所有節(jié)點(diǎn)最終都用到正確的schema版本，需要一定“收斂時(shí)間”。像PrestaDB、Trafodion這一類成熟的數(shù)據(jù)庫引擎一樣，它也用了廣播和租約相結(jié)合的方式。 在DML之后，節(jié)點(diǎn)會(huì)收到一個(gè)“讀”的租約，在分鐘級別的租約內(nèi)可以用這個(gè)schema，而一旦出現(xiàn)Alter Table，將廣播給集群里所有節(jié)點(diǎn)，讓他們放棄當(dāng)前租約，準(zhǔn)備用新的，這樣來達(dá)到更快的收斂時(shí)間。

他們下一步開發(fā)還是會(huì)去支持JOIN和并行Query執(zhí)行。這是個(gè)很大挑戰(zhàn)。像Apache Trafodion這種引擎當(dāng)年能在Nonstop大型數(shù)據(jù)庫上用，支持銀行電信高并發(fā)的OLTP，其核心競爭力之一就在于并行處理，大致的做法包括多個(gè)機(jī)制上的并行，比如并行處理Partition或更小粒度的Division、執(zhí)行器里一個(gè)個(gè)SQL operator連起來的管道并行和SQL Operator本身的同步/異步計(jì)算并行。 但是，這里面的難度很大，比如，為了確定到底用幾個(gè)worker線程參與并行，需要考慮Key的數(shù)據(jù)分散情況，相關(guān)Query可能涉及到的行數(shù)范圍，在架構(gòu)各層插入統(tǒng)計(jì)信息的柄，如何下推，周到的Update Statistics之類以便優(yōu)化，進(jìn)行檢測執(zhí)行樹每層的數(shù)據(jù)傾斜情況等等。