2010-06-21 3 views
2

S3에 직접 자산을 업로드하는 데 도움이되는 코드 샘플/플러그인을 많이 보았습니다. 예를 들어, 아바타가있는 사용자 개체가있는 경우 파일 업로드 필드가 S3에 직접로드됩니다.왜 애셋을 S3에 직접 업로드 하시겠습니까?

내가 볼 수있는 유일한 방법이 사용자 개체가 이미 데이터베이스에 작성하고 S3 버킷 + 경로가

user_avatars.domain.com/some/id/partition/medium.jpg 

그러나 같은 것입니다 경우 수있는 것은 당신에 시도 이미지 태그가 있다면 아바타가 업로드되지 않았을 때 해당 URL에 액세스하면 나쁜 결과가 나타납니다. 존재 확인을 어떻게 처리합니까?

또한 대부분의 협회가 잘 작동하지 않는 것처럼 보입니다. 예를 들어, 사용자가 많은 노래/mp3를 가지고 있다면, 어디에 저장하고 어떻게 액세스 할 것입니까?

또한 유효성이 검사됩니다.

S3 (또는 클라우드)로 직접 업로드하는 것이 좋은 생각이며 사람들이 적절한 사용 사례를 명확히하거나 내 논리가 왜 틀린 지 말해 줄 수있는 상황을 생각하는 데 문제가 있습니다.

답변

3

왜 스토리지/대역폭/백업/등을 지불해야합니까? 구름에 누군가가 당신을 위해 그것을 처리하게 할 수 있습니까?

S3 (및 기타 클라우드 기반 스토리지 옵션)가 모든 두통을 처리합니다. 필요한 모든 스토리지, 우수한 배포 네트워크 (프리미엄 CDN 비용을 지불하지 않는 한 자신보다 훨씬 낫습니다) 및 백업을 얻을 수 있습니다.

사용자가 직접 S3에 업로드 할 수있게하면 더 많은 대역폭이 사용됩니다. 추적 문제를 볼 수는 있지만 S3에서는이 상황을 처리하기가 쉽습니다. 직접 업로드 방법을 살펴보면 성공적인 업로드를 위해 강제로 리디렉션 할 수 있음을 알 수 있습니다.

아마존은 다음 리디렉션 처리기에 다음을 전달합니다 : bucket, key, 당신이 성공 후 업로드 된 자산을 추적 할 필요가 무엇을 제공해야 etag

. 직접 업로드는 두 가지 장점을 모두 제공합니다. 당신은 당신의 추적 정보를 얻고 당신의 대역폭을 내린다.

확인 자세한 내용은이 링크 : Amazon S3: Browser-Based Uploads using POST

+0

이것은 실제로 질문에 대답하지 않습니다. S3에 물건을 저장하려는 이유를 완전히 이해합니다. 나는 지금 당장 그것을한다. 내가 이해할 수없는 것은 유효성 검사를위한 도관으로 서버를 사용하지 않고 데이터베이스에 업로드 한 자산을 추적하지 않고서 S3에 직접 업로드하는 방법입니다. – Tony

+1

그게 내가 찾고 있던거야. 당신이 여기에서 잃는 유일한 이유는 변경된 이미지를 다운로드, 후 처리 및 업로드하지 않는 한 이미지의 사후 처리 뿐이라는 것입니다. – Tony

+1

@ 토니 - 도와 줘서 기뻐요. 후 처리에 관해서는 업로드를 프록시하려는 유스 케이스 일 수 있습니다. 사용자가 S3에 직접 업로드하게하면 다운로드하고 다시 업로드해야하는 번거 로움이 있습니다. –

3

당신에게 Heroku에 레일즈 응용 프로그램을 호스팅하는 경우, 이유는 아주 잘 Heroku가 4MB의 이상 파일 업로드 큰 허용하지 않습니다 될 수 있다는 :
http://docs.heroku.com/s3#direct-upload

사용자가 대용량 파일을 업로드 할 수있게하려면 앞으로해야합니다.

+0

최근에이 사실에 대해 들었습니다. 그렇다면 앱을 사용하여 4MB보다 큰 이미지를 처리하는 방법은 무엇입니까? Heroku에. 꽤 큰 한계처럼 보입니다. 해결책이 있다고 짐작하고 있습니다. – Tony

+0

먼저 S3에 직접 업로드하십시오. 그런 다음 AJAX를 통해 앱에 새로 업로드 된 파일을 알립니다. 앱은 S3의 파일에 액세스하여 사후 처리 (예 : 미리보기)를 수행하고 데이터베이스 (예 : Paperclip 또는 Attachment_fu)에 등록 할 수 있습니다. 코드 예제 : http://gist.github.com/575842 또는 http://tnux.net/2010/01/17/swfupload-direct-to-amazon-s3-in-ruby-on-rails/ –

+0

Some more 코드 예제 : Rails 3, Flash 및 MooTools 기반 FancyUploader를 사용하여 S3에 직접 업로드하는 샘플 프로젝트 : https://github.com/iwasrobbed/Rails3-S3-Uploader-FancyUploader ... 그리고 레일즈 3, Flash/Silverlight/GoogleGears/BrowserPlus 및 jQuery 기반 Plupload를 사용하여 S3에 직접 업로드 : https://github.com/iwasrobbed/Rails3-S3-Uploader-Plupload – iwasrobbed

0

웹 서버의 작동 방식을 기억하십시오.

Node.JS 또는 Erlang (2 가지 예)로 달성 할 수있는 것과 같이 일종의 비동기 웹 설정을 사용하는 경우가 아니면 개의 업로드 요청에서 웹 응용 프로그램이 전체 프로세스 또는 스레드를 묶는 반면 파일은 입니다.입니다.

몇 메가 바이트 크기의 파일을 업로드한다고 가정 해보십시오.대부분의 인터넷 사용자는 엄청나게 빠른 업 링크를 가지고 있지 않으므로 웹 서버는 아무 것도하지 않고 많은 시간을 보내고 있습니다. 모든 작업을 수행하는 동안 다른 요청을 처리 할 수 ​​없습니다. 즉, 사용자가 서버에서 오랜 지연 및/또는 오류 응답을 받기 시작합니다. 즉, 다른 웹 사이트를 사용하여 동일한 작업을 수행하기 시작합니다. 항상 더 많은 프로세스와 쓰레드를 실행할 수 있지만, 각각의 프로세스는 더 많은 메모리를 필요로하며 결국 추가 $를 의미합니다.

Justin Niessner가 언급 한 대역폭 절감과 Thomas Watson이 언급 한 Heroku 해결 방법 외에도 S3에 직접 업로드하면 Amazon이 해당 문제에 대해 걱정할 수 있습니다. 단일 프로세스 웹 서버는 Amazon에 실제 기능을 적용 할 수 없으므로 매우 큰 업로드를 효과적으로 처리 할 수 ​​있습니다.

그래, 설치가 더 복잡하고, 물건을 추적하기 위해 콜백을 처리해야하지만, 정말로 작은 파일 이외의 다른 것 (심지어 그러한 경우에도)을 다루는 경우 왜 비용이 더 들지 요합니까?

수정 : 오타 수정

관련 문제