前へ
目次
索引
DocHome
次へ
|
| iPlanet Directory Server 5.1 導入ガイド |
第 5 章 ディレクトリトポロジの設計
第 4 章「ディレクトリツリーの設計」では、ディレクトリでのエントリの格納方法について説明しました。Directory Server は膨大な数のエントリを格納できるので、エントリを複数のサーバに分散して配置しなければならない場合があります。ディレクトリのトポロジ (topology) は、ディレクトリツリーをどのように複数の物理的な Directory Server に分割するか、およびこれらのサーバをどのように相互にリンクするかを示します。
この章では、ディレクトリのトポロジの計画について説明します。この章は、次の節で構成されています。
トポロジの概要
トポロジの概要
第 4 章「ディレクトリツリーの設計」で設計したディレクトリツリーが複数の物理的な Directory Server に分散されている、分散型のディレクトリを構成するように、iPlanet Directory Server の配置を設計できます。ディレクトリを複数のサーバに分割する手法は、次のような機能強化を実現するのに役立ちます。
データベースは、複製、バックアップ、データの復元などの作業に使用する基本単位です。1 つのディレクトリを管理可能な複数のチャンクに分割し、それらのチャンクを異なるデータベースに割り当てることができます。これらのデータベースは多数のサーバに分散できるので、各サーバの作業負荷が軽減します。1 つのサーバに複数のデータベースを格納できます。たとえば、1 つのサーバに異なる 3 つのデータベースを格納できます。
ディレクトリツリーを複数のデータベースに分割した場合、各データベースには接尾辞 (suffix) と呼ばれるディレクトリツリーの一部分が格納されます。たとえば、ディレクトリツリーのou=people,dc=siroe,dc=com という接尾辞、あるいは分岐にあるエントリを 1 つのデータベースに格納できます。
ディレクトリを複数のサーバに分割すると、各サーバはディレクトリツリーの一部分だけを処理します。分散されたディレクトリの動作は、DNS ネームスペースの各部分を特定の DNS サーバに割り当てるドメインネームサービス (DNS) に似ています。DNS と同様に、ディレクトリのネームスペースを複数のサーバに分散し、クライアント側からは単一のディレクトリツリーを持つ 1 つのディレクトリとして管理させることができます。
iPlanet Directory Server は、別々のデータベースに格納されているディレクトリのデータをリンクするメカニズムである知識参照も提供します。Directory Server には、レフェラルと連鎖という 2 つのタイプの知識参照があります。
以降の節では、データベースと知識参照について説明し、2 つのタイプの知識参照の違いと、データベースの性能を向上させるためのインデックスの設計方法について説明します。
データの分散
データを分散すると、社内の各サーバ上にディレクトリのエントリを物理的に格納することなく、ディレクトリを複数のサーバにわたって拡張できます。そのため、分散型ディレクトリは、1 つのサーバで保持できる数よりはるかに多くのエントリを保持できます。
また、分散されていることがユーザからは見えないようにディレクトリを設定することもできます。ユーザとアプリケーションからは、ディレクトリへの問い合わせに応答する単一のディレクトリがあるようにしか見えません。
「複数のデータベースの使用について」
複数のデータベースの使用について
iPlanet Directory Server はデータを LDBM データベースに格納します。LDBM データベース (LDBM database) はディスクベースの高性能データベースです。各データベースは、割り当てられたすべてのデータを含む大きなファイルのセットから構成されます。
ディレクトリツリーの異なる部分を別々のデータベースに格納できます。たとえば、次のようなディレクトリツリーがあるとします。
ツリーにある 3 つの接尾辞のデータを、次のように 3 つの異なるデータベースに格納できます。
ディレクトリツリーを多数のデータベースに分割すると、それらのデータベースを複数のサーバに分散できます。たとえば、ディレクトリツリーの 3 つの接尾辞を含めるために作成した 3 つのデータベースを、次のように 2 つのサーバに格納できます。
サーバ A には 1 番目と 2 番目のデータベース、サーバ B には 3 番目のデータベースが含まれます。
データベースを複数のサーバに分散すると、各サーバが処理しなければならない作業量を削減できます。このようにして、1 つのサーバで保持できる数よりもはるかに多いエントリに対応するようにディレクトリを拡張できます。
さらに、iPlanet Directory Server ではデータベースを動的に追加できるので、ディレクトリにデータベースが必要になったときに、ディレクトリ全体をオフラインにしなくても新しいデータベースを追加できます。
接尾辞について
各データベースには Directory Server の接尾辞にあるデータが格納されます。ルート接尾辞とサブ接尾辞の両方を作成して、ディレクトリツリーの内容を編成できます。ルート接尾辞 (root suffix) はツリーの最上位にあるエントリです。この接尾辞は、ディレクトリツリーのルートか、または Directory Server 用に設計したもっと大きなツリーの一部を形成します。
サブ接尾辞 (sub suffix) はルート接尾辞の下にある分岐です。ルート接尾辞とサブ接尾辞のデータはデータベースに格納されます。
たとえば、ディレクトリデータの分散を表すために接尾辞を作成したいとします。siroe.com 社のディレクトリツリーは次のように表されます。
siroe.com 社は、ディレクトリツリーを、次のように 5 つの異なるデータベースに分割するとします。
o=NetscapeRoot 接尾辞と dc=siroe,dc=com 接尾辞は両方ともルート接尾辞です。ほかの接尾辞である ou=testing,dc=siroe,dc=com、ou=development,dc=siroe,dc=com、および ou=partners,ou=development,odc=siroe,dc=com はすべて、dc=siroe,dc=com ルート接尾辞のサブ接尾辞です。ルート接尾辞 dc=siroe,dc=com には、元のディレクトリツリーの分岐である ou=marketing のデータが含まれます。
ディレクトリに複数のルート接尾辞が含まれることもあります。たとえば、I-Zed 社という ISP が、siroe.com と company22.com のそれぞれに、複数の Web サイトをホストするとします。この ISP は、2 つのルート接尾辞を作成します。1 つは dc=siroe,dc=com 命名コンテクストに対応し、もう 1 つは dc=company22,dc=com 命名コンテクストに対応します。ディレクトリツリーは次のように表されます。
dc=i-zed,dc=com エントリはルート接尾辞を表します。各ホスト ISP のエントリもルート接尾辞 (o=siroe と o=company22) を表します。ou=people 分岐と ou=groups 分岐は、各ルート接尾辞の下にあるサブ接尾辞です。
知識参照について
データを複数のデータベースに分散したあとは、分散したデータ間の関係を定義する必要があります。そのためには、別々のデータベースに保持されているディレクトリ情報へのポインタである知識参照を使用します。iPlanet Directory Server には、分散されたデータを単一のディレクトリツリーとしてリンクする、次のタイプの知識参照があります。
レフェラル
サーバは、要求を完了するには別のサーバに接続する必要があることを示す情報をクライアントアプリケーションに返します。
連鎖
サーバはクライアントアプリケーションの代わりに別のサーバに接続し、操作が終了すると、結合した結果をクライアントアプリケーションに返します。
次に、これら 2 つのタイプの知識参照をさらに詳しく比較して説明します。
レフェラルの使い方
レフェラル (referral) はサーバが返す情報であり、操作要求を完了するために接続する必要があるサーバをクライアントアプリケーションに指示します。この転送メカニズムは、クライアントアプリケーションがローカルサーバに存在しないディレクトリエントリを要求したときに起動されます。
Directory Server は、次の 2 つのタイプのレフェラルをサポートしています。
デフォルトレフェラル
クライアントアプリケーションが提示した DN に対応する接尾辞がサーバにない場合、ディレクトリはデフォルトレフェラルを返します。デフォルトレフェラルはサーバの設定ファイルに格納されています。Directory Server のデフォルトレフェラルを設定することも、各データベースに個別のデフォルトレフェラルを設定することもできます。
各データベースに設定したデフォルトレフェラルは、接尾辞設定情報を通じて実行されます。データベースの接尾辞が無効な場合は、その接尾辞に対して発行されたクライアント要求にデフォルトレフェラルを返すようにディレクトリを設定できます。接尾辞については、「接尾辞について」を参照してください。接尾辞の設定方法については、『iPlanet Directory Server 管理者ガイド』を参照してください。
スマートレフェラル
スマートレフェラルは、ディレクトリ自体のエントリに格納されています。このレフェラルは、このスマートレフェラルが格納されているエントリの DN とマッチする DN を持つサブツリーに関する情報を保有している Directory Server をポイントします。
レフェラルはすべて、LDAP の URL (Uniform Resource Locator) 形式で返されます。次に、LDAP レフェラルの構造と、Directory Server がサポートする 2 つのタイプのレフェラルについて説明します。
LDAP レフェラルの構造
LDAP レフェラルには LDAP URL 形式の情報が含まれます。LDAP URL には、次の情報が含まれます。
接続先サーバのホスト名
検索操作の場合はベース DN (base DN)。追加、削除、および変更操作の場合はターゲット DN たとえば、クライアントアプリケーションが Jensen という姓を持つエントリを dc=siroe,dc=com 内で検索するとします。レフェラルは、次の LDAP URL をクライアントアプリケーションに返します。
ldap://europe.siroe.com:389/ou=people,l=europe,dc=siroe,dc=com
レフェラルは、ポート 389 のホスト europe.siroe.com に接続し、ou=people,l=europe,dc=siroe,dc=com にルート設定された検索要求を送信するように、クライアントアプリケーションに指示します。
レフェラルがどのように処理されるかは、使用している LDAP クライアントアプリケーションによって決まります。転送されたサーバ上で操作を自動的に再試行するクライアントアプリケーションもあれば、単にレフェラル情報をユーザに返すだけのクライアントアプリケーションもあります。コマンド行ユーティリティなど、iPlanet が提供するほとんどの LDAP クライアントアプリケーションは、自動的にレフェラルを実行します。サーバへのアクセスには、最初のディレクトリ要求で提供するバインド資格が使用されます。
ほとんどのクライアントアプリケーションは、レフェラルの制限数、あるいはホップ数だけレフェラルを実行します。実行するレフェラル数を制限すると、クライアントアプリケーションがディレクトリ検索要求を完了しようとして費やす時間を低減でき、また循環レフェラルパターンが原因で発生する処理停止を防ぐのにも役に立ちます。
デフォルトレフェラルについて
接続したサーバまたはデータベースに要求したデータがない場合は、デフォルトレフェラルがクライアントに返されます。
Directory Server は、要求されたディレクトリオブジェクトの DN とローカルサーバでサポートされているディレクトリ接尾辞を比較して、デフォルトレフェラルを返すかどうかを決めます。DN とサポートされている接尾辞がマッチしない場合はデフォルトレフェラルを返します。
たとえば、ディレクトリクライアントが次のディレクトリエントリを要求したとします。
uid=bjensen,ou=people,dc=siroe,dc=com
ところが、サーバは dc=europe,dc=siroe,dc=com 接尾辞の下に格納されているエントリしか管理していません。このような場合、ディレクトリは、dc=siroe,dc=com 接尾辞に格納されているエントリを取得するために接続する必要があるサーバを示すレフェラルをクライアントに返します。デフォルトレフェラルを受け取ったクライアントは適切なサーバに接続して、元の要求を再送信します。
デフォルトレフェラルは、ディレクトリの分散に関する情報をより多く保持している Directory Server をポイントするように設定します。サーバのデフォルトレフェラルは、nsslapd-referral 属性で設定します。ディレクトリインストール時の各データベースのデフォルトレフェラルは、構成内のデータベースエントリの nsslapd-referral 属性で設定されます。これらの属性値は dse.ldif ファイルに格納されます。
デフォルトレフェラルの設定方法については、『iPlanet Directory Server 管理者ガイド』を参照してください。
スマートレフェラル
Directory Server では、スマートレフェラルを使用するようにディレクトリを設定することもできます。スマートレフェラルを使用すると、ディレクトリのエントリまたはディレクトリツリーを特定の LDAP URL に関連付けることができます。ディレクトリのエントリを特定の LDAP URL に関連付けると、次のいずれかに要求を転送できます。
デフォルトレフェラルとは異なり、スマートレフェラルはディレクトリ自体に格納されます。スマートレフェラルの設定方法と管理については、『iPlanet Directory Server 管理者ガイド』を参照してください。
たとえば、siroe.com 社の米国支社のディレクトリに、ou=people,dc=siroe,dc=com というディレクトリ分岐点があるとします。
ou=people エントリ自体にスマートレフェラルを指定することで、この分岐への要求をすべて siroe.com 社のヨーロッパ支社の ou=people 分岐に転送できます。このスマートレフェラルは、次のようになります。
ldap://europe.siroe.com:389/ou=people,dc=siroe,dc=com
米国支店のディレクトリにある people 分岐への要求はすべて、ヨーロッパのディレクトリに転送されます。このスマートレフェラルを図に示すと、次のようになります。
同じメカニズムを使用して、異なるネームスペースを使っている別のサーバに問い合わせを転送できます。たとえば、siroe.com 社のイタリア支社の従業員がヨーロッパのディレクトリに米国の siroe.com 社員の電話番号を要求したとします。ディレクトリは次のレフェラルを返します。
ldap://europe.siroe.com:389/ou=US employees,dc=siroe,dc=com
同じサーバ上に複数の接尾辞を設定している場合は、あるネームスペースから同じマシン上の別のネームスペースに問い合わせを転送できます。ローカルマシン上の o=siroe,c=us への問い合わせをすべて dc=siroe,dc=com に転送する場合は、o=siroe,c=us エントリに次のスマートレフェラルを設定します。
この LDAP URL の 3 番目のスラッシュは、URL が同じ Directory Server をポイントしていることを示しています。
注
あるネームスペースから別のネームスペースへのレフェラルの作成は、レフェラルの識別名に基づいた検索を実行するクライアント以外では使用できません。ou=people,o=siroe,c=US の下の検索など、ほかの操作は正しく実行されません。
LDAP URL と、スマート URL を iPlanet Directory Server のエントリに含める方法については、『iPlanet Directory Server 管理者ガイド』を参照してください。
スマートレフェラルを設計する際のヒント
スマートレフェラルは簡単に使用できますが、使用するときは次の点を考慮してください。
設計を単純にする
複雑に交錯したレフェラルを使用してディレクトリを運用すると、管理が難しくなります。また、スマートレフェラルを使いすぎると、循環レフェラルパターンを引き起こしてしまう場合もあります。例えば、レフェラルがある LDAP URL をポイントし、その LDAP URL が別の LDAP URL をポイントするといったことが、連鎖のどこかで最後に元のサーバに戻ってしまうまで続くという状況です。次の図に、循環レフェラルパターンを示します。
主要な分岐点で転送する
ディレクトリツリーの接尾辞レベルで転送を処理するように、レフェラルの使用を制限します。スマートレフェラルを使用すると、最下位のエントリ (分岐ではない) への検索要求を別のサーバや DN に転送できます。そのため、スマートレフェラルをエイリアスメカニズムとして使用することがよくあり、その結果、ディレクトリ構造の安全保護を複雑で困難なものにしています。レフェラルの使用をディレクトリツリーの接尾辞または主要な分岐点に限定することで、管理するレフェラル数が減少し、ディレクトリの管理に伴う負荷を低減できます。
セキュリティへの影響を考慮する
アクセス制御はレフェラルの境界を越えると機能しません。要求を発信したサーバがエントリへのアクセスを許可している場合でも、スマートレフェラルがクライアントの要求を別のサーバに転送したときは、クライアントアプリケーションがアクセスを許可されないこともあります。
また、クライアントが認証されるためには、クライアントは転送先のサーバ上でクライアント資格を使用できなければなりません。
連鎖の使用方法
連鎖は要求を別のサーバに中継する手法の 1 つです。この手法はデータベースリンクを介して実行されます。「データの分散」で説明したように、データベースリンク (database link) にデータは含まれていません。データベースリンクは、クライアントアプリケーションの要求をデータがあるリモートサーバに転送します。
連鎖 (chaining) では、サーバがそのサーバに格納されていないデータの要求を受け取ると、データベースリンクを使用してクライアントアプリケーションの代わりに別のサーバに接続し、結果をクライアントアプリケーションに返します。次の図に、この動作を示します。
各データベースリンクはデータを保持しているリモートサーバに関連付けられています。障害が発生したときにデータベースリンクが使用する、データの複製が入った代替リモートサーバを設定することもできます。データベースリンクの設定方法については、『iPlanet Directory Server 管理者ガイド』を参照してください。
リモートデータへの透過的なアクセス
データベースリンクがクライアントの要求を処理するので、データの分散はクライアントからは見えません。
動的な管理
システム全体をクライアントアプリケーションが使用できる状態にしたままで、ディレクトリを部分的にシステムに追加したり、システムから削除したりできます。データベースリンクは、エントリがディレクトリに再分散されるまで、レフェラルを一時的にアプリケーションに返すことができます。接尾辞を使用してこの機能を実装することもできます。接尾辞はクライアントアプリケーションをデータベースに転送するのではなく、レフェラルを返します。
アクセス制御
データベースリンクは、クライアントアプリケーションに代わって該当する認証情報をリモートサーバに提示します。アクセス制御を評価する必要がない場合は、リモートサーバに対するユーザ代行機能を無効にすることができます。データベースリンクの設定方法については、『iPlanet Directory Server 管理者ガイド』を参照してください。
レフェラルと連鎖の選択
分割されたディレクトリ部分をリンクする場合、どちらの手法にも利点と欠点があります。ディレクトリの要件に応じて、どちらか一方、あるいは両方を組み合わせて使用します。
レフェラルと連鎖の大きな違いは、分散された情報の検索方法を認識するインテリジェンスが置かれている場所です。連鎖システムでは、このインテリジェンスがサーバ内に実装されます。レフェラルを使用するシステムでは、インテリジェンスはクライアントアプリケーション内に実装されます。
連鎖では、クライアント側の処理は簡単になりますが、その分サーバ側の処理が複雑になります。連鎖対象のサーバは、リモートサーバと協調して結果をディレクトリクライアントに送信する必要があります。
レフェラルでは、クライアントがレフェラルを検索して検索結果を照合する必要があります。ただし、連鎖よりもレフェラルを使用した方がクライアントアプリケーションを柔軟に作成でき、開発者は分散型ディレクトリの進行状況をより適切な形でユーザにフィードバックできます。
使用方法の違い
レフェラルをサポートしないクライアントアプリケーションもあります。連鎖を使用すると、クライアントアプリケーションは 1 つのサーバと通信するだけで、多数のサーバに格納されているデータにアクセスすることができます。企業のネットワークがプロキシを使用している場合は、レフェラルが機能しないことがあります。たとえば、クライアントアプリケーションがファイアウォール内の 1 つのサーバとだけ通信する権限を持っているとします。クライアントアプリケーションが別のサーバに転送された場合、クライアントはそのサーバに正常に接続できません。
また、レフェラルでは、クライアントを認証する必要があります。つまり、クライアントの転送先のサーバにクライアント資格が格納されている必要があります。連鎖では、クライアント認証は 1 回だけで済みます。要求の連鎖先のサーバでクライアントを再び認証する必要はありません。
アクセス制御の評価
連鎖は、レフェラルとは違う方法でアクセス制御を評価します。レフェラルでは、クライアントのエントリがすべての転送先サーバ上に存在しなければなりません。連鎖では、クライアントエントリがすべての転送先サーバ上に存在している必要はありません。
たとえば、クライアントが検索要求をサーバ A に送信する場合を考えてみます。次の図は、レフェラルを使用した場合の動作です。
上記の図では、クライアントアプリケーションは次の手順を実行します。
クライアントアプリケーションは、まずサーバ A にバインドします。
サーバ A は、ユーザ名とパスワードを提供するクライアントのエントリを保持しているので、バインド受け入れメッセージを返します。レフェラルが機能するためには、サーバ A にクライアントエントリが存在していなければなりません。
クライアントアプリケーションがサーバ A に操作要求を送信します。
要求された情報はサーバ A にないので、サーバ A はレフェラルをクライアントアプリケーションに返し、サーバ B に接続するように通知します。
クライアントアプリケーションが、バインド要求をサーバ B に送信します。サーバ がバインドに成功するには、サーバ B にクライアントアプリケーションのエントリが存在する必要があります。 この方法では、サーバ A からレプリケートされたクライアントエントリのコピーがサーバ B に必要です。
連鎖では、この問題は発生しません。連鎖システムでは、検索要求は次のように動作します。
クライアントアプリケーションがサーバ A にバインドし、サーバ A はユーザ名とパスワードが正しいことを確認しようとします。
サーバ A にはクライアントアプリケーションに対応するエントリが存在しません。その代わりに、サーバ A にはクライアントの実際のエントリがあるサーバ B へのデータベースリンクがあります。サーバ A はバインド要求をサーバ B に送信します。
サーバ B はサーバ A にバインド受け入れメッセージを返信します。
サーバ A はデータベースリンクを使用してクライアントアプリケーションの要求を処理します。データベースリンクはサーバ B にあるリモートデータストアに接続して検索操作を処理します。 連鎖システムでは、クライアントアプリケーションに対応するエントリが、クライアントが要求するデータと同じサーバ上にある必要はありません。たとえば、システムを次のように設定できます。
クライアントアプリケーションがサーバ A にバインドし、サーバ A はユーザ名とパスワードが正しいことを確認しようとします。
サーバ A にはクライアントアプリケーションに対応するエントリが存在しません。その代わりに、サーバ A にはクライアントの実際のエントリがあるサーバ B へのデータベースリンクがあります。サーバ A はバインド要求をサーバ B に送信します。
サーバ B はサーバ A にバインド受け入れメッセージを返信します。
サーバ A は別のデータベースリンクを使用してクライアントアプリケーションの要求を処理します。データベースリンクはサーバ C にあるリモートデータストアに接続して検索操作を処理します。 ただし、データベースリンクは、次のアクセス制御をサポートしません。
ユーザエントリが別のサーバ上にある場合、そのユーザエントリの内容にアクセスする必要がある制御はサポートされない。これには、グループ、フィルタ、およびロールに基づくアクセス制御が含まれる
クライントの IP アドレスまたは DNS ドメインに基づく制御は拒否される場合がある。これは、データベースリンクがリモートサーバに接続するときは、クライアントとして接続するためである。リモートデータベースに IP に基づくアクセス制御が含まれている場合、リモートデータベースは、元のクライアントのドメインではなく、データベースリンクのドメインを使用してアクセス制御を評価する
インデックスを使用したデータベース性能の向上
データベースのサイズによっては、クライアントアプリケーションが実行する検索に多大な時間と資源が費やされることがあります。インデックスを使用すると、検索の性能を向上させることができます。
インデックスとは、ディレクトリのデータベースに格納されるファイルです。データベースごとに、個別のインデックスファイルがディレクトリ内に保持されています。各ファイルは、それがインデックス付けを行う属性に従って命名されます。特定の属性のインデックスファイルには複数のタイプのインデックスを含めることができるので、各属性について複数のタイプのインデックスを保持できます。たとえば、cn.db3 というファイルには共通名属性のすべてのインデックスが入っています。
ディレクトリを使用するアプリケーションのタイプに応じて、さまざまなタイプのインデックスを使用します。アプリケーションの中には、特定の属性を頻繁に検索したり、異なる言語でディレクトリを検索したり、あるいは特定の形式のデータを必要とするものがあります。
ディレクトリのインデックスタイプの概要
ディレクトリのインデックスタイプの概要
ディレクトリは、次のタイプのインデックスをサポートします。
実在インデックス
実在インデックス (presence index) は、uid などの特定の属性を持つエントリをリストします。
等価インデックス
等価インデックス (equality index) は、cn=Babs Jensen のような特定の属性値を持つエントリをリストします。
近似インデックス
近似インデックス (approximate index) は、近似 (音による) 検索を可能にします。たとえば、cn=Babs L. Jensen という属性値を持つエントリがあるとします。cn~=Babs Jensen、cn~=Babs、および cn~=Jensen のいずれで検索しても、近似検索はこの cn=Babs L.Jensen という値を返します。
近似インデックスは、ASCII 文字で書かれた英語名にだけ有効であることに注意してください。
部分文字列検索
部分文字列インデックス (substring index) は、エントリ内の部分文字列の検索を可能にします。たとえば、cn=*derson を検索すると、Bill Anderson、Norma Henderson、Steve Sanderson など、この文字列が含まれる共通名が検索されます。
国際化インデックス
国際化インデックス (international index) は、国際化ディレクトリでの情報検索を高速化します。インデックスが付けられている属性にロケール (OID) を関連付けることで、マッチング規則が適用されるようにインデックスを設定できます。
ブラウズインデックス
ブラウズインデックス、あるいは仮想リスト表示 (VLV) インデックスは、Directory Server Console でのエントリの表示を高速化します。ディレクトリツリー内の任意の分岐にブラウズインデックス (browsing index) を作成することにより、表示性能を向上させることができます。
インデックス付けのコスト評価
インデックスはディレクトリデータベースでの検索性能を向上させますが、次のようなマイナス面もあります。
インデックスが付けられていると、エントリの変更に時間がかかる
保持するインデックスが増えると、ディレクトリがデータベースを更新するのにかかる時間もそれだけ長くなります。
インデックスファイルがディスクスペースを占有する
インデックスを付けた属性が増えると、作成するファイルの数も増えます。また、長い文字列を含む属性に近似インデックスや部分文字列インデックスを作成すると、ファイルはすぐに大きくなります。
インデックスファイルはメモリを使用する
ディレクトリは、実行効率を上げるため、できるかぎり多くのインデックスファイルをメモリ上に置きます。インデックスファイルは、データベースのキャッシュサイズに応じて使用可能なメモリプールを使用します。インデックスファイルの数が増えれば、データベースのキャッシュサイズも大きくする必要があります。
インデックスファイルは作成に時間がかかる
インデックスファイルは検索時間を短縮しますが、必要のないインデックスを保持すると、時間の浪費につながります。ディレクトリを使用するクライアントアプリケーションが必要とするファイルだけを保持するようにします。
前へ 目次 索引 DocHome 次へ
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated March 02, 2002