큰 목록 디자인 및 목록 성능 최대화(SharePoint Server 2010)

 

적용 대상: SharePoint Server 2010

마지막으로 수정된 항목: 2016-11-30

이 문서에서는 큰 문서 라이브러리 및 목록의 성능에 대한 정보를 제공합니다. 여기서 제시하는 권장 사항은 Microsoft SharePoint Server 2010을 사용하여 수행한 일련의 성능 테스트 결과를 통해 확인된 것입니다. 이 문서에서는 큰 목록의 성능 특성과 서로 다른 각 구성이 큰 목록 및 팜의 성능에 주는 영향에 대해 중점적으로 설명합니다. SharePoint Server 2010에는 새롭게 개선된 기능이 다수 포함되어 있어 큰 목록을 보다 쉽게 만들고 사용할 수 있지만, 큰 목록을 만들고 구현하려면 면밀한 계획이 필요합니다. 또한 이 과정에서 정보 아키텍처, 성능, 재해 복구, 통제 등의 다양한 요인을 고려해야 합니다. 이 문서에서는 큰 목록을 구현하는 데 사용되는 정보 아키텍처 및 기능과, 특정 구성이 성능에 주는 영향에 대해 다룹니다.

큰 목록을 만들 때는 목록의 성능에 영향을 줄 수 있는 몇 가지 주요 디자인 관련 사항을 결정해야 합니다. 여기에는 권한, 목록에 추가할 열의 수, 보기의 조회 열 수, 목록을 구성하는 데 사용되는 폴더와 인덱스 등이 포함됩니다. 이러한 사항을 어떻게 결정하느냐에 따라 목록의 성능에 영향을 주게 되며, 목록의 크기가 커질수록 이러한 요인도 더 큰 영향을 줍니다. 이 문서에서는 각 디자인 결정 사항이 큰 목록의 성능에 주는 영향에 대해 설명합니다. 이 정보를 참고하면 효율적인 사용자 환경을 제공하고 업무 요구 사항을 충족하는 동시에 성능 요구 사항도 만족하는 큰 목록을 적절하게 디자인할 수 있습니다.

이 문서에서는 SharePoint Server 2010과 관련된 설명을 제공하지만, 관련 제한과 한도는 Microsoft SharePoint Foundation에도 적용됩니다. 이 문서에서는 큰 목록 사용 환경을 크게 향상시키는 여러 기능에 대해 다루는데, 이러한 기능은 SharePoint Server 2010에서만 사용 가능합니다. 여기서는 SharePoint Foundation과 SharePoint Server를 구분하지 않습니다.

이 문서의 내용

• 쿼리 방법 이해

• 큰 목록 시나리오 예제

• 큰 목록 및 SharePoint Server 2010

• 성능 측정 및 테스트 방법

• 제한 및 한도

• 기타 한도

• 큰 목록과 일반 목록의 차이

• 큰 목록 디자인 및 구현

• 결론

쿼리 방법 이해

목록 보기(메타데이터 탐색 사용), 콘텐츠 쿼리 웹 파트 및 검색의 세 가지 주요 방법으로 목록 데이터에 액세스할 수 있습니다. 각 방법에는 장단점과 적절한 용도가 있습니다.

목록 보기(메타데이터 탐색 사용)

목록 보기는 항상 Microsoft SQL Server 데이터베이스에 액세스하므로, 다른 방법에 비해 쿼리 성능이 저하되고 SQL Server 리소스에 대한 부하가 높아집니다. 또한 목록 보기는 가장 많은 HTML을 렌더링하므로 다른 방법에 비해 페이지 로드 시간도 느립니다. 그러나 보기를 구성하고, 데이터를 동적으로 필터링하고, 문서 작업(예: 버전 관리, 속성 편집)을 수행하는 사용자의 경우에는 목록 보기가 가장 효율적인 환경을 제공합니다. 메타데이터 탐색을 통해 목록 보기 결과를 필터링할 수 있습니다. 다양한 열 데이터를 사용하고 목록 항목 작업에 액세스해야 하는 경우에는 목록 보기를 사용해야 하며, 읽기 및 쿼리를 많이 수행하는 경우에는 다른 쿼리 방법을 고려해야 합니다.

콘텐츠 쿼리 웹 파트

콘텐츠 쿼리 웹 파트에는 정적으로 구성된 데이터 보기가 표시되는데, 이 보기는 성능을 개선하기 위해 포털 사이트 맵 공급자를 사용하여 캐시됩니다. 콘텐츠 쿼리 웹 파트는 캐시되며 가장 적은 HTML을 렌더링하므로 페이지 로드 시간이 빠르며 한 페이지에 여러 쿼리를 쉽게 포함할 수 있습니다. 관련 목록 항목, 문서 또는 페이지에 대한 링크를 표시하려면 콘텐츠 쿼리 웹 파트를 사용해야 합니다. 콘텐츠 쿼리 웹 파트를 캐시하지 않도록 구성할 수도 있지만, 처리량 요구 사항이 낮은 페이지나 캐시가 유용하지 않은 페이지(예: 페이지에 액세스하는 사용자에 따라 쿼리가 변경되는 페이지)의 경우에만 이러한 구성을 사용해야 합니다.

검색

검색 웹 파트를 사용하면 실시간으로 업데이트를 확인하고 속성을 편집하는 대신 콘텐츠 검색용으로 최적화된 시스템에서 쿼리를 실행할 수 있습니다. 정적 쿼리 또는 사용자 지정 쿼리를 사용하도록 검색 웹 파트를 구성할 수 있습니다. 검색 웹 파트는 성능은 뛰어나지만 제공되는 데이터는 가장 최근 크롤링 시점의 데이터입니다. 즉, 해당 결과가 목록 보기 및 콘텐츠 쿼리 웹 파트의 결과보다 오래된 것입니다.

큰 목록 시나리오 예제

몇 가지 일반적인 큰 목록 시나리오가 있으며, 시나리오에 따라 디자인 관련 결정을 다르게 내립니다. 예를 들어 사용자가 빈번하게 콘텐츠를 추가하고 속성을 업데이트하는 공동 작업 큰 목록 시나리오의 경우에는 목록에 항목이 수백만 개와 같이 매우 많이 포함되어 목록 크기가 매우 커지도록 해서는 안 됩니다. 콘텐츠가 자주 업데이트 및 변경되는 상황에서 이와 같이 목록이 커지면 콘텐츠를 필터링하기가 어렵기 때문입니다. 구조화되지 않은 문서 라이브러리를 사용하는 경우에는 이 문서에서 SQL Server의 성능을 유지하는 제한 및 한도를 확인할 수 있습니다. 아래 표에는 큰 목록 시나리오의 고려 사항이 나와 있습니다.

시나리오	목록 크기	관리	읽기/업데이트/추가 비율	새 콘텐츠	사용자
구조화되지 않은 문서 라이브러리	항목 수백 개	관리자 없음	읽기 빈도 높음/추가 및 업데이트는 적절하게 균형 조정됨	수동 업로드	항목 수십 개
공동 작업용 큰 목록 또는 라이브러리	항목 수천 개	비공식적 관련 주제 소유자	읽기 빈도 높음/추가보다 업데이트 빈도가 높음	수동 업로드	항목 수백 개
구조화된 큰 저장소	항목 수만 개	전담 콘텐츠 관리자	읽기 빈도 매우 높음/추가 빈도는 낮고 업데이트 빈도는 매우 낮음	전송 및 업로드	항목 수만 개
대형 보관함	항목 수백만 개	콘텐츠 관리자 팀	읽기 및 업데이트 빈도 낮음, 추가 빈도 높음	전송	항목 수만 개

구조화되지 않은 문서 라이브러리

구조화되지 않은 문서 라이브러리는 팀이나 작업 그룹에서 사용되는 경우가 많으며, 일반적으로 문서가 수십 개에서 수백 개 포함됩니다. 이러한 라이브러리의 경우 계획을 세우지 않으면 목록 보기 임계값보다 커져서 열 추가 등의 작업에 영향을 줄 수 있습니다. 보기의 항목 수가 5천 개를 초과하는 경우 발생할 수 있는 문제 중 하나는 사용자에게 목록 보기 임계값 예외가 발생하는 것입니다. 목록 보기 임계값에 거의 도달한 라이브러리를 모니터링하면 이러한 문제를 줄일 수 있습니다. 문서 라이브러리의 목록 보기 임계값에 거의 도달했음을 나타내는 계기가 문서 라이브러리의 라이브러리 설정 페이지에 표시됩니다.

이 시나리오의 경우 일반적으로 사용자가 수십 명에서 수백 명이지만 동시 사용자의 수는 적습니다. 따라서 단일 라이브러리 내의 로드는 거의 문제가 되지 않습니다. 그러나 이러한 라이브러리가 여러 개 있는 경우에는 특정 인스턴스를 지원하는 계획보다는 해당 라이브러리 전체가 포함되는 규모를 지원하는 데 주력해야 합니다.

공동 작업용 큰 목록 또는 라이브러리

공동 작업용 큰 목록은 항목 수가 수백 개에서 수천 개이며, 현재 사용 중인 많은 양의 콘텐츠를 저장하는 데 사용됩니다. 이러한 목록에는 보통 지식 관리 솔루션, 엔지니어링 라이브러리 및 영업/마케팅 참고 자료 저장소가 포함됩니다. 사용자들은 콘텐츠를 활발하게 추가 및 편집하므로 읽기 및 쓰기 작업이 많이 수행됩니다. 라이브러리의 구성을 유지하기 위해 구조 및 관리 방식을 적용할 수 있습니다. 그러나 사용자가 많은 작업을 수행하므로 관리자가 통제하기 어려운 사고가 발생하여 목록이 예상보다 빠르게 또는 원래 계획했던 한도보다 커지기가 쉽습니다. 이러한 유형의 저장소에는 수백에서 수천 명의 사용자가 포함될 수 있으며, 동시 사용자의 수도 수십 명에서 수백 명에 달할 수 있습니다.

구조화된 저장소 또는 보관함에 비해 공동 작업용 큰 목록은 폴더 추가/삭제, 콘텐츠 형식/열 추가, 콘텐츠 다시 구성 등 관리자에 의한 변경 작업이 수행될 가능성이 높습니다. 목록 크기가 커지면 목록 보기 임계값에 의해 이러한 작업이 제한될 수 있습니다.

구조화된 큰 저장소

구조화된 큰 저장소에는 수천 개에서 수십만 개의 항목이 포함됩니다. 콘텐츠는 최종 버전인 경우가 많으며 워크플로 등의 사용자 또는 시스템 프로세스에 의해 전송됩니다. 이러한 저장소는 일반적으로 부서별 레코드 보관함, 중요한 문서 저장소 및 웹 페이지에 표시되는 최종 문서 저장소로 사용됩니다. 대개 콘텐츠가 구조화되며 높은 수준으로 관리되므로 목록 크기 증가를 쉽게 제어할 수 있습니다. 이 시나리오의 경우 동시 사용자는 수십 명에서 수백 명이고 사용자 층은 수천 명이며, 읽기의 비율이 쓰기보다 훨씬 높습니다. 그러나 이 시나리오에서도 콘텐츠가 업데이트될 수 있으며 자주 추가 및 삭제될 수도 있습니다. 구조화된 큰 저장소의 대표적인 예로는 사업부 또는 조직의 지식 관리 저장소를 들 수 있습니다.

이 시나리오에서는 솔루션을 실제로 사용하기 전에 사용자의 요구를 철저하게 파악하고 포괄적인 테스트를 수행하는 것이 중요합니다. 이러한 과정을 거쳐 실제로 제공되는 솔루션은 많은 양의 콘텐츠로 채워지기 전에 이미 완성된 최종 상태입니다. 예를 들어 적절한 콘텐츠 검색 환경을 제공하려면 올바른 메타데이터 탐색 계층 구조와 필터 구성을 제공해야 할 수 있습니다.

대형 보관함

대형 보관함에는 수천 개에서 수백만 개의 항목이 목록 하나 또는 여러 개나 여러 사이트 모음에 포함될 수 있습니다. 이 시나리오의 경우 보통 읽기 및 업데이트 비율이 낮으며, 규정 준수 또는 기타 이유로 인해 보관해야 하는 문서(예: 법적 요구 사항 충족을 위해 7년 동안 보관해야 하는 문서)의 장기 저장소로만 사용됩니다. 이 시나리오에서는 문서 삭제 및 전송의 처리량을 높게 유지해야 합니다. 콘텐츠를 검색할 때는 주로 검색을 사용합니다.

큰 목록 및 SharePoint Server 2010

Office SharePoint Server 2007에서 큰 목록에 사용할 수 있었던 기능을 SharePoint Server 2010에서도 사용할 수 있으며, 이러한 기능 중 대부분은 더욱 효율적인 성능을 폭넓게 제공하도록 개선되었습니다. 또한 SharePoint Server 2010에는 큰 목록의 성능을 높이고 사용자가 큰 목록을 효율적으로 사용할 수 있도록 하는 새 기능도 다시 포함되어 있습니다. 이 섹션에서는 SharePoint Server 2010의 새로운 기능 및 개선된 기능에 대해 간략하게 설명합니다.

개선된 기능

다음 섹션에서는 Microsoft Office SharePoint Server 2007에서 제공되었으며 SharePoint Server 2010에서 개선된 기능에 대해 설명합니다.

콘텐츠 쿼리 웹 파트

목록, 콘텐츠 형식 및 열을 필터링하여 결과를 표시하도록 콘텐츠 쿼리 웹 파트를 구성할 수 있습니다. 결과를 정렬할 수 있으며 표시할 열을 선택할 수 있습니다. 이처럼 콘텐츠 쿼리 웹 파트는 웹 페이지에서 큰 목록 콘텐츠를 표시하는 데 적합합니다. 일반적으로 콘텐츠 쿼리 웹 파트는 캐시되므로 페이지 로드 시간이 빠르며 데이터베이스 로드는 줄어듭니다. 지식 관리 시나리오에서는 게시 페이지에서 콘텐츠 쿼리 웹 파트를 사용하여 웹 페이지의 내용과 관련된 문서의 링크를 표시할 수 있습니다.

SharePoint Server 2010에서는 다음과 같은 주요 시나리오에서 개선된 성능을 제공합니다.

• 인덱스를 보다 효율적으로 활용할 수 있도록 단일 목록 쿼리 최적화

• 사용자가 쓰기 작업을 수행할 때 캐시 사용률을 높이기 위한 기본 설정과 무효화 및 새로 고침 알고리즘 개선

검색

SharePoint Server 2010에서는 검색 용어 구체화 패널과 개선된 확장성(1억 개 문서에 대한 초 단위 이하 쿼리 대기 시간 지원)을 포함하는 새로운 검색 기능을 제공합니다. 또한 SharePoint Server 2010 Search보다 폭넓은 검색을 수행하는 데 사용할 수 있는 Microsoft FAST Search Server 2010 for SharePoint도 포함되어 있습니다.

큰 목록에서 콘텐츠를 찾는 데 사용할 수 있는 새롭게 개선된 검색 기능으로는 자유 텍스트 쿼리의 부울 연산자 지원, 개선된 연산자 지원(예: 같음, 보다 작음, 보다 큼 등), 범위 구체화, 키워드와 속성에 대한 접두사 일치 등이 있습니다. 예를 들어 "share*"를 쿼리하면 "SharePoint"가 포함된 결과를 찾는 식입니다. 또한 검색 과정에서 사용자가 쿼리에 대해 입력한 내용을 바탕으로 권장 항목을 표시하는 쿼리 추천 단어 기능도 있습니다. 검색 사용자 인터페이스 역시 개선되어 관련 검색, 최상의 선택, 관련 사용자 및 키워드 구체화용 패널이 포함되어 있습니다.

SharePoint Server 2010 Search에서는 확장 기능도 개선되었습니다. 즉, SharePoint Server 2010 Search는 인덱스 서버, 크롤링 서버 및 쿼리 서버를 수평 확장할 수 있습니다. 또한 새로운 인덱스, 향상된 복구 기능, 높아진 가용성 등의 개선 기능도 제공됩니다. FAST Search Server 2010 for SharePoint에는 SharePoint Server 2010 Search의 기능이 모두 포함되어 있을 뿐 아니라 매우 까다로운 요구를 충족하기 위한 확장성, 엔터티 추출, 조정 가능한 관련성 순위, 시각적 최상의 선택, 축소판 그림, 미리 보기 등의 기능이 추가되었습니다.

문서 센터 및 레코드 센터 사이트 서식 파일

문서 센터와 레코드 센터는 구조화된 저장소를 만드는 데 사용할 수 있는 SharePoint Server 2010 사이트 서식 파일입니다. 문서 센터 사이트 서식 파일에는 로그인한 사용자별로 관련 결과를 반환하는 미리 구성된 콘텐츠 쿼리 웹 파트와 메타데이터 탐색이 구성된 문서 라이브러리 등의 기능이 포함되어 있습니다.

레코드 센터 사이트 서식 파일은 문서 센터 사이트 서식 파일과 비슷하지만, 문서 라우팅용 콘텐츠 구성 도우미 기능을 사용할 수 있으며 레코드 라이브러리(추가되는 항목이 자동으로 레코드로 선언되어 삭제할 수 없음)를 포함합니다. 문서 파서가 사용할 수 없도록 설정되어 전송되는 콘텐츠의 충실도가 유지되는 기본 사이트 서식 파일은 레코드 센터 사이트 서식 파일뿐입니다. 이처럼 문서 파서가 사용하지 않도록 설정되어 있어 특정 작업의 성능에 영향을 주는 레코드 센터 사이트 서식 파일은 다른 사이트 서식 파일에 비해 대형 문서 저장소(항목 수천만 개)로 사용하기에 적합합니다.

