Cassandra 데이터 정렬 범위 쿼리

Question

카산드라 열 패밀리/테이블에 대한 올바른 데이터 모델을 찾아 내 필요한 쿼리를 수행하는 데 어려움을 겪고 있습니다.

금융 거래를 나타내는 단일 유형의 엔티티에 대한 데이터 만 저장하면됩니다. (정렬 쿼리에 적용) 주요 분야 :

1. UUID : 거래 시간
2. SOURCE_ID : 거래
3. 타임 스탬프마다 고유 한 ID 문자열 (낮은 기수, 데이터 세트에서 일반적으로 < (10) 고유 값)
4. destination_id : 문자열 (낮은 카디널리티 일반적 < 10 데이터 세트에서 고유 값)
5. MERCHANT_ID : 문자열 (높은 카디널리티 ~ 100K 고유 값)

추가 필드가 있습니다 (총 약 20 개). 그러나 쿼리 나 주문에는 필요하지 않습니다.

1. UUID
2. 하여 날짜 범위에 의해, 주문 SOURCE_ID/destination_id의 정확한 값에 대한 MERCHANT_ID

UUID를 쿼리 기준 :

나는 다음과 같은 두 가지 방법으로 거래를 조회 할 필요가 날짜 범위 쿼리는 가능한 한 효율적이어야하지만 오프라인 프로세스로 매일 실행되므로 시간이 오래 걸릴 수 있습니다. 쿼리 시간이 no로 확장되는 방식을 이해하는 것이 좋습니다. 기록.

Cassandra는 파티션 키 구성에 영향을 줄 경우 2 개의 데이터 센터에서 4 개의 노드 클러스터로 설정됩니다. 나는 카산드라 2.0을 사용하고 있습니다.

Cassandra에 다소 익숙하기 때문에 합성 키, timeuuid, 슬라이스 쿼리 등을 읽었지만 다소 혼란 스럽습니다. 누구나 올바른 접근 방식을 제시하거나 올바른 방향으로 나를 가리킬 수 있다면 매우 감사하게 생각합니다.

감사합니다. 는 (참고, 내가 여기에 있으리라 믿고있어/destination_id이 요구 사항 모두를 의미 SOURCE_ID이 : 쿼리 2는 좀 더 복잡하다

create table tx_by_uuid (
tx_id uuid PRIMARY KEY, 
tx_time timestamp, 
source_id text, 
dest_id text, 
merchant_id text 
) 

:

Answer 1

검색어 1처럼 CQL3,이 보이는, 매우 간단합니다 그리고/또는 상황이 아님)

source_id/destination_id의 정확한 값으로 쿼리하기 때문에 이러한 열의 조합을 파티션 키로 사용하는 것이 가장 이상적입니다. 그것들은 하위 카디널리티 칼럼이기 때문에 울퉁불퉁 한 파티셔닝과 관련된 문제가 발생할 수 있지만, 노드 수에 대한 추가 정보를 제공했기 때문에 source_id + destination_id가이 테이블의 수용 가능한 파티션 키라는 사실을 우리는 확신 할 수 있습니다 각 열에 약 10 개의 고유 한 값이있는 경우 결합하면 약 100 개의 고유 한 값이됩니다. 더 큰 클러스터에서는 이것이 이상적인 데이터 분배가 아니며 우리는 파티션 키에 임시 버킷을 추가하려고 할 수 있지만 4 노드 클러스터의 경우에는 여기에 문제가 없을 수 있습니다.

데이터 범위로 쿼리하려는 경우 tx_time 열을 클러스터링 열로 포함하고자합니다. 또한 상인이 주문한 결과를보고 싶기 때문에 클러스터링 열이 필요합니다. 마지막으로 기본 키가 개별 트랜잭션을 고유하게 식별하도록하기 위해 tx_id가 마지막 클러스터링 열이어야합니다. 이 파티션은 매우 넓은 될 수 있다고

create table tx_by_merchant(
tx_id uuid, 
tx_time timestamp, 
source_id text, 
dest_id text, 
merchant_id text, 
primary key((source_id, dest_id), tx_time, merchant_id, tx_id) 
) 

주, 그래서을들을 나누는 파티션 키에 년 + 달 보충 열을 추가하는 것이 좋습니다 수 있습니다 : 그래서 쿼리 2의 표처럼 보일 수 있습니다 비트. 또한 주문을 취소해야하는 경우 WITH CLUSTERING ORDER 절을 살펴보십시오.

단일 기본 키로 고유하게 식별 된 행을 검색하는 쿼리는 매우 빠릅니다. 매우 넓은 파티션에서 가져 오는 쿼리는 다소 느려질 수 있지만 보조 인덱스로 동일한 작업을 수행하는 것보다 더 빠릅니다.