내부 SharePoint SharePoint 외부 저장소 솔루션 만들기
Pav Cherny
사용할 수 있는 코드 다운로드: ChernySharePoint2009_06.exe2,006 크기(KB)
내용
내부 이진 저장소
외부 이진 저장소
관리되지 않는 EBS 공급자 빌드
관리되는 EBS 공급자 빌드
SharePoint EBS 공급자 등록하는
가비지 컬렉션 구현
결론
Microsoft은 WSS (Microsoft Windows SharePoint Services) 3 및 Microsoft Office SharePoint Server (MOSS) 2007 콘텐츠 데이터베이스에 저장된 데이터의 80 % 만큼 Microsoft Office Word 문서, Microsoft Office Excel 스프레드시트 및 Microsoft Office PowerPoint 프레젠테이션 같은 관계형 아닌 이진 BLOB (Large Object) 데이터가 있는지 예측합니다. 20 % 데이터베이스 백 엔드 위치에 Microsoft SQL Server 리소스의 만족스러운 사용을 의미하는 관계형 메타데이터 것입니다. SharePoint은 FILESTREAM 특성 또는 원격 BLOB 저장소 API와 같은 SQL Server 2008 도입된 구조화되지 않은 데이터의 최신 SQL Server 혁신 장점은 사용하지 않는 있지만 저장 효율성 및 방대한 데이터 볼륨의 효율성을 높이기 위해 옵션을.
특히, SharePoint 외부 이진 저장소 공급자 API, Microsoft 먼저 5월 2007 에서 as a hotfix 게시 및 서비스 팩 1 이상을 통합할 ISPExternalBinaryProvider 포함되어 있습니다. ISPExternalBinaryProvider API를 원격 BLOB 저장소 API를 별개의 것입니다. 타사 공급업체에서 이 API를 사용하여 SharePoint 콘텐츠 주소 지정이 가능한 저장소 (CAS) 시스템 같은 고급 저장소 솔루션을 통합할 수 있습니다. 또한 이 API를 사용하여 저장 효율성 및 SharePoint 팜의 확장성을 높이기 위해 사용자 지정 솔루션을 빌드할 경우 콘텐트 데이터베이스 외부에서 중앙 파일 서버의 SharePoint BLOB 데이터를 유지할 수 있습니다. 그러나 염두에, WSS 3.0 및 MOSS 2007의 이 API가 관련되어 있는. 공급자에게 업데이트 합니다 즉 다음 SharePoint 릴리스에서 변경됩니다.
이 칼럼에서는 SharePoint 저장소 아키텍처 장점 및 단점, 구현 세부 사항을, 성능 고려 사항 및 가비지 수집 ISPExternalBinaryProvider API를 사용하여 확장하는 방법을 설명합니다. 또한 64비트 호환성 설명할 로드 실패하도록 SharePoint 일으킬 수 있는 Microsoft Visual Studio 문제를 올바른 인터페이스 구현 불구하고 ISPExternalBinaryProvider 구성 관리. 적절한, WSS 3.0 SDK ISPExternalBinaryProvider 설명서에서 참조할 I. 바로 가치가 다른 참조가 Kyle Tillman 블로그.
관리 코드에서 구현을 문제도 Mastered 그는 방법을 설명하는 유용한 작업을 아무 Kyle 않지만 WSS 3.0 SDK OLAP이고 Kyle 사람의 블로그에 Visual Studio 예제 프로젝트 포함되어 있으므로 이 열은 자매 자료 비관리 코드와 관리 코드에서 ISPExternalBinaryProvider 예제를 제공하는 결정했습니다. 이들 이 샘플은 목적은 SharePoint 외부 저장소 솔루션에 통합하는 관심이 있다면 시작하는 데 도움이 되는 것입니다. 점을 기억해야 합니다 하지만 이러한 샘플 테스트되지 수 및 프로덕션 사용할 준비가 없습니다.
내부 이진 저장소
기본적으로 SharePoint 콘텐츠 데이터베이스에 AllDocStreams 테이블의 내용 열에 BLOB 데이터를 저장합니다. 이 방법은 분명한 이점은 관계형 데이터 및 관련된 비 관계형 파일의 내용을 간의 간단한 트랜잭션 일관성을 것입니다. 예를 들어, 사용자의 콘텐츠 데이터베이스에 구조화되지 않은 콘텐츠와 함께 Word 문서의 메타데이터를 삽입하는 데 복잡해집니다지 않습니다 않으며 것이 작업을 삭제하거나 선택, 업데이트, 해당 구조화되지 않은 내용을 메타데이터에 연결할 복잡해집니다. 그러나 기본 방법은 가장 확실한 단점은 저장소 리소스의 비효율적인 사용을 점입니다. 하위 않은 I/O 시스템을 고성능 최적화된 불구하고 SQL Server 저장소 엔진을 사용하는 정확하게 파일 서버입니다.
그림 1 .1에서와 같이 SQL Server 데이터베이스 트랜잭션 로그 파일과 데이터 파일이 구성됩니다. 신뢰할 수 있는 트랜잭션 동작을 확인합니다 위해 SQL Server 먼저 모든 트랜잭션 레코드를 씁니다 로그 파일을 먼저 디스크에 데이터 파일의 8KB 페이지에 해당 데이터를 플러시합니다. 선택한 복구 모델에 따라 필요합니다 BLOB 크기를 두 번 이상 저장 용량이 백업을 수행할 때까지 트랜잭션 로그 제거. 또한 SQL Server 데이터 페이지를 직접 있는 구조화되지 않은 SharePoint 콘텐츠를 저장하지 않습니다. 대신, SQL Server 텍스트/이미지 페이지의 개별 컬렉션을 사용하여 및 전용 데이터 행에 있는 BLOB 루트 노드에 대한 16바이트 텍스트 포인터를 저장합니다. 텍스트 이미지 페이지를 균형 트리에서 구성됩니다 아직 각 테이블에 대해 텍스트/이미지 페이지를 하나만 컬렉션이. AllDocStreams 테이블의 모든 파일 내용을 같은 텍스트/이미지 페이지 컬렉션에 걸쳐 있는 의미합니다. 단일 텍스트/이미지 페이지를 여러 BLOB에서 데이터 조각을 저장할 수 또는 해당 있습니다 보유할 중간 노드 BLOB에 대해 크기가 32KB 초과하는.
1 SQL Server 기본 SharePoint BLOB 저장소 그림
이제 않습니다 본격적으로 너무 깊게 SQL Server 내부 넣습니다 하지만. 때 구조화되지 않은 콘텐츠를 읽고 SQL Server 합니다 텍스트 포인터를 가져올 데이터 행을 통해 이동한 다음 해당 BLOB 루트 노드 및 모든 데이터를 찾으려면 가능한 다른 중간 노드를 통해 조각 분산되어 텍스트/이미지 페이지 수를 SQL Server 합니다 모든 데이터 블록이 가져올 전체 에서 메모리로 로드하는 것입니다. SQL Server 페이지 수준에서 I/O 작업을 수행하는 때문입니다. 이러한 복잡한 파일 시스템을 통해 직접 액세스할 비교하여 파일 스트리밍 성능이 저하될. SQL Server 이미지 데이터 형식 최대 용량을 때문에 SharePoint 있는 2 GB 하드 크기 제한인 적용하는. AllDocStreams 테이블의 내용 열을 이미지 열을 이므로 SharePoint 콘텐츠 데이터베이스에 2GB보다 큰 파일을 저장할 수 없습니다.
외부 이진 저장소
ISPExternalBinaryProvider API를 효율적인 방법은 SharePoint 콘텐츠 데이터베이스에 내부 BLOB 저장소 제공합니다. 외부 이진 저장소 (EBS) 공급자를 구현하려면 사용할 수 있는 두 개의 메서드 (StoreBinary 및 RetrieveBinary) 인 간단한 COM 인터페이스를 경우 아키텍처 세부 정보를 보려면 항목을 " 외부 BLOB 저장소 아키텍처" SDK의 WSS 3.0.
SharePoint 로컬 SPFarm 개체 (SPFarm.Local.ExternalBinaryStoreClassId) ExternalBinaryStoreClassId 속성을 설정할 때 공급자의 COM 클래스 식별자 (CLSID) 로 EBS 공급자에게 로드합니다. SharePoint 때 문서 라이브러리에 파일을 업로드할 수 있다면 같은 BLOB 데이터를 전송할 때마다 공급자의 StoreBinary 메서드를 호출합니다. EBS 공급자가 연결된 외부 저장소 시스템에 있는 BLOB 저장하고 SharePoint에, 해당 BLOB 식별자를 BLOB ID 반환합니다 결정할 수 있습니다 또는 해당 BLOB 처리하지 않았습니다 나타내려면 false StoreBinary 메서드를 pfAccepted 매개 변수 집합 이가 있습니다. 후자의 경우 SharePoint 콘텐츠 데이터베이스에 BLOB을 일반적인 방법으로 저장합니다. 반면, EBS 공급자가 있는 BLOB 적용한 경우 SharePoint 경우에만 삽입합니다 BLOB ID가 AllDocStreams 테이블의 내용 열을 그림 2에 표시된 대로. BLOB ID가 EBS 공급자를 파일, 파일 경로, (GUID (Globally Unique Identifier 또는 콘텐츠 다이제스트 같은 외부 저장소 시스템으로 내용을 찾을 수 있도록 모든 값이 될 수 있습니다. 예를 들어, 자매 자료가 포함된 샘플 공급자를 BLOB 파일 서버에서 신뢰할 수 있는 식별을 위해 파일 같이 GUID를 사용합니다.
그림 2 외부 저장 시스템에서 SharePoint BLOB 저장
SharePoint 또한 추적합니다 외부에 저장된 파일을 1로 이러한 파일 중 가장 높은 DocFlags bit를 설정하여. DocFlags는 AllDocs 테이블의 열입니다. 사용자가 외부에 저장된 파일을 다운로드하려면 요청하면 SharePoint DocFlags 확인하고 EBS 공급자의 RetrieveBinary 메서드를 AllDocStreams 테이블의 내용 값을 전달합니다. RetrieveBinary 호출에 대한 응답으로 EBS 공급자가 합니다 표시된 BLOB 외부 저장소 시스템으로부터 검색하고 ILockBytes 인터페이스를 구현하는 COM 개체의 형식으로 SharePoint 이진 콘텐츠 돌아갑니다. SharePoint 콘텐츠 데이터베이스에 직접 저장된 BLOB에 대한 RetrieveBinary 메서드를 호출하지 않습니다 유의하십시오.
또한 점에 유의하십시오 저장 및 검색 프로세스를 사용자에게 드러나지 한 사용자가 SharePoint 무시할 시도할지 않습니다. 따라서 사용자 지정 버전 문서 목록에 있는 동률 메타데이터 외부에 저장된, Microsoft Office 같은 생산성 응용 프로그램을 한 곳에서 및 다른; 문서의 메타데이터를 저장하는 방법을 알 필요가 없으며 및 검색 메타데이터 문서를 별도로 처리할 필요가 없는 기본 제공 웹 파트를 바꿀 필요가. 또한 내 즐겨찾기 EBS 공급자 아키텍처의 장점 중 하나입니다 있으며 사용자가 SharePoint 외부에 저장된 BLOB 데이터에 액세스하려면 거쳐야 합니다. SQL Server 연결을 통해 콘텐츠 데이터베이스에 직접 액세스하는 SharePoint 무시 사용자가 그림 3 .1에서와 같이 실제 파일 내용을 대신 BLOB ID 다운로드 끝나고. 테스트 환경에서 SQL 다운로드 웹 파트를 (사용되는 I 4월 2009 열에 무시할 SharePoint AD RMS 보호 방법을) 배포하는 경우 이 문제를 확인할 수 있습니다. 또한 사용자가 필요하지 않은, 즉 합니다 가지고 있지 — 액세스 외부 BLOB 저장소로의 권한이. SharePoint 보안 계정을 SharePoint 사이트의 응용 프로그램 풀 계정의 보안 컨텍스트에서 EBS 공급자 메서드를 호출하여 때문에 액세스가 필요합니다.
그림 3 : EBS 공급자를 파일 다운로드에 대해 SharePoint 사용 권한 우회하는 데 roadblock 수 있습니다 .
그러나 염두에, EBS 공급자를 데에는 SharePoint 팜의 콘텐츠 데이터베이스에 있는 메타데이터 및 외부 BLOB 저장소 간에 무결성을 유지하는 복잡성 인해 수도. 장점과 단점을 좋은 설명은 항목을 체크 " 작업 제한 및 Trade-Off 분석" SDK의 WSS 3.0. SharePoint 환경에서 EBS 공급자를 구현하기 전에 이 매우 중요한 항목을 읽을 수 있는지 확인하십시오.
관리되지 않는 EBS 공급자 빌드
이제 EBS 공급자를 구축하는 과제 누락 살펴보겠습니다. ISPExternalBinaryProvider 인터페이스는 아래에 WSS 3.0 SDK에서 well-documented " BLOB Access 인터페이스: ISPExternalBinaryProvider." 그러나, Microsoft EBS 공급자 정보를 다룰 잊은 보입니다. 결국 우리는 않은 바로 사용하는 기존 COM 서버의 인터페이스를. Microsoft는 COM 서버에 직접 작성 및 ISPExternalBinaryProvider 인터페이스를 구현하는 작업하는. 무엇보다 WSS 3.0 SDK를 우리는 빌드 및 스레딩 모델에 필요한 것으로 COM 서버의 형식을 언급하지 실패합니다. 기본 COM 서버는 out-of-process 또는 in-process 실행할 수 있으며 (STA (단일 스레드 아파트 모델, 다중 스레드 아파트 (MTA) 모델을 또는 둘 다 지원할 수 또는 자유 스레드된 모델. 제대로 작동하려면 EBS 공급자에 있는 스레드로부터 안전한 in-process COM 서버 스레딩 모델을 " 모두 " STA 및 MTA 지원하는 빌드할 수 있어야 합니다.
사용할 프로그래밍 언어를 고려해야 합니다. ISPExternalBinaryProvider 인터페이스를 낮은 수준의 API 중 SharePoint 때문에 중요합니다. 성능 문제를 전체 SharePoint 팜을 달라질 수 있습니다. 것이 이런 이유로 좋습니다 작은 빌드 및 COM 개체 (예: Visual C++ 및 ATL (Active Template Library) 빠른 수 있는 언어를 사용하여. ATL 지원 스레딩 올바른 수준의 비관리 코드에서 스레드로부터 안전한 COM 서버의 개발을 단순화할 유용한 C++ 클래스를 제공합니다.
Visual Studio에는 또한 ATL 마법사는 다양한이 포함되어 있습니다. 방금 ATL 프로젝트를 만들려면 을 서버 유형, WSS 3.0 SDK에서 ISPExternalBinaryProvider 인터페이스 정의를 ATL 프로젝트의 인터페이스 정의 언어 (IDL) 파일에, 추가 새 클래스를 ATL 단순 개체 스레딩 모델과 집계 없음 " 모두 선택한 다음 새 클래스를 마우스 오른쪽 단추로, 추가를 가리킨 Implement Interface를 클릭합니다 및 ISPExternalBinaryProvider 선택한 복사 동적 연결 라이브러리 (DLL) 선택하십시오. 이게 이를! 인터페이스 구현 마법사 있도록 StoreBinary 및 RetrieveBinary 메서드를 구현하는 집중할 수 있습니다 모든 필요한 배관을 수행합니다.
다시 않는 관리되지 않는 C++ 코드에 intimidate 합니다. 부록 자료 SampleStore.cpp 파일을 분석할 수 StoreBinary 및 RetrieveBinary 구현은 비교적 간단한 있는지 확인할 수 있습니다. 기본적으로 샘플 StoreBinary 메서드는 StorePath 레지스트리 값, SharePoint에서 전달된 Site ID 및 BLOB, 생성된 GUID를 기반으로 파일 경로를 생성합니다 를 만든 다음 Win32 WriteFile 함수를 사용하여 ILockBytes 인스턴스를 에서 가져온 이진 데이터를 저장합니다. 반면, 샘플 RetrieveBinary 메서드를 같은 StorePath 레지스트리 값, 사이트 ID 및 SharePoint에서 전달된 BLOB ID를 기반으로 파일 경로를 생성합니다 TypeCode인 다음 Win32 ReadFile 함수를 사용하여 EBS 공급자가 다음 SharePoint 돌아가기 전달하는 새 ILockBytes 인스턴스를 복사하는 구조화되지 않은 데이터를 검색합니다. 그림 4에서 는 EBS 공급자가 파일 경로를 구문을 방법을 보여 줍니다.
그림 4 생성하는 샘플 EBS 공급자의 StoreBinary 및 RetrieveBinary 작업에 파일 경로
관리되는 EBS 공급자 빌드
물론, 개발자가 EBS 공급자는 관리되는 빌드하는 경우에도 EBS 공급자를 빌드하려면 익숙한 관리되는 언어를 사용하여 원하는 있습니다 SharePoint 반드시 덜 복잡한 COM 상호 운용성 복잡성 때문에 관리되지 않는 공급자를 만드는 것보다 않습니다. 비관리 코드로 작성된 응용 프로그램을 공용 언어 런타임 (CLR) 한 버전을 경우에만 로드할 수 염두에, 있으므로 해당 코드는 동일한 버전의 SharePoint 나머지 사용하는 CLR 작업할 합니다, 그렇지 않으면 수 끝낼 수 위로 예기치 않은 동작이. 또한, 여전히 처리해야 합니다 관리되지 않는 인터페이스 및 매개 변수 및 버퍼 해당 마샬링. 방금 자매 자료가 의 SampleStore.cs SampleStore.cpp을 비교하십시오. 게인 코드 구조 측면에서 관리되는 언어 또는 간단하게 프로그래밍 가지 있습니다.
또한 알고 있어야 64비트 호환성 문제가 관리되는 EBS 공급자를 x 64 플랫폼에서 개발하는 경우. 그림 5 개발 컴퓨터의 COM 등록 설정이 잘못된 결과를 일반적인 오류를 보여 줍니다. Visual Studio 2005 또는 Visual Studio 2008 프로젝트 속성에서 COM Interop 확인란 등록 활성화하면 살펴보겠습니다 끝낼 수 최대 HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ 아래의 레지스트리에서 공급자에 대한 COM 등록 설정을 사용하여 <providerclsid>. Visual Studio, x 64 플랫폼에서 경우에도 Assembly Registration Tool (Regasm.exe) 32비트 버전의 사용합니다.
그림 5 잘못된 COM 등록 설정을 수 기한 관리되는 EBS 공급자를 로드할 수 없습니다 .
그러나 SharePoint 64비트 버전의 %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 디렉터리에 있는 64비트 Regasm.exe 버전을 사용하여 관리되는 EBS 공급자에 수동으로 등록해야 있도록 Wow6432Node, 아래 등록된 32비트 COM 서버를 로드할 수 없습니다. 예를 들어, 명령 " % WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe ManagedProvider.dll <providerclsid> HKEY_CLASSES_ROOT\CLSID\ 아래에 관리 예제 공급자에 대한 필수 레지스트리 설정을 만듭니다. 다른 방법은 설치 프로그램을 만들고 자동 COM 등록 EBS 공급자의 표시하는 것입니다.
관리되는 EBS 공급자가 관리되지 않는 ATL 근접하게 것보다 훨씬 많은 오버헤드 및 성능 저하를 함께 제공되는 또한 합니다. 볼 수 있습니다 레지스트리에서 COM 등록 설정을 비교할 경우. InProcServer32 키 reveals 같이 COM 런타임은 로드합니다 관리되지 않는 EBS 공급자 DLL을 직접 서버로 in-process CLR 핵심 엔진에 있는 관리되는 EBS 공급자 Mscoree.dll 의존하지 동안. 따라서 관리 공급자에 대한 COM 런타임은 CLR에서 로드합니다 및 다음 CLR 어셈블리 키 아래 등록된 대로 EBS 공급자 어셈블리를 로드하는 관리되지 않는 SharePoint 클라이언트 (Owssvr.dll) 및 관리되는 EBS 공급자 간의 상호 작용을 처리하도록 CCW (COM 호출 가능 래퍼) 프록시를 만듭니다.
점을 염두에 관리되지 않는 SharePoint 서버를 직접 작용하지 않는 관리 공급자와 함께. 매개 변수를 마샬링하는 관리되는 메서드를 호출하여 및 HRESULT를 처리하는 있는 CCW 것이.입니다. 이 간접 참조가 관리되지 않는 메서드에 관리되는 메서드의 다른 반환 형식을 특히 명백한 것입니다. 관리되지 않는 메서드는 관리되는 메서드를 void 반환 형식을 할 것으로 있는 동안 성공 또는 실패를 나타내는 HRESULT를 반환합니다. 따라서 않음 관리 코드를 명시적 HRESULT를 반환하십시오. 시스템 또는 오류 조건에 대한 응답으로 사용자 정의 예외를 발생시킬 수 합니다. 관리되는 메서드를 예외 없이 완료된 경우 CCW는 관리되지 않는 클라이언트에 S_OK 자동으로 반환합니다.
반면, 관리되는 메서드가 예외를 발생시킵니다, 경우 CCW는 매핑합니다 오류 코드와 메시지를 HRESULT 및 오류 정보를. CCW는 이 용도로 ISupportErrorInfo IErrorInfo, 등의 다양한 오류 처리 인터페이스를 구현하지만 SharePoint 장점은 이러한 인터페이스 사용하지 않습니다. EBS 공급자는 Windows 이벤트 로그, SharePoint 진단 로그를, 추적 파일 또는 다른 방법을 통해 보고 자신의 오류를 구현해야 합니다. SharePoint은 HRESULT 값이 S_OK로 성공 및 E_FAIL을 모든 오류에 대한 것으로 예상합니다. Marshal.ThrowExceptionForHR 메서드를 사용하여 SampleStore.cs 설명된 대로 SharePoint에, E_FAIL을 반환할 수 있습니다.
SharePoint EBS 공급자 등록하는
쉽게 WSS 3.0 SDK에서 ISPExternalBinaryProvider에 대한 가장 혼동을 섹션은 항목을 " 설치 및 사용자 BLOB 공급자 구성." 이 문서를 작성하는 시점에는 이 섹션에서는 잘못된 정보 및 오류 채워집니다 않았습니다. Windows PowerShell 명령 올바르지 않았습니다. $ yourProviderConfig EBS 공급자가 할당할 나중에 $ providerConfig.ProviderCLSID 사용하여, 않는 수 surprised $ providerConfig 존재하지 없다는 오류 메시지가 나타나면. 물론, 않습니다 경우에도 나타날 이 경우 Active 및 ProviderCLSID 속성을 ISPExternalBinaryProvider 인터페이스에 없는 때문에. 이러한 신비한 속성을 설명서에 포함되지 이중 인터페이스를 속합니다. 방금 재미있는, 샘플 버전 비관리 코드와 관리 코드로 구현된 I 있지만 ISPExternalBinaryProvider 구현을 이러한 독점적인 속성을 전혀 필요하지 않습니다.
ProviderCLSID 속성은 유용한 수 있습니다 있지만 CLSID를 또한 사용할 레지스트리에서 UnmanagedProvider.SampleStore ManagedProvider.SampleStore, 등의 ProgID를 검색할 수 있고 SampleStore.rgs 및 SampleStore.cs 코드 파일에서 CLSID가 찾을 수도 있습니다. 앞에서 설명한 것처럼 CLSID를 로컬 SPFarm 개체의 ExternalBinaryStoreClassId 속성을 설정하는 EBS 공급자를 등록합니다. 빈 GUID (" 00000000-0000-0000-0000-000000000000 " (로컬 SPFarm 개체의 ExternalBinaryStoreClassId 속성을 설정하는 EBS 공급자 등록을 제거합니다. 구성 데이터베이스에 변경 내용을 저장하고 인터넷 정보 서비스 (IIS) 를 다시 시작해야 SPFarm 개체의 Update 메서드를 호출하여 잊지 마십시오. 다음 코드 목록을 Windows PowerShell의 이러한 작업을 수행하는 방법을 보여 줍니다.
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SharePoint')
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local
# Registering the CLSID of an EBS provider
$farm.ExternalBinaryStoreClassId = "C4A543C2-B7DB-419F-8C79-68B8842EC005"
$farm.Update()
IISRESET
# Removing the EBS provider registration
$farm.ExternalBinaryStoreClassId = "00000000-0000-0000-0000-000000000000"
$farm.Update()
IISRESET
가비지 컬렉션 구현
WSS 3.0 SDK featuring 신비한 구성 및 중요한 코드 조각을 다른 구역으로 제목은 " Lazy Garbage Collection 구현." 이 문서를 작성하는 시점에는 이 섹션에서는 FileInfo 배열에 Directory.GetFiles 결과가 잘못된 할당을 DirFromSiteId 및 FileFromBlobid 메서드를 함께 신비한 다른 유틸리티 클래스에 대한 참조가 포함되어 있지만 보겠습니다 않는 수 너무 요구 WSS 3.0 문서 품질에 대한. DirFromSiteId 및 FileFromBlobid 도우미 메서드를 표시 이름을 통해 그 용도를 쉽게 잘못된 FileInfo 배열 문자열 배열로 대체됩니다 또는 DirectoryInfo 개체의 GetFiles 메서드 호출하여 Directory.GetFiles 메서드를 대체할 수 있습니다. 부록 자료 가비지 수집기 샘플 프로그램을 DirectoryInfo 방식을 사용하고 제안된 순서를 가비지 수집 단계 따릅니다.
SDK 설명을 통해 가비지 수집기 표본의 중요한 편차를 타이밍 조건 처리하는 관련된. 시간 조건 수 misidentification 및 가비지 수집 중에 올바른 파일 삭제 있기 때문에 중요한 문제입니다. 그림 6 , EBS 저장소의 모든 BLOB 파일이 열거 및 사이트의 ExternalBinaryIds 컬렉션을 통해 표시된 대로 콘텐츠 데이터베이스에 여전히 있는 BLOB 목록에서 모든 참조를 제거하여 연결되지 않은 파일을 확인하려면 WSS 3 SDK–recommended 방법을 보여 줍니다 살펴보겠습니다. BLOB 목록의 나머지 참조를 삭제해야 합니다 고아 파일을 나타내려면 것으로 있습니다.
그림 6 타이밍 조건을 위해 인해 분리된 같이 유효한 BLOB Misidentification
그러나 EBS 공급자, 물론, 먼저 완료해야 합니다 BLOB 데이터를 쓰기 전에 SharePoint에 BLOB ID 반환할 수 있습니다. 네트워크 대역폭 및 기타 조건을 따라 I/O 성능을 fluctuate 수 있습니다. 따라서 EBS 공급자가 새 BLOB 만들 수 있는 가능성이 있기 (BLOB 목록에 있는 다음 나타납니다 (BLOB ID가 아직 이 컬렉션에 있는 것은 없습니다 경우 ExternalBinaryIds 확인한 후에 BLOB 데이터를 쓰는 완료된 있지만. 그에 따라 해당 참조를 새 BLOB 분리된 BLOB 목록에 남아 및 분리된 BLOB 이때 제거할 경우 실수로 유효한 콘텐츠 항목을 삭제할 데이터가 손실될! 이 문제를 방지하려면 가비지 수집기 샘플을 파일 작성 시간 확인하는 둘 이상의 시간 이전 있는 BLOB 목록에 해당 항목을 추가합니다.
결론
SharePoint 외부 저장소 솔루션을 통합하는 저장 효율성, 시스템 성능과 SharePoint 팜 확장성을 향상시킬 수 있습니다. 이렇게 하면 구조화되지 않은 내용에 액세스하려면 SharePoint 통해 사용자에게 다른 장점은 것입니다. 직접 SQL Server 연결을 통해 콘텐트 데이터베이스의 데이터 가져오기 실제 파일 대신 이진 BLOB 식별자를 경우에만 생성됩니다. 그러나 EBS 공급자를 데에는 SharePoint 팜의 콘텐츠 데이터베이스에 있는 메타데이터 및 외부 BLOB 저장소 간에 무결성을 유지하는 복잡성 인해 또한 사용할.
SharePoint 외부 저장소 솔루션을 통합하는 StoreBinary 및 RetrieveBinary 메서드를 사용하여 ISPExternalBinaryProvider 인터페이스를 구현하는 COM 서버입니다 EBS 공급자를 빌드해야 합니다. 관리되지 않는 만들 수 EBS 공급자, 관리되는 있지만 관리되는 코드를 사용할 경우 성능 및 호환성 문제를 알고 있어야. 또한 염두에 ISPExternalBinaryProvider 인터페이스를 DeleteBinary 메서드가 포함되지 않습니다. 명시적으로 지연 가비지 수집을 통해 분리된 BLOB 제거할 하며 유효한 BLOB 항목 실수로 삭제하는 발생할 수 있습니다 타이밍 조건을 않도록 주의해야 합니다.
Pav Cherny 않으며 있는 IT 전문가가 만든 공동 작업 및 통합 통신 Microsoft 기술을 전문으로. 자신의 발행물에 백서, 제품 설명서 및 IT 작업 및 시스템 관리 사용하여 포커스가 있는 책이 포함됩니다. Pav가 직위가 중 Biblioso Corporation인, 관리되는 설명서 및 지역화 서비스 전문으로 하는 회사.