From relational databases to distributed/parallel databases to cloud databases

從關係型數據庫到分佈式與平行數據庫再到雲端數據庫

課程 : 論文研討(一)日期 : 2012/09/28
時間 : 13:50 ~ 15:30
地點 : S104
作者 : 資工研一 陳曦
講者 : 國立政治大學 陳良弼教授

         今天請來了大名鼎鼎的陳良弼教授來給我們做演講，講了當下數據庫正在由傳統的關係型數據庫到非關係型數據庫演進的趨勢。
        何為NoSQL，NoSQL = Not Only SQL，其實這一概念很早就有人提出，但發展到2009年，NoSQL的趨勢越發高漲，相對於傳統的、成熟的關係型數據庫，NoSQL給整個互聯網行業造成了革命性的影響。
        為何要NoSQL? NoSQL的直接推動力是web2.0網站的興起，傳統的關係型數據庫在應付web2.0網站，特別是大規模高並發(concurrency)的SNS網站（如facebook,twitter），顯得力不從心。
        我想舉以下這個例子說明SQL與NoSQL之間的差異，假設beader在facebook上發了一張照片，那麼在SQL中可能需要建立如下三張表：

user表

_uid	username	from
u00001	beader	Taiwan
u00002	jobs	USA

                          

photo表

_pid	title	uid
p00001	travel1	u00001
p00002	travel2	u00001

comment表

_cid	text	uid	pid
c00001	“nice shot”	u00002	p00001
c00002	“XD”	u00001	p00001

        實際情況要更加複雜，建立表的數量會更多。如果要在你的頁面上顯示這張照片，在照片旁邊顯示出你的名字，以及好友的評論，那麼就要由photo表中找到uid，然後根據uid去user表中找到你的信息，在photo旁邊顯示​​出你的名字，然後再根據pid在comment表中搜索對應的評論，然後再根據uid從user表中查詢到評論該照片的用戶的信息。可以很容易計算出，為了顯示一張有兩個用戶評論的照片，需要進行5次以上的跨表查詢。當然在SQL中跨表查詢似乎不算是太慢，但目前的環境已經和過去不同，在雲端，這三張表可能存在於三個不同的磁碟，甚至三個不同的服務器上，這是跨表查詢的效率問題就值得我們考慮了。

        但再來看看NoSQL的解決方案。在NoSQL中，我們假設也是建立user,photo,comment表，但結構可以大不一樣。拿photo表來開刀，photo表可以長成這個樣子

[

  {_pid : "p00001", title : "travel1" , uid : "u00001" , 

   comment : [

          {_cid : "c00001" , text : "nice shot" , uid : "u00002" },

          {_cid : "c00002" , text : "XD" , uid : "u00001"}

          ]

   },

   {_pid : "p00002", title : "travel2" , uid : "u00001"}

]

        而這個時候，要達到相同的目的，就避免了跨表查詢，查詢速度較之前關係型數據庫快了許多。

        細心的人可能會發現，在NoSQL中，數據結構並不是normalized的，並且在一個欄位底下，會存在層次結構，這在SQL中是不可能出現的，因此，靈活性也是NoSQL的一大特色。

假設之前facebook用的是SQL，那麼某天用戶要求在照片旁邊顯示一個"贊"，這就需要在原始資料庫中加入"贊"這個字段，但這對於​​一個需要24小時連續運轉的網站來說，幾乎是不可能完成的，並且是十分危險的。而對於NoSQL來說，我們就可以比較輕鬆的實現這一要求。原始資料並不需要更改，當某張照片被"贊"的時候，再立刻補上這個字段。

        當然，我們可以很容易得看出NoSQL也存在很大的缺點。在上面這個例子中，photo表中存有comment記錄，而comment表中可能也存有這個記錄，如果某個用戶對其評論進行修改，那就要進行跨表操作，即photo表要改，comment表也​​要改。而對於SQL來說，只需要修改comment表，因此數據一致性上是NoSQL的硬傷。不過對於社交網站而言，絕大部分用戶涉及到的都是查詢操作，相對而言修改操作很少，這是其一。其二，當用戶修改其評論時，我們真的需要立刻修改comment表嗎？不需要，我們只需要先修改photo表中的comment資料，在用戶視角上看，他的評論確實已經改變，但此時comment表中的記錄不一定被更改，服務器可以根據自身狀況，在負載較低的時候，例如晚上，再去更改comment表，從​​而保證幾張表的數據是一致的。

        總的說來，SQL與NoSQL各有各的優缺點。但從未來雲端存儲，雲端運算來看，NoSQL更能適應其需求。