paint-brush
Cassandra: 즉시 사용 가능한 확장성이 뛰어난 데이터베이스~에 의해@therealone
770 판독값
770 판독값

Cassandra: 즉시 사용 가능한 확장성이 뛰어난 데이터베이스

~에 의해 Denis Larionov9m2023/12/27
Read on Terminal Reader

너무 오래; 읽다

이 문서에서는 확장성이 뛰어나고 분산된 와이드 컬럼 데이터베이스인 Cassandra에 대한 개요를 제공합니다. Cassandra는 가용성과 파티션 허용성을 우선시하도록 설계되어 일관성이 중요한 요구 사항이 아닌 애플리케이션에 적합합니다. 높은 처리량과 더 빠른 쓰기 작업을 지원합니다.
featured image - Cassandra: 즉시 사용 가능한 확장성이 뛰어난 데이터베이스
Denis Larionov HackerNoon profile picture

Cassandra는 분산형, 분산형, 확장 가능하고 가용성이 높은 와이드 컬럼 데이터베이스입니다.

CAP 정리 측면에서 Cassandra는 AP(가용성 및 파티션 허용 오차)를 나타냅니다.


카산드라 벤 다이어그램


이는 Cassandra가 모든 노드를 사용할 수 없는 경우에도 모든 클라이언트가 데이터를 찾을 수 있고 부분적인 네트워크 오류가 발생하면 예상대로 작동하는 것을 선호한다는 의미입니다. 그러나 이는 가용성 및 파티션 허용 오차 때문에 데이터의 일관성이 손상될 수 있음을 의미하기도 합니다. 사용자는 데이터를 볼 수 있지만 한동안은 오래되었을 수 있습니다.


Cassandra는 높은 처리량과 더 빠른 쓰기 작업을 달성하도록 설계되었습니다.


그리고 Cassandra의 가용성을 높이는 것은 바로 일관성을 희생하는 것입니다.

기본적으로 Cassandra는 최종 일관성을 갖도록 설계되었습니다. 즉, 강력한 일관성을 제공하지 않을 수 있습니다. 따라서 Cassandra는 일관성이 중요한 요구 사항이 아닌 애플리케이션에 적합합니다. 그러나 강력한 일관성을 제공하도록 Cassandra를 구성할 수 있지만 이는 성능에 영향을 미칠 수 있습니다.

NoSQL 데이터베이스인 Cassandra는 테이블 조인, 외래 키 또는 쿼리하는 동안 WHERE 절에 기본 키 이외의 열을 추가하는 기능을 지원하지 않습니다. Cassandra 사용을 선택하기 전에 이러한 제한 사항을 고려해야 합니다.

카산드라 빌딩 블록

  • 열(Column) : 열은 키-값 쌍을 나타내며 데이터 구조의 기본 단위로 사용됩니다.
  • Row : 기본 키가 참조하는 열의 컨테이너 역할을 합니다.
  • Keyspace : 하나 이상의 Cassandra 노드에 걸쳐 있는 테이블의 컨테이너 역할을 합니다.
  • 클러스터 : Cassandra 내의 키스페이스 컨테이너입니다.
  • Node : Cassandra 인스턴스를 실행하는 컴퓨터 시스템을 나타냅니다. 노드는 물리적 호스트, 클라우드의 머신 인스턴스 또는 Docker 컨테이너일 수 있습니다.

카산드라가 데이터를 저장하는 방법

Cassandra는 데이터를 컬럼 패밀리로 저장합니다. 기본 키가 참조하는 열의 컨테이너 역할을 합니다.

그래, 내가 했어!


열 패밀리의 행에는 키와 값이 있는 여러 열이 포함되며 행 키는 기본 키 역할을 합니다.

컬럼 패밀리 행


열 패밀리는 각 행 키에 대해 서로 다른 열 집합을 저장할 수 있습니다.

다양한 열 세트 저장

Cassandra는 null 값이 있는 열을 저장하지 않으므로 상당한 저장 공간을 절약하는 데 도움이 됩니다.

카산드라의 기본 키는 무엇입니까?

기본 키는 테이블의 각 행을 고유하게 식별합니다. Cassandra에서 기본 키는 두 부분으로 구성됩니다.

카산드라의 기본 키


Cassandra에서 파티션 키는 데이터를 저장하는 노드를 결정하고, 클러스터링 키는 노드 내에 데이터가 저장되는 방법을 결정합니다. 예를 들어 다음과 같은 테이블이 있다고 가정해 보겠습니다.

PRIMARY KEY (city_id, event_id) . 이 기본 키는 두 개의 열로 표시되는 두 부분으로 구성됩니다.


