#devspace

Buffer Pool

• InnoDB 버퍼 풀은 InnoDB에서 가장 핵심적인 부분
• MySQL 성능 튜닝의 중요한 측면
• innodb_buffer_pool_size로 설정하고, 전체 물리 메모리의 50~80% 수준으로 설정
• 버퍼 풀 메모리는 페이징과 캐시 효율성을 위해 LRU 알고리즘을 사용하는 리스트 형태
• 인덱스 설계에 잘 되어 있지만 슬로우 쿼리가 해결되지 않는다면 이 부분을 의심해 봐야 한다.
• 사용되고 있는 상태 확인 쿼리

SHOW STATUS LIKE '%innodb_buffer_pool%';

innodb_buffer_pool_size

• 버퍼 풀의 크기가 클수록 성능에 유리함
  • 버퍼 풀 메모리가 충분히 큰 양으로 할당되어 있다면 innodb는 인메모리 데이터베이스처럼 동작
• 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간 + 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할
  • SELECT를 위한 캐시 효과가 크다 -> 읽으려는 데이터가 메모리에 올라와 있어 디스크 작업이 발생하지 않기 때문이다!
  • INSERT, UPDATE 및 DELETE와 같이 데이터를 변경하는 쿼리는 디스크 작업을 발생시킴 -> 버퍼 풀이 있다면 이렇게 변경된 데이터를 모아서 처리해서 랜덤한 디스크 작업 횟수를 줄일 수 있다!
  • => 다른 버퍼에 할당하는 메모리를 제외하고는 대부분의 메모리를 버퍼 풀에 할당하는 것이 좋다.

innodb_buffer_pool_chunk_size

• 버퍼풀 사이즈를 결정하는 역할
  • 기본값 = 128M
• 코어 수가 적다면 이 값을 늘려서 버퍼 풀의 크기를 늘려야 함

innodb_buffer_pool_instances

• 인스턴스 수를 늘리면 트랜잭션 간 Lock 경합을 줄일 수 있음
  • MySQL은 멀티 쓰레드 구조 -> 쓰레드 간 버퍼 풀 조작에서 exclusive lock 처리 필요
  • 버퍼 풀 접근을 하기 위해 뮤텍스를 사용하므로 뮤텍스에 대한 경합 발생
  • => 인스턴스 수를 늘릴수록 많은 수의 쓰레드가 동시에 버퍼 풀에 접근하더라도 Lock 경합을 피할 수 있다.
• CPU 코어 수가 많은 시스템일수록 인스턴스 수를 늘릴 수 있다.
  • 인스턴스 수 기본값 = 8

⭐️ 버퍼 풀 크기 = innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances의 배수

innodb_buffer_pool_size를 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances와 같지 않은 값으로 구성하면 버퍼 풀 크기는 자동으로 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances의 배수와 같거나 여러 값으로 조정됩니다.

RealMySQL 8.0 을 읽고 정리했습니다.

InnoDB 스토리지 엔진 아키텍처

InnoDB → MySQL의 스토리지 엔진 가운데

• 가장 많이 사용되고,
• 거의 유일하게 레코드 기반의 잠금을 제공하여 동시성 처리가 가능하고, 안정적이며 뛰어난 성능
• 구조

4.2.1 프라이머리 키에 의한 클러스터링

• InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링 되어 저장 → 즉, 프라이머리 키 값의 순서대로 디스크에 저장되어 → 프라이머리 키에 의한 스캔은 상당히 빨리 처리됨
• 결과적으로 쿼리의 실행 계획에서 프라이머리 키는 다른 보조 인덱스에 비해 높은 비중으로 설정
  • InnoDB 테이블 구조 = 오라클의 IOT(Index Organized Table) 구조

4.2.2 외래 키 지원

• Only InnoDB, not MyISAM과 MEMORY 테이블
• 여러가지 제약사항이 있어 실무에서는 잘 사용하지 않음
• InnoDB의 외래 키는 부모 테이블과 자식 테이블 모두 해당 칼럼에 인덱스 생성이 필요하고, 변경 시에는 반드시 부모 테이블이나 자식 테이블에 데이터가 있는지 체크하는 작업이 필요하므로 잠금이 여러 테이블로 전파되고, 그로 인해 데드락이 발생할 때가 많아서 실무에서 잘 사용하지 않는다.

