카산드라 인덱싱:좋은 것,나쁜 것,못생긴 것

인덱싱,정보 가져 오기 및 검색 작업은 물리적 저장 메커니즘과 밀접하게 관련되어 있습니다. 행은 호스트 간에 저장되지만 단일 행은 단일 호스트에 저장됩니다. (복제본 사용)열 패밀리는 정렬 된 순서로 저장되므로 열 집합을 효율적으로 쿼리합니다(행에 걸쳐있는 경우).

나쁜 : 파티셔닝

처음에는 익숙해지기 힘든 것 중 하나는 행에 걸쳐있는 인덱스 쿼리가 없으면(매우)나쁠 수 있다는 것입니다. 그러나 우리의 스토리지 모델로 돌아 가면 놀라운 일이 아닙니다. 카산드라가 호스트 간에 행을 배포하는 데 사용하는 전략을 파티셔닝이라고 합니다.

파티셔닝은 각 호스트에 행 키 범위의 세그먼트(즉,파티션)에 대한 책임을 할당하는”토큰 링”에 할당하는 행 키 범위를 조각하는 행위입니다. “토큰”으로 클러스터를 초기화 할 때 이것을 보았을 것입니다. 토큰은 토큰 범위의 섹션에 대한 책임을 할당하는 토큰 링을 따라 호스트에 위치를 제공합니다. 분할은 행 키를 토큰 범위에 매핑하는 작업입니다.

두 가지 기본 파티셔너가 있습니다:무작위 및 순서 보존. 그들은 적절하게 이름이 지정됩니다. 랜덤 비트러시는 행 키를 토큰으로 해시합니다. 랜덤 비트매개업자의 경우 토큰은 행 키의 해시입니다. 이렇게 하면 노드 집합에 데이터를 균등하게 분배할 수 있지만 행 키 공간의 범위를 쿼리하는 것은 매우 어렵습니다. “시작 행 키”값과”종료 행 키”값에서만 카산드라는 필요한 토큰 공간의 범위를 결정할 수 없습니다. 본질적으로 쿼리에 응답하기 위해”테이블 스캔”을 수행해야하며 카산드라의”테이블 스캔”은 쿼리에 응답하기 위해 각 머신(해시 함수가 좋은 경우 모든 머신 일 가능성이 높음)으로 이동해야하기 때문에 좋지 않습니다.

이제 데이터 배포도 큰 비용으로 사용할 수 있습니다. 나는*하지*오프와 함께 아래로. 행 키를 토큰으로 변환할 때 순서를 유지합니다. 이제 시작 행 키 값과 끝 행 키 값이 주어지면 카산드라*는 찾고있는 데이터를 가진 호스트를 정확히 결정할 수 있습니다. 시작 값을 토큰으로 계산하고 끝 값을 토큰으로 계산하고 그 사이의 모든 것을 선택하고 반환합니다. 그러나 순서를 유지함으로써 행 키가 공간에 균등하게 분배되지 않는 한 토큰도되지 않으며 클러스터의 구성 및 관리 비용이 크게 증가하는 한쪽으로 기울어 진 클러스터를 얻을 수 있습니다. (그럴 가치가 없어)

좋은:보조 인덱스

카산드라는 보조 인덱스에 기본 인덱싱 메커니즘을 제공합니다. 보조 인덱스는 열 값에서 작동합니다. 열 패밀리에 보조 인덱스를 선언합니다. 데이터 택스는 사용에 대한 좋은 문서를 가지고있다. 후드 아래에서 카산드라는”숨겨진 열 패밀리”를 인덱스로 유지합니다. (자세한 내용은 에드 아누프의 프레젠테이션 참조)카산드라는 한 노드에서 열 값 정보를 유지하지 않으며 보조 인덱스가 행 키가 아닌 열 값에 있기 때문에 쿼리는 여전히 모든 노드로 전송되어야합니다. 또한 높은 카디널리티 집합에는 보조 인덱스를 사용하지 않는 것이 좋습니다. 나는 아직 보지 않았지만 이것이”숨겨진 열 패밀리”내에서 사용되는 데이터 모델 때문이라고 가정합니다. 숨겨진 열 패밀리가 고유 값당 행(행 키를 열로 사용)을 저장하는 경우 행을 검색하여 쿼리의 범위 내에 있는지 확인하는 것입니다.
에드의 발표에서:

  • 높은 카디널리티 값(예:타임 스탬프,생년월일,키워드 등)에는 권장되지 않습니다.)
  • 쿼리에서 적어도 하나의 평등 비교가 필요합니다.
  • 정렬되지 않은-결과는 쿼리 값 순서가 아니라 토큰 순서입니다.
  • 데이터 유형에 대한 검색으로 제한되며 카산드라는 기본적으로 다음을 이해합니다

