（十二）—— 索引表模式

云計算設(shè)計模式（十二）——索引表模式

創(chuàng)建索引過的被查詢條件經(jīng)常被引用的數(shù)據(jù)存儲等領(lǐng)域。這種模式可以通過允許應(yīng)用程序更快速地定位數(shù)據(jù)來從數(shù)據(jù)存儲中檢索提高查詢性能。

背景和問題

許多數(shù)據(jù)存儲通過使用主鍵組織為實體的集合的數(shù)據(jù)。應(yīng)用程序可以使用此鍵來查找和檢索數(shù)據(jù)。圖 1 顯示了一個數(shù)據(jù)存儲區(qū)保持顧客的信息的例子。主鍵是客戶 ID。

圖1 - 按主鍵組織的客戶信息（客戶ID）

而主鍵是該取基于該關(guān)鍵字的值的數(shù)據(jù)的查詢寶貴的，應(yīng)用程序可能不能夠使用主鍵是否需要基于其它字段來檢索數(shù)據(jù)。在顧客例如，應(yīng)用程序不能使用該客戶ID主鍵來檢索客戶，如果它通過指定引用的一些其他屬性的值，如在其中客戶位于鎮(zhèn)標(biāo)準(zhǔn)查詢數(shù)據(jù)完全。要執(zhí)行一個查詢，如這可能需要申請獲取并檢查每一個客戶的記錄，這可能是一個緩慢的過程。

許多關(guān)系數(shù)據(jù)庫管理系統(tǒng)支持二級索引。一種二次指數(shù)是由一個或多個非主（輔助）鍵領(lǐng)域舉辦一個單獨的數(shù)據(jù)結(jié)構(gòu)，它表示，其中每個索引值的數(shù)據(jù)被存儲。在一第二索引的項目通常排序方法的第二個鍵的值，使數(shù)據(jù)的快速查找。這些指標(biāo)通常是由數(shù)據(jù)庫管理系統(tǒng)自動進(jìn)行維護(hù)。

由于需要支持您的應(yīng)用程序執(zhí)行不同的查詢，您可以創(chuàng)建任意多個二級指標(biāo)。例如，在一個關(guān)系數(shù)據(jù)庫中凡客ID是主鍵的表的客戶，也可能是有益的補充輔助指數(shù)在鎮(zhèn)域如果應(yīng)用程序頻繁查找的客戶在其居住的小鎮(zhèn)。

然而，盡管二級指標(biāo)是關(guān)系型系統(tǒng)的共同特征，使用云應(yīng)用大部分NoSQL數(shù)據(jù)存儲不提供同等的功能。

解決方案

如果數(shù)據(jù)存儲不支持??二級索引，你可以通過創(chuàng)建自己的索引表手動效仿他們。索引表由指定的鍵組織數(shù)據(jù)。三種策略通常用于構(gòu)建一個索引表，這取決于所需要的二次索引的數(shù)目和該應(yīng)用程序執(zhí)行的查詢的性質(zhì)：

重復(fù)數(shù)據(jù)的每個索引表中，而是由不同的密鑰（完全非規(guī)范化）組織它。圖2顯示了索引表的組織包括城市和姓氏相同的客戶信息：

圖2 - 索引表執(zhí)行二級指標(biāo)的客戶數(shù)據(jù)。數(shù)據(jù)被復(fù)制到每個索引表中。

如果比較的時候，它是通過使用每個鍵查詢的數(shù)目的數(shù)據(jù)是相對靜態(tài)的這一策略可能是適當(dāng)?shù)?。如果?shù)據(jù)是更加動態(tài)，保持每個索引表的處理開銷可能會變得太大，這種方法是有用的。此外，如果數(shù)據(jù)量非常大，空間來存儲重復(fù)的數(shù)據(jù)所需要的量將顯著。

創(chuàng)建由不同的密鑰組織的歸索引表和通過使用主鍵而不是重復(fù)它引用原始數(shù)據(jù)，如示于圖3中的原始數(shù)據(jù)被稱為一個事實表：

圖3 - 索引表執(zhí)行二級指標(biāo)的客戶數(shù)據(jù)。該數(shù)據(jù)是由每個索引表所引用。

