업로드 된 이미지, SQL 데이터베이스 또는 디스크 파일 시스템을 저장하는 가장 좋은 장소는 무엇입니까?

사용자가 서버에 이미지를 업로드 할 수있는 응용 프로그램을 작성 중입니다. 나는 모든 JPEG를 하루에 약 20 개의 이미지를 기대하며 아마도 편집 / 크기 조정하지 않을 것입니다. (이것은 또 다른 질문입니다. 저장하기 전에 서버 측에서 이미지 크기를 조정하는 방법입니다. 누군가 주석에 .NET 리소스를 넣을 수 있습니다.) 업로드 된 이미지를 저장하기에 가장 좋은 장소가 무엇인지 궁금합니다.

• 이미지를 파일 시스템에 파일로 저장하고 해당 이미지의 정확한 경로가있는 테이블에 레코드를 작성하십시오.

• 또는 데이터베이스 서버의 "image"또는 "binary data"데이터 유형을 사용하여 이미지 자체를 테이블에 저장하십시오.

나는 둘 다 장단점을 봅니다. a) 파일을 쉽게 재배치 할 수 있고 테이블 항목을 변경해야하기 때문에 a)가 좋습니다. 반면에 나는 비즈니스 데이터를 웹 서버에 저장하는 것을 좋아하지 않으며 웹 서버를 비즈니스 데이터를 보유하고있는 다른 데이터 소스에 연결하고 싶지 않습니다 (보안상의 이유로) b) 모든 정보는 한 곳에서 쉽게 쿼리에 액세스 할 수 있습니다. 반면에 데이터베이스는 매우 빨리 커질 것입니다. 데이터 아웃소싱이 더 어려울 수 있습니다.

나는 예외가 있지만 일반적으로 파일 시스템에 파일을 저장합니다. 파일의 경우 파일 시스템이 가장 유연하고 성능이 뛰어난 솔루션입니다 (보통).

데이터베이스에 파일을 저장하는 데 약간의 문제가 있습니다. 파일은 일반적으로 평균 행보다 훨씬 큽니다. 많은 큰 파일을 포함하는 결과 집합은 많은 메모리를 소비합니다. 또한 쓰기를 위해 테이블 ​​잠금 (예 : ISAM)을 사용하는 스토리지 엔진을 사용하는 경우 파일 테이블은 저장하는 파일의 크기 / 속도에 따라 자주 잠길 수 있습니다.

보안 관련-일반적으로 파일을 문서 루트 외부에있는 디렉토리 (http 요청을 통해 액세스 할 수 없음)에 저장하고 먼저 적절한 권한을 확인하는 스크립트를 통해 파일을 제공합니다.

옵션 B의 유일한 이점은 모든 데이터를 하나의 시스템에 저장하는 것입니다. 그러나 잘못된 이점입니다! 코드도 데이터 형식이므로 데이터베이스에 저장할 수 있습니다. 어떻게 하시겠습니까?

특별한 경우가 없다면 :

• 비즈니스 로직은 코드에 속합니다.
• 구조화 된 데이터는 데이터베이스 (관계형 또는 비 관계형)에 속합니다.
• 대량 데이터는 스토리지 (파일 시스템 또는 기타)에 속합니다.

파일 시스템을 사용하여 파일을 유지할 필요는 없습니다. 대신 클라우드 스토리지 (예 : Amazon S3 ) 또는 인프라로서의 서비스 (예 : Uploadcare )를 사용할 수 있습니다.

https://uploadcare.com/upload-api-cloud-storage-and-cdn/

그러나 데이터베이스에 파일을 저장하는 것은 나쁜 생각입니다.

Flickr는 파일 시스템을 사용합니다. 여기에서 그 이유를 논의합니다

나는 이것이 오래된 게시물이라는 것을 알고 있습니다. 그러나이 페이지를 방문하는 많은 방문자는이 질문과 관련이 없습니다. 특히 초보자에게는.

웹 사이트에서 이미지 또는 파일을 업로드하고 저장하는 방법 :

정적 웹 사이트의 경우 일부 공유 호스팅의 파일 저장소가 여전히 적합하므로 문제가 없습니다. 동적 웹 사이트가 커지면 문제가 발생합니다. 데이터베이스에서 더 큰 것을 처리 할 수 ​​있지만 이미지와 같은 파일에서 더 큰 것이 문제가됩니다. 웹 사이트에는 두 가지 유형의 이미지가 있습니다.

1. 이미지는 동적 블로그 관리자가 제공합니다. 일반적으로 이러한 이미지는 업로드 전에 최적화되었습니다.

