멀티스레드구성으로 접속당 전용 스레드가 할당되는 것 이외에 백그라운드로 동작하는 유틸리티용 스레드등이 있다.
또, 스토리지 엔진마다 전용 스레드가 존재하는 경우도 있다.
Falcon에서는 접속당 동작하는 스레드와 별도로 Falcon전용 스레드가 존재한다.
구체적으로 시리얼 로그 파일의 내용을 데이터 파일에 비동기로 반영하는 스레드나 메모리영역과 데이터 파일간의 읽기쓰기를 비동기적으로 수행하는 스레드등이 백그라운드에서 동작한다.
InnoDB에서도 비슷하게 백그라운드에서 동작하는 스레드가 존재한다.
Falcon메모리 영역은 로그 캐쉬, 시스템 캐쉬, 페이지 캐쉬, 레코드 캐쉬의 4종류로부터 구성된다.
로그 캐쉬는 REDO정보를 메모리상에 유지하는 영역으로 InnoDB로그 버퍼와 동등하다.
커밋할 때 시리얼 로그 파일에 동기 저장을 한다.
시스템캐쉬는 각종 메타데이터를 저장하는 영역이다.
페이지 캐쉬는 데이터 파일 정보를 캐쉬하는 영역으로 InnoDB buffer pool하고 비슷하다.
InnoDB의 경우는 페이지 사이즈가 16KB로 고정이어서 변경하기위해서는 소스코드를 직접 수정할 필요가 있지만 Falcon에서는 설정파일에서 수정할 수 있도록 되어있다. (현재는 1/2/4/8/16/32KB중에서 선택가능)
페이지 사이즈 변경으로 성능이 크게 변하는 경우는 드물지 않으므로 튜닝의 여지가 넓어졌다고 말할 수 있겠다.
Falcon특유의 메모리 영역이라고 말할 수 있는 것이 레코드 캐쉬이다.
레코드 캐쉬는 어플리케이션에 의해 작성/추출된 레코드 데이터(커밋전의것도 포함)를 캐쉬해두는 영역이다. MVCC의 기반이기도 하고 대부분의 처리는 레코드 캐쉬상에서 수행되게 된다.
레코드 캐쉬의 포인트는 레코드를 관리하는 데 필요한 정보만을 가지고 있기 때문에 InnoDB같은 페이지 내에 레코드를 관리하는 것에 비해 같은 캐쉬 사이즈임에도 보다 많은 레코드를 캐쉬상에서 관리할 수 있다는 장점이 있다.
메모리에 올릴 수 없을 정도의 대량 테이블 데이터를 다루는 경우에 Falcon의 장점이 발휘될 가능성이 높다고 말할 수 있겠다.
또 페이지 경유로 레코드를 (간접적으로 ) 참조하는 것에 비해서 참조 오버헤드도 가볍다라는 점도 놓칠 수 없다.