새로운 기능

이 섹션에서는 큰 목록 및 목록 성능을 관리하는 데 사용할 수 있는 SharePoint Server 2010의 새로운 기능에 대해 설명합니다.

콘텐츠 구성 도우미

모든 사이트에서 특정 문서 라이브러리, 폴더 또는 다른 사이트로 콘텐츠를 라우팅하는 데 콘텐츠 구성 도우미를 사용할 수 있습니다. 콘텐츠 구성 도우미를 통해 메타데이터 속성을 기반으로 콘텐츠용 폴더를 자동으로 만들 수 있습니다. 사용자는 파일 계획 내에서 콘텐츠가 저장되는 위치에 신경 쓰지 않고 다른 사이트에서 콘텐츠 구성 도우미로 콘텐츠를 전송할 수 있습니다. 콘텐츠 구성 도우미를 사용하여 콘텐츠를 서로 다른 폴더에 균형 있게 분산시킴으로써 각 폴더의 최대 크기를 자동으로 유지 관리할 수 있습니다. 지정된 크기 제한에 도달하면 추가 항목을 포함할 수 있도록 새 하위 폴더가 만들어집니다.

메타데이터 탐색

메타데이터 탐색은 SharePoint Server 2010에서 새롭게 제공되는 기능으로, 사용자가 필요한 콘텐츠를 쉽게 찾기 위해 목록을 동적으로 필터링할 수 있도록 합니다. 사용자는 메타데이터 탐색 기능을 통해 필터 옵션을 선택할 수 있으며, 그러면 해당 기능이 최대한 효율적인 방식으로 쿼리 수행 작업을 처리합니다. 메타데이터 탐색은 두 부분으로 구성되는데, 그 중 하나는 사용자가 탐색 계층 구조 및 주요 필터가 포함된 목록을 필터링할 수 있도록 하는 탐색 컨트롤 집합이고 나머지 하나는 쿼리 다시 정렬 및 다시 시도용 메커니즘입니다.

메타데이터 탐색에는 인덱스를 통해 쿼리 수행을 효율적으로 시도하는 다시 시도 및 대체 논리가 있습니다. 너무 많은 결과를 반환하는 쿼리는 대체되어 성능 개선을 위해 결과 하위 집합을 반환합니다. 적절한 쿼리를 수행할 수 없으면 대체가 수행되어 제한된 결과 집합에 대한 필터링이 수행됩니다. 메타데이터 탐색은 인덱스를 자동으로 만듭니다. 이처럼 다시 시도, 대체 및 인덱스 관리 기능을 제공하는 메타데이터 탐색은 큰 목록을 효율적으로 사용하는 데 있어 매우 중요한 요소입니다. 필터링 메커니즘에는 탐색 계층 구조와 주요 필터의 두 가지 종류가 있습니다.

탐색 계층 구조는 트리 컨트롤을 사용하여 폴더, 콘텐츠 형식, 선택 필드 또는 관리되는 메타데이터 용어 집합의 계층 구조를 탐색합니다. 따라서 사용자가 트리 컨트롤을 사용해 폴더를 탐색하는 방법과 같이 메타데이터 계층 구조를 탐색할 수 있습니다. 사용자가 관리되는 메타데이터 열에 대해 계층 구조에서 항목을 선택하면 지정된 용어 또는 모든 하위 용어와 일치하는 모든 항목이 표시됩니다. 이러한 방식은 하위 항목 포함이라고 하며, 관리되는 메타데이터 용어 집합에 연결된 필드에서 사용할 수 있습니다. 사용자는 항목을 다시 선택하여 하위 용어는 포함하지 않고 해당 용어로만 필터링할 수 있습니다. 모든 메타데이터 탐색 쿼리는 재귀 쿼리이며, 목록의 모든 폴더에서 결과를 표시합니다.

주요 필터는 계층 구조 내에서 결과 추가 필터링을 수행하도록 구성할 수 있습니다. 예를 들어 수정한 사람 열을 주요 필터로 추가한 다음 사용자 이름을 입력하면 수정한 사람이 입력한 사용자와 일치하는 결과를 확인할 수 있습니다. 자세한 내용은 메타데이터 탐색 및 필터링(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x412)(영문일 수 있음)을 참조하십시오. 아래 그림에는 메타데이터 탐색 계층 구조 및 주요 필터의 예가 나와 있습니다.

관리되는 메타데이터

관리되는 메타데이터는 SharePoint Server에 정보 아키텍처를 추가하는 새로운 기능 집합입니다. 관리되는 메타데이터 기능에는 관리되는 메타데이터 서비스라는 공유 서비스가 포함됩니다. 이 서비스를 사용하여 SharePoint Server 2010 배포 전체에서 다시 사용할 수 있는 용어 집합을 저장할 수 있습니다. 관리되는 메타데이터 기능에 포함되는 항목은 다음과 같습니다.

• 단순 계층 구조 또는 상세 계층 구조를 지원하는 용어 집합

• 용어 집합을 사용 가능한 속성으로 활용하는 관리되는 메타데이터 열 유형

• 모든 사용자가 새 용어를 추가할 수 있도록 개방되거나 특정 사용자만 관리할 수 있도록 제한되는 용어 집합

관리되는 메타데이터 열과 용어 집합을 사용해 콘텐츠를 구성하면 콘텐츠 쿼리 웹 파트, 메타데이터 탐색 등의 기능을 통해 사용자가 콘텐츠를 찾고 검색하도록 할 수 있습니다. 또한 관리되는 메타데이터는 문서를 분류하는 데 사용할 수 있는 키워드를 추가하므로 일반 검색 쿼리도 보다 쉽게 수행할 수 있습니다. 검색 구체화 패널에서 관리되는 메타데이터를 사용할 수 있습니다. 아래 그림에 관리되는 메타데이터 탐색의 예가 나와 있습니다.

제한 및 한도

SharePoint Server 2010에는 팜 성능을 유지 관리하는 데 사용할 수 있는 다수의 구성 가능한 한도가 도입되었습니다. 예를 들어 이제는 웹 응용 프로그램 수준에 구성 가능한 제한 및 한도가 있습니다. 이러한 항목은 개별 사용자나 프로세스의 작업으로 인해 팜 성능이 저하되지 않도록 하기 위해 추가된 것입니다. 예를 들어 목록 보기 임계값은 특정 수보다 많은 목록 항목에 대해 쿼리를 수행하지 못하도록 하는 한도입니다.

복합 인덱스

큰 목록에서는 인덱스가 중요한 역할을 합니다. SharePoint Server 2010에서는 일반적으로 두 개의 열에 대해 쿼리를 수행할 때 복합 인덱스를 사용하면 유용합니다. 쿼리 시 열을 하나만 선택하면 기준이 부족할 수 있기 때문입니다. 보기에서는 복합 인덱스가 사용되지 않지만 메타데이터 탐색에서는 사용됩니다. 제한 상황이 발생하면 메타데이터 탐색 논리가 쿼리를 다시 시도하여, 선택한 필터 조건에 대해 인덱스 하나와 해당하는 복합 인덱스를 사용해 쿼리에 맞는 전체 또는 부분 결과를 찾을 수 있습니다.

개발자 대시보드

개발자 대시보드에는 각 페이지 로드에 대한 세부 진단 정보가 표시됩니다. 기본적으로 대시보드는 해제되어 있지만 수동으로 설정하거나 항상 표시되도록 구성할 수 있습니다. 개발자 대시보드를 설정하는 경우 데이터베이스 쿼리, 로드 시간 및 오류에 대한 정보를 확인하는 데 사용할 수 있습니다. 개발자 대시보드를 사용하면 성능 문제를 보다 쉽고 빠르게 분석 및 진단할 수 있습니다. 아래 그림에는 개발자 대시보드가 나와 있습니다. 큰 목록의 경우 개발자 대시보드에 메타데이터 탐색 기능이 표시되며, 다시 시도 및 부분 결과 반환에 사용되는 인덱스 목록이 포함된 제한 조건은 작업 트리의 왼쪽에 나타나고 각각 다르게 인덱싱된 SQL Server 쿼리 시도는 목록의 오른쪽에 나타납니다.

개발자 대시보드는 사용자 지정 웹 파트 및 쿼리를 디버깅할 때도 유용합니다. 개발자 대시보드를 사용하도록 설정하는 방법에 대한 자세한 내용은 블로그: 개체 모델/Powershell을 사용하여 개발자 대시보드 설정(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x412)(영문일 수 있음)을 참조하십시오.

콘텐츠 반복기

콘텐츠 반복기 개발자 API는 큰 목록의 코드를 간단하게 작성할 수 있도록 하며, 새 목록 보기 임계값 한도를 지정하는 데 특히 중요합니다. 콘텐츠 반복기를 사용하는 경우 전체 데이터 집합에 대해 작업을 수행하는 대신 작업을 수행할 소규모 콘텐츠 집합을 검색할 수 있습니다. 이를 통해 목록 보기 임계값을 초과하는 작업을 방지할 수 있습니다.

Remote BLOB Storage

기본적으로 SharePoint Server 2010에서는 파일(BLOB(Binary Large Object)) 데이터를 SQL Server 데이터베이스에 저장합니다. 콘텐츠 데이터베이스는 대부분 BLOB 데이터로 구성됩니다. RBS(Remote BLOB Storage)를 사용하면 이 데이터를 SQL Server 외부에 저장할 수 있으므로 저렴한 저장소 옵션을 사용하고 콘텐츠 데이터베이스 크기를 줄일 수 있습니다. Remote BLOB Storage는 SQL Server 2008용 추가 기능 팩으로 통합된 라이브러리 API 집합입니다. Remote BLOB Storage API를 사용하려면 타사 원격 BLOB 저장소 공급자가 필요합니다.

성능 측정 및 테스트 방법

이 섹션에서는 이 문서에서 설명하는 테스트에 사용된 테스트 방법에 대해 설명합니다. 이 방법에서 변형된 방식의 경우 해당 데이터가 있으면 별도로 언급합니다.

하드웨어 및 팜 구성

아래 그림 및 표에 테스트 팜 구성이 지정되어 있습니다. 이 테스트 구성에서는 다음과 같은 두 가지 측면이 대부분의 실제 배포와 크게 다릅니다.

• 도메인 컨트롤러에 병목 현상이 발생하지 않도록 NTLM 인증을 사용합니다. 이를 통해 성능이 약간 향상됩니다.

• 응용 프로그램 서버가 로깅 데이터베이스용으로 사용되는 SQL Server 인스턴스를 포함합니다. 테스트에서는 로깅 수준이 실제 배포보다 훨씬 높기 때문에, 주 SQL Server 인스턴스의 로드를 줄이기 위해 이러한 구성이 사용되었습니다.

컴퓨터 이름	웹 서버 2대	응용 프로그램 서버 1대	데이터베이스 서버 1대
역할	프런트 엔드 웹 서버	응용 프로그램 서버	SQL Server 인스턴스
프로세서	2개 프로세서(4개 코어, 2.33GHz)	2개 프로세서(4개 코어, 2.33GHz)	4개 프로세서(2개 코어, 3.19GHz)
RAM	8GB	8GB	32GB
운영 체제	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64
저장소 및 구조(SQL Server 디스크 구성 포함)	50+18+205GB	50+18+300GB	디스크 배열 - 450GB(15K RPM) 디스크 15개
NIC 수	2	2	2
NIC 속도	1기가비트	1기가비트	1기가비트
인증	NTLM	NTLM	NTLM
소프트웨어 버전	SharePoint Server 2010(시험판)	SharePoint Server 2010(시험판) SQL Server 2008 CTP 3	SQL Server 2008 CTP 3
SQL Server 인스턴스의 수	해당 없음	1	1
부하 분산 유형	하드웨어	해당 없음	해당 없음
출력 캐시
개체 캐시 설정
BLOB 캐시 설정
ULS 로깅 수준	중간	중간	중간
사용 현황 데이터베이스 위치		X
사용 현황 데이터베이스 설정(기록되는 내용)
IRM 설정	없음	없음	없음
바이러스 백신 설정	없음	없음	없음

데이터베이스 형식	데이터베이스 수	RAID 구성
임시 DB	1	0
구성 DB	1	0
콘텐츠 DB #1	1	0
프로필 DB	1	0
검색 DB	1	0
분류 DB	1	0

테스트 로드

테스트 작업을 일반적으로 혼합하여 최적의 로드 지점(안전 영역)에서 테스트를 수행했습니다. 또한 특정 변경 사항을 측정하기 위해 변수가 변경된 각 지점에서 테스트를 수행했습니다. 그리고 최적의 로드 지점을 찾기 위해 스레드를 더 추가하여 환경을 포화 상태로 만들었습니다. 단, 다음 수치는 유지했습니다.

• 75번째 백분위수 대기 시간: 1초 미만

• 프런트 엔드 웹 서버 CPU: 50% 미만

• SQL Server CPU: 50% 미만

• 응용 프로그램 서버 CPU: 50% 미만

• 실패율: 0.01% 미만

테스트 정의

아래 표에는 테스트 정의와 각 테스트에 사용된 프로세스에 대한 간략한 설명이 나와 있습니다.

테스트 이름	테스트 설명
문서 업로드	문서를 업로드합니다. 문서 속성을 편집 및 업데이트합니다.
문서 업로드 및 라우팅	문서를 업로드합니다. 문서 속성을 편집 및 업데이트합니다. 라우팅 규칙과 일치하는 문서를 라우팅합니다.
문서 다운로드	문서를 다운로드합니다.
문서 라이브러리 액세스	문서 라이브러리 목록 보기 페이지에 액세스합니다.
콘텐츠 쿼리 웹 파트가 포함된 홈 페이지 액세스	콘텐츠 쿼리 웹 파트 3개가 포함된 문서 센터 사이트 홈 페이지에 액세스합니다. 캐시된 콘텐츠 쿼리 웹 파트가 등급이 가장 높은 15개 문서를 반환합니다. 캐시된 콘텐츠 쿼리 웹 파트가 가장 최근 문서 15개를 반환합니다. 캐시되지 않은 콘텐츠 쿼리 웹 파트가 현재 사용자에 의해 수정된 최신 항목 15개를 반환합니다.
관리되는 메타데이터 대체 쿼리	5천 개보다 많은 결과를 반환하는 목록 보기 쿼리(단일 값 관리되는 메타데이터 열을 기준으로 필터링)를 수행합니다.
관리되는 메타데이터 선택 쿼리	1천 개의 결과를 반환하는 목록 보기 쿼리(단일 값 관리되는 메타데이터 열을 기준으로 필터링)를 수행합니다.
콘텐츠 형식 대체 쿼리	5천 개보다 많은 결과를 반환하는 목록 보기 쿼리(콘텐츠 형식을 기준으로 필터링)를 수행합니다.
콘텐츠 형식 선택 쿼리	1천 개의 결과를 반환하는 목록 보기 쿼리(콘텐츠 형식을 기준으로 필터링)를 수행합니다.

테스트 혼합

각 테스트 혼합은 서로 다르게 구성되었으며 Visual Studio Test System을 사용하여 테스트를 수행했습니다. 각 테스트에서는 특정 데이터 요소를 채운 다음 테스트 혼합을 실행했습니다(준비 2분, 데이터 수집 10분). 이 문서에서 제공하는 결과는 이 10분 동안의 평균값입니다. 아래 표에는 특정 테스트 혼합에서 각 솔루션의 비율이 나와 있습니다.

솔루션 이름	이 혼합에서 솔루션의 비율
문서 업로드(문서 속성 편집 포함)	20
문서 다운로드	20
문서 라이브러리 액세스	20
콘텐츠 쿼리 웹 파트가 포함된 홈 페이지 액세스	10
관리되는 메타데이터 대체 쿼리(결과 5천 개 초과)	5
관리되는 메타데이터 선택 쿼리(결과 100개)	10
콘텐츠 형식 대체 쿼리(결과 5천 개 초과)	5
콘텐츠 형식 선택 쿼리(결과 100개)	10

제한 및 한도

한도를 적용하여 팜 성능을 저하시키는 작업을 방지합니다. 이러한 기본값은 테스트를 걸쳐 적절하게 선택되었습니다. 목록 보기 임계값과 같은 일부 한도의 경우에는 값을 변경하지 않는 것이 좋습니다. 이러한 한도를 변경하는 경우의 영향을 철저하게 고려하십시오. 이러한 한도로 인해 작업을 수행할 수 없는 경우에는 성능이 낮은 작업을 수행할 수 있도록 한도를 변경하기보다는 좀 더 효율적으로 인덱싱된 방식으로 작업을 실행하도록 변경하는 것을 우선적으로 고려해야 합니다. 이 섹션에서 다루는 대부분의 한도와 제한은 중앙 관리에서 웹 응용 프로그램 관리로 이동한 다음 특정 웹 응용 프로그램의 리본 메뉴에서 일반 설정 - 리소스 제한을 선택하면 구성할 수 있습니다.

목록 보기 임계값

