https://golf-dev.tistory.com/53 Redis INCR을 이용한 분산환경에서의 동시성 제어하기 문제 상황 회사에서 분산환경에서 하루에 한 번만 요청이 가능한 기능이었지만 한 사람이 3번 이상 요청을 보낸 기록이 있어 원인을 찾아보았습니다. 우선 샘플 코드는 다음과 같습니다. fun save( golf-dev.tistory.com 위 글을 보면 Redis의 INCR (increment)은 분산환경에서도 연산의 원자성을 지켜주기 때문에 이 성질을 이용하여 분산환경에서 동시요청에 대한 count를 한 후 일정 count 이상의 요청이 들어오면 해당 요청을 discard 시킬 수 있었습니다. 그렇다면 별 다른 로직 없이 분산환경에서 Redis로 동시성을 제어할 수 있었던 이유는 무엇일까요?..
2000개 WHERE .. IN 절을 처리하는 과정에서 옵티마이저가 Index를 타지 않고 Table Full Scan을 하는 것을 확인했습니다. 이를 방지하기 위해 여러 고민을 하던 와중 FORCE 인덱스를 발견했는데 이에 대해 소개하고 어떤 상황에 쓰면 좋을지 고민해보는 시간을 가져 보겠습니다. 또한 결론적으로 말씀드리면 결국 이 방법이 아닌 다른 방법을 택했는데 그거에 관해서도 소개 드리겠습니다. 또한 모든 설명은 MySQL 기준입니다. FORCE INDEX? FORCE 인덱스는 Query Hint 중 하나로 특정 인덱스를 강제로 사용하도록 합니다. MySQL에서는 적절한 Index를 사용하지 않으면 성능이 저하될 수 있기 때문에 신중하게 선택하여야 합니다. FORCE INDEX는 다음과 같이 사용..

보통 PK로 Join을 하고 보통 우리는 PK로 많이 데이터베이스를 조회합니다. 이러한 이유는 여러가지가 있지만 그 중 논 클러스터링 인덱스와 클러스터링 인덱스의 차이에서 나오는 경우도 있는데요. MySQL을 기준으로 클러스터링 인덱스와 논 클러스터링 인덱스에 대해 알아보겠습니다. 인덱스 페이지 인덱스 페이지는 인덱스 트리의 각 노드에 해당하며, 데이터베이스 시스템은 인덱스 페이지를 사용하여 테이블에서 특정 행을 찾을 수 있습니다. 인덱스 페이지는 키 값에 대한 데이터 위치 정보를 갖고 있기 때문에, 데이터 베이스는 키 값을 인덱스에서 찾은 다음 그 데이터 위치 정보를 활용하여 테이블에서 행을 찾습니다. 인덱스 페이지는 데이터 베이스 시스템의 메모리 내부에 저장될 수도 있고, 디스크에 저장될 수 도 있습..

Index란? 인덱스는 말 그대로 책의 맨 처음 또는 맨 마지막에 있는 색인이라고 할 수 있다. DBMS는 DB 테이블의 모든 데이터를 검색해서 원하는 결과를 갖고 오려면 오래 걸리는데, 이를 빠르게 처리하기 위해 칼럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 인덱스를 만들어 두어 값을 빠르게 탐색한다. 하지만 새로운 값을 추가하거나 삭제, 수정 시 쿼리문 실행 속도가 느려지는데 저장 성능을 희생하고 데이터의 읽기 속도를 높이는데 포커스를 맞춘 것이다. 삽입 삭제 수정 시 정렬이 된 상태로 저장이 되어야하는데 원래 있던 데이터에서 여러가지 변경해야할 비용이 발생하여 이때에는 인덱스는 효율적이지 않다. Index 자료구조 B+ Tree 인덱스 알고리즘 일반적으로 사용되는 인덱스 알고리즘은 B+..

프로젝트를 진행 중에 최근 데이터를 정렬하라는 요구사항에 대해 빠르게 성능을 올리고 싶어 여러가지를 찾아보던 중 커버링 인덱스라는 개념을 발견했다. 인덱스 ? 인덱스는 데이터를 효율적으로 탐색하는 방법이다. 하나의 색인같은 것으로 MySQL 미리 정렬된 상태의 하나의 클러스링된 테이블이 존재하면 이 테이블에 접근하여 빠르게 해당 아이디 값을 찾아가는 방식으로 동작한다. 이 때 성능이 매우 빠르기 때문에 DB 성능향상을 위해 꼭 필요한 기술이다. 커버링 인덱스? 커버링 인덱스 는 쿼리를 충족하는데 필요한 모든 데이터를 갖는 인덱스를 뜻한다.(SELECT/WHERE/GROUP BY/ ORDER BY) 아까 인덱스에서 잠시 언급한 미리 정렬된 상태의 클러스터링된 테이블에 접근하여 데이터를 인덱스 테이블에서 조..

InnoDB는 스토리지 엔진에서 가장 핵심적인 부분이다. 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이고 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 같이한다. 일반적인 애플리케이션에서는 INSERT, UPDATE 그리고 DELETE 처럼 데이터를 변경하는 쿼리는 데이터 파일의 이곳 저곳에 위치한 레코드를 변경하기 때문에 랜덤한 디스크 작업을 발생 시킨다. 하지만 버퍼 풀이 이를 모아서 처리하면 횟수를 줄일 수 있다. 버퍼 풀의 구조 InnoDB 스토리지 엔진은 버퍼 풀이라는 거대한 메모리 공간을 페이지 크기의 조각으로 쪼개어 InnoDB 스토리지 엔진이 데이터를 필요로 할 때 해당 데이터 페이지를 읽어서 각 조각에 저장한다. 버퍼 풀의 페이지 크기 조각을..

InnoDB의 엔진 아키텍처는 다음과 같다. 하나하나 살펴보도록하자!! 프라이머리 키에 의한 클러스터링 InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링 되어 저장된다. 즉, 프라이머리 키 값의 순서대로 디스크에 저장된다는 뜻이며, 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다. 프라이머리 키가 클러스터링 인덱스이기 때문에 프라이머리키를 이용한 레인지 스캔은 상당히 빨리 처리될 수 있다. 하지만 이 기능은 MyISAM에서는 지원하지 않는다. 그래서 프라이머리 키와 세컨더리 인덱스는 구조적으로 아무 차이가 없다. 외래 키 지원 외래 키에 대한 지원은 InnoDB 스토리지 엔진 레벨에서 지원하는 기능으로 MyISAM이나 MEMORY 테이블에..

1. MySQL 엔지 아키텍처 MySQL 전체구조 MySQL은 일반 상용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 지원한다. MySQL 고유의 C API부터 시작해 JDBC나 ODBC 등응 모든 언어로 MySQL 서버에서 쿼리를 사용할 수 있게 지원한다. MySQL서버는 크게 엔진과 스토리지 엔진으로 구분할 수 있다. 그러면 한 번 살펴보자. MySQL 엔진 MySQL 엔진은 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 sQL 파서 및 전처리기, 퀴리의 최적화된 실행을 위한 옵티마이저가 중심을 이룬다. 또한 MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행될 수 있다. 스토리지 엔진 ..
- Total
- Today
- Yesterday
- JPA
- 취업준비
- CS
- Redis
- DB
- 인터뷰
- java
- 게시판
- thread
- 취준
- Spring
- 코딩
- 면접준비
- MySQL
- 백엔드
- 자바
- lock
- Kotlin
- 면접 준비
- IT
- 개발자
- DevOps
- 개발
- 면접
- 프로그래밍
- 동시성
- 취업
- 프로젝트
- docker
- 코드
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |