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

有哪些東西值得思考呢？

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

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

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

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

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

對今后的發展而言，要和大量的NoSQL競爭對手區別開，跨數據中心的數據一致性是個很棒的賣點，隨著FinTech的蓬勃發展，連花旗、大摩、德銀、Visa的舵手都加盟互聯網金融，CockRoachDB也把這個作為路線圖里的重點項目。

隨著Lucene的發展，和Java Future把大家從以Service為節點的DAG拓撲帶到以Future為節點的同、異步統一的網絡編程等等，助力了Twitter從2010年開始開發的的real-time indexing，2010年開始給大家帶來很多想象空間，原來可以自己根據內外不同的數據來源（不僅是用戶帖子，而且用戶資料，排名，第三方數據、地址等等）加好多東西到索引里。

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

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

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