SharePoint Server 2010에서는 수천만 개의 항목이 포함된 문서 라이브러리 및 목록을 지원합니다. 폴더, 표준 보기, 사이트 계층 구조 및 메타데이터 탐색을 사용하여 매우 큰 문서 라이브러리를 만들 수 있습니다. 목록 보기 또는 CAML(Collaborative Application Markup Language) 쿼리를 사용하여 큰 목록에서 데이터를 검색하려면 폴더나 인덱스 중 하나 또는 둘 다를 사용하여 데이터를 분할해야 합니다. 그렇지 않은 경우 검색은 데이터에 효율적으로 액세스하기 위한 메커니즘으로만 사용 가능합니다. 단일 문서 라이브러리가 지원할 수 있는 항목 수는 문서와 폴더를 구성하는 방법, 저장된 문서의 종류와 크기, 문서 라이브러리 사용법, 그리고 문서 라이브러리의 열 수에 따라 달라질 수 있습니다.

기본적으로 목록 보기 임계값은 5천 개가 넘는 항목을 반환하는 쿼리 또는 항목이 5천 개보다 많이 포함된 목록에 열을 추가하는 작업 등 5천 개보다 많은 항목에 대한 작업을 수행하지 못하도록 합니다. 이 기본값은 직접 구성할 수는 있지만 그대로 유지하는 것이 좋습니다. 항목 수가 5천 개보다 많은 목록에 대해 성능이 낮은 쿼리를 사용하는 경우 이 한도를 높이면 전체 처리량이 크게 떨어질 수 있습니다.

비인덱스 쿼리 또는 목록에 열 추가와 같은 일부 작업의 경우 목록의 항목 수에 비례하는 시간과 리소스가 필요합니다. 작은 목록의 경우에는 항목 수가 적으므로 작업이 빠르게 진행되기 때문에 문제가 없습니다. 그러나 목록의 크기가 커지면 이러한 작업에 시간이 오래 걸리고 더 많은 리소스가 사용됩니다. 이 경우 목록 보기 임계값은 이러한 작업에 제한을 적용하지 않고 그대로 실행하는 대신 해당 작업을 차단합니다. 목록 보기 임계값은 고속도로의 가드레일 개념으로 생각할 수 있습니다. 즉, 이 임계값은 데이터 액세스 방법 및 쿼리를 변경해야 하거나 팜 사용량이 적을 때 작업을 수행해야 함을 알려 줍니다.

목록 보기 임계값은 쿼리 등의 데이터베이스 작업에서 한 번에 처리할 수 있는 최대 목록/라이브러리 항목 수이며, 기본적으로 5천 개 항목으로 설정됩니다. 이 한도는 큰 목록의 경우 중대한 영향을 주는데, 이 임계값의 정의에 따르면 큰 목록은 이 한도보다 많은 수의 항목을 포함하는 목록이기 때문입니다. 이 한도를 초과하는 작업은 제한됩니다. 이 한도를 초과하는 목록에서 인덱스를 만드는 등의 작업은 5천 개 이상의 항목을 사용하므로 차단됩니다. 이 한도는 선택도(필터 조건을 통해 유효하게 필터링할 수 있는 항목)가 항목 5천 개를 초과하는 쿼리를 차단하며, 인덱싱되지 않은 열을 필터링하는 쿼리도 차단합니다. 인덱싱되지 않은 열을 필터링하고 일부 경우 정렬하는 쿼리는 올바른 데이터 집합을 검색하기 위해 목록의 모든 항목에 대해 필터링을 수행해야 하므로 목록 보기 임계값보다 많은 항목에 대해 작동하기 때문입니다. 이 한도의 기본값은 SQL Server에서 잠금을 관리하는 방법 및 팜과 목록의 성능을 기준으로 합니다. 이 한도는 변경하지 않는 것이 좋습니다.

데이터베이스 경합을 최소화하기 위해 SQL Server에서는 다른 행에 액세스하는 사용자의 성능을 떨어뜨리지 않고 정확한 업데이트를 보장하기 위한 전략으로 행 수준 잠금을 사용합니다. 그러나 쿼리와 같은 읽기 또는 쓰기 데이터베이스 작업에서 5천 개보다 많은 행을 동시에 잠그는 경우에는 데이터베이스 작업이 완료될 때까지 SQL Server에서 잠금을 전체 테이블로 에스컬레이션하는 것이 보다 효율적입니다. 이 잠금 에스컬레이션이 발생하면 다른 사용자가 테이블에 액세스할 수 없게 됩니다. 잠금에 대한 자세한 내용은 잠금 에스컬레이션(데이터베이스 엔진)(https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x412)을 참조하십시오.

아래 그래프에는 목록 보기 임계값을 조정함에 따른 큰 목록에 대한 쿼리 조합의 처리량이 나와 있습니다. 이 쿼리 조합에는 목록의 모든 항목을 반환하는 쿼리가 포함되어 있으므로, 목록 보기 임계값을 높이면 더 많은 항목이 반환됩니다. 한도를 기본값인 5천 개에서 1만 개로 변경해도 성능에 큰 영향을 줍니다. 이 경우 성능을 개선하기 위해 목록 보기 임계값을 높이거나 낮추는 대신, 기본 목록 보기 임계값은 변경하지 않고 쿼리의 성능이 유지되도록 하는 데 주력해야 합니다.

작업의 성능이 나쁘면 목록 보기 임계값 예외가 발생하며, 그러면 작업을 다시 구성해야 합니다. 이 경우에는 한도를 높이는 대신 비효율적인 작업이 수행되는 이유를 고려하고 해당 문제를 해결해야 합니다. 최악의 시나리오에서는 특정 목록에 대해 일시적으로 EnableThrottling 설정을 false로 변경하여 목록 보기 임계값을 무시할 수 있습니다. 이 작업은 사이트가 아닌 목록 수준에서만 수행해야 합니다. 설정을 변경하여 목록 보기 임계값에 의해 차단되는 성능이 나쁜 작업을 수정할 때까지만 목록 액세스를 허용하도록 이러한 설정을 사용해야 하며, 그 후에는 EnableThrottling 설정을 최대한 빨리 true로 다시 변경해야 합니다.

쿼리를 처음 실행하는 프런트 엔드 웹 서버의 로컬 컴퓨터 관리자 및 팜 관리자의 작업은 목록 보기 임계값에 의해 차단되지 않습니다. 이러한 사용자는 올바르게 구성되지 않은 큰 목록을 검색할 때와 테스트를 수행할 때 주의해야 합니다. 작업이 정상적으로 수행되는 것처럼 보이더라도 사용자에게 반환되는 데이터는 크게 달라질 수 있습니다. 목록 보기 임계값에 의해 차단되는 작업 목록은 이 문서 뒷부분의 목록 보기 임계값에 의해 차단되는 작업을 참조하십시오.

마찬가지로 타이머 서비스 역시 목록 보기 임계값에 의해 작업이 차단되지 않는 계정을 사용하여 실행할 수 있습니다. 이렇게 하면 큰 목록에 대한 지연된 인덱스 작성과 같은 특정 시나리오는 가능해지지만, 코드가 큰 목록 작업 수행을 방지하는지를 세심하게 확인해야 합니다.

목록 보기 임계값

기본값: 5,000	2007에서 제공 여부: 제공되지 않음	구성 가능 여부: 가능
구성 위치: 중앙 관리(웹 응용 프로그램별)

감사자 및 관리자의 목록 보기 임계값

기본값: 20,000	2007에서 제공 여부: 제공되지 않음	구성 가능 여부: 가능
구성 위치: 중앙 관리(웹 응용 프로그램별)

감사자 및 관리자의 목록 보기 임계값은 검색 쿼리 계정이나 개체 캐시 슈퍼 독자/슈퍼 작성자 계정과 같은 특정 서비스 계정에 사용됩니다. 예를 들어 콘텐츠 쿼리 웹 파트는 자동으로 이 한도를 사용하여 큰 쿼리의 결과를 캐시함으로써 서버 리소스를 절약합니다. 웹 응용 프로그램 보안 정책에 따라 슈퍼 독자 또는 슈퍼 작성자인 계정으로 쿼리를 실행하는 경우 사용자 지정 코드를 사용하여 이와 같이 더 높은 한도를 사용하도록 요청할 수 있습니다.

개체 모델 무시 허용

기본값: 예	2007에서 제공 여부: 제공되지 않음	구성 가능 여부: 가능
구성 위치: 중앙 관리(웹 응용 프로그램별)

개체 모델 무시를 허용하면 서비스 계정이 감사자 및 관리자에 대해 목록 보기 임계값을 사용할 수 있는지 여부가 지정됩니다. 팜 관리자는 개체 모델 무시를 사용하도록 설정하고 목록이 예외임을 프로그래밍 방식으로 지정해야 합니다. 그러면 해당 권한이 있는 프로그래머가 쿼리 또는 목록에서 감사자 및 관리자가 사용할 수 있도록 더 높은 목록 보기 임계값을 사용할 것을 프로그래밍 방식으로 요청할 수 있습니다. 값을 아니요로 변경하면 감사자나 관리자가 실행하는 사용자 지정 코드는 무시를 요청하더라도 감사자 및 관리자용의 더 높은 한도가 아닌 목록 보기 임계값을 사용하게 됩니다. 이 설정은 기본값으로 유지하고 필요한 경우 감사자 및 관리자용 목록 보기 임계값만 구성하는 것이 좋습니다.

하루 중 시간대

기본값: 해제	2007에서 제공 여부: 제공되지 않음	구성 가능 여부: 가능
구성 위치: 중앙 관리(웹 응용 프로그램별)

목록 보기 임계값이 적용되지 않은 상태로 작업을 수행할 수 있는 하루 중 시간대를 설정할 수 있습니다. 이 시간은 최대 24시간까지 15분 단위로 조정할 수 있습니다. 하루 중 시간대에 포함되는 시간에 시작된 데이터베이스 작업이나 쿼리는 지정한 시간대에 끝나지 않더라도 완료될 때까지 계속됩니다. 사용량이 적은 시간은 배포마다 다르기 때문에 기본적으로 하루 중 시간대는 구성되지 않으며, 관리자가 해당 시간을 결정해야 합니다. 웹 응용 프로그램을 사용하는 사람이 거의 없는 적절한 시간대가 있는 경우에만 하루 중 시간대를 지정하는 것이 좋습니다. 이렇게 하면 사용자가 인덱스 만들기 등의 큰 목록에 대한 관리 작업을 팜 사용량이 훨씬 적은 시간대에 수행할 수 있습니다.

고유한 사용 권한

목록의 고유한 사용 권한 수가 늘어나면 성능은 저하됩니다. 따라서 큰 목록의 모든 콘텐츠 또는 대부분의 콘텐츠를 고유하게 보호해야 하는 디자인은 다시 고려해야 합니다. 고유한 사용 권한 수가 0~1천 개 사이인 목록에 대한 작업 처리량 차이는 약 20%입니다. 기본적으로는 목록당 5만 개의 고유한 사용 권한을 구성할 수 있습니다. 그러나 이 한도를 고유한 권한 5천 개로 낮추고, 큰 목록의 경우 고유한 권한을 최대한 적게 사용하는 디자인을 사용하는 것이 좋습니다. 이렇게 하면 성능과 관리 효율성을 모두 높일 수 있습니다.

구체적으로는 다음을 수행하는 것이 좋습니다.

• 개별 항목에 대해 사용하는 고유한 사용 권한 수를 최소화하고 대부분의 항목에 고유한 사용 권한을 적용해야 하는 목록 디자인을 간소화합니다.

• 고유한 사용 권한이 필요한 경우 목록 또는 폴더 수준에서만 설정하고 고유한 사용 권한을 필요로 하는 개별 항목의 수를 최소화합니다.

• 각 항목에 개별적인 사용 권한을 적용해야 하는 경우 디자인을 다시 고려합니다. 항목을 여러 목록으로 나누거나 폴더 및 그룹으로 구성하여 모든 항목에 고유한 사용 권한을 적용하지 않고도 적절한 액세스 권한을 부여하는 방법을 찾습니다.

세분화된 사용 권한을 설정하면 성능에 영향을 줄 수 있으며, 다수의 개별 항목에 대해 사용 권한을 다르게 설정하는 경우 관리하기도 어렵습니다. 목록 보기 임계값을 초과하는 목록이나 폴더에 대해 세분화된 사용 권한을 설정하는 작업은 업데이트해야 하는 개별 항목이 너무 많으므로 차단됩니다. 그러나 세분화된 사용 권한 설정은 다른 방식으로도 성능에 영향을 줄 수 있습니다. 따라서 고유한 사용 권한은 기본적으로 목록당 5만 개까지만 구성할 수 있습니다. 이 한도에 도달한 후에 고유한 사용 권한을 선언하려고 하면 해당 작업이 차단됩니다. 목록 보기 임계값과는 달리 이 한도는 쿼리 시가 아니라 항목에 대해 고유한 사용 권한을 만들 때 적용됩니다.

폴더 등의 항목에 대한 사용 권한 상속이 손실되는 경우 해당 항목은 이 한도에 합산되는 고유한 사용 권한으로 계산됩니다. 사용 권한 상속이 손실될 때마다 새로운 범위 ID가 작성됩니다. 보기를 쿼리할 때마다 범위 테이블에 대해 조인을 수행합니다. 그리고 쿼리를 수행할 때는 각 고유 ACL(액세스 제어 목록)을 구문 분석 및 처리해야 합니다. 목록에 포함된 대다수의 고유한 사용 권한은 성능을 저하시키므로 사용하지 않는 것이 좋습니다. 목록의 고유한 사용 권한 수가 많아질수록 쿼리 성능은 낮아집니다. 기본 한도는 고유한 사용 권한 5만 개이지만, 이 한도를 고유한 사용 권한 5천 개로 낮추는 것을 고려해야 합니다.

고유한 사용 권한

기본값: 50,000	2007에서 제공 여부: 제공되지 않음	구성 가능 여부: 가능
구성 위치: 중앙 관리(웹 응용 프로그램별)

행 줄 바꿈

목록에 추가하는 열은 SQL Server 데이터베이스 테이블의 열에 매핑됩니다. 데이터베이스 테이블의 각 행은 서로 다른 여러 열 유형을 고정된 수만큼 지원합니다. 예를 들어 단일 데이터베이스 테이블 행은 날짜 및 시간 열 8개와 숫자 열 12개를 지원합니다. 날짜 및 시간 열이 8개보다 많으면 각 목록 항목은 데이터베이스 테이블 행 2개를 사용합니다.

작은 목록의 경우에는 이러한 행 줄 바꿈이 성능에 거의 영향을 주지 않지만, 큰 목록의 경우에는 많은 영향을 줄 수 있습니다. 행의 줄이 바뀔 때까지는 열을 수 한도까지 추가할 수 있지만, 한 가지 열 유형이 한도에 도달해야 행의 줄이 바뀝니다.

아래 표에는 행의 줄이 바뀔 때까지 특정 데이터 형식에 대해 추가할 수 있는 열의 수가 나와 있습니다.

열 유형	테이블 행당 열 수
한 줄 텍스트 또는 선택 및 여러 줄 텍스트	64 32
날짜 및 시간	8
예/아니요	16
숫자 및 통화	12
계산된 열	8
정수, 단일 값 조회, 사용자 및 그룹, 관리되는 메타데이터	16
고유 식별자	1

행의 줄이 바뀌면 대부분의 작업에서 추가 행당 처리량이 약 35% 감소합니다. 목록에서 사용되는 행의 수를 확인하려면 목록 스키마를 분석하고 목록 필드의 열 유형을 확인해야 합니다.

아래 그래프에는 관리되는 메타데이터 열을 더 많이 포함하기 위해 목록에 사용되는 SQL Server 데이터베이스 행의 수가 늘어남에 따른 읽기 전용 쿼리의 성능이 나와 있습니다. 두 번째 행을 만들기 위해 관리되는 메타데이터 열 15개가 목록에 추가되었으며, 세 번째 행을 만들기 위해 관리되는 메타데이터 열 31개가 이 목록에 추가되었습니다. 테스트는 목록의 항목을 필터링하는 쿼리만 사용하여 수행되었습니다. 보시다시피 각 행이 추가될 때마다 처리량은 35%씩 감소했습니다.

행 크기 제한

기본값: 6	2007에서 제공 여부: 제공되지 않음	구성 가능 여부: 가능
구성 위치: 개체 모델 전용(SPWebApplication.MaxListItemRowStorage)

행 크기 제한은 목록의 각 항목에 사용되는 데이터베이스 내부의 테이블 행 최대 수를 지정합니다. 열 수가 많은 큰 목록을 포함할 수 있도록 각 항목은 여러 내부 테이블 행(최대 6개 행)으로 줄 바꿈됩니다. 예를 들어 목록에 수백 개의 예/아니요 열과 같은 작은 열이 여러 개 있는 경우 이 한도에 도달할 수 있습니다. 이 경우 목록에 예/아니요 열을 더 추가할 수는 없지만 다른 유형의 열은 추가할 수 있습니다. 각 행을 추가할 때마다 오버헤드도 추가로 발생하므로, 큰 목록의 경우에는 행 줄 바꿈을 방지하기 위해 같은 유형의 열 수를 최소화해야 합니다.

조회 열 및 목록 보기

목록 보기의 각 조회 열은 다른 테이블과 조인됩니다. 보기에 조회 열을 추가할 때마다 메타데이터 탐색 및 목록 보기 쿼리가 더욱 복잡해집니다. 표준 조회 열 외에 단일 값 관리되는 메타데이터, 여러 값 관리되는 메타데이터, 단일 값 사용자 및 그룹 열, 그리고 여러 값 사용자 및 그룹 열도 조회 열로 계산됩니다. 보기에 조회 열을 추가해도 성능이 점진적으로 또는 일정하게 떨어지지는 않으며, 8개 열을 추가할 때까지는 성능이 어느 정도 일정하게 유지되다가 그 후에 급격하게 저하됩니다.

