데이터 업로드

스토리지를 버킷으로 구성한 후에는 데이터를 업로드하여 일부 오브젝트를 추가해야 합니다.

스토리지 사용 방법에 따라 시스템에 데이터를 가져오는 방법은 여러 가지가 있습니다. 데이터 과학자는 분석에 사용되는 몇 개의 대형 파일을 가지며, 시스템 관리자는 데이터베이스 백업을 로컬 파일과 동기화된 상태로 유지해야 하고, 개발자는 수백만 개의 파일을 읽고 써야 하는 소프트웨어를 작성합니다. 이러한 각 시나리오는 여러 데이터 수집 방법으로 가장 잘 제공됩니다.

일부 애플리케이션의 경우, 특정 사용자 또는 서비스 ID가 버킷 내 데이터를 읽을 수 없도록 제한하고, 오직 데이터 업로드만 허용하고자 할 수 있습니다. 이는 오브젝트 작성자 IAM 역할 을 통해 가능합니다.

콘솔 사용

대개 웹 기반 콘솔 사용은 Object Storage를 사용하는 가장 일반적인 방법은 아닙니다. 오브젝트는 200MB로 제한되며 파일 이름과 키는 동일합니다. 다중 오브젝트를 동시에 업로드할 수 있으며, 브라우저가 다중 스레드를 허용하는 경우 다중 파트를 동시에 사용하여 각 오브젝트를 업로드합니다. 대형 오브젝트 크기 및 성능 개선에 대한 지원은(네트워크 요인에 따라 다름) Aspera 고속 전송을 통해 제공됩니다.

호환 가능 도구 사용

일부 사용자는 독립형 유틸리티를 사용하여 스토리지와 상호작용하려고 합니다. Cloud Object Storage API는 S3 API의 가장 일반적인 작업들을 지원하므로, 많은 S3-compatible 도구들도 HMAC 인증 정보를 사용하여 Object Storage 에 연결할 수 있습니다.

일부 예에는 Cyberduck 또는 Transmit과 같은 파일 탐색기, Cloudberry 및 Duplicati와 같은 백업 유틸리티, s3cmd 또는 Minio Client와 같은 명령행 유틸리티, 그리고 기타 많은 내용이 포함됩니다. 또한 IBM Cloud 카탈로그에서 데이터를 Cloud Object Storage 으로 옮길 수 있는 타사 서비스(예: Lyve 데이터 전송 서비스 )를 검색할 수도 있습니다.

API 사용

Object Storage의 프로그래밍 방식의 애플리케이션 대부분은 SDK(예: Java, node.js 또는 Python) 또는 Cloud Object Storage API를 사용합니다. 일반적으로 오브젝트는 전송 관리자 클래스에서 파트의 수와 파트 크기가 구성된 다중 파트로 업로드됩니다.

조건부 요청

데이터 읽기 또는 쓰기를 요청할 때 불필요한 조작을 방지하기 위해 해당 요청에 대한 조건을 설정할 수 있습니다. 이는 다음과 같은 사전 조건부 HTTP 헤더를 사용하여 구현됩니다: If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since.

일반적으로 If-Match 를 사용하는 것이 바람직합니다. Last-Modified 값의 세분화 단위가 초 단위뿐이기 때문에, 일부 애플리케이션에서는 경합 상태를 방지하기에 충분하지 않을 수 있기 때문입니다.

If-Match 사용

객체에 대한 PUT, HEAD 또는 GET 요청 시, If-Match 헤더는 제공된 Etag (객체 콘텐츠의 MD5 해시)가 제공된 Etag 값과 일치하는지 확인합니다. 이 값이 일치하면 작업이 진행됩니다. 일치하지 않을 경우, 시스템은 ‘ 412 Precondition Failed ’ 오류를 반환합니다.

If-Match를 상태 변경 메소드 (예: POST, PUT, DELETE) 와 함께 가장 자주 사용하여 여러 사용자 에이전트가 동일한 자원에서 병렬로 작동하는 경우 (즉, "업데이트 유실" 문제점을 방지하기 위해) 우발적인 겹쳐쓰기를 방지합니다.

If-None-Match 사용

객체에 대한 PUT, HEAD 또는 GET 요청 시, If-None-Match 헤더는 제공된 Etag (객체 콘텐츠의 MD5 해시)가 제공된 Etag 값과 일치하는지 확인합니다. 이 값이 일치하지 않으면 작업이 진행됩니다. 일치하는 경우, 시스템은 PUT 요청 시 ‘ 412 Precondition Failed ’ 오류를, GET 또는 HEAD 요청 시 ‘ 304 Not Modified ’ 오류를 반환합니다.

If-None-Match는 최소한의 트랜잭션 오버헤드로 캐시된 정보를 효율적으로 업데이트할 수 있도록 조건부 GET 요청에서 주로 사용됩니다. 클라이언트가 엔티티-태그들을 갖는 하나 이상의 저장된 응답들을 업데이트하기를 원하는 경우, 클라이언트는 GET 요청을 할 때 이러한 엔티티-태그들의 리스트를 포함하는 If-None-Match 헤더 필드를 생성해야 한다.

If-Modified-Since 사용

객체에 대한 HEAD 또는 GET 요청 시, If-Modified-Since 헤더는 해당 객체의 Last-Modified 값(예: Sat, 14 March 2020 19:43:31 GMT)이 지정된 값보다 최신인지 확인합니다. 객체가 수정된 경우, 작업이 진행됩니다. 객체가 수정되지 않은 경우, 시스템은 304 Not Modified``를 반환합니다.

If-Modified-Since는 일반적으로 두 가지 별개의 용도로 사용됩니다. 1) entity-tag가 없는 캐시된 표시의 효율적인 업데이트를 허용하기 위해 그리고 2) 최근에 변경된 자원으로 웹 순회의 범위를 제한하기 위해 사용됩니다.

If-Unmodified-Since 사용

객체에 대한 PUT, HEAD 또는 GET 요청 시, If-Unmodified-Since 헤더는 해당 객체의 Last-Modified 값(예: Sat, 14 March 2020 19:43:31 GMT)이 지정된 값과 같거나 그 이전인지 확인합니다. 객체가 수정되지 않은 경우, 작업이 진행됩니다. Last-Modified 값이 더 최신인 경우, 시스템은 PUT 요청 시 ‘ 412 Precondition Failed ’ 오류를, GET 또는 HEAD 요청 시 ‘ 304 Not Modified ’ 오류를 반환합니다.

If-Unmodified-대부분의 경우 상태 변경 메소드 (예: POST, PUT, DELETE) 와 함께 사용되어 여러 사용자 에이전트가 엔티티 태그를 해당 표시와 함께 제공하지 않는 자원에서 병렬로 작동할 수 있는 경우 (즉, "업데이트 유실" 문제점을 방지하기 위해) 우발적인 겹쳐쓰기를 방지합니다. 또한 선택된 표시가 이전 요청에서 이미 저장된 (또는 부분적으로 저장된) 표시와 일치하지 않는 경우 안전한 메소드와 함께 사용하여 요청을 중단할 수 있습니다.

객체 검색 및 필터링

{: #search-filter-objects} Object Storage 콘솔을 사용하여 이름, 크기, 날짜 또는 확장자를 기준으로 개체를 검색하고 필터링할 수 있습니다 자세한 내용은 UI에서 개체 검색 및 필터링 항목을 참조하십시오.