這種技術(shù)可以節(jié)省空間，降低了維護(hù)的重復(fù)數(shù)據(jù)的開銷。的缺點是，一個應(yīng)用程序具有通過使用第二密鑰來執(zhí)行兩個查找操作以查找數(shù)據(jù)（找到的主鍵的索引表中的數(shù)據(jù)，然后查找在事實表中的數(shù)據(jù)通過使用主鍵）。

創(chuàng)建由重復(fù)的頻繁檢索的字段不同的按鍵組織的部分歸索引表。引用原始數(shù)據(jù)來訪問較少頻繁訪問的字段。圖4示出了這種結(jié)構(gòu)。

圖4 - 索引表執(zhí)行二級指標(biāo)的客戶數(shù)據(jù)。經(jīng)常訪問的數(shù)據(jù)是重復(fù)的每個索引表中。

使用這種技術(shù)，你可以前兩種方法之間取得平衡。可以快速地檢索到通過使用單個查找，常用的查詢數(shù)據(jù)，而空間和維護(hù)開銷是不一樣大，復(fù)制整個數(shù)據(jù)集。

如果應(yīng)用程序通過指定值的組合頻繁地查詢數(shù)據(jù)（例如，“查找生活在雷德蒙和具有史密斯的姓所有客戶”），則可以實現(xiàn)鍵的索引表中的項目作為一個級聯(lián)城市屬性和姓氏屬性的，如示于圖5中的鍵由鎮(zhèn)排序，然后通過名字為那些具有鎮(zhèn)相同的值的記錄。

圖5 - 基于復(fù)合主鍵索引表

索引表可以加快了分片的數(shù)據(jù)查詢操作，并在那里的碎片密鑰散列特別有用。圖 6 顯示了一個示例，其中分片密鑰是客戶 ID 的散列。索引表可以由非散列值（城市和名字）組織數(shù)據(jù)，并提供該哈希分片鍵作為查找數(shù)據(jù)。這樣可以節(jié)省從重復(fù)計算散列鍵的應(yīng)用（其可以是昂貴的操作），如果它需要檢索的數(shù)據(jù)落在一個范圍之內(nèi)，或者它需要讀取的數(shù)據(jù)，以便在非散列密鑰。例如，諸如“查找生活在雷德蒙所有客戶”可以由通過定位在索引表中的匹配項（其全部存儲在一個連續(xù)的塊），并按照引用的客戶數(shù)據(jù)盡快解決的查詢使用存儲在索引表中的碎片的鍵。

圖6 - 索引表中提供了快速查找的分片數(shù)據(jù)

問題和注意事項

在決定如何實現(xiàn)這個模式時，請考慮以下幾點：

• 保持輔助索引的開銷可能是顯著。你必須分析和了解，您的應(yīng)用程序使用的查詢。只創(chuàng)建他們很可能被經(jīng)常使用的索引表。不要投機創(chuàng)建索引的表，以支持應(yīng)用程序不執(zhí)行查詢，或者一個應(yīng)用程序只執(zhí)行非常偶然。
• 在索引表中復(fù)制的數(shù)據(jù)所用的存儲成本和維護(hù)數(shù)據(jù)的多個副本所需的工作條件添加顯著開銷。
• 執(zhí)行一個索引表，作為標(biāo)準(zhǔn)化的結(jié)構(gòu)，引用原始數(shù)據(jù)可能需要的應(yīng)用程序，以執(zhí)行兩個查找操作以查找數(shù)據(jù)。第一操作搜索索引表來檢索主鍵，第二個使用的主密鑰來獲取數(shù)據(jù)。
• 如果系統(tǒng)包含大量索引表在非常大的數(shù)據(jù)集，也可以是難以維持索引表和原始數(shù)據(jù)之間的一致性。有可能設(shè)計圍繞最終一致性模型的應(yīng)用。例如，插入，更新或刪除數(shù)據(jù)，一個應(yīng)用程序可以發(fā)送一條消息給一個隊列，并讓一個獨立的任務(wù)執(zhí)行操作和維護(hù)引用該數(shù)據(jù)不同步的索引表。有關(guān)實現(xiàn)最終一致性的更多信息，請參閱數(shù)據(jù)一致性底漆。

