圖片來源: 

iThome

早在1998年,就已經有人提出NoSQL資料庫的概念,不過,這項技術沒有成為主流。直到最近幾年,出現了大量使用者貢獻資料的網站,帶動了分散式資料庫的需求,這些網站擁有大量使用者貢獻的資料,而且還不斷成長。為了滿足資料成長的擴充需求,傳統的商用關聯式資料庫借助資料庫叢級技術才能解決,然而這就得投資高額的軟硬體擴充經費。

網站業者為了解決如TB等級甚至是PB等級的巨量資料儲存和擴充問題,開始研發各種建置成本較低的分散式開源資料庫,Google自行研發的BigTable就是其中最好的例子。其他如Amazon、Yahoo近幾年也都投入這類NoSQL資料庫的研發。甚至連微軟的Azure雲端平臺也使用了NoSQL技術來存取資料。

同樣情況,像Facebook、Twitter、Zynga這類社交型網站為了解決龐大的使用者互動資料,也大量使用NoSQL資料庫技術。例如Facebook開發出Cassandra資料庫,在600多個運算核心的叢集系統上,儲存了超過120TB的站內郵件。

在2009年,開源社群重新使用NoSQL這個名詞來代表這些分散式非關聯式資料庫的統稱。

其實,NoSQL資料庫包括十幾種資料庫系統,也很不像關聯式資料庫那樣有一套通用的基礎資料庫理論。不過,還是有幾項了解NoSQL資料庫不可不知的關鍵,只要掌握這些關鍵,就能對NoSQL資料庫有基本的了解。

觀念1:NoSQL是Not Only SQL

因為SQL語言是關聯式資料庫的標準查詢語言,原本NoSQL資料庫用來代表那些無法提供SQL語言查詢的資料庫系統,這些資料庫系統大多是開源的分散式資料庫系統,不過,也有少數商用資料庫系統具有NoSQL的特性,例如微軟Azure平臺上儲存資料的方式。

今年開源社群則出現了另外一個新的定義方式,將NoSQL視為「Not Only SQL」,不只是SQL的意思,也就是說混用關聯式資料庫和NoSQL資料庫來達成最佳的儲存效果,例如前面舉的力可科技就是用NoSQL資料庫來儲存資料量大的用戶狀態資料,但其他資料仍然使用關聯式資料庫,以便善用SQL語法的好處。

觀念2:增加機器就能自動擴充資料庫容量

NoSQL資料庫的另一個重要特性是具有水平擴充能力,只要增加新的伺服器節點,就可以不斷擴充資料庫系統的容量。而且可以利用低價的一般等級電腦就能進行水平擴充,不像關聯式資料庫的叢集系統往往需要效能和容量較大的伺服器才能勝任。NoSQL資料庫可以用更低的成本打造出TB等級或PB等級的大型資料庫系統。

有些NoSQL資料庫甚至可以在不停機或不影響應用程式的情況下,線上就能直接擴充資料庫系統的容量。

舉例來說,Cassandra可以動態擴充新的資料庫節點,只要啟動新的資料庫節點,舊有的資料庫節點會自動將資料複製到新節點中,平衡彼此的資料存取負載。不用像常見的資料庫切割作法那樣,必須手動進行資料庫的去正規化、切割資料表、複製資料、指定應用程式連結等過程。

簡單來說,水平擴充能力的意思就是只要增加新的伺服器設備,就能自動增加資料庫的容量,從管理角度來看,這也可以減少長期維護資料庫的人力。

觀念3:打破Schema欄位架構的限制

關聯式資料庫必須透過資料庫的Schema欄位架構來確立資料表之間的關聯,Schema通常是事先設計好的架構,上線以後要進行欄位變更非常麻煩,尤其資料量龐大時要變更Schema的難度很高,例如Twitter為了調整資料欄位,光是執行Alter Table指令來改變資料表的定義就跑了一個禮拜。

NoSQL資料庫則是改用Key-Value資料模式來解決龐大資料的異動困難。Key-Value模式是將一筆資料的結構簡化到只有一個Key值對應到一個Value值,每一筆資料之間沒有關連性,所以,可以任意切割或調整,也可以分散到不同的伺服器中建立副本。