4.2.3 MVCC(Multi Version Concurrency Control)

• 일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능
• MVCC의 가장 큰 목적은 잠금 없는 일관된 읽기를 제공하는 것 → InnoDB는 언두 로그를 이용해 이 기능을 구현함
• ex) ‘유재석’에서 ‘홍길동’으로 UPDATE

mysql > UPDATE member SET name='홍길동' WHERE member_id='1';

이 때의 상황

1. InnoDB 버퍼 풀 : 수정 후 ‘홍길동'이 반영됨 (레코드 전체)
2. 언두 로그 : 수정 전 ‘유재석'이 반영됨 (PK, 메타정보 및 수정된 칼럼만 백업)

→ 이 때, 커밋이나 롤백이 일어나지 않은 상황에서 2번 사용자가 해당 데이터를 읽으려고 하면 어떻게 될까?

결론 : 격리 수준에 따라 다르다.

• READ_UNCOMMITTED : InnoDB 버퍼 풀이나 데이터 파일로부터 변경된 ‘홍길동' 데이터를 읽어서 반환한다.
• READ_COMMITTED 이상 : 아직 커밋되지 않았기 때문에 언두 영역의 '유재석' 데이터를 반환한다. 이러한 과정을 DBMS 에서는 MVCC 라고 표현한다.

4.2.4 잠금 없는 일관된 읽기(Non-Locking Consistent Read)

• InnoDB 스토리지 엔진은 MVCC를 이용해 INSERT와 연결되지 않은 순수한 SELECT 작업은 락을 걸지 않고, 바로 수행
  • 락을 걸지 않기 때문에 다른 트랜잭션이 갖고 있는 락을 기다리지 않음
  • 읽기 작업 가능(serializable 격리 수준은 제외)
  • lock이 걸려있어도 읽을 때는 언두 영역에서 읽기 때문에 lock이 걸리든 말든 상관없이 이전 버전의 데이터를 읽을 수 있다.

4.2.5 자동 데드락 감지

• InnoDB는 그래프 기반의 데드락 체크 방식을 사용 → 데드락이 발생함과 동시에 바로 감지되고, 감지된 데드락은 관련 트랜잭션 중에서 ROLLBACK이 가장 용이한 트랜잭션(ROLLBACK을 했을 때 복구 작업이 가장 작은 트랜잭션, 즉 레코드를 가장 적게 변경한 트랜잭션)을 자동적으로 강제 종료해 버린다. 따라서 데드락 때문에 쿼리가 제한시간(Timeout)에 도달하거나 슬로우 쿼리로 기록되는 경우는 많지 않다.

4.2.6 자동화된 장애 복구

• InnoDB는 손실이나 장애로부터 데이터를 보호하기 위한 여러 가지 매커니즘이 탑재!
  • MySQL 서버가 시작될 때, 완료되지 못한 트랜잭션이나 디스크에 일부만 기록된 데이터 페이지(Partial write) 등에 대한 일련의 복구 작업이 자동으로 진행된다.

4.2.7 InnoDB 버퍼 풀

• InnoDB에서 가장 핵심적인 부분
• innodb_buffer_pool_size 로 설정, 전체 물리 메모리의 50~80% 수준으로 설정
• 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간 + 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할 → INSERT나 UPDATE 그리고 DELETE와 같이 데이터를 변경하는 쿼리는 디스크 작업을 발생시킴 → 버퍼 풀이 있다면 이러한 변경된 데이터를 모아서 처리하게 되면 랜덤한 디스크 작업의 횟수를 줄일 수 있다!
• 아직 디스크에 기록되지 않은 변경된 데이터를 가지고 있다. → 이러한 데이터를 가지고 있는 페이지를 더티 페이지(Dirty page)
• 더티 페이지는 InnoDB에서 주기적으로 또는 어떤 조건이 되면 체크포인트 이벤트가 발생하는데, 이때 Write 스레드가 필요한 만큼의 더티 페이지만 디스크로 기록한다. 체크포인트가 발생한다고 해서 버퍼 풀의 모든 더티 페이지를 디스크로 기록하는 것은 아니다.

