參考資料：
(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更加全面，更加兼容傳統數據。
好多人想問，為什么市面上流行的數據庫居然如此差。設計成這個樣子？難道大家都錯了嗎？事實上這個問題非常easy，傳統數據庫開發得非常早，最早可追述到上世紀七八十年代。距今至少也有30個年頭了。這樣的數據庫系統實際架構和模式，是由當時總體計算機硬件水平和理論水平而決定的。
近些年硬件發展速度相當迅猛，不管是從Disk/RAM的大小到價格，還是CPU的性能和多核（Multi-core）技術等，比起30年前，都有飛躍式的發展。雖然摩爾定律這兩年半導體技術發展的增長速度已經放緩，可是還在不斷進步。再者就是由於。30年前數據庫的應用非常單一非常easy，經過這么多年的發展，我們的實際的數據處理需求也在不斷多樣化。傳統數據庫也隨之不斷地添加不同的功能，使之越來越龐大。
新型OLTP數據庫的架構
為了去除傳統數據庫的性能瓶頸。MIT大學的研究者，依據當前的硬件水平，全然又一次設計了數據庫，而不在之前的傳統數據庫上進行微笑更改。
當代新型數據庫也來越注重分布式scale out。而傳統數據庫則還在提高單台機器的處理能力scale up。對於普通用戶來講，不可能像大型企業一樣資金雄厚。購買價格昂貴的大型機和數據庫軟件。
假設要對數據進行備份，做到High Avaliability的話，就須要至少再購買並執行一個副本。
新型OLTP數據庫解決方式：
| 數據庫系統的更改目的 | 新型OLTP數據庫技術 |
| 去除logging開銷 | 使用新型logging |
| 去除locking，latching等開銷 | 數據分區 + 單線程運行 |
| 去除buffer manager開銷 | 使用內存，代替磁盤讀寫 |
依據相關學者研究的結果看。去除這些重大開銷后。OLTP關系型數據庫Transaction的吞吐量提高了至少20倍。