코드를 살펴보면서 좋아요 기능에 멀티 스레드로인한 동시성이나 성능을 개선할 수 있는 방법이 떠올라 개선해보았습니다. 제가 계속해서 개선해나간 기록들을 남겨두며 누군가에게 도움이 됐음 좋겠습니다. 문제 상황 @Transactional public Long likeBoard(final Long boardId, final Long memberId) { Board board = boardReadService.getBoardOne(boardId); board.getBoardCount().plusLike(); return likeRepository.save(Like.createLike(memberId, boardId)).getId(); } 여러 스레드가 Board 객체를 조회하고 plusLike를 한 후 마지막으로..
2000개 WHERE .. IN 절을 처리하는 과정에서 옵티마이저가 Index를 타지 않고 Table Full Scan을 하는 것을 확인했습니다. 이를 방지하기 위해 여러 고민을 하던 와중 FORCE 인덱스를 발견했는데 이에 대해 소개하고 어떤 상황에 쓰면 좋을지 고민해보는 시간을 가져 보겠습니다. 또한 결론적으로 말씀드리면 결국 이 방법이 아닌 다른 방법을 택했는데 그거에 관해서도 소개 드리겠습니다. 또한 모든 설명은 MySQL 기준입니다. FORCE INDEX? FORCE 인덱스는 Query Hint 중 하나로 특정 인덱스를 강제로 사용하도록 합니다. MySQL에서는 적절한 Index를 사용하지 않으면 성능이 저하될 수 있기 때문에 신중하게 선택하여야 합니다. FORCE INDEX는 다음과 같이 사용..
Index란? 인덱스는 말 그대로 책의 맨 처음 또는 맨 마지막에 있는 색인이라고 할 수 있다. DBMS는 DB 테이블의 모든 데이터를 검색해서 원하는 결과를 갖고 오려면 오래 걸리는데, 이를 빠르게 처리하기 위해 칼럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 인덱스를 만들어 두어 값을 빠르게 탐색한다. 하지만 새로운 값을 추가하거나 삭제, 수정 시 쿼리문 실행 속도가 느려지는데 저장 성능을 희생하고 데이터의 읽기 속도를 높이는데 포커스를 맞춘 것이다. 삽입 삭제 수정 시 정렬이 된 상태로 저장이 되어야하는데 원래 있던 데이터에서 여러가지 변경해야할 비용이 발생하여 이때에는 인덱스는 효율적이지 않다. Index 자료구조 B+ Tree 인덱스 알고리즘 일반적으로 사용되는 인덱스 알고리즘은 B+..
프로젝트를 진행 중에 최근 데이터를 정렬하라는 요구사항에 대해 빠르게 성능을 올리고 싶어 여러가지를 찾아보던 중 커버링 인덱스라는 개념을 발견했다. 인덱스 ? 인덱스는 데이터를 효율적으로 탐색하는 방법이다. 하나의 색인같은 것으로 MySQL 미리 정렬된 상태의 하나의 클러스링된 테이블이 존재하면 이 테이블에 접근하여 빠르게 해당 아이디 값을 찾아가는 방식으로 동작한다. 이 때 성능이 매우 빠르기 때문에 DB 성능향상을 위해 꼭 필요한 기술이다. 커버링 인덱스? 커버링 인덱스 는 쿼리를 충족하는데 필요한 모든 데이터를 갖는 인덱스를 뜻한다.(SELECT/WHERE/GROUP BY/ ORDER BY) 아까 인덱스에서 잠시 언급한 미리 정렬된 상태의 클러스터링된 테이블에 접근하여 데이터를 인덱스 테이블에서 조..
OneToOne은 기본적으로 Lazy 로딩을 지원하지 않는다. 그렇기 때문에 조회 시 Lazy로 설정 시 다음과 같은 문제가 발생한다. 일단 사전에 코드를 보여주면 다음과 같다. Member.java public class Member extends BaseTimeEntity { // 속성 ... // @OneToOne(mappedBy = "member", cascade = {CascadeType.PERSIST, CascadeType.REMOVE}, orphanRemoval = true) private MemberCount memberCount; // == 연관관계 로직 == // public void addMemberCount(final MemberCount memberCount) { this.memb..
@Test @DisplayName("데이터베이스에 존재하는 게시판을 10개 조회해온다.") void findAll() { for (int i = 0; i < 10; i++) { Board board = Board.builder() .title(Title.from("테스트 용입니다. " + i)) .content(Content.from("테스트용 Content 입니다. 재미있다아앙")) .build(); boardService.create(board, 1L); } Pageable pageable = PageRequest.of(0, 10, Sort.Direction.DESC, "id"); List boards = boardService.findAll(pageable); assertThat(boards.siz..
1. MySQL 엔지 아키텍처 MySQL 전체구조 MySQL은 일반 상용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 지원한다. MySQL 고유의 C API부터 시작해 JDBC나 ODBC 등응 모든 언어로 MySQL 서버에서 쿼리를 사용할 수 있게 지원한다. MySQL서버는 크게 엔진과 스토리지 엔진으로 구분할 수 있다. 그러면 한 번 살펴보자. MySQL 엔진 MySQL 엔진은 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 sQL 파서 및 전처리기, 퀴리의 최적화된 실행을 위한 옵티마이저가 중심을 이룬다. 또한 MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행될 수 있다. 스토리지 엔진 ..
JPA를 왜 사용하는가? 필자는 블로그 프로젝트와 팀원들과 토이 프로젝트를 진행하며 JPA를 사용해 왔다. 과거에 JPA를 사용하면서 "SQL쿼리를 직접 작성하지 않는다"는 이점만 보고 JPA를 무작정 사용했던 것 같았다. 하지만 JPA는 우리가 생각하는 것 만큼 간단하지 않다. 복잡하지 않은 일반 개인 프로젝트에서는 무난히 사용했을 지 몰라도 복잡한 연관 관계를 갖고 있는 테이블이 있다고 가정해보자 우리는 이를 JPA로 간단하게 처리할 수 있는가? 그렇다면 JPA를 왜 사용하는지 JPA를 사용했을 때의 이점을 정확히 파악하고 우리는 그것을 남들에게 설명할 수 있어야 한다. 그 이유에 대해 먼저 알아보자 SQL을 직접 다룰 때 발생하는 문제점 RDBMS는 가장 대중적이고 신뢰할 만한 안전한 데이터 저장소..
- Total
- Today
- Yesterday
- 자바
- 취업
- docker
- 인터뷰
- 면접준비
- 코딩
- IT
- 게시판
- 취업준비
- Kotlin
- swarm
- 개발자
- Spring
- 프로그래밍
- 면접 준비
- 개발
- 코드
- DevOps
- JPA
- Redis
- 면접
- 동시성
- 취준
- 프로젝트
- thread
- 백엔드
- DB
- MySQL
- java
- CS
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |