3. 데이터베이스 구조(1) - 해마와 대뇌 피질(cerebral cortex)
데이터베이스의 구조는 컴퓨터의 발전과 함께한다.
우선 간단하게 컴퓨터의 구조를 살펴보자
1. CPU (Central Processing Unit)
ㄴ 컴퓨터의 중앙 처리 장치로, 모든 계산과 논리 연산을 수행한다.
ㄴ 프로그램의 명령어를 해석하고 실행하며, 데이터 처리를 담당하며.
ㄴ 다중코어를 가지고 동시에 여러 작업을 처리할 수 있다.
ㄴ 현재 기준 최대 클럭수는 5GB 가 넘어가며 코어는 64코어가 넘어가고 있다.
2. L1 캐시
ㄴ CPU 내부에 위치한 가장 빠른 메모리로 CPU가 자주 사용하는 데이터와 명령어를 저장하여,
ㄴ CPU가 필요할 때 빠르게 접근할 수 있도록 한다.
ㄴ 용량이 작지만, 속도가 매우 빠르며 일반적으로 L1 캐시는 각 코어마다 별도로 존재한다.
ㄴ 32~64KB 의 용량을 가진다.
3. L2 캐시
ㄴ L1 캐시보다 크고 속도가 느리지만, 여전히 RAM보다 빠르다.
ㄴ CPU와 RAM 사이에서 중간 역할을 하며, CPU가 자주 사용하는 데이터와 명령어를 저장한다.
ㄴ CPU 내부에 위치할 수도 있고, 외부에 위치할 수도 있다.
ㄴ 1MB ~8MB의 용량을 가진다.
4. RAM (Random Access Memory)
ㄴ 컴퓨터의 주기억장치로, 현재 실행 중인 프로그램과 데이터를 저장한다.
ㄴ RAM은 휘발성 메모리로, 전원이 꺼지면 저장된 데이터가 사라진다.
ㄴ 현재 DDR5가 주류를 이룬다.
ㄴ 16,32,64GB의 용량을 가지며 64bit 의 경우 최대 512GB까지 지원한다.
5. SSD (Solid State Drive)
ㄴ 비휘발성 저장 장치로, 데이터를 영구적으로 저장한다.
ㄴ SSD는 하드 드라이브(HDD)보다 훨씬 빠른 데이터 전송 속도를 제공하며,
기계적 부품이 없기 때문에 내구성이 뛰어나고 소음이 적으나 가격이 HDD에 비해 비싸다
ㄴ 하지만 근래 1TB이상의 용량도 많이 저렴해젔다.
전반적으로 데이터베이스에서는 이 이상의 초과지식까지는 개인적인 몫으로 하겠다.
이번에는 뇌의 기억 저장방식을 간단하게 설명하겠다.
일단 인간의 모든 감관으로 전달되는 전기신호를 이미지로 전환 후 "해마"라는 PC의 L캐시와 같은 곳에 저장한다.
RAM과 혼용될 수 있다.
이를 수면시간(특히나 REM수면시간) 에 해마에 있던 기억과 대뇌피질에 있던 과거의 기억(PC의 SSD내 디스크 인덱스 활용하듯)을 index seek 한 후 조합한다.
이때 데이터베이스와(데이터베이스는 기본적으로 FIFO방식이다) 다른것은 뇌 스스로 버려질 기억과 수정될 기억 그리고 강화시킬 기억으로 융합하고 다시 대뇌피질에 저장한다.
이때 과거의 연관 사건이나 이미지가 없을때는 신규로 저장하는데 이때 뇌는 강화의 필요성을 느끼지 못한다.
해서 지속적인 학습이 필요하게 된다.
수면부족이나 숙면을 못하는 경우 이 중요한 작업에 문제가 발생하여 다양한 형태의 이슈가 발생하게 된다.
인간의 뇌는 기본적으로 데이터베이스의 실행계획(parsing) 같은 일을 실행한다.
모든 명령은 캐시를 커처 RAM < SSD 까지 인덱스를 활용(연관 기억에 의존)하여 이루어진다.
예상이 안되는 일이 발생할 시 인간의 뇌는 불안(생명보전 본능)해하고 과거의 기억과 새로운 정보가 충돌(인지부조화)될때 스트레스를 받는 것이다.
멀리 고대 이데아까지 들어갈 필요도 없이 우리 보고 만진다는 생각하는 경험은 사실 보지않고 만지지 않고 예상플랜으로 행동하는 경우가 많을 것이다.
(잘생각해 보라)
데이터베이스는 비록 아직까지는 인간의 뇌보다 수동적이고 보수적이지만 프로세스는 비슷하게 흉내내고 있다.
구조와 메커니즘이나 데이터베이스와 인간의 뇌가 비슷하게 보이지 않는가?
왜 이정도는 알아야 할까?
MS SQL servcer 기준으로 설명하겠다.(여타 DBMS도 거의 동일하므로)
1분 걸리던 쿼리가 1분뒤 다시 실행하니 3초만에 수행이 되었다.
캐시에 저장하기 때문이다.
파싱된 실행계획과 심지어 데이터까지 캐시에 보관한다.
그러므로 2번째 수행한 쿼리는 실제 쿼리 속도라 볼 수 없다.
왜? Buffer Pool에서 바로 가저온 것이니까.. 이해되지?
다른 케이스로는 흔히 튜닝의 주 타겟인 scalar UDF 혹은 SELECT절의 subquery를 보면 1,000,000 row임에도 퍼포먼스에 문제가 없는 경우가 있다.
쿼리가 select절에 scalar형 UDF subquery가 존재할 경우 row별로 그 파라미터값과 플랜 그리고 결과값을 캐시에 저장하고 만약 저장된 값이 존재할 경우 옵티마이저는 캐시에서 그대로 값을 불러온다.
그러므로 100만건이 되더라도 속도에 문제가 없다면 파라미터값이 동일 경우가 대부분으로 캐시 데이터의 사용가능한 경우로 보면된다.
그러므로 scalar형 UDF subquery에서 수행속도의 합은 (파싱속도 + 수행속도) X distinct params 라고 생각하면 되겠다.
이처럼 캐시(Buffer Pool) 를 이용하는 아이디어는 정말 놀라운 생각인 것 같다.
아래 간단하게 캐시와 관련하여 호칭과 기능 및 초기화 명령어를 정리해 보겠다.
(보통의 경우 초기화의 권한은 sysadmin 만이 갖는다.)
1. Microsoft SQL Server
ㄴ Buffer Pool
ㄴ SQL Server는 Buffer Pool을 통해 데이터 페이지와 인덱스를 메모리에 캐시한다.
ㄴ 초기화 명령어 : DBCC DROPCLEANBUFFERS
2. Oracle DB
ㄴ Buffer Cache
ㄴ Oracle DB는 데이터 블록(MS의 page와 같은 의미)을 메모리에 저장하여 디스크 I/O를 줄인다.
ㄴ 자주 접근하는 데이터는 Buffer Cache에 저장된다.
ㄴ 초기화 명령어 : ALTER SYSTEM FLUSH BUFFER_CACHE
3. MySQL
ㄴ InnoDB Buffer Pool
ㄴ InnoDB 스토리지 엔진에서 사용되며, 데이터와 인덱스를 메모리에 캐시한다.
ㄴ 초기화 명령어 : FLUSH TABLES
4. PostgreSQL
ㄴ Shared Buffers
ㄴ PostgreSQL은 Shared Buffers를 사용하여 자주 사용되는 데이터 페이지를 메모리에 저장한다.
ㄴ 초기화 명령어 : DISCARD ALL
PC와 DBMS는 급속도로 빠른 속도로 공진화중이다.
하지만 기본적인 메커니즘은 크게 변경되지 않았다.
철학의 철자도 모르는 사람이 헤겔이나 칸트의 책을 본다고 생각해 보자.
10시간을 읽는다 한들 기억에 남는건 없을 것이다.
인간의 모든 사고의 기반인 기억은 과거 기억을 기반으로 조합하고 통합한다.
성급하게 생각하지말고 기본에 충실하면 이후부턴 기하급수적으로 레벨업이 될 것이다
이 글은 이비니어스( www.evinious.co.kr )의 소유이며 불펌은 허락하지 않습니다.