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ù)傾斜情況等等。