BEZZANG DEV
블로그 이미지

Home

Write

Setting
Development/TIL

[TIL] Spring Data Cassandra와 Spring Data JPA의 차이? (NoSQL과 RDBMS의 차이)

bezzang_kim
|2024. 9. 28. 13:46

*chatGPT4o 의 답변입니다.

Q. does spring data cassandra has concept of transactional? what's difference in spring data jpa?

Spring Data Cassandra는 Spring Data JPA와 같은 방식으로 트랜잭션을 지원하지 않습니다. 두 기술에서 트랜잭션이 다르게 작동하는 이유와 차이점을 설명하겠습니다.

1. Spring Data JPA에서의 트랜잭션 지원

Spring Data JPA(관계형 데이터베이스를 기반으로 하는)는 @Transactional 애노테이션을 사용하여 트랜잭션을 완전히 지원합니다. 이는 관계형 데이터베이스가 기본적으로 ACID(Atomicity, Consistency, Isolation, Durability) 트랜잭션을 지원하기 때문입니다.

JPA 기반 애플리케이션에서는 트랜잭션을 통해:

  • 모든 데이터베이스 작업이 하나의 단위로 성공하거나 실패하도록 보장할 수 있습니다.
  • 일련의 데이터베이스 작업 중 오류가 발생하면 변경 사항을 롤백할 수 있습니다.
  • 하나의 트랜잭션에서 발생한 변경 사항을 다른 트랜잭션에서 격리할 수 있습니다.

JPA 트랜잭션의 예시:

@Transactional
public void saveOrder(Order order) {
    orderRepository.save(order);
    // 다른 데이터베이스 작업...
    // 만약 문제가 발생하면, 모든 변경 사항이 롤백됩니다.
}

2. Spring Data Cassandra에서의 트랜잭션 지원

Cassandra는 NoSQL 데이터베이스로, 관계형 데이터베이스와 같은 다중 행 트랜잭션 또는 전체 ACID 트랜잭션을 제공하지 않습니다. Cassandra는 고도로 분산되고, 파티셔닝되며, 확장 가능하도록 설계되었습니다. 하지만 분산된 특성 때문에 트랜잭션은 제한적입니다.

  • 단일 파티션 트랜잭션: Cassandra는 단일 파티션 내에서 원자성을 보장할 수 있습니다(즉, 동일한 파티션 키로 저장된 데이터에 대해서). 모든 작업이 같은 파티션 내에서 이루어질 경우, 해당 작업들은 함께 성공하거나 실패합니다.
  • 다중 파티션 트랜잭션 없음: Cassandra는 기본적으로 여러 파티션에 걸친 트랜잭션을 지원하지 않습니다. 이는 JPA와 달리 여러 행 또는 파티션에 걸친 작업을 트랜잭션으로 묶을 수 없다는 의미입니다.

Spring Data Cassandra에서:

  • 다중 파티션 간 글로벌 트랜잭션 지원 없음.
  • JPA처럼 @Transactional 애노테이션을 사용할 수 없습니다.
  • 여러 파티션에 걸친 트랜잭션 유사한 동작이 필요하면 애플리케이션 레벨에서 이를 관리해야 합니다(보상 트랜잭션, 나중에 일관성 보장 등).

Spring Data JPA와 Spring Data Cassandra의 트랜잭션 차이점

특징 Spring Data JPA Spring Data Cassandra
ACID 트랜잭션 트랜잭션에 대한 완전한 ACID 지원 단일 파티션 원자성으로 제한
@Transactional 애노테이션 전체 트랜잭션 관리를 위한 지원 지원하지 않음 (글로벌 트랜잭션 없음)
원자성 여러 행/테이블에 걸친 원자성 보장 동일 파티션 내 작업에만 원자성 보장
일관성 강한 일관성 (행 잠금 가능) 나중에 일관성 보장 가능, 튜닝 가능한 일관성
격리성 지원됨 (격리 수준을 조정할 수 있음) 다중 파티션 작업에는 적용되지 않음
내구성 높음 (관계형 데이터베이스에서 보장됨) 분산 환경에서 나중에 일관성 보장
롤백 지원 지원됨 (실패 시 자동 롤백) 여러 파티션에 대한 롤백 지원 없음

