푸른 테이블 스토리지 - 인덱스?

예를 들어 엔티티 테이블 인 "stories"가 있습니다. 여기에는 사람들이 투표 할 수있는 많은 "이야기"목록이 포함됩니다.푸른 테이블 스토리지 - 인덱스?

내 응용 프로그램의 주요 기능은 사용자가 "득표"가 가장 많은 기사를 읽는 것입니다 (결국 다른 알고리즘이 계속 진행될 수도 있습니다). 애저 테이블의 구조

내 첫번째 생각은 :

RowKey = 고유 ID
에 PartitionKey = ??
제목 (아마도 사용자 ID, 당신은 이야기의 사용자 목록을 볼 수 있기 때문에)
URL I 효과적으로 이야기에 대해 조회 할 수있는 방법

는 "정상"으로 간주 설명

사용자 ID

이야기? 대부분의 트래픽은 주요 기사를 쿼리하게 될 것이고 그렇지 않은 경우 다양한 기사를 끌어낼 필요가 없습니다. 내가 원했던 것은 최상위 스토리를 인덱스하는 방법이지만 인덱스는 테이블 스토리지의 기능이 아닙니다. 두 번째 테이블을 유지하는 방법에 대해 생각했지만 사용자가 다른 테이블의 스토리를 업데이트하면 털이 나올 수 있습니다.

이것은 Azure Table Storage를 사용하는 나의 첫번째 hangup이고, 나머지 애플 리케이션은 훌륭하게 작동 할 것입니다. 이 문제로 인해 전체 SQL Azure로 업그레이드하는 것을 싫어합니다.

PS - "상위"스토리를 Azure 테이블 외의 다른 장소에 저장하는 것이 좋습니다. 내 서버는 C# web api를 실행하지만 아무런 차이가 없습니다.

출처

2014-02-21 jonathanpeppers

Azure 테이블 저장소는 비 관계형 데이터 저장소입니다. 따라서 데이터를 저장하고 모델링하는 방식이 크게 다릅니다. 일반적인 패턴은 다양한 유형의 액세스에 대해 두 개의 서로 다른 데이터 저장소를 모델링하는 것입니다. 가장 최근의 테이블 하나와 "가장 좋아하는"테이블의 업데이트입니다.

출처

2014-02-21 16:20:49 BrentDaCodeMonkey

네, 두 테이블을 갖는 것이 최선의 방법이라고 생각합니다. 사람들이 기사에 투표하면서 투표 기록을 "최고"이야기 테이블에 기록하는 것을 확인할 수 있습니다. 커미션 테이블이있는 경우 storie의 "id"로 액세스 할 수 있으며 "최상위"스토리 테이블에 레코드 사본이 있으면 정상적으로 작동합니다. – jonathanpeppers

두 개의 파티션 또는 두 개의 테이블을 사용하는 것이 더 좋습니까? 생각? – jonathanpeppers

파티션이 스케일 단위이고 Azure 테이블 스토리지가 스키마가 적기 때문에별로 중요하지 않습니다. 당신이 생각해야 할 더 큰 질문은 "투표"를 관리하는 방법입니다. 수천 명의 사람들이 기사를 쳤다면 투표 테이블에 병목 현상이 생길 수 있습니다. 어쩌면 체크 아웃 할 수 있습니다 : http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-43-Scalable-Counter-with-Windows-Azure – BrentDaCodeMonkey

"우선 탑 스토리"가 실제로 의미하는 바를 먼저 반영해야합니다. 마지막으로 상위 10 개 이야기를 의미합니까 아니면 특정 비율 값보다 높음을 의미합니까?

파티션 키로 요금 값을 사용할 수 있습니다 (예 : Rate_1, Rate_2, Rate_3, Rate_4, Rate_5). 그러나 값을 정수로 반올림해야하므로 값이 4.1이면 분할률 Rate_4에 배치됩니다.

또는 "TopStories"및 "OtherStories"파티션을 2 개만 사용할 수도 있습니다.

출처

2014-02-21 16:15:01 johnnyno

그렇다면 "최상위"스토리 파티션에서 다른 파티션으로 스토리를 이동시키는 메커니즘은 무엇입니까? 기록을 삭제하고 새 기록을 삽입해야합니까? 이것은 사람들이 이야기를 위아래로 투표 할 때 일어납니다. – jonathanpeppers

두 개의 파티션 또는 두 개의 테이블을 사용하는 것이 더 좋습니까? 생각? – jonathanpeppers

예, entity를 대체해야합니다. 어떤 데이터 액세스 패턴을 예상합니까? 많은 업데이트가 파티션 키를 업데이트하는 것이 좋은 해결책이 아닐 수도 있습니다. 캐싱 최고의 스토리를 제공하여 사전 형식을 개선 할 수도 있습니다. – johnnyno

는

최상위 이야기 알고리즘이 초과 근무를
정보와 같은 요약
와 나는 테이블 스토리지에서 상태를 유지 할

을 세 될 수있는 사실을 진화 할 수 있다는 것을 감안할 때 대신 쿼리의 유연성을 위해 관계형 데이터베이스에서 모델링합니다.

출처

2014-02-21 17:34:00 hocho

RDBMS에서 스케일 문제가 발생했습니다. 1) 저장소 접근 방식에 영향을주지 않습니다. 2) Azure 테이블에서도 주소가 지정 될 수 있습니다. 3) Azure 테이블에서도 주소가 지정 될 수 있습니다. – BrentDaCodeMonkey

SQL Db 사용에 대한 권장 사항은 "최상위 이야기" 이야기 자체가 아닙니다. 탑 스토리 알고리즘은 지난 24 시간 동안 스토리를 추적하면되므로 대규모로 작업 할 필요가 없습니다. SQL Db는보다 다양한 쿼리 시나리오를 지원하며 "최고의"선택이 될 것입니다. – hocho

글쎄, SQL DB는 우리 모두 훈련 된 방식이지만 가격은 100 배 더 큽니다. – Sentinel

Azure Storage Table Design Guide은 자신의 보조 표시를 만들기위한 다양한 접근 방법을 안내합니다.또한 NoSQL 데이터베이스를 설계 할 때 고려해야 할 원칙과 구현 지침을 제공합니다.

출처

2016-10-04 01:17:57

이것은 좋은 정보이며 다른 사람들은 @Jason이 저자임을 알고 싶어합니다. 하지만 -1이 필요하다고 생각하지 않습니다. +1. – jonathanpeppers

푸른 테이블 스토리지 - 인덱스?

답변

관련 문제