采用NoSQL技術(shù)的云存儲解決方案漸漸成熟，但SQL數(shù)據(jù)庫思想還是占據(jù)主導(dǎo)地位。這可能導(dǎo)致使用SQL的方式來解決NoSQL的數(shù)據(jù)建模問題。本文根據(jù)作者的Cassandra項目開發(fā)和項目實(shí)施經(jīng)驗，對NoSQL建模做一些概要性的指導(dǎo)。文章沒有具體的語法指導(dǎo)數(shù)據(jù)建模，這些問題請參考apache網(wǎng)站。 Cassandra已經(jīng)升級為apache組織的頂級項目。目前保持非常快的開發(fā)升級速度。Apache已經(jīng)放出1.0beta版本。不同版本的Cassandra具有不同的特性，因此，在開發(fā)的角度也可以采用不同的數(shù)據(jù)模型。

Cassandra模型可以用一個5維數(shù)組表示，相對應(yīng)keyspace、ColumnFamily（SuperColumns）、Key、Columnes、Value這5個維度。在獲取數(shù)據(jù)采用get語法，以get key為最大獲取數(shù)據(jù)維度，columns為最小獲取數(shù)據(jù)維度。

獲取數(shù)據(jù)可以這樣理解：由于Key值索引是缺省索引，只支持精確查找。如果我們希望最快速的找出一個班的學(xué)生，最簡單的方法是以班級代碼為Key建模。如果我們希望最快速的找出一個年級的學(xué)生，當(dāng)然以年級代碼為Key建模。

這樣的解決方式會帶來一個問題。在以關(guān)系型數(shù)據(jù)庫為主的各種應(yīng)用中，我們習(xí)慣了使用條件語句查找數(shù)據(jù)，從整個數(shù)據(jù)集中獲取需要的數(shù)據(jù)。如：where年級="3"或where班級="302"。SQL可以簡潔的建立應(yīng)用的模型。而Cassandra似乎不能這樣。

實(shí)際情況也確實(shí)如此。在Cassandra 0.6版本時，除非使用代碼，否則很難像SQL一樣方便解決這個簡單的問題。如果僅這樣思考問題，同樣也說明我們還在使用SQL的經(jīng)驗和方式來思考。關(guān)系型數(shù)據(jù)庫應(yīng)用系統(tǒng)經(jīng)驗如：3個經(jīng)典范式，甚至PK、FK、字典表、schema等無一不主導(dǎo)思維。所以，我們需要改變這種思維。

Cassandra不是關(guān)系型數(shù)據(jù)庫，其CF的設(shè)計大約是以一類查詢?yōu)榛�礎(chǔ)。這個觀點(diǎn)有兩層理解：1、以應(yīng)用的角度來考慮數(shù)據(jù)存儲；2、數(shù)據(jù)模型關(guān)鍵是在第二級，也就是ColumnFamily。例如：查詢一個年級的學(xué)生，就應(yīng)該以年級為CF來組織數(shù)據(jù)；查詢一個班級的學(xué)生，就應(yīng)該以班級為CF來組織數(shù)據(jù)。

看起來這非常的不可思議。對于具備豐富SQL經(jīng)驗的人確實(shí)如此（感同身受）。在做系統(tǒng)概要設(shè)計時，為什么用NoSql技術(shù)而不用SQL數(shù)據(jù)庫？最簡單的理由是SQL數(shù)據(jù)庫不能勝任。由于SQL數(shù)據(jù)庫在大數(shù)據(jù)量時維護(hù)復(fù)雜的數(shù)據(jù)約束關(guān)系導(dǎo)致性能上的巨大開銷，影響了業(yè)務(wù)。

以上只是一個簡單的案例，不需要過于。在使用NoSql數(shù)據(jù)庫前，我們應(yīng)該好好反省根深蒂固的SQL數(shù)據(jù)庫+OLTP型應(yīng)用的思維方式。NoSQL領(lǐng)域有一個CAP理論：一個分布式系統(tǒng)不能同時滿足一致性，可用性和分區(qū)容錯性這三個需求，最多只能同時滿足兩個。

