Altibase의 in-memory DB 사용시 데이터 안정성의 확보방법은?

=================================================================================================================

온 - 디스크 데이터베이스가있는 하이브리드 [ 편집 ]

메모리 내부의 데이터를 저장하면 성능상의 이점이 있지만 데이터 저장 방법은 값 비싼 방법입니다. 비용을 제한하면서 메모리 내 스토리지의 이점을 실현하는 접근법은 가장 자주 액세스하는 데이터를 메모리에 저장하고 나머지는 디스크에 저장하는 것입니다. 메모리에 저장해야하는 데이터와 디스크에 저장되어야하는 데이터를 구별하지 않으므로 일부 시스템에서는 데이터 사용에 따라 데이터가 저장된 위치를 동적으로 업데이트합니다. ^[10] 가장 자주 액세스하는 데이터가 메모리에 저장되는 것과는 대조적으로, 이 접근법은 가장 최근에 액세스 된 데이터가 캐시 되는 캐싱 과 약간 다릅니다 .

Q. mysql의 쿼리캐시 처럼 자주 사용하는 쿼리문을 처리해주는 디스크기반 디비를 사용하는것과의 차이점은?

셀렉트, 인설트 할때의 쿼리 실행 과정을 보면 차이점이 있을수도..(아래 자료 참고) http://www.mcobject.com/in_memory_database

If avoiding disk I/O is the goal, why not achieve that through database caching?

Caching is the process whereby on-disk databases keep frequently-accessed records in memory, for faster access. However, caching only speeds up retrieval of information, or “database reads.” Any database write – that is, an update to a record or creation of a new record – must still be written through the cache, to disk. So, the performance benefit only applies to a subset of database tasks. In addition, managing the cache is itself a process that requires substantial memory and CPU resources, so even a “cache hit” underperforms an in-memory database.

=> 캐싱은 자주 접근이 필요한 데이터를 디스크에 접근하지 않고도 빨리 꺼내 쓸 수 있도록 메모리에 올려놓고 쓰는 것. 

하지만 이것은 오직 읽기 작업에만 해당된다. 읽기만 수행하는 경우 캐싱이 성능 향상에 도움이 되지만 

만약 쓰기나 업데이트가 필요한 경우 결국 디스크에 접근이 필요하다. 

더구나 캐시 관리 자체가 메모리와 cpu를 사용하게 되는 하나의 추가적인 작업이 된다. (심지어 캐시 히트율이 낮더라도)

디스크 기반 데이터베이스에서 데이터 전송

1) 어플리케이션이 데이터베이스로부터 데이터를 요청한다.

2) 디비의 runtime은 파일시스템에게 디스크로부터 데이터를 찾아올 것을 지시한다.

3) 파일 시스템은 chche에 대한 데이터를 복사하고 다른 사본을 데이터베이스로 전달

4) 데이터베이스는 하나의 복사본을 캐시에 보관하고 다른 하나는 응용 프로그램에 전달

5) 응용 프로그램은 사본을 수정하고 데이터베이스 API를 통해 다시 데이터베이스로 전달

6) 데이터베이스가 수정 된 데이터 항목을 다시 데이터베이스 캐시에 복사

7) 데이터베이스에 사본은 결국 파일시스템 캐시에서 업데이트 된 파일시스템에 쓰여짐

8) 최종적으로 그 데이터는 물리적 디스크에 다시 쓰여짐

In contrast, an in-memory database system entails a single data transfer. Elimination of multiple data transfers streamlines processing. Removing multiple copies of data reduces memory consumption, and the simplified processing makes for greater reliability and minimizes CPU demands.

=> 인메모리 데이터베이스는 단일 전송을 수반. 여러번의 데이터 전송 과정을 제거하여 메모리 소비를 줄이고, 간단한 프로세싱으로 cpu 사용을 더욱 최소화 시킨다.

=================================================================================================================

인메모리 디비 서버컴퓨터에서 전원이 끊켰을 때 데이터들은 어떻게 될까?

인메모리 디비들은 데이터의 지속성을 위해 다음과 같은 기능들을 지원하고 있다

- 스냅샷

- 트랜잭션 로깅

- Non-Volatile RAM

=================================================================================================================

DBMS의 많은 구성 요소 중에서 굳이 버퍼 관리자를 소개한 이유는 버퍼 관리 정책이 트랜잭션 관리에 매우 중요한 결정을 가져오기 때문이다. 버퍼 관리 정책에 따라서 트랜잭션의 UNDO 복구와 REDO 복구가 요구되거나 그렇지 않게 된다. 이 부분에 대해서 하나씩 살펴보자.

UNDO 

오퍼레이션 수행 중 데이터 페이지가 수정되고 이것이 디스크에 반영되어 출력될 수 있다. 즉 아직 완료되지 않은 트랜잭션이 디스크에 출력될 수 있으므로, 만약 해당 트랜잭션이 정상적으로 종료(커밋)되지 않으면, 수정된 데이터 페이지들도 수정되기 이전 상태로 복구시켜야 한다. 이러한 복구를  UNDO 라고 한다. 

만약 버퍼 관리자가 어떠한 경우에도 트랜잭션 커밋 이전에 수정된 데이터 페이지를 디스크에 쓰지 않는다면 비정상적으로 트랜잭션이 종료되었을때 메모리 버퍼만 수정전으로 되돌리면 되므로 좀더 간단하다. 그렇지만 이 경우 메모리의 크기가 커야한다.