1. city_id 파티션 키 역할을 합니다. 즉, 데이터는 city_id 필드를 기준으로 분할되어 동일한 city_id 가진 모든 행이 동일한 노드에 저장됩니다.

2. event_id 클러스터링 키 역할을 합니다. 각 노드 내에서 데이터는 event_id 열을 기준으로 정렬된 순서로 구성 및 저장됩니다.

클러스터링 키는 노드 내 데이터의 저장 배열을 결정합니다. 여러 클러스터링 키를 가질 수 있으며 파티션 키 뒤에 나열된 모든 열을 클러스터링 열이라고 합니다. 클러스터링 열은 노드에서 데이터가 구성되는 순서를 정의합니다.

클러스터링 키

파티션 키 = "Paris"인 모든 행은 event_id 열의 값에 따라 정렬되어 동일한 노드에 저장됩니다.

즉시 사용 가능한 데이터 파티셔닝

Cassandra는 데이터베이스에 저장된 데이터 양이 많아질 때 읽기/쓰기 작업의 지연 시간을 줄이고 시스템의 처리량을 높이기 위해 Consistent Hashing 기반의 데이터 파티셔닝을 제공합니다.


Cassandra의 파티셔너는 Consistency Hash 링 전체에 데이터가 배포되는 방식을 결정하는 역할을 담당합니다. 데이터가 Cassandra 클러스터에 삽입되면 파티셔너는 파티션 키 에 해싱 알고리즘을 적용합니다. 이 해싱 알고리즘의 결과에 따라 데이터가 속하는 범위가 결정되고 데이터가 저장될 노드가 결정됩니다.

Cassandra의 파티셔너


코디네이터 노드

Cassandra에서 각 노드는 가십 프로토콜을 통해 다른 노드의 토큰 할당을 인식하므로 모든 노드가 다른 노드 범위에 대한 요청을 처리할 수 있습니다. 따라서 클라이언트는 모든 노드에 연결하여 쿼리 읽기 또는 쓰기를 시작할 수 있습니다.


요청을 수신하는 노드를 코디네이터 라고 하며 클러스터의 모든 노드가 될 수 있습니다. 키가 코디네이터의 범위에 속하지 않으면 해당 범위를 담당하는 복제본으로 요청이 전달됩니다.

코디네이터 노드

복제

Cassandra는 고가용성을 보장하기 위해 여러 노드에 걸쳐 데이터를 복제합니다. Cassandra의 각 노드는 특정 데이터 범위에 대한 복제본 역할을 합니다. Cassandra는 데이터의 여러 복사본을 서로 다른 복제본에 분산함으로써 하나의 노드를 사용할 수 없는 경우 다른 복제본이 해당 데이터 범위에 대한 쿼리를 처리할 수 있도록 합니다. 두 가지 설정이 복제 프로세스에 영향을 미칩니다.

복제


복제 요소는 동일한 데이터의 복사본을 저장할 노드 수를 결정합니다. 복제 인수가 3인 클러스터에서는 각 행이 세 개의 서로 다른 노드에 저장됩니다.

Cassandra의 각 키스페이스는 서로 다른 복제 요소를 가질 수 있습니다.

Cassandra에서는 파티션 키의 해시를 기반으로 범위를 소유한 노드에 첫 번째 복제본이 할당됩니다. 나머지 복제본은 시계 방향으로 연속 노드에 배치됩니다. Cassandra는 두 가지 복제 전략을 사용하여 복제본을 담당할 노드를 결정합니다.

간단한 복제 전략

이 전략에서는 첫 번째 복제본은 파티셔너가 결정한 노드에 배치되고, 후속 복제본은 시계 방향으로 다음 노드에 배치됩니다.

간단한 복제 전략

이 복제 전략은 단일 데이터 센터 클러스터에만 적용 가능합니다.

네트워크 토폴로지 전략

데이터의 완전한 손실에 대한 복원력을 보장하기 위해 동일한 데이터 센터 내의 추가 복제본은 다른 데이터 센터의 첫 번째 노드에 도달할 때까지 링을 따라 시계 방향으로 이동하여 배치됩니다. 이러한 배열은 전력, 냉각 또는 네트워크 문제로 인해 동일한 데이터 센터 내에서 일반적으로 발생하는 동시 오류의 영향을 완화하는 데 도움이 됩니다.

네트워크 토폴로지 전략

다중 데이터 센터 구성의 경우 네트워크 토폴로지 전략을 고려해야 합니다. 이 접근 방식을 사용하면 각 데이터 센터에 대해 다양한 복제 요소를 지정할 수 있으므로 각 특정 위치에 배치할 복제본 수를 제어할 수 있습니다.

카산드라를 사용해야 하는 경우

