Cassandra 쿼리 언어(CQL): 삽입, 업데이트 및 삭제
⚡ 스마트 요약
Cassandra 쿼리 언어는 SQL과 유사한 구문을 사용하지만 내부적으로는 다른 의미 체계를 가진 삽입, 업데이트, 삭제 및 읽기 작업을 처리합니다. 이 페이지에서는 각 문, 삽입과 업데이트를 통합하는 업서트(upsert) 동작, 그리고 WHERE 절의 실제 한계에 대해 설명합니다.

데이터 삽입
The Cassandra insert 문은 데이터를 씁니다. Cassandra 행 형식의 열입니다. Cassandra 삽입 쿼리는 사용자가 제공한 열만 저장합니다. 반드시 기본 키 열만 지정해야 합니다.
주어진 값이 아닌 경우 공간을 차지하지 않습니다. 삽입 후에는 결과가 반환되지 않습니다.
통사론
INSERT INTO KeyspaceName.TableName (ColumnName1, ColumnName2, ColumnName3) VALUES (Column1Value, Column2Value, Column3Value);
예시
다음은 실행된 스냅샷입니다. Cassandra 하나의 레코드를 삽입할 테이블 쿼리에 삽입 Cassandra 테이블 '학생'.
INSERT INTO University.Student (RollNo, Name, dept, Semester) VALUES (2, 'Michael', 'CS', 2);
명령을 성공적으로 실행한 후 Insert into Cassandra, 하나의 행이 Cassandra RollNo 2의 학생, 이름 Michael, 부서 CS 및 2학기 학생.
다음은 현재 데이터베이스 상태의 스냅샷입니다.
데이터 업데이트
Cassandra 화를 낸다. Upsert는 다음을 의미합니다. Cassandra 기본 키가 아직 존재하지 않으면 행을 삽입하고, 기본 키가 이미 존재하는 경우 해당 행을 업데이트합니다.
이는 실질적으로 중요한 결과를 초래합니다. INSERT 문은 중복 키 오류를 보고하지 않으므로, 실수로 다시 삽입하면 경고 없이 기존 행이 덮어쓰여집니다. 이러한 상황을 방지해야 할 경우, IF NOT EXISTS를 추가하여 해당 문을 가벼운 트랜잭션으로 만들 수 있습니다.
INSERT INTO University.Student (RollNo, Name) VALUES (2, 'Michael') IF NOT EXISTS;
경량 트랜잭션은 복제본 간의 합의 과정을 거치므로 일반 쓰기 작업보다 속도가 상당히 느리며, 검증이 정말 필요한 경우에만 사용해야 합니다.
데이터 업데이트
The Cassandra 업데이트 쿼리는 다음의 데이터를 업데이트하는 데 사용됩니다. Cassandra 테이블. 데이터를 업데이트한 후 결과가 반환되지 않으면 데이터가 성공적으로 업데이트되었음을 의미하고 그렇지 않으면 오류가 반환됩니다. 열 값은 'Where' 절로 데이터가 필터링되는 동안 'Set' 절에서 변경됩니다.
통사론
UPDATE KeyspaceName.TableName SET ColumnName1 = NewValue1, ColumnName2 = NewValue2 WHERE ColumnName = ColumnValue;
예시
다음은 데이터를 업데이트하기 전의 데이터베이스 상태를 보여주는 스크린샷입니다.
다음은 실행된 스냅샷입니다. Cassandra Student 테이블의 기록을 업데이트하는 업데이트 명령입니다.
UPDATE University.Student SET name = 'Hayden' WHERE rollno = 1;
업데이트 쿼리가 성공적으로 실행된 후 Cassandra 'Update Student'를 선택하면 학생 이름이 'Clark'에서 롤번호 1이 있는 'Hayden'으로 변경됩니다.
다음은 데이터 업데이트 후 데이터베이스 상태를 보여주는 스크린샷입니다.
upsert 동작 때문에 존재하지 않는 기본 키에 대한 UPDATE 작업은 실패하는 대신 해당 행을 생성합니다.
Cassandra 데이터 삭제
'삭제' 명령은 Student 테이블에서 전체 행 또는 일부 열을 제거합니다. 데이터가 삭제되면 테이블에서 즉시 삭제되지 않습니다. 대신 삭제된 데이터에는 삭제 표시가 표시되고 압축 후 제거됩니다.
통사론
DELETE FROM KeyspaceName.TableName WHERE ColumnName1 = ColumnValue;
위의 Cassandra 행 삭제 구문은 where 절의 데이터 필터링에 따라 하나 이상의 행을 삭제합니다.
DELETE ColumnName1, ColumnName2 FROM KeyspaceName.TableName WHERE ColumnName1 = ColumnValue;
위 구문은 테이블에서 일부 열을 삭제합니다.
예시
다음은 데이터를 삭제하기 전의 현재 데이터베이스 상태를 보여주는 스냅샷입니다.
다음은 Student 테이블에서 한 행을 제거하는 명령의 스냅샷입니다.
DELETE FROM University.Student WHERE rollno = 1;
CQL Delete 명령이 성공적으로 실행되면, student 테이블에서 rollno 값이 1인 행 하나가 삭제됩니다.
다음은 데이터 삭제 후 데이터베이스 상태를 보여주는 스냅샷입니다.
삭제 과정에서 노드가 오프라인 상태가 되더라도 복구 시 해당 행을 되살릴 수 없도록 하기 위해, 삭제 후에는 gc_grace_seconds(기본값 10일) 동안 툼스톤이 유지됩니다. 따라서 대용량 데이터를 삭제하면 이후 모든 읽기 작업에서 스캔해야 하는 마커가 남게 됩니다.
뭐 Cassandra 지원하지 않습니다
CQL은 SQL 구문을 차용하지만 관계형 실행 모델은 따르지 않으므로, 몇 가지 익숙한 구문이 다르게 동작하거나 아예 존재하지 않습니다.
- CQL은 테이블 간 조인을 지원하지 않습니다. 관련 데이터는 쓰기 시점에 하나의 테이블로 비정규화해야 합니다.
- CQL은 WHERE 절에서 OR 조건을 지원하지 않습니다. 단일 열에 대해 IN 절을 사용하거나, 별도의 쿼리를 실행하십시오.
- CQL은 UNION 또는 INTERSECT를 지원하지 않습니다.
- 기본 키가 아닌 열은 인덱스가 생성될 때까지 필터링할 수 없습니다.
- 크거나 작음 비교는 클러스터링 열에만 적용됩니다. 왜냐하면 디스크에서 정렬되는 열은 클러스터링 열뿐이기 때문입니다.
- LIKE 연산자를 사용한 패턴 매칭은 SASI 인덱스가 필요하며 일반 열에서는 사용할 수 없습니다.
오랫동안 제기되어 온 주장 하나를 바로잡아야 합니다. 집계 함수가 지원됩니다. 개수, 최소값, 최대값, 합계 및 AVG ~에 도착하다 Cassandra 2.2 및 GROUP BY 3.10 버전에 도착했습니다. 단, 가용성보다는 범위에 유의해야 합니다.
SELECT dept, COUNT(*) FROM University.Student WHERE RollNo = 1 GROUP BY dept;
위에서처럼 단일 파티션으로 제한하면 집계가 효율적입니다. 하지만 전체 테이블에 대해 실행하면 클러스터 전체 스캔이 되므로 집계가 필요하지 않습니다. Cassandra 임시 분석에는 여전히 적합하지 않으며, 이것이 바로 대규모 보고서 작성이 일반적으로 다른 곳으로 미뤄지는 이유입니다. Spark 또는 외부 창고.
Cassandra Where 절
In Cassandra, 데이터 검색은 민감한 문제입니다. 열이 필터링되었습니다. Cassandra 기본 키가 아닌 열에 인덱스를 생성합니다.
통사론
SELECT ColumnNames FROM KeyspaceName.TableName WHERE ColumnName1 = Column1Value AND ColumnName2 = Column2Value;
예시
- 다음은 데이터 필터링 없이 Student 테이블에서 데이터 검색을 보여주는 스냅샷입니다.
SELECT * FROM University.Student;
Student 테이블에서 두 개의 레코드가 검색됩니다.
- 다음은 데이터 필터링을 통해 Student에서 데이터 검색을 보여주는 스냅샷입니다. 하나의 레코드가 검색됩니다.
데이터는 이름 열을 기준으로 필터링됩니다. 이름이 일치하는 모든 레코드가 검색됩니다. Guru99.
SELECT * FROM University.Student WHERE name = 'Guru99';
WHERE 절이 참조할 수 있는 열을 규정하는 규칙은 기본 키에서 직접 파생됩니다.
- The 파티션 키 효율적인 쿼리를 위해서는 반드시 전체 값을 제공해야 합니다. 왜냐하면 이 값은 데이터가 저장된 노드를 식별하기 때문입니다.
- Cluster컬럼 그러면 제한될 수 있지만, 선언된 순서대로만 제한됩니다. 건너뛰기ping 하나는 거부되었습니다.
- 범위 비교는 참조된 마지막 클러스터링 열에 대해서만 허용되며, 이전 열에 대해서는 허용되지 않습니다.
- 모든 품종 다른 열 보조 색인이 필요하며, 이는 다음에서 다룹니다. 인덱스 생성 및 삭제 튜토리얼.
문의가 거부되면, Cassandra 종종 ALLOW FILTERING을 추가하라는 메시지가 나타납니다. 이는 해결책이라기보다는 경고로 받아들이세요. 모든 노드의 모든 파티션을 검사하는데, 스키마 변경이 거의 항상 올바른 대응입니다.










