개요

Altibase를 사용하여 프로젝트를 수행하기 전에 서버의 저장장치 용량이 결정되어야 한다. 이 문서에서는 서버 구성에 필요한 메모리, 디스크의 용량을 어떻게 산정할 수 있는가에 대해 설명한다.

이 문서는 아래 버전을 기준으로 작성되었다.

• Altibase 7.1.0 이상

메모리 용량 산정

메모리 용량 산정은 다음의 3가지 항목을 고려해야 한다. 

1. 메모리 DB의 크기
2. 디스크 DB의 버퍼 크기
3. 질의문 수행을 위한 메모리

메모리 DB의 크기

메모리 테이블스페이스에 생성된 테이블은 32 KB 단위의 페이지를 할당받는다. 한 페이지는 다시 해당 테이블의 레코드의 길이에 따라 슬롯(Slot)이라는 단위로 나누어진다. 

따라서 32 KB 단위의 한 페이지는 생성된 테이블이 갖는 레코드의 길이에 따라 여러 개의 슬롯(Slot)으로 나누어진다. 

한 페이지 내의 정확한 슬롯(Slot) 크기나 개수는 Altibase 성능뷰 V$MEMTBL_INFO에서 확인할 수 있다.

Altibase의 메모리 DB는 모든 데이터와 인덱스를 메모리에 상주시키는 형태이다.

따라서 운영 환경에서 메모리 DB의 크기를 산정할 때, 실제 생성할 메모리 테이블 스키마와 예상 레코드 수를 기준으로 산정한다.

다음과 같이 산정할 수 있다.

• 메모리 테이블의 인덱스는 실제 메모리 상의 위치를 가리키는 포인터 정보만 관리하기 때문에 (레코드 건수 * 8 bytes) 형태로 계산한다. 
  메모리 인덱스 수에 따라 '8 bytes * 레코드 수 * 인덱스 수' 수식으로 계산할 수 있다.
• 위와 같은 계산식으로 산출된 테이블의 각 예상 크기의 총 합이 메모리 DB의 용량으로 산정될 수 있다. 또한, 이와 같이 산출된 용량에서 30%~50%의 여유율을 고려하여 메모리 DB의 용량을 산정하면 된다.
  (필요한 여유율이 무엇인지는, 아래 "질의문 수행을 위한 메모리" 부분에서 추가적으로 설명한다.)
• 정확한 레코드의 길이를 파악하려면 테이블을 생성한 후, SYSTEM_.SYS_COLUMNS_에서 해당하는 테이블 컬럼의 SIZE의 합을 조회하면 명확하게 알 수 있다.
• Volitile 테이블스페이스의 경우도, 실제 데이터가 존재하게 되면 메모리 영역을 사용하기 때문에 위와 같은 기준으로 용량 산정에 포함시켜야 한다.
  (Volatile 테이블스페이스에 생성된 테이블의 데이터는, Altibase 서버를 재구동하면 모두 유실된다. Volatile 테이블스페이스의 테이블에 대한 트랜잭션은 
  물리적인 트랜잭션 로그를 기록하지 않고 빠른 임시 처리를 위해 사용되는 테이블스페이스 개념으로 제공되고 있다.)

디스크 DB의 버퍼 크기

디스크 DB의 버퍼 크기 산정에 대해서는 고정된 계산식이 존재하지 않는다. 

다만, 전체 디스크 DB 중에서 자주 접근될 것으로 예상되는 디스크 DB 크기 대비 10% 이상을 권장한다.

예를 들어, 디스크 DB 중에서 자주 접근되는 데이터의 크기를 100 GB라고 산정한다면, 10%인 10 GB 이상을 버퍼 크기로 설정하도록 한다.

질의문 수행을 위한 메모리

메모리 용량 산정은 데이터 외에도 다음 3가지 영역의 메모리 사이즈를 고려해야 한다.

1. 질의 정보 및 질의 실행계획
2. 연산을 위한 임시성 메모리 공간
3. MVCC 기법에 의한 별도의 메모리 여유율

질의 정보 및 질의 실행계획

질의 수행 시, Altibase는 내부적으로 최적화된 실행계획으로 질의가 처리될 수 있도록 실행계획 수립 절차를 거치게 된다. 이 실행계획의 수립 및 판단 부분은 질의 처리의 성능에 있어서 매우 비중이 크다.

하지만, Altibase는 동일한 질의에 대해서 매번 실행계획을 수립하는 비용을 줄이기 위해, 내부적으로 이미 수행된 질의에 대한 질의 정보 및 실행계획을 저장하여 관리하고 있다. 그리고 이를 위해서는 세션 메모리 영역이 필요하다.