有些NoSQL資料庫則是增加了Column的觀念,用法上等於是可以用更多的Key值來對應Value,例如Cassandra就提供了4層或5層Key-Value的資料結構,可以用3個Key來對應1個Value值。例如用「使用者帳號」、「個人檔案」、「生日」這三個Key值來取得某一個用戶的生日日期。採用Column設計的NoSQL資料庫會比只用Key-Value資料架構的資料庫更有彈性,減少資料存取程式的開發難度。

因為NoSQL資料庫沒有Schema架構,所以,也無法支援標準的SQL語法來查詢資料。NoSQL資料庫通常是透過簡單的API來新增、更新或刪除資料庫中的內容,有些資料庫則會提供類似SQL語法中的Select查詢機制,不過通常也無法執行複雜的Join指令,例如Google App Engine就提供了GQL語法讓開發者查詢BigTable上的資料。

觀念4:資料遲早會一致

為了確保資料的完整性,關聯式資料庫採用的交易(Transaction)的設計,讓資料存取或異動過程中不會受到干擾。Transaction資料庫的特性就是ACID,在SQL執行過程中,確保有交易作為最小運作單位(Atomicity)、異動過程確保整體資料庫的一致性(Consistency)、執行多筆交易時能隔離交易中的資料不受其他交易影響(Isolation)以及交易過程不會變動原始資料的持久性(Durability)。

但是ACID架構的資料庫擴充不易,所以,NoSQL資料庫大多沒有交易的設計,而是採用了另外一個不同的CAP資料庫理論。

CAP理論有三個關鍵,包括資料一致性(Consistent)、可用性(Availability)和中斷容忍性(Partition Tolerance)。理論上無法同時兼顧CAP這三種特性,所以,NoSQL資料庫通常會選擇其中兩種特性來設計,通常是選擇CP或AP。

多數NoSQL資料庫選擇的是CP的設計,不過,NoSQL資料庫中談的資料一致性和關聯式資料庫的意義不同。NoSQL資料庫會採取Eventually Consistency(資料遲早會一致)的作法,因為NoSQL的分散式設計會將資料分散複製到不同節點中,每個節點各自也能異動資料,然後再彼此同步。同步過程就會有時間落差,若同時讀取不同節點上的資料,會發生資料不一致的情況。

NoSQL資料庫為了保持分散式的擴充架構,容許這樣的情況,只有保證最後資料會達到一致。而在資料尚未同步的短暫時間內就需要開發者自行解決資料衝突或遺失的問題,或者是用NoSQL資料庫來記錄那些對精確度要求較低的資料,例如Facebook的贊按鈕,即使少了幾個贊的記錄,使用者也不容易發現,就適合用NoSQL資料庫來儲存。導入NoSQL資料庫時,開發者得先評估資料的性質,是否能承擔資料遺失的風險。

觀念5:成熟度不足,版本升級風險高

因為近幾年Web 2.0網站和社交網站的盛行,才開始出現用NoSQL資料庫解決使用者貢獻資料的暴漲問題。很多NoSQL資料庫都是這2、3年內才出現,所以,資料庫本身的功能還不完整,也較少出現成熟穩定的版本,版本升級過程中很容易會出現不相容的情形。

另一方面,這類資料庫大多透過API來存取資料,新的版本若增加了新的功能,也會改變這些API的參數或呼叫方式。對開發者而言,等於得重新修改應用程式,才能正確取得資料庫中的內容。甚至是資料庫本身儲存的檔案格式也會變化,升級新版本資料庫後,反而無法讀取舊版檔案,必須進行格式轉檔的工作。

找到合適的NoSQL資料庫,一方面要挑選知名網站所使用的資料庫,因為這些知名網站通常也是這些資料庫的貢獻者,他們為了解決自身的使用問題,會比較積極地完善資料庫。

另外,還要考慮自身的技術能力以及掌握外國技術發展的學習能力,雖然NoSQL資料庫提供了另外一種低成本的分散式資料庫,自動擴充節點的功能可以節省資料庫維護人力,但是,相對地,也須承擔技術不夠成熟時的變動風險。

 

為了解決使用者貢獻資料快速成長的問題,Facebook開發了一套NoSQL資料庫Cassandra,在600多個運算核心的叢集系統上,儲存了超過120TB的站內郵件資料。

 


相關報導請參考「NoSQL:解決資料庫暴量的新方法」


Advertisement

更多 iThome相關內容