4.2.8 Double Write Buffer

• 파셜 페이지(Partial-page) or 톤 페이지(Ton-page) : 페이지가 일부만 기록되는 현상, 하드웨어 오작동이나 시스템 비정상 종료 등으로 발생함
• InnoDB의 리두 로그는 공간의 낭비를 막기 위해 페이지의 변경된 내용만을 기록함 → 이로 인해 InnoDB에서 더티 페이지를 디스크 파일로 플러시할 때 일부만 기록되는 문제가 발생하면 해당 페이지는 복구가 어려울 수도.. → 이를 막기 위해 Double Write 기법을 이용!

4.2.9 언두(Undo) 로그

• ex) ‘유재석’에서 ‘홍길동’으로 UPDATE

mysql > UPDATE member SET name='홍길동' WHERE member_id='1';

• 언두 영역 : when? UPDATE나 DELETE 문장으로 데이터를 변경했을 때 why? 변경되기 전의 데이터를 보관하고자 사용
• 언두 데이터 : ex) 언두 데이터 ‘유재석’ why?

1. 트랜잭션의 rollback 대비용
2. 트랜잭션의 격리 수준을 유지하면서 높은 동시성 제공해줘서
   • 트랜잭션의 격리 수준 : 동시에 여러 트랜잭션이 데이터를 변경하거나 조회할 때, 한 트랜잭션의 작업 내용이 다른 트랜잭션에 어떻게 보여질지를 결정하는 기준

4.2.10 체인지 버퍼

• 인덱스 변경에 따른 자원 소모를 줄여주는 임시 메모리 공간

탄생 배경

• 🧐 문제 : INSERT나 UPDATE 될 때 데이터 파일을 변경하는 작업 + 해당 테이블에 포함된 인덱스를 변경하는 작업 이 필요 →해당 테이블에 포함된 인덱스를 변경하는 작업 은 랜덤하게 디스크를 읽는 작업이 필요하므로 테이블에 인덱스가 많다면 상당히 많은 자원을 소모
• 😃 해결 : 인덱스를 변경해야 한다면, 즉시 실행하지 않고 임시 공간에 저장해 두고 바로 사용자에게 반환하는 형태로 성능을 향상! → 이 때 사용하는 임시 메모리 공간 = 체인지 버퍼

특징

• 반드시 중복 여부를 체크해야 하는 유니크 인덱스는 체인지 버퍼를 사용할 수 없음
• 체인지 버퍼에 임시로 저장된 인덱스 레코드 조각은 이후 백그라운드 스레드에 의해 병합됨 → 이를 체인지 버퍼 머지 스레드 라고 함

4.2.11 리두(Redo) 로그 및 로그 버퍼

데이터 파일을 변경하는 것은 랜덤하게 디스크에 기록해야 하므로 비용이 비싼 작업이다. → 이 작업을 모아서 처리하여 성능을 향상하기 위해 InnoDB 버퍼 풀 같은 장치가 있음

BUT! InnoDB 버퍼 풀 만으로는 ACID를 보장할 수 없어서 → 순차적으로 디스크에 기록하는 로그 파일을 생성 = 리두 로그 (일반적으로 로그를 지칭함) 너무 많은 변경이 일어나면 리두 로그에 기록하는 것도 큰 문제가 되어서 보완하고자 = 로그 버퍼 로그 버퍼의 크기 = 일반적으로 1~8MB 수준, BLOB나 TEXT와 같이 큰 데이터를 자주 변경하는 경우는 더 크게 설정

4.2.12 어댑티브 해시 인덱스

• InnoDB에서 사용자가 자주 요청하는 데이터에 대해 자동으로 생성하는 인덱스
• innodb_adaptive_hash_index : 시스템 변수를 이용해서 활성화 및 비활성화

도입 목적

• B-Tree의 검색 시간을 줄여주기 위해

작동 방식

• 자주 읽히는 데이터 페이지의 키 값을 이용해 변수 생성
• 필요할 때마다 어댑티브 해시 인덱스를 검색해서 레코드가 저장된 데이터 페이지로 가기
• → 장점! B-Tree를 루트 노드부터 리프 노드까지 찾아가는 비용이 없어지고, CPU는 적은 일을 하지만 쿼리 성능은 빨라져서 동시에 더 많은 쿼리를 처리함

