기억해야 할 개념들(2)

1. 속도 비교

덧셈 연산, 동일 내용 검색, EBS I/O, S3 I/O 중 속도 차이를 비교해보자.

먼저,크게 두분류로 나눌 수 있다.

• CPU 기반 연산: 덧셈 연산, 동일 내용 검색. 이들은 CPU와 메모리를 주로 사용하며, 매우 빠른 처리가 가능하다.
• I/O 기반 작업: EBS I/O, S3 I/O. 이들은 데이터 저장소(디스크, 네트워크 스토리지)를 액세스하는 작업으로, CPU보다는 느린 입출력 처리이다.

자 이제, EBS I/O, S3 I/O를 비교해보자.

 

AWS S3 vs EBS 성능 및 용도 차이

현직에서는 S3와 EBS 선택에 대한 고민이 많다고 한다.

• Amazon EBS는 EC2 인스턴스에 블록 레벨 스토리지로 붙어 있어 지연 시간과 IO 성능이 낮고 빠르다. 
• Amazon S3는 오브젝트 스토리지로서 대량의 데이터를 저장하는데 적합하며 확장성이 좋지만, 네트워크를 통해 접근하므로 지연 시간이 상대적으로 높고 IO 속도가 느리다.

EBS는 대략 S3 대비 10배 이상 빠른 IO 성능을 보이며, 특히 SSD 기반 EBS는 높은 IOPS와 일관된 저지연을 제공한다. 

S3는 높은 가용성, 내구성, 확장성을 제공하지만 낮은 지연을 요구하는 작업에는 적합하지 않다. 

따라서, EBS가 S3보다 속도측면에서 적합하다. 

이번에는 덧셈 연산, 동일 내용 검색를 비교해보자.

 

동일 내용 검색 vs 덧셈 연산

동일 내용 검색(인메모리 캐시 같은)과 덧셈 연산(CPU 연산)은 둘 다 매우 빠른 작업이지만 속도 차이가 있다.

• 덧셈 같은 CPU 연산은 메모리 내 데이터에 대해 즉시 처리되므로 매우 빠르다. CPU 파이프라인에서 직접 수행돼 지연이 거의 없다.
• 동일 내용 검색은 인메모리 캐시 조회 방식이라 메모리 접근이 필요하므로 CPU 연산보다 느릴 수 있다. 

 

따라서 속도 순서는 덧셈 연산(가장 빠름) > 동일 내용 검색(메모리 기반, 약간 느림) > EBS 스토리지 IO > S3 스토리지 IO 순이 된다.

 

2. 스택과 큐의 차이

 

스택과 큐는 데이터가 삽입되고 삭제되는 순서에서 근본적인 차이가 있다.

스택은 후입선출(LIFO, Last In First Out) 구조로 가장 마지막에 들어온 데이터가 가장 먼저 나간다.

예를 들어 함수 호출에서 가장 최근에 호출된 함수가 먼저 반환되는 흐름과 일치한다. 삽입과 삭제가 모두 스택의 한쪽 끝(top)에서 이루어져 간단하고 효율적

큐는 선입선출(FIFO, First In First Out) 구조로 가장 먼저 들어온 데이터가 가장 먼저 나간다. 작업 대기열이나 프린터 대기처럼 처리 순서가 도착 순서와 같아야 하는 상황에 적합하며, 삽입은 한쪽 끝(rear)에서, 삭제는 반대쪽(front)에서 이루어진다.

 

스택 프레임에서 스택을 사용하는 이유는 함수 호출과 종료 과정에서의 흐름을 자연스럽게 관리하기 위해서이다. 함수가 호출되면, 해당 함수의 지역 변수, 매개변수, 반환 주소 등의 정보를 스택 프레임이라는 하나의 블록에 저장한다. 그리고 이 스택 프레임들은 위에서 아래로 차곡차곡 쌓이게 되는데, 이것이 바로 스택 자료구조의 후입선출 특성과 일치하기 때문이다. 함수가 종료되면 가장 마지막에 호출된 함수의 스택 프레임부터 제거하면서 되돌아오게 되는데, 이 과정이 스택 구조와 동일하다.

반면, 대기 큐 또는 실행 큐는 여러 작업이 순서대로 쌓이고 처리되어야 하는 작업 대기 상태를 관리하는 자료구조. 여기서 큐를 사용하는 이유는 요청이 들어온 순서대로 공정하게 처리하려는 목적 때문이다. 요청이 먼저 들어온 작업이 먼저 처리되어야 하므로, 선입선출 구조인 큐를 사용하는 것이다. 대기열이나 프린터 작업 큐는, 작업 요청 순서 보장이 중요하기 때문에 큐가 적합하다.

 

즉, 함수 호출과 같은 흐름에서는 호출-복귀 순서가 자연스럽게 LIFO 구조인 스택이 적합하며, 작업 대기나 요청 처리 등에서는 순서대로 처리하는 FIFO 구조인 큐가 적합한 것이다.

추가로, 함수 호출-반환 흐름이 후입선출인 이유는 함수 실행의 특성 때문이다. 한 함수가 다른 함수를 호출하면 호출된 함수는 호출한 함수가 종료될 때까지 실행을 멈춘다. 그래서 가장 마지막에 호출된 함수가 먼저 실행을 끝내고 반환되어야 하며, 이를 통해 이전 함수로 다시 돌아올 수 있다.

 

3. 쿼리 실행

 

DBMS에 쿼리를 날리면 내부적으로 쿼리가 어떤 순서로 실행될까?

 