Cassandra에서 트랜잭션 지원이 제한적인 이유

Cassandra는 높은 가용성과 파티션 내성을 염두에 두고 설계되었으며, 이는 CAP 정리(Consistency, Availability, Partition Tolerance)에 맞춰져 있습니다. 이로 인해 Cassandra는 일관성보다는 가용성과 파티션 내성을 선택하므로, 여러 행이나 파티션에 걸친 ACID 트랜잭션을 제공할 수 없습니다.

Cassandra와 같은 분산 데이터베이스에서는 데이터를 여러 노드와 파티션에 걸쳐 분산하여 확장성을 유지하며, 강한 일관성 또는 ACID 트랜잭션을 유지하려면 성능과 확장성이 저하될 수 있습니다.

Cassandra와 같은 환경에서 트랜잭션 처리 방법

Cassandra가 완전한 ACID 트랜잭션을 제공하지 않기 때문에, 다른 접근 방식을 채택해야 합니다:

  • 멱등성 작업: 작업을 멱등성 있게 설계하여, 동일한 작업을 여러 번 수행해도 결과가 달라지지 않도록 해야 합니다.
  • 나중에 일관성 보장: 나중에 일관성 보장 개념을 이해하고, 시스템이 일시적인 불일치를 처리할 수 있도록 해야 합니다.
  • 애플리케이션에서 트랜잭션 관리: 보상 트랜잭션을 구현하거나 애플리케이션 레벨에서 일관성을 관리해야 합니다.

요약

  • Spring Data JPA는 완전한 ACID 트랜잭션을 제공하며, 여러 행과 테이블에 걸쳐 트랜잭션을 관리하기 위해 @Transactional 애노테이션을 사용합니다.
  • Spring Data Cassandra는 완전한 트랜잭션 지원을 제공하지 않습니다. 단일 파티션 작업에 대해서만 원자성을 보장하며, 여러 파티션에 걸친 트랜잭션은 지원하지 않습니다. 트랜잭션은 애플리케이션 레벨에서 관리해야 하며, 경우에 따라 보상 전략이 필요할 수 있습니다.

Q. and then, is there no the concept of entity too?

네, 맞습니다! Spring Data Cassandra에서는 Spring Data JPA에서 사용되는 "엔터티(Entity)" 개념이 동일하게 적용되지 않습니다. JPA와 Cassandra는 모두 영속성 데이터를 다루지만, 데이터베이스의 특성 때문에 접근 방식과 기본 개념이 크게 다릅니다.

다음은 Spring Data JPA와 Spring Data Cassandra의 "엔터티" 개념 차이점입니다:

1. Spring Data JPA: 엔터티(Entity) 개념

JPA는 관계형 데이터베이스에서 사용되며, 엔터티는:

  • 테이블에 매핑된 객체입니다.
  • 각 엔터티 클래스는 하나의 테이블을 나타내며, 필드는 테이블의 컬럼을 나타냅니다.
  • 엔터티는 @Entity, @Table 및 기타 JPA 애노테이션을 사용하여 관계, 제약 조건, 매핑 등을 정의합니다.
  • JPA는 일대다(one-to-many), 다대다(many-to-many) 및 엔터티 간의 외래 키 제약 조건과 같은 관계형 개념을 처리합니다.

JPA 엔터티 예시:

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;

    // 기타 필드, 관계 등
}

2. Spring Data Cassandra: 엔터티(Entity) 개념 없음

Cassandra에서는 테이블과 행에 초점을 맞추며, 이는 NoSQL 기반의 컬럼 패밀리 스토어로, JPA에서 사용되는 엔터티 개념과 직접적으로 매핑되지 않습니다. @Entity 대신 Spring Data Cassandra는:

  • @Table 애노테이션을 사용하여 Cassandra의 테이블을 나타냅니다.
  • @PrimaryKey 또는 @PrimaryKeyColumn 애노테이션으로 파티션 키와 클러스터링 컬럼을 지정합니다.

Cassandra는 구조를 가지지만, 관계형 데이터베이스에서처럼 엄격한 "엔터티" 관계는 존재하지 않습니다.

Cassandra 테이블 표현 예시:

@Table("users")
public class User {
    @PrimaryKey
    private String userId;

    @Column("username")
    private String username;