아래 그래프에서는 보기의 조회 열 수가 증가함에 따른 처리량의 변화를 보여 줍니다. 보시다시피 조회 열이 0~8개일 때는 성능 변화가 비교적 일정하다가 10개가 되면 처리량이 크게 떨어집니다. 이 테스트는 행을 하나만 사용하는 목록으로 수행했습니다. 목록에서 행의 줄이 바뀌는 경우에는 성능이 더욱 빠르게 떨어집니다.

아래 그래프에서는 보기의 조회 열 수가 늘어남에 따른 SQL Server CPU 사용률을 보여 줍니다. 보시다시피 조회 열이 10개가 되면 사용률이 크게 높아집니다. 쿼리 수가 많은 목록의 경우 보기의 조회 열이 8개보다 많으면 쿼리가 비정상적으로 많은 양의 SQL Server 리소스를 사용하게 됩니다. 따라서 이 한도를 8보다 크게 변경하지 않는 것이 좋습니다.

이러한 성능 저하는 목록의 총 조회 열 수 때문이 아니라 보기 또는 쿼리의 조회 열 수 때문입니다. SharePoint Workspace에서는 보기에서 열을 사용하는지 여부에 관계없이 조회 열이 9개 이상인 목록을 동기화할 수 없습니다.

목록 보기 조회 임계값

기본값: 8	2007에서 제공 여부: 제공되지 않음	구성 가능 여부: 가능
구성 위치: 중앙 관리(웹 응용 프로그램별)

기타 한도

이 섹션에서는 이 문서의 다른 위치에서 다루지 않는 한도에 대해 설명합니다.

목록당 인덱스

기본값: 20

2007에서 제공 여부: 제공(한도: 10)

구성 가능 여부: 불가능

위 표에는 목록당 만들 수 있는 인덱스의 한도(복합 인덱스 및 SharePoint Server 2010에서 작성되는 인덱스 포함)가 나와 있습니다. 이 한도는 구성할 수 없습니다.

데이터시트 보기 및 Excel로 내보내기

기본값: 50,000

2007에서 제공 여부: 제공되지 않음

구성 가능 여부: 불가능

위 표에는 Microsoft Excel로 내보내기 및 데이터시트 보기에서 사용 가능한 최대 항목 수가 나와 있습니다. 그러나 데이터시트 보기의 경우 목록 보기 임계값에 의해 작업이 차단됩니다. 따라서 목록 보기 임계값이 5천 개 항목인데 목록 보기의 항목 수는 5천~5만 개인 경우 데이터시트 보기를 사용하려고 하면 데이터시트 보기 한도가 더 높아도 목록 보기 예외 메시지가 표시됩니다.

SharePoint Workspace

기본값: 목록당 항목 3만 개

2007에서 제공 여부: 제공되지 않음

구성 가능 여부: 불가능

Microsoft SharePoint Workspace에는 목록당 항목이 3만 개보다 많은 목록 동기화를 차단하는 구성 불가능한 한도가 있습니다. 목록에 3만 개의 항목이 포함된 경우 사용자는 SharePoint Workspace를 통해 목록을 동기화할 수 없으며, 항목을 선택적으로 동기화할 수도 없습니다.

큰 목록과 일반 목록의 차이

목록이 목록 보기 임계값을 초과하면 이전에는 수행 가능했던 일부 작업이 차단됩니다. 여기서 가장 큰 문제는 사용자들이 목록에 액세스하기 위해 가장 자주 사용하는 기본 목록 보기입니다. 목록 보기는 큰 목록에 대해서도 정상적으로 작동하도록 구성해야 합니다. 예를 들어 목록 루트에 목록 보기 임계값보다 많은 항목이 포함되어 있으면 목록 액세스 시 오류가 발생합니다. 메타데이터 탐색 기능이 사용하도록 설정된 경우에는 오류 대신 결과 하위 집합이 표시됩니다.

목록 보기 임계값이 사용되는 경우 해당 임계값보다 많은 항목에 대해 수행하는 모든 데이터베이스 작업이 차단됩니다. 즉, 이 임계값은 반환되거나 수정되는 항목 수만 차단하는 것이 아닙니다. 예를 들어 비인덱스 열에 대해 100개의 결과를 반환하는 필터를 적용하는 경우, 목록에 1만 개의 항목이 포함되어 있으면 1만 개의 항목 모두에 대해 검사를 수행해야 하므로 쿼리가 실패합니다. 반면 해당 열에 인덱스를 추가하는 경우에는 작업이 항목 100개에 대해서만 수행되므로 정상적으로 완료됩니다.

큰 목록에 대한 작업은 다음 두 그룹으로 분류할 수 있습니다.

• 목록이 목록 보기 임계값을 초과함   항목이 폴더로 구분되어 있어도 전체 목록의 크기가 목록 보기 임계값을 초과하면 일부 작업을 수행할 수 없습니다. 이러한 작업으로는 항목이 들어 있는 폴더에 관계없이 모든 항목에 대해 수행되는 재귀 쿼리(예: 체크 아웃된 버전 관리)가 있습니다. 폴더를 포함하지 않고 모든 항목을 반환하는 보기의 경우에도 작업이 차단됩니다. 또한 열 추가, 인덱스 만들기/삭제 등 전체 목록에 대해 수행되는 작업도 차단됩니다.

• 컨테이너가 목록 보기 임계값을 초과함   목록 루트 또는 폴더에 목록 보기 임계값보다 많은 항목이 포함되어 있으면 일부 작업을 수행할 수 없습니다. 예를 들어 목록에는 1만 개의 항목이, 폴더에는 3천 개의 항목이 포함된 경우 폴더를 삭제하거나 폴더 이름을 바꿀 수 있습니다. 그러나 폴더에 목록 보기 임계값을 초과하는 6천 개의 항목이 포함된 경우에는 해당 폴더에 대한 작업이 목록 보기 임계값을 초과하므로 폴더를 삭제할 수 없습니다.

목록이 목록 보기 임계값을 초과하는 경우에는 계획을 통해 보기 및 기타 탐색 옵션을 올바르게 구성해야 합니다. 보기 및 기타 탐색 옵션은 미리 구성하는 것이 가장 좋지만, 목록이 목록 보기 임계값을 초과하여 그에 대한 조치를 취해야 하는 경우가 많습니다. 항목이 많은 목록의 열 인덱싱, 열 만들기 등의 일부 작업은 시간이 오래 걸리며 목록 보기 임계값에 의해 차단됩니다. 그러나 이러한 작업을 하루 중 특정 시간대에 수행하거나 팜 또는 컴퓨터 관리자가 수행할 수 있습니다. 이러한 작업은 수행하기 전에 미리 계획해야 합니다. 목록이 이미 너무 큰 경우 하루 중 시간대 또는 관리 자격 증명을 통해 이러한 작업을 수행하도록 계획하십시오.

목록이 너무 커지면 웹 브라우저에서 일부 작업을 실행할 때 시간이 초과될 수 있습니다. 예를 들어 문서가 수백만 개 포함된 목록의 경우 새 열을 추가하는 데 시간이 너무 오래 걸릴 수 있습니다. 이러한 경우 작업을 수행하려면 Windows PowerShell을 사용해야 하며, 다른 사용자의 작업이 차단되지 않도록 사용량이 적은 시간을 선택해야 합니다.

목록 보기 임계값에 의해 차단되는 작업

아래 표에는 목록 보기 임계값에 의해 차단되는 목록 작업이 나와 있습니다.

목록이 목록 보기 임계값을 초과하면 차단되는 작업

작업	설명
목록 열 추가/제거/업데이트	형식 변경, 고유성 변경 등 다양한 종류의 업데이트를 비롯하여 조회 열 및 계산된 열을 포함한 모든 열에 대한 작업입니다. 이름 변경 등의 일부 업데이트는 목록의 일부 항목에는 영향을 주지 않으므로 차단되지 않습니다.
목록 콘텐츠 형식 추가/제거/업데이트	목록의 모든 항목에 영향을 주므로 목록 보기 임계값보다 많은 항목이 포함된 목록에 대해서는 차단됩니다.
인덱스 만들기/제거	목록의 모든 항목에 영향을 주므로 목록 보기 임계값보다 많은 항목이 포함된 목록에 대해서는 차단됩니다.
체크 인된 버전이 없는 파일 관리	목록 보기 임계값보다 많은 항목이 포함된 목록에 대해 실패하는 비인덱스 재귀 쿼리입니다.
비인덱스 재귀 쿼리	필터 및 일부 정렬을 포함합니다. 목록 크기가 목록 보기 임계값보다 크면 이 작업은 실패합니다. 인덱스가 없으므로 전체 목록에 대한 전체 검사를 수행하며, 모든 항목을 반환하고 폴더는 무시합니다.
교차 목록 쿼리	콘텐츠 쿼리 웹 파트에서 수행하는 쿼리를 포함하며, 감사자 및 관리자용 목록 보기 임계값 설정(기본적으로 2만 개 항목)을 따릅니다. 2만 개보다 많은 항목에 대해 작업이 수행되는 경우 쿼리는 실패합니다.
관계 동작을 적용하는 조회 열	참조되는 목록이 목록 보기 임계값보다 많은 항목을 포함하는 경우에는 관계 동작을 적용하는 조회 열을 만들 수 없습니다.
목록 삭제	목록의 모든 항목에 영향을 주므로 목록 보기 임계값보다 많은 항목이 포함된 목록에 대해서는 차단됩니다.
사이트 삭제	사이트에 포함된 모든 항목의 합이 목록 보기 임계값보다 크면 사이트 삭제 작업은 너무 많은 항목에 대해 수행되므로 차단됩니다.
데이터가 포함된 서식 파일로 목록 저장	목록의 모든 항목에 영향을 주므로 목록 보기 임계값보다 많은 항목이 포함된 목록에 대해서는 차단됩니다.
목록 보기에서 요약 표시	목록의 모든 항목에 대해 쿼리를 수행하므로 목록 보기 임계값보다 많은 항목이 포함된 목록에 대해서는 차단됩니다.
목록에서 첨부 파일 사용/사용 안 함	목록의 모든 항목에 영향을 주므로 목록 보기 임계값보다 많은 항목이 포함된 목록에 대해서는 차단됩니다.

컨테이너가 목록 보기 임계값을 초과하면 차단되는 작업

작업	설명
폴더 삭제/복사/이름 바꾸기	폴더에 포함된 항목 수가 목록 보기 임계값보다 많으면 작업이 너무 많은 행에 대해 수행되므로 실패합니다.
비인덱스 열을 필터링하는 쿼리	컨테이너(폴더 또는 목록)에 포함된 항목 수가 목록 보기 임계값보다 많으면 실패합니다. 인덱스가 없으므로 전체 폴더에 대해 전체 검사를 수행합니다.
세분화된 보안 권한 설정	세분화된 사용 권한을 설정하려는 목록이나 폴더에 포함된 항목 수가 목록 보기 임계값보다 많으면 작업이 너무 많은 행에 대해 수행되므로 실패합니다. 큰 목록의 문서와 같은 하위 항목에 대해서는 세분화된 사용 권한을 설정할 수 있지만, 목록 보기 임계값보다 많은 항목이 포함된 폴더나 목록 자체에 대해서는 사용 권한을 설정할 수 없습니다.
탐색기에서 열기	컨테이너에 포함된 항목(하위 폴더의 항목은 제외)의 수가 목록 보기 임계값보다 많으면 항목이 표시되지 않습니다. 폴더에 8천 개의 항목이 있는데 루트에는 항목이 4천 개만 있고 나머지 4천 개는 하위 폴더에 들어 있으면 탐색기에서 열기가 작동합니다. 그러나 목록의 루트에 목록 보기 임계값보다 많은 항목이 있으면 탐색기에서 열기를 사용해도 항목이 표시되지 않습니다. 탐색기에서 열기를 사용하려면 목록의 항목을 컨테이너 루트의 목록 보기 임계값보다 적은 수의 폴더로 구성해야 합니다.

사용 가능하지만 정상적으로 작동하지 않을 수 있는 기능

이 섹션에서는 큰 목록에 대해 정상적으로 작동하지 않을 수 있는 기능에 대해 설명합니다.

데이터시트 보기

목록이 목록 보기 임계값보다 커져도 문서 라이브러리의 라이브러리 리본 메뉴 탭에서 사용할 수 있는 데이터시트 보기 단추는 계속 사용 가능합니다. 그러나 목록 크기가 목록 보기 임계값보다 커지는 경우 보기에 일부 항목이 로드되기는 하지만 "관리자가 적용한 목록 보기 권한이 제한되어 전체 목록을 볼 수 있는 권한이 없습니다."라는 메시지가 표시됩니다. 리본 메뉴를 통해 목록에 대한 설정에서 데이터시트 보기 옵션을 사용하지 않도록 설정할 수 있습니다. 또한 데이터시트 보기에는 하드 한도(5만 개 항목)가 적용되므로 목록 보기 임계값이 5만 개 항목을 초과하면 이 보기가 차단됩니다.

큰 목록 디자인 및 구현 계획

큰 목록을 구현하기 전에 업무 상황 및 요구 사항을 고려하십시오. SLA(서비스 수준 계약), 백업/복원 시간, 콘텐츠 크기, 콘텐츠의 양(항목 수), 액세스 횟수 등의 요구 사항을 모두 고려해야 합니다. 응용 프로그램의 크기와 요구에 따라서는 하드웨어, 콘텐츠 저장소 및 SharePoint Server 2010 정보 아키텍처를 비롯한 여러 수준에서 중요한 선택을 해야 합니다. 항목 수가 수백만 개이고 동시 사용자가 수백 명에 달하는 대형 응용 프로그램의 경우 특정 프로젝트용으로 독립 실행형 하드웨어가 필요할 수 있습니다. 그러나 동시 사용자가 수십 명이고 문서가 수만 개 포함된 문서 저장소의 경우에는 기존 사이트의 단일 문서 라이브러리와 기존 공유 하드웨어에서도 정상적으로 작동합니다.

계획 과정에서는 최종적으로 문서 형식(이름, 데이터 형식 및 사용법), 인덱스, 폴더 구조, 탐색용 링크 및 페이지 사용법, 계획된 사용 권한 구조, 예상 항목 수 및 총 데이터 크기가 포함된 목록이 완성되어야 합니다. 또한 수행할 쿼리 종류와 목록 데이터 액세스/작성/업데이트 방법에 대한 세부 정보도 포함해야 합니다.

큰 목록 구현 및 디자인을 계획한 후에는 프로토타입을 디자인 및 작성합니다. 이 계획 단계에서는 큰 목록을 디자인하고, 개념 증명을 구현하고, 해당 목록이 작동하는지를 확인합니다. 이 단계에서 테스트 환경에 많은 양의 콘텐츠를 채워 데이터 액세스 및 성능에 대한 예상을 확인하면 유용할 수 있습니다. 디자인 프로세스에서는 최종적으로 원하는 목록의 개념 증명을 지정하고 열, 콘텐츠 형식, 폴더 구조, 보기, 인덱스, 메타데이터 탐색이나 기타 검색 방법에 사용되는 열, 사용되는 분류, 다양한 웹 파트의 사용법, 그리고 콘텐츠 구성 도우미 등의 기타 기능 사용법이 포함된 문서를 작성해야 합니다.

콘텐츠 크기 예상

큰 목록의 경우에는 용량을 계획하고 디자인 관련 사항을 결정하기 위해 다양한 수치를 예상해야 합니다. 구체적으로는 다음과 같은 몇 가지 주요 수치를 계획해야 합니다.

• 총 콘텐츠 데이터베이스 크기

• 평균 및 최대 파일 크기

• 버전 수

• 콘텐츠의 양 - 목록의 총 항목 수

콘텐츠 데이터베이스 크기

백업, 복원 및 서비스 수준 계약에 대해 지원되는 항목을 파악함과 동시에 필요한 디스크 공간 및 하드웨어를 계획할 때 중요한 요소는 총 콘텐츠 데이터베이스 크기입니다. 전체 콘텐츠 데이터베이스 크기는 백업 및 복원 시에 필요한 가동 중지 시간을 계산할 때 가장 중요한 요소입니다.

콘텐츠 데이터베이스의 예상 크기는 평균 문서 크기에 문서당 평균 버전 수와 예상 문서 수를 곱하여 계산할 수 있습니다. 파일 외에 콘텐츠 데이터베이스 데이터용으로 20%를 계산된 값에 추가로 더합니다. 보통 시간이 지남에 따라 버전이 커지기 때문에 이 값은 큰 경우가 많으며, 일반적으로 체크 인된 문서의 평균 파일 크기는 모든 버전의 평균 파일 크기보다 더 큽니다. 목록이 예상보다 더 커진다면 콘텐츠의 양을 효율적으로 제어하는 메커니즘이 있는 경우가 아니면 큰 버퍼를 추가해야 합니다.

평균 및 최대 파일 크기

