여러 개의 작은 Azure 저장소 Blob 컨테이너 (각각 일부 Blob 포함) 또는 많은 Blob이 포함 된 하나의 정말 큰 컨테이너가 더 나은가요?


81

따라서 시나리오는 다음과 같습니다.

Azure Storage에 데이터 blob을 쓰는 웹 서비스의 여러 인스턴스가 있습니다. Blob을받은시기에 따라 컨테이너 (또는 가상 디렉터리)로 그룹화 할 수 있어야합니다. 가끔 (최악의 경우 매일) 오래된 Blob이 처리 된 다음 삭제됩니다.

두 가지 옵션이 있습니다.

옵션 1

예를 들어 "blobs"라는 하나의 컨테이너를 만든 다음 모든 블로그를 해당 컨테이너에 저장합니다. 각 Blob은 디렉터리 이름이 수신 된 시간 인 디렉터리 스타일 이름을 사용합니다 (예 : "hr0min0 / data.bin", "hr0min0 / data2.bin", "hr0min30 / data3.bin", "hr1min45 / data.bin). ", ...,"hr23min0 / dataN.bin "등 -X 분 마다 새 디렉토리 ). 이러한 Blob을 처리하는 것은 먼저 hr0min0 Blob을 처리 한 다음 hr0minX 등을 처리합니다 (Blob은 처리 중일 때 여전히 기록 중임).

옵션 2

도착 시간을 기반으로 한 이름을 가진 컨테이너가 많이 있고 (첫 번째는 blobs_hr0min0, blobs_hr0minX 등) 컨테이너의 모든 Blob은 명명 된 시간에 도착한 Blob입니다. 이러한 블로그를 처리하는 것은 한 번에 하나의 컨테이너를 처리합니다.

제 질문은 어떤 옵션이 더 낫습니까? 옵션 2는 더 나은 병렬화를 제공합니까 (컨테이너가 다른 서버에있을 수 있기 때문에) 또는 많은 컨테이너가 다른 알 수없는 문제를 일으킬 수 있기 때문에 옵션 1이 더 나은가요?

답변:


60

확장 성 / 병렬화 관점에서 보면 Win Azure Blob 저장소의 분할은 컨테이너가 아닌 Blob 수준에서 수행되기 때문에 실제로 중요하지 않다고 생각합니다. 여러 컨테이너에 분산되는 이유는 액세스 제어 (예 : SAS) 또는 총 스토리지 크기와 더 관련이 있습니다.

자세한 내용은 여기를 참조하십시오 : http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx

( "파티션"까지 아래로 스크롤).

인용 :

Blob – 파티션 키가 Blob 이름으로 내려 가기 때문에 여러 서버에 걸쳐 여러 Blob에 대한 액세스를로드 균형 조정하여 액세스를 확장 할 수 있습니다. 이렇게하면 컨테이너가 필요한만큼 커질 수 있습니다 (스토리지 계정 공간 제한 내에서). 단점은 여러 Blob에서 원자 적 트랜잭션을 수행하는 기능을 제공하지 않는다는 것입니다.


Blob 이름을 가능한 한 짧게 유지할 필요가 있습니까? (I는 "모양의 톤과 하나 개 정말 큰 용기"라는 질문에 옵션 1이 있습니다.)
nmit026

60

모두가 Blob에 직접 액세스하는 것에 대한 훌륭한 답변을 제공했습니다. 그러나 컨테이너에 Blob을 나열해야하는 경우 많은 컨테이너 모델을 사용하면 더 나은 성능을 볼 수 있습니다. 단일 컨테이너에 막대한 수의 Blob을 저장하고있는 회사와 방금 이야기했습니다. 컨테이너의 개체를 자주 나열한 다음 해당 Blob의 하위 집합에 대해 작업을 수행합니다. 전체 목록을 검색하는 시간이 증가함에 따라 그들은 성능 저하를보고 있습니다.

이것은 귀하의 시나리오에 적용되지 않을 수도 있지만 고려해야 할 사항입니다.


1
이것은 좋은 지적입니다. 글을 쓰는 시점 (2016 년 6 월)은 컨테이너의 모든 Blob 목록을 가져오고 목록의 Count속성을 확인하는 것 외에는 컨테이너의 Blob 수를 계산할 수있는 방법이 아직 없다고 생각 합니다.
Steven Rands

Blob 이름을 가능한 한 짧게 유지해야합니까? (나는 "수많은 얼룩을 가진 하나의 정말 큰 컨테이너", 질문의 옵션 1을 가지고 있습니다.)
nmit026

정확히 우리가 피하려는 시나리오
Glenit

21

이론적으로 말하면 많은 컨테이너 또는 더 많은 Blob이있는 더 적은 컨테이너간에 차이가 없어야합니다. 추가 컨테이너는 추가 보안 경계로 유용 할 수 있습니다 (예 : 공개 익명 액세스 또는 다른 SAS 서명의 경우). 추가 컨테이너는 정리 (단일 컨테이너 삭제 대 각 blob 대상 지정)시 좀 더 쉽게 정리할 수 있습니다. 이러한 이유로 더 많은 컨테이너를 사용하는 경향이 있습니다 (성능이 아님).

이론적으로 성능에 미치는 영향은 없어야합니다. Blob 자체 (전체 URL)는 Windows Azure의 파티션 키입니다 (오랫 동안 사용). 이것은 파티션 서버에서로드 밸런싱되는 가장 작은 것입니다. 따라서 동일한 컨테이너에 서로 다른 서버에서 제공되는 두 개의 서로 다른 blob을 가질 수 있습니다 (그리고 종종 그렇게 될 것입니다).

Jeremy는 더 많은 컨테이너와 더 적은 컨테이너간에 성능 차이가 있음을 나타냅니다. 그 이유를 설명 할만큼 벤치 마크를 파헤 치지는 못했지만 불일치를 설명하기 위해 다른 요인 (크기, 테스트 기간 등)을 의심 할 것입니다.


4

이것에 들어가는 또 하나의 요소가 있습니다. 가격!

현재 작업 목록 및 컨테이너 만들기는 동일한 가격 : 0,054 US $ / 10.000 호출

실제로 blob을 작성하는 데 동일한 가격이 적용됩니다.

따라서 극단적 인 원인으로 많은 컨테이너를 만들고 삭제하면 더 많은 비용을 지불 할 수 있습니다.

  • 삭제는 무료입니다

여기에서 계산기를 볼 수 있습니다 : https://azure.microsoft.com/en-us/pricing/calculator/

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.