2. 사용자의 경우 사용자의 이미지는 아바타와 같은 이미지를 업로드 할 수 있습니다. 또는 사용자는 블로그 컨텐츠를 작성하고 텍스트 편집기에서 일부 이미지를 넣을 수 있습니다. 이러한 종류의 이미지는 크기를 예측하기가 어렵습니다. 사용자는보기 크기는 조정하지만 이미지 크기는 조정하지 않아도 작은 콘텐츠에 대해서만 큰 이미지를 업로드 할 수 있습니다.

품목 번호를 무시하여 위의 1, 품목 번호에 대한 빠른 해결책. 2 웹 사이트에 이미지 최적화 기능이없는 경우 다음 팁으로 일시적으로 해결할 수 있습니다.

1. 사용자가 이미지 갤러리로 리디렉션하여 텍스트 편집기에서 직접 업로드 할 수 없도록하십시오. 이 페이지에서 사용자는 컨텐츠에 포함되기 전에 파일을 미리 업로드해야합니다. 이 방법을 파일 관리자라고합니다.

2. 사용자가 이미지를 업로드 할 때 이미지 자르기 기능을 사용하십시오. 사용자가 매우 큰 파일을 업로드하더라도 이미지 크기가 제한됩니다. 최종 이미지는 자른 이미지의 결과입니다. 서버 측에서 크기를 정의 할 수 있으며 예를 들어 500Kb 이하 만 허용합니다.

이제는 일시적입니다. 최종 솔루션의 경우 질문이 반복됩니다.

• 큰 이미지 저장을 처리하는 방법?
• 확장 프로그램의 크기를 조정하거나 변경하십시오.
• 크고 작은 웹 사이트 나 전자 상거래는 이미지의 파일 저장을 어떻게 처리합니까?

우리가 할 수있는 일 :

1. 공유 호스팅 VPS에서 마이그레이션 부족한? 그런 다음 Dedicated (전용)로 업그레이드하면 더 높아집니다.

2. 파일 저장을위한 자체 서버를 작성하십시오. 인터넷 검색을 수행합니다. 생각만큼 어렵지 않습니다. 어떤 사람들은 웹 사이트를 위해 그것을합니다.

3. 가장 쉬운 방법은 CDN 파일 저장 서비스를 사용하는 것입니다.

좋아, 1과 2는 약간 비싸다. 그러나 3은 최고의 솔루션이라고 생각하지 않습니다.

일부 CDN 서비스를 사용하면 원하는만큼 웹 파일을 저장할 수 있습니다.

질문, "웹 사이트에서 CDN으로 파일을 업로드하는 방법은 무엇입니까?"

걱정하지 마십시오. 일단 등록하면 일반적으로 무료이며 파일 업로드 방법과 웹 사이트 간 링크를 얻는 방법에 대한 지침을 얻을 수 있습니다. API 등을 얻을 수 있습니다. 그것은 간단합니다.

일부 공급자는 제한된 저장 공간과 대역폭으로 14 일 동안 무료 서비스를 제공합니다. 그러나 그것은 출발점에 괜찮을 것입니다. 유일한 문제는 '사람들이 시도하지 않기'때문입니다.

그것이 초보자에게 도움이되기를 바랍니다.

우리는 클라이언트가 몇 가지 다른 백엔드에서 옵션 B (데이터베이스 스토리지)를 몇 번 고집해 왔으며 결국 옵션 A (파일 시스템 스토리지)로 돌아갔습니다.

이와 같은 대형 BLOB는 우리가 시도한 최신 버전 인 SQL Server 2005에서도 제대로 처리되지 않았습니다.

특히, 우리는 심각한 팽창을 보았고 아마도 잠금 문제가 있다고 생각합니다.

또 다른 참고 사항 : NTFS 기반 저장소 (Windows 서버 등)를 사용하는 경우 한 디렉토리에 수천 및 수천 개의 파일을 넣는 방법을 고려할 수 있습니다. 왜 그런지 잘 모르겠지만 때로는 파일 시스템이 그 상황에 잘 대처하지 못합니다. 누구든지 이것에 대해 더 많이 알고 있다면 듣고 싶습니다.

그러나 나는 항상 하위 디렉토리를 사용하여 조금 나눕니다. 작성 날짜는 종종 다음과 같이 잘 작동합니다.

이미지 /2008/12/17/.jpg

... 이것은 적절한 수준의 분리를 제공하고 디버깅하는 동안 약간 도움이됩니다. 탐색기와 FTP 클라이언트는 모두 엄청나게 큰 디렉토리가있을 때 약간 질식 할 수 있습니다.

편집 : 2017의 간단한 참고 사항, 최신 버전의 SQL Server에는 내가 논의 한 단점을 피하기 위해 많은 BLOB를 처리하는 새로운 옵션이 있습니다.

편집 : 2020에 대한 빠른 참고, AWS / Azure 등의 Blob Storage도 수년 동안 옵션이었습니다. 이것은 저렴하기 때문에 많은 웹 기반 프로젝트에 매우 적합하며 배포, 특정 서버로 확장, 필요할 때 다른 환경 디버깅 등과 같은 특정 문제를 단순화 할 수 있습니다.