    @Column("email")
    private String email;

    // 기타 필드
}

주요 차이점: 엔터티 vs 테이블

  • 관계형 데이터베이스(JPA)는 엔터티 간의 구조화된 관계(예: 외래 키, 조인)에 중점을 둡니다. 엔터티는 테이블을 나타내며, 조인을 통해 관계를 관리할 수 있습니다.
  • Cassandra(Spring Data Cassandra)는 확장성과 성능에 중점을 둡니다. 조인과 같은 복잡한 관계를 피하고, 비정규화된 데이터 및 넓은 행을 선호합니다. @Table로 주석이 달린 클래스는 Cassandra 테이블을 나타내지만, 객체 간의 관계로서 엔터티 개념은 존재하지 않습니다.

이러한 차이점이 존재하는 이유

Cassandra는:

  • 수평 확장성을 위해 설계되었습니다. 데이터는 여러 노드에 분산되며, 외래 키 제약이나 복잡한 관계(조인)를 지원하지 않습니다.
  • 비정규화: 데이터를 정규화된 엔터티로 분리하고 이를 조인하는 대신, 데이터를 비정규화하여 여러 테이블에 중복 저장함으로써 빠른 읽기를 제공합니다.
  • 조인 없음: Cassandra는 조인을 지원하지 않으므로, 데이터 모델은 테이블 간 관계를 피하도록 설계되어야 합니다. 대신 쿼리 패턴에 맞게 데이터를 설계합니다.

Cassandra에서 데이터 모델을 생각하는 방법

Cassandra에서는:

  • 테이블은 주로 데이터를 쿼리하는 방식에 맞게 설계됩니다. 빠른 읽기를 위해 넓은 행으로 데이터를 비정규화하는 것이 일반적입니다.
  • 파티션 키와 클러스터링 컬럼과 같은 기본 키 개념을 가집니다. 하지만 외래 키나 조인 테이블과 같은 엔터티 관계는 없습니다.
  • 복잡한 엔터티 매핑에 의존하는 대신, 효율적인 쿼리 처리를 위해 설계가 이루어집니다.

주요 차이점 요약:

개념 Spring Data JPA Spring Data Cassandra
엔터티 있음 (@Entity) 없음 (@Table로 Cassandra 테이블을 표현)
관계 일대다, 다대다 등의 관계를 지원 관계 없음; 데이터는 비정규화됨
조인 테이블 간의 복잡한 조인 지원 조인 없음, 비정규화된 넓은 행에 중점
ACID 트랜잭션 완전히 지원 단일 파티션 원자성으로 제한
정규화 정규화 원칙을 따름 빠른 읽기를 위해 데이터는 주로 비정규화됨

Spring Data Cassandra에서는 엔터티가 더 간단합니다. 각 클래스는 하나의 테이블을 나타내며, 필드는 컬럼을 나타냅니다. 그러나 JPA에서와 같은 복잡한 관계는 존재하지 않습니다. Cassandra는 확장성과 가용성, 그리고 특정 쿼리 패턴을 최적화하는 데 중점을 둡니다.

Q. it's not just cassasndra, general nosql's feature?

네, 맞습니다! Spring Data Cassandra와 Spring Data JPA의 차이점은 일반적인 NoSQL 데이터베이스의 특징을 반영합니다. 대부분의 NoSQL 데이터베이스는 관계형 데이터베이스(SQL)와는 다른 몇 가지 공통된 특징을 가지고 있습니다.

