문서/이미지 데이터베이스 저장소 디자인 질문

Question

질문 :

내가 직접 데이터베이스 이미지 저장소에 액세스하거나 문서 요청을 처리하는 미들웨어 조각을 작성하는 내 응용 프로그램을 작성해야한다.

배경 :

나는 사용자 정의 문서 이미징 및 워크 플로 응용 프로그램을 현재 약 1,500 만 문서/문서 이미지 저장 (90 % + 단일 페이지, 그룹 4 tiffs를, 나머지 PDF, Word 및 Excel 문서)를 가지고있다. 이미지 저장소는 매우 비싸고 솔직히 너무 많은 오버 헤드를 가진 상업용 타사 응용 프로그램입니다. 문서 이미지를 저장하고 검색하는 시스템이 필요합니다.

이미징을 SQL Server 2005 데이터베이스로 직접 이동하는 것이 좋습니다. 색인 정보는 매우 제한적입니다. 기본적으로 2 개의 색인 필드가 있습니다. 생명 보험 증서 관리 시스템이므로 보험 증권 번호와 시스템 고유의 고유 ID 번호로 이미지를 색인합니다. 다른 인덱스 값이 있지만 이미지 데이터와 별도로 저장 및 관리됩니다. 이러한 인덱스 값을 통해 개별 이미지 검색을위한 고유 한 id 값을 조회 할 수 있습니다.

데이터베이스 서버는 DB 파일을 호스팅하는 SAN 드라이브가있는 듀얼 쿼드 코어 Windows 2003 상자입니다. 현재 이미지 저장소 크기는 약 650GB입니다. 변환 된 데이터베이스의 크기를 확인하기 위해 테스트를 수행하지 않았습니다. 데이터베이스 디자인에 대해 정말로 묻고있는 것은 아닙니다. 저는 DBA와 협력하고 있습니다. 그게 바뀌면 나는 다시 돌아올거야 :-)

대체 할 현재 시스템은 분명히 미들웨어 응용 프로그램이지만 3 대의 Windows 서버에 분산되어있는 매우 중량 시스템입니다. 이 경로를 선택하면 단일 서버 시스템이됩니다.

내 관심사는 성능에 크게 비중을 둔 스케일과 성능입니다. 저는 약 100 명의 사용자를 보유하고 있으며 향후 몇 년 동안 사용량 증가는 느려질 것입니다. 대부분의 사용자는 주로 읽기 사용자입니다. 이미지를 시스템에 자주 추가하지는 않습니다. 우리는 스캔을 처리하거나 저장소에 이미지를 추가하는 부서를 가지고 있습니다. 우리는 또한 ftp를 통해 문서를 수신하는 몇 가지 다른 응용 프로그램을 가지고 있으며, 전체 색인 정보 나 사용자가 검토하고 색인하는 "배치"로 저장소에 자동으로 넣습니다.

대부분의 (90 % +) 문서/이미지가 매우 작습니다. < 100K, 아마도 < 50K입니다. 따라서 데이터베이스 파일에 이미지를 저장하는 것이 SQL 2008을 사용하고 파일 스트림.

Answer 1

6 개월 후의 관리가 돌아오고 "응용 프로그램 X의 기능 Y가 허용 할 수 없을 정도로 느리게 실행되고 있으며 속도를 어떻게 높이나요?"라는 의미에서 확장 성 및 성능이 궁극적으로 서로 결혼하게됩니다. 그리고 종종 백 엔드 솔루션을 업그레이드하는 것이 해결책입니다. 백엔드 업그레이드에 관해서는 하드웨어 측면에서 확장하는 것보다 스케일 아웃하는 것이 거의 항상 저렴합니다.

간단히 말해서 사용자 앱의 수신 요청을 특별히 처리 한 다음 적절한 대상으로 라우팅하는 미들웨어 앱을 만드는 것이 좋습니다. 이렇게하면 백엔드 스토리지 솔루션에서 프론트 엔드 사용자 응용 프로그램을 충분히 추상화 할 수 있으므로 확장 성이 문제가 될 때 미들웨어 응용 프로그램 만 업데이트해야합니다.

Answer 2

이것은 간단합니다. 애플리케이션을 인터페이스에 작성하고, 어떤 종류의 팩토리 메커니즘을 사용하여 해당 인터페이스를 제공하고, 원하는 인터페이스를 구현하십시오.

인터페이스에 만족하면 응용 프로그램이 곧바로 DB 또는 다른 구성 요소와 관련되어 구현과 분리됩니다.

인터페이스 디자인에 약간의 생각이 있지만 "간단합니다, 작동합니다, 지금 작동합니다"구현은 미래의 시스템 교정의 균형을 유지하면서 반드시 엔지니어링을 넘어서는 것은 아닙니다.

당신이이 시점에서 인터페이스를 필요로하지 않는다고 주장하는 것은 쉽습니다. 인스턴스화하는 단순한 클래스가 아닙니다. 그러나 계약 (예 : 인터페이스 또는 클래스 서명)이 잘 정의 된 경우 변경에서 사용자를 보호합니다 (예 : 백 엔드 구현 다시 실행). 필요할 때 인터페이스를 나중에 클래스로 바꿀 수 있습니다.

확장성에 관한 한 테스트하십시오. 그렇다면 규모를 조정할 필요가있을뿐만 아니라 때로는 알 수 있습니다. "100 명의 사용자에게 훌륭하게 작동하며 200에 문제가 있습니다. 150에 도달하면 백엔드를 다시 살펴 보려고 할 수도 있지만 지금은 좋습니다."

그건 실사와 책임감있는 디자인 전략 인 IMHO입니다.

Answer 3

나는 gabriel1836에 동의합니다. 그러나 한시적으로 하이브리드 시스템을 운영 할 수 있다는 장점이 있습니다. 독점 시스템에서 가정용 시스템으로 1400 만 개의 문서를 하룻밤 사이에 변환하지 않기 때문입니다.

또한 데이터베이스 외부에 문서를 저장하는 것이 좋습니다. 파일 시스템 (로컬, SAN, NAS는 중요하지 않음)에 저장하고 데이터베이스에있는 문서에 대한 포인터를 저장하십시오.

지금 어떤 문서 관리 시스템을 사용하고 있는지 알고 싶습니다.

또한 독점 시스템에서 제공하는 캡처 (검색 및 가져 오기)를 대체하려는 노력을 과소 평가하지 마십시오.