특징

• (key, value) = (’인덱스 키 값’, 해당 인덱스 키 값이 저장된 ‘데이터 페이지 주소’)
• 인덱스 키 값 = ‘B-Tree 인덱스 고유번호(ID)와 B-Tree 인덱스 실제 키 값’ 조합
• 인덱스 키 값에 ‘B-Tree 인덱스의 고유번호’가 포함되는 이유 → InnoDB에서 어댑티브 해시 인덱스는 하나만 존재하기 때문이다. 즉, 특정 키 값이 어느 인덱스에 속한 것인지 구분하기 위해서!

RealMySQL 8.0 을 읽고 정리했습니다.

4.1.1 전체 구조

MySQL 서버 = 사람의 머리 역할을 담당하는 MySQL 엔진 + 손발 역할을 담당하는 스토리지 엔진

MySQL 엔진

1. 커넥션 핸들러 : 클라이언트로부터 커넥션 및 쿼리 요청을 처리
2. SQL 인터페이스 : DML, DDL, Procedure, View 등 SQL 인터페이스 제공
3. SQL 파서 : SQL 문법 오류 탐지 및 SQL 쿼리 문장을 MySQL이 처리하기 좋은 토큰 단위로 나눠서 트리 형태로 파싱하는 작업 담당
4. SQL 옵티마이저 : 쿼리의 최적화된 실행을 담당
5. 캐시 & 버퍼 : 성능 향상을 위한 보조 저장소 기능 담당

스토리지 엔진

• 핸들러 API를 만족하면 누구든지 스토리지 엔진을 구현하여 MySQL을 추가하여 사용할 수 있음
• 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분

💡 MySQL 엔진은 하나지만 스토리지 엔진은 여러 개를 동시에 사용할 수 있음

다음 예제와 같이 테이블이 사용할 스토리지 엔진을 지정하면 이후 테이블의 모든 읽기 작업이나 변경 작업은 정의된 스토리지 엔진이 처리한다.

mysql > CREATE TABLE test_table (fd1 IT, fd2 INT) ENGINE = INNODB;

핸들러 API

MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에게 쓰기 또는 읽기를 요청하는데, 이러한 요청을 핸들러(Handler) 요청이라고 하고, 여기서 사용되는 API를 핸들러 API라고 한다.

4.1.2 MySQL 스레딩 구조

MySQL은 프로세스 기반이 아니라 스레드 기반으로 작동하며, 크게 포그라운드 스레드 + 백그라운드 스레드

포그라운드 스레드(클라이언트 스레드)

• MySQL 서버에 접속된 클라이언트의 수만큼 존재
• 주로 클라이언트가 요청하는 쿼리 문장을 처리(고객 창구 역할)
• 사용자가 작업을 마치고 커넥션을 종료하면, 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시(Thread pool)로 되돌아간다.
  • 이미 스레드 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면 스레드 캐시에 넣지 않고 스레드를 종료시켜 일정 개수의 스레드만 스레드 캐시에 존재하게 한다.
  • 스레드의 개수를 일정하게 유지하게 만들어주는 파라미터 = thread_cache_size

백그라운드 스레드

• Insert buffer 를 병합하는 스레드
• 로그를 디스크로 기록하는 스레드
• InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
• 데이터를 버퍼로 읽어들이는 스레드
• 그리고 기타 여러 가지 잠금이나 데드락을 모니터링 하는 스레드
• 모든 백그라운드 스레드를 관리하는 메인 스레드

가장 중요한 것은 **로그 스레드(Log thread)**와 버퍼의 데이터를 디스크로 내려쓰는 작업을 처리하는 쓰기 쓰레드

읽기 / 쓰기 쓰레드의 개수를 지정하는 파라미터 = innodb_write_io_threads / nodb_read_io_threads

4.1.3 메모리 할당 및 사용구조

글로벌 메모리 영역

• MySQL 서버가 시작되면서 운영체제로부터 할당된다.
• 하나의 메모리 공간만 할당된다. 모든 스레드에 의해 공유된다.

로컬(세션) 메모리 영역

