사용자가 서버에 이미지를 업로드 할 수있는 응용 프로그램을 작성 중입니다. 나는 모든 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 웹 사이트에 이미지 최적화 기능이없는 경우 다음 팁으로 일시적으로 해결할 수 있습니다.
-
사용자가 이미지 갤러리로 리디렉션하여 텍스트 편집기에서 직접 업로드 할 수 없도록하십시오. 이 페이지에서 사용자는 컨텐츠에 포함되기 전에 파일을 미리 업로드해야합니다. 이 방법을 파일 관리자라고합니다.
-
사용자가 이미지를 업로드 할 때 이미지 자르기 기능을 사용하십시오. 사용자가 매우 큰 파일을 업로드하더라도 이미지 크기가 제한됩니다. 최종 이미지는 자른 이미지의 결과입니다. 서버 측에서 크기를 정의 할 수 있으며 예를 들어 500Kb 이하 만 허용합니다.
이제는 일시적입니다. 최종 솔루션의 경우 질문이 반복됩니다.
- 큰 이미지 저장을 처리하는 방법?
- 확장 프로그램의 크기를 조정하거나 변경하십시오.
- 크고 작은 웹 사이트 나 전자 상거래는 이미지의 파일 저장을 어떻게 처리합니까?
우리가 할 수있는 일 :
-
공유 호스팅 VPS에서 마이그레이션 부족한? 그런 다음 Dedicated (전용)로 업그레이드하면 더 높아집니다.
-
파일 저장을위한 자체 서버를 작성하십시오. 인터넷 검색을 수행합니다. 생각만큼 어렵지 않습니다. 어떤 사람들은 웹 사이트를 위해 그것을합니다.
-
가장 쉬운 방법은 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)를 분명히 말할 것입니다.
내가 추천하는 또 다른 사항은 파일 이름을 사용자가 사진에서 지정한 이름에서보다 관리하기 쉬운 이름으로 즉시 변경하는 것입니다. 예를 들어, 각 사진을 고유하게 식별하기 위해 날짜와 시간이있는 것.
또한 나중에 합병증을 피하기 위해 이상한 문자의 사용자 파일 이름을 제거하는 데 도움이됩니다.
