建站
咨詢
售后
建站咨詢
新聞中心
【外電頭條】列數(shù)據(jù)庫出名可能是因為Google BigTable的出現(xiàn)，它表面上和關(guān)系數(shù)據(jù)庫類似，但實際上卻有著本質(zhì)的不同，一個是按行存儲數(shù)據(jù)（關(guān)系數(shù)據(jù)庫），一個是按列存儲數(shù)據(jù)（列數(shù)據(jù)庫）的，你不能將適用于關(guān)系數(shù)據(jù)庫的解決方案強(qiáng)加給列數(shù)據(jù)庫，因為列數(shù)據(jù)庫是沒有關(guān)系的。數(shù)據(jù)庫頻道向您推薦《NoSQL：關(guān)系型數(shù)據(jù)庫的終結(jié)者？》專題，以便于您更好的理解NoSQL。
搞清楚下面幾個概念才能理解列數(shù)據(jù)庫是如何工作的：
◆Column Family
◆Super Column
◆Column
列數(shù)據(jù)庫中的Column和Super Column是不占位的，意味著如果它們里面沒有值，它們只占用0字節(jié)，Column Family與傳統(tǒng)數(shù)據(jù)庫中的表類似，但和表又不一樣，在Column Family中的唯一定義是名稱和鍵（Key）排序選項（沒有任何模式）。
我個人認(rèn)為Column Family數(shù)據(jù)庫（CFDB）可能是消除抽象設(shè)計的最佳方法，因為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是一個由名稱，值和時間戳組成的三元組（我將忽略時間戳，把它當(dāng)作一個Key/Value對看待）。
最重要的是要明白CFDB架構(gòu)設(shè)計的外圍重要性，如果架構(gòu)都不正確，那基本上就無法獲取數(shù)據(jù)，CFDB通常按照鍵或鍵范圍提供一兩種形式的查詢，這是很有意義的，因為CDFB通常是分布式的，鍵決定了數(shù)據(jù)的真實物理位置，這是因為數(shù)據(jù)是基于Column Family的排序順序存儲的，你是沒有辦法改變排序方式的（除了選擇升序和降序外）。
和關(guān)系數(shù)據(jù)庫中的排序順序不一樣，列數(shù)據(jù)庫的排序順序不受列的值影響，只受列名的影響。
假設(shè)在Users Column Family，@ayende行中，我們將列“name”設(shè)為“Ayende Rahine”，列“l(fā)ocation”設(shè)為“Israel”，CFDB將會象Users Column Family文件一樣對它們進(jìn)行排序：
- @ayende/location = “Israel”
- @ayende/name = “Ayende Rahien”
這是因為排序時“l(fā)ocation”小于“name”的緣故，如果在Friends Column Family中有一個Super Column，用戶“@ayende”有兩個朋友，它們將會象Friends Column Family文件那樣進(jìn)行存儲：
- @ayende/friends/arava= 945
- @ayende/friends/rose = 14
記住，這個屬性對理解CFDB是如何工作的相當(dāng)重要，我們以Twitter模型為例，我們需要存儲：用戶和推（tweet），我們定義了三個Column Family：
◆Users – 按UTF-8排序
◆Tweets – 按連續(xù)GUID排序
◆UsersTweets - Super Column Family，按連續(xù)GUID排序
我們創(chuàng)建一個用戶（我使用name參數(shù)標(biāo)志列名和值，key參數(shù)表示行的鍵，Column Family是Users）：
- cfdb.Users.Insert(key: “@ayende”, name: “Ayende Rahine”, location: “Israel”, profession: “Wizard”);
下圖是一個可視化的表示，注意與關(guān)系數(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ù)它進(jìn)行排序；
◆兩個行上面有不同的數(shù)據(jù)列；
◆我們實際上沒有任何方法將用戶和推關(guān)聯(lián)起來。
在關(guān)系數(shù)據(jù)庫中，我們通常會定義一個名叫UserId的列，這樣我們可以通過它將推鏈接回用戶，此外，關(guān)系允許我們按用戶ID查詢推，但CFDB沒有這樣的功能，無法根據(jù)列的值進(jìn)行查詢，也沒有辦法按照列進(jìn)行查詢，CFDB只能根據(jù)鍵查詢，我們以UsersTweets Column Family為例進(jìn)行說明：
- cfdb.UsersTweets.Insert(key: “@ayende”,
- timeline: { SequentialGuid.Create(): firstTweetKey } );
- cfdb.UsersTweets.Insert(key: “@ayende”,
- timeline: { SequentialGuid.Create(): secondTweetKey } );
在CFDB上，它看起來象：
圖 3 用戶和推關(guān)聯(lián)
這里我們向UsersTweets Column Family插入數(shù)據(jù)，行的Key是“@ayende”，Super Column timeline有兩列，每個列的名字是一個連續(xù)的GUID，這意味著我們可以根據(jù)它進(jìn)行排序，實際上我們是用一個Super Column創(chuàng)建了一個行，它又包含兩列，列名是一個GUID，每一列的值是Tweets表中一個行的鍵。
問題：我們可以在Users Column Family中創(chuàng)建一個Super Column存儲關(guān)系嗎？是的，可以這么做，但一個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ì)上來講，我們執(zhí)行了兩個查詢，一個是在UsersTweets Column Family執(zhí)行的，用行鍵“@ayende”請求timeline Super Column中的列和值，然后在Tweets Column Family上執(zhí)行另一個查詢，獲得真正的推。
因為數(shù)據(jù)是按照列名排序的，同時我們選擇的是降序排序，我們獲得了該用戶的最后25個推。
如果我想展示最后25個推該怎么辦？很簡單，只需要查詢Tweets Column Family中的推，然后按鍵倒序排序即可。
為什么CFDB有如此多的限制？
你可能已經(jīng)注意到我多次提及RDBMS和CFDB的差異，我認(rèn)為CFDB理解起來確實有點難，即使它表面上和關(guān)系數(shù)據(jù)庫很接近，但它的限制卻很多，沒有連接，沒有真正的查詢功能（除了主鍵外），越是熟悉關(guān)系數(shù)據(jù)庫，對理解CFDB越是有影響。
之所以有這么多的限制，主要原因是CFDB設(shè)計目標(biāo)就是運行在多臺機(jī)器上，存儲大量信息的，在關(guān)系數(shù)據(jù)庫中幾乎是不可能存儲這么多數(shù)據(jù)的，即使是象Oracle RAC這樣的集群數(shù)據(jù)庫也存儲不了那么多數(shù)據(jù)。
CFDB不提供連接的原因是，連接需要你能掃描整個數(shù)據(jù)集，這個時候要么使用一個視圖，否則就只有掃描整個數(shù)據(jù)庫了，這會造成性能急劇下降，因此CFDB必須避免出現(xiàn)這種情況。
CFDB不提供按列或按值查詢的原因是，因為這樣要么需要一個索引，要么掃描整個數(shù)據(jù)集，CFDB將查詢限制到只能按鍵進(jìn)行查詢，確保它能準(zhǔn)確地知道查詢應(yīng)在哪個節(jié)點上運行，這意味著每個查詢只會掃描一小段數(shù)據(jù)集，性能自然會好很多。
理解列數(shù)據(jù)庫需要一種截然不同的思維方式，雖然我沒有CFDB實戰(zhàn)經(jīng)驗，我可以想像得到，使用它們遷移是個麻煩事，但它確實是獲得高可擴(kuò)展數(shù)據(jù)存儲的最好方式。
到最后，數(shù)據(jù)庫的編輯了解到，有些專業(yè)人士還是認(rèn)為列數(shù)據(jù)庫也不全是NoSQL。盡管有Sybase IQ這樣的產(chǎn)品，但是列數(shù)據(jù)庫當(dāng)中還是有關(guān)系存在的。
作者簡介
Ayende Rahien只是網(wǎng)名，作者的真實名字叫做Oren Eini，他是一名經(jīng)驗豐富的開發(fā)人員/架構(gòu)師，主要精力放在CLR，構(gòu)建商業(yè)應(yīng)用和開發(fā)生產(chǎn)力框架和工具上，他也是多個著名開源項目的積極成員，包括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
【編輯推薦】
- 用NoSQL來替代MySQL在Digg中的原因
- MongoDB CEO談NoSQL的大數(shù)據(jù)量處理能力
- 專訪蓋國強(qiáng)：NoSQL很火 但還需市場檢驗
- 詳解NoSQL數(shù)據(jù)庫使用實例
- 云計算時代NoSQL當(dāng)?shù)?關(guān)系數(shù)據(jù)庫日薄西山
文章名稱：NoSQL那些事：51CTO帶您走進(jìn)列數(shù)據(jù)庫
瀏覽路徑：http://www.dlmjj.cn/article/dpjdpsc.html
