雲端運算設計模式（十二）——索引表模式

標籤：

 

建立索引過的被查詢條件經常被引用的資料存放區等領域。這種模式可以通過允許應用程式更快速地定位元據來從資料存放區中檢索提高查詢效能。

背景和問題

許多資料存放區通過使用主鍵組織為實體的集合的資料。應用程式可以使用此鍵來尋找和檢索資料。圖1顯示了一個資料存放區區保持顧客的資訊的例子。主鍵是客戶ID。

圖1  - 按主鍵組織的客戶資訊（客戶ID） 


而主鍵是該取基於該關鍵字的值的資料的查詢寶貴的，應用程式可能不能夠使用主鍵是否需要基於其它欄位來檢索資料。在顧客例如，應用程式不能使用該客戶ID主鍵來檢索客戶，如果它通過指定引用的一些其他屬性的值，如在其中客戶位於鎮標準查詢資料完全。要執行一個查詢，如這可能需要申請擷取並檢查每一個客戶的記錄，這可能是一個緩慢的過程。 

許多關聯式資料庫管理系統支援二級索引。一種二次指數是由一個或多個非主（輔助）鍵領域舉辦一個單獨的資料結構，它表示，其中每個索引值的資料被儲存。在一第二索引的項目通常排序方法的第二個鍵的值，使資料的快速尋找。這些指標通常是由資料庫管理系統自動進行維護。 

由於需要支援您的應用程式執行不同的查詢，您可以建立任意多個二級指標。例如，在一個關聯式資料庫中凡客ID是主鍵的表的客戶，也可能是有益的補充輔助指數在鎮域如果應用程式頻繁尋找的客戶在其居住的小鎮。 

然而，儘管二級指標是關係型系統的共同特徵，使用雲應用大部分NoSQL資料存放區不提供同等的功能。 

解決方案

如果資料存放區不支援??二級索引，你可以通過建立自己的索引表手動效仿他們。索引表由指定的鍵組織資料。三種策略通常用於構建一個索引表，這取決於所需要的二次索引的數目和該應用程式執行的查詢的性質： 
•重複資料的每個索引表中，而是由不同的密鑰（完全非正常化）組織它。圖2顯示了索引表的組織包括城市和姓氏相同的客戶資訊：

圖2 - 索引表執行二級指標的客戶資料。資料被複製到每個索引表中。 


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

•建立由不同的密鑰組織的歸索引表和通過使用主鍵而不是重複它引用未經處理資料，如示於圖3中的未經處理資料被稱為一個事實表：

圖3 - 索引表執行二級指標的客戶資料。該資料是由每個索引表所引用。 


這種技術可以節省空間的，降低了維護的重複資料的開銷。的缺點是，一個應用程式具有通過使用第二密鑰來執行兩個尋找操作以尋找資料（找到的主鍵的索引表中的資料，然後尋找在事實表中的資料通過使用主鍵）。 

•建立由重複的頻繁檢索的欄位不同的按鍵組織的部分歸索引表。引用未經處理資料來訪問較少頻繁訪問的欄位。圖4示出了這種結構。

圖4 - 索引表執行二級指標的客戶資料。經常訪問的資料是重複的每個索引表中。 


使用這種技術，你可以前兩種方法之間取得平衡。可以快速地檢索到通過使用單個尋找，常用的查詢資料，而空間和維護開銷是不一樣大，複製整個資料集。 


如果應用程式通過指定值的組合頻繁地查詢資料（例如，“尋找生活在雷德蒙和具有史密斯的姓所有客戶”），則可以實現鍵的索引表中的項目作為一個級聯城市屬性和姓氏屬性的，如示於圖5中的鍵由鎮排序，然後通過名字為那些具有鎮相同的值的記錄。

圖5 - 基於複合主鍵索引表 


索引表可以加快了分區的資料查詢操作，並在那裡的片段密鑰散列特別有用。圖6顯示了一個樣本，其中分區密鑰是客戶ID的散列。索引表可以由非散列值（城市和名字）組織資料，並提供該雜湊分區鍵作為尋找資料。這樣可以節省從重複計算散列鍵的應用（其可以是昂貴的操作），如果它需要檢索的資料落在一個範圍之內，或者它需要讀取的資料，以便在非散列密鑰。例如，諸如“尋找生活在雷德蒙所有客戶”可以由通過定位在索引表中的匹配項（其全部儲存在一個連續的塊），並按照引用的客戶資料儘快解決的查詢使用儲存在索引表中的片段的鍵。

 

圖6  - 索引表中提供了快速尋找的分區資料 

