CQRS 읽기 시스템에 Azure Table Storage 또는 SQL Azure를 사용합니까?

CQRS 읽기 시스템에 Azure Table Storage 또는 SQL Azure를 사용합니까?

우리는 읽기 성능을 크게 향상시키는 것을 목표로 CQRS 시스템의 읽기 부분을 사내에 구현하려고 합니다.현재 우리의 읽기는 SQL Azure 데이터베이스의 어느 정도 역직렬화를 포함하여 정규화된 데이터에 대해 Linq-to-SQL 쿼리를 실행하는 웹 서비스를 통해 수행됩니다.

데이터의 단순화된 구조는 다음과 같습니다.

• 사용자
• 대화(같은 수신자에게 보내는 메시지 그룹화)
• 메세지
• 수신인(사용자 집합)

사용자가 메시지 피드 보기를 요청할 때 다음 중 하나를 읽을 수 있도록 이 상태를 정규화되지 않은 상태로 전환합니다.

Azure Table Storage에 저장된 비정규화된 표현

• 파티션 키로서의 사용자 ID
• 대화행 키로서의 ID
• 엔티티로 저장된 변경되기 쉬운 모든 휘발성 데이터
• 엔티티에서 JSON으로 직렬화된 메시지
• 엔티티에서 JSON으로 직렬화된 해당 메시지의 수신자
• 테이블 저장소의 행 크기 제한(960KB)과 관련된 주요 문제
• 또한 "휘발성 데이터" 열에 대한 쿼리는 키의 일부가 아니기 때문에 느려집니다.

Azure Table Storage에 저장된 정규화된 표현

• 대화 세부사항, 메시지 및 수신자에 대한 다른 표
• 대화 테이블에 저장된 메시지 및 수신인의 파티션 키.
• 막대: 위와 동일한 구조를 따릅니다.
• 최대 행 크기 문제를 해결합니다.
• 그러나 정규화된 상태가 비정규화된 테이블의 성능 향상을 감소시킬 수 있습니까?

OR

SQL Azure에 저장된 정규화되지 않은 표현

• 사용자 ID 및 대화복합 기본 키로 보유된 ID
• 변경되기 쉬운 휘발성 데이터를 별도의 열에 저장
• 열에 JSON으로 직렬화된 메시지
• 열에 JSON으로 직렬화된 해당 메시지의 수신자
• 인덱싱 및 비정규화된 데이터 구조를 위한 최고의 유연성
• 테이블 스토리지 쿼리보다 성능이 훨씬 느림

Table Storage 또는 SQL Azure에서 비정규화된 구조를 구현한 경험이 있는 사람이 있는지 여부를 묻는 것입니다. 어떤 것을 선택하시겠습니까?아니면 제가 놓친 더 나은 접근법이 있을까요?

제 직감으로는 테이블 스토리지의 표준화된 데이터(적어도 어느 정도는)가 최선의 방법일 것이라고 생각합니다. 하지만 사용자가 사용할 모든 데이터를 수집하기 위해 3개의 쿼리를 수행하는 것이 성능 향상을 저해하지 않을까 걱정됩니다.

Azure 테이블을 고려하는 주된 이유는 읽기 성능을 크게 향상시키는 것이며, 시나리오에서 SQL Azure를 사용하는 것은 "SQL Azure에 고정된 비정규화된 표현" 아래의 마지막 요점에 따라 "훨씬 더 느립니다."저는 개인적으로 몇 가지 이유로 이것이 매우 놀랍다고 생각하며 이 주장이 어떻게 이루어졌는지에 대한 자세한 분석을 요청합니다.대부분의 경우 SQL Azure가 훨씬 빠르다는 것이 기본 입장입니다.

다음은 제가 그 주장에 대해 회의적인 몇 가지 이유입니다.