수정된 페이지를 디스크에 반영하는 시점을 기준으로 다음의 두 가지 정책이 있다.

(트랜잭션이 정상적으로 커밋되지 않은 상태에서 디스크에 반영된 경우 다시 이전으로 되돌림) => RollBack

1) STEAL : 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책

2) ㄱSTEAL : 수정된 페이지들을 최소한의 트랜잭션 종료 시점까지 버퍼에 유지하는 정책 => 메모리 크기가 커야함

 REDO

UNDO 복구의 반대개념. 커밋한 트랜잭션의 수정은 어떠한 경우에도 유지(durability)되어야 한다. 이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 REDO 복구 라고 하는데, REDO 복구 역시 UNDO 복구와 마찬가지로 버퍼 관리 정책의 영향을 받는다. 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에 쓸 것인가 여부로 두 가지 정책이 구분된다.

(트랜잭션이 커밋되었으면 유지시켜야 함. 바로바로 디스크에 쓸 건지 일정 시간이후에 한번에 디스크에 쓸 건지 두 가지 경우가 있음)

1) FORCE : 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책

2) ㄱFORCE : 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책

=================================================================================================================

1. 데이터베이스의 영속성을 제공하고 Commit된 트랜잭션에 대한 안정성 확보를 위해서 트랜잭션 처리시의 WAL (Write Ahead Logging) 로깅 방식을 사용하고 있으며, 로그파일 개수가 일정 개수이상 되거나 정해진 주기가 되면 메모리의 변경된 데이터 페이지를 디스크로 Write하는  체크 포인트를 통해 복구 시간을 최소화 시키고 있습니다.
2. * WAL : 로그를 먼저 디스크에 저장하고 DB 페이지를  저장하는 절차. 디스크에 최종 트랜잭션 정보가 저장되어 있어 비정상종료시 트랜잭션로그를 통해 복구할수 있습니다.
    
3. 백업 및 복구 지원
   백업은 DBMS의 비정상 상황에 대비해서 논리적/물리적으로 데이터베이스의 사본을 생성합니다. 이러한 데이터베이스의 사본은 DB 운영 시에 온라인으로 생성이 가능하며, 복구 상황 시에는 백업 받은 데이터베이스 사본을 이용하여 완전복구 또는 불완전 복구를 수행하여 데이터베이스를 정상화시킬 수 있습니다.

=================================================================================================================

DBMS에서 데이터를 보존하는 기억장치는 대부분 하드디스크입니다. 하드디스크에서 지속성을 실현하려면 쓰기를 전부 '동기화 쓰기'로 하면 좋겠지만,

데이터베이스의 쓰기는 기억장치의 임시 장소에 무작위로 액세스해서 쓰기를 수행하기 때문에 동기화 쓰기는 느려서 성능면에서 실용적이지 않습니다. 

그래서 지속성과 성능이 양립하도록 일반적으로 DBMS에서는 다음과 같은 구조를 사용합니다.

- 로그 선행 쓰기 (WAL: Write Ahead Log)

데이터베이스의 데이터 파일 변경을 직접 수행하지 않고, 우선 로그로 변경 내용을 기술한 로그 레코드를 써서 동기화하는 구조입니다. 

MySQL에서는 이 로그를 'InnoDB 로그'로 부릅니다. WAL은 다음과 같은 이점이 있습니다.

1) 디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다.

2) 디스크에 쓰는 용량과 횟수를 줄일 수 있다. 

3) 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행한다.

- 데이터베이스 버퍼

커밋 시에는 WAL에 변경내용을 쓰기 때문에 데이터 파일의 변경 내용은 트랜잭션이 커밋되면서 동시에 동기화할 필요가 없습니다. 

그렇다고 트랜잭션마다 버퍼를 취해 비동기적인 쓰기를 하면 로그와 데이터 파일 간 일관성을 유지하기 어렵습니다. 

그래서 일반적인 DBMS에서는 '데이터베이스 버퍼'를 준비해 데이터 파일로의 입력을 데이터베이스 버퍼 경유로 일원화해서 단순화하고 있습니다. 

이 때문에 효율적으로 데이터의 일관성을 유지할 수 있게 됩니다. MySQL의 경우 갱신의 흐름은 다음과 같습니다.

=================================================================================================================

* CHECKPOINT 여부 trace

   체크포인트 발생시, $ALTIBASE_HOME/trc/altibase_sm.log 파일에 다음과 같이 로그가 남습니다. (altibase 4) 
   [2007/09/19 14:43:40] [Thread-3] [Level-9]
   [CHECKPOINT-BEGIN]
   [2007/09/19 14:43:41] [Thread-3] [Level-9]
   [CHECKPOINT-END]

   altibase3 의 경우, $ALTIBASE_HOME/trc/altibase_boot.log에 남습니다.

=================================================================================================================

이중화는 Active-Standby 또는 Active-Active 관계로 구성된 데이터베이스간에 트랜잭션 로그 기반으로 데이터를 서로 복제하는 기능이다.

Altiabse의 이중화 기능은 서비스를 수행하고 있는 서버의 데이터에 대한 최신 백업 데이터의 유지와, 서버의 예기치 않은 종료가 발생했을 때 

즉시 대체 서버에서 동일한 데이터베이스로 서비스를 재개할 수 있는 무정지 운영환경을 제공하는 것을 목적으로 한다.

* 데이터베이스 이중화 방법

* 이중화 기능의 사용 방법