注意： 微軟 Azure 存儲表支持事務(wù)更新到同一個分區(qū)中保存的數(shù)據(jù)進(jìn)行更改（簡稱實體組的事務(wù)）。如果你可以存儲一個事實表和在同一個分區(qū)的一個或多個索引表中的數(shù)據(jù)，您可以使用此功能來幫助確保一致性。

索引表可以自行進(jìn)行分區(qū)或分片。

何時使用這個模式

使用這種模式來提高查詢性能，當(dāng)應(yīng)用程序經(jīng)常需要使用一鍵以外的主（或子庫）鍵來檢索數(shù)據(jù)。

這種模式可能不適合時：

• 數(shù)據(jù)是不穩(wěn)定的。索引表可能變得過時的速度非常快，使其無效，或者使保持在索引表大于用它制成的任何節(jié)省的開銷。
• 選作索引表中的二級密鑰的場是非常不鑒別，只能有一個小的值的集合（例如，性別）。
• 數(shù)據(jù)值的選擇為一個索引表中的二級密鑰的場的平衡是高度傾斜。例如，如果 90％ 的記錄中包含相同的值中的一個字段，然后創(chuàng)建和維護(hù)一個索引表中查找基于該字段中的數(shù)據(jù)可以施加更大的開銷比通過數(shù)據(jù)掃描順序。然而，如果查詢非常頻繁地針對位于對剩余的 10％ 的值，該索引可以是有用的。你必須明白的疑問，您的應(yīng)用程序正在執(zhí)行，以及如何他們經(jīng)常執(zhí)行。

例子

Azure 存儲表在云中運行的應(yīng)用程序提供了一個高度可擴展的鍵/值數(shù)據(jù)存儲。應(yīng)用程序存儲，并通過指定一個鍵檢索數(shù)據(jù)值。的數(shù)據(jù)值可以包含多個字段，但一個數(shù)據(jù)項的結(jié)構(gòu)是不透明的表存儲，這僅僅處理一個數(shù)據(jù)項作為一個字節(jié)數(shù)組。

Azure 存儲表還支持分片。分片密鑰包括兩個元件，一個分區(qū)鍵和行密鑰。有相同的分區(qū)鍵的數(shù)據(jù)項都存儲在同一分區(qū)（碎片），并且項目被存儲在一個子庫中排鍵順序。表存儲優(yōu)化用于執(zhí)行獲取數(shù)據(jù)下降分區(qū)中的連續(xù)范圍的行鍵值范圍內(nèi)的查詢。如果您正在構(gòu)建存儲在 Azure 的表的信息的云應(yīng)用，你應(yīng)該組織你的數(shù)據(jù)在考慮這個功能。

例如，考慮存儲有關(guān)電影的信息的應(yīng)用程序。應(yīng)用程序經(jīng)常按流派查詢電影（動作片，紀(jì)錄片，歷史，喜劇，戲劇，等等）。可以通過使用類型作為分區(qū)鍵，并指定電影的名稱作為行密鑰創(chuàng)建一個天青表的分區(qū)的每個類型，如圖7。

圖7 - 存儲在 Azure Table 中的電影數(shù)據(jù)，按流派劃分和排序的電影名稱

這種方法不太有效，如果該應(yīng)用程序還需要通過演員主演查詢電影。在這種情況下，你可以創(chuàng)建一個單獨的Azure表作為一個索引表。分區(qū)鍵是演員和行關(guān)鍵是電影的名字。對于每個演員的數(shù)據(jù)將被存儲在單獨的分區(qū)。如果一個電影明星不止一個演員，同一部電影會出現(xiàn)在多個分區(qū)。

可以通過采用上面的解決方案部分中所述的第一種方式重復(fù)在每個分區(qū)中保存的值的電影數(shù)據(jù)。然而，很可能是每個影片將（對于每個演員一次）重復(fù)幾次，所以它可能是更有效的，以部分非規(guī)范化，以支持最常見的查詢（如其他演員的姓名）的數(shù)據(jù)，并實現(xiàn)一個應(yīng)用程序由包括必要找到在體裁分區(qū)的完整信息，分區(qū)鍵來檢索任何剩余的細(xì)節(jié)。這種方法是通過在解決方案部分中的第三項中的說明。圖8描述了這種方法。

圖8 - 演員分區(qū)作為索引表的影像數(shù)據(jù)