Target Query vs Broadcast Query

• Target Query : Query할 때 어느 Shard에 있는지 안다. (지정한다!)
  • 일부 데이터를 조회하는 경우를 뜻한다.
  • Replica Set 인 경우에는 모든 Shard에 해당 데이터가 존재한다.
    • 따라서 어느 Shard를 조회하나 동일하게 조회가 가능하다.
  • Shared Cluster인 경우에는 데이터를 분산해서 저장한다.
    • 서로 다른 Shard에 있는 경우 찾고 + 병합하는 과정이 있어 속도가 느림
    • ex. I-P에 대한 데이터를 조회하는 경우에는 두번째 shard만 조회하면 되지만, h~p에 대해서 조회할 경우에는 2개의 Shard를 찾고 + 병합한다.

• Broadcast Query :
  • 전체 데이터를 조회
  • Sharded Cluster인 경우, 모든 Shard를 전체를 조회해야하는 케이스를 말한다.
  • 따라서 모든 Shard의 데이터를 조회해와서 병합하는 과정을 거치다보니 속도가 매우 느리다.

• Q. 보통 서비스에서 조회하는 경우는 ‘전체 데이터를 조회’보다는 일부의 조건을 가지고 조회하는 케이스가 훨씬 더 많지 않는가? → 대부분 그렇긴하다.

  • 그런 경우는 Sharded Cluster & 범위조건으로 데이터를 나누는 경우에는 효과가 좋을 수 있다.
  • 하지만, Sharded Cluster 이면서 Hash Shard 인데, 범위를 조회하는 경우에는 a~h의 값을 읽고 싶더라도 전체를 조회해야 한다.
  • vs Sharded Cluster 이면서 값이 index인 경우에는 범위를 조회할 경우, Target Query이다.

  Q. 그럼 Range Shard를 쓰면되는거 아닌가?

  : 그렇다고 한들, range shard 를 사용하면 한 쪽에 몰리는 현상이 발생할 수 있다.

  이는 Sharded Cluster를 쓰는 의미가 없어진다.

• 특히 범위조건으로 하는 경우에는 성능이 특히 떨어진다.

Sharded Cluster의 제한 사항!

Shard 키를 수정할 시에 주의할 점!

• version에 따라서 나뉜다.

• 4.2 ~ Shard Key에 대해서 쿼리 필터로 사용하면 수정할 수 있다.

• ~4.0 에서는 한번 생성한 후에는 무조건 오류가 난다. 따라서 Shard Key변경은 불가능한 작업.

• 예를 들어, 아래와 같이 {a, b}를 가진 복합 Shard Key에 대해서 살펴보자.

a만 쿼리 필터에 넣으면 수정할 수 없다는 오류 메세지가 뜨지만,