Altibase에는 크게 2가지 영역의 세션 메모리 영역이 존재하는데, 모든 세션에 공통적으로 활용되는 SQL_CACHE 영역과 세션별로 할당되는 메모리 영역이다.

SQL_CACHE의 크기는 동적으로 크기가 늘어나지 않기 때문에 질의에 대한 실행계획을 모두 저장할 수 없을 경우 세션에 할당된 메모리 영역에 저장하는 구조로 동작하고 있다. 

따라서 메모리 용량을 산정할 때 세션에 할당될 메모리 공간도 함께 고려되어야 한다.

임시성 메모리 공간

메모리 DB에서 group by, aggregation 등이 포함된 질의가 수행될 경우, 원천 데이터에서 사용자가 요구한 질의 결과로 가공하기 위해서는

중간 결과셋을 저장하는 별도의 저장 공간을 필요로 한다. 임시성 메모리 공간이란 이때 사용되는 별도의 저장 공간을 의미한다.

(디스크 DB의 경우는 기본적으로 디스크용 임시 테이블스페이스를 사용하나, 성능 개선을 위해 힌트 등을 사용하여 메모리 영역을 사용하게 할 수 있다.)

결과적으로, 이 영역은 명확하게 산술적으로 계산하는 것이 불가능하다. 사용하게 될 임시성 메모리 공간의 증가 정도는 질의의 유형에 따라, 데이터의 크기에 따라, 동시에 수행되는 질의에 따라 매우 유동적이기 때문이다.

단, 할당된 이후에는 지속적으로 재사용이 되기 때문에 적절하게 산정하면 전체 메모리 산정에 있어 크게 영향을 주지는 않는다.

MVCC 기법에 의한 별도의 여유율

Altibase는 변경 트랜잭션 진행 중에 조회 트랜잭션이 발생할 경우, 두 트랜잭션 간의 경합을 최소화하여 성능을 극대화하기 위해 MVCC라는 동시성 제어 기법을 사용한다.

그리고 이 MVCC 기법을 사용하기 위해, 테이블 내에 버저닝(Versioning)된 데이터의 이전 이미지를 임시적으로 저장한다. (MVCC에 관한 자세한 설명은 "MVCC 가이드" 문서를 참고한다.)

따라서, 메모리 용량을 산정할 때 MVCC를 위한 여유율도 함께 고려되어야 한다.

메모리 용량 산정의 예

메모리 테이블을 1년에 100만 건씩 증가되는 형태로 10년을 보관한다고 전제하면, 다음과 같이 용량 산정을 할 수 있다.

위 테이블은 다음의 SQL문을 통해 레코드의 길이를 확인할 수 있다.

Altibase는 메모리 자원에 대한 관리 차원으로 8바이트 단위 정렬을 한다. 즉, 8의 배수로 나누어지지 않는 크기는 그보다 큰 8의 배수로 관리된다.

따라서, 레코드의 길이가 282 bytes라면 정렬 규칙에 의해 288 bytes를 하나의 레코드 길이로 산정해야 한다.

위와 같이 레코드의 길이를 파악하였다면, 다음과 같은 표로 계산이 가능하다.

위와 같이 테이블 별로 입력 데이터가 만들어지면 데이터와 인덱스에 대한 용량을 산정하는 것이 가능하다.

그리고, 데이터와 인덱스에 대한 용량이 산정되면 아래와 같이 전체 필요 메모리 용량을 계산할 수 있게 된다.

이러한 메모리 용량 산정은 순수하게 Altibase의 용량만 산정한 것이다. 만약, 동일한 서버 내에 사용자 응용프로그램까지 운영할 계획이라면, 그 부분에 대한 별도의 용량 산정도 반드시 진행되어야 한다.

디스크 용량 산정

디스크 용량은 다음의 4가지 항목을 고려해야 한다. 

1. 메모리 체크포인트 이미지 파일
2. 트랜잭션의 로그파일 공간
3. 디스크 DB의 예상 공간
4. 디스크 DB의 백업 공간

메모리 체크포인트 이미지 파일

Altibase는 갑작스러운 장애가 발생할 경우라도 메모리 상에 변경된 데이터를 다시 복구할 수 있도록 주기적으로 메모리 DB의 내용을 물리적인 데이터파일로 저장한다.