업로드 가능한 파일에 대해 적절한 웹 응용 프로그램 설정을 지정하려면 최대 파일 크기가 필요합니다(기본값은 50MB, 최대값은 2GB). 평균 파일 크기를 사용하면 콘텐츠 증가 속도를 파악하고 총 콘텐츠 크기를 예상할 수 있습니다. 현재 필요한 시스템 역할을 하는 시스템의 파일을 파악하여 평균 파일 크기를 예상할 수 있습니다.

평균 버전 수

버전 관리를 사용하는 경우에는 콘텐츠 크기가 크게 증가할 수 있으므로 신중하게 고려해야 합니다. 몇 가지 방법을 통해 버전을 제한할 수 있습니다. 예를 들어 정보 관리 보존 정책을 사용하여 일정 기간이 지나면 이전 버전은 모두 삭제할 수도 있고, 저장할 버전 수를 제한할 수도 있습니다. 버전에 영향을 주는 다른 요인들도 있습니다. 예를 들어 저장소의 모든 콘텐츠가 콘텐츠 구성 도우미를 통해 전송되는 경우 콘텐츠 구성 도우미는 최신 체크 인 버전만 복사하기 때문에 버전이 전혀 없을 수 있습니다. 저장소의 문서를 사용자들이 빈번하게 편집하는 경우에는 공동 작성을 고려해야 할 수 있습니다. 각 공동 작성 세션에서는 버전이 자동으로 작성됩니다. 저장소 사용법을 고려하고, 기존 솔루션을 평가하여 문서에 대해 만들어지는 평균 버전 수를 예상하십시오.

콘텐츠의 양

콘텐츠의 양은 단일 목록의 총 항목 수입니다. 콘텐츠의 양을 예상하려면 기존 콘텐츠 원본 및 새 시스템으로 이동할 콘텐츠를 파악하거나, 시스템을 사용할 사용자의 수 및 시스템의 용도를 확인해야 합니다. 또한 컨테이너당 항목 및 메타데이터 피벗이나 인덱스 필터당 항목 등 기타 관련 수치도 확인해야 할 수 있습니다. 보기 및 메타데이터 탐색을 계획할 때는 이러한 수치도 중요한 역할을 합니다.

Remote BLOB Storage

저장소 요구 사항이 높은 목록의 경우에는 근본적인 문서 저장 방법을 결정해야 할 수 있습니다. 기본적으로 SharePoint Server 2010은 모든 문서를 SQL Server 데이터베이스에 BLOB로 저장합니다. SharePoint Server 2010 및 SQL Server 2008에서는 문서를 SQL Server 데이터베이스 외부에 저장하여 데이터베이스 크기를 줄일 수 있도록 하는 Remote BLOB Storage API를 제공합니다. Remote BLOB Storage 사용 여부는 대체로 비용 절약 측면을 고려하여 결정하게 됩니다.

Microsoft의 최근 테스트 결과에 따르면, Remote BLOB Storage를 사용하는 경우 처리량이 5~10% 감소하며 큰 파일의 경우에도 대기 시간에는 큰 차이가 없었습니다. 그러나 사용하는 특정 Remote BLOB Storage 공급자에 따라서는 성능에 차이가 있을 수 있습니다. Remote BLOB Storage를 사용하는 경우에는 콘텐츠 데이터베이스 크기가 감소하지만, 그렇다고 해서 콘텐츠 데이터베이스에 더 많은 항목을 저장할 수 있는 것은 아닙니다. SQL Server 데이터베이스에 포함된 목록의 항목 수가 성능에 영향을 주며, BLOB를 제거하더라도 목록 크기는 변경되지 않습니다. 다음과 같은 몇 가지 시나리오에서는 다소 성능이 저하되더라도 비용 측면의 이점이 매우 크므로 Remote BLOB Storage를 사용하는 것이 효율적입니다.

• 보관함(공동 작업용이 아닌 데이터)

• 자주 업데이트하지 않는 비디오, 이미지 등의 매우 큰 BLOB 저장

Remote BLOB Storage를 사용하는 경우 팜에서 사용되는 서버 및 기술이 추가될 수 있으며 Remote BLOB Storage 공급자를 더 추가해야 합니다. Remote BLOB Storage 공급자는 SQL Server 데이터베이스 외부의 저렴한 저장소에 BLOB를 저장할 수 있도록 지원합니다. Remote BLOB Storage API를 사용하려면 SQL Server Enterprise가 필요합니다.

비용 면에서 Remote BLOB Storage가 이점을 제공하는 시점은 데이터가 TB 단위일 때입니다. 그러나 단지 콘텐츠 데이터베이스의 크기가 TB 단위라고 해서 Remote BLOB Storage를 사용할 필요는 없으며, 백업 및 복원과 서비스 수준 계약도 주의 깊게 고려해야 합니다. Remote BLOB Storage를 사용하는 경우에는 두 기술을 동기화해야 하므로 재해 복구가 보다 까다로워집니다. 재해 복구와 관련하여 고려해야 하는 주요 사항은 재해 후 시스템을 복원하고 백업 및 복구 BLOB를 처리하는 데 걸리는 시간입니다. 자세한 내용은 RBS 개요(SharePoint Server 2010)를 참조하십시오.

목록 아키텍처

큰 목록 프로젝트에서는 적절한 아키텍처를 선택하는 것이 중요합니다. 아키텍처는 일단 결정하여 구현하고 나면 변경하기가 어렵기 때문입니다. 따라서 콘텐츠의 크기와 양, 저장소 사용법, 콘텐츠 추가/업데이트 방법, 콘텐츠 액세스 방법 등을 미리 계획하고 고려해야 합니다. 이러한 모든 요소는 콘텐츠를 구성하는 방법(단일 목록, 여러 목록 또는 여러 사이트 모음), 사용되는 메타데이터 및 콘텐츠 검색 방법에 영향을 줄 수 있습니다. 큰 목록의 경우에는 이러한 모든 결정 사항이 특히 중요한데, 콘텐츠의 양이 많으면 시스템 사용 방법을 다시 디자인하기가 더욱 어렵기 때문입니다.

단일 목록, 여러 목록 또는 여러 사이트 모음

큰 목록 솔루션을 디자인할 때는 단일 목록 아키텍처가 적절한지를 고려해야 합니다. 콘텐츠 작업 및 검색 시의 사용 편이성과 같은 업무 요구 사항을 기준으로 하여 콘텐츠를 단일 목록에 배치할지를 결정합니다. 대부분의 경우에는 여러 목록을 사용하는 것이 더 적절합니다. SharePoint Server 2010의 기능과 사용 가능한 리소스를 활용하여 효율적인 사용자 환경과 뛰어난 사용성을 제공하는 구현을 성공적으로 작성하는 것을 최우선 과제로 지정해야 합니다.

단일 목록을 사용하는 경우 사용자가 보다 쉽게 콘텐츠를 찾고 사용할 수 있으므로 콘텐츠를 저장할 위치 또는 원하는 콘텐츠를 찾기 위해 액세스해야 하는 목록을 결정하지 않아도 됩니다. 그러나 콘텐츠의 양이 늘어나면 콘텐츠를 찾기가 점점 어려워질 수 있으며, 특히 보기 필터링 또는 폴더 탐색 등의 방법으로는 콘텐츠를 찾기가 더욱 어려울 수 있습니다. 목록의 항목이 수십만 개가 되면 메타데이터 탐색은 사용하기가 어려워질 수 있습니다. 구체적이지 않은 쿼리를 실행하는 경우 결과가 수백 개, 심지어는 수천 개 반환될 수도 있습니다.

예를 들어 인덱스 도메인에 용어가 5천 개 있고 각 용어에는 필터와 일치하는 동일한 수의 항목이 있다고 가정해 보겠습니다. 용어 하나를 필터링하면 항목이 10만 개인 목록의 경우 결과 20개가, 항목이 1백만 개인 목록의 경우 결과 200개가 반환됩니다. 목록 크기가 너무 큰 경우 사용자가 선택하는 대부분의 필터는 사용자가 원하는 콘텐츠를 찾기에 적절한 결과 집합을 반환하지 않습니다. 프로젝트에 서로 다른 여러 종류의 콘텐츠가 있고 사용자가 이러한 콘텐츠를 구별할 수 있어야 한다면 여러 목록을 사용하는 것을 고려해야 합니다.

대규모 보관 시나리오와 같이 콘텐츠가 매우 많아지는 경우에는 여러 사이트 모음 아키텍처를 사용하는 것도 고려해 볼 수 있습니다. 새로운 SharePoint Server 2010 기능을 사용하면 사이트 모음을 그룹으로 묶어 문서를 부하 분산할 수 있습니다. 콘텐츠 구성 도우미 기능을 통해 여러 사이트 모음 간에 문서를 라우팅할 수 있습니다. 문서를 검색할 때는 검색 기능을 사용해야 합니다. 문서를 장기간 저장해야 하는 경우에는 이러한 방법을 사용하면 효율적입니다. 여러 사이트 모음에 콘텐츠를 균형 있게 분산시킬 수 있으며, 단일 목록보다 훨씬 많은 문서를 지원하도록 아키텍처를 확장할 수 있기 때문입니다.

목록 권장 사항 요약

• 항목 수가 많은 경우 다음과 같은 상황에서는 단일 목록을 사용합니다.

  • 별도의 목록에 항목을 배치하는 것이 논리적이지 않은 경우

  • 단일 목록을 사용할 때 최적의 사용자 환경이 제공되는 경우

• 항목 수가 많은 경우 다음과 같은 상황에서는 여러 목록을 사용합니다.

  • 항목을 여러 목록으로 그룹화하는 것이 논리적인 경우

  • 여러 목록을 사용할 때 최적의 사용자 환경이 제공되는 경우

  • 사용자가 콘텐츠를 추가하거나 찾는 데 사용할 목록을 혼동할 염려가 없는 경우

• 다음과 같은 경우에는 여러 사이트 모음 아키텍처를 사용합니다.

  • 단일 저장소에서 수천만 개 이상의 항목을 지원해야 하는 경우

  • 그룹을 여러 사이트 모음으로 그룹화하는 것이 논리적인 경우(예: 연도별 데이터 분할)

메타데이터

SharePoint Server 2010에서는 정보 아키텍처를 만들 때 메타데이터 및 콘텐츠 형식을 유용하게 활용할 수 있습니다. 관리되는 메타데이터, 용어 집합 및 메타데이터 탐색과 같은 새로운 기능이 제공되므로 콘텐츠를 검색할 때 메타데이터가 매우 유용하며 중요한 역할을 합니다. 큰 목록에서는 콘텐츠 형식 및 열 수정과 같은 작업이 차단되므로 메타데이터 요구 사항을 미리 계획하는 것이 특히 중요합니다. 메타데이터 탐색 또는 메타데이터로 콘텐츠를 검색하는 기타 다른 방법을 사용하려는 경우에는 디자인 단계 중에 콘텐츠 형식 및 포함할 열을 계획해야 합니다.

대부분의 큰 목록 시나리오에서는 메타데이터가 단순히 유용한 요소에 그치는 것이 아니라, 시스템을 사용하려는 사용자는 메타데이터를 반드시 사용해야 합니다. 기본 제공 시스템 프로세스, 사용자 지정 구성과 코드, 그리고 사용자의 수동 적용 등 세 가지 기본 방법을 통해 메타데이터를 적용할 수 있습니다. 열을 사용하여 콘텐츠를 검색하려는 경우 대부분의 항목에는 해당 열에 대해 지정된 값이 있어야 합니다. 따라서 탐색에 사용할 열과 메타데이터를 채울 방법을 반드시 계획해야 합니다. 정확한 메타데이터 적용을 보장하려면 기본 제공 프로세스와 사용자 지정을 사용해야 합니다. 모든 항목에는 콘텐츠 형식이 있으므로, 예를 들어 콘텐츠 형식을 통해 문서를 분류하는 경우에는 모든 항목에 해당 메타데이터가 포함되며 이를 통해 콘텐츠 형식 기준 필터링이 간편해집니다.

콘텐츠 형식

가장 기본적인 콘텐츠 분류는 콘텐츠 형식을 사용한 분류입니다. 문서 또는 항목 형식 등의 메타데이터로 콘텐츠를 분류하는 경우에는 콘텐츠 형식에 해당 분류를 사용할지를 고려해야 합니다. 콘텐츠 형식을 사용하면 워크플로 및 서식 파일에 연결되는 동시에 특정 콘텐츠 형식에도 연결되는 열을 정의할 수 있습니다. 각 콘텐츠 형식에는 서식 파일이 하나만 연결될 수 있으며, 문서 라이브러리의 새 문서 메뉴를 사용하여 콘텐츠 형식 인스턴스를 새로 만들 때 이 서식 파일을 사용합니다.

Microsoft Word, Microsoft PowerPoint 및 Excel과 기타 제품의 파일 형식에 대해 서식 파일을 사용할 수 있습니다. 사용자가 새 콘텐츠 형식 인스턴스를 작성할 때는 해당 클라이언트 응용 프로그램을 통해 서식 파일을 사용하여 작성을 시작합니다. 콘텐츠가 업로드되면 사용자는 사용 가능한 콘텐츠 형식 중에서 선택할 수 있습니다. 콘텐츠 형식은 고유하고 구체적이어야 하며, 사용자가 어려움 없이 사용할 콘텐츠 형식을 선택할 수 있도록 목록당 적은 수의 콘텐츠 형식만 포함해야 합니다.

콘텐츠 형식은 사용자가 항목을 만들거나 업로드할 때 채워야 하는 메타데이터를 제어하므로, 업무 요구 사항을 충족하며 콘텐츠 전송 시의 문제를 최소화하는 데 필요한 열을 고려해야 합니다. 적절한 콘텐츠 형식 집합을 선택하여 기본 수준에서 콘텐츠를 자동으로 분류하면 탐색이 원활해집니다. 모든 항목에는 콘텐츠 형식이 있으므로 필터링 시에는 모든 항목에 대해 작동하는 피벗을 사용할 수 있습니다.

콘텐츠 형식 권장 사항 요약

• 가장 기본적인 콘텐츠 구성 방법으로 콘텐츠 형식을 사용합니다.

• 콘텐츠 형식을 사용하여 해당 형식의 콘텐츠에 필요한 특정 열을 선택합니다.

• 각 목록에는 최소한의 콘텐츠 형식(10개 미만)만 포함해야 하며, 사용자가 사용해야 하는 콘텐츠 형식을 쉽게 파악할 수 있도록 각 형식은 고유해야 합니다.

• 콘텐츠 형식에는 기본 제공 열이 있으며, 이 열에는 모든 항목에 대한 값이 있어 필터링 및 메타데이터 탐색 시에 사용할 수 있습니다.

공동 작업용 큰 목록 및 콘텐츠 형식 예제: 제품 사양 라이브러리

제품 사양 라이브러리는 제품 개발 팀에서 디자인 사양, 테스트 계획 및 기타 제품 개발 항목을 저장하는 데 사용됩니다. 이 예제에서는 다음의 6가지 콘텐츠 형식을 사용합니다. 모든 콘텐츠 형식에는 프로젝트 시작 날짜, 프로젝트 종료 날짜, 예산, 디자인 팀원, 제품 이름 및 제품 유형에 해당하는 열이 있습니다.

• 제품 사양 - 제품 디자인 세부 정보가 포함된 Word 파일입니다. 디자이너 및 최종 검토 날짜가 추가 메타데이터로 포함됩니다.

• 테스트 사양 - 제품 테스트 계획이 포함된 Word 파일입니다. 테스터 및 테스트 완료 상태가 추가 메타데이터로 포함됩니다.

• 개발 계획 - 제품 개발 계획이 포함된 Word 파일입니다.

• 스토리보드 - 디자인 기획안을 제시하는 데 사용되는 PowerPoint 프레젠테이션입니다.

• 비용 분석 - 제품 개발 비용 및 잠재적 시장 기회를 분석하는 Excel 프레젠테이션입니다.

• 타임라인 - 제품 개발 인정에 대한 세부 정보가 포함된 Excel 스프레드시트입니다.

이 예제에서 사용자는 콘텐츠 형식을 기준으로 필터링하여 제품 사양이나 제품 스토리보드를 찾을 수 있습니다. 사용자 지정 서식 파일을 통해 사용자의 작업을 구성할 수도 있습니다. 열과 콘텐츠 형식의 수가 적어서 사용자들이 작업에 적합한 옵션을 쉽게 선택할 수 있는 동시에, 메타데이터를 채워 콘텐츠를 쉽게 필터링하고 찾을 수도 있습니다.

열

열의 수 및 필수 열

열을 사용하여 항목에 포함되는 메타데이터 종류를 지정할 수 있습니다. 열은 숨겨진 열, 선택적 열 또는 필수 열로 표시할 수 있습니다. 숨겨진 열은 워크플로 등의 자동화된 작업에 사용합니다(사용자가 편집할 수 없음). 필수 열은 반드시 필요한 경우에만 사용해야 합니다. 예를 들어 항목을 적절한 위치로 라우팅하거나 탐색을 하려면 메타데이터 속성이 필요할 수 있습니다. 이러한 경우에는 사용자가 열의 값을 비워 두면 안 됩니다. 탐색 필터로 사용되는 열에 메타데이터가 채워진 항목의 수가 적을수록 탐색 유용성은 떨어집니다. 대부분의 항목이 쿼리에서 반환되지 않기 때문입니다.

