보조 인덱스가 자리에있을 때 카산드라 데이터베이스를 확장 할 수있는 잘못된 방법

카산드라는 여러 가지 이유로 내가 가장 좋아하는(관리되지 않음)데이터베이스입니다.

모든 데이터베이스와 마찬가지로 데이터 액세스 패턴을 기반으로 카산드라를 사용해야하므로 임시 쿼리를위한 유연한 데이터베이스가 필요하거나 지속적으로 데이터베이스 모델 변경에 충분히 적응할 수있는 경우 다른 옵션을 고려해야합니다.

카산드라는 열 지향 데이터베이스이며 데이터 쿼리가 이미 정의되어있을 때 정말 강력합니다. 데이터 팩스,카산드라를 지원하는 회사는,당신이 카산드라에서 다음 데이터 모델을 쿼리를 설계하여 시작해야하는 것이 좋습니다. 열 구조에도 불구하고 카산드라는 맵과 같은 열 유형으로 많은 데이터 구조를 지원합니다.

카산드라는 기본 키 데이터베이스이며,이는 데이터가 기본 키의 해시 값(파티션 키)을 기반으로 클러스터를 중심으로 유지되고 구성됨을 의미합니다. 두 개 이상의 파티션이 있는 테이블의 경우 파티션의 첫 번째 부분만 파티션 키로 간주합니다. 복합 키에 대한 자세한 내용은 여기를 참조하십시오.

더 명확하게하기 위해 카산드라의 가장 중요한 특성 중 하나로 돌아 가자.: 그것은 건축 그리고 그것은 스포프가 없다는 사실.

카산드라 클러스터는 노드(3 개 이상)로 구성되며 이러한 노드는 함께 노드 링을 구성합니다:

카산드라 클러스터의 각 노드는”독립적으로”작동하지만 다른 노드는 클러스터에 대해 구성된 복제 요소 구성에 따라 동일한 데이터를 저장할 수 있습니다.

데이터가 유지되는 위치(노드)를 알기 위해 카산드라는 주어진 테이블의 피케이 열을 사용하여 일관된 해시 함수를 통해 계산 된 해시 값(토큰)을 사용합니다.

쿼리를 실행할 때 코디네이터 노드(일반적으로 응용 프로그램 인스턴스 중 가장 가까운 노드)는 링에서 어떤 노드가 데이터를 가지고 있는지 찾습니다. 링의 모든 노드가 읽기 및 쓰기 측면에서 동일한 마스터리스 접근 방식에 대한 마법입니다.

응용 프로그램이 고부하 상태에 있을 때 카산드라 클러스터의 크기를 조정하는 방법을 이해하려면 이 개념을 이해하는 것이 매우 중요합니다.

보조 인덱스

카산드라는 보조 인덱스의 개념도 가지고 있습니다. 관계형 데이터베이스에서는 지정된 테이블에 많은 인덱스를 가질 수 있으며,보조 인덱스를 갖는 비용은 읽기 작업이 아닌 쓰기 작업과 관련이 있습니다. 카산드라에서는 이것이 사실이 아니다.

카산드라의 보조 인덱스는 데이터 모델이 변경되고 새 열을 기반으로 쿼리해야 할 때 유용하고 유혹적 일 수 있습니다.

그런 식으로 보조 인덱스를 사용하면 다음과 같은 쿼리를 실행할 수 있습니다:

다음 표에서 이차식 인덱스를 사용할 수 있습니다.’;

2 차 인덱스 사용에 대한 문제

시나리오를 상상해보십시오:당신은 블랙 프라이데이/사이버 월데이에 있으며 카산드라 클러스터가 피크 이벤트로 고통 받고 있으며 데이터베이스를 확장하기 위해 더 많은 노드를 추가하고 트래픽의 균형을 유지하고 생존해야합니다. 좋아,그렇지?

일반적으로 확장성이 뛰어난 응용 프로그램의 일반적인 상황입니다. 그러나 응용 프로그램이 보조 인덱스를 사용하여 쿼리를 실행하는 경우에는 어떻습니까?

네,요점을 얻었습니다.

카산드라가 파티션 키를 사용하여 링에 데이터를 배포한다고 말했을 때 기억하십니까? 이 문제는 이미 발생하고 있지만 쿼리에 보조 인덱스를 도입 할 때 문제가 발생합니다. 보조 인덱스는 파티션 키의 일부가 아니며 카산드라는 파티션 키를 통해 데이터가 어디에 살고 있는지 알고 있습니다. 이러한 종류의 인덱스를 사용하는 쿼리를 실행할 때 카산드라가 하는 일은 쿼리를 만족시키려고 하는 링의 각 노드를 찾는 것입니다.

실제 시나리오

블랙 프라이데이 동안 우리의 응용 프로그램은 높은 부하였습니다. 블랙 프라이데이 이벤트에서 제공하는 거대한 할인 혜택을 원하는 많은 고객.