這個理論面臨各種猜疑和壓力，但在沒有更好的理論支持前，暫且用著也無妨。Cassandra在這個理論中被標(biāo)記為A+P，即可用性和分區(qū)容忍性。可用性（Availability）：每一個操作總是能夠在確定的時間內(nèi)返回，也就是系統(tǒng)隨時都是可用的。分區(qū)容忍性（Partition Tolerance）： 在出現(xiàn)網(wǎng)絡(luò)分區(qū)（比如斷網(wǎng)）的情況下，分離的系統(tǒng)也能正常運(yùn)行（這些思想在SQL中也很難理解）。

不同的應(yīng)用有不同的側(cè)重點(diǎn)。傳統(tǒng)OLTP型應(yīng)用中，我們必須ACID特性。而在非交易型的分布式系統(tǒng)，我們的點(diǎn)是在系統(tǒng)的可用性上，如系統(tǒng)的部分節(jié)點(diǎn)宕機(jī)，仍需要保證業(yè)務(wù)的可用性。這里有個專業(yè)的術(shù)語描述“BASE”。

隨著Cassandra的不斷完善和升級，我們在處理數(shù)據(jù)模型上也就較大的自由度。Cassandra 0.7相比較以前的版本，除了bug修復(fù)和性能的提高，還有一個最重要的更新就是2級索引。Key索引為一級索引，column索引為二級索引。同樣的問題。采用2級索引可以更方便的解決。

在Cassandra 0.7中，對列值（column values）的索引叫做“二級索引”，它與列簇（ColumnFamilies）中對Key的索引不同。二級索引允許我們對值進(jìn)行查詢，并且在后臺自動建立，不會引起讀寫阻塞。二級索引可以使用范圍查詢。這樣，我們可以改良原始方案。可以使用更直觀的、維護(hù)和編程一致的解決方案。

在使用二級索引時，需要注意：在所謂的primary（主要描述）數(shù)據(jù)集中使用一個嵌套循環(huán)過濾。意味著在查詢語句中不能只使用一個索引條件如：班級>302 ，否則只會得到：No indexed columns present in index clause with operator EQ 。

在使用二級索引時，需要增加一個主要描述索引。如增加一個年級索引，使用條件where 年級= "3" and 班級 > 302；這個案例似乎不大好理解。從另一個角度上來看二級索引其實(shí)是取出所有滿足等式的數(shù)據(jù)集，再循環(huán)遍歷。以前需要寫代碼解決的事情，現(xiàn)在只需要建立索引就能搞定。

對于Cassandra模型的理解，可以讓我們更優(yōu)雅的解決應(yīng)用開發(fā)的問題。通常，Cassandra只能提供對key的確定值查詢。如果需要對key進(jìn)行范圍查詢呢？有兩個方法：1、修改模型，將key維度下沉到column維度，然后建二級索引查詢；2、數(shù)據(jù)分布策略中，如果采用有序的分布策略如： OrderPreservingPartitioner等，就可以使用Key的范圍查詢。

數(shù)據(jù)建模不僅僅受開發(fā)工具影響，還需要考慮應(yīng)用的類型。OLAP型應(yīng)用比OLTP型應(yīng)用更多地使用冗余的數(shù)據(jù)模型。一個原因是描述同一個對象的粒度不同，還有一個原因是以空間代價換取時間代價。所以在Cassandra建模的過程中也應(yīng)該考慮這些因素。

在不久的將來，云計算一定會徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏云計算，及時獲取人工智能、大數(shù)據(jù)、云計算和物聯(lián)網(wǎng)的前沿資訊和基礎(chǔ)知識，讓我們一起攜手，引領(lǐng)人工智能的未來！

標(biāo)簽： 大數(shù)據(jù) 代碼 數(shù)據(jù)庫 網(wǎng)絡(luò) 云計算

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。