Windows Azure 테이블 저장소 계정의 제한 사항

Windows Azure에서 호스팅되고 테이블 저장소를 사용하는 다중 테넌트 웹 기반 SaaS 응용 프로그램을 설계하고 있습니다. Windows Azure 테이블 저장소 계정의 제한 사항

내가 지금까지 발견 한 유일한 한계

은 다음과 같습니다 엔티티 당 가입 당

5 저장 계정
100 TB의 최대 저장 계정 당
1메가바이트는

내가 결정하고 여러 고객을 위해 스토리지를 가장 잘 분할하는 방법 :

옵션 1 : 각 고객에게 고유 한 스토리지 계정을 제공하십시오. 5 계정 기본 제한을 고려하지 않을 가능성이 있습니다.

옵션 2 : 각 고객에게 고유 한 테이블 세트를 제공하십시오. 등 "CustA_Books", "CustB_Books"

옵션 3으로 책 테이블 분할로 고객 식별자와 테이블 이름 접두사 : 테이블의 한 세트를 가지고,하지만 고객을 분할하는 파티션 키를 접두사. "CustA_Fiction", "CustA_NonFiction", "CustB_Fiction", "CustB_NonFiction"등의 파티션 키가있는 하나의 "Books"테이블

옵션 2와 3에 대한 장단점은 무엇입니까? 옵션 2에 영향을 줄 수있는 단일 계정의 테이블 수에 제한이 있습니까?

출처

2011-04-27 Matt Johnson

또 하나의 중요한 한계는 계정 당 초당 5,000 엔티티/메시지/블롭 인 것으로 생각됩니다. http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx –

테이블 이름에 '_'을 사용할 수 없습니다. 문자 (옵션 2 예제와 다름). 영숫자 만 허용됩니다. – Youngjae

Windows Azure에서 만들 수있는 테이블 수에는 제한이 없습니다. 귀하의 유일한 제한은 귀하가 이미 기재 한 것입니다. 음 ... 엔티티 속성의 크기가 항상 64KB 이하이거나 일괄 처리 옵션 (100 엔티티 또는 4MB, 무엇이든간에)을 고려하면 다른 제한이있는 것 같습니다.

아무튼 여기에 유의해야 할 점은 PartitionKey가 가장 중요한 것입니다. 고객 이름과 함께 PK를 작성하면 좋은 파티셔닝 이점을 얻을 수 있습니다. 단점은 동일한 테이블에서 고객 데이터를 혼합하면 데이터를 삭제하는 것이 더 어려워집니다 (고객 삭제가 필요한 경우). 따라서 테이블을 다른 레벨의 분할로 사용할 수 있습니다. 생성하는 PK는 자신이 작성한 테이블에 적용됩니다.

대용량으로 데이터를 삭제해야하거나 고객 (테넌트)간에 데이터를 쿼리해야하는 경우 여기를 고려해보십시오. 첫 번째 경우에는 고객 당 별도의 테이블을 사용하는 것이 합리적입니다. 그래서 삭제는 하나의 작업이고 최대 100 개의 엔티티 당 하나입니다. 그러나 테넌트를 통해 쿼리해야하는 경우 여러 테이블이있을 때이 데이터를 조인하는 것이 더 어렵습니다 (여러 쿼리가 필요할 수도 있음).

모든 것이 동일하기 때문에 임차인 기능이 겹치지 않으면 테이블을 다른 수준의 파티션으로 사용하고 임차인을 삭제해야하는 경우 내 인생을 더 쉽게 만들어야합니다. 그래서, 그 옵션 2

HTH

출처

2011-04-27 21:08:03 dunnry

아, 구독 당 20 개의 스토리지 계정을 추가해야합니다. – dunnry

감사합니다. 나는 옵션 2가 잘 작동한다고 생각한다. 테이블 수에 제한이 있는지 확실하지 않았습니다. –

[이제 구독 당 100 개의 저장소 계정] (http://msdn.microsoft.com/en-us/library/azure/gg433040.aspx) – Gabrielius

내가보기 엔 제안이 고객 데이터에 대한 좋은 수준 또는 연합을 추가하기 때문에 우리는이 길을가는 2

옵션 것 같다. 답글에 언급 된 바와 같이 고객 추가/삭제를 관리하는 것이 더 쉽습니다.우리가 주목 한 또 다른 이점은 고객 데이터의 '복사 가능'입니다. 이러한 접근 방식은 전체 로트에 영향을 미치지 않고 고객 별 데이터를 다른 스토리지 계정 또는 테스트 환경 용으로 이동하는 것을 훨씬 쉽게합니다.

SaaS 세계에서 이것은 또한 많은 SaaS 사용자의 관심사이기도하지만 약간의 노력으로 고객이 자신의 데이터 사본을 얻을 수있게 해줍니다.

출처

2015-09-15 17:35:50

다른 대안 : N 개의 스토리지 계정이 있다고 가정하면 구독 당 100 개의 스토리지 계정이 있습니다. 각 스토리지 계정에는 고객 당 테이블이 있습니다. 삽입, 업데이트, 같은 파티션 키, 테이블 요청 작업의 경우

삭제하거나 포인트 조회, 당신은, 고객 이름 + 파티션 키의 해시 값을 계산하는 기본 N의 모듈 식을 계산 (스토리지 계정의 총 수) 정확한 스토리지 계정의 인덱스를 찾아 올바른 스토리지 계정/테이블로 요청을 전달하십시오.
범위 쿼리와 같은 파티션 키가없는 읽기 요청의 경우. 그런 다음 요청을 모든 스토리지 계정에 브로드 캐 스트하고 결과를 병합해야합니다.

여러 스토리지 계정의 이름 지정과 관련하여 특히주의해야 할 사항 중 하나는 다음과 같습니다. 계정을 사 전적으로 명명하면 Azure 백엔드의 동일한 파티션 서버와 권장되는 확장 성 모범 사례에 따라 계정이 지정됩니다. N 개의 스토리지 계정이있는 경우. 각 스토리지 계정 이름에 3 자리 해시가 붙어 있으므로 균등하게 분배됩니다.

출처

2016-04-06 10:52:16

Windows Azure 테이블 저장소 계정의 제한 사항

답변

관련 문제