轉自：http://www.infoq.com/cn/news/2017/04/redefine-database-history
提起VividCortex公司的創建者兼CEO Baron Schwartz，大家可能會比較陌生，但讀過他的著作《高性能MySQL》的一定大有人在。他同時也做過許多開源軟件的性能分析、監控和管理工作。同時他還對許多不同的數據庫社區有所貢獻，包括Oracle、PostgreSQL、Redis和MongoDB等。最近他在博客上分享了一些關於數據庫的想法。從2000年左右LAMP組合引起的互聯網大潮開始，到后來競爭者的出現，從其現象展示出來的一些關鍵因素，他談到了我們可以從中得到的收獲，以及對未來的展望。
為什么LAMP組合可以獲得這么大的成功呢？其實它的每個組成部分都有很多東西可以講，而且反應了技術架構上的變化，或者說是架構變化的產物。但我覺得其中的MySQL則是今天數據庫趨勢的領頭羊。
MySQL的成功與互聯網的繁榮相輔相成，它成功的因素有很多，很難下定論，但很明確的一點就是它“足夠好”。MySQL的巨大成功也造就了后來的NoSQL大潮，但隨着NoSQL的定義由“不要SQL”慢慢冷卻退化成“不只是SQL”，並且慢慢地都支持了類SQL的語言，在這一切發生之后，Baron Schwartz相信關系型數據庫仍將持續發展並長久不衰，但它的統治地位已經被動搖，新興的技術中必然有些會發展得可以與之平起平坐。他認為現在已經可以看出數據庫技術發生了一些歷史性的轉變。
下一代通用型數據庫
關系型數據庫和SQL使用起來都是比較痛苦的。SQL並不能非常直觀地反映出寫SQL的人的真實意圖。而且在一條SQL執行的時候，如果不是一個數據庫專家，你並不了解數據庫在背后到底做了多少事情，由此會產生多少副作用。而且將SQL寫到程序代碼里時也是非常痛苦的，因為現代編輯器可以在寫代碼的同時就幫你解決許多編程語言的問題，但對於程序代碼中的SQL語言塊它們卻無能為力。在編輯器看來它們就是一個個無意義的字符串，沒辦法進行編譯、語法檢查、甚至類型檢查等等。一直到程序運行起來，你才能得到一些晦澀的執行返回。
因此SQL是有許多方面可以改進的，比如讓程序代碼和數據庫使用相同的語言和工具集；設計一種數據庫查詢語言，讓它與編程語言的工作方法類似；將數據庫與程序的內存空間映射起來……等等。當然由此會引入許多新問題，畢竟當初SQL被發明出來時就是解決了一批舊問題，又引入了許多新問題。歷史總是驚人的相似。
事實上正是這些原因引發了2009年左右出現的一代新型數據庫，比如map-reduce數據庫、鍵值型數據庫、Javascript數據庫等。它們都有着各自美好的初衷，在某些領域做得非常出色，也在某些方面飽受詬病。作為新興數據庫技術的密切觀察者，Baron Schwartz曾經非常看好MongoDB、Redis和Riak。現在事實也證明MongoDB和Redis使用的廣泛性。雖然Schwartz不敢斷言這兩種數據庫勝出的絕對原因，但肯定有部分原因是在於使用它們時是非常愉悅的：
Redis的設計理念很簡單：為一條數據打上標簽，然后就可以用這個標簽去獲取並操作數據了。數據結構非常豐富，而且數據結構的設計也和程序員們的習慣非常吻合，處理數據的操作正是構建應用程序的基礎操作。而且，Redis非常專注於把這些事情做好，並且不會分心去解決別的問題。
MongoDB的概念也類似，基本就是數據庫應該可以存儲嵌套的、結構化的文檔，並且可以直接映射為編程語言中使用的數據結構或對象。並且在此之上MongoDB還有另外一個強大的工具：可以直接使用應用得非常廣泛的JavaScript來查詢數據庫。還有，它內置分布式的特性，因此你的業務程序就不必再考慮分片細節了。
同時代出現的其它NoSQL型數據庫由於沒有用類似思路去解決相似問題，所以在大潮過后，它們也就慢慢退出歷史舞台了。比如Cassandra解決了分布式問題，但給程序員們的表現手段實在有限，最終成了一個非常高可用卻不怎么強大的數據庫，因此沒有什么吸引力。
Baron Schwartz認為：
人們將來創造出來的更加現代的數據庫必將是非常實用而且好用的。
時間序列數據庫
時間序列數據庫會把事件帶上時間戳保存起來，並將時間戳作為數據模型的一個非常天然而基本的組成部分。它們支持做基於時間的分析，以支持基於時間的查詢為第一要務。許多時間序列數據庫甚至強制要求任何查詢都必須將時間作為一個維度。
Baron Schwartz曾細致地討論過時間序列數據庫，曾經論證世界就是時間序列，而且分享過他認為的時間序列數據庫應該滿足的需求（盡管針對需求這一部分，他的有些觀點已經發生了改變）。在現有的這個類型的數據庫產品中，Schwartz認為InfluxDB最有前途，Elasticsearch也不錯。
InfluxDB最近的受關注度在急劇上升，因為它在試圖定義“一個原生的基於時間的數據庫到底是怎樣的”，並試圖回答作為一個數據庫滿足這樣的特性是否已經足夠，以及在有了這樣的特性之后，用戶還可能希望再添加些什么功能。定義一款數據庫的功能邊界很難，但現在看起來InfluxDB做得相當不錯。
ElasticSearch在某些方面提供了時間序列的功能，但它的核心並不在此。它實際上是一個有時間概念的分布式查詢引擎。這樣做很自然，人們也會相應的有疑問：如果你准備使用一個有時間的非時間序列數據庫，那為什么你不干脆使用一個有時間序列功能的關系型數據庫？
Baron Schwartz認為不管怎樣，有一件事情非常確定：
時間序列非常重要，一定會有非常棒的專用的時間序列數據庫來滿足這個需求。絕對不能只是滿足於某種其它類型的數據庫聲稱：“哦，我們也支持那個功能！”
xxx