• MySQL 서버 상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역, 서버와의 커넥션을 세션 이라고 하기 때문에 세션 메모리 영역 이라고도 한다.
• 각 클라이언트 스레드 별로 독립적으로 할당되며 절대 공유되지 않는다.

4.1.4 플러그인 스토리지 엔진 모델

MySQL의 독특한 구조 중 대표적인 것이 바로 플러그인 모델이다!

• 사용자 인증 방식, 검색 엔진, 스토리지 엔진 등을 플러그인 형태로 개발해서 사용할 수 있다.
• 핸들러 API MySQL 엔진의 쿼리 실행기는 스토리지 엔진이 제공하는 API를 이용하여 스토리지 엔진에게 CRUD 작업을 위임한다. → 이 때, 스토리지 엔진이 제공하는 API = 핸들러 API
• 플러그인 모델 핸들러 API 규칙을 만족하도록 구현하면 누구든지 스토리지 엔진을 만들어서 MySQL 서버에 추가해서 사용할 수 있다.
• 대부분의 작업은 엔진에서 처리가 되며, 마지막인 “읽기/쓰기” 만이 스토리지 엔진에서 처리하게 된다.
  • GROUP BY, ORDER BY 등 복잡한 쿼리도 MySQL 엔진에서 처리하므로 실제로 데이터 읽기/쓰기 기능은 작아보이겠지만, 처리 방식이 얼마나 많이 달라질 수 있는지 알 수 있게 될것이다.
• 쿼리 작업은 여러 하위 작업으로 나뉘는데, 이 작업에서 MySQL 엔진 영역과 스토리지 엔진 영역의 차이를 아는 것이 중요하다.

4.1.5 컴포넌트

• MySQL 8.0 에 기존 플러그인 아키텍처를 대체하기 위함
• 플러그인의 단점을 보완해서 구현됨
• INSTALL COMPONENT  를 통해서 컴포넌트를 설치하고 관련 새로운 시스템 변수를 설치하면 된다.
• MySQL 서버 플러그인의 단점
  1. 오직 MySQL 서버와 인터페이스 할 수 있고, 플러그인끼리 통신할 수 없다.
  2. MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않다. (캡슐화 안 함)
  3. 플러그인은 상호 의존 관계를 설정할 수 없어서 초기화가 어렵다.

4.1.6 쿼리 실행 구조

• 쿼리 파서(Parser) : 쿼리 문장에 대해서 문법(Syntax) 확인을 하고 쿼리 문장을 적절한 단위로 분할하여 파서 트리(parser tree)를 만든다.
• 전처리기(Pre-processor) : 앞에서 만들어진 파서 트리를 보고 구조적으로 문제가 있는지 확인한다. (예를 들면, 존재하지 않는 테이블이나 컬럼 등에 접근한다거나 접근하려고 보니 권한이 없다거나 하는 등)
• 옵티마이저(Optimizer) : 요청받은 쿼리를 어떻게 하면 가장 적은 비용으로 빠르게 → 즉, 최적으로 처리할지 결정한다.
  • 앞으로 개발자가 해야할 일은 이 옵티마이저가 더 나은 결정을 할 수 있도록 쿼리를 작성하는 것 = 실행 계획 생성
• 실행 엔진 : 옵티마이저에 의해 결정된 실행 계획대로 핸들러에게 지시한다.
  • ex) 임시 테이블 만들어 → where 조건대로 레코드 읽어와 → 읽은 레코드를 임시 테이블에 써라 → …
• 핸들러(스토리지 엔진) : MySQL 서버의 가장 밑단에서 실행 엔진이 내린 지시대로 작업을 수행한다.

4.1.7 복제

• 복제(Replication) = 2대 이상의 MySQL 서버가 동일한 데이터를 담도록 실시간 동기화하는 기술
• 데이터베이스의 데이터가 갈수록 대용량화 되어 가는 것을 생각하면 확장성(Scalability)는 DBMS에서 아주 중요한 요소
• MySQL의 복제는 거의 2000년도부터 제공됐기 때문에 타 DBMS의 복제보다 훨씬 이전부터 제공된 기능이며 또한 그만큼 안정적