모두와 함께,보조 인덱스는 상자 밖으로 작동하고 우리는 간단한 값에 그들을 사용하여 좋은 성공을 거두었습니다.

추악한:스스로 할 수있는(직접)/넓은 행

지금,아름다움은 보는 사람의 눈안에 있는다. 노스클에 대한 아름다운 점 중 하나는 단순함이다. 구조는 간단합니다:키 공간,열 패밀리,행 및 열. 그러나 그것을 간단 하 게 유지 의미 때때로 당신은 당신의 자신의 손에 것 들을 걸릴 필요가.

이것은 와이드 행 인덱스의 경우입니다. 카산드라의 스토리지 모델을 활용하여 각 행 키가 인덱스의 열이되는 자체 인덱스를 쉽게 구축 할 수 있습니다. 이 주위에 당신의 머리를 얻기 위해 때로는 어렵다,그러나 우리는 우리가 우편 번호에있는 모든 사용자를 선택하려는 그것에 의하여 경우가 상상할 수 있습니다. 주 사용자 열 제품군은 사용자 정의 키에 입력,우편 번호는 각 사용자 행의 열입니다. 우리는 보조 인덱스를 사용할 수 있지만 꽤 많은 우편 번호가 있습니다. 대신 우리는”라는 단일 행으로 열 패밀리를 유지할 수 있습니다. 이 행에 열을 쓸 수 있습니다. 열은 정렬 된 순서로 저장되므로”18964″로 시작하는 모든 열을 빠르게 쿼리합니다(예:18964_ 및 18964_를 시작 및 끝 값으로 사용할 수 있음).

이 접근 방식의 한 가지 명백한 단점은 행이 호스트에 자체 포함되어 있다는 것입니다. (다시 복제본을 제외하고)이는 모든 쿼리가 단일 노드에 도달한다는 것을 의미합니다. 나는 아직 이것에 대한 좋은 대답을 찾지 못했습니다.

또한,그리고 이럴 때,넓은 행 인덱싱의 가장 추악한 부분은 클라이언트 관점에서입니다. 우리의 구현에서,우리는 사람들이 카산드라의 데이터와 상호 작용하는 작업에 가장 적합한 도구를 선택할 수 있도록,클라이언트 측에서 언어 불가지론하기 위해 최선을 다했습니다. 그 정신으로,디디 인덱스는 몇 가지 문제를 제시한다. 넓은 행은 종종 복합 키를 사용합니다. 복합 키에 대한”기본”지원이 있지만 모든 클라이언트 라이브러리는 자체 버전(헥터,아스 티아 낙스 및 중고품)을 구현합니다. 즉,데이터를 쿼리해야 하는 클라이언트에서는 먼저 인덱스를 쿼리할 논리를 추가해야 하며,또한 모든 클라이언트는 동일한 방식으로 복합 키를 생성해야 합니다.

더 나은 만들기…

바로 이런 이유로,이 논리를 서버 측에 푸시하는 데 도움이되는 두 개의 오픈 소스 프로젝트를 출시하기로 결정했습니다. 첫 번째 프로젝트는 카산드라 트리거입니다. 이를 통해 카산드라의 쓰기에 비동기 활동을 첨부 할 수 있습니다. (그러한 활동 중 하나는 색인 생성 일 수 있습니다)우리는 또한 카산드라 색인을 출시했습니다. 이 도구는 당신의 시스템의 모든 것을 통제하에 관리하는데 도움을 줍니다. 카산드라 인덱싱에 사용한 것과 동일한 서버 측 기술을 사용하여 인덱싱하려는 열을 구성하면 됩니다. 항상 그렇듯이 질문,의견 및 생각을 환영합니다. (특히 어딘가에서 벗어난 경우)

답글 남기기

이메일 주소는 공개되지 않습니다.