우리는 우리의 응용 프로그램을 살펴 보았고 모든 분석은 우리를 우리의 지속성(이 경우 카산드라 데시벨)으로 이끌었습니다. 우리는 대기 시간의 긴 기간을 가지고,하지만 모든 요청에 대해,단지 일부에 대한.

다시 정상 상태로 물건을 유지하려고,우리의 첫 번째 책략은 우리의 카산드라 클러스터에 더 많은 노드를 추가하는 것이 었습니다.

우리는 추가하고 우리는 여전히 대기 시간 문제로 고통 받고 있습니다. 질문은:왜 아직도 이런 일이 일어나고 있습니까?

우리는 틀렸다. 그것은 단순한 결론이었고 우리는 하나의 매우 중요한 세부 사항을 돌보지 않았습니다.이 행동은 모든 요청에서 일어나는 것이 아니라 그 중 일부에서 일어났습니다.

당신이 보조 인덱스에 대해 생각한다면,빙고! 즉,정확히 문제였다.

노드를 추가하면 문제가 해결되지 않습니다. 그것은 완전히 파레토 일이었다.

문제를 자세히 설명하고 문제를 완화하는 방법

블랙프라이데이 이벤트 전 한 순간에 데이터 모델을 변경해야 했습니다. 우리는 우리의 응용 프로그램을 지역화하고 고객의 지역은 우리에게 중요한 일이되기 시작,우리는 제품이나 지역에 따라 데이터를 조회 할 필요가 있었다.

다시 찾고 점을 연결,우리는 우리가 구현에 대한 매우 소중한 것을 깨달을 수 있었다.

우리는 왜 그렇게 소중했을까? 심지어 우리의 쿼리 시간이 많이 증가하지 않았다는 것을 고려하기 때문에,우리는 변화를했다.

이 구현은 보조 인덱스를 사용하여 쿼리 시간을 증가 시켰을뿐만 아니라 카산드라의 인프라를 확장 한 결과 더 많은 문제가 발생했습니다. 우리는 우리의 클러스터에 더 많은 노드를 추가로,따라서 문제가 기하 급수적으로 증가하고,데이터를 찾기 위해 찾아 더 많은 노드를 의미했다.

이 문제를 완화하기 위해 이전에 있었던 노드 수를 회수하여 클러스터에 있는 대부분의 노드에 대한 복제 요소를 늘렸습니다.

또한 읽기 일관성 수준을 덜 일관성있게 변경했습니다. 우리는*쿼럼을 사용하고 대신 우리는 하나로 변경. 이 노드의 부하를 낮추는 데 도움이.

이벤트 며칠 전에 응용 프로그램을 동결 시켰을 때 우리는 새로운 데이터(쓰기 작업)가 없으며 데이터가 현재 상태에서 일관성이 있다는 것을 알았습니다.

다음 날과 데이터베이스 모델 솔루션

최종 솔루션의 일부로 데이터베이스 모델에 대해 다시 생각하고 이벤트 중에 완화 경로로 수행한 변경 내용을 롤백해야 했습니다.이는 순차 번호(카디널리티가 높음)로 인해 클러스터에 데이터를 균등하게 분산시키는 특성 때문에 좋은 결정이었습니다.

새로운 필드”지역”에 대해,우리는 카산드라 컬렉션 데이터 유형을 활용하고 우리의 제품 테이블의 열로 각 지역에 대한지도를 사용했다.

보조 인덱스는 항상 나쁜 생각입니까?

짧은 대답은’아니오’입니다.

조금 더 잘 설명하면 카산드라에는 로컬 인덱스와 글로벌 인덱스의 두 가지 종류의 인덱스가 있습니다.

이름에서 알 수 있듯이 로컬 인덱스는 로컬에만 존재하는 일종의 인덱스입니다. 보조 인덱스를 만들 때 카산드라는 보조 인덱스가 이 테이블의 기본 키가 되는 새(숨겨진)테이블을 만듭니다. 이 새 테이블의 가시성은 링(클러스터)이 아닌 노드 측면입니다. 보조 인덱스의 경우입니다.

반면에 전역 인덱스는 파티션 키를 통해 링 가시성을 가지므로 카산드라는 해당 파티션 키를 통해 링에서 데이터가 어디에 있는지 알고 있습니다.

보조 인덱스는 쿼리에 기본 인덱스와 보조 인덱스가 모두 있는 경우 대안이 될 수 있습니다. 이 경우 카산드라는 파티션 키를 통해 데이터가 어디에 있는지(어떤 노드)를 알고(로컬)보조 인덱스를 참조하는 노드의 로컬 테이블을 찾습니다.

여기에 잘 설명된 보조 인덱스에 대한 몇 가지 다른 뉘앙스도 있지만 가장 좋은 방법은 데이터 모델을 비정규화하여 이를 방지하는 것입니다.