메타데이터 열의 수가 늘어나면 사용자가 메타데이터를 입력할 가능성은 낮아집니다. 적용되는 열을 파악한 다음 값을 지정해야 하는 추가 작업이 발생하기 때문입니다. 필수 열을 많이 사용하는 경우에는 콘텐츠를 업로드하는 데 시간이 너무 많이 걸리므로 사용자가 해당 디자인을 적용하기가 어려울 수 있으며, 매우 개방적인 공동 작업 시나리오에서는 큰 문제가 발생할 수도 있습니다. 그러나 콘텐츠의 가치와 해당 콘텐츠를 작성하는 데 필요한 작업량이 늘어나면 사용자가 시간을 할애하여 해당 필드에 값을 입력할 가능성이 높아집니다(특히 해당 작업의 빈도가 낮은 경우).

디자인 단계에서는 필수 작업을 수행하고 콘텐츠를 검색하는 데 필요한 메타데이터를 고려하고, 사용자가 해당 메타데이터를 입력하는 데 걸리는 시간과 사용자에 대한 영향을 예측해야 합니다. 콘텐츠 작성 오버헤드가 너무 커서 사용자가 시스템을 도입하지 않는 경우에는 나중에 시스템을 재구성하기가 어려울 수 있습니다.

필드 유형과 단일 값 필드 및 여러 값 필드 비교

열을 선택할 때 고려하는 사항 중 하나는 열 유형 및 열에 값을 여러 개 포함할지 여부입니다. 관리되는 메타데이터 필드에 대한 쿼리는 선택 열에 대한 쿼리보다 효율적이므로, 선택 필드 대신 관리되는 메타데이터 필드 사용을 고려할 수 있습니다. 관리되는 메타데이터, 사용자 또는 그룹 등의 열은 여러 값을 지원할 수 있습니다. 그러나 여러 값 열에 대한 쿼리는 단일 값 열에 대한 쿼리만큼 효율적이지 않습니다.

일반적으로 큰 목록의 콘텐츠를 분류 및 검색할 때 주로 사용되는 구성 요소는 열 및 콘텐츠 형식입니다. 열 및 콘텐츠 형식 목록은 계획 단계에서 이미 준비된 상태여야 합니다. 목록에 추가하는 콘텐츠 형식 및 열의 수는 성능에 미묘한 영향을 줄 수 있습니다. 단일 목록에 추가하는 특정 유형의 열 수로 인해 행 줄 바꿈이 적용됩니다. 자세한 내용은 이 문서 앞부분의 행 줄 바꿈을 참조하십시오..

공동 작업용 큰 목록 및 열 예제: 제품 사양 라이브러리

이 섹션에서는 이 예제에 사용되는 열에 대해 설명합니다.

• SharePoint Server 2010에서 자동으로 유지 관리되는 열: ID, 콘텐츠 형식, 수정한 날짜, 만든 날짜, 수정한 사람, 만든 사람, 문서 ID

• 사용자 지정을 통해 유지 관리되는 열:

  • 제품 유형 및 제품 팀에 해당하는 폴더별 메타데이터 기본값(각 제품 유형에는 폴더가 있으며, 각 제품 유형 폴더에는 여러 제품 팀 폴더가 있음)

  • 워크플로 업데이트: 승인 상태, 프로젝트 완료

• 사용자가 유지 관리하는 열: 디자이너, 테스터, 최종 검토 날짜

• 탐색 시 정상 작동하는 열: 콘텐츠 형식, 제품 유형, 제품 팀

• 상태 추적용으로 사용되며 탐색 시에도 정상 작동하는 열: 최종 검토 날짜, 승인 상태, 프로젝트 완료

• 탐색 시 유용할 수 있는 열: 디자이너, 테스터, 제품 이름, 수정한 사람, 수정한 날짜

열 권장 사항 요약

• 내용을 입력할 수 있는 열 수를 최소화합니다.

• 시스템 프로세스 및 탐색에 사용할 열은 주의 깊게 선택합니다. 필요한 필드를 고려하고 필수 필드 수를 최소화합니다.

• 필수 필드는 탐색에 필요한 경우에 사용해야 합니다(예: 특정 필드에 대해 콘텐츠 쿼리 웹 파트 사용). 또한 날짜 필드에 대해 사용자가 지정해야 하는 보존 작업을 지정하는 것과 같은 관리 작업에서도 필수 필드를 사용해야 합니다.

• 단일 값 열에 대한 쿼리가 여러 값 열에 대한 쿼리보다 빠르게 실행되므로 여러 값이 반드시 필요한 경우가 아니면 단일 값 열을 사용합니다.

목록에 포함된 특정 열의 총 수에 따라 행 줄 바꿈이 적용되어 성능이 저하될 수 있습니다. 큰 목록에서는 열 수를 최소화하고 가능하면 행 줄 바꿈을 방지합니다.

폴더

콘텐츠를 폴더로 구성하는 방법을 주의하여 고려해야 합니다. 폴더는 다음과 같은 세 가지 기본 방식으로 사용할 수 있습니다.

• 논리적으로 콘텐츠를 폴더로 구성합니다. 예를 들어 계약의 경우 계약 체결 연도/월을 기준으로, 송장의 경우 송장 작성 날짜를 기준으로 폴더로 구성할 수 있습니다. 이렇게 하면 사용자들이 폴더 구조를 쉽게 탐색하거나 메타데이터를 사용하여 문서를 찾을 수 있습니다. 또한 문서를 올바른 폴더로 쉽게 자동 라우팅할 수도 있습니다. 콘텐츠 구성 도우미에서 제공하는 기능을 사용하면 특정 한도를 초과하여 항목을 추가하는 경우 하위 폴더를 만들어 단일 폴더의 항목 수를 제한할 수 있습니다.

• 보존 및 사용 권한이나 기타 관리 기능용으로 콘텐츠를 폴더로 구성합니다. 예를 들어 소수의 사용자만 액세스할 수 있는 기밀 문서용 폴더를 만들거나, 폴더별로 문서에 각각 다른 보존 일정이 적용되는 위치 기반 보존을 사용할 수 있습니다. 이 시나리오에서는 사용자가 문서 액세스 권한만 있으면 문서 위치에는 신경을 쓰지 않기 때문에 사용자 탐색이 더 까다로워질 수 있습니다. 이러한 경우에는 폴더 구조를 사용하기보다는 주로 메타데이터 탐색 및 검색을 통해 문서를 찾습니다.

• 사용자 탐색을 지원하기 위해 주제나 범주별 폴더로 콘텐츠를 구성합니다. 대부분의 사용자는 폴더를 사용한 탐색에 익숙합니다. 특정 응용 프로그램의 경우에는 사용자가 쉽게 탐색할 수 있는 폴더 구조를 유지하는 것이 중요할 수 있습니다. 이러한 시나리오에서는 사용자가 대개 폴더 구조를 이해하고 있으며 문서를 찾고 저장할 위치도 알고 있습니다. 이 방법은 메타데이터 탐색 및 검색과 함께 사용할 수 있습니다.

SharePoint Server 2010의 개선된 기능을 사용하면 폴더를 보다 유동적으로 사용할 수 있으며 성능 고려 사항에 대한 의존도를 낮출 수 있습니다. 사용자는 폴더를 탐색하는 대신 관리되는 메타데이터 및 메타데이터 탐색을 통해 메타데이터로 콘텐츠를 쉽게 필터링할 수 있습니다. 그러면 사용자 탐색뿐만이 아니라 사용 권한, 정책 등의 관리용으로도 콘텐츠를 구성할 수 있습니다. 예를 들어 특정 직원만 액세스할 수 있는 기밀 자료 폴더와 모든 직원이 액세스할 수 있는 폴더를 별도로 만들 수 있습니다. 각 폴더에 대해 서로 다른 사용 권한을 지정하고 콘텐츠 구성 도우미를 사용해 메타데이터를 기반으로 콘텐츠를 적절한 폴더로 자동 이동할 수 있습니다. 메타데이터 탐색을 사용하는 경우에도 탐색 시에 폴더를 계속 사용할 수 있습니다.

콘텐츠 구성 도우미 기능을 사용하는 경우 콘텐츠 형식 및 메타데이터를 기준으로 콘텐츠를 폴더로 자동 이동할 수 있으며, 사용자가 콘텐츠를 저장할 위치를 결정하지 않아도 됩니다. 또한 특정 폴더의 지정된 항목 한도에 도달하면 콘텐츠 구성 도우미를 통해 새 폴더를 자동으로 만들 수도 있습니다. 항목이 폴더로 구성되어 있지 않은 경우에는 폴더 루트의 항목 수가 목록 보기 임계값보다 많지 않으면 큰 목록에 대해 탐색기에서 열기(WebDAV)가 작동하지 않는다는 점도 고려해야 합니다.

폴더 기반 보기 및 메타데이터 기반 보기는 성능상 매우 유사합니다. 논리적/사용자 환경 측면에서 볼 때는 폴더를 사용하여 콘텐츠를 구분하는 것이 적절합니다. 메타데이터 탐색에서는 재귀 쿼리를 수행하므로 폴더 외부의 모든 항목이 반환됩니다. 콘텐츠 검색 시 이 방법을 주로 사용하는 경우에는 폴더 구조가 그다지 중요하지 않을 수도 있습니다.

아래 그래프에는 다양한 유형의 보기를 사용해 동일한 수의 항목에 액세스하는 방식으로 수행된 테스트의 결과가 나와 있습니다. 모든 보기에서는 1천 개의 결과가 반환되었습니다. 그래프에는 목록 크기가 커짐에 따른 개별 보기의 초당 요청 수가 표시되어 있습니다. 결과에 나와 있는 것처럼, 목록 크기가 커져도 폴더와 인덱싱된 보기의 성능은 비교적 일정하게 유지되었습니다(목록 크기가 작은 경우 폴더의 성능이 더 우수함). 가장 큰 목록에서는 성능 차이로 인해 데이터 검색 시 사용할 방법(폴더 또는 인덱스)이 결정되지 않도록 폴더와 인덱싱된 보기를 조합하여 사용했습니다.

폴더 권장 사항 요약

• 항목을 폴더로 구성할 방법을 계획합니다. 항목은 자동 또는 수동으로 이동할 수 있습니다.

• 메타데이터 탐색 등의 기능을 사용하는 경우 폴더의 항목 수를 제한할 필요성이 낮아집니다.

• 메타데이터 탐색을 폴더 탐색과 함께 사용합니다. 이렇게 하면 검색할 콘텐츠 구성용으로만 폴더를 사용하는 대신 정책 및 보존 관리용으로도 폴더를 사용할 수 있습니다.

• 최선의 사용자 환경이 제공되는 경우에는 탐색 지원을 위해 콘텐츠를 폴더로 구성할 수 있습니다(다른 탐색 옵션과 함께 사용하는 경우도 해당됨).

• 콘텐츠 구성 도우미를 사용하여 문서를 메타데이터에 따라 폴더로 자동 이동하는 경우, 특정 한도에 도달하면 하위 폴더에 추가 항목을 만드는 옵션을 사용할 수 있습니다.

• 탐색기에서 열기(WebDAV)를 사용하려는 경우에는 항목을 폴더로 구성할 때 특정 폴더의 루트에 포함된 항목 수가 목록 보기 임계값보다 적도록 해야 합니다.

• 폴더를 사용하지 않는 경우 목록 보기에서 콘텐츠를 검색하려면 메타데이터 탐색을 사용해야 합니다.

공동 작업용 큰 목록 및 폴더 예제: 제품 사양 라이브러리

제품 사양 라이브러리에서는 폴더를 사용하여 탐색을 지원하고 콘텐츠를 논리적으로 배치합니다. 사용자는 새 제품 사양을 만들 때 어떤 폴더를 사용해야 하는지를 잘 알고 있습니다. 각 제품 유형에 대한 폴더가 있으며, 각 제품 유형에는 각 제품 팀에 해당하는 여러 개의 폴더가 있습니다. 각 제품 팀은 디자인 중인 각 제품에 대한 문서 집합을 보유하고 있으며, 특정 제품과 관련된 문서가 문서 집합에 저장됩니다. 이를 통해 다음과 같은 구조가 생성됩니다.

• 활강 스키 - 제품 유형(폴더)

  • 경기용 스키 - 제품 팀(폴더)

    초고속 활강용 Racer X - 제품(문서 집합)

각 폴더에 대해 메타데이터 기본값을 구성할 수 있으며, 그러면 라이브러리 사용자가 폴더를 사용하여 콘텐츠를 쉽게 찾을 수 있습니다.

대형 보관함 및 폴더 예제: 레코드 센터

레코드 센터 사이트는 법적 준수를 위해 보관해야 하지만 콘텐츠를 더 이상 수정하지는 않는 항목의 장기 저장소로 사용됩니다. 이 시나리오에서 항목은 제한된 폴더 및 기밀 폴더의 두 폴더로 자동 라우팅됩니다. 제한된 폴더의 경우 소수의 사용자에게만 액세스가 허용되는 엄격한 사용 권한이 적용되며, 문서를 10년 동안 보관해야 합니다. 기밀 폴더의 경우 제한된 폴더보다는 많은 사용자가 액세스할 수 있으며 문서를 7년 동안 보관해야 합니다. 이러한 폴더를 사용하면 항목이 해당 폴더로부터 사용 권한을 받으므로 고유한 사용 권한 수를 줄이고 사용 권한을 보다 쉽게 관리할 수 있습니다. 레코드 센터 사이트에 저장되는 모든 항목은 메타데이터에 따라 루트, 기밀 폴더 또는 제한된 폴더로 라우팅됩니다.

인덱스

목록당 작성할 수 있는 인덱스의 한도는 20개(구성 불가)이며, 여기에는 복합 인덱스 및 기본적으로 열을 인덱싱하는 SharePoint Server 2010 기능이 포함됩니다. 목록에 인덱스를 추가해도 성능에는 거의 영향이 없지만 추가, 업데이트 등의 일부 작업에는 영향을 줍니다. 사용하지 않는 인덱스가 있으면 성능이 약간 저하될 수 있으며, 일부 SharePoint Server 2010 기능은 사용하도록 설정되면 인덱스를 추가하므로 필요 이상으로 많은 인덱스를 사용하지 않아야 합니다. 예를 들어 만료 및 eDiscovery 기능을 사용하는 경우 SharePoint Server 2010에는 최소 3개의 인덱스 슬롯이 필요합니다. 나중에 새 인덱스를 만들어야 하는 경우에 대비하여 사용 가능한 인덱스 슬롯을 3개 이상으로 유지하십시오.

SharePoint Server 2010에서는 고유한 인덱싱 메커니즘을 통해 해당 데이터베이스 테이블 구조를 사용합니다. SharePoint Server에서는 목록 설정을 수정하여 인덱스를 만듭니다.

인덱스를 계획할 때는 다음 사항을 고려하십시오.

• 목록 보기 임계값이 초과된 목록에 대해 필터링을 수행하려면 인덱스가 필요합니다.

• 인덱스는 20개까지만 만들 수 있으므로 만들 단일 인덱스 및 복합 인덱스를 적절하게 계획해야 합니다.

• eDiscovery, 정보 관리 정책 보존 등 열을 만들어야 할 수 있는 SharePoint Server 2010 기능용으로 인덱스 슬롯을 예약해 둡니다.

• 단일 필터로 많이 사용되는 필터 및 메타데이터 탐색 계층 구조를 사용할 때와, 단일 필드를 사용해 콘텐츠 쿼리 웹 파트를 필터링하거나 필터가 포함된 보기를 사용할 때는 단일 인덱스를 만듭니다.

• 두 열을 사용하여 필터링하며, 보통 개별적으로는 목록 보기 임계값보다 많은 항목을 반환하지만 함께 선택 가능한 쿼리의 경우에는 복합 인덱스를 만듭니다.

• 인덱스로 인해 문서 추가/문서 속성 편집 등의 일부 작업 성능이 저하될 수 있으므로 필요한 경우에만 인덱스를 만듭니다.

면밀한 인덱스 계획

인덱스 및 인덱싱된 열에 대해 하드 한도 20개가 적용되는 목록은 큰 목록에서 매우 중요한 요소입니다. 따라서 단일 인덱스와 복합 인덱스를 주의하여 선택해야 합니다. 인덱스는 다양한 기능에 사용됩니다. 예를 들어 메타데이터 탐색 기능은 구성된 탐색 계층 구조 및 키 필터를 자동으로 인덱싱합니다. 탐색 및 정보 아키텍처에서 필터링에 중요한 역할을 하는 열에 대해 인덱스를 만들어야 합니다.

자동으로 만들어진 인덱스

SharePoint Server 기능은 목록 인덱스 한도에 합산되는 인덱스를 만들 수 있습니다. 아래 표에는 문서 라이브러리에서 일반적으로 사용되며 인덱싱된 열을 추가하는 SharePoint Server 2010 기능 목록이 나와 있습니다.

열	기능	사용법
보류 및 보고서 상태	현재 위치 레코드 관리 또는 보류 및 eDiscovery	현재 위치 레코드 관리 사이트 모음 기능이나 보류 및 eDiscovery 기능이 사용하도록 설정된 상태에서 항목을 레코드로 선언하거나 목록에서 보류하면 이 열이 추가되고 인덱싱됩니다.
만료 날짜, 콘텐츠 형식	정보 관리 정책	목록에 대해 위치 기반 보존이 설정되어 있거나, 목록에 추가하는 콘텐츠 형식에 대한 정보 관리 정책에 보존이 설정되어 있으면 이 두 열이 추가되고 인덱싱됩니다.

단일 인덱스와 복합 인덱스를 만드는 경우

