처음 리눅스에 대해 알게 된 건 어릴 때 영화에서 해커를 보면 검은 화면에 영어가 빠르게 올라오는 장면을 보고 알게 되었다. 이후 컴퓨터에 대해 공부를 하면서 리눅스에 대해 알게 되었고 그 당시에는 리눅스가 어떠한 것을 하기 위해서 사용이 되는지 몰라 학습을 회피를 하였다. 현재 개발자를 꿈꾸면서 리눅스는 선택이 아닌 필수가 되었고 기존에 알고 있는 내용과 배포를 하면서 알게 된 내용을 정리하기 위하여 이 글을 작성하였다. 1. 리눅스에 대해 알아보자 1. 리눅스란 윈도우 , MacOS 같은 컴퓨터의 운영체제이지만 조금 다른 부분이 있다. 윈도우 , MacOS는 흔히 GUI(Graphic User Interface)란 우리가 지금 사용하고 있는 컴퓨터에 화면처럼 모든 요소들이 화면에 그림으로 나타나서 사..

테스트를 하기 위해서 local에 DB를 실행을 해야되는데 이것을 In Memory를 통하여 local에 실행하지 않고 테스트가 가능하다. 우선 설정을 위해서 src/test 에서 resources 디렉토리를 추가해 주고 application.yml도 추가해준다. 이렇게 추가된 application.yml은 test시 main directory 하위에 있는 application.yml보다 우선권을 가지게 된다. spring: datasource: url: jdbc:h2:mem:test username: sa password: driver-class-name: org.h2.Driver jpa: hibernate: ddl-auto: create properties: hibernate: format_sql: ..

인덱스를 왜 사용해야 되는지 알기 위해서는 디스크 읽기 방식에 대해 공부를 해야된다. 이 포스트는 인덱스에 관련된 내용이기 때문에 디스크 읽기 방식에 대해 간단하게 설명하고 넘어가겠다. 2개의 읽기 방식을 이해하면 좋은데 랜덤I/O와 순차I/0 방식이다. 랜덤I/O방식과 순차I/O 방식의 공통적인 행동이 있는데 플래터를 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는다. 하지만 여기서 차이가 나는 부분은 순차I/O는 1번의 시스템 콜을 호출하고 랜덤I/O는 3번의 호출을 하였다. 이렇게 살펴보면 순차I/O를 사용하면 효율이 좋겠지만 기본적으로 랜덤I/O를 사용하고 있는 MySQL을 현실적 특성상 순차I/O로 변경하기는 어렵다. 그래서 랜덤I/O를 사용을 하면서 접근하는..

MYSQL 격리 수준 격리 수준 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 테이블을 볼 수 있게 처리를 할 것인지 결정하는 것이다. 1. Read Uncommitted Read Uncommitted 격리 수준은 각 트랜잭션에서 변경 내용이 commit , Rollback 여부에 상관없이 다른 트랜잭션에 보인다. (Dirty Read) → 사용자 A가 insert를 하고 사용자 B가 commit 이 되지 않은 데이터를 select로 접근을 한다. → 만약에 Insert 하는 경우에 오류가 발생하여 롤백을 하게 된다면 사용자B는 어떤 데이터를 접근을 하고 있을까? — 롤백이 되지 않은 데이터를 접근 → 이처럼 Read Uncommitted는 정합성에 많은 문제가 ..

Lock 락은 기본적으로 동시성을 보장한다. 즉. 락은 동시성을 제어할 때 락의 범위를 최소화를 하는게 중요하다. 왜냐하면 락의 범위가 길어지면 대지중인 커넥션이 많아지고 나중에는 커넥션 풀이 고갈로 이어질 수 있다. 기본적으로 MySQL에서는 트랜잭션 커밋 , 록백시점에 락이 풀린다. 트랜잭션이 곧 락의 범위가 된다고 생각하면 된다. MySQL에서 락은 크게 InnoDB 엔진 , MySQL 엔진 레벨로 나눌 수 있다. 📌 비관적 동시성 제어(PCC, Pessimistic Concurrency Control) 비관적 락이라고도 하며 트랜잭션이 충돌하는 가정하에 잠금을 거는 방식 일반적으로 Shared Lock, Exclusive Lock을 통해 이를 구현한다. 📌 낙관적 동시 수행 제어(OCC, Opti..

이번 주에 했던 작업 JUnit 5 , MockMVC을 이용한 첫 테스트 코드 작성 AssertJ , Mockito를 이용해서 테스트 작성 Given , When , Then 테스트 코드 작성하면서 느낀점 코드의 작성은 개발자가 하지만 그 코드를 보는 사람을 생각하며 작성하자 코드의 작성은 개발자가 하지만 테스트 코드는 비즈니스 로직을 검증 이외에 다른 사람들에게 쉽게 내가 생각한 로직을 명확하게 표현을 할 수 있다고 생각한다. @Nested , @DisplayName에 명확한 이름을 사용하여 가독성을 높이는게 생각보다 더 중요하다고 느꼈다. 빠르게 검증이 가능하다. 기존에 프로젝트를 하면서 테스트를 하는것 보다 빠르게 시나리오를 만들어서 로직을 검증을 하니 개발에 대한 시간이 줄어들고 에러를 더 쉽게 ..