傳統資料庫沒落，OLTP新型資料庫發展火熱，資料庫沒落oltp

傳統資料庫沒落，OLTP新型資料庫發展火熱，資料庫沒落oltp

參考資料：

(1) 《OLTP Through the Looking Glass, and What We Found There》

(2) 《The End of an Architectural Era》，VLDB 2007

越來越多的程式員開始做移動App的開發，真正做底層系統開發的程式員還是少數。看到國內資料庫系統發展的資料不是很多，我也把自己對當前資料庫系統發展的認識寫成博文， 和大家分享，希望可以互相學習。

資料庫系統的近期發展和分類

隨著作業系統發展趨於穩定（不包括移動端OS），越來越的的研究集中在資料庫系統的發展上，沒有多少人說要重新做一個作業系統，更多的人是在現有的OS上做各式各樣的應用。但是過去的10年，是資料庫井噴式發展的階段，各式各樣的產品迸發出來，例如檔案儲存體資料庫（如MongoDB），列儲存資料庫（如Vertica）， 各種NewSQL資料庫（如VoltDB）。之所有有如此的發展，歸結於資料量不斷快速膨脹，傳統資料庫在大資料上的處理效能不能滿足需求等。人們趨於去開發針對不同應用類型的資料庫，來滿足對特定資料處理的需求，在作業系統上開發資料庫系統應用很像是在開發移動App一樣，出現了蓬勃似得發展。由於當下Big Data依舊是非常火熱的話題，在未來的一段時間內，提供底層資料管理服務的資料庫，仍舊會是電腦發展比較快的領域之一。

許多人會把資料庫系統和其他某些概念混淆在一起，其實資料庫作為一個大的系統，就對目前市場上產品來講，可以分好多類：

1. 關係型資料庫管理系統（Relational DBMS），例如：Oracle，SQL Server, MySQL， PostgreSQL

2. 鍵-值 儲存，例如：Redis，Memcached, DynamoDB

3. 檔案儲存體，例如：MongoDB，CouchDB，Couchbase

4. 大資料存放區系統, 例如：Cassandra，HBase，Google's Bigtable

5. 基於Hadoop的資料分析系統，例如：Hive，Spark，Impala（第四類和第五類，多多少少有些交叉。）

6. 文字查詢系統, 例如：Solr, Elasticsearch.

除了上面的常見類型，還有其他很多小分支，形資料庫，對象資料庫等，這裡不作為討論的重點。 本文主要探討第一類傳統關係型資料庫系統（RDBMS）。

不同類型的資料庫，適用於不同的需求，他們之間有相似也有不同。作為第一類傳統關係型資料系統，與其他類型資料庫最明顯的區別有幾點：A）支援所有SQL語句，B）支援事務（Transaction）的ACID屬性。 第二類和第三類就不具備的特點A和B，第四類和第五類大多不支援A和B。即使其他類別支援A或B，也是和RDBMS所支援的A，B有很大不同。對於A而言，其他類別資料庫也只是支援某些SQL的子集，而不是整個SQL標準，或者說是較老的SQL標準，比如SQL92+。對於B而言，不是在Row層級支援所有事務的ACID屬性，那些eventually consistency什麼的，都是商業宣傳詞彙，其實就是no consistency。

這裡並不是說其他類別的資料庫不好，只是我們進入了一個資料庫多元化的時期，不同的資料庫都有自己的特點和擅長的地方，不可一概而論。比如對於Consistency來言，銀行的業務就需要strong consistency，確保資金出入正確，而微博這種應用可以捨棄一些consistency來換取系統高輸送量，使用者不是非常關心能否即使（比如時間延誤小於2秒）看到朋友的微博狀態。

傳統關係型資料庫系統系統根據應用還可以大致分為兩類：OLTP（Online Transaction Processing）和OLAP（Online analytical processing），其中OLTP處理並發，多線程管理等事務，OLAP用於大量資料分析，是BI（Business Intelligence）的一部分。第一類的關係型資料庫系統大都包含了OLTP和OLAP的功能，屬於通用型的資料庫。下文也著重討論OLTP類型的資料庫。

傳統關係型資料庫效能分析及瓶頸

