|
| Sun ONE Directory Server 5.2 安裝和調整指南 |
隨著 Directory Server 處理的項目不斷增多，搜尋所耗用的時間與系統資源也可能越來越多。索引是用於改善搜尋效能的一種工具。本章涵蓋 Directory Server 索引的運作方式，讓您能夠了解在特定部署方面使用特定索引的成本與效益。
關於索引
索引使查詢資訊與 Directory Server 項目產生關聯。索引表現為 Directory Server 資料庫內儲存的文檔。文中所說的資料庫是指尾碼的實體表示法。對大部分部署而言，一個尾碼對應一個資料庫；而對某些部署而言，一個尾碼可能對應多個資料庫。Directory Server 將資料庫預設儲存於 ServerRoot/slapd-ServerID/db/ 下 (nsslapd-directory 的預設值)。您可於此處找到個別的資料庫實例，它們的每個已編制索引屬性均對應一個索引檔。例如，資料庫 example 的 CN 索引檔中儲存來自尾碼 dc=example,dc=com 中的項目，此索引檔的名稱即為 ServerRoot/slapd-ServerID/db/example/example_cn.db3。
哪些屬性應編製索引，需視用戶端應用程式存取目錄資料的方式而定。表 7-1 簡要說明各種標準的索引類型。
表 7-1 標準索引類型
索引類型
回答問題...
近似
哪些項目此屬性的值發音類似於 foobar？
瀏覽
哪些項目適合這個虛擬清單檢視搜尋?
相等
哪些項目此屬性的值是 foobar？
國際
哪些項目與這個國際地區設定相符?
存在
哪些項目有此屬性？
子字串
哪些項目此屬性的值符合 *foo*？
特定屬性 (如 CN) 的索引檔可能包含多種索引類型。例如，如果在 example 資料庫中為 CN 編製索引，以進行相等及子字串對應，則 example_cn.db3 將同時包含相等與子字串索引。
請參閱「Sun ONE Directory Server 管理指南」，以了解：
- 索引類型概論
- 建立與刪除索引的說明
- 由 Directory Server 所建立的預設索引清單
- Directory Server 所需的系統索引清單
預設索引可以改善許多情況的搜尋效能，並包含其他應用程式 (如郵件傳送) 的某些支援。在某些情況下，您可以選擇停用或甚至刪除特定的預設索引，以提高效能。系統索引是 Directory Server 所憑藉的索引；請不要刪除或修改。
效益：搜尋如何使用索引
索引可加快搜尋的速度。索引內含有數值清單，其中每個數值各與對應該數值的項目識別碼清單產生關聯。Directory Server 可以利用索引中的項目識別碼清單快速查詢項目。若不利用索引管理項目清單，Directory Server 可能必須檢查尾碼中的每個項目，才能找到符合搜尋條件的項目。
從搜尋要求的處理方式說明即可明顯了解：為何索引搜尋所需的處理顯著少於非索引搜尋。Directory Server 處理每個搜尋要求的方式如下：
- 用戶端應用程式傳送搜尋要求給 Directory Server。
- Directory Server 檢查要求以確定搜尋基礎對應於它可處理的尾碼。否則，便傳回錯誤給用戶端，而且可能傳回轉介給另一個 Directory Server 實例。
- Directory Server 判斷它所管理的索引內是否有哪一個適合該搜尋。
對於存在的每個此類索引，Directory Server 均將搜尋其中的候選項目 (可能與搜尋要求相對應的項目)，如圖 6-2 所示。
請注意，如果沒有此類索引存在，Directory Server 會根據資料庫中的所有項目產生候選項目組。對大型部署而言，這個步驟可能會消耗大量的時間與系統資源 (依搜尋而定)。
- Directory Server 檢查每個候選的項目，以判斷是否符合搜尋條件。找到符合的項目時，Directory Server 會將其傳回給用戶端應用程式。
Directory Server 繼續檢查候選的項目，直到檢查過所有候選的項目，或到達資源限制 (例如 nsslapd-lookthroughlimit、nsslapd-sizelimit 或 nsslapd-timelimit) 為止，如「限制用戶端可用的資源」所述。
從步驟 3 可明顯看出，索引能夠顯著減少 Directory Server 為回應用戶端搜尋要求所必須執行的處理。
成本：更新對索引的影響
更新不僅會變更項目本身，還會變更參考該項目的索引。索引中對某一項目的參考越多，更新過程中修改索引的潛在處理成本便越高。具體而言，Directory Server 會先修改所有受影響的索引，之後再傳送更新認可給用戶端應用程式，如圖 6-3 所示。
除了維護索引所產生的處理成本之外，索引存在磁碟空間及記憶體潛在空間等成本問題。如「搜尋最佳化」所述，在針對搜尋最佳化資料庫快取大小時，您可能選擇提供足夠的記憶體，使資料庫快取中能夠同時容納項目與索引。索引越大，所需空間就越多。64 位元索引需要的空間要比 32 位元索引多一些。
一般而言，對某個 Directory Server 實例的索引進行調整，表示要對索引進行篩選，確保它們在實現快速搜尋方面的效益足以彌補需要更多更新處理及更多空間成本的不足。請養成只維護有用索引的好習慣；不要浪費資源為用戶端難得搜尋的屬性維護沒有用的索引。
存在索引
圖 7-1 描述 nsRoleDN 屬性的存在索引，顯示此索引與屬性值無關，而只包含資料庫中有 nsRoleDN 屬性的所有項目。此屬性的每一個值都與 * 相符。
圖 7-1 存在索引的表示法
如上所示，內部 entryid 屬性值讓 Directory Server 能夠儲存可快速擷取項目的參考。實際上，Directory Server 是用 dbinstance_id2entry.db3 索引檔擷取項目，此處的 dbinstance 取決於「關於索引」中所指的資料庫識別碼。
當 Directory Server 收到項目的更新要求時，若該項目的屬性有存在索引，它必須決定是否要將項目從索引中移除，然後必須執行任何必要的修改，再傳回更新認可給用戶端應用程式。
存在索引的成本通常低於其他索引類型，但為存在索引所維護的項目清單可能相當長。
相等索引
圖 7-2 描述了 SN (姓氏) 屬性的相等索引。圖中顯示，對於此索引中的每個屬性值，均具有一個以此值為 SN 屬性值的項目的列表與之對應。
圖 7-2 相等索引的表示法
當 Directory Server 收到項目的更新要求時，若該項目的屬性有相等索引，它必須決定是否要將項目從索引中移除，並決定是否要在索引中新增或移除清單，然後必須執行任何必要的修改，再傳回更新認可給用戶端應用程式。
例如，相等索引的成本通常低於子字串索引，但所需空間大於存在索引。但有些用戶端應用程式，如郵件伺服器 (Messaging Server) 可能要依賴相等索引才能提供最佳的搜尋效能。如相片與加密密碼等大型二進位屬性應避免使用相等索引。
子字串索引
圖 7-3 描述了 SN (姓氏) 屬性的子字串索引。圖中摘要顯示此索引如何按屬性值維護一系列清單。
Directory Server 為子字串編製索引，以便能夠在索引中找到要搜尋的雙字元子字串。因此，使用索引，(sn=*ab*) 的搜尋能夠加快速度 (舉例而言)，但 (sn=*a*) 的搜尋則不會。
圖 7-3 子字串索引的表示法
Directory Server 提供更進一步的最佳化，允許在萬用字元前只加上子字串的首字元進行搜尋。因此，在有子字串索引時，諸如 (sn=a*) 一類的搜尋 (而不是 (sn=*a*) 或 (sn=*a) 一類的搜尋) 也可以加速搜索。
請注意，Directory Server 根據自己的內建規則建立子字串索引。這些子字串不是由系統管理員設定的。
當 Directory Server 收到項目的更新要求時，若該項目的屬性有子字串索引，它必須決定是否要將項目從索引中移除、判斷項目的修改對索引有無影響及影響程度、決定是否要在索引中新增或移除項目 ID 或項目 ID 清單，然後必須執行任何必要的修改，再傳回更新認可給用戶端應用程式。更新的次數取決於屬性值字串的長度。
維護子字串通常相當耗費成本。由於成本因編製索引的字串長度而異，因此請避免不必要的子字串索引，特別是可能有長字串值的屬性 (例如 description)。子字串索引不能套用諸如相片的二進位屬性。
瀏覽 (虛擬清單檢視) 索引
圖 7-4 描述了虛擬清單檢視的瀏覽索引。圖中顯示此索引如何依存虛擬清單檢視資訊。也就是瀏覽索引的 vlvBase、vlvScope、vlvFilter 與 vlvSort 屬性值。此索引類型的項目 ID 會依據 vlvSort 條件排序。
圖 7-4 瀏覽索引的表示法
當 Directory Server 收到符合 vlvFilter 值的項目更新要求時，它必須決定是否要將項目從索引中移除，並決定項目在清單中的正確位置，然後必須執行任何必要的修改，再傳回更新認可給用戶端應用程式。
近似索引
Directory Server 用一種不同的 metaphone 語音演算法維護近似索引。此演算法將屬性字串值分解成大致接近其英文語音發音的近似值；並使用相同的演算法處理傳入搜尋要求中數值的比對。由於此演算法大致以音節為基礎，因此對於電話號碼等包含數字的屬性沒有多大用處。
此演算法會為每個屬性值字串產生一個目標字串。因此這種英文字串「發音類似」的索引編制方法，其成本與相等索引類似。
國際索引
國際索引使用特定地區設定的對應規則維護索引。因此這類索引的成本類似子字串與相等索引。
若使用自訂的對應規則伺服器外掛程式，您可以延伸國際索引及其他索引類型的標準支援。如需關於自訂對應規則外掛程式的詳細資訊，請參閱「Sun ONE Directory Server Plug-In API 程式設計指南」。
例如：為項目編製索引
假設有一個尾碼，其多項屬性均已經編制索引，其中包括：對 uid 編制了相等索引；對一般名稱 (cn) 及姓氏 (sn) 編制了相等、子字串及近似索引；對 mail 編制了相等索引；對 telephoneNumber 屬性編制了相等及子字串索引；以及對 description 屬性編制了子字串索引，現在要將如下所示的使用者項目加入其中。
在新增此項目時，Directory Server 必須修改 cn、sn、mail、telephoneNumber 與 description 的索引。表 7-2 說明了預期的項目數。
表 7-2 使用者項目範例的索引更新
屬性
近似
相等
子字串1
總索引更新
uid
1
1
cn
1
1
17
19
sn
1
1
9
11
1
1
telephoneNumber
1
11
12
description
47
47
對於大部分部署而言，不建議對像此處 description 字串一樣長的字串使用子字串索引。
請注意，description 字串的子字串索引更新次數 (47) 大於所有其他屬性組合的更新次數 (44)。不僅如此，若進一步修改 description 字串，更新次數甚至可能到達或超過最大更新次數 (依新字串而定)。對於像 description 這類長字串值而言，在大部分情況下，不要套用子字串索引。
調整編製索引以便提高效能
在許多情況下，為提高效能而調整編製索引是指啟用索引以加速常用的搜尋，並停用維護成本高又不經常使用的索引。
注意 資料庫備份包含索引，因此應符合 Directory Server 的組態。
變更索引設定方式後，請同時備份組態及資料。
對於涉及特定應用程式專用之複本的大型部署，您可以選擇為不同 Directory Server 實例設定不同的索引。舉例而言，假設有以下拓樸：
- 主機只處理寫入
- 集線器處理至客戶的複寫負載
- 有些客戶為特定應用程式 (如郵件傳送) 專用
例如，此案例中的主機不處理搜尋，所以您可以選擇不在主機上維護高成本的子字串索引。您也可以決定有些其他索引幾乎用不到，因此可以停用。
集線器除了管理要求之外，基本上不會收到用戶端要求，所以在這種情況下您可以停用所有索引，只留下 Directory Server 本身所需的系統索引。
在個別應用程式專用的特定客戶上，您可以決定停用應用程式用不到的所有索引。至於停用哪些索引，需視特定應用程式所執行的搜尋而定。
只允許索引搜尋
Directory Server 可以傳回 LDAP_UNWILLING_TO_PERFORM 給要求非索引搜尋的用戶端，以避免執行成本昂貴的非索引搜尋。
若要避免對特定資料庫執行非索引搜尋，請將資料庫的 nsslapd-require-index 屬性值設為 on：
$ ldapmodify -h host -p port -D "cn=directory manager" -w password
dn:cn=example,cn=ldbm database, cn=plugins, cn=config
changetype:modify
replace:nsslapd-require-index
nsslapd-require-index:on
^D (^Z on Windows systems)變更會立即生效。不必重新啟動 Directory Server。
限制索引清單長度
在大型且增長迅速的目錄部署中，對於特定索引鍵，索引可能會達到效益遞減點。當效益減到最小時，特定索引鍵的關聯清單變得太長，以致於維護清單的成本大於偶爾對候選項目之特定索引鍵執行非索引搜尋的成本。想像有一個非常大的電話簿應用程式，它以姓氏編製相等索引。如果電話簿中 Smith 的個數太多，導致為 Smith 維護索引的成本超過它在查詢的效益。這時候，Directory Server 便應該停止為 Smith 編製姓氏索引，但 Directory Server 仍應該繼續編製其他姓氏的索引。
Directory Server 具有處理這種狀況的機制。您可以將某個組態屬性設定為臨界值。當特定索引鍵的清單項目數達到設定的值時，Directory Server 便會以一個 Token 取代此索引鍵的清單，指定應執行非索引搜尋以尋找該特定索引鍵的候選項目。此值大約接近但小於搜尋所檢查之候選項目數的最大值，您可以使用 nsslapd-lookthroughlimit 設定此值，如表 9-1 所述。
此機制稱為所有 ID 臨界值，此名稱取自用於設定全域臨界值的組態屬性 cn=config,cn=ldbm database,cn=plugins,cn=config 上的 nsslapd-allidsthreshold。請注意，目前這個值對於 Directory Server 實例來說是全域值。無法依不同的索引對其進行不同的設定。
圖 7-5 說明 Smith 姓氏個數大於 nsslapd-allidsthreshold 時的編製索引範例。
圖 7-5 達到索引鍵的所有 ID 臨界值
請注意，臨界值只影響索引表格中的一個清單。其他索引鍵的清單則不受影響。
索引清單大小不適當的問題
如果用戶端主要執行索引搜尋，而且已經如第 6 章 「調整快取大小」所述，正確調整快取大小，但搜尋效能依舊不佳的話，可能是因為臨界值不適當。當您發現索引搜尋的執行效能不佳時，務請先適當調整快取大小。接著檢查 access 記錄檔，以決定 Directory Server 是否經常達到所有 ID 臨界值。
在 access 記錄 RESULT 訊息末端的 notes=U 標幟表示 Directory Server 執行非索引搜尋。同一連線與作業的前一個 SRCH 訊息指定篩選器所用的搜尋。以下兩行範例追蹤傳回 10000 個項目的 (cn=Smith) 非索引搜尋。訊息中的時間戳記已移除。
conn=2 op=1 SRCH base="o=example.com" scope=0 filter="(cn=Smith)"
conn=2 op=1 RESULT err=0 tag=101 nentries=10000 notes=U如果您發現許多應為已編制索引的搜尋中存在這類紀錄對，則表明提高臨界值可以改善搜尋效能。
變更索引清單臨界值大小
nsslapd-allidsthreshold 的理想值通常是在目錄中項目總數的 5% 左右的範圍內。例如，預設值 4000 通常適合用於處理項目數為 80,000 個項目以下的 Directory Server 實例。如果您計畫於近期內在目錄中增加大量項目，或預期目錄的成長速度非常快的話，您可以將這個值設成遠大於 5%。您也可以將支援許多搜尋的客戶複本的臨界值設定成其他值，而不是僅支援寫入的主機複本的臨界值。如果您計畫於近期內從 LDIF 重新初始化大型的目錄，您甚至可以選擇剛好在重新初始化前調整 nsslapd-allidsthreshold 的值，因為每次變更這個屬性值都必須重新建立所有索引。在任何狀況下，除非您有充分明確的理由，否則即便是極大型的部署都應避免將所有 ID 臨界值設得非常高 (超過 50,000)。
依下列方式變更所有 ID 臨界值。請注意，進行變更時，Directory Server 實例上的服務將會中斷。
- 停止要調整的 Directory Server 實例。
- 將所有目錄資料庫匯出到 LDIF。
如需詳細資料，請參閱「Sun ONE Directory Server 管理指南」。
- 小心調整 ServerRoot/slapd-ServerID/config/dse.ldif 中 nsslapd-allidsthreshold 屬性的值。
- 從 LDIF 重新初始化所有目錄資料庫。
如需詳細資料，請參閱「Sun ONE Directory Server 管理指南」。
- 如果已針對舊的所有 ID 臨界值調整資料庫快取大小，而且伺服器有足夠的實體記憶體，則可以考慮將資料庫快取大小，增幅比例為臨界值增幅比例的 25%。
換言之，如果將所有 ID 臨界值從 4000 提高到 6000，您可以將資料庫快取大小加大 12.5%，以因應增加的索引清單大小。請試驗找出最佳大小，然後再將變更套用到實際執行伺服器。如需關於調整資料庫快取的詳細資料，請參閱第 6 章 「調整快取大小」。
- 重新啟動 Directory Server 實例。
疑難排解索引分散
支援大型索引及高更新率的 Directory Server 實例可能會遇到索引鍵極端分散的問題。即使資料庫大小固定，索引鍵極端分散仍可能降低執行效能。如果您認為是索引鍵極端分散的問題導致伺服器效能明顯變差，請考慮重新產生受影響的索引，以減少分散程度。
如需建立索引的詳細資料，請參閱「Sun ONE Directory Server 管理指南」。