【51CTO外電頭條】列數(shù)據(jù)庫出名可能是因為Google BigTable的出現(xiàn)，它表面上和關系數(shù)據(jù)庫類似，但實際上卻有著本質的不同，一個是按行存儲數(shù)據(jù)（關系數(shù)據(jù)庫），一個是按列存儲數(shù)據(jù)（列數(shù)據(jù)庫）的，你不能將適用于關系數(shù)據(jù)庫的解決方案強加給列數(shù)據(jù)庫，因為列數(shù)據(jù)庫是沒有關系的。51CTO數(shù)據(jù)庫頻道向您推薦《NoSQL：關系型數(shù)據(jù)庫的終結者？》專題，以便于您更好的理解NoSQL。

搞清楚下面幾個概念才能理解列數(shù)據(jù)庫是如何工作的：

◆Column Family

◆Super Column

◆Column

列數(shù)據(jù)庫中的Column和Super Column是不占位的，意味著如果它們里面沒有值，它們只占用0字節(jié)，Column Family與傳統(tǒng)數(shù)據(jù)庫中的表類似，但和表又不一樣，在Column Family中的唯一定義是名稱和鍵（Key）排序選項（沒有任何模式）。

我個人認為Column Family數(shù)據(jù)庫（CFDB）可能是消除抽象設計的最佳方法，因為CFDB中的一切都是圍繞真實的物理模型的。

◆Column Family – Column Family指定數(shù)據(jù)如何存儲在磁盤上的，一個Column Family中的所有數(shù)據(jù)都將保存在相同的文件中，一個Column Family可以容納多個Super Column或Column。

◆Super Column - Super Column是一個字典，它是一個包含其它列的列，但一個Super Column不能包含另一個Super Column。

◆Column -  Column是一個由名稱，值和時間戳組成的三元組（我將忽略時間戳，把它當作一個Key/Value對看待）。

最重要的是要明白CFDB架構設計的外圍重要性，如果架構都不正確，那基本上就無法獲取數(shù)據(jù)，CFDB通常按照鍵或鍵范圍提供一兩種形式的查詢，這是很有意義的，因為CDFB通常是分布式的，鍵決定了數(shù)據(jù)的真實物理位置，這是因為數(shù)據(jù)是基于Column Family的排序順序存儲的，你是沒有辦法改變排序方式的（除了選擇升序和降序外）。

和關系數(shù)據(jù)庫中的排序順序不一樣，列數(shù)據(jù)庫的排序順序不受列的值影響，只受列名的影響。

假設在Users Column Family，@ayende行中，我們將列“name”設為“Ayende Rahine”，列“location”設為“Israel”，CFDB將會象Users Column Family文件一樣對它們進行排序：

@ayende/location = “Israel”  
@ayende/name = “Ayende Rahien” 

這是因為排序時“location”小于“name”的緣故，如果在Friends Column Family中有一個Super Column，用戶“@ayende”有兩個朋友，它們將會象Friends Column Family文件那樣進行存儲：

@ayende/friends/arava= 945  
@ayende/friends/rose = 14 

記住，這個屬性對理解CFDB是如何工作的相當重要，我們以Twitter模型為例，我們需要存儲：用戶和推（tweet），我們定義了三個Column Family：

◆Users – 按UTF-8排序

◆Tweets – 按連續(xù)GUID排序

◆UsersTweets - Super Column Family，按連續(xù)GUID排序

我們創(chuàng)建一個用戶（我使用name參數(shù)標志列名和值，key參數(shù)表示行的鍵，Column Family是Users）：

cfdb.Users.Insert(key: “@ayende”, name: “Ayende Rahine”, location: “Israel”, profession: “Wizard”); 

下圖是一個可視化的表示，注意與關系數(shù)據(jù)庫的區(qū)別。

圖 1 保存用戶信息的存儲樣式

現(xiàn)在我們創(chuàng)建一個推：

var firstTweetKey = “Tweets/” + SequentialGuid.Create();  
cfdb.Tweets.Insert(key: firstTweetKey, application: “TweekDeck”, text: “Err, is this on?”, private: true);  
var secondTweetKey = “Tweets/” + SequentialGuid.Create();  
cfdb.Tweets.Insert(key: secondTweetKey, app: “Twhirl”, version: “1.2”, 
text: “Well, I guess this is my mandatory hello world”, public: true); 

下面是它真實的存儲格式：

圖 2 保存推信息的存儲樣式

這里有幾件事需要注意：

◆在這里，Key不重要，重要的是它是連續(xù)的，因為后面會根據(jù)它進行排序；

◆兩個行上面有不同的數(shù)據(jù)列；

◆我們實際上沒有任何方法將用戶和推關聯(lián)起來。

在關系數(shù)據(jù)庫中，我們通常會定義一個名叫UserId的列，這樣我們可以通過它將推鏈接回用戶，此外，關系允許我們按用戶ID查詢推，但CFDB沒有這樣的功能，無法根據(jù)列的值進行查詢，也沒有辦法按照列進行查詢，CFDB只能根據(jù)鍵查詢，我們以UsersTweets Column Family為例進行說明：

