앞으로 시간 남는대로 SQLite의 소스 및 구조를 분석하는 올릴까 합니다. 예전에도 관련 글이 몇 가지 있지만 앞으로는 좀 더 상세하게 파헤칠까 합니다.
이번에는 가장 기본이 되는 SQLite의 기본적인 레이어 구조와 페이지 핸들링에 대해 다루어 보겠습니다.
Architecture of SQLite(출처:sqlite.org)
이 글을 관심있게 읽어 보실 분이라면 이미 SQLite를 몇 번은 다루어 보셨겠죠?
우리는 SQLite 쉘을 이용하거나 혹은 JDBC든 C API든 무언가를 통해 SQL을 SQLite에 보내게 됩니다. 이것이 좌상단의 Core레이어에 있는 Inteface입니다. 위에 말한 것들이 모두 Interface가 됩니다.
SQL문장은 우상단의 SQL처리 레이어(SQL Compiler)를 통해 SQLite Virtual DB Engine이 처리할 수 있는 OPcode로 번역됩니다.
Core 레이어 마지막의 Virtual Machine이 바로 OPcode를 받아 처리하는 역할을 합니다.
OPcode는 형태상으로 어셈블리와 비슷하며 SQL 처리 과정을 이해하기에 편한 구조를 지니고 있습니다.
Backend는 실제로 저장되는 데이터 구조를 다루는 부분입니다. Virtual Machine에서 무슨 테이블에 이거 집어넣어라, 무슨 인덱스에서 이거 삭제해라 등등 좀 더 세밀한 명령을 보내면 메모리와 디스크에 저장된 데이터를 조작하게 됩니다.
B-tree부분은 인덱스와 테이블 저장구조를 담당합니다. SQLite에서 인덱스는 당연히 B-tree로 이루어지며 일반 테이블 또한 row id를 키로 하는 B-tree입니다.
B-tree의 operation은 메모리 상에서 이루어지며 Pager(page cache)를 통해 메모리에 올라와 있던 B-tree 페이지가 디스크로 내려가고 또 불려 올라오게 됩니다.
디스크 I/O를 비롯한 부분은 OS마다 다르므로 OS Interface를 통해 각 OS마다 따로 구현되어 있습니다.
경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다. https://s1004games.com
그럼 원래 쓰려 했던 페이지 핸들링에 대해 얘기해 보겠습니다.
대부분의 DB는 디스크에 저장할 때 페이지 단위로 저장을 하며 이는 SQLite도 마찬가지입니다. Data Chunk라고 부르기도 하는 이 페이지는 SQlite에서 기본적으로 1024바이트 단위입니다.
디스크에 데이터를 쓸 때는 먼저 페이지를 할당한 뒤에 이 페이지에 데이터를 써넣으며 페이지가 꽉 차면 다시 페이지를 할당합니다. 즉, 페이지 크기가 1024바이트라면 DB 파일은 늘 1K 단위로, 4K라면 4K 단위로만 증가하게 됩니다.
그런데 왜 페이지를 쓰느냐? 당연히 데이터 관리가 더 쉽기 때문입니다. 일종의 divide and conquer 접근법과도 관련이 있습니다. 페이지는 앞부분에 각각 일정 바이트 크기의 페이지 헤더를 갖고 있습니다. 이 헤더 정보를 분석하면 각 페이지에 데이터가 얼마나 차 있는지를 알 수 있게 되어 있는데 사용률이 낮은 페이지끼리 합쳐준다든가 하는 로직도 가능하겠지요.
또한 테이블과 인덱스 별로 페이지를 구분해 줄 수도 있습니다. A 테이블이 2,4,5페이지를 사용하고 있고, A테이블의 idx1 인덱스는 3, 6 페이지를 사용한다든가 하는 식입니다.
페이지를 쓰지 않고 그때그때 필요한만큼만 계속 공간을 할당한다고 상상해 보시면, 아마 감당하기 힘들어질 것입니다. 게다가 페이지와 인덱스 영역의 구분도 안되는데 한동안 DB를 쓰다가 갑자기 drop한다면 난리 나겠죠 -_-;
즉, SQLite에서 table이나 index를 새로이 create하면 그 때마다 새로운 페이지가 하나 할당됩니다.
SQLite 쉘에서 실행해서 다음 명령을 실행해 DB 파일을 만들어 봅시다.
eminency@eminency-desktop:~/test$ sqlite3 testdb
SQLite version 3.4.2
Enter ".help" for instructions
sqlite> create table ttbl (ic int, tc text);
sqlite> create index idx1 on ttbl (ic);
빠져 나와서 DB 파일 크기를 확인해 보면 3072바이트입니다. 물론 1024 바이트 페이지가 세 개 생겼으니 3072 바이트입니다 -_-;
테이블 하나와 인덱스 하나를 만들었는데 페이지 두 개가 아니라 왜 세 개일까요? 이는 테이블과 인덱스 관리를 위해 내부적으로 sqlite_master라는 메타 테이블이 하나 더 만들어지기 때문입니다. 다음 커맨드를 실행해 보면 확실히 알 수 있습니다.
sqlite> .explain
sqlite> select * from sqlite_master;
type name tbl_name rootpage sql
---- --------- ---------- ---------- ---------------------------------
tabl ttbl ttbl 2 CREATE TABLE ttbl (ic int, tc tex
inde idx1 ttbl 3 CREATE INDEX idx1 on ttbl (ic)
보시다시피 sqlite_master의 레코드는 테이블과 인덱스가 만들어질때마다 추가됩니다(type이나 sql뒤가 잘린 건 SQLite의 디스플레이 방식 때문입니다. 데이터가 이상한게 아닙니다 -_-).
SQL문이 들어오면 테이블명이나 인덱스명 검색은 sqlite_master에서 이뤄지겠죠.
그럼 실제로 페이지에 데이터가 어떤 방식으로 저장되는가...에 대해서는 다음에 다루겠습니다. 생각보다 길어진 관계로..-_-
빠른 시일내에 다음 편(?)을 올리겠습니다. 좋은 한 주 되세요.