• 마스터 서버(INSERT/UPDATE 이용, Primary) + 슬레이브 서버(SELECT만 가능, Secondary)
  • 마스터는 반드시 1개, 슬레이브는 1개 이상이지만 서버 하나로 마스터이면서 슬레이브도 수행하도록 설정하는 것도 가능
  • 단지 서버의 역할 모델을 지칭하는 것일뿐!
  마스터 서버
  1. 마스터에 쓰인 데이터를 슬레이브에 “복제"하여 데이터를 동기화한다.
  2. 마스터 서버는 복제를 위해서 MySQL 바이너리 로그를 활성화해서 남겨야 한다.
     1. 바이너리 로그에는 DML(데이터를 조작하는 문장)과 DDL(스키마를 변경하는 문장)이 기록됨
  슬레이브 서버
  1. 슬레이브 서버는 **마스터 서버에 접속할 정보(IP, Port, 계정)**를 가지고 있으면 된다.
  2. 마스터 서버로 동기화 요청을 하고 받아온 내역을 릴레이 로그에 기록한다.
     1. 참고로 바이너리 로그와 릴레이 로그는 내용이 동일하다.
• 🚨 복제시 주의사항
  1. 슬레이브는 하나의 마스터만 설정 가능
  2. 슬레이브는 항상 읽기 전용
  3. 마스터 장비와 슬레이브 장비 사양은 동일한 것으로 사용
  4. 복제가 불필요한 경우 바이너리 로그 중지(바이너리 로그 작성은 비용이 굉장히 큰 작업)
  5. 바이너리 로그와 트랜잭션 격리 수준(isolation level)
     1. 바이너리 로그 파일은 어떤 내용이 기록되느냐에 따라 STATEMENT 포맷 방식과 ROW 포맷 방식
     • STATEMENT 포맷 : 마스터에서 실행되는 쿼리 문장 기록
     • ROW 포맷 : 마스터에서 실행된 쿼리에 의해 변경된 레코드 값을 기록

4.1.8 쿼리 캐시

• 쿼리(SQL)를 캐시하지 않고, 쿼리 결과를 메모리에 캐시한다.
• 쿼리 캐시는 key, value 쌍의 맵(Map) 같은 자료구조로 되어있다.
• MySQL에만 있는 기능이며, 생각보다 효율적이지 않은 경우가 많다.
• 🔽 쿼리 캐시 확인 절차
  1. 요청으로 들어온 문장이 쿼리 캐시에 존재하는가? (공백, 대소문자 등 완벽하게 일치해야)
  2. 사용자의 권한은 충분한가?
  3. 트랜잭션 내에서 실행된 쿼리면, 결과도 같은 가시 범위 내의 트랜잭션에서 만들어진 결과인가?
     1. 가시 범위 : 자신의 트랜잭션 아이디보다 작은 것(자신의 트랜잭션보다 이전에 실행된 트랜잭션)만 확인 가능한 조건
  4. 쿼리에 사용된 기능이 캐시돼도 동일한 결과를 보장할 수 있는가?
  5. → CURRENT_DATE, SYSDATE, RAND 같이 호출 시점에 따라 달라지는 요소가 있는지?, 변수가 결과에 영향을 미치는지?
  6. 캐시 생성 후 해당 데이터에 변경이 있었는지?
  7. 쿼리 결과가 너무 큰 데이터는 아닌지?
  8. 쿼리 캐시를 사용하지 못하게 하는 요소가 있는지?
     1. 캐시할 수 없는 요소
     • 임시 테이블에 대한 쿼리
     • 사용자 변수 사용한 쿼리
     • 컬럼(column)기반 권한 설정
     • LOCK IN SHARE MODE 힌트
     • FOR UPDATE 힌트
     • User Defined Function 사용
     • 독립적인 SELECT 문이 아닌 일부분의 서브 쿼리
     • Stored Procedure, Function, Trigger에서 사용한 쿼리
     • SQL_NO_CACHE 힌트

  🧐 복잡한 쿼리 캐시 확인 절차(이 밖에도 더 있음)가 있기에 캐시 적중률이 떨어질 수 있고, 
  쿼리 결과가 너무 크면 캐시를 비우는데도 오버헤드가 걸리므로 
  전체적으로 보았을 때 과연 효율적인가에 대해서는 사용 환경을 잘 따져봐야 할 필요가 있다…
  

