개발블로그

비행기 예약 서비스에서 두 사람이 동시에 같은 좌석을 예약한다거나, 온라인 쇼핑몰에서 수량이 1개 남은 상품을 두 사람이 동시에 결제하게 된다면 어떻게 될까? 이처럼 우리가 사용하는 서비스에서 빈번하게 마주할 수 있는 문제를 '동시성 문제'라고 한다. 이러한 상황이 발생하지 않도록 사전에 처리가 필요하다.동시성 제어를 위한 두 가지 접근법으로 비관적 락(Pessimistic Lock)과 낙관적 락(Optimistic Lock)이 있다. 비관적 락(Pessimistic Lock)비관적 락은 '충돌이 자주 발생할 것이다'라는 비관적인 가정에 기반한 제어 방식이다. 데이터에 잠금을 설정해서 다른 사용자가 같은 데이터에 접근할 수 없도록 차단하는 것이다. 원리1. 데이터를 읽거나 수정하기 전에 데이터에 락(Lo..

인덱스 생성 전 실행 계획 -> Merge Left Join (cost=8192.75..441426.93 rows=4386 width=150) (actual time=102.871..9919.006 rows=4154 loops=1) Merge Cond: ((order.user_id)::text = (user.id)::text) ... 생략 -> Materialize (cost=2798.21..425278.44 rows=4075321 width=119) (actual time=79.025..8708.221 rows=4093777 loops=1) -> Merge Left Join (cost=2798...

최근 슬로우 쿼리 로그를 모니터링하던 중, 특정 쿼리의 실행 시간이 1초를 초과하는 것을 발견했다. 이는 우리 서비스의 반응 시간에 직접적인 영향을 미치는 부분이었기에, 즉각적으로 최적화 작업을 하기로 결정했다.이번 글에서는 이 쿼리를 어떻게 분석하고, 실행 시간을 단축시켰는지에 대한 과정을 공유하고자 한다. 초기 쿼리의 문제점초기에 사용했던 쿼리는 다음과 같다. (예시 쿼리를 사용했다)-- 사용자의 클릭 로그를 분석하여 가장 인기 있는 블록을 식별하기 위한 쿼리 작성SELECT b.block_id, b.type, b.content, count(*) as click_countFROM block_log blJOIN block b ON b.block_id = bl.block_idWHERE bl.user_id..

통계 정보테이블 및 인덱스 통계 정보비용 기반 최적화에서 가장 중요한 것은 통계 정보다.테이블의 통계 정보가 자동으로 갱신되도록 할 수도 있고 원할때마다 수동적으로 갱신을 해줄 수도 있다. 통계 정보가 자동으로 갱신되면 인덱스 레인지 스캔으로 처리하던게 어느 날 갑자기 풀 테이블 스캔으로 실행되는 상황이 발생할 수도 있다.통계 정보를 명령을 통해 갱신하려고 한다면 MySQL 사용량이 많지 않은 시간을 이용하는 것이 좋다. 히스토그램히스토그램 도입 이전에는 통계 정보로 테이블 레코드 건수와 인덱스된 칼럼이 가지는 유니크한 값의 개수 정도만 가지고 있었다. 하지만 데이터는 균등한 분포도를 가지지 않는다.히스토그램은 특정 칼럼이 가지는 모든 값에 대한 분포도 정보를 가지지는 않지만 각 범위별로 레코드의 건수와..

쿼리 힌트쿼리 힌트는 인덱스 힌트와 옵티마이저 힌트로 구분할 수 있다. 인덱스 힌트인덱스 힌트는 SQL의 문법에 맞게 사용해야 해서 ANSI-SQL 표준 문법을 준수하지 못하게 되는 단점이 있다. 그래서 가능하다면 인덱스 힌트보다는 옵티마이저 힌트를 사용하는게 좋다. 인덱스 힌트는 SELECT와 UPDATE 명령에서만 사용할 수 있다. - STRAIGHT_JOINSELECT STRAIGHT_JOIN *FROM example1 e1, example2 e2WHERE ...여러 개의 테이블이 조인되는 경우 조인 순서를 고정할 수 있다. FROM 절에 명시된 테이블의 순서대로 조인을 수행하도록 한다. - USE INDEX / FORCE INDEX / IGNORE INDEXSELECT * FROM example ..

쿼리 실행 절차1. SQL 파싱 - SQL 문장을 잘게 쪼개서 MySQL 서버가 이해할 수 있는 수준으로 분리(파스 트리)한다.2. 최적화 및 실행 계획 수립 - 파스 트리를 확인하면서 어떤 테이블/인덱스를 이용할지 선택3. 두 번째 단계에서 결정된 계획으로 작업 수행 옵티마이저의 종류비용 기반 최적화 - 작업의 비용 정보와 예측 통계 정보를 이용하여 실행 계획을 산출하고, 비용이 최소로 소요되는 처리 방식을 선택한다.규칙 기반 최적화 - 같은 쿼리에 대해서는 거의 항상 같은 실행 방법을 만들어낸다. ORDER BY 처리소트 버퍼MySQL은 정렬을 수행하기 위해 별도의 메모리 공간을 할당받아서 사용하는데, 이 메모리 공간을 소트 버퍼라고 한다. 소트 버퍼는 정렬이 필요한 경우에만 할당되고 정렬해야 할 레..

- R-Tree 인덱스공간 인덱스는 R-Tree 인덱스 알고리즘을 이용해 2차원의 데이터를 인덱싱하고 검색하는 목적의 인덱스다. 공간 정보의 검색을 위한 R-Tree 알고리즘을 이해하려면 MBR이라는 개념을 알고 있어야 한다. MBR이란 "Minimun Bounding Rectangle"의 약자로 해당 도형을 감싸는 최소 크기의 사각형을 의미한다.공간 인덱스는 일반적으로는 GPS 기준의 위도, 경도 좌표 저장에 주로 사용된다. 대표적으로는 '현재 사용자의 위치로부터 반경 5km 이내의 음식점 검색'등과 같은 검색에 사용할 수 있다.- 전문 검색 인덱스문서의 키워드를 인덱싱하는 기법에 따라 크게 단어의 어근 분석과 n-gram 분석 알고리즘으로 구분할 수 있다.불용어 처리를 통해 예상하지 못한 토큰들이 걸..

- 디스크 읽기 방식데이터베이스의 성능 튜닝은 어떻게 디스크 I/0를 줄이느냐가 관건일때가 상당히 많다.1. HDD와 SSDSSD의 장점은 기존 하드 디스크 드라이브보다 랜덤 I/O가 훨씬 빠르다는 것이다.2. 랜덤 I/O와 순차 I/O디스크에 데이터를 쓰고 읽는 데 걸리는 시간은 디스크 헤더를 움직여서 읽고 쓸 위치로 옮기는 단계에서 결정된다. 즉 디스크의 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한 번에 기록하느냐에 의해 결정된다.일반적으로 쿼리를 튜닝하는 것은 랜덤 I/O 자체를 줄여주는 것이 목적이라고 할 수 있다. 여기서 랜덤 I/O를 줄인다는 것은 쿼리를 처리하는 데 꼭 필요한 데이터만 읽도록 쿼리를 개선하는 것을 의미한다. - 인덱스란?칼럼의 값과 해당 레코드가 저장된 주소..

- 데이터 암호화MySQL 서버의 암호화 기능은 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다. MySQL 서버에서 사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화돼 있는지 여부를 식별할 필요가 없으며, 암호화된 테이블도 그렇지 않은 테이블과 동일한 처리 과정을 거친다.MySQL 서버의 TDE에서 암호화 키는 키링 플러그인에 의해 관리되고 키링 플러그인은 2단계 키 관리 방식을 사용한다. MySQL 서버의 데이터 암호화는 마스터 키와 테이블스페이스 키라는 두 가지 종류의 키를 가지고 있다. 이렇게 2단계 암호화 방식을 사용하는 이유는 암호화 키 변경으로 인한 과도한 시스템 부하를 피하기 위해서다.MySQL 서버의 암호화는 데이터 페이지가 한 번 메모..

-데이터 압축MySQL 서버에서 디스크에 저장된 데이터 파일의 크기는 일반적으로 쿼리의 처리 성능과도 직결되지만 백업 및 복구 시간과도 밀접하게 연결된다.MySQL 서버에서 사용 가능한 압축 방식은 크게 테이블 압축과 페이지 압축의 두 가지 종류로 구분할 수 있다.페이지 압축페이지 압축은 "Transparent Page Compression"이라고도 불리는데, MySQL 서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고, 반대로 디스크에서 데이터 페이지를 읽어올 때 압축이 해제된다. 여러 가지 문제점들로 인해 많이 사용되지 않는다.테이블 압축테이블 압축은 운영체제나 하드웨어에 대한 제약 없이 사용할 수 있기 때문에 일반적으로 더 활용도가 높다.1. 압축 테이블 생성테이블 압축을 사용하기 ..