공부, 기록

MySQL의 잠금은 크게 스토리지 엔진과 MySQL 엔진으로 나눌 수 있다. MySQL 엔진 잠금 글로벌 락 : 가장 범위가 큰 잠금이다. 한 세션에서 해당 잠금을 획득할 경우 다른 세션에서는 대부분의 DDL, DML 문장이 블락 당한다(조회 제외). 즉 범위는 MySQL 서버 전체이며 작업 대상 테이블, 카탈로그 DB가 다르더라고 동일하게 영향을 미친다. 백업 락 : DB 백업을 위해 글로벌 락보다 좀 더 가볍게 잠금을 획득하는 방법. 백업락이 걸릴 경우 오브젝트의 변경(DDL), REPAIR TABLE, OPTIMIZE TABLE, USER 에 대한 수정 등 정보를 변경할 수 없다. 하지만 데이터의 변경의 경우 허용이 된다 (Log에 기록되므로 해당 로그를 추가로 백업하는 과정을 거치면 백업 셋트를 ..

DBMS를 운영하는 과정에서 로그파일을 이해하는 것은 매우 중요한 방식이다. 로그 파일을 통하여 수집, 가공 처리를 통해 모니터링 기능을 구성할 수 있으며 서버의 상태를 빠르게 파악하는 방법 또한 로그 파일을 확인하는 과정을 통하여 가능하다고 생각한다. 이를 위해 MySQL의 로그파일들을 파악할 필요가 있다고 생각한다. 1. 에러 로그 파일 : MySQL이 실행되는 동안 도중에 발생하는 에러, 경고 메시지가 출력되는 로그 파일. (my.cnf 의 log_error 이름의 파라미터로 정의된 경로) 시작하는 과정과 관련된 정보성 및 에러 메시지 마지막으로 종료할 때 비정상적으로 종료된 경우 나타나는 트랜잭션 복구 메시지 쿼리 처리 도중에 발생하는 문제에 대한 에러 메시지 비정상적으로 종료된 커넥션 메시지 (..

InnoDB의 버퍼 풀은 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이다. 데이터 파일에 쓰기 작업을 Lazy하게 일괄 처리할 수 있는 기능도 버퍼의 역할이다. 이로 인해 디스크 Random Access를 줄일 수 있다 (변경된 데이터를 모아서 처리하기 때문에). 버퍼 풀 관리를 위해 InnoDB 스토리지 엔진은 LRU (Least Recently Used), 리스트와 Flush 리스트, Free 리스트 3개의 자료 구조로 관리한다. Free List : 버퍼 풀에서 실제 사용자 데이터로 채워 지지 않은 비어 있는 페이지 목록, 사용자의 쿼리가 새롭게 디스크의 데이터 페이지를 읽어와야 하는 경우 사용. LRU List : 내부적으로 MRU와 LRU로 관리되며 오래될 수록 LRU의 t..

MVCC (Multi-Version Concurrency Control)는 데이터베이스 시스템에서 동시성을 관리하기 위해 사용되는 방법입니다. MVCC의 종류로는 대표적으로 두가지 방법이 존재한다. 1. MGA(Multi Generation Architecture) Perssimistic Lock을 사용하는 로 데이터(튜플)을 replace하지 않고 같은 영역에 추가로 보관해놓고 활용하는 방법이다. 대표적으로 SQL Server는 위의 방법을 택한다. 2. Rollback Segment 위와 달리 데이터(튜플)을 replace하고 별도저장소에 변경전 데이터를 보관해놓고 활용하는 방법이다. oracle, mysql(innodb)가 해당한다. MySQL은 Undo Log를 사용하여 MVCC를 구현. 즉, 변..

컬럼기반의 DBMS는 데이터 저장 효율과 대량 데이터를 처리하는데에 이점이 있다. 어떤 구조로 인해 로우 기반 DBMS에 비해 장점이 생기는지 알아보고자 한다. 로우기반시스템 - 한로우의 여러 컬럼을 동시에 작업할 때 사용. 이때 로우의 길이가 짧고 모든 로우를 해당 디스크에서 한번에 읽어 올 수 있는 구조일수록 효율은 우수 - 모든 컬럼의 값을 동시에 입력해야 할 때 더 효율적. 이 때는 동일한 디스크 블록에 한꺼번에 쓰일 수 있음 컬럼기반시스템 - 데이터중에서 많은 양의 데이터를 집합적으로 분석하거나 많은 컬럼 중에서 분석하려는 몇가지 컬럼에 대해 처리하는 환경에서 유리 - 한번에 모든 로우를 변경하지 않는, 즉 다른 컬럼에게 영향을 주지 않고 특정 컬럼 값을 대체할 때 유리 로우 기반 DBMS에서 ..

새벽에 일어나는 작업 중 임시 테이블을 생성하고 해당 테이블과 서비스 테이블을 조인하여 Seq (Identitiy 값인 PK)를 조건으로 데이터를 삭제하는 내용이 있었다. 어떠한 사유로 해당 작업이 새벽에 진행 중 STOP이 되었고 이를 오전 중 다시 실행하고자 하였다. 삭제 중 Key 기반으로 Lock이 잡혔어야 할 데이터가 Lock 에스컬레이션이 발생하였는지 테이블에 Lock 이 걸렸고 일단 서비스 데이터가 인입되어야 하는 테이블이므로 삭제 작업을 중지하도록 하였다. 롤백이 어느정도 진행되고 금방 중단이 될 것으로 판단했으나 시간이 꽤 지나도 롤백이 완료가 되지 않았고 KILL SESSIONID WITH STATUSONLY 를 통하여 확인하였으나 롤백 진행이 0%에 멈춰있었다. 해당 세션을 죽이기 위..

현재 이슈 내용 1. 데이터가 서비스 초기의 예상보다 점점 커지고 있음. 2. 데이터의 Insert와 Delete가 빈번한 특징이 있음. 3. 대량의 데이터를 삭제하기 위한 배치 작업이 무거움이 있음. 4. 데이터가 여러 타입으로 나뉘는데 그 중 유저당 하나의 값만 가질 수 있는 데이터의 경우 Insert에 시간이 소요가 큼. 개선 방안 1. 데이터를 정책보다 많이 가지고 있는 케이스가 있었고 이를 먼저 해결해야했음(기획, 개발, 사업팀과의 커뮤니케이션을 통한 정책 확인 및 데이터 정리 필요). 2. 삭제의 경우 배치가 가장 문제가 되었었고 이를 작은 트랜잭션 범위로 처리하는 방식을 채택함. 3. 유니크 값을 가져야하는 데이터의 경우 먼저 insert를 진행한 후에 그 뒤에 중복이 되는 데이터를 삭제하는..

신규 프로젝트로 구글 Analytics 처럼 내부 데이터를 Snakey Diagram, Funnel 분석, Segment 분석 등을 할 수 있는 툴을 만들어야했다. 기존에 내부 데이터 통계 툴에 신규 탭으로 추가될 예정이었고 기술 스택도 크게 차이가 없을 것이라 판단했다. (기존 : 스프링부트 + SQL Server) 그러나 해당 툴은 대용량 데이터 (10억건 이상) 의 데이터에 비정규 조건으로 조회가 들어오며 또한 실시간으로 API가 데이터를 반환해주어야했다. 이를 기존의 스택으로 빠르게 응답해주기는 어렵다고 판단하였고.. 대안으로 2가지 방법을 생각해보았다. 1. Spark 를 사용한 데이터 분석 2. 신규 DBMS(통계용)를 스프링부트에 연결하여 분석 1의 경우 파이썬 API 개발을 통하여 PySp..

1. 좌표가 이동될 때 마다 일부 테이블을 전체 스캔하는 케이스. 쿼리에서 조건이 없이 전체 내용을 조회한 후에 현재 좌표에 일치하는 정보를 읽어가는 쿼리였다. 테이블이 크지 않아 reads, duration은 낮은 편이었으나 상대적으로 cpu지표는 높은 편이었다. 해당 서비스의 호출 빈도수가 높아지자 read 지표에서는 이상이 없었으나 cpu가 높아졌다. 내부의 데이터가 동일한 조건으로 전체 테이블을 Scan하는 상황이 발생하여 cpu가 높아지는 것으로 판단하였고. 이를 해결하기 위해 내부 데이터가 거의 COLD 데이터인 점을 활용하여 내부 데이터를 배치성으로 테이블을 생성해두는 방식으로 개선하였다. 데이터의 변경은 이루어지므로 특정시점에 데이터를 temp 테이블로 생성하고 서비스 테이블과 rename..

MySQL의 아키텍처는 크게 MySQL엔진, 스토리지엔진으로 구분할 수 있다. MySQL 엔진은 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서, 전처리기, 옵티마이저가 중심을 이룬다. 스토리지 엔진은 데이터를 디스크 스토리지에 저장하거나 읽어오는 역할을 한다. 스레드 영역 MySQL은 스레드 기반으로 작동한다 (스레드는 특성상 자원을 공유한다) 포그라운드(클라이언트) 스레드와 백그라운드 스레드로 구분한다. 포그라운드 스레드 : MySQL서버에 접속된 클라이언트의 수만큼 존재. 사용을 마치면 스레드 캐시로 돌아간다. 하지만 이미 스레드 캐시에 특정 개수 이상의 스레드가 있으면 스레드 캐시에 넣지 않고 스레드를 종료하는데 이는 시스템 변수로 설정 가능. 데이터를 MySQL의 데이터 버퍼나 캐시로..