Database

TimescaleDB란 ?TimeScaleDB는 PostgreSQL 확장으로 개발된 오픈 소스 시계열 데이터베이스시계열데이터 저장 및 쿼리 성능 최적화하면서도 PostgreSQL의 강력한 기능 유지 핵심 기능 : 하이퍼테이블하이퍼테이블은 사용자에게 하나의 테이블처럼 보이지만, 내부적으로 여러 개의 작은 청크로 분할되어있다.(한마디로 논리적 테이블)쪼개는 최적화 작업이 백그라운드에서 실행이 청크들은 시간 간격, 다른 차원 (id, 위치 등)으로 분할될 수 있다. 장점Chunk pruningWHERE ts BETWEEN ... 같은 시간 필터만 있어도, 해당 범위를 벗어난 chunk는 통째로 스킵 → I/O 크게 절감.병렬 처리 쉬움서로 다른 chunk를 여러 워커가 병렬 스캔 가능(특히 집계/리포트).인덱..

프라이머리 키 값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터링 인덱스라고 한다.중요한 점은 프라이머리 키 값에 의해 레코드의 저장 위치가 결정된다. 따라서 프라이머리 키 값의 변경은 레코드의 물리적 저장위치의 변경을 뜻한다.클러스터링 인덱스는 사실 인덱스라기 보단 레코드의 저장 방식으로 보는게 편하다. (클러스터링 테이블이라고 부름)일반적으로 우리가 사용하는 InnoDB 테이블은 항상 클러스터링 인덱스로 저장되기 때문에 키 기반의 검색이 매우 빠르지만,그에따라 레코드의 저장이나 프라이머리 키의 변경이 상대적으로 느리다. 클러스터링 인덱스 구조 자체는 일반 B-Tree와 비슷하지만, 세컨더리 인덱스를 위한 B-Tree의 리프 노드와는 달리, 클러스터링 인덱스의 리프 노드에는 모든 칼럼이 같이 저장되..

인덱스를 적재적소에 활용하려면, 결국 MySQL이 어떻게 인덱스를 타고 실제 레코드를 읽어내는지에 대해 좀 더 깊이 살펴봐야 한다. 인덱스 레인지 스캔인덱스 레인지 스캔은, 인덱스의 접근 방법 가운데 가장 대표적인 접근 방식이다.B-Tree 인덱스의 필요한 영역을 스캔하는데에는 어떤 작업이 필요할까 ? 다음 쿼리를 예제로 살펴보자SELECT * FROM employees WHERE first_name BETWEEN 'Ebbe' AND 'Gad'; 인덱스 레인지 스캔은, 검색해야할 범위가 결정되었을 때 사용하는 방식이다.위 그림은 "인덱스"를 읽는 경우에 대한 그림인데, 크게 두 가지 과정이 수반된다. 이는 먼저 브랜치 노드를 거쳐 리프노드의 레코드 시작지점을 찾는 과정, 그리고 해당 시작 지점부터 리프노..

