Cassandra 간단한 데이터베이스 예제를 사용한 데이터 모델

이기는하지만 Cassandra 질의 언어는 다음과 유사합니다. SQL 언어에 따라 데이터 모델링 방법이 완전히 다릅니다.

In Cassandra, 잘못된 데이터 모델은 특히 사용자가 RDBMS 개념을 구현하려고 할 때 성능을 저하시킬 수 있습니다. Cassandra. 아래에 자세히 설명된 몇 가지 규칙을 염두에 두는 것이 가장 좋습니다.

Cassandra 데이터 모델 규칙

In Cassandra, 쓰기 비용은 비싸지 않습니다. Cassandra 조인, 그룹화 기준, OR 절, 집계 등을 지원하지 않습니다. 따라서 데이터를 완전히 검색할 수 있는 방식으로 저장해야 합니다. 따라서 데이터를 모델링하는 동안 이러한 규칙을 염두에 두어야 합니다. Cassandra.

쓰기 횟수 최대화

In Cassandra, 쓰기는 매우 저렴합니다. Cassandra 이 시스템은 높은 쓰기 성능에 최적화되어 있습니다. 따라서 쓰기 횟수를 최대화하여 읽기 성능과 데이터 가용성을 향상시키십시오. 데이터 쓰기와 데이터 읽기 사이에는 상충 관계가 있습니다. 그러므로 데이터 쓰기 횟수를 최대화하여 데이터 읽기 성능을 최적화하십시오.

데이터 중복 극대화

데이터 비정규화와 데이터 복제는 사실상 Cassandra. 디스크 공간은 메모리, CPU 처리 및 IO 작업보다 더 비싸지 않습니다. Cassandra 분산 데이터베이스이므로 데이터 복제를 통해 즉각적인 데이터 가용성이 보장되고 단일 장애 지점이 발생하지 않습니다.

Cassandra 데이터 모델링 목표

데이터를 모델링하는 동안 다음 목표를 가져야 합니다. Cassandra:

데이터를 주변에 고르게 분산시킵니다. Cluster

각 노드에 동일한 양의 데이터가 필요합니다. Cassandra Cluster데이터는 기본 키의 첫 번째 부분인 파티션 키를 기준으로 여러 노드에 분산됩니다. 따라서 클러스터 전체에 데이터를 고르게 분산시키려면 카디널리티가 높은 열을 파티션 키로 선택하는 것이 좋습니다.

데이터를 쿼리하는 동안 읽는 파티션 수 최소화

파티션은 동일한 파티션 키를 가진 레코드 그룹입니다. 읽기 쿼리가 실행되면 서로 다른 파티션의 서로 다른 노드에서 데이터를 수집합니다.

파티션이 많으면 쿼리 데이터를 수집하기 위해 이러한 모든 파티션을 방문해야 합니다.

파티션을 생성하지 말아야 한다는 의미는 아닙니다. 데이터 용량이 매우 큰 경우, 단일 파티션에 그 방대한 양의 데이터를 저장할 수 없습니다. 단일 파티션으로는 속도가 저하될 것입니다.

따라서 균형 잡힌 수의 파티션을 선택하십시오.

좋은 기본 키 입력 Cassandra

위의 두 목표는 하나의 결정으로 귀결되므로, 아래 두 스키마는 키가 부적절한 경우와 적절한 경우의 동일한 테이블을 보여줍니다.

예를 들어 어떤 기본 키가 적합한지 알아보겠습니다.

다음은 MusicPlaylist 테이블입니다.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY (SongId, SongName)
);

위의 예에서 MusicPlaylist 테이블은

• SongId는 파티션 키입니다.
• SongName은 클러스터링 열입니다
• 데이터는 곡명(SongName)을 기준으로 클러스터링됩니다. 곡 ID(SongId)당 하나의 파티션만 생성되며, 각 곡은 고유한 식별자를 가지므로 각 파티션에는 하나의 행만 저장됩니다.

잘못된 기본 키로 인해 이 데이터 모델에서는 데이터 검색 속도가 느려집니다.

여기에 또 다른 테이블 MusicPlaylist가 있습니다.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY ((SongId, Year), SongName)
);

위의 예에서 MusicPlaylist 테이블은

• SongId와 Year는 파티션 키입니다.
• SongName은 클러스터링 열입니다.
• 데이터는 SongName을 기준으로 클러스터링됩니다. 이 테이블에서 매년 새로운 파티션이 생성됩니다. 그 해의 모든 노래는 같은 노드에 있습니다. 이 기본 키는 데이터에 매우 유용합니다.

이 데이터 모델을 사용하면 데이터 검색이 빨라집니다.

데이터 모델링 Cassandra

쿼리를 모델링하는 동안 다음 사항을 명심해야 합니다.

지원하려는 쿼리 결정

우선, 원하는 쿼리가 무엇인지 결정하세요.

예를 들어, 필요한가요?

• 조인
• 그룹화 기준
• 어떤 열 등을 필터링합니다.

쿼리에 따라 테이블 만들기

쿼리에 따라 테이블을 만듭니다. 귀하의 쿼리를 만족시킬 테이블을 생성하십시오. 최소한의 파티션을 읽어야 하는 방식으로 테이블을 생성해 보십시오.

이어지는 세 섹션에서는 거의 모든 스키마에서 발견되는 세 가지 관계 유형에 해당 원칙을 적용합니다.

