7장   색인화 조정

Directory Server에서 처리하는 항목 수가 늘면 검색에 사용되는 시간과 시스템 자원도 증가합니다. 색인은 검색 성능을 향상시키는 도구입니다. 이 장에서는 특정 배포에 특정 색인을 사용함으로써 발생하는 손실과 이점을 이해할 수 있도록 Directory Server 색인이 어떻게 작동하는지에 대해 설명합니다.

색인

---

색인은 조회 정보와 Directory Server 항목을 연결하며 파일 형식으로 Directory Server 데이터베이스와 함께 저장됩니다. 여기서 데이터베이스는 접미사의 물리적 표시입니다. 대부분의 배포 시 접미사와 데이터베이스는 1대1로 대응하지만 한 개의 접미사가 여러 데이터베이스에 분산될 수도 있습니다. Directory Server는 기본적으로 ServerRoot/slapd-ServerID/db/에 nsslapd-directory의 기본값으로 데이터베이스를 저장합니다. 여기에 저장된 각 데이터베이스 인스턴스는 색인화된 속성 당 한 개의 색인 파일을 갖습니다. 예를 들어, 데이터베이스의 CN 색인 파일인 example은 dc=example,dc=com 접미사 항목을 저장하며 ServerRoot/slapd-ServerID/db/example/example_cn.db3이라고 합니다.

색인화되는 항목은 클라이언트 응용 프로그램이 디렉토리 데이터에 액세스하는 방법에 따라 달라집니다. 표 7-1에는 표준 색인 유형이 간략하게 설명되어 있습니다.

표 7-1    표준 색인 유형 

색인 유형	질문 형식
근사	속성 값이 foobar와 비슷한 값을 가진 항목은?
찾아보기	이 가상 목록 보기 검색에 맞는 항목은?
동일	속성 값이 foobar인 항목은?
국가별	이 국가별 로켈에 맞는 항목은?
있음	이 속성이 있는 항목은?
하위 문자열	속성 값이 *foo*에 일치하는 항목은?

CN과 같은 특정 속성의 색인 파일에는 여러 유형의 색인이 포함될 수 있습니다. 예를 들어 CN이 동일 및 하위 문자열 유형으로 example 데이터베이스에 색인화되어 있으면 example_cn.db3에는 동일 색인과 하위 문자열 색인이 모두 포함됩니다.

다음 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.

• 각 색인 유형에 대한 개요
• 색인 작성 및 삭제 방법
• Directory Server에서 작성하는 기본 색인 목록
• Directory Server에 필요한 시스템 색인 목록

대부분의 경우 기본 색인은 검색 성능을 향상시키며 메시징과 같은 다른 응용 프로그램을 일부 지원합니다. 성능 향상을 위해 특정 기본 색인을 비활성화하거나 삭제할 수도 있습니다. 시스템 색인은 Directory Server 작동에 중요한 역할을 하므로 삭제하거나 수정하지 마십시오.

이점: 검색 시 색인의 역할

---

색인은 검색 속도를 증가시킵니다. 색인에는 값 목록이 포함되어 있으며, 각각의 값은 해당되는 항목 식별자 목록과 연결되어 있습니다. Directory Server는 색인에 있는 항목 식별자 목록을 사용하여 신속하게 항목을 조회할 수 있습니다. 항목 목록을 관리하는 색인이 없으면 Directory Server는 검색에 일치하는 항목을 찾기 위해 접미사의 모든 항목을 확인해야 합니다.

검색 요청이 어떻게 처리되는지 이해하면 색인화된 검색이 색인화되지 않은 검색보다 훨씬 간단하게 처리되는 이유를 명확히 알 수 있습니다. Directory Server에서 각 검색 요청을 처리하는 과정은 다음과 같습니다.

1. 클라이언트 응용 프로그램이 Directory Server로 검색 요청을 보냅니다.
2. Directory Server에서 이 요청을 검사하여 검색 기준이 해당 디렉토리 서버에서 처리할 수 있는 접미사인지 확인합니다. 아닌 경우 클라이언트에 오류를 반환하며, 다른 Directory Server 인스턴스에 대한 참조를 반환할 수도 있습니다.
3. Directory Server에서 해당 검색에 적합한 색인을 관리하고 있는지 확인합니다.

