4.1 설명
Apache Cassandra 는 NoSQL 시스템 클래스에 속하는 분산 데이터베이스 관리 시스템으로 해시 형식으로 제공되는 대용량 데이터 어레이의 확장성과 안정성이 뛰어난 스토리지를 생성하도록 설계되었습니다.
처음에 이 프로젝트는 Facebook 내부에서 개발되었고 2009년에 Apache Software Foundation의 날개 아래로 이전되었으며 이 조직은 계속해서 프로젝트를 개발하고 있습니다. Cassandra 기반의 산업용 솔루션은 Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Huawei, Netflix, Apple, Instagram, GitHub, Twitter 및 Spotify와 같은 회사에 서비스를 제공하기 위해 배포됩니다. 2011년까지 Cassandra에서 단일 데이터베이스를 제공하는 가장 큰 서버 클러스터에는 400개 이상의 시스템이 있었고 300TB 이상의 데이터가 포함되었습니다.
Java 언어 로 작성되었으며 DynamoDB와 유사한 분산 해시 시스템을 구현하여 데이터 볼륨이 증가함에 따라 거의 선형 확장성을 제공합니다. 여러 수준의 중첩으로 해시를 저장할 수 있다는 점에서 키-값 쌍에만 데이터를 저장하는 MemcacheDB와 같은 시스템과 다른 열 계열을 기반으로 하는 데이터 저장 모델을 사용합니다.
내결함성 DBMS의 범주에 속합니다. 데이터베이스에 저장된 데이터는 분산 네트워크의 여러 노드에 자동으로 복제되거나 여러 데이터 센터에 고르게 분산됩니다. 노드에 오류가 발생하면 다른 노드에서 해당 기능을 즉석에서 선택하여 클러스터에 새 노드를 추가하고 Cassandra 버전을 업데이트합니다. 추가 수동 개입 및 다른 노드의 재구성 없이 즉석에서 수행됩니다.
그러나 로드 밸런싱의 품질을 유지하기 위해 기존 노드를 포함하여 각 노드에 대한 키(레이블)를 다시 생성하는 것이 좋습니다. 노드 수가 여러 번(2배, 3배 등) 증가하는 경우 기존 노드에 대한 키 생성을 피할 수 있습니다.
4.2 데이터 모델
Cassandra 용어에서 애플리케이션은 관계형 모델의 데이터베이스 스키마 개념에 해당하는 키스페이스와 함께 작동합니다. 이 키스페이스는 관계형 테이블의 개념에 해당하는 여러 열 패밀리를 포함할 수 있습니다.
차례로 열 패밀리에는 레코드(행)의 키(행 키)를 사용하여 결합되는 열(열)이 포함됩니다. 열은 이름(열 이름), 타임스탬프(타임스탬프) 및 값(값)의 세 부분으로 구성됩니다. 레코드 내의 열은 순서가 지정됩니다. 관계형 데이터베이스와 달리 레코드(및 데이터베이스 측면에서 행)에 다른 레코드와 동일한 이름을 가진 열이 포함되는지 여부에 대한 제한이 없습니다.
컬럼 패밀리는 여러 종류가 있을 수 있지만 이 문서에서는 이 세부 정보를 생략합니다. 또한 최신 버전의 카산드라에서는 CQL 언어를 사용하여 데이터(DDL, DML)를 정의하고 변경하는 쿼리를 실행할 수 있을 뿐만 아니라 보조 인덱스를 생성할 수 있게 되었습니다.
cassandra에 저장된 특정 값은 다음으로 식별됩니다.
- 키스페이스 는 애플리케이션(도메인)에 대한 바인딩입니다. 동일한 클러스터에서 다른 애플리케이션의 데이터를 호스팅할 수 있습니다.
- 컬럼 패밀리는 쿼리에 대한 바인딩입니다.
- 키는 클러스터 노드에 대한 바인딩입니다. 키는 저장된 열이 끝나는 노드를 결정합니다.
- 열 이름은 레코드의 속성에 대한 바인딩입니다. 하나의 항목에 여러 값을 저장할 수 있습니다.
각 값은 기록 중 충돌을 해결하는 데 사용되는 사용자 지정 숫자인 타임스탬프와 연결됩니다. 숫자가 클수록 최신 열이 고려되고 비교 시 이전 열을 덮어씁니다.
4.3 데이터 유형
데이터 유형별: 키스페이스 및 열 패밀리는 문자열(이름)입니다. 타임스탬프는 64비트 숫자입니다. 키, 열 이름 및 열 값은 바이트 배열입니다. Cassandra에는 데이터 유형의 개념도 있습니다. 이러한 유형은 열 패밀리를 생성할 때 개발자가 지정할 수 있습니다(선택 사항).
열 이름의 경우 이를 비교기라고 하고 값 및 키의 경우 유효성 검사기라고 합니다. 첫 번째는 열 이름에 허용되는 바이트 값과 정렬 방법을 정의합니다. 두 번째는 열 및 키 값에 유효한 바이트 값입니다.
이러한 데이터 유형이 설정되지 않은 경우 cassandra는 값을 저장하고 실제로 내부에 저장되기 때문에 바이트 문자열(BytesType)로 비교합니다.
- BytesType : 모든 바이트 문자열(검증 없음)
- AsciiType : ASCII 문자열
- UTF8Type : UTF-8 문자열
- IntegerType : 임의 크기의 숫자
- Int32Type : 4바이트 숫자
- LongType : 8바이트 숫자
- UUIDType : UUID 유형 1 또는 4
- TimeUUIDType : 유형 1 UUID
- DateType : 8바이트 타임스탬프 값
- BooleanType : 두 값: true = 1 또는 false = 0
- FloatType : 4바이트 부동 소수점 숫자
- DoubleType : 8바이트 부동 소수점 숫자
- DecimalType : 임의의 크기와 부동 소수점이 있는 숫자
- CounterColumnType : 8바이트 카운터
카산드라에서 모든 데이터 쓰기 작업은 항상 다시 쓰기 작업입니다. 즉, 이미 존재하는 동일한 키와 이름을 가진 컬럼이 컬럼 패밀리에 들어오고 타임스탬프가 저장된 것보다 크면 값을 덮어씁니다. . 기록된 값은 절대 변경되지 않으며 새 열만 새 값으로 들어옵니다.
카산드라에 쓰는 것이 읽는 것보다 빠릅니다. 이는 설계에서 취하는 접근 방식을 변경합니다. 데이터 모델 설계의 관점에서 카산드라를 고려하면 열 패밀리를 테이블이 아니라 구체화된 뷰(복잡한 쿼리의 데이터를 나타내는 구조)로 상상하는 것이 더 쉽습니다. 디스크.
쿼리를 사용하여 어떤 방식으로든 데이터를 구성하려고 시도하는 대신 이 쿼리에 필요할 수 있는 모든 것을 대상 패밀리에 저장하는 것이 좋습니다. 즉, 엔터티 간의 관계 또는 개체 간의 관계 측면에서 접근하는 것이 아니라 쿼리 측면에서 접근해야 합니다. 어떤 순서로 기록해야 하는지; 주요 데이터와 관련된 어떤 데이터를 함께 요청해야 하는지 - 이 모든 것은 이미 컬럼 패밀리에 저장되어 있어야 합니다.
레코드의 열 수는 이론적으로 20억으로 제한됩니다. 이것은 간단한 여담이며 자세한 내용은 디자인 및 최적화 기술에 대한 문서에서 찾을 수 있습니다. 이제 카산드라에 데이터를 저장하고 읽어오는 과정에 대해 알아보자.
GO TO FULL VERSION