提起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認為不管怎樣,有一件事情非常確定:
時間序列非常重要,一定會有非常棒的專用的時間序列數據庫來滿足這個需求。絕對不能只是滿足于某種其它類型的數據庫聲稱:“哦,我們也支持那個功能!”
流式數據庫
流式數據庫,也有人稱之為發布-訂閱型、消息隊列、消息中間件等,這些概念都是類似的。這些數據庫的核心內容基本就是日志和總線。它們不會永久地存儲數據,只是幫你暫時有序地保存數據,以后再讀出。這種類型的數據庫可以有效地幫你將復雜的企業內部技術架構簡化。只要在思想觀念上做轉變,就會喜歡使用它,而且用上了就會愛不釋手。Baron Schwartz預測到:
在這個領域里也出現了許多產品,比如Spark。但依我看來,Apache Kafka是毫無爭議的游戲規則改變者。它實在是一項標志性的轉折點技術。在這里我不會試著解釋為什么,我只是指點你們去了解一下Kafka背后的公司——Confluent。去讀讀與她相關的材料吧。我知道有很多非常棒的人都在那里工作,他們都非常有天份,聰明,這些不是膚淺的市場宣傳。你可以從他們的成果中受益非淺。
結論
Baron Schwartz并不認為NoSQL僅僅是曇花一現,盡管的確有很多不怎么樣的技術已經銷聲匿跡了。痛苦和解決方案都是真實存在過的,能否存活下來的決定因素在于一項技術是不是真的適合市場。在將來,傳統關系型數據庫所未能滿足的三個方面將會有蓬勃發展:向后兼容的新型關系型和SQL、時間序列型和流式數據庫。讓大家一起拭目以待吧!