DevLog 😶

🌱 문제 상황 간단하게 테스트하고 싶은 내용이 생겨서 DTO용 data class를 생성하였는데, 아래와 같이 Jackson의 역직렬화 관련 오류가 발생하였다. Resolved [org.springframework.http.converter.HttpMessageNotReadableException: JSON parse error: Cannot construct instance of `study.ticketService.domain.application.dto.ConcertTicketCreateRequest` (although at least one Creator exists): cannot deserialize from Object value (no delegate- or property-based Cr..

🌱 들어가기 전 지난 리마큐 포스팅에서 그림으로 설명했던 'CREW' 테이블에 대해서 직접 코드 레벨로 작성해보고자 한다. CREATE TABLE `CREW` ( `id` bigint NOT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; 사전 설정을 위해서 스토리지 엔진을 innoDB로 설정한 'CREW' 테이블을 생성해준다. SET AUTOCOMMIT = false; ⭐️ 그리고, autocommit 모드는 꼭 OFF로 설정해두고 진행하자. 나는 이번에 2개의 세션을 열어서 진행하였다. 🌱 READ UNCOMMITTED SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;..

🌱 들어가기 전이번 포스팅에서는 InnoDB의 인덱스와 락의 상관관계와 트랜잭션 격리 수준에 대해서 알아보자. 🌱 인덱스와 락지난 포스팅에서 레코드 락에 대해 정리할 때 다음과 같은 멘트를 남겼다.innoDB의 경우 레코드 자체를 잠그는 것보다는, 인덱스의 레코드를 잠근다.인덱스를 잠그기 때문에 레코드 검색 시 발견된 모든 레코드의 락을 걸게 된다. 예를 들어, crew 테이블에 age = 23인 사람이 100명이라고 생각해보자. 이때, age에는 인덱스가, name에는 인덱스가 걸려있지 않은 상태다.SELECT COUNT(*) FROM crew WHERE age = 23; # result: 100 하지만, age = 23이면서 name = 'journey'인 결과는 1개만 나온다고 가정해보자.SELEC..

🌱 들어가기 전이번 포스팅에서는 트랜잭션에 대한 간단한 개념과, MySQL과 InnoDB 스토리지엔진에서 제공하는 락에 대해서 알아보자. 🌱 트랜잭션 트랜잭션은 하나의 논리적인 작업 셋에 완전히 적용(commit)되거나, 아무것도 적용되지 않음 (rollback)을 보장해야 한다. InnoDB와 MyISAM 테이블은 트랜잭션 관점에서도 차이를 보이는데, 이를 확인해보자. 우선, 아래와 같이 myISAM과 innoDB를 사용한 2개의 테이블을 만들자.CREATE TABLE tb_myisam ( id INT NOT NULL, PRIMARY KEY (id) ) ENGINE=MYISAM; CREATE TABLE tb_innodb ( id INT NOT NULL, PRIMARY KEY (id) ) ENGINE=i..

🌱 들어가기 전 드디어 기나긴 패킷 여행의 마지막이다. 이번 포스팅에서는 웹 서버측에서 어떤 식으로 패킷을 받아오는지 알아볼 것이다! 클라이언트에서 패킷을 전송하는 단계를 반대로 뒤집은 것과 동일하기 때문에 크게 어렵지 않을 것이다. 🌱 클라이언트가 보낸 패킷이 서버로 도착한 직후 다시 돌아와서, 클라이언트에서 보낸 패킷이 서버로 도착한 직후 어떤 일이 발생하는지 간단하게만 알아보자. (이 부분은 크게 중요한 건 아니라서 간단하게 짚고 넘어가고자 한다.) 우선, 서버 측으로 들어온 패킷의 경우 사실 '전기 신호'의 형태로 들어온다. 전기 신호는 LAN 어댑터에서 수신되며, 여기서 1과 0의 디지털 데이터로 바뀌게 된다. 위 그림은 전기 신호에서 디지털 데이터로 변환되었을 때 패킷의 형태이다. 변경된 디지..

✔️ 레벨 로그 레벨 2 방학 시작한 지 조금 됐지만... ㅎㅎ 뒤늦게 회고를 작성해보고자 한다. 지난 레벨 1 인터뷰 때에 비해서 레벨 2의 인터뷰는 더 많은 인원이 진행했다. (하지만 임팩트룸에서 하다 보니 엄청 복작복작한 느낌이었당) 함께한 크루들은 성하, 박스터, 루카, 깃짱, 헙크, 이오, 두둠이고, 코치님은 브리였다. 💪 저번에는 2일차에 인터뷰였어서 준비할 시간이 넉넉했는데, 이번에는 1일차에 걸린 바람에 준비할 시간도 별로 없었다 ㅎㅎㅎ 레벨 로그 / 레벨 인터뷰 직렬화와 역직렬화 www.notion.so 노션에 레벨 인터뷰를 준비하며 열심히 정리했었다. 레벨 2에서 배운 게 워낙 중구난방해서 그런가... 최대한 스프링에 대한 것만 공부하고 갔다. 블로그에 한 번 더 올리는 것보다는 노션이..

라온, 쥬니, 세인, 쵸파랑 진행했던 레벨 2 마지막 미션, 장바구니 협업 미션이다! 프론트 크루분들이랑도 함께 할 수 있었어서 너무 재밌었던 시간이었다 😊 이번 미션은 저번에 진행했던 미션을 바탕으로 하다 보니까 코드적인 부분보다, 배포 쪽을 더 신경썼던 것 같다. 마지막 미션인 만큼 정말 많이 배웠던 시간이었다 ㅎㅎ ✔️ 작성한 코드 GitHub - Cl8D/jwp-shopping-order: 우아한테크코스 레벨 2 장바구니 협업 미션 레파지토리 우아한테크코스 레벨 2 장바구니 협업 미션 레파지토리. Contribute to Cl8D/jwp-shopping-order development by creating an account on GitHub. github.com ✔️ PR [2단계 - 주문 기능..

🌱 들어가기 전이번 포스팅에서는 InnoDB의 전반적인 아키텍처 중에서 디스크 영역에 대해서 알아보자. 마찬가지로 간단하게만 짚고 넘어가고자 한다. 🌱 Tablespace테이블 스페이스는 데이터를 저장하기 위해 사용되는 큰 논리적인 단위이며, Segment -> Extent -> Page -> Row와 같은 형태로 구성된다. MySQL에서 테이블 스페이스는 저장하는 데이터의 종류에 따라서 5가지로 분류가 가능한데, 이는 다음과 같다. - System tablespace - File-Per-Table tablespace - General Tablespace - Temporary Tablespace - Undo Tablespace 🌱 System tablespaceSystem tablespace의 경우 My..

🌱 들어가기 전이번 포스팅에서는 InnoDB의 전반적인 아키텍처 중에서 메모리 영역에 대해서 알아보자. 상당히 복잡하기 때문에 대략적인 내용만 이해하고 넘어가도 충분하다고 생각한다. 🌱 InnoDB 버퍼 풀 (Buffer Pool)위 그림은 MySQL 8.0 기준 InnoDB 구조를 나타낸 그림이다. 이중에서 버퍼 풀의 경우 InnoDB 스토리지 엔진의 가장 핵심적인 부분이다. 디스크의 데이터 파일, 인덱스 정보를 메모리에 캐시도 해둘 수 있고, 쓰기 작업을 지연시켜서 일괄 처리도 가능하다.💡 그렇다면 크기는 어느 정도로 설정해야 할까? 보통 OS 전체 메모리 공간이 8기가 이하라면 50% 정도만 버퍼 풀로 설정하고, 나머지는 다른 프로그램이 사용할 공간으로 남겨두는 것이 좋다. 만약 메모리 공간이 더 ..

🌱 InnoDB 스토리지 엔진 아키텍처MySQL에서 가장 많이 사용하는 스토리지 엔진인 'InnoDB'에 대한 아키텍처를 알아보자.그림이 복잡하기는 하지만, 왼쪽은 이전에 봤던 MySQL 엔진이고, 오른쪽이 InnoDB 스토리지 엔진의 구성도이다. 이번 포스팅에서는 innoDB 스토리지 엔진의 특징에 대해서 알아보도록 하자. 1. PK에 의한 클러스터링기본적으로 InnoDB의 모든 테이블은 PK를 기준으로 클러스터링되어 저장된다. 여기서 클러스터링된다는 것은, PK 값이 비슷한 레코드끼리 묶어서 저장하는 것을 의미한다. PK 값이 레코드의 저장 위치를 결정하기 때문에 신중하게 결정해야 한다. 일반적인 DBMS에서 세컨더리 인덱스의 리프 노드에는 데이터의 실질적인 물리 주소가 들어가서, 해당 인덱스의 데이..