카산드라가 카디널리티가 높은 열에 인덱스를 만드는 것을 권장하지 않는 이유는 무엇입니까?

카산드라 문서는

다음과 같은 상황에서는 색인을 사용하지 마십시오.

• 카디널리티가 높은 열에서는 소수의 결과에 대해 많은 양의 레코드를 쿼리하기 때문입니다. 아래의 카디널리티 열 인덱스 사용 문제를 참조하십시오.

계속됩니다

많은 고유 값을 갖는 높은 카디널리티 열에 인덱스를 만들면 필드 간 쿼리시 결과를 거의 찾지 못합니다. 10 억 곡의 표에서 아티스트 대신 작가 별 노래 (일반적으로 각 노래마다 고유 한 값)를 찾는 것이 매우 비효율적 일 수 있습니다. Cassandra 내장 색인을 사용하는 대신 테이블을 색인 형식으로 수동으로 유지 보수하는 것이 더 효율적일 것입니다. 고유 한 데이터를 포함하는 열의 경우 인덱스 된 열이있는 테이블에 대한 쿼리 볼륨이 보통이고로드가 일정하지 않은 한 편의상 인덱스를 사용하는 것이 성능 측면에서 좋습니다.

그러나 실제로 질문에 대답하지 마십시오. 왜 비효율적입니까? "테이블을 인덱스 형식으로 수동으로 유지 관리하는"의미가 무엇인지 모르겠습니다. 그러나 "... 쿼리 볼륨이 중간 정도 인 한 편의상 인덱스를 사용하는 것은 때때로 성능 측면에서 우수합니다."

언제 어디서나 PK를 사용하도록 지시하려고합니까? 비효율이란 무엇입니까? 인덱스에 도달하는 쿼리는 클러스터의 모든 ¹ 노드를 쿼리해야하며 각 노드는 로컬 인덱스에서 조회를 수행하고 결과는 집계됩니다. 로트의 가장 느린 노드를 기다려야하므로 네트워크 대기 시간을 지불하는 것을 제외하고는 반드시 비싸지 않습니다 (각 인덱스 조회가 상당히 저렴해야 함). 여기에 빠진 것이 있습니까?

그러나 드물지만 거의 고유하지 않은 속성으로 찾아보아야 할 bajillion 항목이있는 컬렉션이있는 경우… 이것이 적절한 용도입니까?

_{¹ 모두? 복제가 3의 복제 팩터에 대해 클러스터의 1/3에 도달 할 수 있음을 의미하는 경우 IDK?}

Cassandra 인덱스 ( 예 : 기본 키와 달리 "보조 인덱스")를 사용하면 각 노드 는 쿼리 에 응답하기 위해 자체 로컬 데이터 를 쿼리해야합니다 (Cassandra secondary indexexes FAQ 참조 ). 이러한 인덱스는 백그라운드 프로세스를 사용하여 빌드 됩니다 . 이 배경은 지수 가 적중 측면에서 오탐 (또는 오탐 측면에서 오탐)을 리턴 할 수 있음을 의미합니다 .

이는 높은 카디널리티 열에서 해당 열의 변경 비율 ( 즉, 추가 / 삭제)이 상당히 높을 수 있음을 의미합니다. 따라서 변경 프로세스가 백그라운드 프로세스를 통해 인덱스를 업데이트하는 것 보다 빠르면 인덱스를 사용하는 것이 "비효율적"입니다 (인덱스가 애플리케이션에서 필요로하는 것보다 많은 작업을 수행하므로 종종 오답을 얻을 수 있음) .

보다 효율적인 방법은 쿼리의 측면에서 정확성 , 두 번째 유지하기 위해 할 수있는 테이블을 , 오히려 보조 인덱스보다. indexes 와 달리 테이블 은 다른 테이블처럼 취급됩니다. 그들은있는 많은 응용 프로그램을이 쿼리 결과를 줄 가능성이 기대를 . 단점은 테이블을 유지하고 있음을 지표로 이제 응용 프로그램 제약 (하는 카산드라 "보조 인덱스"대,하는 즉, 응용 프로그램 코드는 이제이하는 알고 그 "인덱스"테이블에서 / 삭제 행을 삽입, 그리고 애플리케이션 수준 "조정"을 통해 두 테이블을 동기화 상태로 유지합니다.

도움이 되었기를 바랍니다!

일부 용어 : 상위 테이블은 인덱스가 작성되는 테이블입니다. 보조 인덱스 테이블은 다른 테이블에서 인덱스를 유지하기 위해 생성 된 테이블입니다.

보조 인덱스 테이블의 데이터는 부모 테이블의 데이터와 동일한 노드에 저장됩니다. Cassandra 파티 셔 너는 인덱스 테이블 데이터를 파티셔닝 및 분배하지 않습니다. 따라서 인덱스 열에서 조회를 수행하려는 경우 데이터를 포함하는 복제본 노드뿐만 아니라 모든 노드가 쿼리됩니다. (코디네이터 노드는 데이터가 어디에 있는지 알지 못합니다) https://www.datastax.com/dev/blog/cassandra-native-secondary-index-deep-dive

ssn 또는 다른 고유 ID와 같은 높은 카디널리티 열의 경우 기본 키를 사용한 일대일 매핑이 있습니다. 이러한 열에서 인덱스를 생성하면 데이터가 복제 팩터 수의 노드에 상주하지만 모든 노드에서 조회 호출이 실행됩니다. 가장 좋은 경우 코디네이터가 데이터가 포함 된 노드에 직접 충돌하고 일관성 수준에 도달하면 결과를 얻습니다. 최악의 경우, 찾고있는 데이터가 인덱스에 없으면 모든 노드가 응답하여 데이터가 없다는 것을 알 때까지 기다립니다. 따라서 보조 인덱스 테이블에서 모든 조회 호출에 대해 모든 노드가 적중됩니다. 테이블이 정상적인 C * 테이블 인 경우 모든 조회 호출에 대해 적중되는 복제 요소 수의 노드 만 비교하십시오.