[Qdrant] 샤드 (Shard)

#qdrant

이전 포스트
https://blog.naver.com/sssang97/223984676160
분산 DB 클러스터를 구성할 경우에는, 샤드와 레플리카를 관리하는 것이 중요한 지점이 된다.

좀 헷갈릴 수 있는데, 샤드는 큰 데이터를 별도의 노드에 분산해서 저장하는 것을 말하고, 레플리카는 같은 데이터를 여러 노드에 복제해서 일종의 백업을 하는 것을 말한다.
샤드는 파티션이라고도 한며, 전적으로 큰 데이터를 효율적으로 핸들링하기 위한 수단이다.

여기서는 샤드를 다루는 방법만 정리해본다.

Qdrant DB는 3노드 클러스터로 구성되어있다고 가정하겠다.

자동 샤드 구성

분산 클러스터 모드에서는 따로 옵션을 주지 않고 컬렉션을 생성하더라도 샤드가 자동으로 구성된다.
데이터의 분포도를 예측할 수 없고, 항상 전체 데이터셋 기준으로 dynamic한 검색만을 수행해야 한다면 그냥 자동 샤딩을 사용해도 된다.

샤드의 개수는 컬렉션 생성 시에 "shard_number"로 지정할 수 있으나, 기본값은 현재 노드의 개수다.

그러니까 이 경우에는 그냥 만들어도 3개의 샤드로 분산되게 되는 셈이다.

만들고 보면 shard_number가 3개로 설정된 것을 볼 수 있다.

그리고 컬렉션의 클러스터 정보를 보면

해당 컬렉션이 설정된 샤드 목록을 또 볼 수 있다.
그리고 저 shard_id를 이용해서 섬세한 제어를 할 수도 있다.

이 상태에서 데이터를 넣으면

그러면 qdrant가 자동으로 알아서 해싱하고, 적절한 샤드를 찾아서 각 노드에 쪼개서 저장하게 된다.

그럼 검색할 때는 각 노드에 분산된 데이터를 어떻게 찾을까?
이것도 사실 elasticsearch와 접근법은 비슷하다.

query를 받은 DB 노드가 coordinator가 되어서, 다른 노드에서 데이터를 또 필요한 만큼 가져온다.
이 단계에서 사용자가 고려할 것은 딱히 없다.

샤드는 노드의 개수보다 많아도 된다. 기본적으로는 노드당 2개의 샤드를 잡는 것을 권장한다. 노드가 3개면 6개로 잡아도 되는 것이다.

향후 확장이 예상된다면 훨씬 크게 잡아도 된다. 그러면 이후에 재샤딩을 할 필요 없이 편하게 확장할 수 있다.

근데 자동 샤딩을 쓰면 편하긴 하지만, 성능적으로 조정하기 어려운 부분이 생긴다.

예상하고 있는 범위의 특정 데이터 군집을 반복적으로 접근한다고 하면, 그 군집을 샤드별로 쪼개고 매번 따로 조회하는 것은 지나치게 비효율적이기 때문이다.

예를 들어, 특정 채팅방 안에 있는 채팅 데이터는 함께 조회되는 경우가 매우 많을 것이다.
이럴 때는 "채팅방 ID" 같은 것을 기반으로 어떤 데이터가 어떤 샤드에 저장될지를 직접 조정할 필요가 생긴다.

그러면 다른 하나의 샤드만 조회해도 필요한 데이터를 빠르게 가져올 수 있다.

한번 설정해보자.
컬렉션을 만들때 샤드 개수를 1로 지정하고, 샤딩 method를 커스텀으로 지정해야 한다.

그러면, 자동 샤딩모드와는 다르게 샤드 목록이 기본으로 생기지는 않을 것이다.

이걸 이제 우리 필요에 맞게 설정해줘야 한다.

이런 식으로 말이다.
그러면 이제부터는 데이터를 밀어넣을 때마다 저장할 샤드의 키를 정해줘야 한다.

이제는 샤드 키 없이는 샵입도 안된다.

적당히 지정해서 넣고

쿼리를 날려보면

기본 동작은 모든 샤드를 스캔하는 것이다.
그래서 지금은 개별 샤드에 존재하는 모든 값을 가져온 것을 볼 수 있다.

특정 샤드에 있는 데이터만 조회해도 된다면, 쿼리할 때도 샤드 키를 지정할 수 있다.

그럼 딱 그거만 가져온 것을 볼 수 있다.

다른 샤드에 동일한 point ID를 사용하는 것은 권장하지 않는다.
일단, 다른 샤드마다 동일한 point ID를 생성하는 것이 허용되긴 한다. 하지만 전체 샤드 대상으로 검색할 때는 확실하지 않은 방식으로 중복이 제거된다.