NDB 스토리지 엔진의 행 데이터는 , 데이터 영역, 인덱스 영역을 포함해서 전부 메모리상에서 관리된다.
그 때문에 데이터 액세스는 매우 빠르다.
무엇보다도 메모리는 디스크에 비교해 꽤 비싸기 때문에 수백기가급의 대량 데이터를
다룰 필요가 있다면 MySQL Cluster로 전부 관리하는 것은 현실적이지 않을 수 있다.
다만, MySQL에서는 테이블단위로 스토리지 엔진을 선택가능하기 때문에 고속화가
필요한 테이블은 NDB로 하고 그 이외에는 InnoDB이나 MyISAM으로 하는 구성도 가능하다.
또 5.1에서부터는 테이블데이터(인덱스영역은 빼고)를 디스크상에서 관리할까 메모리상에서
관리할까 하는 선택이 가능하게 된다.
데이터양이 많은 시스템이라서 MySQL Cluster를 사용할 수 없는 것은 아니다.
◆트랜잭션에 대응
InnoDB와 마찬가지로 트랜잭션의 커밋, 롤백이 가능하다.
다만, 분리 레벨은 Read Committed만이 지원된다.
읽고 있는 중에는 Lock을 걸지 않는 것도 InnoDB하고 같다.
◆체크포인트와 그룹 커밋에 따른 영속화
메모리상에서 관리한다라고 하면 머신을 멈추면 모든 데이터가 날라가버린다고 생각할 지도 모른다.
그러나 MySQL Cluster(Data Node)에서는 정기적으로 체크포인트처리가 수행되어
메모리상에 있는 데이터가 디스크에 저장된다. 정상정지나 이상정지등의 이유로 Data Node가
멈추어 재기동이 필요하게 된 경우에는 디스크로부터 테이블 데이터를 읽어들여 메모리에서
전개하게 된다. 그 때문에 Data Node의 프로세스를 멈추어도 테이블 데이터를 잃어버릴 염려는 없다.
이 처럼 Data Node의 모든 메모리데이터를 디스크에 쓰는 처리를 Local Checkpoint라고 부르고 있다.
Local Checkpoint는 기본적으로 수분 간격으로 수행되어진다. (TimeBetweenLocalCheckpoint라는 파라미터로 제어 가능하다. )
그렇지만 이 외에도 트랜잭션의 커밋결과를 디스크에 저장하는 처리도 이루어진다.
이 처리는 Global Checkpoint라고 불리운다.
그러나 InnoDB하고 달리, 커밋 동시에 저장은 하지 않고 일정시간(TimeBetweenGlobalCheckpoint에서 지정한 밀리세컨드)간격으로 그때까지의 커밋정보가
같이 디스크에 쓰여지게 되어있다.
이것은 성능을 높이기 위한 조치이다.
커밋시 동시 저장의 목적은 정전등의 노드 장해가 발생하더라도 직전 커밋정보까지 복원가능케 하는 것이 지만
MySQL Cluster에서는 같은 데이터를 여러개의 노드가 가지고 있기 때문에 1개의 노드에 장해가
발생하더라도 시스템정지으로 되지는 않는다. 그 때문에 엄밀한 커밋시 동시 저장을 하지 않아도
문제는 없다라는 것이다. SQL문등 어플리케이션레벨에서의 튜닝이 필요한 환경에서는 REDO로그 파일에 동기 저장이 bottle neck이 되는 경우가 많지만
MySQL Cluster에서는 그런 걱정이 없다. 이것도 성능 향상에 큰 공헌을 하고 있다.