최근에 PDF / Word 파일을 MySQL 테이블에 저장하는 PHP / MySQL 앱을 만들었습니다 (지금까지 파일 당 최대 40MB).

장점 :

• 업로드 된 파일은 다른 모든 것과 함께 백업 서버에 복제되므로 별도의 백업 전략이 필요하지 않습니다 (안심하십시오).
• 업로드 / 폴더가 없어도 모든 응용 프로그램의 위치를 ​​알 필요가 없기 때문에 웹 서버 설정이 약간 더 간단합니다.
• 데이터 무결성을 향상시키기 위해 편집을 위해 트랜잭션을 사용하게됩니다. 고아 파일이 없거나 누락 된 것에 대해 걱정할 필요가 없습니다.

단점 :

• 테이블 중 하나에 500MB의 파일 데이터가 있으므로 mysqldump는 이제 looooong 시간이 걸립니다.
• 파일 시스템과 비교할 때 전반적으로 메모리 / CPU 효율성이 떨어짐

구현을 성공이라고 부르고 백업 요구 사항을 처리하고 프로젝트 레이아웃을 단순화합니다. 앱을 사용하는 20-30 명의 사용자에게는 성능이 좋습니다.

나는 내 웹 사이트에 업로드 된 이미지를 사용하고 옵션 a)를 분명히 말할 것입니다.

내가 추천하는 또 다른 사항은 파일 이름을 사용자가 사진에서 지정한 이름에서보다 관리하기 쉬운 이름으로 즉시 변경하는 것입니다. 예를 들어, 각 사진을 고유하게 식별하기 위해 날짜와 시간이있는 것.

또한 나중에 합병증을 피하기 위해 이상한 문자의 사용자 파일 이름을 제거하는 데 도움이됩니다.

이미지의 크기를 확실히 조정하고 가능한 경우 형식을 확인하십시오. 예를 들어 GIFAR 취약점으로 인해 악의적 인 Java 애플릿을 GIF 파일에 숨겨 현재 컨텍스트에서 쿠키를 읽고 보낼 수 있습니다. 사이트 간 스크립팅 공격을위한 또 다른 사이트. 이미지의 크기를 조정하면 일반적으로 포함 된 코드가 축소되므로이를 방지 할 수 있습니다. 이 공격은 JVM 패치로 해결되었지만 이진 파일을 스크러빙하지 않고 순진하게 제공하면 모든 범위의 취약점이 열립니다.

대부분의 바이러스 스캐너는 파일 시스템에 대해서만 실행할 수 있습니다. 바이너리를 DB에 저장하면 스캐너를 매우 쉽게 실행할 수 없습니다.

SQL Server 2008에는 RunAs Radio # 74 에서 언급 된 파일 스트림 데이터 유형 이라고하는 일종의 하이브리드 방식이 있습니다. 대부분의 사람들은 2008 년 otion을 가지고 있지 않지만, 그렇게한다면이 옵션은 매우 멋지게 보입니다

이것은 기본적으로 내가하는 일입니다.

1. 업로드 된 이미지를 임시 디렉토리 또는 메모리에 저장하십시오.
2. 영구적으로 저장하기 전에 해당 이미지를 처리하십시오. 2.1. 색상 보정 2.2. 압축 2.3. 이미지 크기를 기준으로 여러 복사본 만들기 2.4. .xl, .lg, .md, .sm 등 접미사로 이름 바꾸기
3. 처리 된 모든 이미지 파일 (단일 파일에서) id을 모든 행 / 문서에 대한 데이터베이스에 저장 될 폴더 이름을 가진 폴더 안에 넣 습니다 image file name(또는 이미지 이름으로 임의 이름 일 수 있음).
4. 존재하지 않는 경우 yyyy / mm / d path 폴더를 만듭니다 . 예를 들어 2016/08/21입니다. 동일한 문서와 행에 대해 해당 경로와 데이터베이스에 저장하십시오.
5. 이미지 id폴더를 path폴더로 이동하십시오 . (경로 폴더는 / var / web-content 폴더에있을 수 있습니다.)
6. 메모리 버퍼를 비우거나 임시 파일을 삭제하십시오.

문서에 언급 된 이미지에 액세스해야하는 경우 이미지가 포함 된 폴더의 경로와 ID가 있습니다. 예를 들어/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg

이렇게하면 처리 된 모든 이미지 파일을 삭제 해야하는 경우 폴더를 삭제하면 내용이 반복적으로 나타납니다.

대부분의 구현은 옵션 A입니다.

옵션 B를 사용하면 데이터베이스에서 해당 비트를 브라우저에 표시 할 수있는 비트로 마샬링 할 때 whoop4ss의 전체 캔을 열 수 있습니다. 또한 db가 다운되면 이미지를 사용할 수 없습니다.