4.1.9 스레드 풀

일정량의 스레드를 미리 생성해놓고, 스레드가 필요할 때 미리 생성된 스레드를 제공하는 방식 → why? 요청마다 스레드를 생성하는 경우 오버헤드가 많이 발생하기 때문에 이를 줄이고자!

• 발생하는 오버헤드
  • 스레드 생성, 제거
  • context switching
  • 스레드 스케줄링
• Enterprise 버전 : 스레드 풀 제공 Community 버전 : 제공 X → Percona Server 사용하면 됨..

4.1.10 트랜잭션 지원 메타데이터

• 메타데이터 : DB 서버에서 테이블의 구조 정보, 스토어드 프로그램 등의 정보
• 메타데이터들을 InnoDB에 저장

활용 예제

Counting

Strings

• 단순 증감 연산
• INCR / INCRBY / INCRBYFLOAT / HINCRBY / HINCRBYFLOAT / ZINCRBY

Bits

• 데이터 저장공간 절약
• 정수로 된 데이터만 카운팅 가능
  • userid 값이 0 이상의 정수값일 때만 카운팅이 가능
  • 시퀀셜한 값이 없을 때에는 사용 불가
• SETBIT / BITCOUNT

HyperLogLogs

• 대량의 유니크한 데이터를 카운팅할 때 적절
• set과 비슷하지만 저장되는 용량이 매우 작음
• 웹사이트에 방문한 유니크한 IP 수 / 하루 종일 크롤링한 URL 수 / 검색엔진에서 검색된 유니크한 단어 수
• PFADD / PFCOUNT / PFMERGE

Messaging

Lists

• 자체적으로 blocking 기능을 제공해서 Event Queue로 사용 → 불필요한 polling을 막을 수 있음
• 키가 있을 때만 저장 가능 - LPUSHX / RPUSHX

Streams

• 로그 저장
• append-only
• 시간 범위 검색 / 신규 추가 데이터 수신 / 소비자별 다른 데이터 수신(소비자 그룹) - kafka에서 차용
• 메시징 브로커 역할
• XADD : hash처럼 key-value 쌍으로 저장

장애 포인트

Redis는 Single Thread 라는 점을 잊지 말자!

• keys * → scan으로 대체
• 오래 걸리는 커맨드는 사용하지 말자
• hash, sorted set 쓸 때 하나의 키에 100만개 이하로만 담자
• Flush All : 키 다 날려버리기 → 이거 하는 동안 다른거 못함

Replication

• replicaof 커맨드로 간단하게 복제 연결
• 비동기식 복제
• Master가 다운되더라도 Replica가 서비스를 계속 할 수 있음
• HA 기능이 없으므로 장애 상황 시 수동 복구
  • replicaof no one
  • 서버 다운시 AOF 또는 RDB로 재시작
• replication 과정에서 fork가 발생하므로 메모리 부족 발생 가능
• 특정 커맨드 disable 하기

Sentinel

센티널은 일반 노드들을 실시간으로 모니터링(monitoring)하는 역할

자동 페일오버 가능한 HA 구성

• 마스터가 비정상이면 자동 페일오버(Automatic Failover)
• 연결 정보 변경 필요 없음
• 센티널 노드는 항상 3대 이상, 홀수로 존재해야 함
  • 과반수 이상의 센티널이 동의해야 페일오버 진행
  • 예) 네트워크의 잠깐의 오버타임 때문에 마스터 노드가 죽었다고 생각하는 하나의 센티널이 있다고 가정할 때, 과반수 이상의 센티널이 "OK"해야 비로소 그 마스터 노드는 죽은 것이고, 그때 Replica에서 마스터 노드를 선출한다.
• 알림 : 감시하고 있는 인스턴스가 페일오버 되었을 때 Pub/Sub으로 애플리케이션(클라이언트)에게 알리거나 shell script로 관리자에게 이메일이나 SMS으로 알림 가능

Cluster

스케일 아웃과 HA 구성

• 키를 여러 노드에 자동으로 분할해서 저장 (샤딩)
• 모든 노드가 서로를 감시하며 마스터 비정상 상태일 때 자동 페일오버
• 최소 3대의 마스터 노드 필요

아키텍처 선택 기준