• SQL Azure는 기본적이고 효율적인 TDS 프로토콜을 사용하여 데이터를 반환합니다. Azure Tables는 JSON 형식을 사용하므로 자세한 내용은 다음과 같습니다.
• 기본 키를 사용하거나 SQL Azure에 인덱스가 있는 한 SQL Azure의 조인/필터는 매우 빠릅니다. Azure 테이블에는 인덱스가 없으므로 클라이언트 측에서 조인을 수행해야 합니다.
• Azure Tables에서 반환되는 레코드 수 제한(한 번에 1,000개의 레코드)은 많은 레코드를 가져오려면 여러 번의 왕복을 구현해야 함을 의미합니다.

사용자 정의 인덱스를 포함하는 추가 테이블을 만들어 Azure Tables에서 인덱스를 위조할 수 있지만, 사용자가 해당 인덱스를 유지 관리해야 하므로 작업 속도가 느려지고 주의하지 않을 경우 분리 시나리오가 생성될 수 있습니다.

마지막으로 중요한 것은 스토리지 비용을 절감하려는 경우(SQL Azure보다 저렴함)와 SQL Azure가 제공할 수 있는 것보다 더 많은 스토리지가 필요한 경우(단, 이제 Federation을 사용하여 단일 데이터베이스 최대 스토리지 제한을 해소할 수 있음)입니다.예를 들어 10억 개의 고객 레코드를 저장해야 하는 경우 Azure Table을 사용하는 것이 타당할 수 있습니다.하지만 Azure Tables를 사용하여 속도를 높이는 것만으로는 다소 의심스럽습니다.

아키텍처를 완전히 변경하기 전에 SQL Server/SQL Azure에 내재된 성능 병목 현상에 도달하고 있음을 입증할 수 있는 전문 SQL 개발 기술을 보유하고 있는지 확인해 보겠습니다.

또한 귀사의 성능 목표가 무엇인지 정의합니다.액세스 시간이 100배 더 빠를 것으로 예상하십니까?대신 캐슁을 고려했습니까?데이터베이스에서 인덱싱을 올바르게 사용하고 있습니까?

내 2센트...:)

저는 CQRS의 정확한 정의에 대해 논쟁하려고 하지 않을 것입니다.우리가 애저에 대해 이야기하고 있기 때문에, 나는 그것의 문서들을 참조로 사용할 것입니다.이를 통해 다음을 확인할 수 있습니다.

1. CQRS는 별도의 읽기 저장소를 사용할 필요가 없습니다.

   더 큰 분리를 위해 읽기 데이터와 쓰기 데이터를 물리적으로 분리할 수 있습니다.

   "넌 할 수 있어"는 "꼭 해야 해"를 의미하지 않습니다.

2. 비정규화 및 읽기 최적화 정보:

   비록 ~일지라도

   CQRS 기반 시스템의 읽기 모델은 일반적으로 고도로 정규화된 보기로 구체화된 데이터 보기를 제공합니다.

   핵심은

   읽기 데이터베이스는 쿼리에 최적화된 자체 데이터 스키마를 사용할 수 있습니다.

   다른 스키마일 수 있지만 정규화되거나 "고도로 정규화되지" 않을 수 있습니다.다시 한 번 - 할 수 있지만 그렇다고 해서 그렇게 해야 하는 것은 아닙니다.

   또한 SQL 요청이 많아서가 아니라 쓰기 잠금으로 인해 성능이 저하된 경우:

   읽기 저장소는 쓰기 저장소의 읽기 전용 복제본일 수 있습니다.

   또한 요청의 최적화에 대해 이야기할 때는 스토리지 유형보다는 요청 자체에 대해 더 많이 이야기하는 것이 좋습니다.

