다음과 같은 구조를 구현하려고합니다. [u : 112 eq 1] 또는 (u : 118 eq 1)과 같은 쿼리를 수행 할 수 있도록 속성 이름 "u : uid") 또는 (u : 119 eq 1)]. 잠재적으로 작업을 완료 할 수 있습니다. 수백 개의 UID를 검색하는 것과 같은 상황에서는 좋지 않을까 우려됩니다. 또한 응용 프로그램이 커지면 "열"수가 수만 개까지 커질 수 있습니다. 하늘색 테이블 아키텍처에 익숙한 사람이라면 누구에게이 사실을 밝힐 수 있습니까? 그리고 같은 구조를 구현하는 또 다른 방법이 있을까요? 여기Azure 테이블 집합 쿼리
그래서 몇 가지 :
:와 속성의 이름을 수 없습니다.u이 테이블의 속성 이름이라고 가정하면 쿼리 만 PartitionKey을 포함하지 않기 때문에 전체 테이블 스캔이 수행됩니다. 테이블이 작 으면 문제가되지 않지만 테이블이 커질수록 많은 문제가 발생할 수 있습니다. uid이 고유 경우, 나는 당신이에 PartitionKey로 값을 설정 한 다음 난 강력하게 진행하기 전에 윈도우 Azure 스토리지 팀이 블로그 게시물을 읽어 보시기 바랍니다 것이다
(PartitionKey eq '112') or (PartitionKey eq '118') or (PartitionKey eq '119')
처럼 조회 할 수 있습니다 제안 : http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx.
빠른 답장을 보내 주셔서 감사합니다. 불행히도 제 경우에는 PartitionKey와 RowKey 같은 다른 속성을 이미 사용했습니다. (u11, u133, u134 ......)와 같은 수천 개의 키 ("열")가 문제라고 생각하십니까? – spacemilkman
엔티티 당 256 키 (속성 -> 열)의 한계가 있으므로 단 하나의 엔티티에 1000s의 키가있을 수 없습니다. 둘째,'PartitionKey'를 항상 쿼리에 사용하십시오. 검색어 **에서 제외하면 부정적인 영향을 미칠 수 있습니다 **. 당신이 사용하고자하는 완벽한 데이터 구조로 질문을 업데이트 할 수 있습니까? 의미있는 대답을 제공하는 데 확실히 도움이 될 것입니다. –
256 키 제한으로 인해 내 접근이 불가능 해졌습니다. 그래서 본질적으로 나는 uid IN (1,33,233,3,288,8,33322)와 같은 쿼리를 수행해야합니다. Partitionkey가 다른 방식으로 사용되고 있기 때문에이를 달성하기 위해 속성 값을 사용해야합니다. – spacemilkman