메타데이터 탐색 기능은 메타데이터 탐색 설정 페이지에서 선택하는 계층 구조 및 키 필터 열에 대해 적절한 인덱스를 자동으로 만듭니다. 단일 인덱스는 모든 계층 구조 트리 필드와 보다 제한적인 일부 키 필터 유형에 대해 만들어집니다. 따라서 이러한 인덱스를 단독으로 사용해도 인덱싱된 결과 및 부분 결과가 반환됩니다. 복합 인덱스는 지원되는 모든 계층 구조 및 키 필터 조합에 대해 만들어지며, 따라서 트리 필터와 키 필터 값을 모두 사용하는 경우의 선택도가 최대화됩니다.

필터링할 열이 많은 목록의 경우에는 인덱스 한도에 도달하지 않도록 인덱스를 수동으로 관리해야 할 수 있습니다. 특정 탐색 계층 구조 및 키 필터 조합을 사용하지 않으려는 경우에는 인덱스 수를 줄이기 위해 복합 인덱스를 만들지 않을 수 있습니다. 이러한 인덱스를 만드는 경우, 선택 가능하며 목록 보기에서 단독으로 사용 가능한 열에 대해서는 단일 인덱싱을 선택해야 합니다(단일 필터 또는 다른 필터를 선택하기 전에 적용되는 첫 번째 필터). 일반적으로 메타데이터 탐색 또는 사용자 지정 쿼리에서 두 필터를 함께 사용하며 인덱스 하나만 선택하기는 어려운 경우에는 복합 인덱스를 사용해야 합니다. 목록 보기, 웹 파트 및 기타 데이터 액세스 방법에서 필터링용으로 사용되는 열에 대해서는 인덱스를 만듭니다.

인덱스가 여러 개이면 유용하지 않은 경우도 있습니다. 사업부 및 콘텐츠 형식의 두 열로 필터링하는 경우를 가정해 보겠습니다. 이 필터링은 AND 연산이므로 사업부 및 콘텐츠 형식에 해당하는 필터가 모두 일치하는 '교집합' 부분만 반환됩니다. 즉, 쿼리를 수행하면 사업부 필터와 일치하는 모든 항목이 먼저 반환된 후에 콘텐츠 형식으로 필터링된 항목이 반환됩니다. 특정 사업부와 일치하는 항목이 10개뿐이면 데이터 집합이 작으므로 콘텐츠 형식에 대한 인덱스는 큰 문제가 되지 않습니다. 그러나 사업부의 값과 일치하는 항목이 수천 개인 경우에는 복합 인덱스를 사용해야 합니다.

복합 인덱스를 사용하면 두 열에 대해 인덱스를 만들 수 있으므로 보다 효율적인 쿼리가 가능해집니다. 두 열에 대해 AND 연산을 수행할 때는 복합 인덱스를 사용해야 합니다. 복합 인덱스를 사용하는 기본 제공 SharePoint Server 기능은 메타데이터 탐색뿐입니다. 메타데이터 탐색 기능을 사용할 수 있는 경우에는 목록에 대해 메타데이터 탐색 컨트롤이 구성되어 있지 않아도 다시 시도 및 대체 논리가 사용됩니다. 복합 인덱스는 메타데이터 탐색 쿼리가 아니면 보기에서는 사용되지 않습니다.

성능에 대한 인덱스의 영향

단일 컨테이너에 목록 보기 임계값보다 많은 항목이 포함된 목록에 대해 쿼리를 수행하려면 인덱스가 필요하며, 인덱스를 사용하면 성능을 크게 향상시킬 수 있습니다. 큰 목록에 대해 효율적인 쿼리를 수행하려면 인덱스가 필요하며 인덱스를 통해 쿼리 성능을 크게 향상시킬 수는 있지만, 인덱스를 유지 관리해야 하므로 다른 작업에는 좋지 않은 영향을 줄 수 있습니다. 항목을 작성, 업데이트 및 삭제할 때는 해당 항목이 포함되는 인덱스도 업데이트해야 합니다. 항목이 1만 개 포함된 목록에 대해 업로드/업데이트/삭제 작업 테스트를 수행한 결과, 인덱스가 0~20개일 때의 성능에 대한 영향은 10% 미만이었습니다.

인덱스 만들기

기본적으로 메타데이터 탐색 기능은 단일 인덱스와 복합 인덱스를 자동으로 만듭니다. 메타데이터 탐색 설정 페이지에서 이 옵션을 사용하지 않도록 설정할 수 있습니다. 메타데이터 탐색 기능은 지원되는 각 열 유형에 대해 단일 인덱스를, 지원되는 각 탐색 계층 구조 및 키 필터 조합에 대해 복합 인덱스를 자동으로 만듭니다. 두 키 필터 조합에 대해서는 복합 인덱스가 자동으로 만들어지지 않지만, 수동으로 복합 인덱스를 만들 수 있습니다. 메타데이터 탐색은 인덱스를 지원하는 대부분의 열 유형에 대해 단일 인덱스 및 복합 인덱스를 자동으로 만듭니다. 값의 수가 적고 단독으로는 선택하기 어려운 키 필터 유형에 대해서는 단일 인덱스가 자동으로 만들어지지 않습니다. 여기에는 예/아니요, 단일 값 선택 또는 콘텐츠 형식 열이 포함됩니다. 그러나 이러한 열에 대해서도 인덱스는 지원되며 수동으로 인덱스를 만들 수는 있습니다.

단일 인덱스가 지원되는 열

아래 표에는 메타데이터 탐색에 의해 자동으로 만들어지는 인덱스에 대한 정보가 나와 있습니다. 메타데이터 탐색은 인덱스 만들기를 지원하는 모든 열에 대해 단일 값 인덱스를 만듭니다.

열 유형	인덱스 작성 여부
탐색 계층 구조
단일 값 관리되는 메타데이터	작성
여러 값 관리되는 메타데이터	작성 안 함(시스템에서 여러 값으로 인덱싱됨)
콘텐츠 형식 ID	작성
단일 값 선택	작성
폴더	작성 안 함(시스템에서 폴더별로 인덱싱됨)
키 필터
단일 값 관리되는 메타데이터	작성
여러 값 관리되는 메타데이터	작성 안 함(시스템에서 여러 값으로 인덱싱됨)
콘텐츠 형식 ID	작성 안 함(수동 작성 가능)
단일 값 선택	작성 안 함(수동 작성 가능)
여러 값 선택	작성 안 함(인덱싱되는 열로 지원되지 않음)
숫자	작성
날짜	작성
예/아니요	작성 안 함(수동 작성 가능)
통화	작성
사용자(단일 값)	작성
사용자(여러 값)*	작성 안 함(시스템에서 여러 값으로 인덱싱됨)
모든 태그	작성 안 함(시스템에서 여러 값으로 인덱싱됨. 항목의 모든 관리되는 메타데이터 값에 대해 특수 필터가 사용됨)

자동으로 작성되는 복합 인덱스

메타데이터 탐색 기능을 사용하는 경우 탐색 계층 구조와 키 필터를 함께 선택할 수 있습니다. 메타데이터 탐색 기능은 지원되는 모든 탐색 계층 구조 및 키 필터 조합에 대해 복합 인덱스를 자동으로 만듭니다. 아래 표에는 지원되는 조합이 나와 있습니다.

탐색 계층 구조	단일 값 관리되는 메타데이터	여러 값 관리되는 메타데이터	콘텐츠 형식 ID	단일 선택	폴더
키 필터
단일 값 관리되는 메타데이터	예	아니요	예	아니요	아니요
여러 값 관리되는 메타데이터	아니요	아니요	아니요	아니요	아니요
콘텐츠 형식 ID	예	아니요	아니요	아니요	아니요
단일 값 선택	아니요	아니요	아니요	아니요	아니요
여러 값 선택	아니요	아니요	아니요	아니요	아니요
숫자	예	아니요	예	아니요	아니요
날짜	예	아니요	예	아니요	아니요
사용자(단일)	예	아니요	예	아니요	아니요
모든 태그	아니요	아니요	아니요	아니요	아니요
예/아니요	예	아니요	예	아니요	아니요
통화	예	아니요	예	아니요	아니요
사용자(여러 값)	아니요	아니요	아니요	아니요	아니요

메타데이터 선택도

목록이 커지면 메타데이터 선택도의 중요성도 높아집니다. 아래 권장 사항은 모든 목록 크기에 적용되지만 작은 목록의 경우에는 그다지 중요하지 않을 수도 있습니다.

선택도는 쿼리의 결과로 반환되는 것으로 간주해야 하는 항목의 수입니다. 선택도에는 실제 선택도(쿼리 검색 조건과 일치하는 총 결과 수)와 제한 선택도(인덱싱된 열에 적용되는 조건을 적용한 후에 고려해야 하는 결과의 수)라는 두 가지 요소가 있습니다. 사용자 환경을 고려할 때는 주로 실제 선택도를 고려합니다. 제한 선택도는 SQL Server 인스턴스에 대한 영향을 고려할 때 주로 고려합니다.

메타데이터 탐색 및 기타 목록 필터링 메커니즘을 효율적으로 사용하려면 필터링에 사용되는 메타데이터가 제한적이어야 합니다. 기본적으로는 사용자가 결과를 빠르게 검색하여 원하는 항목을 찾을 수 있도록 목록 보기에는 30개의 항목이 표시됩니다. 쿼리에서 30개보다 많은 결과가 반환되는 경우 사용자는 페이징을 통해 결과를 찾아야 합니다. 콘텐츠 쿼리 웹 파트를 사용하는 경우에는 보통 결과가 10~15개 반환됩니다. 결과 수가 이보다 많으면 추가 결과는 표시되지 않습니다. 쿼리 결과가 수백 개에 달하는 경우에는 원하는 항목을 찾기가 어려워집니다. 선택도는 목록 보기 임계값을 초과하는 작업을 방지하는 데도 중요합니다. 메타데이터 탐색의 경우 이러한 작업을 수행하면 대체가 수행되며 결과가 일부만 반환됩니다.

콘텐츠 구성 도우미 및 자동 균형 조정

콘텐츠 구성 도우미는 문서 저장소의 콘텐츠를 구성하는 데 있어 중심적인 역할을 하는 구성 요소가 될 수 있습니다. 콘텐츠 구성 도우미를 사용하는 저장소의 경우 사용자가 최종 상태의 문서를 업로드하는 전송 환경이 있습니다. 콘텐츠 구성 도우미를 사용할 수 있는 시나리오의 예는 다음과 같습니다.

• 메타데이터를 기반으로 사이트 간에/사이트 내에서 문서를 자동으로 라우팅하는 경우

• 문서를 라우팅하고 일/월/년 기준 폴더와 같이 새 폴더를 자동으로 만드는 경우

• 폴더의 항목 수 균형을 자동으로 조정하려는 경우

데이터 액세스 및 검색

큰 목록은 주로 콘텐츠를 검색 가능하도록 저장하는 데 사용됩니다. 이 경우 사용자의 콘텐츠 검색 방법을 적절하게 계획해야 하는데, 이 방법은 큰 목록의 성능과 큰 목록 구현의 성공 여부에 가장 큰 영향을 주기 때문입니다. 검색, 메타데이터 탐색, 콘텐츠 쿼리 웹 파트, 보기 등의 여러 기능을 모두 활용하여 사용자의 콘텐츠 검색을 지원할 수 있습니다. 데이터를 쿼리하는 사용자 지정 웹 파트와 같은 사용자 지정 솔루션 역시 흔히 사용됩니다. 웹 사이트 구성 방법을 미리 계획하십시오. 문서 센터 사이트의 홈 페이지와 같은 중앙 방문 페이지를 사용하여 콘텐츠를 롤업하고 큰 목록 진입점을 제공할 수 있습니다. 게시 페이지를 사용하여 각 페이지에서 다양한 주제에 대해 다루는 웹 사이트를 만든 다음 웹 파트를 사용하여 큰 목록에서 관련 항목이나 문서를 가져올 수도 있습니다. 데이터 액세스 및 검색과 관련해서는 다음과 같은 사항을 고려해야 합니다.

• 검색, 콘텐츠 쿼리 웹 파트, 메타데이터 탐색, 목록 보기 및 사용자 지정 웹 파트를 원하는 대로 조합하여 사용할 수 있습니다.

• 콘텐츠 검색 방법 및 필터링/정렬에 사용할 열을 미리 계획합니다.

• 기본 페이지 모델을 계획합니다. 또한 문서 라이브러리에서 모든 작업을 수행할지, 아니면 관련 콘텐츠에 연결되는 여러 페이지 모델이나 방문 페이지 모델을 사용할지를 고려합니다.

데이터 액세스 방법

세 가지 기본 SharePoint Server 2010 기능을 사용하여 간단한 구성에서 목록 데이터를 쿼리 및 필터링할 수 있습니다. 이 세 기능은 목록 보기와 메타데이터 탐색, 콘텐츠 쿼리 웹 파트, 그리고 검색입니다. 사용자 지정 코드를 통해 목록을 쿼리하기 위한 추가 옵션도 있으나, 이 문서에서는 이러한 옵션에 대해 설명하지 않습니다.

• 보기를 사용하면 표시되는 열을 구성할 수 있습니다. 목록 데이터는 다양한 방법으로 표시할 수 있습니다. 열을 기준으로 결과를 필터링 및 정렬하도록 보기를 구성할 수 있습니다.

  • 메타데이터 탐색은 SharePoint Server 2010 목록 보기용 필터링 컨트롤입니다. 메타데이터 탐색이 구성되어 있으면 목록 보기에 표시되는 결과를 동적으로 필터링하기 위한 메타데이터 계층 구조 및 키 필터를 선택할 수 있습니다.

• 콘텐츠 쿼리 웹 파트는 SharePoint Server 2010 목록의 데이터를 표시합니다. 한 목록 또는 여러 목록에서 결과를 반환하도록 쿼리를 구성할 수 있습니다. 기본적으로 콘텐츠 쿼리 웹 파트는 캐시되지만 캐시되지 않도록 지정할 수도 있습니다.

• 검색 상자 또는 검색 결과 웹 파트를 사용하면 검색 결과를 반환할 수 있습니다. 이러한 결과의 범위를 특정 목록으로 좁히고 검색 메타데이터 구체화 컨트롤을 사용하여 안내가 제공되는 검색을 수행할 수 있습니다.

아래 표에는 쿼리 방법 및 사용 방법이 나와 있습니다.

쿼리 방법	사용법
목록 보기 및 메타데이터 탐색	목록 보기는 항상 SQL Server 백 엔드 데이터베이스에 액세스하므로 쿼리가 성능에 가장 큰 영향을 주며 SQL Server의 부하가 높아집니다. 보다 많은 문서 상호 작용(체크 인, 체크 아웃, 속성 편집) 옵션을 제공하고 데이터에 실시간으로 액세스할 수 있도록 하려면 목록 보기를 사용합니다.
콘텐츠 쿼리 웹 파트	콘텐츠 쿼리 웹 파트는 포털 사이트 맵 공급자를 사용하여 쿼리를 캐시하며, 가장 적은 양의 HTML을 렌더링하므로 쿼리 속도가 빠르고 렌더링 시간이 적게 걸립니다. 단일 페이지에 대해 여러 쿼리를 수행하려는 경우 및 동적 탐색 시에는 콘텐츠 쿼리 웹 파트를 사용합니다.
콘텐츠 쿼리 웹 파트(캐시 안 됨)	실시간 데이터 액세스를 제공하기 위해 콘텐츠 쿼리 웹 파트는 데이터베이스를 직접 쿼리할 수 있습니다. 쿼리를 캐시할 수 없는 경우, 실시간 업데이트가 필요한 경우 및 페이지 액세스 빈도가 시간당 1회 미만이라 캐시가 채워지지 않는 경우에는 이 구성을 사용합니다. 캐시된 콘텐츠 쿼리 웹 파트의 최초 로드 시에는 추가 오버헤드가 발생합니다.
검색	쉽게 확장할 수 있으며 읽기 성능을 높이도록 최적화된 서버 인프라에서 읽기 작업을 수행하도록 하려면 검색 쿼리를 사용합니다. 정적 쿼리를 사용하도록 검색 쿼리를 구성할 수도 있고 사용자가 검색 쿼리를 지정하도록 허용할 수도 있습니다.

콘텐츠 쿼리 웹 파트

아래 표에는 콘텐츠 쿼리 웹 파트 사용 시의 여러 장단점이 나와 있습니다.

장점	단점
관련 문서나 페이지에 대한 링크 등 탐색 구성 요소와 같이 효율적으로 사용 가능합니다. 간단한 구성을 통해 여러 열을 표시할 수 있습니다. 여러 콘텐츠 쿼리 웹 파트를 한 페이지에서 쉽게 사용할 수 있습니다. 검색 및 목록 보기에 비해 렌더링 시간이 짧습니다. 기본적으로 캐시되므로 SQL Server 부하가 줄어듭니다.	제한된 속성만 표시할 수 있습니다. 링크가 문서, 페이지 또는 목록 항목 자체와 같은 항목으로 직접 연결됩니다. 목록 작업을 수행할 수 없습니다.