Cassandra는 대량의 데이터를 처리해야 하고 일관성보다 데이터 가용성을 우선시하는 애플리케이션에 탁월합니다. 다음과 같은 경우에 적합합니다 .


1. 사물 인터넷(IoT) 애플리케이션 : Cassandra는 장치 및 센서에서 생성되는 대량의 데이터를 처리할 수 있기 때문에 IoT 환경에 이상적인 선택입니다. 분산 아키텍처를 통해 지리적으로 분산된 대규모 데이터를 관리할 수 있습니다.


2. 시계열 데이터 : 측정항목, 모니터링 시스템, 원격 측정 데이터 등 시계열 데이터를 처리하는 애플리케이션은 Cassandra의 효율적인 쓰기 작업과 수평 확장성의 이점을 누릴 수 있습니다. 이러한 기능은 타임스탬프가 지정된 방대한 양의 데이터를 저장하고 관리하는 데 중요합니다.


3. 웹 및 모바일 애플리케이션 : Cassandra는 높은 처리량과 낮은 대기 시간의 데이터 액세스를 제공하므로 상당한 양의 데이터를 생성하는 대규모 사용자 기반이 있는 웹 및 모바일 플랫폼에 적합합니다. 여기에는 소셜 미디어 플랫폼, 게임 앱, 전자상거래 사이트가 포함됩니다.


4. 실시간 빅 데이터 분석 : Cassandra는 빅 데이터의 실시간 처리를 지원하므로 대규모 데이터 세트에서 즉각적인 통찰력이 필요한 애플리케이션에 귀중한 선택입니다. 추천 엔진과 사기 탐지 시스템 등이 그 예입니다.


5. 분산 데이터 웨어하우스 : 대규모 분산 데이터 세트를 보유한 기업은 Cassandra를 데이터 웨어하우스 솔루션으로 활용할 수 있습니다. 여러 데이터 센터에 걸쳐 데이터를 복제하는 기능은 고가용성과 재해 복구를 보장합니다.


6. 메시징 시스템 : Cassandra의 높은 쓰기 및 읽기 처리량은 이벤트 로깅, 감사 추적 또는 메시지 대기열과 같은 높은 데이터 볼륨을 처리하는 메시징 시스템에 매우 적합합니다.


7. 개인화 및 콘텐츠 관리 시스템 : 콘텐츠 관리 시스템과 같이 대규모로 개인화된 콘텐츠 제공이 필요한 애플리케이션은 맞춤형 콘텐츠를 다수의 사용자에게 동시에 제공하는 Cassandra의 속도와 확장성의 이점을 누릴 수 있습니다.


8. 지리적으로 분산된 애플리케이션 : Cassandra는 여러 데이터 센터를 지원하므로 지리적으로 분산된 데이터가 필요한 애플리케이션에 탁월한 선택입니다. 다양한 지역에서 짧은 지연 시간의 데이터 액세스를 보장하고 높은 복원력을 제공합니다.

카산드라를 사용하지 말아야 할 경우