이러한 과정을 체크포인트라고 하며, 이 과정에서 생성되는 데이터파일의 용량은 메모리 DB의 크기로 생성이 된다. (체크포인트의 자세한 과정은 "Altibase 체크포인트 가이드" 문서를 참고한다.)

이때 생성되는 파일은 각각 1벌씩 2개의 파일로 생성되기 때문에 디스크 용량에 있어서는 메모리 DB 용량의 2배수를 필요로 한다. 

트랜잭션의 로그파일 공간

Altibase는 WAL(Write-Ahead Logging) 프로토콜에 의한 회복 기법을 수행하기 위해 트랜잭션에 대한 로깅을 수행한다. 

이때 수행되는, 로그의 기록 과정에서 물리적 파일에 저장 공간을 요구하게 되며 이렇게 기록되는 파일들을 온라인 로그파일이라고 부른다.

온라인 로그파일들은 체크포인트가 발생하면 자동적으로 삭제가 되지만, 경우에 따라서는 삭제가 되지 않고 유지될 수 있다. 다음과 같은 경우가 그에 해당한다.

• 이중화 환경에서 이중화 송신자가 보내야 할 로그를 보내지 못하고 유지하는 경우
• 대량의 변경 작업의 발생으로 트랜잭션이 장시간 유지되는 경우

어떠한 이유로든, 온라인 로그파일의 지속적인 유지로 인한 디스크 용량 부족 장애가 발생하는 것은 방지해야 하므로 가능한 안정적인 공간을 확보하는 것을 권장한다.

하지만, 온라인 로그파일을 위한 디스크 공간은 일반적으로 계산식에 의해 권장하기 어렵다.

시스템의 규모에 따라 유동적이기 때문에, 성능 부하 테스트 등을 통해서 생성되는 로그파일 양의 수치와 같은 자료를 기반으로 산정하는 것이 바람직하다.

만일, 이와 같은 테스트를 진행하기 어려운 경우라면 최소한 50 GB 이상의 디스크 공간을 권장한다.

디스크 DB의 예상 공간

디스크 DB는 메모리 DB의 용량 산정 방법과 달리, 페이지 단위의 산정을 권장한다. 각 페이지당 PCTFREE와 PCTUSED의 속성에 따라서, 저장 가능한 공간의 제약이 발생하기 때문이다.

디스크 DB의 페이지 크기는 8192 bytes이다. 여기서 각 페이지마다 PCTFREE의 설정을 계산한 페이지의 공간을, 레코드를 위해 사용 가능한 공간으로 계산한다.

레코드 및 인덱스의 헤더 길이는 아래와 같다. 메모리 DB와 다르게 디스크 DB는, 인덱스에 구성된 컬럼의 길이가 용량 산정에 고려되어야 한다.

• 각 컬럼 별로 길이 정보를 위한 1 byte를 지닌다. 만약 250 bytes 이상의 컬럼이면 3 bytes의 길이 정보를 위한 헤더를 지닌다.
• 페이지 내에서 정확한 오프셋 정보를 빠르게 알기 위한 슬롯 디렉토리 영역을 저장될 공간에 포함하여 계산한다.

디스크 DB의 용량 산정은 다음과 같이 수행한다. (인덱스는 키를 구성하는 컬럼의 길이를 합산해야 한다.)

페이지당 들어갈 수 있는 레코드의 수를 구하면 그 값으로 예상 건수에 대해 필요로 하는 페이지의 수를 구할 수 있다.

그런데, 실제 사용되는 페이지는 8192 bytes 단위이므로 최종 산출에서는 8192 bytes를 곱하여 용량을 산정한다.

인덱스의 경우에도 위와 같이 산정하는데, 인덱스를 구성하는 키 컬럼의 길이를 레코드의 길이로 적용해서 계산하면 된다.

헤더는 인덱스의 헤더 16 bytes를 이용하면 된다.

위와 같이 모든 디스크 테이블에 대한 용량을 구하게 되면, 총합을 계산한 후 30%~50%의 여유율을 고려하여 용량을 산정한다.

디스크 DB의 언두 테이블스페이스와 임시 테이블스페이스

언두 테이블스페이스

디스크 DB의 언두 테이블스페이스는 변경된 이미지의 복제 본이 트랜잭션의 종료 시점까지 임시로 저장되는 공간으로 사용된다. 

따라서 사용자가 요구한 질의 처리에 따라 사용량이 변화하기 때문에 사용량을 예측하기 어렵다.

예를 들어, 1 TB의 테이블을 한번에 갱신하는 트랜잭션이 발생하면, 1 TB만큼 언두 테이블스페이스가 필요로 한다.

