NoSQL數據建模技術

本文節譯自NoSQL Data Modeling Techniques。

NoSQL數據建模中的一般問題

作爲前言，首先提出一些NoSQL建模中的一般化問題：

• 與關係建模不同，NoSQL數據建模通常從應用程序查詢的角度來建模：

  • 關係建模的方式通常是由數據的結構來決定的，設計的主題是：「我能回答什麼問題？」

  • NoSQL建模的方式則是由數據訪問方式決定（例如要支持哪些查詢），設計的主題是：「我能提出什麼問題？」

• NoSQL建模通常需要對數據結構和算法有更深的理解。本文中，我們將探討一些雖然不是針對NoSQL，但是在NoSQL中很實用的數據結構。

• 數據的冗餘和反範式化是很重要的。

儘管數據建模技術是沒有定式的，但對於特定的系統來說，本文將給出一些思路。

概念性技術

1. 反範式化

反範式化可以被定義爲多個文檔/表擁有相同的數據副本，以使查詢處理變得更簡單高效。

2. 聚集

主流的NoSQL數據庫均對模式（schema）沒有很強的限制：

• Key-Value存儲通常不對存儲的值有約束，因此值可以是任意的格式。此外，一個業務實體也可以佔用多條記錄。例如，用戶賬戶可以這樣建模：以UserID_name, UserID_email這樣的名稱作爲key。
• 文檔型數據庫通常則是固有的schema-less。

這樣的設計允許實用複雜的內部結構來構建實體，主要包括兩方面：

• 最小化一對多的關係（通過嵌套實體），這樣，就會減少連接操作。
• 隱藏了異構的業務實體間的不同。

我們可以用如下這張圖來展示。這副圖對產品實體進行了建模。首先，我們說，所有的產品都有ID，價格和描述。接下來，我們發現不同類型的產品擁有不同的屬性，例如書籍的作者和褲子的長度。有些屬性是一對多或者多對多的，例如唱片中的曲目等。接下來，我們發現，有些實體難以用固定的屬性建模，例如褲子的屬性取決於品牌。雖然在關係數據庫中，這些模型都是能建出來的，但顯然不如NoSQL簡潔。

3. 應用程序端連接

NoSQL解決方案中幾乎不支持連接。作爲「問題驅動」的NoSQL設計，連接通常在設計時就被考慮好了，使用之前描述的反範式化和聚集就可以解決這個問題。當然，有些時候，連接還是無法避免，此時應該由應用程序處理。

一般建模技術

4. 原子聚集

很多NoSQL的解決方案都缺乏對事務的支持。在一些情形中，可以通過使用分佈式鎖或使用應用程序級別的MVCC來實現事務特性。但通常都是使用上文提到的聚集的特性來保證部分ACID特性。

5. 可枚舉鍵

無序的Key-Value模型有一個很大的優點：數據可以通過對key的hash，分佈放在多個服務器上。有序模型更復雜，但有時候有序的鍵對應用程序來說更有用。考慮下面這個例子：

• 一些NoSQL存儲提供原子計數器，可以用來產生ID序列。可以用複合key：userID_messageID存儲消息。如果我們知道了最新消息的ID，那麼就可以向前遍歷所有的消息。

• 也可以利用這樣的特性對消息分組，例如按日期分組。

6. 降維

降維是一項把多維數據映射到Key-Value模型或者其他非多維模型的技術。

傳統的地理信息系統使用四叉樹或者R-樹及其變種作爲索引。這些結構需要原地更新，並且當數據量很大的時候也會遇到困難。一個方法是，遍歷二維的結構，並將其轉化爲一個一維的列別。這項技術中比較有名的方法叫做Geohash。如下圖所示：

7. 索引表

這項技術主要使用在大表數據庫中，看圖就好：