문서/이미지 데이터베이스 저장소 설계 질문

Question

의문:

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

배경:

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

이미징을 SQL Server 2005 데이터베이스로 직접 이동하는 것을 고려하고 있습니다. 인덱싱 정보는 매우 제한적입니다 - 기본적으로 2 개의 인덱스 필드. 생명 보험 정책 관리 시스템이므로 정책 번호와 시스템 넓은 고유 ID 번호로 이미지를 색인합니다. 다른 인덱스 값이 있지만 이미지 데이터와 별도로 저장되고 유지됩니다. 이러한 색인 값은 개별 이미지 검색에 대한 고유 한 ID 값을 조회하는 기능을 제공합니다.

데이터베이스 서버는 DB 파일을 호스팅하는 SAN 드라이브가있는 듀얼 쿼드 Core Windows 2003 상자입니다. 현재 이미지 저장소 크기는 약 650GB입니다. 변환 된 데이터베이스가 얼마나 큰지 확인하기 위해 어떠한 테스트도하지 않았습니다. 나는 실제로 데이터베이스 디자인에 대해 묻지 않습니다. 저는 그 측면에서 우리의 DBA와 함께 일하고 있습니다. 그것이 바뀌면 다시 올 것이다 :-)

교체 할 현재 시스템은 분명히 미들웨어 응용 프로그램이지만 3 개의 Windows 서버에 걸쳐 매우 헤비급 시스템입니다. 이 경로를 가면 단일 서버 시스템이 될 것입니다.

저의 주요 관심사는 Scalabity와 Performace입니다. 나는 약 100 명의 사용자가 있으며, 앞으로 몇 년 동안 사용량 성장이 느려질 것입니다. 대부분의 사용자는 주로 사용자를 읽습니다. 시스템에 이미지를 자주 추가하지 않습니다. 저장소에 이미지를 스캔하고 추가하는 부서가 있습니다. 또한 문서를 수신하는 몇 가지 다른 응용 프로그램 (FTP를 통해)이 있으며, 수신 된대로 수신 된대로 자동으로 저장소에 삽입되거나 사용자가 검토 및 색인을 검토하고 "배치"로 삽입합니다.

문서/이미지의 대부분 (90%+)은 매우 작고 <100k, 아마도 <50k이므로 데이터베이스 파일에 이미지를 저장하는 것이 SQL 2008을 얻고 파일 스트림을 사용하는 것보다 가장 효율적이라고 생각합니다.

Answer 1

종종 확장 성과 성능은 궁극적으로 경영진이 돌아와서 "응용 프로그램 X의 기능 y가 허용되지 않게 실행되고 있습니다. 어떻게 속도를 높이는가?" 그리고 종종 답은 백엔드 솔루션을 업그레이드하는 것입니다. 그리고 백엔드를 업그레이드 할 때, 하드웨어 측면에서 확장하는 것보다 거의 항상 스케일을 저렴하게 비싸게됩니다.

따라서 Long Story에게 간단히 말해서, 사용자 앱에서 들어오는 요청을 특별히 처리 한 다음 해당 대상으로 라우팅하는 미들웨어 앱을 구축하는 것이 좋습니다. 이렇게하면 백엔드 스토리지 솔루션에서 프론트 엔드 사용자 앱이 충분히 추출되어 확장 성이 문제가되면 미들웨어 앱 만 업데이트해야합니다.

Answer 2

이것은 간단합니다. 응용 프로그램을 인터페이스에 쓰고, 어떤 종류의 공장 메커니즘을 사용하여 해당 인터페이스를 공급하고 원하는 인터페이스를 구현하십시오.

인터페이스에 만족하면 응용 프로그램은 DB 또는 다른 구성 요소와 직접 대화하든 (대부분) 구현에서 격리되어 있습니다.

인터페이스 디자인에 대해 약간의 생각을하지만 Bone Stupid를 수행합니다. "간단하고 여기서 작동합니다."구현은 시스템을 반드시 공학적으로는 시스템을 교정하는 데 좋은 균형을 제공합니다.

이 시점에서 인터페이스가 필요하지 않다고 주장하는 것은 쉽습니다. 그러나 계약이 잘 정의되어 있다면 (즉, 인터페이스 또는 클래스 서명)는 변경으로부터 보호하는 것입니다 (예 : 백엔드 구현을 다시 구현 함). 필요한 경우 나중에 클래스를 인터페이스로 항상 교체 할 수 있습니다.

확장성에 따라 테스트하십시오. 그렇다면 당신은 당신이 확장해야 할 수도있을뿐만 아니라 아마도 언제라도 알고 있습니다. "200 명에게는 100 명의 사용자에게 훌륭하게 작동합니다. 150을 기록하면 백엔드를 다시 한 번 살펴 보는 것을 고려하고 싶지만 지금은 좋습니다."

그것은 실사와 책임있는 디자인 전술입니다.

Answer 3

나는 Gabriel1836에 동의합니다. 그러나 추가 된 이점은 한동안 하이브리드 시스템을 한동안 실행할 수 있다는 것입니다. 1,400 만 개의 문서를 독점 시스템에서 밤새 홈 성장 시스템으로 변환하지 않기 때문입니다.

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

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

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