Falcon은 현재 폭넓게 쓰이고 있는 스토리지엔진 InnoDB의 다른 선택지의 하나로써 기대받고 있다.
Falcon은 관계형 데이터베이스(RDBMS) 계의 권위자인 Jim StarKey씨와 그의 아내 Ann Harrison씨를 중심으로 개발이 진행되고 있다.
Jim StarKey씨는 InterBase의 아버지이자 또 Ann Harrison씨와 함께 Firebird의 메인커밋터로도 활약하고 있다.
그들은 Netfrastructure라 불리우는 회사에서 차세대 RDBMS의 개발을 진행하고 있었지만 2006년 2월에 MySQL AB가 Netfrastructure를 매수하게 됨으로 MySQL AB로 바뀌게 되었다.
Falcon의 가장 기본적인 특징은 트랜잭션을 서포트한다는 것이다.
커밋/롤백에 한하지 않고 row level lock, MVCC(Multi-Version Concurrency Control), lock을 걸지 않고 하는 online backup, crush recovery등은 어느것이던지 트랜잭션 지원을 기반으로 어플리케이션 개발에 있어서 매우 중요한 기능이다.
MySQL5.0에서 트랜잭션을 서포트하고 있는 스토리지엔진은 InnoDB와 NDB(MySQL Cluster)가 있다.
InnoDB는 MyISAM등과 마찬가지로 주로 MySQL 서버 1대 또는 Master/Slave형 replication구성에서 채용된다.
한편 NDB는 클러스터 구성을 전제로 하는 것으로 in-memory형의 고속, 고가용스토리지엔진이고 초당 수만~수십만트랜잭션등의 자릿수가 다른 처리능력을 요하는 환경에 쓰여지고 있다. (유럽과 미국를 중심으로 다수의 실적이 있다.)
Falcon은 이 중 InnoDB와 MyISAM과 같은 영역을 타겟팅하고 있다.
유저 입장에서 보는 기능은 InnoDB와 거의 비슷하므로 InnoDB의 대체적인 존재라고도 말해지고 있다. 그렇지만 Falcon은 InnoDB하고는 내부적으로 아키텍쳐가 전혀 다르고 InnoDB만 커버가능한 특징도 일부 존재한다.
이때문에 InnoDB상위호환(완전한 치환가능한 존재)이 되지는 않으므로 주의해야한다.
Falcon 안정판 릴리스시기는 MySQL 5.1의 다음 버전(5.2)을 예정하고 있다.
다만, 앞으로 개발상황이나 사용자의 요구에 따라서는 5.0이나 5.1에 back-porting될 가능성도 있다.
InnoDB에서만 커버되는 특징
InnoDB가 가지고 있지만 Falcon에는 없는 특징은 다음과 같은 것이 있다.
- Falcon에서는 cluster index를 채용하고 있지않다.
- Falcon에서는 분리 레벨 Read Uncommitted을 지원하지 않는다.
- 바이너리 로그의 기록방식인 「statement 기준(종래형)」,「행 기준」중에서 Falcon에서는 후자만 지원한다.
3의 「행 기준」기록형식은 MySQL 5.1이후에 지원되는 기능으로 바이너리 로그에의 기록형식이 종래의 DDL/DML문 그대로가 아니라 물리적인 값이 된다는 것이다.
InnoDB에서는 2개를 전부 지원하고 있지만 Falcon에서는 기존 방식으로 지원하지 않는다.
바이너리로그의 기록방식의 차이는 replication뿐만아니라 디스크장해가 있을 때의 복구에도 영향을 끼친다.
기존방식에서는 정확히 기록되지 않았던 UUID()등이 이용가능하다라는 merit가 있는 반면 전체적인 사이즈가 증가한다는 결점도 있다.
현 단계에서는 1,2,3 어느것도 지원할 계획은 없지만 요구에 맞게 장래적으로 지원될 가능성도 있을 것이다.
이것 이외에도 InnoDB는 가지고 있고 현시점의 Falcon이 가지고 있지 않는 중요한 기능이 몇개 더 있다.
SELECT FOR UPDATE, foreign key제약, online backup, Two-Phase Commit등은 베타버전에서는 지원될 예정이다.