NoSQL 데이터베이스의 일반적인 특징:

  1. 스키마 없음 (유연한 스키마)
    • 관계형 데이터베이스(SQL): 엄격한 스키마를 가지고 있어, 데이터를 삽입하기 전에 테이블 구조(컬럼, 타입, 관계)를 정의해야 합니다. 스키마 변경은 데이터베이스 마이그레이션을 필요로 합니다.
    • NoSQL 데이터베이스: 일반적으로 스키마가 없거나 스키마가 유연합니다. 즉, 사전 정의된 컬럼이나 필드 유형 없이 문서나 행을 저장할 수 있습니다. 이는 데이터 모델의 변경이 자주 일어나는 경우 빠른 작업을 가능하게 합니다.
  2. 조인 없음 (비정규화)
    • SQL: 여러 테이블 간의 조인을 지원하며, 이를 통해 데이터를 정규화(즉, 중복을 최소화하기 위해 데이터를 여러 엔터티로 나눔)합니다.
    • NoSQL: 테이블이나 컬렉션 간의 조인을 지원하지 않습니다. 대신 비정규화(데이터 중복)를 통해 읽기 성능을 최적화합니다. 분산 시스템에서 조인 작업은 성능 저하를 초래할 수 있기 때문에, NoSQL에서는 이러한 비용을 피하려고 합니다.
  3. 수평 확장성 (Horizontal Scalability)
    • SQL: 일반적으로 수직 확장(서버의 CPU, 메모리 등 하드웨어 업그레이드) 방식으로 확장됩니다.
    • NoSQL: 수평 확장을 위해 설계되었습니다. 즉, 더 많은 서버(노드)를 추가하여 데이터를 분산하고 처리 성능을 확장합니다. 대규모 데이터를 처리하기 위해 데이터를 여러 노드에 분산시킵니다.
  4. 다중 문서/엔터티에 대한 ACID 트랜잭션 없음
    • SQL: 관계형 데이터베이스는 다중 행, 테이블, 데이터베이스 간의 복잡한 트랜잭션을 지원하며, 완전한 ACID(Atomicity, Consistency, Isolation, Durability) 보장을 제공합니다.
    • NoSQL: 일반적으로 일관성을 나중에 보장(eventual consistency)하며, 여러 문서나 행에 걸친 완전한 ACID 트랜잭션을 지원하지 않습니다. 일부 NoSQL 데이터베이스는 단일 문서나 파티션 내에서 ACID 보장을 제공하지만, 여러 컬렉션 또는 테이블에 걸쳐서는 불가능합니다.
  5. 읽기/쓰기 성능 최적화
    • SQL: 일반적으로 읽기와 쓰기의 균형을 맞추면서 강한 일관성을 제공합니다.
    • NoSQL: 매우 높은 성능의 읽기와 쓰기를 위해 최적화되어 있습니다. 특히 대용량 데이터(예: 소셜 미디어 피드, 로그 데이터 등)를 처리할 때 뛰어난 성능을 발휘합니다. 이 과정에서 일부 일관성 보장을 희생하여 나중에 일관성을 보장합니다.
  6. 파티셔닝 및 복제
    • SQL: 파티셔닝 및 복제를 지원하지만, 이는 주요 초점은 아닙니다. 관계형 데이터베이스에서 이러한 기능을 구현하고 구성하는 것은 복잡할 수 있습니다.
    • NoSQL: 파티셔닝(샤딩)과 복제를 기본적으로 지원하며, 데이터를 여러 서버에 분산시키고 복제하여 가용성과 장애 내성을 보장합니다. 데이터는 고가용성을 위해 여러 노드에 복제됩니다.
  7. 관계보다는 쿼리 패턴에 집중
    • SQL: 데이터 모델은 종종 엔터티 간의 관계를 중심으로 설계되며, 복잡한 쿼리에서 여러 테이블을 조인할 수 있습니다.
    • NoSQL: 쿼리 패턴에 맞추어 데이터 모델을 설계합니다. 데이터를 저장하고 구조화하는 방식은 주로 어떻게 데이터를 조회할지에 최적화되어 있습니다. 관계보다는 분산 환경에서 효율적인 데이터 검색에 중점을 둡니다.
  8. NoSQL 데이터베이스의 다양한 유형
    • 관계형 데이터베이스: 테이블과 관계를 기반으로 일관된 모델을 따릅니다.
    • NoSQL 데이터베이스: 각기 다른 데이터 모델에 따라 여러 유형으로 나뉩니다:
      • 문서 기반 (예: MongoDB): 문서(JSON과 유사한 형식)로 데이터를 저장하며, 각 문서는 유연한 스키마를 가질 수 있습니다.
      • 키-값 저장소 (예: Redis): 매우 빠른 읽기/쓰기를 위한 간단한 키-값 쌍을 저장합니다.
      • 컬럼 패밀리 (예: Cassandra): 열과 행으로 데이터를 저장하며, 분산된 저장과 빠른 쿼리에 최적화되어 있습니다.
      • 그래프 기반 (예: Neo4j): 관계 및 그래프 구조의 데이터를 처리하고 쿼리하는 데 최적화되어 있습니다.