Apache Cassandra는 강력하고 확장 가능하지만 모든 애플리케이션이나 사용 사례에 적합하지는 않을 수 있습니다. 트랜잭션이 많은 애플리케이션, 복잡한 쿼리 및 강력한 일관성이나 빠른 스키마 변경이 필요한 시나리오에는 적합하지 않습니다. 이러한 경우에는 기존의 관계형 데이터베이스 관리 시스템(RDBMS) 또는 기타 NoSQL 솔루션이 더 적합할 수 있습니다. Cassandra가 최적의 선택이 아닐 수 있는 몇 가지 시나리오는 다음과 같습니다.


  1. 소규모 프로젝트 : Cassandra의 복잡성과 리소스 요구 사항은 소규모 프로젝트나 데이터 세트가 제한된 애플리케이션의 경우 과도할 수 있습니다. 더 단순한 데이터베이스 솔루션은 더 비용 효율적이고 관리하기 쉬운 대안을 제공할 수 있습니다.


  2. ACID 속성이 필요한 트랜잭션 시스템 : Cassandra는 ACID(원자성, 일관성, 격리, 내구성) 속성을 완전히 지원하지 않습니다. 애플리케이션에 일반적으로 은행이나 금융 시스템에서 볼 수 있는 복잡한 트랜잭션이 필요한 경우 기존 RDBMS가 더 적합할 수 있습니다.


  3. 무거운 쿼리 및 집계 조인 : 애플리케이션이 조인, 하위 쿼리 또는 복잡한 집계에 크게 의존하는 경우 Cassandra가 가장 적합한 선택이 아닐 수 있습니다. 빠른 쓰기 및 읽기용으로 설계되었지만 복잡한 쿼리 처리용으로는 설계되지 않았습니다.


  4. 강력한 일관성 요구 사항이 있는 데이터 : Cassandra는 최종 일관성을 제공하지만 모든 읽기 및 쓰기 작업에 강력한 일관성이 필요한 사용 사례에는 적합하지 않을 수 있습니다.


  5. 단일 클러스터에서 대기 시간이 짧은 읽기 및 쓰기 : Cassandra는 다중 노드 분산 환경에서 잘 작동하지만 대기 시간이 짧은 읽기 및 쓰기가 필요한 단일 노드 또는 소규모 클러스터 배포에는 최적의 선택이 아닐 수 있습니다.


  6. Blob 저장소 : Cassandra는 이미지나 비디오와 같은 대규모 바이너리 개체(BLOB)를 저장하는 데 최적화되어 있지 않습니다. 다른 스토리지 솔루션은 대형 Blob을 효율적으로 처리하는 데 더 적합합니다.


  7. 임시 쿼리가 필요한 애플리케이션 : Cassandra의 쿼리 기능은 본격적인 SQL 데이터베이스에 비해 제한됩니다. 임시 쿼리 및 보고에 크게 의존하는 애플리케이션에는 적합하지 않습니다.

    Cassandra에서 테이블 디자인은 데이터에 액세스하는 방식과 밀접하게 연결되어 있으며 데이터 엔터티 간의 관계에만 초점을 맞추기보다는 쿼리 패턴을 강조합니다. 이는 스키마 설계가 정규화 원칙을 기반으로 하는 RDBMS의 접근 방식과 다릅니다.


  8. 신속한 스키마 진화 : 애플리케이션에서 데이터베이스 스키마를 자주 변경해야 하는 경우 Cassandra의 스키마 관리는 기존 RDBMS 시스템이나 기타 NoSQL 솔루션에 비해 유연성이 떨어질 수 있습니다.


  9. 복잡한 쿼리, 조인 및 기록 데이터 분석을 포함하는 데이터 웨어하우스 애플리케이션 : Cassandra는 쓰기가 많은 워크로드 및 실시간 데이터 액세스에 적합하지만 복잡한 쿼리가 필요한 데이터 웨어하우징 시나리오에는 가장 적합한 선택이 아닐 수 있습니다. 조인 및 기록 데이터 분석.

요약

이 문서에서는 확장성이 뛰어나고 분산된 와이드 컬럼 데이터베이스인 Cassandra에 대한 개요를 제공합니다. Cassandra는 가용성과 파티션 허용성을 우선시하도록 설계되어 일관성이 중요한 요구 사항이 아닌 애플리케이션에 적합합니다. 높은 처리량과 더 빠른 쓰기 작업을 지원합니다.


Cassandra의 빌딩 블록에는 열, 행, 키스페이스, 클러스터 및 노드가 포함됩니다. 열은 키-값 쌍을 나타내고, 행은 기본 키가 참조하는 열에 대한 컨테이너 역할을 하며, 키스페이스는 여러 노드에 걸쳐 있는 테이블에 대한 컨테이너 역할을 하고, 클러스터에는 키스페이스가 포함되어 있으며, 노드는 Cassandra 인스턴스를 실행하는 컴퓨터 시스템을 참조합니다.


Cassandra는 기본 키가 참조하는 열의 컨테이너인 열 패밀리에 데이터를 저장합니다. 일관된 해싱을 통해 데이터 분할이 이루어지므로 대기 시간이 줄어들고 처리량이 늘어납니다. 파티셔너는 일관성 해시 링 전체에 데이터를 배포하고 코디네이터 노드는 읽기 및 쓰기 쿼리를 처리합니다.


Cassandra는 고가용성을 위한 복제를 제공합니다. 데이터의 복제본은 여러 노드에 저장되므로 노드를 사용할 수 없는 경우 복제본에서 쿼리를 처리할 수 있습니다. 복제 요소와 전략에 따라 복제본 수와 이를 담당하는 노드가 결정됩니다.


Cassandra는 확장성 및 고가용성과 같은 이점을 제공하지만 제한 사항이 있습니다. 테이블 조인, 외래 키 또는 쿼리 중에 WHERE 절에 기본 키 이외의 열을 추가하는 기능을 지원하지 않습니다.


전반적으로 Cassandra는 확장성이 뛰어난 애플리케이션, 특히 강력한 일관성보다 가용성과 파티션 허용성을 우선시하는 애플리케이션을 위한 강력한 데이터베이스 솔루션입니다.

Cassandra의 몇 가지 흥미로운 측면을 다음 기사에서 다루겠습니다. 놓치지 않도록 구독해주세요 !

건배!