cfdb.UsersTweets.Insert(key: “@ayende”,  
timeline: { SequentialGuid.Create(): firstTweetKey } );  
cfdb.UsersTweets.Insert(key: “@ayende”,  
timeline: { SequentialGuid.Create(): secondTweetKey } ); 

在CFDB上，它看起來象：

圖 3 用戶和推關聯(lián)

這里我們向UsersTweets Column Family插入數(shù)據(jù)，行的Key是“@ayende”，Super Column timeline有兩列，每個列的名字是一個連續(xù)的GUID，這意味著我們可以根據(jù)它進行排序，實際上我們是用一個Super Column創(chuàng)建了一個行，它又包含兩列，列名是一個GUID，每一列的值是Tweets表中一個行的鍵。

問題：我們可以在Users Column Family中創(chuàng)建一個Super Column存儲關系嗎？是的，可以這么做，但一個Column Family要么容納Super Column，要么容納Column，不能二者兼得。

為了獲得某個用戶發(fā)的推，我們需要執(zhí)行：

var tweetIds =   
      cfdb.UsersTweets.Get(“@ayende”)  
             .Fetch(“timeline”)  
             .Take(25)  
             .OrderByDescending()  
            .Select(x=>x.Value);  
var tweets = cfdb.Tweets.Get(tweetIds); 

從本質上來講，我們執(zhí)行了兩個查詢，一個是在UsersTweets Column Family執(zhí)行的，用行鍵“@ayende”請求timeline Super Column中的列和值，然后在Tweets Column Family上執(zhí)行另一個查詢，獲得真正的推。

因為數(shù)據(jù)是按照列名排序的，同時我們選擇的是降序排序，我們獲得了該用戶的最后25個推。

如果我想展示最后25個推該怎么辦？很簡單，只需要查詢Tweets Column Family中的推，然后按鍵倒序排序即可。

為什么CFDB有如此多的限制？

你可能已經注意到我多次提及RDBMS和CFDB的差異，我認為CFDB理解起來確實有點難，即使它表面上和關系數(shù)據(jù)庫很接近，但它的限制卻很多，沒有連接，沒有真正的查詢功能（除了主鍵外），越是熟悉關系數(shù)據(jù)庫，對理解CFDB越是有影響。

之所以有這么多的限制，主要原因是CFDB設計目標就是運行在多臺機器上，存儲大量信息的，在關系數(shù)據(jù)庫中幾乎是不可能存儲這么多數(shù)據(jù)的，即使是象Oracle RAC這樣的集群數(shù)據(jù)庫也存儲不了那么多數(shù)據(jù)。

CFDB不提供連接的原因是，連接需要你能掃描整個數(shù)據(jù)集，這個時候要么使用一個視圖，否則就只有掃描整個數(shù)據(jù)庫了，這會造成性能急劇下降，因此CFDB必須避免出現(xiàn)這種情況。

CFDB不提供按列或按值查詢的原因是，因為這樣要么需要一個索引，要么掃描整個數(shù)據(jù)集，CFDB將查詢限制到只能按鍵進行查詢，確保它能準確地知道查詢應在哪個節(jié)點上運行，這意味著每個查詢只會掃描一小段數(shù)據(jù)集，性能自然會好很多。

理解列數(shù)據(jù)庫需要一種截然不同的思維方式，雖然我沒有CFDB實戰(zhàn)經驗，我可以想像得到，使用它們遷移是個麻煩事，但它確實是獲得高可擴展數(shù)據(jù)存儲的最好方式。

到最后，51CTO數(shù)據(jù)庫的編輯了解到，有些專業(yè)人士還是認為列數(shù)據(jù)庫也不全是NoSQL。盡管有Sybase IQ這樣的產品，但是列數(shù)據(jù)庫當中還是有關系存在的。

作者簡介

Ayende Rahien只是網(wǎng)名，作者的真實名字叫做Oren Eini，他是一名經驗豐富的開發(fā)人員/架構師，主要精力放在CLR，構建商業(yè)應用和開發(fā)生產力框架和工具上，他也是多個著名開源項目的積極成員，包括NHibernate，Castle等，另外，Oren Eini還創(chuàng)建了多個開源項目，如Rhino Mocks，NHibernate Query Analyzer，Rhino Commons等。

原文出處：ayende.com/Blog/archive/2010/05/14/that-no-sql-thing-Column-family-databases.aspx

【編輯推薦】

1. 用NoSQL來替代MySQL在Digg中的原因
2. MongoDB CEO談NoSQL的大數(shù)據(jù)量處理能力
3. 51CTO專訪蓋國強：NoSQL很火 但還需市場檢驗
4. 詳解NoSQL數(shù)據(jù)庫使用實例
5. 云計算時代NoSQL當?shù)?關系數(shù)據(jù)庫日薄西山