DevKTak 일기장

Transaction isolation level 종류 및 특징 READ UNCOMMITTED (레벨 0) SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리는 계층 각 트랜잭션에서의 변경내용이 commit 이나 rollback 여부에 상관없이 다른 트랜잭션에서 값을 읽을 수 있다. Dirty Read 발생! 정합성에 문제가 많은 격리 수준이기 때문에 사용하지 않는 것을 권장 READ COMMITTED (레벨 1) SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리지 않는 계층 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기하게 됨 Commit이 이루어진 트랜잭션만 조회 가능 Oracle, SQL Server에서 기본으로 사용 Non-R..

Q. 개발자로서 DNS를 구현한다면 어떤 자료구조를 선택하고 어떤 프로토콜을 선택할 것 같은지? A. Map Q. 맵으로 자료구조를 선택하였을 때 유저의 DNS 쿼리가 들어온다면 처리하느데 소요되는 시간 복잡도는? A. 최선의 경우 O(1) 이고 해시충돌이 일어날 경우 O(N) Q. 그럼 해시 충돌은 왜 일어날까요? A. 먼저 해시 함수란 임의의 길이를 갖는 메시지를 입력받아 고정된 길이의 해시값을 출력하는 함수 해시테이블은 해시함수(key값을 mod 연산)를 사용해서 나온 해시값을 key값으로 하고 데이터를 Value로 하여 테이블 형태로 만든다.여기서 해시값을 key값으로 해시 테이블에 insert 하려고 보니까 이미 데이터가 있는 경우를 해시충돌 이라고 한다. Q. 그렇다면 충돌을 해결하기 위한 ..

즉시 로딩(FetchType.EAGER) @ManyToOne @OneToOne 지연 로딩(FetchType.LAZY) @OneToMany @ManyToMany JPA N + 1 문제란? 1번의 쿼리를 날렸을 때 의도하지 않은 N번의 쿼리가 추가적으로 실행되는 것을 의미한다.  1:N 또는 N:1 관계를 가진 엔티티를 조회할 때, JPA Repository를 활용해 인터페이스 findAll() 호출 시 Fetch EAGER 전략으로 데이터를 조회하는 경우 Fetch LAZY 전략으로 데이터를 가져온 이후에 연관 관계인 하위 엔티티를 다시 조회하는 경우 N + 1 문제가 발생한다. 기본 전략을 LAZY로 가져가고 필요 시 EAGER를 사용하는 방향으로 개발하던 중 2번과 같은 상황이 나에게도 드디어! ㅎ..

OSI 7 계층과 인터넷 프로토콜 스택의 4 계층 TCP의 특징은 가상 연결, 데이터 전달보증, 순서 보장이 있으며 소켓이 연결됐다 라는것은 사실은 물리적으로 진짜 연결된 것이 아닌 논리적으로만 연결된 것이다. UDP의 특징은 IP와 같은데 + PORT, + 체크섬 정도만 추가된 단순하고 빠른 프로토콜이며 HTTP3에서 사용중이다. HTTP의 특징은 비연결성, 클라이언트 서버 구조, 무상태가 있으며 Stateless 하기 때문에 서버 확장성이 높음(스케일 아웃) HTTP 메서드의 속성 안전(Safe Methods): 호출해도 리소스를 변경하지 않는다. ➪ GET 멱등(Idempotent Methods): 몇번을 호출하든 결과가 똑같다. ➪ GET, PUT, DELETE 캐시가능(Cacheable Meth..

먼저 트랜잭션을 알아야 이해 할 수 있었던 것 같다. Transaction 하나의 작업을 수행하는데 필요한 데이터베이스의 연산을 모아놓은 것으로 데이터베이스 작업의 단위, SQL문의 집합이라고 생각하면 된다. 트랜잭션에서 중요한 것은 트랜잭션 단위로 구분해서 모두 성공하거나 모두 실패해야 데이터베이스의 일관성을 유지할 수 있다. Lock은 동시성을 제어하기 위한 기능이고 Transaction은 정합성을 보장하기 위한 기능이다. Dead Lock - 둘 이상의 프로세스가 다른 프로세스가 점유하고 있는 자원을 서로 기다릴 때 무한 대기에 빠지는 상황 - 교착상태란 두 개 이상의 트랜잭션이 특정 자원(테이블 또는 행)의 잠금(Lock)을 획득한 채 다른 트랜잭션이 소유하고 있는 잠금을 요구하면 아무리 기다려..

자연키(natural key) 비즈니스에 의미가 있는 키 예: 주민등록번호, 이메일, 전화번호 대리키(surrogate key) 비즈니스와 관련 없는 임의로 만들어진 키, 대체키로도 불린다. 예: 오라클 시퀀스, auto_increment, 키생성 테이블 사용 * 자연키 보다는 대리키를 권장 기본키(Primary key) 매핑 방식 직접 할당: @Id 어노테이션만 사용해서 회원의 기본키를 직접 할당 자동 생성: 대리키 사용 방식, 기본키 생성을 데이터베이스에 위임한다. IDENTITY: 자동 증가 컬럼(auto_increment)을 이용한 전략 데이터베이스에 INSERT 쿼리를 실행한 후에 생성된 키를 가져와서 엔티티의 식별자로 사용 MySQL, SQL Server 등에서 사용 단점은 주로 대량의 데이..

복잡도란? 알고리즘의 성능을 나타내는 척도이다. 시간 복잡도: 특정한 크기의 입력에 대하여 알고리즘이 얼마나 오래걸리는지를 의미 공간 복잡도: 특정한 크기의 입력에 대하여 알고리즘이 얼마나 많은 메모리를 차지하는지를 의미 복잡도를 측정함으로써 우리는 다음의 2가지를 계산할 수 있다. 시간 복잡도: 알고리즘을 위해 필요한 연산의 횟수 공간 복잡도: 알고리즘을 위해 필요한 메모리의 양 * 빅오 표기법: 가장 빠르게 증가하는 항만을 고려하는 표기법 그리디(Greedy) == 탐욕법이란? 현재 상황에서 지금 당장 좋은 거만 고르는 방법 구현(Implementation)이란? 머릿속에 있는 알고리즘을 소스코드로 바꾸는 과정 완전 탐색: 모든 경우의 수를 주저 없이 다 계산하는 해결 방법 일반적으로 알고리즘 문제를..

나의 프로젝트 시작 후 REST API를 만드는 과정에서의 첫 에러 등장! 에러 내용: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class com.hotelJava.accommodation.dto.AccommodationResponseDTO and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: java.util.ArrayList[0]) at com.fasterxml.jackson..

1. 협업할 Repository를 Fork 떠서 나의 Repository로 가져오자 2. Fork 뜬 나의 원격 Repository에 있는 프로젝트를 Clone해서 나의 로컬 PC에 만들자 git clone {나의 Repository URL} 3. 원본 소스코드가 있는 곳의 위치(Upstream)를 미리 등록해주자 git remote add upstream {협업할 Repository의 URL} 4. 기능 단위 개발 작업을 위해 Branch를 따주자 git checkout -b {생성할 브랜치 명} 5. 코드 작업 후 Add, Commit 후 나의 Repository에 Push 해주자 git push origin {생성한 자신의 브랜치 명} 6. 본인 계정 깃허브 저장소에 접속해서 Compare & p..