數據存儲在實際應用中，就是怎么用數據庫把我們的業務數據保存起來。從宏觀角度看，大致包含三大類技術：B-TREE，LSM&SSTable，列式存儲。雖然主流的關系型數據庫，如Oracle、MySQL（innodb）都是采用B-TREE，但是兩者其實并沒有綁定關系，比如TokuDB，作為MySQL的存儲引擎之一也是使用LSM作為其核心思想；NewSQL中的TiDB雖然也是基于關系模型的，但是底層的存儲引擎使用RocksDB，也是基于LSM&SSTable。底層技術處于互相學習和融合之中。

　　B-TREE

　　B-TREE和關系模型同步出現于70年代，到90年幾乎占領了所有的數據庫市場。B-TREE簡單的理解就是多葉節點的樹，每個葉節點并非是每行數據，而是數據庫的的數據塊。這么設計的原因是樹的層次影響著搜索性能，而且磁盤的讀寫是基于塊（BLOCK）的，使用塊可以大大減少節點數量，進而減少樹的層次。

　　B-TREE的特點在于讀寫性能比較穩定，響應時間和磁盤隨機讀寫的時間成正比（10ms）。并且由于B-TREE對應到數據庫的每條記錄，可以很容易的實現事務、行鎖和隔離級別。讀性能略高于LSM算法。而且B-TREE基于塊的存儲方式，可以很容易的把內存中的塊和磁盤上的塊一一對應起來，很容易的實現緩存。在實際應用中，前2-3級節點內都可以在緩存中讀取，由此大大提高了訪問效率。

　　而不足在于真正面對海量數據時（如數據量進入到百億級別時），由于樹層數和緩存比率的減少，會導致性能逐步下降。此外由于B-TREE在寫入時也需要通過搜索定位到葉節點，因此相對于LSM，其寫入時開銷較大。PS：其實現在已經出現了分布式的B-TREE，比如oracle的localeindex。

　　LSM&SSTable

　　目前主流的存儲架構還是磁盤+內存，磁盤順序讀寫的性能高于隨機讀寫三個數量級，而在內存中進行隨機讀寫的的性能也大于磁盤的三個數量級，可以得出用磁盤當做磁帶一樣只做順序讀寫，而把內存當做磁盤，提供所有的隨機讀寫訪問的總體思想，這也就是出LSM-Tree的算法。

　　簡單說就是在內存中維護一張MemTable，把所有最新的數據都寫到其中，所有數據依據key值進行排序（隨機讀寫）。當MemTable的大小到大閾值之后，把它寫到磁盤上，形成一個個的SSTable（順序寫）。每個SSTable構造一個索引，由于SSTable中的數據都是排好序的，所以索引較小，可以保存在內存里面，所以所有的索引搜索動作都是在內存進行的（隨機讀）。

　　每次查找的過程如下：首先在MemTable中搜索（內存隨機查找），如果沒有依次在每個SSTable的索引中查找（內存隨機查找）。把查找從磁盤隨機動作變成了基于內存的隨機動作。隨著SSTable的增多，搜索的次數會增加，為了提高性能，后臺會把多個SSTable合并為一個（如HBase、LevelDB等等）。并且提供布隆過濾器（BloomFilter）來過濾掉不需要的SSTable。從總體效果上看，寫入的效率大大高于基于B-Tree的存儲引擎，而讀取性能接近于B-Tree。

　　LSM&SSTable在寫入密集型應用中有較大優勢，同時在讀取方面也有不錯的表現。不足之處在于上面提到的，不定期對增加的SSTable進行合并時，對于數據庫會產生一定壓力。

　　由于這些特點，LSM&SSTable大量應用于許多組件中，比如HBase、LevelDB等KeyValue數據庫中，同時也在消息引擎Kafka和搜索引擎Solr使用。

　　列式存儲

　　以上兩種存儲引擎主要適合于聯機場景，如有大量的基于客戶各類行為數據的批量計算的推薦系統中，以及預計客戶的流動性缺口等等。在這些場景中，列式存儲在性能上有非常明顯的優勢。隨著各類大數據應用的擴展，列式存儲從和Hive共生的ORC，到和Spark共生的Parquet也被應用到了各個數據分析應用中。

　　從傳統的數據分析類應用，到人工智能應用，都需要遍歷整個數據集，上面也提到磁盤在順序讀寫和隨機讀寫性能方面的巨大差距，所以所有的數據倉庫都會在全表遍歷中采用磁盤順序遍歷。所以遍歷的文件空間越小，性能越高。列式存儲按列對數據進行保存，以減少數據庫每次訪問的文件尺寸。

　　首先，分析應用一般局限于對于表中的部分字段都分析，列是存儲可以讓引擎只訪問部分字段，減少吞吐量。其次，列式存儲數據壓縮能力更強。因為行級別的存儲方式壓縮是基于數據塊，壓縮比大致為50%-70%左右，而且壓縮比越大，解壓縮對于CPU的占用也越大。由于單列內的數據非常類似，尤其是各種碼值類的數據，比如性別（男、女、其他），行數越多，壓縮比越大。10億客戶的性別，也可以簡單的表達為如下這樣：“連續100個男性、連續50個女性、又連續80個男性、連續70個女性”，按照每行的位置依次表達下去。

　　再次，同樣由于列內數據的取值范圍有限，也可通過位圖來表達，比如10表示男，01表示女，因此只用2個bit就可以表示出來，從而進一步增加壓縮比。在在許多場景中能夠把以前數G的數據壓縮為幾百K。由此可以顯著降低批量計算時對于存儲的吞吐壓力和提升計算效率。

　　當然列式存儲也并非完美，在更新時列式存儲相對行式存儲，很難直接做到就地修改的效果，往往需要把整列鎖住，重新計算，重新生成整個列。所以列式存儲更多的適合于數據分析時需要全表遍歷的場景。

　　數據存儲總結

　　綜合考慮上面三種存儲方式的優勢和不足。推薦系統根據應用訪問數據的特點把數據分布到了不同的存儲機制中。

　　對于需要提供事務、鎖，數據量不特別大的場景中，采用基于B-TREE的存儲機制，例如合約簽訂，合約執行等業務需要數據庫提供多行的事物處理，而且數據量和交易量不是特別大，把數據保持在傳統關系型數據庫中，也正好利用了B-TREE的優點。

　　對于訪問數據量，以及每日新增、修改量特別大的場景，采用LSM&SSTable作為存儲引擎，例如客戶的標簽數據，數據量達到百億級，每日增量也可達上億記錄，數據保存在HBase數據庫中，可以較為輕松，在數十分鐘之內就可完成批量更新，而查詢響應時間也沒有隨著數據量的增加而變慢，仍然保證在幾毫秒以內。

　　最后是列式存儲，它適合于數據分析類場景，如進行客戶流動性預測、客戶投資方案生成這類分析場景中，需要對于數據進行反復遍歷的操作，最終采用的方案是把數據從原來的產品數據庫中導出后存到Hadoop集群的HDFS中采用Parquet格式存儲數據，后繼采用Spark來訪問時，遍歷數據的時間可以控制在數分鐘級別。
責任編輯人：CC