NoSQL 데이터베이스의 예시 특징

  1. Cassandra (컬럼 패밀리 NoSQL)
    • 조인이나 외래 키를 지원하지 않습니다.
    • 테이블은 특정 쿼리에 맞게 설계됩니다.
    • 나중에 일관성 보장 및 높은 가용성을 제공합니다.
    • 노드를 추가하여 수평 확장이 가능합니다.
  2. MongoDB (문서 기반 NoSQL)
    • 데이터를 유연한 스키마를 가진 문서(JSON과 유사한 형식)로 저장합니다.
    • 조인을 지원하지 않지만, 문서를 중첩하여 데이터를 비정규화할 수 있습니다.
    • 단일 문서 내에서 ACID를 지원하지만, 컬렉션 간에는 지원하지 않습니다.
    • 샤딩을 통한 수평 확장이 가능합니다.
  3. Redis (키-값 저장소)
    • 데이터를 키-값 쌍으로 저장합니다.
    • 스키마나 관계가 없습니다.
    • 캐싱, 실시간 데이터, 세션 관리에 뛰어납니다.
    • 여러 키에 걸친 트랜잭션 지원은 없습니다.
  4. Neo4j (그래프 NoSQL)
    • 관계와 그래프 기반 쿼리에 최적화되어 있습니다.
    • 매우 연결된 데이터에 대한 복잡한 쿼리를 처리합니다.
    • Cassandra나 MongoDB처럼 대규모 분산 시스템에 최적화되지는 않았습니다.

관계형 데이터베이스(SQL)와 NoSQL 데이터베이스 비교

특징 SQL (관계형 데이터베이스) NoSQL 데이터베이스
스키마 고정된 스키마, 사전 정의 필요 스키마가 없거나 유연함
조인과 관계 복잡한 조인, 정규화 및 관계 지원 조인 없음, 비정규화와 내장 문서 사용
트랜잭션 완전한 ACID 지원, 복잡한 트랜잭션 가능 제한적이거나 여러 엔터티 간 트랜잭션 미지원
확장성 수직 확장(서버의 자원 추가) 수평 확장(서버/노드 추가)
일관성 강한 일관성(ACID 보장) 나중에 일관성 보장(CAP 이론에 따른 절충)
데이터 모델 테이블, 행, 열 문서, 키-값, 컬럼 패밀리, 그래프
쿼리 방식 SQL로 조인과 집계 쿼리 처리 쿼리 패턴에 따라 다름(예: CQL, MongoDB 쿼리 언어)
사용 사례 구조화된, 트랜잭션이 필요한 데이터 대규모, 실시간 데이터를 처리하는 환경

요약

  • NoSQL 데이터베이스는 스키마 유연성, 비정규화, 조인 미지원, 제한적인 트랜잭션 지원, 수평 확장성을 공유합니다.
  • Spring Data JPA는 엔터티-관계 모델과 완전한 ACID 트랜잭션을 제공하는 반면, NoSQL 데이터베이스(예: Cassandra)는 분산 시스템에서 높은 성능과 확장성을 위해 최적화된 구조를 제공합니다.

NoSQL 데이터베이스는 각각의 유형에 맞는 특성이 다르지만, 모든 NoSQL 데이터베이스는 확장성, 유연성, 성능을 우

선시하는 설계 철학을 공유하며, 이는 전통적인 관계형 데이터베이스의 강한 일관성 및 복잡한 관계 지원과는 차별화된 방식입니다.

저작자표시

'Development > TIL' 카테고리의 다른 글

[TIL][Spring] Spring Webflux의 Spring Security (@EnableWebFluxSecurity), ReactiveSecurityContextHolder  (2) 2024.09.11
[TIL] DTO, Entity에서 Wrapper 클래스를 사용하는 이유  (0) 2024.08.29
[TIL] Kafka와 RabbitMq의 철학, 그리고 어떻게 철학을 달성했을까?  (0) 2024.08.17
[TIL] Redis 캐싱을 사용해야 할 때 주의해야 하는 점  (0) 2024.08.15
[TIL] 다시 배우는 Docker  (0) 2024.08.09

티스토리툴바