一、OceanBase相比其他開源的noSQL數(shù)據(jù)庫的優(yōu)點

1. OB的redolog是使用分布式一致性算法paxos實現(xiàn)的。所以在CAP理論中，雖然OB使用的是強一致模型，但是OB能在一定網(wǎng)絡(luò)分區(qū)的情況下做到高可用（通俗點講就是多余半數(shù)機器還活著的時候就能干活）。官方的MySQL目前做不到這一點

2. OB的存儲結(jié)構(gòu)使用的是兩級的LSM-tree。其中內(nèi)存中的C0 Btree葉節(jié)點不需要和磁盤上的btree一樣大小，所以能做得比較小，對cpu的cache比較友好，并且不會有寫入放大的問題。使得OB的寫性能有極大的提升。同時磁盤上的C1 tree不是一個傳統(tǒng)意義上的btree（btree未經(jīng)壓縮可能浪費一半空間）?？臻g利用率大大提高。簡單來說就是速度快，省成本。這里說的比較粗略，想詳細(xì)理解自己去看LSM-tree的論文。

3. 數(shù)據(jù)庫自動分片功能（支持hash/range，一級二級等等分片方式），提供獨立的proxy路由寫入查詢等操作到對應(yīng)的分片。這意味著數(shù)據(jù)量再大也不需要手動分庫分表了。并且分片能在線的在各個server之間遷移，解決熱點問題（資源分配不均的問題，做到彈性加機器和減機器）。每個分片（確切的說是被選為主的分片）都支持讀寫，做到多點寫入（高吞吐量，性能可線性擴展）。

4. 數(shù)據(jù)庫內(nèi)部實現(xiàn)的無阻塞的兩階段提交（跨機事務(wù)）。參見論文Consensus on Transaction Commit

5. 數(shù)據(jù)庫原生的多租戶支持。能直接隔離租戶之間的cpu，mem，io等資源。

6. 基于代價的SQL查詢優(yōu)化和改寫功能，對于復(fù)雜的分析型SQL做得比MySQL好（目前比Oracle差，正在努力追趕中）。支持各種類型的join算法（nestloop, merge, hash），優(yōu)化器會自動選擇優(yōu)異的join類型。支持類似Oracle的SPM功能，用戶能很輕松自如的管理查詢計劃。

7. 自動化的集群管理，包括機器上下線，自動下故障盤等等?？傊甇B的設(shè)計理念就是只要是數(shù)據(jù)庫需要解決的問題就不讓用戶操心。

延伸閱讀：

二、數(shù)據(jù)庫的查詢功能實現(xiàn)原理

數(shù)據(jù)庫查詢是數(shù)據(jù)庫的最主要功能之一。我們都希望查詢數(shù)據(jù)的速度能盡可能的快，因此數(shù)據(jù)庫系統(tǒng)的設(shè)計者會從查詢算法的角度進行優(yōu)化。最基本的查詢算法當(dāng)然是順序查找（linear search），這種復(fù)雜度為O(n)的算法在數(shù)據(jù)量很大時顯然是糟糕的，好在計算機科學(xué)的發(fā)展提供了很多更優(yōu)異的查找算法，例如二分查找（binary search）、二叉樹查找（binary tree search）等。如果稍微分析一下會發(fā)現(xiàn)，每種查找算法都只能應(yīng)用于特定的數(shù)據(jù)結(jié)構(gòu)之上，例如二分查找要求被檢索數(shù)據(jù)有序，而二叉樹查找只能應(yīng)用于二叉查找樹上，但是數(shù)據(jù)本身的組織結(jié)構(gòu)不可能完全滿足各種數(shù)據(jù)結(jié)構(gòu)（例如，理論上不可能同時將兩列都按順序進行組織），所以，在數(shù)據(jù)之外，數(shù)據(jù)庫系統(tǒng)還維護著滿足特定查找算法的數(shù)據(jù)結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)以某種方式引用（指向）數(shù)據(jù)，這樣就可以在這些數(shù)據(jù)結(jié)構(gòu)上實現(xiàn)高級查找算法。這種數(shù)據(jù)結(jié)構(gòu)，就是索引。