작은 Azure 저장 블롭 용기(각각 몇 개의 블롭이 있는 용기)가 많은 것이 좋습니까, 아니면 정말 큰 블롭 용기가 많은 것이 좋습니까?

작은 Azure 저장 블롭 용기(각각 몇 개의 블롭이 있는 용기)가 많은 것이 좋습니까, 아니면 정말 큰 블롭 용기가 많은 것이 좋습니까?

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

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

두 가지 옵션이 있습니다.

옵션 1

저는 "블롭스"(예: "블롭스")라는 컨테이너를 만든 다음 모든 블로그를 해당 컨테이너에 저장합니다.각 BLOB는 수신된 시간인 디렉토리 이름(예: "hr0min0/data.bin", "hr0min0/data2.bin", "hr0min30/data3.bin", "hr1min45/data.bin", ..., "23hrmin0/dataN.bin" 등)과 함께 디렉토리 스타일 이름을 사용합니다.이러한 블롭을 처리하는 것은 먼저 hr0min0 블롭을 처리한 다음 hr0minX 등을 처리할 것입니다(그리고 블롭은 여전히 처리 중입니다).

옵션 2

도착 시간을 기준으로 한 이름의 컨테이너가 여러 개 있습니다(먼저 blobs_hr0min0, blobs_hr0minX 등). 컨테이너의 모든 블롭은 지정된 시간에 도착한 블롭입니다.이러한 블로그를 처리하는 것은 한 번에 하나의 컨테이너를 처리합니다.

그래서 제 질문은, 어떤 옵션이 더 나은가 하는 것입니다.(컨테이너가 다른 서버에 있을 수 있기 때문에) 옵션 2가 병렬화를 더 잘 제공합니까? 아니면 많은 컨테이너가 다른 알려지지 않은 문제를 일으킬 수 있기 때문에 옵션 1이 더 낫습니까?

모든 사람들이 블롭에 직접 접근하는 것에 대한 훌륭한 답변을 제공했습니다.그러나 용기에 블롭을 나열해야 하는 경우 다중 용기 모델을 사용하면 성능이 향상될 수 있습니다.저는 한 컨테이너에 엄청난 양의 블롭을 저장해온 회사와 방금 이야기를 나눴습니다.컨테이너에 있는 개체를 자주 나열한 다음 해당 블롭의 하위 집합에 대해 작업을 수행합니다.전체 목록을 검색할 시간이 증가함에 따라 실적이 크게 개선되고 있습니다.

시나리오에는 적용되지 않을 수도 있지만 고려해야 할 사항입니다.

(확장성/병렬화 관점에서) Win Azure 스토리지의 파티셔닝은 컨테이너가 아닌 BLOB 레벨에서 수행되기 때문에 그다지 중요하지 않다고 생각합니다.여러 컨테이너에 분산되는 이유는 액세스 제어(예: SAS) 또는 전체 스토리지 크기와 더 관련이 있습니다.

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

(아래로 스크롤하여 "파티션"으로 이동합니다.)

견적:

Blobs – 파티션 키가 Blob 이름까지 내려가기 때문에 서버 간에 서로 다른 Blob에 대한 액세스를 로드 밸런싱하여 액세스를 확장할 수 있습니다.이렇게 하면 필요한 만큼 컨테이너를 확장할 수 있습니다(스토리지 계정 공간 제한 내).단점은 우리가 여러 블롭에서 원자 거래를 할 수 있는 능력을 제공하지 않는다는 것입니다.

이론적으로 말하면, 많은 용기와 더 많은 방울이 있는 적은 용기 사이에는 차이가 없어야 합니다.추가 컨테이너는 추가 보안 경계로 적합할 수 있습니다(예: 공개 익명 액세스 또는 다른 SAS 서명).또한 추가 용기를 사용하면 가지치기(단일 용기를 삭제하는 것과 각 방울을 대상으로 하는 것)할 때 하우스키핑을 조금 더 쉽게 할 수 있습니다.저는 이러한 이유로 (성능이 아닌) 더 많은 용기를 사용하는 경향이 있습니다.

이론적으로 성능에 미치는 영향은 없어야 합니다.BLOB 자체(전체 URL)는 Windows Azure의 파티션 키입니다(오래전부터 있음).이는 파티션 서버에서 로드 밸런싱되는 최소 크기입니다.따라서 동일한 컨테이너에 두 개의 서로 다른 블롭이 서로 다른 서버에 의해 제공될 수 있습니다.

Jeremy는 더 많은 용기와 더 적은 용기 사이에 성능 차이가 있음을 나타냅니다.저는 그 이유를 설명할 수 있을 정도로 그러한 벤치마크를 깊이 연구하지는 않았지만, 불일치를 설명할 다른 요인(예: 크기, 테스트 기간 등)을 의심합니다.

여기에 들어가는 요소가 하나 더 있습니다.가격!

현재 List 작업과 Create 컨테이너는 동일한 가격입니다. 0,054 US$ / 10.000 통화

같은 가격이 실제로 블로그를 쓰는 데에도 적용됩니다.

따라서 극단적인 이유로 많은 컨테이너를 생성하고 삭제하면 훨씬 더 많은 비용을 지불할 수 있습니다.

• 삭제는 무료입니다.

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

https://learn.microsoft.com/en-us/azure/storage/blobs/storage-performance-checklist#partitioning

Azure 스토리지에서 BLOB 데이터를 분할하는 방법을 이해하는 것은 성능 향상에 유용합니다.Azure 스토리지는 여러 파티션에 걸쳐 있는 데이터보다 단일 파티션의 데이터를 더 빠르게 처리할 수 있습니다.블로그 이름을 적절하게 지정하면 읽기 요청의 효율성을 높일 수 있습니다.

Blob 스토리지는 확장 및 로드 밸런싱을 위해 범위 기반 파티셔닝 체계를 사용합니다.각 BLOB에는 전체 BLOB 이름(계정+컨테이너+BLOB)으로 구성된 파티션 키가 있습니다.파티션 키는 BLOB 데이터를 범위로 분할하는 데 사용됩니다.그런 다음 범위는 Blob 스토리지 전체에서 로드 밸런싱됩니다.

언급URL : https://stackoverflow.com/questions/8158452/is-it-better-to-have-many-small-azure-storage-blob-containers-each-with-some-bl