問題和注意事項

在決定如何?這個模式時，請考慮以下幾點： 
•保持輔助索引的開銷可能是顯著。你必須分析和瞭解，您的應用程式使用的查詢。只建立他們很可能被經常使用的索引表。不要投機建立索引的表，以支援應用程式不執行查詢，或者一個應用程式只執行非常偶然。 
•在索引表中複製的資料所用的儲存成本和維護資料的多個副本所需的工作條件添加顯著開銷。 
•執行一個索引表，作為標準化的結構，引用未經處理資料可能需要的應用程式，以執行兩個尋找操作以尋找資料。第一操作搜尋索引表來檢索主鍵，第二個使用的主要金鑰來擷取資料。 
•如果系統包含大量索引表在非常大的資料集，也可以是難以維持索引表和未經處理資料之間的一致性。有可能設計圍繞最終一致性模型的應用。例如，插入，更新或刪除資料，一個應用程式可以發送一條訊息給一個隊列，並讓一個獨立的任務執行操作和維護引用該資料不同步的索引表。有關實現最終一致性的更多資訊，請參閱資料一致性底漆。 


注意： 

微軟Azure儲存表支援事務更新到同一個分區中儲存的資料變更（簡稱實體組的事務）。如果你可以儲存一個事實表和在同一個分區的一個或多個索引表中的資料，您可以使用此功能來協助確保一致性。 


•索引表可以自行進行分區或分區。 

何時使用這個模式

使用這種模式來提高查詢效能，當應用程式經常需要使用一鍵以外的主（或子庫）鍵來檢索資料。 

這種模式可能不適合時： 
•資料是不穩定的。索引表可能變得過時的速度非常快，使其無效，或者使保持在索引表大於用它製成的任何節省的開銷。 
•選作索引表中的二級密鑰的場是非常不鑒別，只能有一個小的值的集合（例如，性別）。 
•資料值的選擇為一個索引表中的二級密鑰的場的平衡是高度傾斜。例如，如果90％的記錄中包含相同的值中的一個欄位，然後建立和維護一個索引表中尋找基於該欄位中的資料可以施加更大的開銷比通過資料掃描順序。然而，如果查詢非常頻繁地針對位於對剩餘的10％的值，該索引可以是有用的。你必須明白的疑問，您的應用程式正在執行，以及如何他們經常執行。 

例子

Azure儲存表在雲中啟動並執行應用程式提供了一個高度可擴充的鍵/值資料存放區。應用程式儲存，並通過指定一個鍵檢索資料值。的資料值可以包含多個欄位，但一個資料項目的結構是不透明的表格儲存體，這僅僅處理一個資料項目作為一個位元組數組。 

Azure儲存表還支援分區。分區密鑰包括兩個元件，一個分區鍵和行密鑰。有相同的分區鍵的資料項目都儲存在同一分區（片段），並且項目被儲存在一個子庫中排鍵順序。表格儲存體最佳化用於執行擷取資料下降分區中的連續範圍的行索引值範圍內的查詢。如果您正在構建儲存在Azure的表的資訊的雲應用，你應該組織你的資料在考慮這個功能。 

例如，考慮儲存有關電影的資訊的應用程式。應用程式經常按流派查詢電影（動作片，紀錄片，曆史，喜劇，戲劇，等等）。可以通過使用類型作為分區鍵，並指定電影的名稱作為行密鑰建立一個天青表的分區的每個類型，7。

 

圖7  - 儲存在Azure Table中的電影資料，按流派劃分和排序的電影名稱 


這種方法不太有效，如果該應用程式還需要通過演員主演查詢電影。在這種情況下，你可以建立一個單獨的Azure表作為一個索引表。分區鍵是演員和行關鍵是電影的名字。對於每個演員的資料將被儲存在單獨的分區。如果一個電影明星不止一個演員，同一部電影會出現在多個分區。 

可以通過採用上面的解決方案部分中所述的第一種方式重複在每個分區中儲存的值的電影資料。然而，很可能是每個影片將（對於每個演員一次）重複幾次，所以它可能是更有效，以部分非正常化，以支援最常見的查詢（如其他演員的姓名）的資料，並實現一個應用程式由包括必要找到在體裁分區的完整資訊，分區鍵來檢索任何剩餘的細節。這種方法是通過在解決方案部分中的第三項中的說明。圖8描述了這種方法。

圖8  - 演員分區作為索引表的影像資料

本文翻譯自MSDN：http://msdn.microsoft.com/en-us/library/dn589791.aspx

雲端運算設計模式（十二）——索引表模式