쿼리 실행 과정

 

1. 파싱
   • DBMS는 해당 SQL이 쿼리 문법과 구조가 맞는지 검증한다. 
2. 분석 및 검증
   • 쿼리가 의미적으로 맞는지, 테이블 및 컬럼이 존재하는지, 접근 권한이 있는지를 확인한다.
3. 논리적 실행 계획 수립
   • 쿼리의 요구사항을 충족하는 논리적 데이터 처리 절차를 수립. 즉, 어떤 테이블을 어떻게 탐색하고 조인할지에 대한 계획을 옵티마이저가 세운다.
4. 쿼리 최적화 (옵티마이저)
   • 여러 실행 계획 후보 중에서 가장 비용이 적고 효율적인 실행 경로를 선택한다.
5. 물리적 실행 계획 생성 및 실행
   • 최적화된 계획에 따라 DB 엔진이 데이터를 실제로 조회, 필터링, 조인, 집계하여 결과를 만든다.
   • 이때 인덱스, 버퍼캐시, 파티셔닝, 병렬 처리가 활용될 수 있다.
6. 결과 반환 
   • 최종 데이터를 클라이언트에 반환

 

옵티마이저

 

가장 효율적인 방법으로 SQL을 수행할 최적의 처리 경로를 생성해주는 두뇌역할. 개발자가 SQL을 작성하고 실행하면 옵티마이저에서 "이 쿼리문을 어떻게 실행 시키겠다" 라는 실행 계획을 세운다. 각 실행 계획의 예상 비용을 산정한 후 각 실행 계획을 비교하여 가장 효율적인 실행 계획에 따라 수행된다.

여러 실행계획을 "만들고" 그 중에서 최적의 실행계획을 "고르는" 과정이 모두 옵티마이저 안에서 이루어진다.

여러 실행계획을 미리 만들어둔 상태에서 고르는 게 아니라,

주어진 쿼리와 통계 정보를 기반으로 실행계획 후보들을 생성하는 단계 + 후보 중 가장 효율적인 계획을 선택하는 단계가 순차적으로 진행 된다.

비용은 CPU, 메모리, 디스크 I/O 등을 고려한다. 이에 따라, 인덱스 사용 여부, 조인 순서, 데이터 필터링 방법 등이 결정

 

옵티마이저의 종류

	특징	장점	단점
규칙 기반 옵티마이저	사전에 정의된 규칙과 우선순위에 따라 실행 계획을 생성 우선순위에 의해 액세스 경로를 선택하며, 인덱스가 존재하면 항상 인덱스를 우선 사용	실행 계획이 규칙적이고 예상 가능	통계정보를 고려하지 않아 실제 비용이 높은 계획을 선택할 수 있다. 복잡한 쿼리에는 한계
비용 기반 옵티마이저	쿼리 실행에 드는 비용(소요시간, 자원 사용량)을 예측하여 최소 비용이 드는 실행 계획을 선택 통계 정보(테이블, 인덱스, 칼럼 분포 등)를 통해 현실적이고 효율적인 계획을 수립 질의 변환기, 대안 계획 생성기, 비용 예측기 모듈로 구성	통계 정보 기반으로 더 효율적인 실행 계획을 수립할 수 있어, 복잡한 쿼리에도 적합	실행 계획의 예측과 제어가 어렵다.

현재 대부분 상용 DBMS는 비용 기반 옵티마이저를 사용하며, Oracle DB의 경우 10v 이후부터 규칙 기반 옵티마이저 지원이 중단됨

 

쿼리 속도 개선 방향

 

1. 인덱스 사용
   
   • WHERE 절에 자주 사용되는 컬럼이나, 정렬에 사용되는 컬럼에 인덱스를 만들어야 한다.
   • 인덱스 생성 시에는 데이터베이스 크기와 인덱스 크기를 고려하며, 너무 많은 인덱스 생성은 지양
2. 적절한 JOIN 사용하기
   
   • INNER JOIN은 성능이 뛰어나고, OUTER JOIN은 불필요한 행까지 탐색할 수 있어 성능 저하 가능
   • JOIN 순서와 조건 최적화, 불필요한 JOIN은 제거
3. 서브쿼리 최소화하기
   • 조인은 여러 테이블을 한 번에 결합해 처리하기 때문에 옵티마이저가 효율적으로 실행 계획을 세우고 인덱스를 잘 활용할 수 있어 대용량 데이터 처리에 강하다.
   • 서브쿼리는 메인 쿼리 내에서 별도 쿼리가 반복 실행될 수 있어,  N+1 문제처럼 데이터가 많을 때 성능 저하가 심해질 수 있다.
   • 가능한 JOIN, EXISTS 같은 대체 방식을 활용하고,
   • 가장 정확한 판단은 EXPLAIN 같은 실행 계획을 확인해 보고, 상황에 맞게 조인이나 서브쿼리를 선택하는 것
4. 쿼리 실행 계획 확인하기
   
   • DBMS에서 EXPLAIN 명령어로 실행 계획을 확인할 수 있다.
   • 인덱스 사용 여부, 전체 테이블 스캔 여부, 조인 방법 등을 확인해야 한다.
5. 쿼리 성능 모니터링
   • 어느 쿼리가 자원을 많이 소모하는지, 실행 빈도는 어떤지 파악

 

 

 

참고

https://retto9522.tistory.com/54

https://moonpiechoi.tistory.com/132

https://chung-develop.tistory.com/145#google_vignette