이러한 색인이 있으면 Directory Server는 그림 6-2와 같이 각 색인에서 검색 요청과 일치할 가능성이 있는 후보 항목을 조사합니다.

이러한 색인이 없으면 Directory Server는 데이터베이스에 있는 모든 항목에서 후보 항목 집합을 생성합니다. 대규모 배포 시에는 검색에 따라 이 단계에 상당한 시간과 시스템 자원이 소요될 수 있습니다.

4. 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    실재 색인의 예

그림과 같이 Directory Server는 entryid 속성 값을 사용하여 빠른 검색을 허용하는 항목 참조를 저장할 수 있습니다. Directory Server는 실제로 dbinstance_id2entry.db3 색인 파일을 사용하여 항목을 검색합니다. 여기서 dbinstance는 "색인"에 설명된 데이터베이스 식별자에 따라 달라집니다.

Directory Server는 있음 유형으로 색인화된 속성이 포함된 항목의 업데이트 요청을 받으면 클라이언트 응용 프로그램에 업데이트 확인 메시지를 반환하기 전에 색인에서 해당 항목을 제거할지 여부를 결정한 다음 필요한 항목을 모두 수정해야 합니다.

실재 색인에 다수의 항목이 유지관리되는 경우도 있지만 실재 색인으로 인한 손실은 일반적으로 다른 색인 유형보다 적습니다.

동일 색인

그림 7-2는 SN(성) 속성의 동일 색인으로, 이 색인이 SN 속성 값별로 해당 값을 가진 항목 목록을 유지관리하는 방법을 보여줍니다.

그림 7-2    동일 색인의 예

Directory 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 Phonetic 알고리즘의 변형을 사용하여 근사 색인을 유지관리합니다. 이 알고리즘은 속성 문자열 값을 유사한 영어 발음으로 분석합니다. 검색 요청에 따라 비교할 값도 동일한 알고리즘을 사용하여 처리됩니다. 이 알고리즘은 음절을 기초로 하기 때문에 전화 번호와 같이 숫자가 포함된 속성에는 효과가 없습니다.

이 알고리즘은 각각의 속성 값 문자열에 대해 한 개의 대상 문자열을 생성하기 때문에 영어 문자열의 "유사 발음" 색인화는 동일 색인화와 손실이 비슷합니다.

국가별 색인

국가별 색인은 특정 로켈에 대한 일치 규칙을 사용하여 색인을 유지관리합니다. 따라서 이 색인은 하위 문자열 색인 및 동일 색인과 손실이 비슷합니다.

사용자 정의 일치 규칙 서버 플러그 인을 사용하면 국가별 색인 및 기타 색인 유형에 대한 표준 지원을 확장할 수 있습니다. 사용자 정의 일치 규칙 플러그 인에 대한 자세한 내용은 Sun ONE Directory Server Plug-In API Programming Guide를 참조하십시오.

예제: 항목 색인화

아래 코드 예제와 같이 uid에 대한 동일 검색, 일반 이름(cn)과 성(sn) 속성에 대한 동일, 하위 문자열 및 근사 검색, mail 속성에 대한 동일 검색, telephoneNumber 속성에 대한 동일 및 하위 문자열 검색, description 속성에 대한 하위 문자열 검색을 위해 색인화된 접미사에 사용자 항목을 추가하는 경우를 가정해 보십시오.

---

코드 예 7-1    샘플 사용자 항목

dn: uid=yyorgens,ou=People,dc=example,dc=com

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

uid: yyorgens

givenName: Yolanda

sn: Yorgenson

cn: Yolanda Yorgenson

mail: yolanda.yorgenson@example.com

telephoneNumber: 1-650-960-1300

description: Business Development Manager, Platinum Partners

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
mail		1		1
telephoneNumber		1	11	12
description			47	47

1 이 코드 예제의 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를 다시 시작할 필요가 없습니다.

색인 목록 길이 제한