3. "둘 중 하나에서 읽음"에 대해 [...

   Materialized View 패턴은 원본 데이터가 쿼리에 적합한 형식이 아니거나, 적절한 쿼리를 생성하기 어렵거나, 데이터 또는 데이터 저장소의 특성으로 인해 쿼리 성능이 떨어지는 환경에서 미리 채워진 데이터 보기를 생성하는 것을 설명합니다.

   여기서 핵심은 관점이 복수라는 것입니다.

   구체화된 보기는 단일 쿼리에 대해서도 최적화될 수 있습니다.

   ...

   구체화된 보기는 하나 또는 소수의 쿼리에 특별히 맞게 조정되는 경향이 있습니다.

   따라서 이 세 가지 옵션 중 선택할 수 없습니다.실제로는 훨씬 넓습니다.또한 보기를 생성하기 위해 다른 스토리지가 필요하지 않습니다.모든 작업을 단일 DB 내에서 수행할 수 있습니다.

4. 대해서

   제 직감으로는 테이블 스토리지의 표준화된 데이터(적어도 어느 정도는)가 최선의 방법일 것이라고 생각합니다. 하지만 사용자가 사용할 모든 데이터를 수집하기 위해 3개의 쿼리를 수행하는 것이 성능 향상을 저해하지 않을까 걱정됩니다.

   네, 물론 성능이 저하될 것입니다! (일관성 문제도 고려하십시오.하지만 그것이 괜찮을까요, 아닌가요? 여러분은 그것을 테스트하기 전까지는 절대 확신할 수 없습니다.당신의 데이터와 당신의 요청과 함께.데이터 전송 지연은 일부 정교한 SQL 요청에 필요한 시간보다 짧을 수 있기 때문입니다.

결론은 다음과 같습니다.

1. 필요한 기능은 무엇이며 테이블 스토리지 및/또는 SQL Azure 중 어떤 기능이 있습니까?
2. 그러면 비용이 얼마나 들까요?

이것들은 당신 자신에게만 대답할 수 있습니다.이러한 선택은 성능과 거의 관련이 없습니다.왜냐하면 두 가지 모두에 적합한 지수가 있다면 그 성과는 사실상 구분할 수 없을 것이라고 생각하기 때문입니다.

요약:

SQL Azure 또는 Azure 테이블 스토리지?

다양한 요청과 데이터를 사용할 수 있으며 두 가지 모두를 사용해야 합니다.그러나 질문에 대한 정보가 너무 적어서 정확한 답변을 드릴 수 없습니다(정확한 요청이 필요합니다).하지만 저는 @HerveRoggero의 의견에 동의합니다. 아마도 SQL Azure를 고수해야 할 것입니다.

다른 답변에 가치를 추가할 수 있을지는 모르겠지만, 귀하의 쿼리 경로를 기반으로 데이터 스토리지를 모델링하는 데 관심을 기울이고 싶습니다.언급된 모든 데이터 비트를 함께 쿼리할 것입니까?사용자가 클릭 후 추가 정보로 일부를 요청할 예정입니까?저는 당신이 이 질문에 대해 이미 생각해 보셨을 것이고, 당신이 한 번에 모든 것을 쿼리하고 싶어한다는 것을 확신한다고 생각합니다. 즉, API나 다른 것이 이 모든 정보를 한 번에 반환해야 합니다.

이 경우 키별로 단일 개체를 쿼리하는 것보다 더 나은 것은 없습니다.Azure의 Table Storage에 대해 구체적으로 말씀하시는 경우, 여기에 키 값 스토어라고 나와 있습니다.문서 데이터베이스(예: 코스모스 DB)를 대신 고려하셨는지 궁금합니다.CQRS 읽기 모델을 구현하는 경우 사용자가 피드에서 보는 모든 정보를 포함하는 사용자당 단일 문서를 생성할 수 있습니다.사용자 ID(키)를 기준으로 해당 문서를 쿼리합니다.결국 당신은 읽기 모델을 구현하는 것을 목표로 하고 있기 때문에 이 접근 방식이 제가 생각하는 최적의 CQRS 구현이 될 것입니다.제가 질문을 잘못 해석했거나 문서 데이터베이스를 사용하지 않는 강력한 이유가 있는 경우를 제외하고는요.

언급URL : https://stackoverflow.com/questions/11391415/do-i-use-azure-table-storage-or-sql-azure-for-our-cqrs-read-system