이와 같은 최악의 경우를 고려하지 않는다면 일반적으로 가장 용량이 큰 테이블의 30% 정도를 언두 테이블스페이스 용량으로 산정하는 것이 바람직하다.

임시 테이블스페이스

임시 테이블스페이스 역시 질의의 유형에 따라 사용량이 변화하기 때문에 사용량을 예측하기 어렵다. 

따라서, 언두 테이블스페이스와 동일하게 가장 용량이 큰 테이블의 30% 정도를 임시 테이블스페이스 용량으로 산정하도록 한다.

언두 테이블스페이스와 임시 테이블스페이스는 충분한 공간을 산정하여, 운영에 문제가 없도록 해야 한다.

디스크 DB의 백업 공간

백업과 관련된 자세한 사항은 "Altibase 백업 및 복구 가이드" 문서를 참고하도록 하며, 여기에서는 백업과 관련된 용량을 산정하는 부분에 대해서만 설명한다.

Altibase의 백업을 위해서는 반드시 아카이브 로그 모드로 운영을 해야 하고, 그러기 위해서는 2개의 디스크 공간이 요구된다.

백업 공간의 경우는, 예측된 메모리 DB와 디스크 DB 용량의 총합으로 산정하면 된다.

매번 전체 DB를 백업하는 형태와 증분 백업 형태, 테이블스페이스 단위 백업 형태 등 백업 형태가 다양하기 때문에 각 백업에 알맞은 공간을 산정하도록 한다.

아카이브 로그파일 디렉토리의 경우, 사용자가 백업을 완료한 시점 이후에 참조되지 않는 이전 로그파일은 모두 삭제해도 무방하다. 

따라서, 백업 주기와 정책에 따라 보관되는 로그파일 용량이 다를 수 있기 때문에 백업 정책에 따라 유동적이라고 할 수 있다.

다음의 예를 통해 알아보자. 아래의 예에서 백업 정책은 1일 단위로 가정한다.

• 메모리 DB는 체크포인트 시에는 1벌(2개의 파일)로 저장이 되지만, 백업 단계에서는 안정적인 1개의 파일만 백업되기 때문에 메모리 DB 용량 만큼 백업 공간을 고려하면 된다.
• 디스크 DB는 전체 백업 정책으로 가정할 경우, 예상되는 디스크 DB의 용량 만큼 백업 공간이 필요하다.
• 아카이브 로그파일은 다음 백업 발생 때까지 보관이 되어야 이전에 백업한 백업본을 이용하여 현재 시점까지 복구가 가능하기 때문에, 백업 주기의 기간 동안 발생된 아카이브 로그파일이 모두 저장 되어 있어야 한다.
• 백업 주기 개념으로 보면 현재 백업이 성공해야 직전 백업본을 삭제할 수 있음으로, 직전 백업본까지 디스크에 유지할 경우 2배의 백업 필요 공간이 요구된다.

iloader를 통한 백업 활용 시 고려 사항

온라인 백업 방법에 더해 부가적으로 테이블 별로 백업을 받는 것이 필요한 경우, iloader라는 유틸리티를 사용하여 텍스트 형태의 파일로 테이블을 백업 받을 수 있다.

이러한 경우에는 디스크 용량 산정 시에 iloader를 통해 백업된 데이터 파일의 용량을 고려해야 한다.

일반적으로 5 bytes 정도의 데이터 구분자를 컬럼마다 사용해야 하기 때문에 실제 예상된 디스크 DB의 용량에 추가적으로 다음과 같은 산술로 나온 공간이 필요로 한다.

즉, 최초에 산정된 디스크 DB의 용량에 추가적으로 구분자 용량이 필요로 한다는 의미이다. 

또한, 압축하여 디스크 내에 보관할 경우에도 위에서 산정한 용량 대비 압축률을 고려하여 보관될 공간의 크기도 산정해야 한다.

이 부분은 아래 디스크 용량 산정 예제에 추가하지 않음으로, 사용자가 이 방법의 백업을 선택할 경우 반드시 고려하기 바란다.

디스크 용량 산정 예제

요약

지금까지 Altibase를 운용하는데 필요한 메모리, 디스크의 용량 산정 방법을 알아보았다.

하지만 데이터베이스 시스템 용량을 산정할 때에는 각 항목별로 고려할 사항이 적지 않기 때문에, 실제 시스템을 구성할 경우에는 사전에 충분한 데이터의 검토를 통해 가장 적합한 구성 방법을 찾는 것이 바람직하다.