SQL 서버 및 파일 시스템 및 S3 등에서 이미지 제공

내 응용 프로그램 (클래식 asp yay!)은 25GB에서 약 2.1 백만 개의 이미지를 가지고 있으며 90 일의 데이터 만 나타내므로 최소 365로 가고 싶습니다. 나는 이것을 통제하고 모든 옵션을 고려하고 있습니다. 다음 관행의 장단점에 대해 어떻게 생각하십니까?

• SQL Server 전문가 : 간편한 백업 단점 : 성능?
• 파일 시스템 전문가 : 속도 단점 : 중복성, 백업 속도가 느립니다 (현재는 전체 백업을 수행하여 더 나은 결과를 얻을 수 있음)
• S3 등 전문가 : 대역폭이 데이터 센터에서 거의 무제한 스토리지 인 Amazon으로 이동했습니다. Negatives : 비용, 비용 분석이 까다 롭습니다 (내 대역폭의 80 %가 ROI 목적을위한 이미지라고 추정).

다른 사람이 수백만의 이미지 문제를 처리하고 있으며 어떻게 해결 했습니까?

우리는 수백만 개의 이미지가 없지만 수십만 개의 이미지를 가지고 있으며 메타 데이터를위한 mysql, 백업을 위해 로컬 디스크에 저장된 이미지, 그리고 사용자에게 제공되는 Amazon s3으로 푸시 된 하이브리드 접근 방식을 사용합니다. 우리는 아마존과 가용성에 아무런 문제가 없었습니다. 클라우드 프론트로 전환하는 것은 우리 계획에 있으며 시간을 찾기 만하면됩니다.

이 토론은 귀하의 결정에 도움이 될 수 있습니다 :
http://ask.metafilter.com/59635/Millions-of-images

SQL 서버의 메타 데이터와 파일 시스템의 파일 (또는 s3 또는 cloudfront)을 사용합니다. 그러나 가장 좋은 대답은 몇 가지 다른 사용 패턴에 따라 다릅니다.

• 이미지가 자주 바뀌나요?
• 파일 시스템에서 직접 이미지를 제공 할 수 있습니까 (즉, img src="...") 액세스 제어가 필요한지 여부 후자의 경우 데이터베이스 솔루션이 가장 좋습니다.
• 대부분의 시간 동안 (최근 10 %) 적은 수의 이미지를 제공하고 있거나 분포가 비교적 널리 퍼져 있습니까?

수백만 개의 이미지 백업은 정렬 방식에 관계없이 복잡 할 것입니다. 이는 많은 데이터 일뿐입니다. 해당 솔루션을 커밋하기 전에 SQL Server에서 Blob 백업에 대한 좋은 사례 연구를 찾고 싶습니다. (유용한 기사는 다음과 같습니다. http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

파일 시스템에 파일을 저장하기로 결정했다면 다음과 같은 몇 가지 및하지 않은 사항에 대해이 ServerFault 질문을 읽으십시오 . 파일 시스템에 백만 개의 이미지 저장 .

" 데이터 / 이진 데이터를 데이터베이스에 저장하지 마십시오 "라고 말한 사람들 은 오래된 정보를 바탕으로 답하므로 (BarBinary 유형 열에 데이터를 저장한다고 가정) 무시하십시오 . SQL Server 2008에서 FILESTREAM 데이터 형식 을 사용하면 SQL Server를 사용하여 이미지를 저장하는 성능 문제를 완화 할 수 있습니다 . 본질적으로 FILESTREAM 데이터 형식을 사용하면 데이터베이스에 데이터를 쉽게 저장할 수 있으며 제공하는 성능과 결합 할 수 있습니다 NTFS 파일 저장소의 파일

SQL Mag 를 인용하려면 :

"SQL Server 2008의 새로운 FILESTREAM 지원은 NTFS 파일 시스템에서 직접 LOB에 액세스하는 이점과 SQL Server 관계형 데이터베이스 엔진이 제공하는 참조 무결성 및 간편한 액세스 기능을 결합한 것입니다."

자세한 내용 은 MSDN의 Ravi S.Maniam이 블로그 를 참조하십시오 .

수백만 개의 이미지 챌린지를 다루지 않지만 Amazon CloudFront를 사용합니다. 모든 파일은 S3 버킷에 저장되지만 Amazon의 컨텐츠 전송 시스템을 통한 서버입니다. S3 만 사용하지는 않습니다.

두 번째 선택은 파일 시스템입니다. 간단하고 쉬운 문제는 이러한 모든 파일이 하나의 디렉토리에 있으면 모든 것이 충돌한다는 것입니다.

나에게 SQL은 이와 같은 시스템에 대한 옵션이 아닙니다. 대역폭 전송에 대한 요금이 부과 될뿐만 아니라 쿼리 처리에 대한 요금도 청구됩니다. 호스팅에 따라 달라 지지만 전용 서버를 사용하거나 적어도 요금이 청구되는 VPN을 사용한다고 가정합니다 사이클. 그런 다음 이미지 서버와 동일한 데이터베이스를 사용하면 전체 사이트 속도가 느려집니다. 그렇지 않으면 두 개의 데이터베이스 연결을 관리해야하는이 모든 복잡성을 추가 할 수 있습니다.

데이터베이스는 트랜잭션 데이터 / 일관성 및 보안을 위해 설계되었습니다.

미디어 파일 (이미지, 오디오, 비디오)은 생성 및 삭제되는 경향이 있지만 거의 업데이트되지 않습니다. 따라서 일반적으로 다른 데이터와 트랜잭션 일관성을 유지할 필요가 없으며 데이터베이스는 실제 이점을 제공하지 않습니다. 텍스트 내용이 다를 수 있습니다.

파일의 URL이 있으면 누군가 파일을 직접 가져 오는 개념에 아무런 문제가 없다면 파일 시스템이 좋습니다. 사람들이 파일을 다운로드하기 전에 요금을 청구해야하는 사진 라이브러리와 같은 것을 실행하는 경우 다른 문제 일 수 있습니다. 즉, 사용자가 지불 한 후에는 해당 사용자에게 고유 한 URL을 얻거나 짧은 시간 동안 만 유효 할 수 있으며 응용 프로그램은 동일한 이미지를 가리키는 여러 개의 또는 임시 URL을 처리합니다. 그것은 여전히 ​​앱과 파일 시스템에 의해 처리 될 수는 있지만 직접 파일 다운로드 (대부분 S3의 이점을 배제 할 것)가 아니라 응용 프로그램을 통해 미디어를 제공하게되며 DB와 파일 시스템의 차이는 적습니다. .