Azure 스토리지 테이블 레코드 필터링

Question

Azure Storage Table을 사용하여 구축 된 블로그 게시 시스템과 같은 이미지 이미징. 사용자가 메시지를 게시하고 데이터베이스가 사용자의 Region, City 및 Language를 함께 기록합니다.

그런 다음 사용자는 다른 모든 사용자의 소식을 탐색하고 지역, 도시 및 언어의 조합으로 필터링 할 수 있습니다. 또는 둘 모두를 보지 마십시오.

나는 몇 가지 솔루션을 참조하십시오

1. 이 지역 도시 언어의 조합으로 8 개 개의 다른 파티션에 각 메시지를 넣어 (전문가 : 읽기에 번개 빠른 점 질의, 단점 : 쓰기에 메시지 당 8 개 거래).
2. 각 메시지를 Region-City와 언어로 필터링 할 수있는 파티션 검사 기능 (프로 : 적은 트랜잭션 (1), 단점 : 파티션 스캔, 메시지 당 4 트랜잭션)을 조합하여 4 개의 다른 파티션에 배치하십시오.
3. 사용자의 ID (프로 : 메시지 당 단일 트랜잭션, 단점 : 느린 테이블 스캔 및 그 이후의 파티션 스캔)를 기반으로 각 메시지를 파티션에 넣습니다.

내가 그것을 볼 방법 : 빠른

1. 읽기, 느린 (그리고 아마도 비용이 많이 드는) 글.
2. 균형 읽기/쓰기/비용.
3. 빠른 쓰기, 느리지 만 저렴한 읽기.

"비용/저렴한"이란 거래가 아닌 (공간이 아님) 가격을 의미합니다. 그리고 "균형 잡힌"의미는이 변형들 중 하나를 의미합니다.

인덱스 테이블 사용에 대한 생각은 있지만 여기에서 어떻게 도움이되는지는 알 수 없습니다. 질문은 아마도 다른 좋은 방법이있을 것입니다.

Answer 1

나는 (1)의 변형과 함께 가기로 결정했습니다.

차이점은 Region-Location-Language에 대한 모든 조합을 저장하지 않는다는 것입니다.

Table: FiltersByRegion 
---------------------- 
Partition: Region 
Row:  Location.Language 
Prop:  Message 

---

Table: FiltersByRegionPlace 
--------------------------- 
Partition: Region.Location 
Row:  Language 
Prop:  Message 

때문에 나는 '이 단 순 시청자 수를 저장하기 원하고있어 사실

---

Table: FiltersByRegionLanguage 
------------------------------ 
Partition: Region.Language 
Row:  Location 
Prop:  Message 

---

Table: FiltersByLanguage 
------------------------ 
Partition: Language 
Row:  Region.Location 
Prop:  Message 

---

대신 난 단지 순 시청자 수를 저장하기로 결정 매 게시물마다 많은 거래를해야합니다. 데이터베이스에 아직 존재하지 않는 것들만.

즉, 동일한 region-location-language에서 많은 게시물이있는 경우 필터 테이블이 업데이트되지 않고 트랜잭션이 소비되지 않습니다. 유니크 테스트를 통해 Redis를 사용하여 약간의 작업 속도를 높일 수 있습니다.

필터링은 이제 올바른 테이블을 선택하는 문제입니다.

Answer 2

시나리오 및 읽기/쓰기 패턴에 따라 다릅니다. 일부 측면을 고려해 볼 수 있습니다.

1. 레코드를 쿼리하는 방법에 대한 디자인. 엔터티 데이터로 메시지 ID가있는 "Region-City-Language"파티션에 넣으면 빠른 쿼리에서 도움이 될 수 있습니다.

2. 각 메시지는 고유 한 메시지 ID 및 ID를 가질 수 있습니다. 메시지 매핑은 다른 테이블에 저장되며 메시지가 업데이트되고 다른 테이블에서 참조 된 메시지 ID가 변경되지 않은 경우 하나의 테이블 만 업데이트하면됩니다.

3. 테이블 디자인의 ParitionKey와 RowKey와 두 키가있는 쿼리 엔터티를 활용하십시오. 예 : 파티션 키는 "Region-City-Language"이고 행 키는 "User"입니다.

4. 쿼리 시나리오에 대한 엔티티의 복사본을 저장하는 것이 좋습니다. 예를 들어, 사용자 기반 및 언어 기반 쿼리가 많은 경우 "사용자"및 "언어"가 각각 키로있는 두 개의 테이블이 있다고 생각할 수 있습니다.

자세한 안내는 https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/을 참조하십시오.