문서를 어디에 저장할 것인지 고려 사항 - 파일 서버 또는 DB?

StackOverflow https://stackoverflow.com/questions/2201557

  •  18-09-2019
  •  | 
  •  

문제

내 웹사이트에 업로드된 문서와 관련하여 디자인 결정을 내려야 합니다.파일 서버 어딘가에 저장하거나 데이터베이스(MSSQL 2005)에 blob으로 저장할 수 있습니다.설계 결정에 차이가 있는 경우 이러한 문서는 기밀이므로 어느 정도 보호되어야 합니다.

제가 생각한 고려사항은 다음과 같습니다.

  1. 파일 서버에 저장하면 HUUUUUUUGE개의 파일이 모두 단일 디렉터리에 덤프되므로 디렉터리 트리 구조에 대한 합리적인 의미론적 정의를 해결할 수 없는 한 액세스 속도가 느려집니다.
  2. OTOH, 파일 서버가 DB보다 압축을 어느 정도 더 잘 처리할 수 있을 것 같아요...아니면 내가 틀렸어?
  3. 내 직감으로는 DB의 보안이 파일 서버의 보안보다 강력하다고 말하지만, 그것이 반드시 사실인지는 확실하지 않습니다.
  4. 내 DB에 테라바이트 단위의 blob이 있으면 성능에 어떤 영향을 미칠지 모르겠습니다.

여기에 몇 가지 권장 사항을 알려주시면 감사하겠습니다.감사해요!

도움이 되었습니까?

해결책

SQL Server 2005에서는 다음 중 하나만 선택할 수 있습니다. VARBINARY(MAX) 파일을 데이터베이스 테이블 내부에 저장하거나 외부에 보관합니다.

데이터베이스 외부에 두는 것의 명백한 단점은 데이터베이스가 그들에게 일어나는 일을 실제로 제어할 수 없다는 것입니다.이동하고, 이름을 바꾸고, 삭제할 수 있습니다.....

SQL 서버 2008 소개합니다 FILESTERAM 속성 VARBINARY(MAX) 유형을 사용하면 파일을 데이터베이스 테이블 외부에 둘 수 있지만 여전히 데이터베이스의 트랜잭션 제어하에 있습니다.디스크에서 파일을 삭제할 수는 없습니다. 파일은 데이터베이스의 필수 부분이므로 복사되고 백업됩니다.필요한 경우에는 좋지만 대규모 백업이 필요할 수 있습니다!:-)

SQL Server 2008 출시에서는 데이터베이스에 직접 항목을 저장하는 경우와 FILESTREAM을 사용하는 경우에 대한 몇 가지 "모범 사례"가 제시되었습니다.이것들은:

  • 파일 크기가 일반적으로 256KB 미만인 경우 데이터베이스 테이블이 가장 좋은 옵션입니다.
  • 파일 크기가 일반적으로 1MB를 초과하거나 2GB를 초과할 수 있는 경우 FILESTREAM(또는 귀하의 경우:일반 오래된 파일 시스템)이 최선의 선택입니다
  • 두 여백 사이에 있는 파일은 권장되지 않습니다.

또한 쿼리 성능에 부정적인 영향을 주지 않으려면 대용량 파일을 별도의 테이블에 모두 넣는 것이 좋습니다. 쿼리하는 일반 테이블의 일부로 큰 덩어리를 두지 말고 대신 메가바이트의 문서나 이미지가 정말로 필요한 경우에만 쿼리하는 별도의 테이블입니다.

그러면 어디서부터 시작해야 할지에 대한 아이디어를 얻을 수 있습니다!

다른 팁

파일 시스템 솔루션을 고려해 보시기 바랍니다.이유는 다음과 같습니다.

  • 파일에 대한 더 나은 액세스 권한을 갖게 됩니다(디버깅하는 경우 중요함). 이는 일반 콘솔 기반 도구를 사용할 수 있음을 의미합니다.
  • 빠르고 쉽게 OS를 활용하여 로드를 분산할 수 있습니다(예: 분산 파일 시스템 사용, 하드웨어 RAID를 통한 중복성 추가 등).
  • OS 액세스 제어 목록을 활용하여 권한을 적용할 수 있습니다.
  • 당신은 데이터베이스를 막히지 않습니다

디렉터리에 항목이 너무 많아 걱정된다면 언제든지 분기 스키마를 생성할 수 있습니다.예를 들어:

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt

이 인기 있는 주제 뒤에는 많은 "의존적 상황"이 있습니다.문서가 민감하고 기밀이라고 말씀하셨으니 즉시 데이터베이스에 저장하겠습니다.다음은 몇 가지 이유입니다.

  • 잠재적으로 보안이 향상됩니다.데이터베이스보다 파일 시스템을 해킹하는 것이 더 쉬운 경우가 많습니다.
  • 더 나은 볼륨 제어.한 폴더에 있는 수천 개의 파일은 데이터베이스가 깜박이지 않고 한 테이블에서 수백만 개의 행을 차지할 수 있는 OS에 부담을 줄 수 있습니다.
  • 더 나은 검색 및 스캔.데이터를 로드할 때 분류 열을 추가하거나 전체 텍스트 인덱싱을 시도하여 실제 문서를 스캔하세요.
  • 백업이 더 효율적일 수 있습니다. 백업 계획에 다른 데이터베이스를 추가하기만 하면 됩니다(물론 공간 세부 사항을 파악한 후에).그리고 이러한 백업 파일은 민감한 문서를 얻으려는 모든 사람을 난독화하는 또 다른 계층입니다.
  • SQL Server 2008에는 여기에 도움이 될 수 있는 데이터 압축 옵션이 있습니다.아니면 애플리케이션이 그렇게 하도록 합니까?(아마도 난독화를 통해 보안이 강화될 것입니다)

SQL Server 2008에는 여기에 도움이 될 수 있는 파일 스트림 데이터 유형도 있지만 귀하의 상황에 권장할 만큼 익숙하지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top