B-Tree는 데이터베이스의 인덱싱 알고리즘 중 가장 일반적으로 사용된다.B-Tree는 칼럼의 원래 값을 변형시키지 않고 인덱스 구조체 내에서는 항상 정렬된 상태로 유지한다. 페이지인덱스의 저장방식에 대해 이해하려면 페이지에 대한 이해가 필수이다.페이지는 디스크와 메모리(버퍼풀)에 데이터를 읽고 쓰는 최소 작업 단위이다. 일반적인 인덱스를 포함해 PK와 테이블 등은 모두 페이지 단위로 관리된다.따라서 페이지에 저장되는 개별 데이터의 크기를 최대한 작게 하여, 1개의 페이지에 많은 데이터들을 저장할 수 있도록 하는 것이 중요하다.페이지에 저장되는 데이터가 크기가 클수록 디스크 I/O가 많아지고, 메모리에 캐싱할 수 있는 페이지의 수가 줄어들 수 있다.(디스크I/O를 통해 페이지를 읽어오면 버퍼 풀이라는 메..

인덱스는 데이터베이스 쿼리의 성능을 언급하면서 빼놓을 수 없는 부분이다. 디스크 읽기 방식그전에 인덱스에만 의존적인 용어는 아니지만 자주 언급되는 디스크 읽기 방식인 랜덤 I/O, 순차 I/O에 대해 간단히 알아보자. 컴퓨터의 CPU나 메모리처럼 전기적 특성을 띤 장치는 빠르게 성장했지만 디스크같은 기계식장치의 성능은 제한적으로 발전했다.최근 SSD드라이브가 활용되고 있지만 여전히 데이터 저장 매체는 컴퓨터에서 가장 느린 부분이다.따라서 데이터베이스의 성능 튜닝은 디스크 I/O를 얼마나 줄이느냐가 관건일 때가 상당히 많다. 디스크의 헤더를 움직이지 않고 한 번에 많은 데이터를 읽는 순차 I/O의 경우 SSD가 하드디스크에 비해 거의 비슷한 성능을 보이지만,결국 SSD의 장점은 랜덤 I/O가 빠르다는 것이..

인덱스와 잠금InnoDB 엔진의 레코드 락 부분을 보면, 사실 InnoDB는 레코드를 잠그는 것이 아니라, 인덱스를 잠그는 방식으로 처리하는걸 볼 수 있다.즉, 변경해야 할 레코드를 찾기 위해 검색한 인덱스의 레코드를 모두 잠궈야한다. 이는 인덱스 설계가 중요한 이유와 연결되는데, 예시를 통해 알아보자.SELECT COUNT(*) FROM employees WHERE first_name = "jin"; //253SELECT COUNT(*) FROM employees WHERE first_name = "jin" AND last_name = "hyogyeom; //1 만약 employees 테이블이 first_name 컬럼만을 멤버로 가지는 인덱스를 가지고 있다고 가정해보자.first_name = jin 인..

InnoDB 스토리지 엔진은 이전에 봤던 MySQL 엔진 레벨의 잠금과 별개로, 스토리지 엔진 내부에서 레코드 기반의 잠금방식을 지원한다. 이전에는 InnoDB 스토리지 엔진에서 사용되는 잠금에 대한 정보가 얻기 어려웠는데최근 버전에는 MySQL 서버에 존재하는 information_schema 데이터베이스에 존재하는INNODB_TRX, INNODB_LOCKS, INNODB_LOCK_WATES 라는 테이블을 조인해서 조회 시 확인할 수 있다. InnoDB는 기본적으로 MVCC를 이용한 낙관적인 동시성 제어를 지원하지만특정 상황에 S-Lock, X-Lock을 이용해 비관적인 동시성 제어를 사용한다.X-Lock배타적 락이라고도 불리는 이 잠금은, read/write에 대한 잠금이다.SELECT .. FOR ..

MySQL에서 사용되는 잠금은 크게 스토리지 엔진 레벨과 MySQL 엔진 레벨로 나눌 수 있다. MySQL 엔진 레벨의 잠금은 모든 스토리지 엔진에 영향을 미치지만, 스토리지 엔진 레벨의 잠금은 스토리지 엔진 간 상호 영향을 미치지 않는다. MySQL 엔진에서는 테이블 데이터 동기화를 위한 테이블 락 이외에도 테이블의 구조를 잠그는 메타데이터 락,그리고 사용자 필요에 맞게 사용할 수 있는 네임드 락을 제공하는데, 이번에는 MySQL 엔진 레벨의 잠금에 대해 공부해보았다. 글로벌 락글로벌 락은 MySQL이 제공하는 잠금 중에서 가장 범위가 크다.일단 한 세션에서 글로벌 락을 획득하면, 다른 세션에서 실행한 SELECT를 제외한 대부분의 DDL과 DML이 대기 상태로 남는다.글로벌 락이 미치는 범위는 MyS..

InnoDB 엔진의 버퍼 풀과 LRU에 대해서 공부하였다. InnoDB 버퍼 풀InnoDB 스토리지 엔진에서 가장 핵심적인 부분으로, 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해두는 공간이다.쓰기 작업을 지연시켜 일괄 작업으로 처리해줄 수 있게 해주는 버퍼 역할도 같이 한다. 일반적인 INSERT, UPDATE, DELETE처럼 데이터를 변경하는 쿼리는 디스크 작업을 발생시키기 때문에,버퍼 풀이 이러한 변경된 데이터를 한 번에 모아 디스크 작업의 횟수를 줄일 수 있다. 버퍼 풀의 크기 설정에 대한 내용은 MySQL 5.7부터 inno_buffer_pool_size 시스템변수를 통해 설정할 수 있으며, 동적으로 크기를 확장할 수 있다는 점을 짚고 넘어가겠다. (버퍼 풀의 크기를 동적으로 변경하고..

MySQL의 스토리지 엔진 중 가장 많이 사용되는 InnoDB 엔진에 대해 공부해보았다. InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공하며,그로인해 높은 동시성 처리가 가능하고, 안정적이며 성능이 뛰어나다. 프라이머리 키에 의한 클러스터링InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 저장된다.즉 프라이머리 키 값의 순서대로 디스크에 저장된다는 뜻이며, 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다.(위 내용은 추후 인덱스에서 자세히 다룰 예정) InnoDB와 달리 MyISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않는다. 따라서 프라이머리 키와 세컨더리 인덱스는 구조..