너무 많은 파일 (BLOB)이있는 SQL Server DB를 처리하는 전략은 무엇입니까?


11

시나리오 :
별도의 웹 서버에서 ASP.NET 응용 프로그램을 서비스하는 SQL Server 2005 데이터베이스

데이터베이스 :
DB에는 약 5GB의 "일반"데이터와 약 15GB의 "파일"이 있습니다 (예 : 이미지로 저장된 200k PDF (BLOB)). 사용자가 더 많은 파일을 업로드하고 있으며 더 많은 디스크 공간을 빠르게 소비하고 있습니다 (DB는 향후 몇 개월 안에 대부분 50GB까지 증가 할 수 있음).

우려 사항 :
DB에 너무 많은 파일을 저장하면 이미 문제발생합니다 (예 : 데이터베이스의 전체 크기가 크면 가끔 전체 DB 백업 및 배포가 어려워집니다).

그리고 우리는 더 많은 문제가 있을까 걱정하고 있습니다 . (예 : 성능 문제-전체 DB를 RAM에 보관할 수 없어서 발생했을 수 있습니다.)

질문 :
이 문제에 어떤 기술 솔루션을 제안 하시겠습니까? 파일 시스템에 파일을 저장 하시겠습니까? 데이터베이스를 두 개로 나누고 파일에 대해 더 크고 느린 데이터베이스를 가지고 있습니까?

필요한 경우 추가 정보 :
이 파일은 매우 중요하지 않으며 매우 빠른 액세스 시간이 필요하지 않습니다. 몇 초가 걸리며 현재 최대 시간당 수십 개의 선택이있을 수 있습니다. DB의 다른 "정상"데이터에는 초당 여러 번 필요한 정보가 포함됩니다.


솔루션의 일부로 2008+로 업그레이드 할 수 있습니까?
Jon Seigel

@Jon Seigel 예, 2008 년 (또는 2012 년)에는 어떤 옵션을 사용할 수 있습니까?
MGOwen

답변:


6

현재 3TB이고 하루 5GB가 증가하는 매우 유사한 데이터베이스를 돌 봅니다.

  • Filestream (2008+)은 백업 / 복원 문제를 해결하지 못합니다.
  • 파일 스트림은> 1MB 이상의 파일에 대해 LOB 스토리지보다 성능이 우수 하므로 Paul Randal의 테스트는 말합니다 . 워크로드는 256KB-1MB에 의존하며 일반적으로 <256KB에서는 더 나쁩니다.
  • 일부 환경에서 Filestream의 큰 장점은 버퍼 풀을 무시하고 대신 Windows 시스템 캐시를 사용한다는 것입니다.
  • 파일을 파일 시스템에두면 데이터베이스 레코드와의 트랜잭션 일관성이 유실됩니다. 또한 수백만 개의 개별 파일을 백업하는 오버 헤드가 추가되어 번거로울 수 있습니다.

Filestream에 대한 찬반 양론의 무게를 측정하고 귀하의 사례에 적합한 지 확인하십시오. 우리의 경우에는 다른 경로를 사용하여 데이터베이스를 분할하기로 결정하여 부분 가용성 / 조각 복원 을 사용할 수 있습니다 .

우리가 사용할 수 없었던 한 가지 옵션은 이전 / 아카이브 파일 그룹을 읽기 전용으로 표시하는 것입니다. 그런 다음 읽기 전용 파일 그룹을 자주 백업 할 수 있습니다.

2005 표준 (파티션은 Enterprise 버전 기능)을 고수하고 기록에 대해 읽기 전용 옵션이있는 경우이 방식을 구식 방식으로 해결할 수 있습니다.

  • 테이블을 나누십시오. 예를 들어 월별 테이블을 기준으로 활성 / 역사 경로 또는 날짜를 고려할 수 있습니다.
  • 히스토리 데이터를 읽기 전용 파일 그룹에 넣고 추가 데이터를 아카이브 할 때만 백업하십시오. 이로 인해 백업 시간이 단축된다는 사실을 사용자에게 이해 시키십시오. 부분 가용성 기능이 없으면 복원에 시간이 걸릴 수 있습니다.
  • 테이블 위에 분할 된 뷰 를 만듭니다 .

3TB 블로 버를 고려중인 마지막 옵션 중 하나는 파일 데이터를 문서 데이터베이스 또는 클라우드 스토리지 (예 : AmazonS3 , Azure BLOB Storage )로 이동하는 것입니다. 이것은 앞에서 언급 한 트랜잭션 일관성 문제를 야기하지만 매우 비싼 SQL Server에서로드를 제거합니다.


당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.