近些年有關傳統資料庫效能的分析，已經有很多很多。我個人比較看好惠普HP和麻省理工大學MIT聯合研究出的一片文獻《OLTP Through the Looking Glass, and What We Found There》。簡單的講，他們的對當代資料庫進行瞭解刨式地分析，得出結論：傳統關係通用型資料庫，只有10%左右的時間是處理有效資料，剩下90%的時間都浪費在其他輔助工作上：Buffer manager，Latching，Locking，logging，Btree keys等。

這是他們跑TPC-C benchmark得出不同資料庫部分的效能表徵圖，左側為指令的百分比，右側為CPU cycle（即CPU執行時間）的百分比。白色部分為真正有用的資料處理，剩下的都是傳統資料庫不可或缺的部分，但是消耗了大量的資源。由所示，緩衝管理和鎖，門閂和日誌都是傳統關係型資料庫實際較大的開銷。

傳統資料庫的效能缺陷一直沒有提到大家的議程上，主要還是因為在過去資料量太小的緣故。隨著近10年網際網路的發展，尤其是近5年移動端應用爆炸式的湧現，資料量也在井噴式的增長。在當代，誰能處理好大資料，誰能挖掘Big data的商業價值，誰就能賺到錢。不少科技公司的競爭，就是資料處理能力的競爭。這也是為什麼近10年湧現出很多NoSQL的資料庫和NewSQL的資料庫。NoSQL發展的早些，現有很多知名的系統，例如Google的Big Table，Amazon的DynamoDB，Apache的HBase，Cassandra等。NewSQL系統出現的晚於NoSQL大概5,6年吧，現在流行的有VoltDB，NuoDB，Clustrix等。他們的共同點都是解決大資料的處理效能問題，不同點是NewSQL系統，旨在解決NoSQL不支援標準SQL語言和事務Transaction不全支援ACID屬性的特點。換句話說，NewSQL的功能要比NoSQL更加全面，更加相容傳統資料。

好多人想問，為什麼市面上流行的資料庫竟然如此差，設計成這個樣子？難道大家都錯了嗎？其實這個問題很簡單，傳統資料庫開發得很早，最早可追述到上世紀七八十年代，距今至少也有30個年頭了。這種資料庫系統實際架構和模式，是由當時整體電腦硬體水平和理論水平而決定的。近些年硬體發展速度相當迅猛，無論是從Disk/RAM的大小到價格，還是CPU的效能和多核（Multi-core）技術等，比起30年前，都有飛躍式的發展。儘管摩爾定律這兩年半導體技術發展的增長速度已經放緩，但是還在不斷進步。再者就是因為，30年前資料庫的應用很單一很簡單，經過這麼多年的發展，我們的實際的資料處理需求也在不斷多樣化，傳統資料庫也隨之不斷地增加不同的功能，使之越來越龐大。

 

新型OLTP資料庫的架構

為了去除傳統資料庫的效能瓶頸，MIT大學的研究者，根據當前的硬體水平，完全重新設計了資料庫，而不在之前的傳統資料庫上進行微笑更改。

當代新型資料庫也來越注重分布式scale out，而傳統資料庫則還在提高單台機器的處理能力scale up。對於普通使用者來講，不可能像大型企業一樣資金雄厚，購買價格昂貴的大型主機和資料庫軟體。如果要對資料進行備份，做到High Avaliability的話，就需要至少再購買並運行一個副本。

新型OLTP資料庫解決方案：

資料庫系統的更改目的	新型OLTP資料庫技術
去除logging開銷	使用新型logging
去除locking，latching等開銷	資料分區 + 單線程執行
去除buffer manager開銷	使用記憶體，取代磁碟讀寫

根據相關學者研究的結果看，去除這些重大開銷後，OLTP關係型資料庫Transaction的輸送量提高了至少20倍。

資料庫中的OLTP是什?

On-Line Transaction Processing聯機交易處理系統(OLTP)
也稱為面向交易的處理系統，其基本特徵是顧客的未經處理資料可以立即傳送到計算中心進行處理，並在很短的時間內給出處理結果。這樣做的最大優點是可以即時地處理輸入的資料，及時地回答。也稱為即時系統(Real time System)。衡量聯機交易處理系統的一個重要效能指標是系統效能，具體體現為即時回應時間(Response Time)，即使用者在終端上送入資料之後，到電腦對這個請求給出回覆所需要的時間。
 
問OLTP對關聯式資料庫的具體是什用法，不要貼概念，

OLTP基本上最後的結果是資料表設計的方式是以交易為最終目的,所以一般都是高正規化