摘要:本文通過(guò)一個(gè)簡(jiǎn)單的實(shí)例詳細(xì)介紹了Cassandra數(shù)據(jù)建模的五個(gè)步驟。以下是譯文。
我們最近在Instaclustr發(fā)表了一篇有關(guān)在Cassandra中經(jīng)常出現(xiàn)的數(shù)據(jù)建模錯(cuò)誤的文章。這篇文章非常受歡迎,并促使我思考如何設(shè)計(jì)出高質(zhì)量的Cassandra數(shù)據(jù)模型,以避免在設(shè)計(jì)的過(guò)程中掉入陷阱。
在互聯(lián)網(wǎng)上,你可以找到很多有關(guān)適配數(shù)據(jù)模型設(shè)計(jì)規(guī)則和設(shè)計(jì)模式的優(yōu)秀文章,例如:Apache Cassandra數(shù)據(jù)建模指南和數(shù)據(jù)建模優(yōu)秀實(shí)踐 。
然而,我們并沒(méi)有一個(gè)詳細(xì)的操作步驟來(lái)指導(dǎo)你對(duì)數(shù)據(jù)進(jìn)行分析,并適配相應(yīng)的規(guī)則和模式。但這份白皮書(shū)正嘗試著填補(bǔ)這方面的空白。
第一階段:了解數(shù)據(jù)
這個(gè)階段有兩個(gè)步驟,這兩個(gè)步驟都是為了更好地理解你正在建模的數(shù)據(jù)和所需的訪問(wèn)模式。
定義數(shù)據(jù)域
第一步是深入理解數(shù)據(jù)域。作為一個(gè)非常熟悉關(guān)系數(shù)據(jù)建模的人,我傾向于通過(guò)繪制ER圖來(lái)理解這些實(shí)體、主鍵和互相之間的關(guān)系。但是,如果你熟悉另一種標(biāo)記法,你也可以用一下試試。你需要在邏輯層面理解以下關(guān)鍵點(diǎn):
數(shù)據(jù)模型中的實(shí)體(或?qū)ο螅┦鞘裁矗?/p>
實(shí)體的主要關(guān)鍵屬性是什么?
實(shí)體之間有哪些關(guān)系(即從一個(gè)到另一個(gè)的引用)?
關(guān)系的相對(duì)基數(shù)是多少(例如,假設(shè)存在一對(duì)多的關(guān)系,那么平均是1對(duì)10,還是1對(duì)10000)?
定義所需的訪問(wèn)模式
下一步,弄清楚你自己需要如何訪問(wèn)數(shù)據(jù):
列出需要訪問(wèn)數(shù)據(jù)的路徑,例如:
以客戶(hù)ID為索引,在某個(gè)日期范圍內(nèi)搜索交易記錄,然后從搜索結(jié)果中搜索特定交易的詳細(xì)信息。按某個(gè)特定的服務(wù)器和度量標(biāo)準(zhǔn)搜索,檢索x度量值,按年齡升序排列。
按某個(gè)特定的服務(wù)器和度量檢索,從特定時(shí)間點(diǎn)開(kāi)始檢索x度量值。
對(duì)于給定的傳感器,檢索給定日期的多個(gè)度量的所有讀數(shù)。
對(duì)于給定的傳感器,檢索當(dāng)前值。
請(qǐng)記住,對(duì)記錄的任何更新操作都是一個(gè)訪問(wèn)路徑,都需要仔細(xì)考慮。
從性能的角度來(lái)確定哪些訪問(wèn)最關(guān)鍵。是否有一些訪問(wèn)需要盡可能快的速度,而其他一些訪問(wèn)則需要花一定的時(shí)間進(jìn)行多次讀取或在一定范圍內(nèi)進(jìn)行檢索?
請(qǐng)記住,在這個(gè)階段,你需要非常全面地了解如何訪問(wèn)數(shù)據(jù),在Cassandra的性能、可靠性和可伸縮性之間做出權(quán)衡。
第二階段:了解實(shí)體
這個(gè)階段有兩個(gè)具體的步驟,旨在了解與數(shù)據(jù)相關(guān)的主要和次要實(shí)體。
確定主要訪問(wèn)實(shí)體
現(xiàn)在,我們開(kāi)始從分析數(shù)據(jù)域和應(yīng)用需求轉(zhuǎn)為開(kāi)始設(shè)計(jì)數(shù)據(jù)模型了。在進(jìn)入這個(gè)階段之前,你需要把上面兩個(gè)步驟的工作做得扎實(shí)一點(diǎn)。
這一階段主要的想法是根據(jù)你所使用的訪問(wèn)模式將數(shù)據(jù)去規(guī)范化到盡可能少的表中。對(duì)于每一次按鍵進(jìn)行的查詢(xún),需要有一張表來(lái)滿足查詢(xún)需求。我創(chuàng)造了一個(gè)術(shù)語(yǔ)“主要訪問(wèn)實(shí)體”來(lái)描述用于查詢(xún)的實(shí)體(例如,按客戶(hù)ID進(jìn)行的查找將使用客戶(hù)表作為主要訪問(wèn)實(shí)體,按服務(wù)器和度量名稱(chēng)的查找將使用服務(wù)器-度量實(shí)體作為主要訪問(wèn)實(shí)體)。
主要訪問(wèn)實(shí)體定義了去規(guī)范化結(jié)果表的分區(qū)級(jí)別(即表會(huì)為每個(gè)主要訪問(wèn)實(shí)體的實(shí)例提供一個(gè)分區(qū))。
你可以選擇使用二級(jí)索引來(lái)滿足一些訪問(wèn)模式,而不是使用不同的主要訪問(wèn)實(shí)體來(lái)實(shí)現(xiàn)數(shù)據(jù)復(fù)制。請(qǐng)記住,包含在輔助索引中的列應(yīng)比被索引的表的基數(shù)更低,并且你要對(duì)索引值的更新頻率了如指掌。
對(duì)于上面舉的訪問(wèn)模式的例子,我們將定義以下主要訪問(wèn)實(shí)體:
客戶(hù)和交易(從客戶(hù)實(shí)體獲取交易清單,然后從交易實(shí)體查找交易詳情)
服務(wù)器-度量
傳感器
傳感器
分配次要實(shí)體
下一步是尋找一個(gè)地方用來(lái)存儲(chǔ)那些沒(méi)有被選為主要訪問(wèn)實(shí)體的實(shí)體數(shù)據(jù)(這些實(shí)體被稱(chēng)為次要實(shí)體)。你可以這樣做:
通過(guò)從一對(duì)多關(guān)系的父級(jí)次要實(shí)體獲取數(shù)據(jù)并在主要訪問(wèn)實(shí)體級(jí)別存儲(chǔ)它的多個(gè)副本(例如,將客戶(hù)的電話號(hào)碼存儲(chǔ)在客戶(hù)的訂單記錄中)。
通過(guò)從一對(duì)多關(guān)系的子次要實(shí)體獲取數(shù)據(jù)并通過(guò)使用聚集鍵或通過(guò)使用多值類(lèi)型(列表和映射)將其存儲(chǔ)在主要訪問(wèn)實(shí)體級(jí)別上(例如,將記錄項(xiàng)列表添加到交易表中)。
對(duì)于一些次要實(shí)體,只有一個(gè)相關(guān)的主要訪問(wèn)實(shí)體,所以不需要選擇在哪個(gè)方向推入數(shù)據(jù)。對(duì)于其他實(shí)體,你需要選擇將數(shù)據(jù)推入哪些主要訪問(wèn)實(shí)體。
為了獲得最佳的讀取性能,需要將數(shù)據(jù)副本推送到用作次要實(shí)體中數(shù)據(jù)訪問(wèn)路徑的每個(gè)主要訪問(wèn)實(shí)體中。
然而,維護(hù)多個(gè)副本數(shù)據(jù)會(huì)影響到數(shù)據(jù)插入和更新的性能,并會(huì)增加應(yīng)用程序的復(fù)雜性。因此,需要根據(jù)應(yīng)用程序指定的性能要求在讀取性能與數(shù)據(jù)維護(hù)成本之間做出權(quán)衡。
在這個(gè)階段要做出的另一個(gè)決定是要選擇使用聚集鍵還是多值類(lèi)型來(lái)進(jìn)行數(shù)據(jù)推升。一般來(lái)說(shuō):
在只有一個(gè)子次要實(shí)體向上推升的情況下使用聚集鍵,特別是在子次要實(shí)體本身有子節(jié)點(diǎn)上卷的情況下。
在有多個(gè)子實(shí)體推升到主要實(shí)體的時(shí)候使用多值類(lèi)型
請(qǐng)注意,這些規(guī)則可能比較簡(jiǎn)單,但它們可以引申出對(duì)這方面更深入的思考。
第三階段:審核與調(diào)優(yōu)
最后一個(gè)階段則是在必要的情況下對(duì)數(shù)據(jù)模型進(jìn)行審核、測(cè)試,以及調(diào)優(yōu)。
審核分區(qū)和聚集鍵
在這個(gè)階段中,你需要將所有需要存儲(chǔ)的數(shù)據(jù)分配到一個(gè)或多個(gè)表中,并且這些表需要支持所需的訪問(wèn)模式。下一步是檢查生成的數(shù)據(jù)模型是否有效地使用了Cassandra,如果沒(méi)有,則進(jìn)行調(diào)優(yōu)。在這個(gè)階段,需要檢查和調(diào)整的內(nèi)容包括:
分區(qū)鍵是否有足夠的基數(shù)?如果沒(méi)有,則可能需要將列從聚集鍵變?yōu)榉謪^(qū)鍵(例如,將主鍵(client_id,timestamp)更改為主鍵((client_id,timestamp)))或引入將多個(gè)聚集鍵分組為分區(qū)的新列(例如,將主鍵(client_id,timestamp)更改為主鍵((client_id,day),timestamp))。
分區(qū)鍵中的值是否會(huì)經(jīng)常更新?對(duì)主鍵的更新將導(dǎo)致記錄的刪除和重新插入。例如,在一個(gè)維護(hù)了所有客戶(hù)的狀態(tài)的表中,可能有主鍵(狀態(tài),客戶(hù)ID)。但是,這將導(dǎo)致每當(dāng)客戶(hù)狀態(tài)發(fā)生變化時(shí)都需要?jiǎng)h除并重新插入記錄。在這種情況下,最好選擇集合或列表數(shù)據(jù)類(lèi)型,而不是將客戶(hù)ID作為聚集鍵。
每個(gè)分區(qū)中的記錄數(shù)是否有限制?特別大的分區(qū)和或者分布非常不均勻的分區(qū)可能會(huì)出現(xiàn)問(wèn)題。例如,假設(shè)有一張client_updates表,其主鍵為(client_id,update_timestamp),則客戶(hù)記錄的更新次數(shù)可能并沒(méi)有限制,因?yàn)榭赡苡猩倭康目蛻?hù)已經(jīng)有10年未更新,而大多數(shù)客戶(hù)只有一兩天而已。
測(cè)試和調(diào)優(yōu)
最后一步,也可能是最重要的,即對(duì)數(shù)據(jù)模型進(jìn)行測(cè)試,并根據(jù)需要進(jìn)行調(diào)優(yōu)。請(qǐng)記住,像分區(qū)或記錄數(shù)增長(zhǎng)過(guò)快的問(wèn)題只有在實(shí)際負(fù)載下使用幾天(或更長(zhǎng)時(shí)間)之后才能發(fā)現(xiàn)。因此,測(cè)試的時(shí)候需要盡可能地接近真實(shí)負(fù)載,并密切監(jiān)視各種警告信息(nodetool cfstats和cfhistograms命令對(duì)此非常有用)。
在這個(gè)階段,你也可以考慮調(diào)整一些影響數(shù)據(jù)物理存儲(chǔ)的設(shè)置。例如:
改變壓縮策略;
如果只使用TTL來(lái)刪除數(shù)據(jù)的話,則可以降低gc_grace_seconds,或者
設(shè)置緩存選項(xiàng)。
一個(gè)完整的例子
為了說(shuō)明這一點(diǎn),下文將介紹一個(gè)示例,該示例構(gòu)建了一個(gè)數(shù)據(jù)庫(kù),用于存儲(chǔ)和檢索來(lái)自多個(gè)服務(wù)器的日志消息。請(qǐng)注意,與大多數(shù)實(shí)際的案例相比,這個(gè)例子非常簡(jiǎn)單。
步驟1:定義數(shù)據(jù)域
上面的ER圖描述了本示例的數(shù)據(jù)域,包括:
有很多(百萬(wàn)數(shù)量級(jí))的日志消息,有時(shí)間戳和主體。盡管消息ID在ER圖中顯示為主鍵,但消息時(shí)間加消息類(lèi)型是備用主鍵。
每個(gè)日志消息都有一個(gè)消息類(lèi)型,多個(gè)類(lèi)型被進(jìn)一步分組為一個(gè)消息類(lèi)別(例如,消息類(lèi)型可能是“內(nèi)存不足錯(cuò)誤”,類(lèi)別可能是“錯(cuò)誤”)。有幾百個(gè)消息類(lèi)型和大約20個(gè)類(lèi)別。
每個(gè)日志消息來(lái)自一個(gè)消息源。消息源是生成消息的服務(wù)器。我們的系統(tǒng)中有1000臺(tái)服務(wù)器。每個(gè)消息源都有一個(gè)源類(lèi)型對(duì)其進(jìn)行分類(lèi)(如紅帽服務(wù)器、Ubuntu服務(wù)器、Windows服務(wù)器、路由器等)。有大約20個(gè)源類(lèi)型。每個(gè)源每天有大約10000條消息。
消息體可以被解析并存儲(chǔ)為多個(gè)消息體(一般來(lái)說(shuō)是鍵值對(duì))。每條消息通常不超過(guò)20個(gè)消息體。
步驟2:定義所需的訪問(wèn)模式
我們需要能夠:
檢索給定源的最近10條消息的所有可用信息(并且能夠從中及時(shí)回溯)。
檢索給定源類(lèi)型的最近10條消息的所有可用信息。
步驟3:確定主要訪問(wèn)實(shí)體
這里有兩個(gè)主要訪問(wèn)實(shí)體:源和源類(lèi)型。源類(lèi)型的基數(shù)(約為20)使其非常適合成為二級(jí)索引,所以我們將使用源作為主要訪問(wèn)實(shí)體,并添加源類(lèi)型為二級(jí)索引。
步驟4:分配次要實(shí)體
在這個(gè)例子中,這個(gè)步驟相對(duì)簡(jiǎn)單,因?yàn)樗袛?shù)據(jù)都需要滾入到日志源主要訪問(wèn)實(shí)體中。所以我們需要:
下推源類(lèi)型名稱(chēng)
下推消息類(lèi)別和消息類(lèi)型以記錄消息
上推日志消息,使其作為新實(shí)體的聚集鍵
作為map類(lèi)型上推消息體。
最終這將是一個(gè)帶有源ID分區(qū)鍵和(消息時(shí)間,消息類(lèi)型)聚集鍵的單個(gè)表。
步驟5:審核分區(qū)和聚集鍵
根據(jù)檢查清單檢查這些分區(qū)和聚集鍵:
分區(qū)鍵是否有足夠的基數(shù)?是的,有1000個(gè)源。
分區(qū)鍵中的值是否會(huì)經(jīng)常更新?不,所有的數(shù)據(jù)都是一次寫(xiě)入的。
每個(gè)分區(qū)中的記錄數(shù)是否有限制?不,消息數(shù)可能會(huì)隨著時(shí)間的推移而無(wú)限地增長(zhǎng)。所以,我們需要解決無(wú)限分區(qū)大小的問(wèn)題。在時(shí)間序列數(shù)據(jù)中,解決這個(gè)問(wèn)題的典型模式是將一組時(shí)間段引入到聚集鍵中。在這種情況下,每天10000條消息是一個(gè)比較合理的數(shù)字,可以包含在一個(gè)分區(qū)中,因此我們將使用“天”作為分區(qū)鍵的一部分。
最后,Cassandra結(jié)果表是這樣的:
CREATETABLEexample.log_messages ( message_id uuid, source_name text, source_type text, message_type text, message_urgencyint, message_category text, message_timetimestamp, message_time_day text, message_body text, message_parts map
?
評(píng)論
查看更多