從新定義數據庫歷史的時刻——時間序列數據庫Schwartz認爲InfluxDB最有前途，Elasticsearch也不錯

轉自：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