為什么說關系型數據庫不會滅亡
過去十年是非常令人興奮的十年，因為它與數據有關。在這十年中，一些技術的出現見證了數據的爆炸式增長：
- 社交媒體(或者說Web 2.0)產生了持續增長的數據;
- 物聯網(傳感器設備)產生了日益增長的數據;
- 新模型不斷涌現出來，數據庫市場從沒如此熱鬧過。
廠商市場人員，分析師機構和媒體以及技術傳播者們創造了“大數據”和“NoSQL”這些詞匯，把過去十年里圍繞持久化技術出現的模糊觀點匯集在一起。然而多大才算“大數據”呢?你做的是“大數據”嗎?你需要“大數據”嗎?這些根本性問題卻很少有人提起。
事實上，你真的不需要。你可以繼續使用傳統的架構和關系型數據庫。我堅信關系型數據庫不會滅亡。為什么?且看我總結出的三大理由：
1、RAM的價格持續走低
一時之間，經濟學家和分析師都認為摩爾定律將要終結。單CPU的處理能力達到了非量子物理所能達到的極限，我們不能再以那么低的成擴展處理器能力。因此多核處理器出現了，廠商都開始鼓吹采用分布式架構來進行數據處理和共享。
但是我們真的需要把數據分發到多臺服務器上，并在分布式環境中與CAP理論做斗爭嗎?事實上，你大可不必付此代價。(注：CAP原則是NOSQL數據庫的基石。Consistency一致性、Availability可用性、Partition tolerance分區容錯性。)
雖然CPU不會變的更快，但是RAM卻一直在變的更便宜。現在，一臺數據庫服務器可以把整個數據庫都放到內存中，這個費用我們是絕對負擔得起的。
幾家主流的關系數據庫廠商已經基于其各自的標準產品實現了內存計算功能和列存儲功能。包括Oracle數據庫12c、SQL Server 2014、SAP HANA等。全球最大的問答網站Stack Exchange就是一個很好的例子，到目前為止，他們還在使用集中式的RDBMS來跑核心應用。他們的服務器配置了400GB RAM，每天要處理3.43億次查詢操作，運轉起來沒有遇到任何問題。
這種經典架構很好地印證了遵循摩爾定律：“只要扔更多的硬件進去，它就能更快地運行。”所以你還沒有必要把系統改造成分布式架構。換句話說，磁盤已經不在是應用程序的性能瓶頸。有了RAM，你可以很容易地在單一服務器上進行擴展。
2、SQL是最好的查詢語言
你可以說SQL時最差的數據庫查詢語言，但你也找不到第二種語言來代替它。
從技術的角度來看，QUEL可能曾經是更好的語言，但是80年代初期由于Oracle和IBM耍了花招，SQL以及ANSI/ISO SQL標準最終勝出了。SQL最基本的廣受批評的問題之一是它并不是真正的關系型語言。這一點早在1983年C.J.Date就在其論文《對SQL數據庫語言的批判》中就明確指出了，但是那時已經太遲了，SQL已經贏得了競爭。為什么呢?
(注：Ingres 公司使用的是 Stonebraker 教授發明的QUEL的查詢技術，這和IBM的SQL大不相同。在某些地方QUEL甚至要優于SQL。IBM當時擔心Ingres把QUEL變成標準會對自己不利。經過一番衡量，決定把自己的SQL提交給數據庫標準委員會。而Stonebraker教授可不打算把QUEL提交給數據庫標準委員會，學院派的他認為這么做實際上是扼殺了創新精神。鷸蚌相爭，漁翁得利。ORACLE看到并抓住了這個絕佳的機會，大肆宣布ORACLE全面與SQL兼容，加上 ORACLE當時對Ingres PC上的版本的攻擊，再加上ORACLE公司銷售上的強勢，Ingres不斷丟城失地，等到后來推出支持SQL的數據庫的時候為時已晚。緊跟IBM讓 ORACLE得以成長、壯大，擁抱標準，擁抱開放，擁抱變化，讓ORACLE立于不敗之地。——Fenng《書寫歷史的甲骨文–ORACLE公司傳奇》)
SQL本身就是設計用來讓人類創建臨時查詢的語言。值得注意的是，SQL語言幾乎是唯一的聲明性語言，它存活了下來并成為了最流行的數據庫查詢語言。
在大部分人們還更適應以命令行的風格指揮計算機工作時，聲明式思想是很難被接收的。我們可以看到，試圖創建這類語言的不只在數據庫領域，也包括一些常規用途語言(比如：Java語言)。具體來說，Java EE完全是標記式的，主要標記標簽和成員類型，使解釋器可以處理那些標簽并注入行為。一旦你把JPA，JAXB，JAX-RS，JAX-WS，EJB，甚至或許還包括Spring和一些其他工具組合到一起形成應用，你馬上就能知道理解所有這些聲明式元素的含義以及了解它們如何及何時交互有多么困難。通常情況下，行為不是具體的或者是半具體的。
SQL是一種比較簡單的聲明式語言，有很多的限制。這是優點，因為語言特性不多，可以使你快速實現符合SQL標準的需求。事實上，SQL語言的這種普遍性甚至導致了許多NoSQL數據庫都在采用SQL或者非常近似地模仿SQL：
- SQL on Hadoop
- Phoenix for HBase
- Cassandra的CQL
- JCR-SQL2等等
當然了，更不用說數不清的關系型數據庫統統都在使用SQL。
隨著廣受歡迎的ORM幫助把用SQL實現CRUD的繁瑣工作抽象出來，再考慮到查詢和大批量數據處理(不管你的底層存儲是關系型的還是非關系型的都沒有關系)，可以說SQL幾乎沒有有競爭力的替代品。
換言之，SQL的非關系性是該語言的主要優點之一，它使得SQL可以與其它方面的數據處理進行協作，比如XML、OLAP、JSON、列存儲等等。
3、過程性語言是理想的計算機語言
關系型數據庫勝過其它非關系存儲機制的第三個優點就是過程性語言(Procedural Language)與SQL語言的緊密集成。
如果你采用縱向擴展，那么你的單臺數據庫服務器會希望利用盡可能多的處理器核心資源。因此，你會希望盡可能在服務器的RAM中進行數據計算。
多年來，企業軟件架構師們都在試圖把業務邏輯轉移到中間層，對于采用J2EE或者后來的Java EE架構的更是如此。這一觀念幫助許多大型軟件廠商在已經銷售了昂貴數據庫的情況下，又成功銷售了及其昂貴的中間件作為架構必備補充。
在以前這是非常合理的，因為20年前的數據庫并沒有當今數據庫如此強大。然而，現在商業版的SQL優化器已經極其強大了。為讓你的SQL提速，你需要做的全部工作就只有調整合適的索引了。如果你決定使用的平臺不支持使用SQL，那么這會極大增加你的數據處理邏輯總擁有成本。要想手工操作，用Java這種通用的命令式語言以算法的形式實現執行計劃調優是非常困難的。當然，這種做法也有一些思路，可以用像jOOQ這種API實現。
對于一切不合適用SQL的情況，你可以使用關系數據庫的過程性語言，它支持直接在數據庫中實現更復雜更明確的算法，可以使業務邏輯與數據綁定非常緊密。這種語言不但訪問數據非常快速，而且可以用SQL與大批量數據處理交互。
換句話說，把一些計算量繁重的邏輯放到數據庫中，對于許多情況來說都是最好的選擇。我認為未來會有更多的技術公司將開始構建內存數據庫，這將毫無疑問進一步推動過程性SQL語言的普及。過程性語言包括：Transact-SQL(T-SQL)，PL/SQL和SQLScript。
關系數據庫贏得了過去，也將贏得未來
“如果你只有一把錘子，那么所有問題看起來都像釘子。”
對于關系數據庫來說，可能沒有更好的比喻了。他們是瑞士軍刀級的錘子，有數以百萬計的工具，絕大多數開發者們需要的只是這把“錘子”，他們就可以走很遠。所以，保持冷靜，繼續前行(Keep calm and SQL on)!
關于作者：Lukas Eder是瑞士公司Data Geekery的創始人兼CEO，這家公司主要提供JooQ工具，能夠將SQL語言與Java進行緊密的結合。
