用NoSQL (Not Only SQL) 解決資料庫不斷擴充的維護問題。
社交遊戲的互動會造成大量寫入資料的需求，一天就會產生2GB資料量；Facebook、Google、Twitter這些國外大型網站，為了解決資料庫大量資料存取的問題，近年來紛紛捨棄了關聯式資料庫技術(RDB)，改以NoSQL資料庫來提升效能與擴充彈性。
早在1998年，就已經有人提出NoSQL資料庫的概念，不過，這項技術沒有成為主流。直到最近幾年，出現了大量使用者貢獻資料的網站，帶動了分散式資料庫的需求，這些網站擁有大量使用者貢獻的資料，而且還不斷成長。為了滿足資料成長的擴充需求，傳統的商用關聯式資料庫借助資料庫叢級技術才能解決，然而這就得投資高額的軟硬體擴充經費。
網站業者為了解決如TB等級甚至是PB等級的巨量資料儲存和擴充問題，開始研發各種建置成本較低的分散式開源資料庫，Google自行研發的BigTable就是其中最好的例子。其他如Amazon、Yahoo近幾年也都投入這類NoSQL資料庫的研發。甚至連微軟的Azure雲端平臺也使用了NoSQL技術來存取資料。
同樣情況，像Facebook、Twitter、Zynga這類社交型網站為了解決龐大的使用者互動資料，也大量使用NoSQL資料庫技術。例如Facebook開發出Cassandra資料庫，在600多個運算核心的叢集系統上，儲存了超過120TB的站內郵件。
但其實NoSQL並非觀念上的衝擊，而是將存取資料庫的方式拉回十年前 - 根據資料的使用特性，選擇適當的儲存機制；在這個基礎觀念下，當我們有適合關聯式處理的資料時，我們還是會把它存入RDBMS。故所謂 RDBMS 落伍的說法，其實並不成立。
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資料庫提供了另外一種低成本的分散式資料庫，自動擴充節點的功能可以節省資料庫維護人力，但是，相對地，也須承擔技術不夠成熟時的變動風險。
4類主流NoSQL資料庫
類型 1 Key-Value類型的資料庫最多
Key-Value資料庫是NoSQL資料庫中最大宗的類型，這類資料最大的特色就是採用Key-Value資料架構，取消了原本關聯式資料庫中常用的欄位架構（Schema），每筆資料各自獨立，所以，可以打造出分散式和高擴充能力的特性。
包括像Google的BigTable、Hadoop的HBase、Amazon的Dynamo、Cassandra、Hypertable等都是這類Key-Value資料庫。
Google自行研發的BigTable建置在Google檔案系統GFS上，專供Google自家應用程式使用，例如Gmail、GoogleReader、Google地圖、YouTube等應用的資料都是儲存在BigTable中。現在Google也透過GoogleAppEngine服務開放其他人使用BigTable來儲存資料。
BigTable就像是一張整合大量機器的資料表，所有資料都存在同一張資料表中，單個資料表可以儲存PB等級的內容。GoogleAppEngine提供了一種GQL查詢語言，讓開發者使用Select語法來查詢BigTable中的資料，不過，這種GQL語言不能像SQL語言那樣可以使用Join語法來進行跨資料表查詢。
因為Google沒有釋出BigTable和相關的雲端運算平臺，後來就出現了另外一套參考Google雲端運算架構的Hadoop平臺，並且發展出HBase分散式資料庫。HBase是Hadoop平臺使用的資料庫，用來儲存Hadoop進行MapReduce平行運算的資料。類似Google的BigTable，也是在一張大資料表中儲存很多行資料，每一行的結構同樣有一個主要Key值和任意數量的列欄位。
Amazon開發的Dynamo分散式資料庫則是用在Amazon的網路服務，例如S3儲存服務，也是採取Key-Value的儲存方式來建立分散式的高可用性環境。Amazon的購物車就是使用Dynamo資料庫，Dynamo會將一份資料複製到很多伺服器上建立副本，彼此定期同步。不過，由於Dynamo無法確保每一個副本的資料即時同步，為了解決資料衝突和遺失的問題，Amazon另外開發了衝突解決技術來確保資料的一致性。
在Key-Value資料庫類型中，還有一個最近很熱門的NoSQL資料庫，也就是力可科技使用的Cassandra。這是Facebook在2008年釋出的分散式資料庫，支援Java平臺。Facebook用Cassandra來儲存高達120TB的站內信箱（inbox）資料，2009年3月由Apache基金會接手維護，現在是Apache重點發展的頂級計畫之一。
和HBase這種主從式架構的分散式資料庫不同，Cassandra每一個在資料庫叢集中的節點都是相同的，沒有主從關係，所以，建置分散式資料庫時，Cassandra最少只要建立2個伺服器節點就能執行，這兩個節點的功能和角色幾乎一模一樣，只需要在設定檔中指定好彼此溝通的IP網址即可。啟動資料庫以後，這兩個節點會自行複製資料、分散儲存、平衡資料庫存取的負載。
類型 2 記憶體資料庫是知名網站慣用快取工具
記憶體資料庫（In-memoryDatabase）就是將資料儲存在記憶體的NoSQL資料庫，包括了Memcached、Redis、Velocity、Tuplespace等。其實像Memcached、Redis都是一種Key-Value資料架構的資料庫，只是這類資料庫改將資料儲存在記憶體中來提高讀取效率，大多用來快取常用網頁，加快傳遞網頁的速度，減少讀取硬碟的次數，不過系統關機後就無法保存。
2003年就出現的Memcached更是許多知名網站改善網站瀏覽效率的重要工具，例如YouTube、Facebook、Zynga、Twitter等都有使用Memcached。Google應用代管服務AppEngine也提供了Memcached的服務。
在Facebook上最熱門的FarmVille農場遊戲就是利用Memcached來改善遊戲流暢性。FarmVille每天登入的使用者人數高達1千萬人，為了讓使用者操作過程不需要等待資料讀寫的延遲，FarmVille採取2層式的架構，使用Memcached來傳遞站上使用者的資料，稍後再整批將資料寫入後端MySQL資料庫，儲存在硬碟上。不過，這個架構的風險就是，系統當機時，會遺失一整批儲存在記憶體中的資料。
除了老牌的Memcached以外，2009年出現了一個新的開源記憶體資料庫Redis。除了提供分散式的快取以外，Redis和Memcached最大的不同點是，Redis提供了一個資料架構，可以自動排序那些儲存在Redis中的資料，讓開發者取得排序後的資料。
Redis在今年3月時獲得VMware贊助。9月剛釋出了2.0新版，新增加了如虛擬記憶體的設計，讓開發者可以放入記憶體容量更多的資料量。美國分類廣告網站Craigslist和程式碼代管網站Github都是使用Redis來加快存取速度。
類型 3 文件資料庫適合儲存非結構化資料
文件資料庫主要是用來儲存非結構性的文件，例如最常見的非結構化資料就是HTML網頁。一個HTML網頁結構不像一般表格那樣有固定的欄位，每個欄位有特定資料類型和大小。例如網頁裡有Head和Body結構，Body元素中可能會有10個段落，段落中會有文字、連結、圖片等。文件資料庫的資料結構往往是鬆散的樹狀結構。
很多文件資料庫都是商用資料庫系統，文件資料庫的概念源自IBM的LotusNotes儲存文件的方式，XML資料庫也是一種文件資料庫。常見的開源文件資料庫像是CouchDB、MongoDB以及Riak等。
隨著網頁儲存和搜尋索引的需求大增，CouchDB和MongoDB這2款文件資料庫越來越受到關注。2005年就出現的CouchDB剛釋出了1.0版，它也是Apache基金會維護的頂級計畫之一。CouchDB提供了一套RESTful的API，讓應用程式透過HTTP協定就能存取資料庫，也可以用JavaScript作為查詢語言。
2009年才出現的MongoDB很快就已經釋出穩定的1.6.1版，可以用來儲存UTF-8和非UTF-8的文件資料。不像CouchDB只能儲存UTF-8格式的文件。MongoDB同樣可以在查詢指令中使用JavaScript。採取Master-Slave架構，1臺Master伺服器搭配多臺資料伺服器，資料伺服器間互相備援、容錯。
類型 4 圖學資料庫可用於記錄社交關係
最後一類是圖學資料庫，這不是專門用來處理圖片的資料庫，而是指運用圖學架構來儲存節點間關係資料架構，例如用樹狀結構來組織從屬關係或網狀結構來儲存朋友關係，地理圖資系統通常也會用圖學資料庫來儲存地圖上每一點和鄰近點的關係，或用圖學資料庫來計算點與點之間最短的距離，也可以用同樣的概念來計算出人與人之間最短的交友距離。圖學資料庫最大的特性是對複雜性的擴充力，關係越複雜的資料越適合使用圖學資料庫。
這類資料的資料結構沒有標準的作法，基本的圖學資料包括了節點（Node）、關係（Relation）和屬性（Property）三種結構。例如用節點來記錄Facebook上的帳號、用關係來記錄朋友關係、用屬性來描述這個帳號的個人資料等。最後可以用網絡圖來呈現出Facebook用戶之間的交友狀況。常見的圖學資料庫如Neo4j、InfoGrid、AllegroGrph等。
進階閱讀：大智若魚 - NOSQL 背後的共通原則
參考
留言列表