공간이 너무 큰 문제라고 생각하지 않습니다 ... 테라 바이트 드라이브는 현재 수백 달러입니다.

옵션 B를 수행 할 시간이나 리소스가 없기 때문에 옵션 A로 구현하고 있습니다.

자동 크기 조정을 위해 imagemagick을 사용해보십시오 ... 많은 주요 오픈 소스 컨텐츠 / 사진 관리 시스템에 사용됩니다 ... 그리고 .net 확장자가 있다고 생각합니다.

A를 사용합니다. 둘 이상의 서버를 실행할 계획이 아닌 한 공유 드라이브에 넣습니다.

이것이 확장되지 않을 때가되면 캐싱 메커니즘을 조사 할 수 있습니다.

물론, 긍정적 인 옵션 A. 다른 사람들은 데이터베이스가 BLOB을 처리하도록 설계되었는지 여부에 관계없이 일반적으로 BLOB를 잘 처리하지 못한다고 언급했습니다. 반면에 파일 시스템은 이런 것들을 위해 산다. RAID 스트라이핑을 사용하고 여러 드라이브에 이미지를 분산 시키거나 지리적으로 다른 서버에 이미지를 분산시킬 수도 있습니다.

또 다른 장점은 데이터베이스 백업 / 복제가 엄청나다는 것입니다.

옵션 A.

이미지가로드되면 저장하기 전에 형식을 확인하고 크기를 조정할 수 있습니다. http://www.codeproject.com에 이미지 크기를 조정하기위한 많은 .Net 코드 샘플이 있습니다. 예를 들면 다음과 같습니다. http://www.codeproject.com/KB/cs/Photo_Resize.aspx

보안상의 이유로 공격자가 사이트의 컨텍스트에서 실행될 수있는 이미지 파일 내에 JavaScript를 업로드 할 수있는 IE의 컨텐츠 스니핑으로 인한 문제를 피하는 것이 좋습니다 . 따라서 이러한 종류의 공격을 방지하기 위해 이미지를 저장하기 전에 이미지를 변형 (자르기 / 크기 조정) 할 수 있습니다. 이 답변 에는 다른 아이디어가 있습니다.

글쎄, 사용자가 서버에 파일을 업로드하는 비슷한 프로젝트가 있습니다. 내 관점에서는 옵션 a)가 더 유연하기 때문에 최상의 솔루션입니다. 하위 디렉토리로 분류 된 보호 된 폴더에 이미지를 저장해야합니다. 주 디렉토리는 http 요청에서 액세스 할 수 없도록 스크립트를 실행 (중요) 및 (읽기, 쓰기) 보호하지 않아야하므로 관리자가 기본 디렉토리를 설정해야합니다.

이것이 도움이되기를 바랍니다.

파일을 편집 할 필요가없는 작은 파일 인 경우 옵션 B는 잘못된 옵션이 아닙니다. 나는 파일을 저장하고 미친 디렉토리 구조 문제를 처리하는 논리를 쓰는 것을 선호합니다. 데 많은 하나의 디렉토리에있는 파일의 것은 좋지 않습니다. 알 겠어?

파일이 크거나 특히 사무실과 같은 프로그램에서 지속적인 편집이 필요한 경우 옵션 A가 가장 좋습니다.

대부분의 경우 환경 설정의 문제이지만 옵션 A로 이동하면 디렉토리에 파일이 너무 많지 않게하십시오. 옵션 B를 선택하면 BLOBed 데이터가있는 테이블을 자체 데이터베이스 및 / 또는 파일 그룹에 포함시킵니다. 유지 관리, 특히 백업 / 복원에 도움이됩니다. 정기적 인 데이터는 상당히 작지만 이미지 데이터는 시간이 지남에 따라 커질 것 입니다.

요구 사항, 특히 볼륨, 사용자 및 검색 빈도에 따라 다릅니다. 그러나 중소 규모 사무실의 경우 가장 좋은 방법은 Apple Photos 또는 Adobe Lighroom과 같은 응용 프로그램을 사용하는 것입니다. 이러한 종류의 리소스를 저장, 카탈로그, 색인 및 구성하는 데 특화되어 있습니다. 그러나 스토리지 요구 사항이 많고 사용자 수가 많은 대규모 조직의 경우 Nuxeo 또는 Alfresco와 같은 디지털 자산 관리를 사용하여 콘텐츠 관리 플랫폼을 인스턴스화하는 것이 좋습니다. 두 가지 모두 매우 우수한 리소스를 제공하여 대량의 데이터를 단순화 된 방법으로 검색하여 데이터를 검색합니다. 그리고 매우 중요합니다. 두 플랫폼 모두에 무료 (오픈 소스) 옵션이 있습니다.