콘텐츠 쿼리 웹 파트는 목록에서 콘텐츠를 검색하는 데 사용되며 페이지, 문서 및 목록 항목에 대해 사용할 수 있습니다. 기본적으로 콘텐츠 쿼리 웹 파트는 캐시되므로 성능을 높이고 SQL Server 리소스에 대한 영향을 줄일 수 있습니다. 기본 캐시 설정은 30분이므로 데이터가 비교적 최신 상태로 유지되지만, 이는 콘텐츠 쿼리 웹 파트가 검색 쿼리보다 많은 SQL Server 리소스를 사용한다는 의미이기도 합니다. 콘텐츠 쿼리 웹 파트는 가장 적은 양의 HTML을 렌더링하므로 페이지 렌더링 속도가 빠르며, 여러 콘텐츠 쿼리 웹 파트를 단일 페이지에서 구성할 수 있습니다. 캐시된 콘텐츠 쿼리 웹 파트를 사용하는 경우 목록 크기가 커져도 데이터에 빠르게 액세스할 수 있으며, 캐시되지 않은 콘텐츠 쿼리 웹 파트의 경우 대기 시간이 있기는 하지만 이는 유사한 목록 보기 쿼리와 거의 동일합니다.

콘텐츠 쿼리 웹 파트는 페이지에서 콘텐츠 롤업을 제공하기 위해 탐색 구성 요소로 사용해야 합니다. 예를 들어 페이지를 통해 문서 라이브러리에 있는 콘텐츠 개요를 제공한 다음 콘텐츠 쿼리 웹 파트를 사용하여 관련 페이지 및 문서를 반환할 수 있습니다. 다른 예로는 현재 사용자가 수정한 항목, 최신 항목, 등급이 가장 높은 항목 등이 있습니다. 대부분의 사용자가 체크 인, 체크 아웃, 버전 관리 등의 목록 작업을 수행할 필요가 없는 읽기 집약적 시나리오에서 콘텐츠 쿼리 웹 파트를 사용할 수 있습니다. 아래 그림에는 등급이 가장 높은 문서가 표시되는 콘텐츠 쿼리 웹 파트가 나와 있습니다.

콘텐츠 쿼리 웹 파트를 사용하면 목록 보기에 액세스하지 않고도 콘텐츠에 액세스할 수 있습니다. 소수의 콘텐츠에 자주 액세스하거나 추적하려는 항목이 있는 경우, 문서 센터 사이트 서식 파일에서는 이러한 용도로 사용 가능한 콘텐츠 쿼리 웹 파트 3개가 기본 제공됩니다. 이 세 웹 파트는 각각 로그인한 사용자가 수정한 항목, 등급이 가장 높은 문서, 그리고 최신 문서를 반환합니다. 이 세 콘텐츠 쿼리 웹 파트는 함께 조합되어 액세스 빈도나 관심도가 높은 콘텐츠가 표시되는 방문 페이지를 제공합니다. 이 페이지를 통해 새로운 콘텐츠를 검색하고 자주 사용하는 문서에 빠르게 액세스할 수 있습니다. 또 다른 예로는 사용자가 추적할 콘텐츠를 표시할 수 있는 즐겨찾기 목록을 만든 다음 콘텐츠 쿼리 웹 파트를 사용하여 즐겨찾기 목록을 반환하는 방식이 있습니다. 이렇게 하면 사용자가 목록 자체에 액세스하지 않고도 자주 사용하는 콘텐츠에 빠르게 액세스할 수 있습니다.

큰 목록에서 콘텐츠 쿼리 웹 파트를 사용하는 경우에는 결과가 올바르게 반환되고 목록 보기 임계값으로 인해 쿼리가 차단되지 않도록 하기 위해 고려해야 하는 몇 가지 중요한 사항이 있습니다. 우선, 인덱싱된 열을 사용하여 목록 보기 임계값보다 적은 수로 항목을 필터링해야 합니다. 목록 중 하나가 큰 목록이면 교차 목록 쿼리를 사용하지 않는 것이 좋습니다. 교차 목록 쿼리에서 고려하는 항목의 총 수가 감사자 및 관리자의 목록 보기 임계값(기본적으로 2만 개)보다 많은 경우에는 작업이 차단됩니다.

콘텐츠 쿼리 웹 파트 권장 사항 요약

• 자주 액세스하거나 관심도가 높거나 사용자의 콘텐츠 검색을 지원하는 데 사용될 수 있는 항목을 반환하려면 콘텐츠 쿼리 웹 파트를 사용합니다.

• 큰 목록에 대해 콘텐츠 쿼리 웹 파트를 사용할 때는 쿼리가 목록 보기 임계값을 초과하지 않도록 항목을 필터링해야 합니다.

• 필터링용으로는 인덱스가 포함된 열만 사용해야 합니다.

• 쿼리에서 고려하는 항목의 총 수가 감사자 및 관리자의 목록 보기 임계값(기본적으로 2만 개)보다 많은 경우에는 콘텐츠 쿼리 웹 파트를 사용하여 여러 목록을 쿼리하지 않습니다.

• 로드 시간을 단축하고 SQL Server 부하를 줄이려면 캐싱을 사용합니다.

검색 웹 파트

아래 표에는 검색 웹 파트의 여러 장단점이 나와 있습니다.

장점	단점
SQL Server를 실행하는 컴퓨터에서 보다 쉽게 확장할 수 있는 검색 서버로 쿼리 작업을 오프로드할 수 있습니다. 검색 쿼리와 인덱스 서버는 SQL Server를 직접 쿼리하는 것보다 쉽게 확장할 수 있으며 성능이 뛰어납니다. 결과가 메타데이터만이 아닌 문서의 전체 텍스트 검색 결과를 기반으로 합니다. 텍스트 요약을 통해 콘텐츠 쿼리 웹 파트보다 많은 결과 관련 정보가 제공됩니다.	결과가 가장 오래된 상태입니다(가장 최근의 크롤링 시점 상태). 결과에 열 값이 표시되지 않습니다. 목록 작업을 수행할 수 없습니다.

검색 쿼리는 SQL Server 리소스에 직접 액세스하는 것보다 확장성이 뛰어납니다. 검색이 읽기 집약적 시나리오에 최적화되어 있으며, SQL Server 인스턴스를 확장하는 것보다 여러 검색 인덱스 및 쿼리 서버로 수평 확장하는 것이 보다 쉽기 때문입니다. 미리 구성된 검색 웹 파트 또는 검색 상자를 사용하거나 이 두 항목을 조합하여 사용자의 콘텐츠 검색을 지원할 수 있습니다. 검색 쿼리를 사용하는 경우 쿼리를 검색 인덱스로 오프로드할 수 있어 SQL Server의 부하가 감소합니다. 또한 검색 쿼리는 콘텐츠 쿼리 웹 파트 또는 목록 보기 쿼리에 비해 목록 크기의 영향을 적게 받습니다.

미리 구성된 쿼리 또는 사용자 지정 쿼리의 결과를 표시하는 모든 시나리오에서 검색을 사용할 수 있습니다. 검색은 확장성이 높은 영역에서 최고의 성능을 제공합니다. 항목에 대해 목록 작업 수행해야 하거나 데이터를 실시간으로 표시해야 하는 경우에는 검색을 사용하면 안 됩니다. 검색에서 반환되는 결과는 가장 최근 크롤링 시의 데이터이기 때문입니다. 아래 표에는 사용 가능한 검색 웹 파트 세 개가 나와 있습니다.

검색 웹 파트	설명
핵심 결과 웹 파트	페이징을 통해 전체 결과가 제공되며 모든 기능이 갖춰진 웹 파트입니다. 시스템 또는 사용자 지정 쿼리를 사용할 수 있습니다.
연결된 결과 웹 파트	전체 결과 액세스를 위한 링크(선택 사항)가 포함된 작은 결과 집합입니다.
검색 상자 웹 파트	사용자가 쿼리할 내용을 입력하는 웹 파트입니다.

목록 보기

아래 표에는 목록 보기 사용 시의 여러 장단점이 나와 있습니다.

장점	단점
체크 인, 체크 아웃, 속성 편집 등의 목록 보기 작업을 통해 문서와 상호 작용할 수 있습니다. 보기를 쉽게 사용자 지정하고 다른 열을 표시할 수 있습니다. 고도의 대화형 환경이 제공되므로 결과를 실시간으로 동적 필터링 및 정렬할 수 있습니다.	대기 시간 및 처리량과 관련하여 성능을 가장 크게 저하시킵니다. 렌더링 시간이 가장 오래 걸립니다. 페이지당 목록 보기 웹 파트가 하나일 때만 최상의 사용자 환경이 제공됩니다.

목록 보기 및 메타데이터 탐색은 폴더 및 인덱스 중 하나 또는 둘 모두를 사용하는 큰 문서 라이브러리에서 콘텐츠 검색을 지원할 수 있습니다. 목록 보기 쿼리는 실시간으로 수행되며 SQL Server 데이터베이스를 직접 쿼리하기 때문에 결과가 가장 최신 상태입니다. 그러나 이러한 방식은 성능에 가장 큰 영향을 줍니다. 목록 크기가 크면 전체 처리량이 감소하며 작업 대기 시간도 길어집니다. 또한 목록 보기는 페이지 로드를 위해 가장 많은 콘텐츠를 렌더링하므로 목록 보기 사용 시에는 페이지 렌더링 시간이 길어지는 경우가 많습니다.

항목에 대해 목록 보기 작업을 수행해야 하는 경우에는 메타데이터 탐색 및 목록 보기를 사용해야 합니다. 읽기 작업 빈도가 낮은 시나리오에서는 목록 사용 시 목록 보기를 기본적으로 사용할 수 있습니다. 읽기 작업을 많이 수행하는 경우에는 목록 데이터 액세스 시 사용할 기본 방법으로 다른 쿼리 방법을 고려해야 할 수 있습니다.

보기 구성

보기 구성 권장 사항 요약

• 보기에 사용되는 열을 주의하여 선택합니다. 열 수가 많아지면 렌더링할 데이터도 많아지므로 페이지 로드 시간이 길어지며, 그러면 최적의 사용자 환경을 유지하기가 어려워집니다.

• 보기의 조회 열(예: 관리되는 메타데이터와 사용자 및 그룹) 수를 최소화합니다. 조회 열이 많으면 다른 데이터베이스 테이블과의 조인이 수행되어 데이터베이스 부하가 증가하기 때문입니다.

• 열에는 요약을 사용하지 않습니다.

• 인덱싱된 열을 사용하여 보기를 필터링하지 않는 경우에는 폴더의 항목을 표시하는 옵션을 선택하고 개별 폴더의 항목이 목록 보기 임계값보다 많지 않도록 해야 합니다.

• 반환되는 항목 수를 줄이려면 인덱싱된 열에서 보기를 필터링해야 합니다. 이를 통해 항목 수를 목록 보기 임계값보다 적게 유지해야 합니다(특히 하위 폴더가 없거나 폴더에 목록 보기 임계값보다 많은 항목이 포함된 경우).

• 일반적인 경우에는 목록 보기 임계값에 의해 차단되는 쿼리에 대해 최신 결과를 반환할 수 있도록 메타데이터 탐색 기능을 설정합니다. 기본적으로는 거의 모든 사이트에서 이 기능이 사용하도록 설정됩니다.

• 필터링된 보기와 메타데이터 탐색을 함께 사용하는 경우에는 모든 결과가 반환되도록 위치별 보기를 통해 메타데이터 탐색 피벗용으로 필터링되지 않은 보기를 만들 수 있습니다.

열 및 조회 열의 수

보기는 목록 데이터에 액세스하는 데 가장 일반적으로 사용되는 방법입니다. 사용자가 콘텐츠를 찾는 방법을 최적화하고 성능 요구 사항을 충족하려면 보기를 주의하여 선택해야 합니다. 큰 목록의 경우 특히 보기 구성 방법을 면밀하게 확인해야 합니다. 표준 보기와 사용자 지정 보기만 사용하는 것이 좋습니다. 데이터시트 보기, Gantt 보기 및 일정 보기의 경우 목록 보기 임계값에 의해 작업이 차단될 수 있으므로 목록 보기 임계값을 초과하는 목록에는 사용하지 않는 것이 좋습니다. 보기에서는 열 수를 최소화해야 하며, 특히 조회 열(관리되는 메타데이터, 사용자 및 그룹, 조회 종류)을 적절한 수로 포함해야 합니다. 조회 시에는 다른 테이블과의 조인이 수행되어 성능에 영향을 주기 때문입니다.

열 필터링 및 요약

SharePoint Server 2010에서는 새로운 목록 보기 임계값이 적용되어 큰 목록에서 보기를 사용하는 방법이 크게 변경되었습니다. 보기에서 목록 보기 임계값보다 많은 결과를 반환하려고 하면 오류가 발생합니다. 큰 목록에 대해 요약을 사용하려는 시도는 항상 목록 보기 임계값에 의해 차단되므로, 요약은 사용해서는 안 됩니다. 중요한 요소는 반환되는 행 수가 아닌 검색해야 하는 항목 수입니다. 보기에 색 = "빨강" 열이 포함된 필터가 있는데 색이 인덱싱된 열이 아니면 보기 작업이 차단될 수 있습니다. 쿼리와 일치하는 항목은 100개뿐이라도 목록의 항목 수가 1만 개이면 쿼리는 1만 개의 항목을 모두 검색해야 합니다. 이 경우 사용자가 보기에 액세스하려고 하면 오류가 발생합니다. 이 문제를 해결하려면 폴더, 필터 및 인덱싱, 그리고 메타데이터 탐색을 사용하면 됩니다.

폴더

모든 폴더에 목록 보기 임계값보다 적은 항목이 포함되도록 목록이 구성된 경우 폴더의 항목을 표시하는 옵션을 선택할 수 있습니다. 결과의 수가 목록 보기 임계값보다 적도록 필터링하는 메커니즘이 있는 경우가 아니면 폴더 외부의 모든 항목을 표시하도록 지정해서는 안 됩니다.

인덱싱

앞서 설명한 예제에서는 색 열에 대해 쿼리를 수행하는 경우 열이 인덱싱되지 않았으므로 쿼리가 실패합니다. 이 문제를 해결하기 위해 색 열을 인덱싱할 수 있으며, 그러면 값이 고유한 경우 쿼리가 작동합니다. 빨강 항목이 100개뿐이면 쿼리는 작동하지만, 일치하는 항목이 목록 보기 임계값보다 많으면 인덱싱을 수행해도 작업이 차단됩니다. 기본적으로 ID 필드, 폴더 구조 및 여러 값 조회는 시스템에서 인덱싱됩니다. 새로 만들어 필터링에 사용하는 모든 열에는 수동으로 만든 인덱스가 있어야 합니다.

예제 보기

최근 변경된 항목

최근 변경된 항목 보기는 가장 최근에 변경된 항목을 표시하는 데 사용되며, 사용자가 최근에 수정된 다양한 원본의 콘텐츠에 자주 액세스하는 경우 기본 보기로 사용할 수 있습니다. 이 보기는 모든 항목에 대해 항상 설정되는 시스템 메타데이터를 사용하므로 쉽게 구성할 수 있습니다. 큰 목록의 경우 항목 한도를 목록 보기 임계값보다 작게 설정하거나 결과를 목록 보기 임계값보다 적은 수로 필터링해야 합니다. 이 보기를 만들려면 수정된 필드를 인덱싱하고 내림차순으로 정렬해야 합니다. 수정한 날짜 열에 대해 필터를 지정하고 오늘-x] 수식을 사용합니다. 여기서 x는 데이터를 표시할 기간(일)입니다. 옵션으로는 보다 큼 또는 같음을 선택합니다. [오늘-x] 수식은 목록 보기 임계값보다 적은 수의 항목을 반환해야 합니다.

내 항목

내 항목 보기는 사용자가 자신의 문서에 자주 액세스하는 저장소에서 사용할 수 있습니다. 이 보기는 모든 항목에 대해 항상 설정되는 시스템 메타데이터를 사용하므로 쉽게 구성할 수 있습니다. 이 보기에서는 수정한 사람 열이나 만든 사람 열 중 하나 또는 둘 다를 사용하여 필터링합니다. 필터에서 이 보기를 만들려면 수정한 사람 열을 선택하고 값을 [ME]로 설정한 후에 OR를 사용하여 만든 사람 열에서 역시 값을 [ME]로 설정해 두 번째 필터를 설정합니다. 여러 사용자가 같은 문서를 편집하는 경우에는 수정한 사람 열과 함께 만든 사람 열을 사용해야 합니다. 수정한 사람 열은 여러 사용자 열이 아니므로 이 보기에는 사용자가 현재까지 수정한 모든 문서가 표시되지는 않습니다. 이 예제에서는 해당 작업이 OR 연산이므로 두 열을 모두 인덱싱해야 합니다.

결론

SharePoint Server 2010에서는 큰 목록 작업 성능과 사용자 환경을 개선하는 새로운 기능과 개선된 기능이 제공됩니다. 제한과 한도를 적용하여 다른 사용자의 팜 성능을 유지하고 특정 작업이 SQL Server 리소스를 비정상적으로 많이 사용하지 않도록 방지할 수 있습니다. 향상된 메타데이터와 메타데이터 탐색은 목록 데이터 검색을 위한 향상된 환경을 제공합니다. 또한 큰 목록에서 사용할 수 있도록 콘텐츠 쿼리 웹 파트, 검색 및 목록 보기를 구성할 수 있습니다. 요구 사항에 적합한 솔루션을 만들려면 면밀한 계획이 필요합니다. 그러나 뛰어난 성능으로 작업할 수 있도록 디자인된 기본 솔루션을 구성하여 큰 목록을 빠르게 개발할 수 있습니다.

See Also

Other Resources

리소스 센터: SharePoint Server 2010의 용량 관리