저는 약 10년 동안 InnoDB를 사용해왔고, InnoDB를 원하는대로 수정할 수 있을만큼 InnoDB에 대해 충분히 이해했습니다. 하지만 효율성을 높이기 위한 몇 가지 목표를 달성하기 위해 다음 단계로 넘어갈 필요가 있다는 걸 깨달았습니다. 안타깝게도, InnoDB에서 제공하는 문서 (documentation)는 InnoDB의 내부 데이터 구조에 대한 명확한 설명이 부족했습니다. 필요한 정보를 찾을 수 있는 유일한 방법은 코드를 보는 것 뿐이었습니다.
하지만 코드의 구조와 사용법 (특히 상호관계)이 너무 복잡해서 전부 기억하기가 힘들었고, 결국엔 코드를 그냥 읽고만 있다는 걸 깨달았습니다. 또한, 이런 식으로 필요한 정보를 찾는 작업은 단순히 코드를 읽는 것만으로 구조를 제대로 이해했다는 전제 하에 가능한 일이었습니다 (저에겐 이 방식이 여러모로 착오가 있었습니다).
복잡하고 문서화가 잘 되어있지 않은 것을 이해하기 위해 제가 택한 접근법은 다음의 세 단계로 이루어집니다:
기본적인 이해가 될 때까지 기존 문서와 코드를 읽으세요. 종종 이 단계에서 잘못 이해하거나 factorization을 잘못하는 경우가 있습니다.
자신만의 코드로 구현해보세요. 매우 기초적이고 실수투성이여도 완전히 다른 언어로 작성하는 것이 좋습니다 (copy & paste만 하는 걸 방지하기 위해). 작동하는 것과 작동하지 않는 것에 기반하여 이해를 다시 해보세요.
새롭게 이해한 것들을 바탕으로 새로운 문서와 다이어그램을 만드세요. 그리고 필요에 따라 구현을 리팩토링하세요 (문서 작성을 위해 모든 걸 다시 검토하면서 잘못된 factorization을 발견할 수 있습니다). 코드를 리팩토링하면서 새롭게 이해한 것들을 기반으로 문서를 수정하세요. 다 고쳐질 때까지 이 과정을 반복하세요.
InnoDB의 디스크 상의 데이터 구조를 구현하기 위해, 저는 Ruby를 사용해 innodb_ruby 프로젝트를 시작했습니다. Ruby는 매우 유연하고, 프로토타이핑을 빠르게 할 수 있고, 제가 지금 제일 좋아하는 언어이기 때문에 Ruby를 선택했습니다. 하지만 어떤 언어를 선택하든 상관 없으며, 성능은 그렇게 큰 문제가 되지 않습니다 (테스트 하는 게 짜증날 만큼 심하게 느린 게 아니라면).
프로젝트를 시작하자마자 저는 몇 분만에 16KiB 페이지의 FIL 헤더 (InnoDB의 모든 페이지 유형에 공통)를 아주 기본적으로 파싱했습니다. 몇 시간 후엔, INDEX 페이지 헤더에 같은 기능을 구현했으며 얼마나 많은 레코드가 각 인덱스 페이지에 있는지와 같은 매우 기본적인 질문에 답할 수 있었습니다.
조금 더 나아가서, 한 번에 하나씩 제가 필요한 다른 중요한 데이터 구조를 구현했습니다. InnoDB 스토리지의 각 단계를 더 깊이 이해할 수 있도록 그때그때 필요한 것들을 순서대로 구현했습니다. Davi도 이 작업에 함께 했고, 레코드에서 가변-폭 (variable-width) 필드 유형을 처리하는 것과 같이 까다로운 부분을 구현했습니다.
이런 방식으로 InnoDB의 주요 데이터 구조에 대해 기본적으로 동작하는 read-only 버전을 구현했습니다.
다이어그램을 그릴 수 있을만큼 충분한 InnoDB의 비밀을 밝혀내자마자, 주요한 InnoDB의 디스크 상의 데이터 구조에 대해 명확하고 친숙한 다이어그램을 그렸습니다. 그렇게 innodb_diagrams 프로젝트를 시작했고, OmniGraffle에서 다이어그램을 빌드했습니다.
현재 tablespace 파일 (ibdataX 및 *.ibd 파일)의 디스크 기반 저장 형식은 대부분 Barracuda 형식의 테이블 (COMPACT 레코드 포함)로 설명되어 있습니다. Antelope 형식 (REDUNDANT 레코드 포함) 및 InnoDB 압축 테이블에 해당하는 문서를 작성하기 위해선 해야할 일이 여전히 많습니다. 로그 파일 형식도 마찬가지입니다.
인터랙티브한 데모를 할 수 있는 코드와 훌륭한 보조 자료가 될 다이어그램을 사용해, 좀 더 흥미롭고 문서화되지 않은 구조에 대한 포스트를 작성하려고 합니다. 눈을 떼지 마세요!