급성장하는 대규모 디렉토리 배포 시에는 색인화가 특정 색인 키에 대한 한계효용 체감점에 도달할 수 있습니다. 한계효용 체감점에 도달하면 특정 키와 관련된 목록이 너무 길어져 때때로 해당 키에서 후보 항목을 찾는 색인화되지 않은 검색을 수행하는 것보다 이 목록을 유지관리함으로써 발생하는 손실이 더 큽니다. 예를 들어, 성 속성에 대해 동일 유형으로 색인화된 큰 전화 번호부 응용 프로그램을 가정해 보십시오. 전화 번호부에 Smiths라는 이름이 너무 많아서 Smiths에 대해 색인을 유지관리하는 손실이 조회 이점보다 크다고 가정합니다. 이때 Directory Server는 Smith 성의 색인화를 중지해야 합니다. 하지만 다른 성의 색인화는 Directory Server에서 계속되어야 합니다.

Directory Server에는 이 작업을 처리하기 위한 메커니즘이 있습니다. 구성 속성을 임계값으로 설정하십시오. 특정 키에 대한 목록의 항목 수가 설정된 값에 도달하면 Directory Server는 해당 키에 대한 후보 항목을 찾기 위해 색인화되지 않은 검색을 수행하도록 지정하는 토큰으로 키 목록을 바꿉니다. 이 값은 검색 중에 확인되는 최대 후보 항목 수보다 약간 작으며 표 9-1에 설명된 것처럼 nsslapd-lookthroughlimit를 사용하여 설정됩니다.

이 메커니즘은 전역 임계값(cn=config,cn=ldbm database,cn=plugins,cn=config의 nsslapd-allidsthreshold) 설정에 사용된 구성 속성의 이름을 따서 모든 ID 임계라고 합니다. 현재 이 값은 Directory Server 인스턴스에서 전역으로 사용되며 각 색인에 대해 다르게 설정할 수 없습니다.

그림 7-5는 nsslapd-allidsthreshold보다 많은 수의 Smiths 성에 대한 색인화의 예를 보여줍니다.

그림 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%보다 훨씬 높은 값을 설정할 수 있습니다. 거의 쓰기만 지원하는 마스터와 많은 검색을 지원하는 소비자 복제본에 각각 다른 임계를 설정할 수도 있습니다. nsslapd-allidsthreshold 속성 값을 변경할 경우 모든 색인을 다시 작성해야 하므로 근시일 내에 LDIF를 사용하여 큰 디렉토리를 다시 초기화할 예정이면 초기화 직전에 값을 조정해도 됩니다. 어느 경우든지 명확한 이유가 없으면 대규모 배포에 대해서도 모든 ID 임계를 매우 높게(50,000 이상) 설정하지는 마십시오.

다음과 같이 모든 ID 임계를 변경합니다. 변경 중에는 Directory Server 인스턴스에서 서비스가 중단됩니다.

1. 해당 Directory Server 인스턴스를 중지합니다.
2. 모든 디렉토리 데이터베이스를 LDIF로 내보냅니다.

자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.

3. ServerRoot/slapd-ServerID/config/dse.ldif의 nsslapd-allidsthreshold 속성 값을 신중하게 조정합니다.
4. LDIF를 사용하여 모든 디렉토리 데이터베이스를 다시 초기화합니다.

자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.

5. 데이터베이스 캐시 크기가 이전의 모든 ID 임계값에 맞춰 조정되었으며 서버의 물리적 메모리가 충분하면 데이터베이스 캐시 크기를 임계 증가값의 25%만큼 늘리는 것이 좋습니다.

즉, 모든 ID 임계를 4000에서 6000으로 늘리는 경우 증가된 색인 목록 크기를 수용하기 위해 데이터베이스 캐시 크기를 약 12.5%만큼 늘릴 수 있습니다. 생산 서버에 변경 사항을 적용하기 전에 실제 테스트를 통해 최적 크기를 확인합니다. 데이터베이스 캐시 조정에 대한 자세한 내용은 6장 "캐시 크기 조정"을 참조하십시오.

6. Directory Server 인스턴스를 다시 시작합니다.

색인 단편화 문제 해결

대규모 색인과 높은 업데이트 비율을 지원하는 Directory Server 인스턴스에서 과도한 색인 키 단편화는 심각한 문제가 될 수 있습니다. 색인 키 단편화가 과도하면 데이터베이스 크기는 같아도 성능이 저하됩니다. 과도한 색인 키 단편화로 인해 서버 성능이 크게 저하된 경우 영향을 받은 색인을 다시 생성하여 단편화를 줄이는 것이 좋습니다.

색인 작성에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.