🐥 카카오테크캠퍼스 - 2단계 1주차 기본 Entity 설계 User(사용자) - id : PK - userName : 유저 이 름 - email : 이메일 - password : 비밀번호 - createDate : 생성 날짜 - updateDate : 수정 날짜 Product(상품) 상품 상세보기 - id : PK - productName : 제품 명 - description : 제품 설명 - image : 제품 사진 - price : 제품 가격 - starCount : 별점 - createDate : 생성 날짜 - updateDate : 수정 날짜 Option(옵션) - id : PK - productId : FK->Product.id - optionName : 옵션 이름 - price : 옵션 가격..
카카오테크캠퍼스
🐥 카카오테크캠퍼스 - 2단계 1주차 과제분석 이번 주의 과제는은 Entity를 작성하는 것이다. 화면 설계와 요구사항 명세를 보고, 고민해보라는게 핵심인거 같다. 과제에는 기본적인 테이블(User, Product, Option, Order, Item)은 이미 제시가 되어 있다 또한, API/화면 설계/요구사항 명세서도 주어져있다. 예시로 회원 가입의 응답 데이터를 보면, 아래와 같다. 우린 이제, User 테이블에는 적어도, username,email,password 필드가 필요 함을 알게 되었다. 또한, 테이블을 작성 할 때 PK는 필수이다. API 명세를 보니, 예외 처리가 필요한 사항도 친절하게 적혀있다. 예외 처리를 어느 타이밍에 해야 할지도 고민해야 한다. 이번에 화면 설계를 봐보자, 테이블 ..
🐥 카카오테크캠퍼스 - 2단계 1주차 강의 OT : BE 파트 개발 프로세스 BE는 FE를 만들지 않을 것이므로, 제시된 jar 파일을 구동하여 FE를 대신한다 기능 개발 확인은 PostMan 또는, 직접 Docker로 빌드하면서 개인 별로 기능을 구현할 것이다 전체적으로, 로컬에서 개발하고, 테스트를 한 후 Github 브랜치에 계속 개발을 진행한다. 크램폴린(카카오 클라우드)는 Github에서 코드를 업데이트한다 기억하자! BE는 FE가 개발하기 편하도록, 데이터를 넘겨줘야 한다 화면에 필요한 DTO만 던져준다던가 DTO가 바뀌면 꼭 프론트에게 말해준다던가 PK는 보이지 않아도 꼭 만들어줘야 한다 Entity 파악 : UI를 보고 어떤 데이터가 필요한지 보는 시야 필요 예를 들어 아래와 같이 회원 가..
낙관적 Lock과 비관적 Lock 낙관적 잠금 낙관적 잠금은 충돌이 드물고 전체 트랜잭션 중에 리소스를 잠글 필요가 없다고 가정하는 전략입니다. 대신 트랜잭션이 커밋될 때 충돌을 확인합니다. 충돌이 감지되면(예: 다른 트랜잭션이 데이터를 수정함) 트랜잭션이 롤백되고 오류가 반환됩니다. 낙관적 잠금은 버전 번호를 사용하여 구현됩니다. 트랜잭션이 커밋되면 시스템은 데이터베이스의 현재 버전 번호가 읽은 버전 번호와 일치하는지 확인합니다. 일치하면 트랜잭션이 커밋되고 버전 번호가 증가합니다. 일치하지 않으면 충돌이 발생하고 트랜잭션이 롤백됩니다. 다음은 낙관적 잠금을 사용하는 방법의 예입니다. START TRANSACTION; SELECT version_number FROM table_name WHERE con..
동시성 제어 데이터베이스의 동시성 제어를 통해 여러 트랜잭션(Transaction)이 서로 간섭하지 않고 동시에 발생할 수 있습니다. 동시 실행에도 불구하고 트랜잭션의 일관성, 격리 및 내구성을 보장하게 하는 것이죠! 데이터베이스의 동시성 문제에 대한 일반적인 패턴 공유 리소스 조회 여러 트랜잭션이 공유 리소스를 읽고 있을 때 하나의 트랜잭션이 리소스를 수정하는 경우 제대로 관리하지 않으면 불일치가 발생할 수 있습니다. 공유 리소스 업데이트 여러 트랜잭션이 공유 리소스를 동시에 업데이트하려고 하면 충돌이 발생할 수 있습니다. 이를 종종 쓰기-쓰기 충돌이라고 합니다. 교착 상태 교착 상태는 두 개 이상의 트랜잭션이 서로 리소스를 해제하기를 무한정 기다릴 때 발생합니다. 이는 관리해야 하는 동시성 제어의 일..
트랜잭션 격리레벨 트랜잭션(Transaction) 격리 수준은 한 트랜잭션에서 변경한 내용을 다른 트랜잭션에 표시하는 방법과 시기를 결정합니다. SQL에는 네 가지 트랜잭션 격리 수준이 있습니다. READ UNCOMMITTED 가장 낮은 격리 수준입니다. 이 수준에서 트랜잭션은 아직 커밋되지 않은 다른 트랜잭션에서 쓰고 있는 데이터를 읽을 수 있습니다( 이로 인해 불일치가 발생할 수 있습니다. READ COMMITTED 이것은 많은 데이터베이스 시스템의 기본 수준입니다. 이 수준을 사용하는 트랜잭션은 트랜잭션이 시작되기 전에 커밋된 데이터만 볼 수 있습니다. 이는 더티 읽기를 방지하지만 여전히 반복 불가능한 읽기 및 팬텀 읽기로 이어질 수 있습니다. REPEATABLE READ 이 수준은 읽은 데이터가 ..
트랜잭션 트랜잭션은 하나 이상의 SQL 문을 포함하는 단일 논리적 작업 단위입니다. 트랜잭션은 데이터베이스 시스템에서 데이터 무결성과 일관성을 보장하는 데 사용됩니다. 동일한 데이터에 대한 여러 작업이 동시에 발생할 수 있는 다중 사용자 및 동시 데이터베이스 환경에서 매우 중요합니다. 예시로 아래의 SQL 문이 작동하는 것을 봅시다 홍길동이 김국밥에게 잔액을 +900을 줬지만 3번에서 실패가 발생했습니다 이 경우, 데이터의 정합성이 깨집니다. 위의 그림처럼, 홍길동은 900이 그대로 남았지만, 김국밥은 잔액이 900원이 더 생긴 상태로 쿼리가 종료 되었습니다 눈 먼 돈이 생겨버렸죠 이러한 문제 때문에 여러 SQL문을 마치 하나의 오퍼레이션으로 묶어야 하는 필요가 생겼습니다 ACID ACID로 참조되는 네..
Fan Out On Read (Pull Model) 웹 서비스를 예시로 들며 Fan Out On Read 모델에 대해 알아봅시다 푸시 모델이라고도 하는 Fan Out On Read는 게시물 작성 시 팔로워의 타임라인에 게시물을 즉시 전달하여 실시간 업데이트를 보장하기 위해 소셜 미디어 시스템에서 사용되는 전략입니다. 이 접근 방식은 즉각적인 데이터 일관성을 우선시하여 팔로워가 지체 없이 최신 게시물을 받을 수 있도록 합니다. Fan Out On Read에는 몇가지 특징이 있습니다 즉시 전달 Fan Out On Read를 사용하면 게시물이 생성되는 즉시 팔로워의 타임라인에 즉시 전달됩니다. 게시물 작성과 팔로워의 타임라인에 표시되는 사이에는 지연이 없습니다. Read Latency 증가 시스템이 포스트 데..
Fan Out On Write (Push Model) Fan Out On Read (Pull Model)로 설명을 하면, 게시물 작성 할 때 , 해당 회원을 팔로우하는 회원들에게 데이터를 배달하는 것입니다 일종의 인덱스? 역할을 하는 Timeline 테이블을 만들어, 조회 시간을 줄여 시간복잡도에서 이득을 가져 가는 것이죠 정리를 하자면, Fan Out On Write(푸시 모델)는 게시물이 생성되는 즉시 팔로워의 타임라인에 게시물이 전달되는 소셜 미디어 시스템에서 사용되는 전략입니다. 실시간 업데이트 및 즉각적인 데이터 일관성을 보장하기 위해 타임라인 데이터가 팔로워의 타임라인으로 푸시됩니다. 단순화된 검색 게시물은 이미 팔로워의 타임라인에 전달되어 있기 때문에 팔로워가 자신의 타임라인에 액세스할 때 ..
커버링 인덱스 커버링 인덱스는 페이지네이션을 최적화하기 위한 기법입니다. 커버링 인덱스의 기본 아이디어는 검색 조건이 인덱스에 부합하다면, 테이블에 바로 접근하는 것보다 인덱스를 통해 접근하는 것이 빠르지 않을까?입니다 즉 테이블에 접근하지 않고 바로, 인덱스로만 데이터 응답을 내려주는 것입니다 인덱스에 필요한 모든 정보를 포함하여 데이터에 대한 접근과 검색 속도를 향상시키는거죠. 커버링 인덱스는 인덱스에 모든 필요한 컬럼이 포함되어 있기 때문에 데이터 테이블에 직접 접근하지 않고도 필요한 정보를 인덱스에서만 가져올 수 있습니다 흐름 설명 위의 테이블에 SELECT 나이 FROM 회원 WHERE 나이 < 30 쿼리를 날리는 상황을 가정해 봅시다 조회가 끝나면, 19와 27이 조회 되었고, 인덱스를 따라 ..
