第13章 インデックスの管理

インデックス付けは、属性または値を分類および整理することにより、情報の検索と取得を容易にします。本章では、検索アルゴリズム自体、コンテキストにインデックスのメカニズムを配置し、インデックスを作成、削除、および管理する方法を説明します。

13.1. インデックスの概要

本セクションでは、Directory Server でのインデックスの概要を説明します。これには、以下のトピックが含まれます。

13.1.1. インデックスタイプの概要

インデックスはディレクトリーのデータベースにあるファイルに保存されます。ファイルの名前は、インデックス化された属性に基づいて、ファイルに含まれるインデックスの型は生成されません。各インデックスファイルには、特定の属性に対して複数のインデックスが保持されると、複数のインデックスが含まれる場合があります。たとえば、共通の name 属性用に保持されるすべてのインデックスは cn.db ファイルに含まれます。
Directory Server は、以下のタイプのインデックスをサポートします。
  • Presence index (pres) には、特定の属性を含むエントリーのリストが含まれており、検索には非常に便利です。たとえば、アクセス制御情報を含むエントリーを簡単に検証できます。プレゼンスインデックスを含む aci.db ファイルを生成すると、ACI=* の検索を効率的に実行して、サーバーのアクセス制御リストを生成します。
  • Equality index (eq) により、特定の属性値を含むエントリーの検索が改善されます。たとえば、cn 属性の等価インデックスを使用すると、ユーザーは cn=Babs Jensen の検索をより効率的に実行できます。
  • Approximate index (approx) は、効率的な近似検索や sounds-like 検索に使われます。たとえば、エントリーには属性値 cn=Firstname M Lastname を含めることができます。概算検索では、この値を cn~=Firstname Lastname、cn~=Firstname、または cn~=Lastname に対する検索に対して返します。同様に、l~=San Fransisco (スペルミスに注意) を検索すると、l=San Francisco を含むエントリーが返されます。
  • Substring index (sub) は、維持するコストのかかるインデックスですが、エントリー内の部分文字列に対して効率的な検索が可能になります。部分文字列のインデックスは、各エントリーの最小 3 文字に制限されます。
    たとえば、cn=*derson の形式で検索すると、Bill Anderson、Jill Henderson、または Steve Sanderson といった文字列が含まれる共通名と一致します。同様に、telephoneNumber= *555* の検索は、555 が含まれる電話番号を持つディレクトリー内の全エントリーを返します。
  • 国際インデックス は、国際ディレクトリー内の情報の検索を迅速化します。国際インデックスの作成プロセスは、通常のインデックスを作成するプロセスと似ています。ただし、オブジェクト識別子 (OID) をインデックス化する属性に関連付けることで 一致するルール を適用する点が異なります。
    サポートされるロケールおよび関連付けられた OID が付録D 国際化にリスト表示されています。追加のマッチングルールを受け入れるように Directory Server を設定する必要がある場合は、Red Hat コンサルティングにお問い合わせください。

13.1.2. デフォルトインデックスおよびデータベースインデックスの概要

Directory Server には、一連のデフォルトインデックスが含まれます。新規データベースの作成時に、Directory Server はこれらのデフォルトインデックスを cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config から新規データベースにコピーします。次に、データベースはこれらのインデックスのコピーのみを使用します。このインデックスは cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config に保存されます。
注記
Directory Server は cn=config エントリーの設定を複製しません。したがって、レプリケーショントポロジーの一部であるサーバーでは、インデックスを異なる方法で設定できます。たとえば、レプリケーションがカスケードする環境では、クライアントがハブからデータを読み取らない場合は、ハブにカスタムインデックスを作成する必要はありません。
Directory Server のデフォルトインデックスを表示するには、以下を実行します。 
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com \
     -b "cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config" \
     '(objectClass=nsindex)'
注記
cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config に保存されているデフォルトのインデックス設定を更新しても、変更は cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config の個々のデータベースには適用されません。
個別のデータベースのインデックスを表示するには、次のコマンドを実行します。 
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend index list database_name

13.1.3. 検索アルゴリズムの概要

インデックスを使用して検索を迅速化します。ディレクトリーがインデックスをどのように使用するかを理解するには、検索アルゴリズムを理解するのに役立ちます。各インデックスには、 (cn、共通名、属性など) 属性の一覧と、インデックス化された属性値が含まれるエントリーの ID の一覧が含まれます。
  1. LDAP クライアントアプリケーションは、検索要求をディレクトリーに送信します。
  2. ディレクトリーは、受信要求を調べて、指定したベース DN が、1 つ以上のデータベースまたはデータベースリンクに含まれる接尾辞と一致することを確認します。
    • 一致する場合には、ディレクトリーはリクエストを処理します。
    • 一致しない場合、ディレクトリーは接尾辞と一致しないことを示すエラーをクライアントに返します。cn=config 下の nsslapd-referral 属性で参照を指定している場合、ディレクトリーは、クライアントがリクエストを購入できる LDAP URL も返します。
    • Directory Server は、どのインデックスが適用されるかを確認するための検索フィルターを調べ、フィルターを満たす各インデックスからエントリー ID のリストを読み込もうとします。ID リストは、フィルターで使用されている AND または OR に参加するかによって組み合わせられます。
      各フィルターコンポーネントは個別に処理され、ID リストを返します。
    • エントリー ID の一覧が設定された ID リストのスキャン制限よりも大きい場合や、属性にインデックスが定義されていない場合、Directory Server は、この filtercomponent の結果を allids に設定します。個々の検索コンポーネントの結果に論理操作を適用すると、その一覧は引き続き ALLIDs のままになる場合は、データベース内のすべてのエントリーを検索します。これは インデックスのない 検索です。
  3. Directory Server は、ID リストのすべてのエントリー ID について、id2entry.db データベースまたはエントリーキャッシュから (またはインデックスなしの検索の場合はデータベース全体から) すべてのエントリーを読み取ります。その後、サーバーはエントリーをチェックして、検索フィルターと一致するかどうかを確認します。それぞれの一致が見つかったら、それが返されます。
    サーバーは、すべての候補エントリーを検索するか、設定されたリソース制限に達するまで、ID のリストを検索し続けます。(リソース制限は「コマンドラインを使用したユーザーおよびグローバルリソース制限の設定」にリスト表示されます。)
    注記
    簡単なページ化された結果制御を使用して、検索に対して別のリソース制限を設定できます。たとえば、管理者は、高いサイズまたは無制限サイズを設定し、ページ化された検索で制限を検索しますが、ページのない検索には低いデフォルト制限を使用します。

