[performance] S3의 디렉터리 당 최대 파일

백만 개의 이미지가있는 경우 일부 폴더 / 하위 폴더 계층 구조에 저장하거나 폴더없이 모두 버킷에 바로 덤프하는 것이 더 낫습니까?

모든 이미지를 계층 구조가없는 버킷에 덤프하면 LIST 작업이 느려지나요?

폴더 및 하위 폴더를 즉석에서 만들고 ACL을 설정하는 데 (프로그래밍 방식으로) 상당한 오버 헤드가 있습니까?



답변

S3는 계층 적 네임 스페이스를 존중하지 않습니다. 각 버킷에는 키에서 객체로의 여러 매핑 (관련 메타 데이터, ACL 등)이 포함됩니다.

객체의 키에 ‘/’가 포함될 수 있지만 S3는 경로를 일반 문자열로 취급하고 모든 객체를 플랫 네임 스페이스에 넣습니다.

제 경험상 LIST 작업은 객체 수가 증가함에 따라 (선형 적으로) 더 오래 걸리지 만 이것은 아마도 Amazon 서버에서 요구되는 증가 된 I / O의 증상 일 가능성이 높습니다.

그러나 조회 시간은 객체 수에 따라 증가하지 않는 것 같습니다. 이는 아마도 일종의 O (1) 해시 테이블 구현 일 것입니다. 따라서 동일한 버킷에 많은 객체를 포함하는 것은 정상적인 사용을위한 작은 버킷만큼 성능이 좋습니다 (예 : 목록이 아님).

ACL의 경우 버킷과 각 개별 객체에 권한을 설정할 수 있습니다. 계층 구조가 없으므로 두 가지 옵션 만 있습니다. 당연히 버킷 전체 권한을 많이 설정하면 수백만 개의 파일이있는 경우 관리자의 골칫거리를 크게 줄일 수 있지만 권한을 부여 할 수만 있고 취소 할 수는 없으므로 버킷 전체 권한은 모두 ACL의 최대 하위 집합이어야합니다. 그 내용.

다음과 같은 경우 별도의 버킷으로 분할하는 것이 좋습니다.

  • 완전히 다른 콘텐츠-이미지, 사운드 및 기타 데이터를위한 별도의 버킷을 사용하면보다 건전한 아키텍처가됩니다.
  • 상당히 다른 ACL-각 객체가 특정 ACL을 수신하는 하나의 버킷 또는 ACL이 다르고 객체 별 ACL이없는 두 개의 버킷을 가질 수있는 경우 두 버킷을 가져옵니다.


답변

원래 질문 “S3의 디렉터리 당 최대 파일”에 대한 대답은 무제한입니다. 버킷의 객체에 대한 S3 제한 도 참조하십시오 .


답변

루트가있는 디렉토리 구조를 사용하고 하나 이상의 하위 디렉토리를 사용합니다. 나는 종종 “문서 가져 오기 날짜”를 루트 아래의 디렉토리로 사용합니다. 이렇게하면 백업을 좀 더 쉽게 관리 할 수 ​​있습니다. 어떤 파일 시스템을 사용하든 결국 파일 수 제한 (물리적 제한이 아니라면 실용적)에 도달하게됩니다. 여러 루트를 지원하는 것도 생각할 수 있습니다.


답변