從CockroachDB 看事務(wù)型數據庫開(kāi)發(fā)

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

　　有哪些東西值得思考呢?

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

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

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

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

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

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

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

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

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

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

原文轉自：http://www.infoq.com/cn/news/2016/04/CockroachDB-worth-learning