The Architecture Of SQLite

출처: modules/moniwiki/wiki.php/SQLIte%20Architecture

Contents

1 The Architecture Of SQLite

1.1 Introduction

1.2 Interface

1.3 Tokenizer

1.4 Parser

1.5 Code Generator

1.6 Virtual Machine

1.7 B-tree Driver

1.8 Page Cache

1.9 OS Interface

2 결론

3 관련 링크

1 The Architecture Of SQLite

작성자: mwyun(멍)

1.1 Introduction

SQLite library의 acrchitecture 설명에 대한 문서이다. Block Diagram Of SQLite 그림 참조

1.2 Interface

SQLite library는 main.c 소스 파일안의 네 개의 함수들에 의해 구현되었고, 공동 인터페이스의 대부분(전부)이다. sqlite_get_table() 루틴은 table.c에서 구현되었다. Tcl interface는 tclsqlite.c에서 구현되었다. 최신의 정보는 SQLite는 개별적으로 사용할 기 위한 C interface의 최신 정보가 있다. SQLite library안의 모든 외부 심볼들은 prefix sqlite와 함께 시작함으로써 다른 소프트웨어와 이름 충돌을 피한다. 그 심볼들은 sqlite_과 함께 시작하는 외부 사용에 위해서 계획된 것이다.(다른 말로, 그 심볼은 SQLite를 위한 API이다.??)

1.3 Tokenizer

SQL 문장을 실행할 때 포함할 시작을 언제할 것인가는 inferface에서 통과되면 tokenizer에서 시작한다. tokenizer의 작업은 시작하는 토큰인 경우 멈추고(??), 그 토큰들을 parser로 하나에 하나씩(one by one) pass한다. tokenizer는 C로 작동하는 코드이다. tokenizer을 위한 코드의 모두는 tokenize.c 소스 파일안에 포함되어 있다. 이 디자인에서 말하고자 하는 것은(알리는 것은), tokenizer가 parser를 호출한다. 사람들은 어떤 다른 것으로 하는 것보다 아마도 YACC와 BISON을 익숙하다. tokenizer가 parser를 호출한다. 작가는 SQLite를 동시에 두가지 길을 끝냈으며 parser를 호출하는 tokenizer를 위한 통상적인 작업 결과 nicer(??)를 찾았다. YACC는 되돌아갔다.?

1.4 Parser

parser는 조각이다. 그것의 context위에 tokens을 기본으로 의미를 할당(부여)한다. SQLite를 위한 parsr는 Lemon LALR parser generator(생성기)를 사용하여 생성돼었다. Lenmon은 YACC/BISON의 동일한 작업이었다. 그러나 이것을 사용하는데는 입력 syntax(구문)이 에러가 발생하기 쉽지 않은데 차이가 있다.(다르다) Lemon 또한 parser가 재진입과 thread-safe하도록 생성되었다. 그리고 lemon은 non-terminal 소멸자의 개념을 정의하였다. 그것은 syntxt(구문) 에러를 만나도라도 메모리 유출을 하지 않는다. 소스 파일 parser.y에서 Lemon을 운영한다. 그러나 lemon은 일반적으로 개발 메카니즘을 기반으로 한 프로그램이 아니다.(??) lemon은 완전한 소스 코드(단지 하나의 C 소스)이며 SQLite 배포에서 "tool" 하위디렉토리 안에 포함되었다. lemond의 문서화는 배포의 "doc" 하위 디톡리에 안에서 찾을 수 있다.

1.5 Code Generator

