摘要：本文通過一個簡單的實例詳細介紹了Cassandra數據建模的五個步驟。以下是譯文。

我們最近在Instaclustr發表了一篇有關在Cassandra中經常出現的數據建模錯誤的文章。這篇文章非常受歡迎，并促使我思考如何設計出高質量的Cassandra數據模型，以避免在設計的過程中掉入陷阱。

在互聯網上，你可以找到很多有關適配數據模型設計規則和設計模式的優秀文章，例如：Apache Cassandra數據建模指南和數據建模優秀實踐 。

然而，我們并沒有一個詳細的操作步驟來指導你對數據進行分析，并適配相應的規則和模式。但這份白皮書正嘗試著填補這方面的空白。

第一階段：了解數據

這個階段有兩個步驟，這兩個步驟都是為了更好地理解你正在建模的數據和所需的訪問模式。

定義數據域

第一步是深入理解數據域。作為一個非常熟悉關系數據建模的人，我傾向于通過繪制ER圖來理解這些實體、主鍵和互相之間的關系。但是，如果你熟悉另一種標記法，你也可以用一下試試。你需要在邏輯層面理解以下關鍵點：

數據模型中的實體（或對象）是什么？

實體的主要關鍵屬性是什么？

實體之間有哪些關系（即從一個到另一個的引用）？

關系的相對基數是多少（例如，假設存在一對多的關系，那么平均是1對10，還是1對10000）？

定義所需的訪問模式

下一步，弄清楚你自己需要如何訪問數據：

列出需要訪問數據的路徑，例如：

以客戶ID為索引，在某個日期范圍內搜索交易記錄，然后從搜索結果中搜索特定交易的詳細信息。按某個特定的服務器和度量標準搜索，檢索x度量值，按年齡升序排列。

按某個特定的服務器和度量檢索，從特定時間點開始檢索x度量值。

對于給定的傳感器，檢索給定日期的多個度量的所有讀數。

對于給定的傳感器，檢索當前值。

請記住，對記錄的任何更新操作都是一個訪問路徑，都需要仔細考慮。

從性能的角度來確定哪些訪問最關鍵。是否有一些訪問需要盡可能快的速度，而其他一些訪問則需要花一定的時間進行多次讀取或在一定范圍內進行檢索？

請記住，在這個階段，你需要非常全面地了解如何訪問數據，在Cassandra的性能、可靠性和可伸縮性之間做出權衡。

第二階段：了解實體

這個階段有兩個具體的步驟，旨在了解與數據相關的主要和次要實體。

確定主要訪問實體

現在，我們開始從分析數據域和應用需求轉為開始設計數據模型了。在進入這個階段之前，你需要把上面兩個步驟的工作做得扎實一點。

這一階段主要的想法是根據你所使用的訪問模式將數據去規范化到盡可能少的表中。對于每一次按鍵進行的查詢，需要有一張表來滿足查詢需求。我創造了一個術語“主要訪問實體”來描述用于查詢的實體（例如，按客戶ID進行的查找將使用客戶表作為主要訪問實體，按服務器和度量名稱的查找將使用服務器-度量實體作為主要訪問實體）。

主要訪問實體定義了去規范化結果表的分區級別（即表會為每個主要訪問實體的實例提供一個分區）。

你可以選擇使用二級索引來滿足一些訪問模式，而不是使用不同的主要訪問實體來實現數據復制。請記住，包含在輔助索引中的列應比被索引的表的基數更低，并且你要對索引值的更新頻率了如指掌。

對于上面舉的訪問模式的例子，我們將定義以下主要訪問實體：

客戶和交易（從客戶實體獲取交易清單，然后從交易實體查找交易詳情）

服務器-度量

傳感器

傳感器

分配次要實體

下一步是尋找一個地方用來存儲那些沒有被選為主要訪問實體的實體數據（這些實體被稱為次要實體）。你可以這樣做：

通過從一對多關系的父級次要實體獲取數據并在主要訪問實體級別存儲它的多個副本（例如，將客戶的電話號碼存儲在客戶的訂單記錄中）。

通過從一對多關系的子次要實體獲取數據并通過使用聚集鍵或通過使用多值類型（列表和映射）將其存儲在主要訪問實體級別上（例如，將記錄項列表添加到交易表中）。

對于一些次要實體，只有一個相關的主要訪問實體，所以不需要選擇在哪個方向推入數據。對于其他實體，你需要選擇將數據推入哪些主要訪問實體。

為了獲得最佳的讀取性能，需要將數據副本推送到用作次要實體中數據訪問路徑的每個主要訪問實體中。