카산드라는 다음과 같이 현재 나는 간단한 테이블이 _가 전용 테이블

에서 최신 행을 필터링 할 수 있습니다. 키는 고유 한 타임 스탬프입니다. 모든 쿼리는 다음 형식의 범위 쿼리입니다.카산드라는 다음과 같이 현재 나는 간단한 테이블이 _가 전용 테이블

SELECT * from datatable WHERE timestamp > 123456 ALLOW FILTERING

또한 쿼리는 삽입 된 최신 행의 작은 집합 만 요청합니다. 지금 당장 가지고있는 문제는이 쿼리의 성능이 테이블 크기와 음의 상관 관계가 있다는 것입니다. 테이블이 커짐에 따라 쿼리가 단지 몇 행을 반환하더라도 응답을 얻는 데 훨씬 오래 걸립니다.

성능 저하를 피하기 위해 (예 : 색인 생성 또는 클러스터링 설정) 표 스키마를 수정하는 방법에 대해 조언 해 주실 수 있습니까? 감사합니다.

출처

2017-12-05 kirbo

'ALLOW FILTERING '은 모든 노드를 검사하므로 권장되지 않습니다. 그래서 성능 문제가 있습니다. 달성하고자하는 것에 대한 자세한 내용을 추가 할 수 있습니까? –

Pro-tip, Cassandra에서'ALLOW FILTERING '을 사용해야 할 필요가 있다면 아마 잘못했을 것입니다. – Aaron

버킷 하루 또는 일주일 또는 한 달에 잘립니다 날짜입니다

CREATE TABLE datatable (
    bucket timestamp, 
    time timestamp, 
    value bigint, 
    PRIMARY KEY ((bucket), time) 
) WITH CLUSTERING ORDER BY (time DESC);

처럼 버킷 시간 추가 (약 섭취 속도에 따라 얼마나 많은 알아낼 수, 괜찮은 목표는 파티션 당 64메가바이트에 관한 것입니다 만 thats very flexible), 그렇게하면 단일 파티션 내에서 모든 행을 매우 효율적으로 수집하게됩니다.

노드 당 수십억 개의 파티션이 있으면 복구 및 압축이 크게 느려집니다. 또한 파티션 순서는 무작위 (파티션 키 순서의 murmur3 해시)이므로 위의 쿼리를 순서대로 수행 할 수 없습니다.

위의 값을 사용하면 시작 시간의 버킷을 ALLOW FILTERING (현재 사용하지 않는 장난감 또는 테스트 환경 이외의 다른 환경에서는 사용하지 말아야 함)없이 현재 버켓으로 반복 할 수 있으며 그 결과는 타임 스탬프의 순서

출처

2017-12-05 15:27:55

정확히 내가 말하려고했던 것! – Aaron

GUID가 기본 키로 사용되는 많은 cassandra 관련 예제가 있습니다. GUID는 timestamp와 동일한 성능 문제가있는 것으로 보입니다. perfomace degragation을 방지하기 위해 종류의 버킷을 사용해야합니까? –

작은 파티션은 실제로는 문제가되는데, 그 이유는 위와 같은 시계열에서 발생하지만 엔티티 유형의 경우에는 발생하지 않으므로 항상 문제가되지는 않습니다. timeseries/대기열 유형 외부의 상황은 일반적으로 과잉입니다. GUID 키를 사용했다면 guid에 기반한 어떤 종류의 인공 키를 사용하여 추가 된 날짜를 모른 채 조회를위한 키를 생성 할 수 있습니다. 즉, 최대 guid를 bigint로 3 천만 개로 유지하면 최대 30 백만 개의 키 또는 키의 수를 조정할 수있게하려면 점프/랑데뷰 해시. –

카산드라는 다음과 같이 현재 나는 간단한 테이블이 _가 전용 테이블

답변

관련 문제