13.1.4. おおよその検索

また、このディレクトリーでは、metaphone 表音アルゴリズムのバリエーションを用いて、近似的なインデックスで検索を行っています。各値は単語のシーケンスとして処理され、各単語について電話番号が生成されます。
注記
Directory Server の metaphone 表音アルゴリズムは US-ASCII 文字のみをサポートします。したがって、インデックスは、英語の値でのみ使用してください。
概算検索に入力した値は、表音コードシーケンスに変換されます。以下の両方が当てはまる場合、エントリーはクエリーに一致すると考えられます。
  • すべてのクエリー文字列コードは、エントリー文字列に生成されたコードと一致します。
  • クエリー文字列コードはすべて、エントリー文字列コードと同じ順序で実行されます。
ディレクトリーの名前 (フォネティックコード) クエリー文字列 (フォネティックコード) 一致のコメント
Alice B Sarette (ALS B SRT) Alice Sarette (ALS SRT) 一致。コードが正しい順序で指定されます。
Alice Sarrette (ALS SRT) 一致。コードは、Sarette が間違っているにもかかわらず、正しい順序で指定されます。
Surette (SRT) 一致。生成されたコードは、Sarette のスペルが間違っているにもかかわらず、元の名前で存在しています。
Bertha Sarette (BR0 SRT) 一致するものはありません。コード BR0 は元の名前に存在しません。
Sarette, Alice (SRT ALS) 一致するものはありません。コードが正しい順序で指定されていません。

13.1.5. インデックスのメリットとのバランス

新しいインデックスを作成する前に、インデックスを維持することのメリットとコストのバランスを考えてください。
  • 概算インデックスは、通常、数字を含む属性 (電話番号など) には効率的ではありません。
  • 部分文字列のインデックスはバイナリー属性では機能しません。
  • 等価インデックスは、値が大きい場合に使用しないようにしてください (例: 暗号化データを含む写真やパスワードを含む属性など)。
  • 検索であまり使用されない属性のインデックスを維持することは、グローバル検索のパフォーマンスを向上させることなく、オーバーヘッドを増加させます。
  • インデックス化されていない属性は、検索要求で依然として指定できますが、検索のタイプによっては検索パフォーマンスが大幅に低下する可能性があります。
  • 保守するインデックスが多いほど、必要なディスク領域が多くなります。
インデックスは、非常に時間がかかります。以下に例を示します。
  1. Directory Server は add 操作または modify 操作を受け取ります。
  2. Directory Server は indexing 属性を調べ、属性値に対してインデックスが維持されているかどうかを判断します。
  3. 作成した属性値がインデックス化されると、Directory Server はインデックスから新しい属性値を追加または削除します。
  4. 実際の属性値はエントリーに作成されます。
たとえば、Directory Server はエントリーを追加します。 
dn: cn=John Doe,ou=People,dc=example,dc=com
objectclass: top
objectClass: person
objectClass: orgperson
objectClass: inetorgperson
cn: John Doe
cn: John
sn: Doe
ou: Manufacturing
ou: people
telephoneNumber: 408 555 8834
description: Manufacturing lead for the Z238 line of widgets.
Directory Server は以下のインデックスを維持します。
  • cn (通称) および sn (姓) 属性の等価、近似、および部分文字列インデックス。
  • 電話番号属性の等価および部分文字列のインデックス。
  • 説明属性の部分文字列インデックス。
そのエントリーをディレクトリーに追加する場合は、Directory Server で以下の手順を実行する必要があります。
  1. John と John Doe の cn 等価インデックスエントリーを作成します。
  2. John と John Doe の適切な cn 近似インデックスエントリーを作成します。
  3. John と John Doe の適切な cn 部分文字列インデックスエントリーを作成します。
  4. Doe の sn 等価インデックスエントリーを作成します。
  5. Doe の適切な sn 近似インデックスエントリーを作成します。
  6. Doe の適切な sn 部分文字列インデックスエントリーを作成します。
  7. 408 555 8834 の電話番号等価インデックスエントリーを作成します。
  8. 408 555 8834 の適切な電話番号部分文字列インデックスエントリーを作成します。
  9. Manufacturing lead for the Z238 line of widgets の適切な説明部分文字列インデックスエントリーを作成します。この文字列に対して多数の部分文字列エントリーが生成されます。
この例が示すように、大規模なディレクトリーのデータベースの作成および維持に必要なアクションの数は、リソースを必要とします。

13.1.6. インデックスの制限

nsrole や cos_attribute などの仮想属性をインデックス化できません。仮想属性には計算値が含まれます。これらの属性をインデックス化すると、Directory Server は無効なエントリーセットを返して直接的かつ内部検索を行うことができます。