在互聯網中關係型數據庫是否再也不那麼重要

關鍵詞：互聯網、關係型數據庫 

　　強調互聯網，這是由於本文所討論的前提是互聯網應用。與「傳統」應用不一樣，互聯網中的應用天天面臨的是海量的數據、大量的請求以及對系統可靠性和響應速度有着更高的要求。「傳統」應用，我姑且淺顯地認爲是，數據量不大，面對的用戶羣範圍相對較小，天然大量的高併發請求場景幾乎不存在。 

　　在上文對互聯網應用和傳統應用有了一個大概的認識後，接下來咱們來談一談，本文的主題關係型數據庫在兩種類型應用的不一樣使用方式，以及關係型數據在現在的互聯網應用中是否再也不是關注的焦點。 

　　首先，海量的數據。百萬級甚至千萬級億級的數據已不可能存儲在單一的數據表中，甚至不可能存儲在一個數據庫中。試想若是將全部的數據存儲在單庫單表中，一旦發生全表掃描，這對於系統響應速度來說將是一個災難。然而在傳統應用中，可能單庫單表已經足以適用。 

　　第二，因爲產生了海量數據，進而數據在磁盤上的存儲被設計成了「分庫分表」的模式，利用某種特定的「路由」算法，定位一個數據所處的位置。正是由於「分庫分表」的設計，使得關係型數據中的「聯表查詢」場景失效，因此在互聯網應用中，一張表的設計已經幾乎再也不有「外鍵」，也就是聯表查詢幾乎已消失。 

　　第三，大量的請求。這在互聯網應用中比較常見，一塊兒突發事件，一個明星的突發新聞，都會形成大量的請求瞬時到達。數據庫的承載能力是有限的，一旦全部的訪問量在某一時刻同時涌入，這直接會形成數據庫宕機，整個系統甚至會由於數據庫的緣由形成服務不可用。因此在現在的互聯網應用中，對數據的讀取寫入幾乎已經再也不直接操做數據庫，而是在數據庫前加入了一道「安全」屏障——緩存。 

　　第四，服務的可靠性。服務的可靠性，即便系統出現問題，也要保證部分可用，讀寫分離是一個很好的解決方案，讀取和寫入操做再也不同一個數據庫中進行，而是將他們分開。若是此時有大量寫操做，要儘可能不影響讀操做，或者若是若是在寫入數據庫時形成數據庫宕機，此時要儘可能不能影響數據庫的讀操做。此時在互聯網應用中一般就會部署一套「主從」數據庫，主庫寫，從庫讀，這就會衍生出數據同步的問題，或者概括爲數據一致性問題。 

　　能夠看到，互聯網應用與傳統應用的異同點在於，互聯網應用對於數據庫的着重點在於從總體上進行把握，對數據的操做相對來講比較「粗糙」。而傳統應用因爲其自身緣由，只須要考慮更爲「精細化」的操做，例如連表查詢，表與表的關係，關係表仍是實體表等等。 

　　這是否意味着，在互聯網中關係型數據庫已經再也不那麼重要了呢？那些課本上的第一範式、第二範式已通過時了呢？ 

　　若是認爲互聯網中關係型數據庫再也不強調「精細化」的操做，就是已通過時了，這是一葉障目不見泰山。再總結一下，在互聯網中，對於關係型數據庫，咱們須要設計分庫分表、主從庫、讀寫分離、熱點數據緩存等等。在傳統應用中，對於關係型數據庫，咱們須要設計出E-R圖，須要設計主鍵、外鍵，須要寫聯表查詢的SQL語句等等。 

　　再回顧一下，咱們在大學的數據庫課程中，在學習數據庫時，是不是從第一範式、第二範式開始的？再逐步練習「一個學生學習了哪幾門課程」、「一個學生每一個課程的分數」、「某門課程按80分、90分以上分類」這類的SQL語句，由於這是基礎，這是原理。 

　　那麼回到本文的主題「在互聯網中關係型數據庫是否再也不那麼重要」，筆者的觀點是，側重點不一樣，互聯網應用的很大，有的很大很大，有時須要你放棄遵循某些範式，從其餘方面去彌補，而從總體上去思考如何進行數據建模，互聯網應用更加考驗的是「能力」，對數據建模的能力，如何構建更高的可靠性應用。傳統應用，更加考驗的是一切按照規矩來，「精細化」的操做，對SQL語句的熟悉程度就意味着對數據庫的熟悉程度。 

　　但就算是互聯網中，SQL語句並不是是不重要的，不要由於本身處在互聯網，不熟悉SQL語句當作是一種「炫耀」，這是扎馬步式的基本功。最簡單的例子，若是不重要，像阿里同樣的互聯網公司，照樣在研究關係型數據庫（參見：阿里巴巴數據庫內核月報： http://mysql.taobao.org/monthly/）。 

　　最後，《三體》一書中，智子鎖死了人類的基礎物理學，致使人類在科技面前徹底停滯。 

 

 

這是一個能給程序員加buff的公衆號