파서가 완전한 SQL 문장으로 토큰을 어셈블링한 후에, SQL 문장을 필요로 하는 작업을 virtual machine에서 생성하기 위해 코드 생성기를 콜한다. 그것들은 코드 생성기안의 7개의 파일이 있다. 이 파일들은 시리즈 매직 발생의 대부분이다. expr.c는 표현(수식)을 위해 코드 생성을 조작한다. where.c는 SELECT, UPDATE와 DELETE 문장의 WHERE 절을 위한 코드 생성을 조작한다. delete.c, insert.c, select.c, 그리고 update.c는 SQL 문장과 동일한(same?) names를 위한 코드 생성을 조작(조정)한다. 필요한 expr.c와 where.c안의 각자 호출 루틴의 파일(?), 모든 다른 SQL문장은 build.c의 출력 코드다.

1.6 Virtual Machine

코드 생성기에 의해 생성된 프로그램은 vm에 의해 실행된다. vm에 대한 추가적인 정보는 개별적으로 이용할 수 있다. 요약하면 vm은 database 파일을 조작하는 추상 컴퓨팅 엔진 명확하게 디자인되어 구현하였다. 머신은 중간물 스토리지을 위해 사용하기 위해 스택을 가지고 있다. Each instruction contains an opcode and up to three additional operands. vm은 하나의 소스 파일 vdbe.c안에 완전히 포함되었다. vm은 단지 vdbe.h를 가지고 있는데 사이에 vm과 SQLite 라이브러리의 수면(?) 사이의 인터페이스로 정의되었다.

1.7 B-tree Driver

SQLite database는 btree.c 소스 파일안에 B-Tree 구현으로 인한 사용으로 디스크위에서 관리한다. B-tree는 database안의 각각의 table과 index를 위해 사용되기 위해 분리하다. 모든 B-tree는 동일한 디스크 파일안에 저장된다. B-tree는 1024 바이트 크기의 각각의 페이지이다. key와 data는 "payload"를 호출하는 영역안에 함꼐 저장되는 entry(기입, 입장)이다. payload는 B-tree entry에 의해 동일한 페이지 위에 저장될 수 있으며 236 바이트이다.(?) 어떤 추가적인 payload는 overflow page들에 연결고리안에 저장된다. btree.h 헤더 파일에 의해 정의된 B-tree 서브시스템으로 인터페이스한다.

1.8 Page Cache

B-tree 모듈은 1024 byte chunks(덩어리)의 디스크에서 정보를 필요로 한다. page cache는 이 chunks를 읽기, 쓰기, 캐슁하기 위해 응답가능해야 한다. page cache는 단지 database 파일의 rollback과 atomic commit 추상화와 reader/writer 락을 도와주고 제공해준다. B-tree 드라이버는 page cache와 알려진 page cache의 특별한 페이지를 요청한다. 언제 수정된 페이지 또는 commit 또는 rollback이 바꼈을 때, 그리고 페이지 캐쉬는 빠르고 안정하고 유효하게 조작을 필요로 한다 작업의 모두 자세히 산란하게 조작한다.(?) C 소스 파일 pager.c안에 page cache의 코드들이 포함되었다. header file pager.h에 의해 정의된 page cache 서브시스템으로 인터페이스 한다.

1.9 OS Interface

POSIX와 Win32 os 사이에서 호환성있게 제공하며, SQLite는 os의 인터페이스로 추상 계층을 사용한다. os.c 파일은 파일들을 열고, 닫고 지우고, 락을 생성하고 지우는, disk cache를 flushing하고, 앞으로 지원할 것들의 20개의 루틴에 대해 포함한다.(가지고 있다.) 이 평션들은 #ifdefs로 분리된 두개의 구현을 포함한다: POSIX를 위한 하나와 Win32를 위한 다른 것이다. os.h 헤더 파일의 의해 정의된 OS 추상 레이어로 인터페이스(조정한다, 접촉)한다.

2 결론

SQLite의 아키텍처에 대해 알아보았으며, SQLite DBMS 개발에 좋은 참고 자료가 됐으면 합니다.

오역이 있을수 있으므로 미흡한 부분은 원문과 비교해보세요!

3 관련 링크

• sqlite 공식 홈페이지
• The Architecture Of SQLite