꾸준하게, 차근차근

Redis를 활용하기 전, 기본 개념부터 다지기 위해 차근차근 기록하며 글을 작성하려 한다.내 머릿속엔 지우개가 있기 때문에, 그리고 강사님도 내가 이해하기 쉬운 방법으로 정리하라 하셨기에 잘 정리해보자? 1. Redis란?Remote Dictionary Server의 약자로, "Key-Value" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템(DBMS)이다.- 위키백과 - 라고 정의되어 있지만 너무 어렵다.따라서, 나는 아래와 같이 이해하기로 했다.데이터 처리 속도가 엄청 빠른 NoSQL 데이터베이스이다. 여기서 NoSQL은 Key-Value 형태로 데이터를 저장하는 데이터베이스라고 생각하면 쉽다. 2. Redis의 장점장점은 무수히 많겠지만, 많이 ..

동시에 같은 데이터를 수정하게 될 경우 DB락이 어떻게 동작하는지 정리하려 한다. 1. 문제점 세션1이 트랜잭션을 시작하고 데이터를 수정하는 동안(커밋 연산이 일어나기 전) 세션2에서 같은 데이터를 수정하게 되면 여러가지 문제가 발생한다. 첫번째, 트랜잭션의 원자성(트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하거나 모두 실패해야 한다는 원칙)이 깨진다.두번째, 세션1이 커밋 연산이 아닌 롤백 연산을 실행하게 될 경우, 세션2는 잘못된 데이터를 수정하게 된다. 이와 같은 문제를 방지하려면, 세션이 트랜잭션을 시작하고 데이터를 수정하는 동안(커밋이나 롤백 연산이 일어나기 전) 다른 세션에서 해당 데이터를 수정할 수 없게 막아야 한다. 데이터베이스는 이런 문제를 해결하기 위해 락(Lo..

Querydsl 학습하면서 부딪혔던 이슈에 대해 정리한다. 1. 이슈의 원인 IntelliJ가 버전업하거나 Querydsl의 Gradle 설정이 버전업하면서 적용 방법이 달라지기도 하며, 각자의 환경 설정에 따라 정상적으로 동작하지 않을 수 있다. 현재 나의 SpringBoot 버전은 3.2로 3.0 이하의 설정으로는 Querydsl이 정상적으로 동작하지 않아 버전에 맞게 설정을 해줘야 했다. Querydsl 설정은 공식 매뉴얼에 소개되어 있지 않아 본인 환경에 맞는 대안을 찾아 설정해야 한다. 2. 원인 해결 프레임워크 설정 추가 build.gradle 파일의 dependencise 영역에 프레임워크 설정을 추가한다. // Querydsl 설정 추가 implementation 'com.querydsl:..

트랜잭션을 자세히 이해하기 위해 데이터베이스의 서버 연결 구조와 세션에 대해 정리하려 한다. 1. 데이터베이스 연결 구조 1 사용자는 클라이언트(WAS, Database tools, SpringBoot, H2 Console)를 사용하여 데이터베이스에 접근할 수 있는데, 이때 클라이언트는 데이터베이스 서버에 연결을 요청하고 커넥션을 맺고 데이터베이스 서버는 세션을 생성한다.그리고 해당 커넥션을 통한 모든 요청은 생성된 세션을 통해 실행된다. 세션은 트랜잭션을 시작하고, 커밋 또는 롤백을 통해 트랜잭션을 종료하며 사용자가 커넥션을 닫거나 데이터베이스 관리자가 세션을 강제로 종료하면 해당 세션은 종료된다. 2. 데이터베이스 연결 구조 2 커넥션 풀이 10개의 커넥션을 생성했다면, 세션도 10개가 생성된다.이는..

이번 챕터에서는 두 가지 아키텍처 스타일 중 두번째 육각형 아키텍처(헥사고날 아키텍처)에 대해 이야기 한다. 1. 육각형 아키텍처(헥사고날 아키텍처) 육각형 아키텍처는 애플리케이션 코어가 각 어댑터와 상호 작용하기 위해 특정 포트를 제공한다. 육각형 안에는 도메인 엔티티와 이와 상호 작용하는 유스케이스가 있다. 육각형 외부로 향하는 의존성이 없기 때문에 마틴이 클린 아키텍처에서 제시한 의존성 규칙이 그대로 적용된다. 대신 모든 의존성은 코어로 향한다. 육각형 바깥에는 애플리케이션과 상호 작용하는 다양한 어댑터들이 있다. 왼쪽에 있는 어댑터들은 애플리케이션 코어를 호출하기 때문에 애플리케이션을 주도하는 어댑터(driving adapter)들이다. 반면 오른쪽에 있는 어댑터들은 애플리케이션 코어에 의해 호출..

이번 챕터에서는 두 가지 아키텍처 스타일 중 첫번째 클린 아키텍처에 대해 이야기 한다. 1. 클린 아키텍처 로버트 C. 마틴이 정립한 용어로, 클린 아키텍처에서는 설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI 기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다고 이야기 한다. 이는 도메인 코드가 바깥을 향하는 어떤 의존성도 없어야 함을 의미하며, 대신 의존성 역전의 원칙의 도움으로 모든 의존성이 도메인 코드를 향한다. 클린 아키텍처에서 가장 주요한 규칙은 의존성 규칙으로, 계층 간의 모든 의존성이 안쪽을 향해야 한다는 것이다. 아키텍처 코어에는 유스케이스에서 접근하는 도메인 엔티티가 존재하며, 유스케이스는 단일 책임을 갖기 위해 조금 ..

트랜잭션을 도입하는 이유나 사용법에 대해선 알고 있으나, 자세한 이해가 부족한 상태라 개념을 다지기 위해 정리하려 한다. 1. 트랜잭션이란 여러 개의 작업을 하나로 묶은 실행 유닛을 말하며, 데이터베이스 관점에서는 상태를 변화시키는 기능을 수행하기 위한 하나 이상의 쿼리를 모아 놓은 논리적 작업 단위를 말한다. 2. 트랜잭션의 ACID 원자성(Atomicity) 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하거나 모두 실패해야 한다. 일관성(Consistency) 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어, 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다. 격리성(Isolation) 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 ..

첫번째 챕터에서는 계층형 아키텍처의 문제점에 대해 이야기하였다. 이번 챕터에서는 계층형 아키텍처의 대안에 대해 이야기 한다. 1. 단일 책임 원칙 단일 책임 원칙의 일반적인 해석은 아래와 같다. "하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다." 이는 단일 책임이라는 말을 가장 직관적으로 해석한 것으로, 단일 책임 원칙이라는 이름에 오해의 여지가 있다는 점을 주의해야 하며, 단일 책임 원칙의 실제 의도가 아니다. 단일 책임의 원칙의 실제 정의는 아래와 같다. "컴포넌트를 변경하는 이유는 오직 하나 뿐이어야 한다." '책임'은 '오로지 한 가지 일만 하는 것'보다 '변경할 이유'로 해석해야 한다. 컴포넌트를 변경할 이유가 오로지 한 가지라면 컴포넌트는 딱 한 가지 일만 ..