일대일 관계 처리 Cassandra

일대일 관계는 두 테이블이 일대일 대응을 갖는다는 것을 의미합니다. 예를 들어, 학생은 한 과목만 등록할 수 있는데, 특정 학생이 어떤 과목에 등록했는지 검색하고 싶습니다.

따라서 이 경우 테이블 스키마는 과목명, 학생의 학년 번호, 학생 이름 등 특정 과목에 해당하는 학생의 모든 세부 정보를 포함해야 합니다.

위 다이어그램은 학생 한 명이 정확히 하나의 강좌에 대응하기 때문에 쿼리를 처리하는 단일 테이블을 보여줍니다.

CREATE TABLE Student_Course (
    Student_rollno int PRIMARY KEY,
    Student_name text,
    Course_name text
);

Student_rollno가 파티션 키이므로, 학번으로 조회하면 정확히 하나의 파티션만 읽게 됩니다.

일대다 관계 처리 Cassandra

일대다 관계는 두 테이블 간에 일대다 대응이 있음을 의미합니다.

예를 들어, 한 과목을 많은 학생들이 공부할 수 있습니다. 특정 과목을 수강하고 있는 모든 학생을 검색하고 싶습니다.

따라서 과목명을 조회하면 특정 과목을 수강할 학생의 이름이 많이 나올 것입니다.

여기서 과목명은 파티션 키가 되어 해당 과목의 모든 학생이 같은 파티션에 속하게 되고, 학번은 클러스터링 열이 되어 각 학생이 서로 다른 행으로 유지됩니다.

CREATE TABLE Student_Course (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

다음 쿼리를 통해 특정 과목의 모든 학생을 검색할 수 있습니다.

SELECT * FROM Student_Course WHERE Course_name = 'Course Name';

다대다 관계 처리 Cassandra

다대다 관계는 두 테이블 사이에 다대다 대응이 있음을 의미합니다.

예를 들어, 한 과목을 여러 학생이 공부할 수도 있고, 한 학생이 여러 과목을 공부할 수도 있습니다.

특정 과목을 수강하고 있는 모든 학생을 검색하고 싶습니다. 또한, 특정 학생이 수강하고 있는 과목 전체를 검색하고 싶습니다.

이 경우, 저는 두 개의 테이블을 만들겠습니다. 즉, 문제를 두 가지 경우로 나누는 것입니다. 이것은 중복 규칙을 가장 명확하게 보여주는 예입니다. 동일한 사실이 두 번 기록되어 각 쿼리가 하나의 파티션을 읽도록 하는 것입니다.

먼저, 특정 학생의 강좌를 찾을 수 있는 테이블을 생성하겠습니다.

CREATE TABLE Student_Course (
    Student_rollno int,
    Course_name text,
    Student_name text,
    PRIMARY KEY (Student_rollno, Course_name)
);

다음 쿼리를 사용하면 특정 학생이 수강한 모든 과목을 찾을 수 있습니다.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

둘째, 특정 과목을 수강하는 학생 수를 확인할 수 있는 테이블을 생성하겠습니다.

CREATE TABLE Course_Student (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

다음 쿼리를 통해 특정 과목의 학생을 찾을 수 있습니다.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

학생이 강좌에 등록할 때마다 두 테이블 모두에 기록되어야 하며, 일반적으로 단일 로그 배치 내에서 기록되므로 두 복사본이 동기화된 상태를 유지합니다.

공통의 Cassandra 데이터 모델링 실수

대부분의 부실한 스키마는 몇 가지 오류를 반복하며, 각각의 스키마는 trac관계형 디자인에서 이어받은 습관으로 돌아가는 것입니다.

• 무한 파티션: 국가 이름과 같은 파티션 키를 선택하면 수백만 개의 행이 하나의 파티션에 저장됩니다. 파티션 크기를 적절하게 유지하려면 (국가, 월)과 같은 시간 버킷을 추가하세요.
• 카디널리티가 매우 낮은 키: 상태 플래그처럼 가능한 값이 몇 개밖에 없는 파티션 키는 모든 트래픽을 몇몇 노드에 집중시키고 나머지는 유휴 상태로 둡니다.
• 쿼리가 작동하도록 하려면 ALLOW FILTERING을 사용해야 합니다. 모든 파티션을 스캔하여 모델링 문제를 숨깁니다. 쿼리에 필요한 경우 스키마에 다른 테이블이 필요합니다.
• 쿼리 대신 엔티티를 모델링합니다. 학생 테이블과 강좌 테이블을 만든 다음 애플리케이션에서 이들을 결합하려고 하면 설계 목적에 어긋납니다.
• 잦은 삭제 및 덮어쓰기: 각 삭제 작업은 압축으로 제거될 때까지 읽고 건너뛰어야 하는 툼스톤을 기록하므로 자주 사용되는 파티션의 읽기 속도가 느려집니다.

이러한 사항을 피하면 스키마가 이 페이지 상단에 명시된 규칙 및 아래에 요약된 관계적 대조와 일치하게 유지됩니다.

RDBMS와 RDBMS의 차이점 Cassandra 데이터 모델링

이러한 스키마 결정은 실제 적용에서 다음과 같이 나타납니다. Cassandra 테이블 키 스페이스 자습서.

자주 묻는 질문