SQLite의 알려지지 않은 이야기

(corecursive.com)

47P by xguru 2021-07-05 | favorite | 댓글 15개

SQLite 개발자 Richard Hipp의 인터뷰 팟캐스트 요약(38분, 스크립트 있음)
본업은 미국 해군의 구축함에 들어가는 소프트웨어 개발자
ㅤ→ 함선 내부에서 사용하는 Informix가 에러가 잦고, 서버가 죽고 연결이 끊어지곤 했음
ㅤ→ 전함이기 때문에 전투중에 피해를 입어도 “DB에 연결할 수 없습니다” 팝업 안보이고 튼튼하게 잘 동작해야 함.
ㅤㅤ트랜잭션도 필요 없고, 어떤 상황에서도 데이터를 램에 읽어들여야 했음
ㅤ→ 서버 없이 실행되는 SQL DB 엔진을 찾아봤는데 없어서, 직접 만들기로 함

SQLite V1 (2000년)

SQL문을 프로그램으로 생각해서 쿼리를 컴파일하고 실행하는 바이트 코드 엔진을 작성
실제로 프로젝트에서 사용되지는 않음 (고객이 Informix를 쓰기 원함)
개발 용도로 쓰면서, 인터넷에 공개했고 그걸 사람들이 쓰기 시작
"Palm Pilot에서 SQL DB를 실행했어요" 같은 말들을 보게 되고 사람들의 주목을 끌었음. 그래서 더 작업을 진행하도록 격려받음.

Motorola

2001~2002년 사이, 모토로라가 자신들의 새로운 전화 OS에 SQLite를 넣겠다고 전화가 옴
필요한 기능을 지원해주면 비용을 내겠다는 것
오픈소스로 돈을 벌 수 있다는 사실을 그때 처음 알게 됨
약 $80,000로 요즘에 비하면 많지 않은 돈이었지만, 본인한테는 굉장히 놀라운 금액이었음.
같이 일하던 세명과 함께 프로젝트를 진행했고 그게 시작이었음

America Online Phones

그 다음으로 연락이 온 것은 AOL 이었음
CD를 우편으로 보내던 시절이었는데, 그 CD 안에는 Database 가 필요했음
즉 CD 안에 SQLite를 넣기를 원했고 새로운 기능을 필요로 했음

Symbian OS 와 Nokia

추수감사절에 런던으로 가서 미팅을 진행(영국은 추수감사절이 없으니까)
Symbian OS를 위한 DB를 원했고, 다른 DB들과 경쟁을 벌임(2개의 오픈소스,7개의 상용)
다른 9개 DB에 튜닝할 기회를 주었지만, SQLite가 최종 승리

Bus Factor [1] 와 콘소시엄

버스팩터는 몇명이 버스에 치이면 개발이 중단되는 지를 의미하는 지표
본인은 풀타임으로 여럿과 함께 일을 하고 있었지만, Symbian 쪽에서 버스 팩터를 높여야 한다고 얘기가 나왔음
SQLite 컨소시엄을 시작해서 프로젝트에 자금을 지원하고 더 많은 사람들이 장기적으로 참여하도록 하자는 것
모든 컨소시엄 멤버들이 투표권을 가지게 하는 것 같은 미친 아이디어를 내었음
모질라 재단의 Mitchell Backer가 이걸 어디선가 듣고 전화를 걸어옴
ㅤ→ "리차드, 당신은 완전히 잘못하고 있어요. 컨소시엄을 만드는 법을 알려줄께요"
ㅤ→ 그녀가 규칙을 만들기 시작
ㅤ→ "개발자들이 통제권을 가져야 해요. 그들의 결정이 최종입니다. 들어간다는 것 만으로 투표권을 가지면 안돼요."
ㅤ→ "이걸 이용하는 회사들은 돈을 기부하는 명예를 얻지만, 최종 결정은 당신이 해야합니다."
ㅤ→ 그녀는 매우 단호했고, 모든 걸 정리했음. 그녀는 변호사임
리차드는 "어떻게 사람들이 참여하게 하죠? 인센티브는 뭐구요?" 라고 얘기하자,
ㅤ→ "걱정하지 마세요. 그들은 참여할 겁니다. 그리고, 실제로 이렇게 하면 Mozilla가 창립 멤버가 될 겁니다."
Mozilla, Symbian 및 Adobe의 지원을 받고, 세 회사와 컨소시엄을 시작
ㅤ→ 처음에 심비안이 콘소시엄이 필요하다고 얘기했을 때 어찌 해야 할지 몰랐음. 어떻게 미첼베이커가 이걸 듣고 전화했는지는 모르지만, 이 모든게 놀라운 여정.

Enter Android : 안드로이드의 시작

모든 스마트폰이 SQLite를 사용하고 있기 때문에, 리차드는 초기 스마트폰 개발을 모든 측면에서 볼 수 있었음
2005년에 안드로이드와 회의를 진행. 그때는 안드로이드도, 아이폰도 나오기 전
상단에 작은 디스플레이와 풀 QWERTY 키보드를 가진 블랙베리와 비슷한 폰에 연결해서 SQLite를 디버깅 했음
실제 동작하는 전화망에 붙은 폰에서 GDB로 디버깅하는 것은 놀라운 경험이었음
그때는 모토로라, 심비안, 노키아의 누구도 그런 걸 하지 않았을 때였고, 이때 안드로이드가 거대해질 것이라는 걸 알았음

Guy, This Is Important : 여러분, 이게 정말 중요해요

그 시절 다른 업체들은 하드웨어와 소프트웨어 업데이트 주기가 30일 정도로 굉장히 길었는데, Android는 실제 망에 붙은 전화기에 하루에 몇 번씩 새로운 OS를 넣었음.
NDA 하에 받은 프로토타입 안드로이드 폰은 3D 프린트 된 것 같은 케이스였지만, 휴대는 가능할 정도 였음.
ㅤ→ 다른 회사의 것들은 큰 브레드보드 & 프로토타입에, 망에도 붙어 있지 않아서 폰으로 쓸 수도 없었음
모토로라, 심비안 사람들에게 "이거 중요하니까 이걸 해결해야 한다고 말하고 싶었지만 말할 수 없었음" (NDA 때문에) 그리고 그게 차이를 만듦

Testing and Aviation Standards : 테스팅과 항법 표준

Adam(인터뷰어) : "지금 리차드의 DB는 정말 활기찬 상태임. 재능 있고 팀도 능력 있지만, 모든 안드로이드폰에 들어가는 DB를 지원하는 1~4명의 소프트웨어 컨설팅 회사임. 개발자들은 DB에 굉장히 열심이고, 데이터에 문제가 생기는 걸 싫어합니다"
우리는 모든 사람에게 Naive하게 SQLite 는 버그가 없다고 자랑하고 있었지만, 안드로이드는 확실히 우리가 틀렸다는 것을 증명했음.
버그없이 소프트웨어를 만들수 있을거라 생각했지만, 소프트웨어가 수백만개의 장비에 설치될 때 얼마나 버그가 많이 날 수 있는지 놀라울 정도임.
그때쯤에 항공전자공학(Avionics) 회사인 Rockwell Collins와 일을 하고 있었는데, 그들이 DO-178B [2] 개념을 소개해줬음.
ㅤ→ DO-178B는 안전이 중요한 항공 제품들의 품질 표준에 관한 것인데, 다른 품질 표준과 달리 "읽을 수 있음(readable)"
ㅤ→ 몇백달러 쯤 하는데 얇으니까 꼭 읽어보기를 권함
실제로 DO-178B의 프로세스를 따르기 시작했고, 그중 하나가 100% MCDC Test Coverage
MCDC(Modified Condition / Decision Coverage) [3] 는 테스트가 개별 분기를 적어도 한번 이상 통과해야 하는 것
SQLite 가 MCDC 100% 가 되는데 주당 60시간 기준으로 1년이 걸렸음. 정말 정말 어려웠음. 매일 12시간을 해야 했고 정말 피곤.
90~95% 의 테스트 커버리지는 쉬운데 나머지 5%가 정말 어려움. 하지만 1년간 그렇게 해서 최종적으로 100%에 도달하자 Android 에서 버그리포트가 오지 않게 되었음
그때부터 작동하기 시작했고, 큰 차이를 내었음. 그 이후 8~-9년동안 버그가 없었음.

수십억개의 테스트

첫번째는 TCL(Tool Command Language)로 작성되었고, 일반적인 개발자 테스트 였음
아직도 첫번째 TCL테스트는 유지 보수하고 있고 공개되어 있음. 100%는 아니지만 SQLite 의 모든 기능을 상세 테스트 함.
MCDC 100% 커버리지는 TH3 라고 부르고 공개하지 않음 (proprietary)
이걸 항공회사에 팔아서 돈을 벌어보려고 했지만 한개도 못팔았으니 효과는 없었음..
하지만 우리 제품을 정말 견고하게 유지하고 새로운 기능 과 버그 수정을 빠르게 해볼 수 있게 해줌
테스트 갯수를 세기는 어렵지만 10만개의 개별테스트가 매개 변수화 되어서 수십억개의 테스트가 실행 됨
체크리스트가 있고, 릴리즈전 최소 3일 동안 테스트를 진행함
의도적으로 여러 개의 OS에서 테스트를 진행함
ㅤ→ 요즘은 모든 장비들이 리틀 엔디안이지만 예전엔 빅엔디안들도 많았음. 그래서 PowerPC iBook 에서 빅엔디안 테스트를 진행
ㅤ→ 32비트 플랫폼과 ARM 과 Intel, 64 Bit 플랫폼, 윈도우, 리눅스, 맥, OpenBSD 등 우리가 할수 있는 모든 플랫폼과 OS에서 테스트를 진행
ㅤ→ 여러개의 다른 테스트 스윗이 있고, 원래 TCL도 있고, TH3도 있음. 지속적으로 실행되는 Fuzzer(퍼지 테스팅)도 있음.
SQL Logic 테스트도 있음
ㅤ→ 10년전에 Shane Harrelson 이 만든 엄청난 더미의 SQL 문장
ㅤ→ 손댈 수 있는 모든 DB에서 테스트 했는데 모든 DB엔진이 답을 못내고, 세그멘테이션 폴트를 내었음. SQLite 포함. 단, Postgres 만 빼고.
ㅤ→ Postgres 만 항상 결과를 내었고 결점을 찾을수 없었음. Postgres 개발자들은 우리가 충분히 노력하지 않은거라고 했지만.. Postgres에 에러를 내는 것은 가능은 했겠지만, 우린 매우 감동했음
ㅤ→ 상용 버전 Oracle도 크래시 내었고, DB2도 크래시 냄
ㅤ→ 중요한 포인트는 SQLite가 이 모든 쿼리들에 대해서 동일한 답을 내도록 했다는 것

Building From First Principles

처음에 작성을 시작했을 때, 어떻게 SQL DB 엔진을 만드는지 레퍼런스가 있는지 찾아보려고 했는데 없었음. 그래서 직접 만들어야 했고, 완전히 독립적인 임무였음.
많은 이론들이 MIT, 하바드, 버클리에서 일어나고 있었지만 그 학교들에 가지 않으면 이론이 존재한다는 사실조차 몰랐고, 찾는 방법도 없었음.
Postgres 가 사용하는 Volcano 모델과 SQLite 가 사용하는 Byte Code 모델은 살펴보면 우린 모두 같은 아이디어로 수렴됨
위에서 보면 매우 다른 곳에서 시작하지만, 우린 어떻게 그걸 더 빠르게 하는가에서 같은 영역에 수렴함
이게 이론적으로 일종의 검증이라고 생각함. 두개의 독립적인 개발라인이 동일한 답을 내놓는 것
예를 들어서, 나는 Covering Index에 대해서는 전혀 몰랐는데, 독일에서 열린 PHP 컨퍼런스에 참석했을 때, MySQL의 David Axmark도 참여해서 강연을 했음
ㅤ→ 그 강연에서 MysQL 이 어떻게 Covering Index를 만들었는지 설명함
ㅤ→ DB의 인덱스에 어러개 컬럼이 있을때, 인덱스의 앞쪽 컬럼에 대해서만 쿼리하고 답이 나머지 컬럼에 있다면 DB는 원본 테이블 조회없이 인덱스만으로도 사용 가능해서 작업이 빨라짐
ㅤ→ 그래서 집으로 돌아오는 비행기에서 사람이 별로 없길래, 랩탑을 열고 대서양 상공에서 SQLite 의 커버링 인덱스를 구현했음

B-Trees and The Art of Computer Programming

많은걸 직접 만들어야 했음. 아무도 나에게 B Tree를 가르쳐 준적이 없음. 그냥 들어봤을뿐.
직접 B트리를 개발하려고 할때, 책장에서 Don Knuth의 TAOCP 가 있어서 B트리를 찾았고 그가 알고리듬을 설명해줬음
재미난건, 책에는 B트리 검색과 삽입 알고리듬은 자세히 설명하지만, 삭제하는 알고리듬은 제공하지 않음. 그건 챕터 끝 연습문제에 있어서, 나만의 B 트리를 만들기 전에 문제를 풀어야 했음. "고마워요 Don, 정말 감사해요."
현 시대의 사람들은 적어도 TAOCP 를 읽거나 훑어보기라도 해야함

Freedom to Build It Yourself : 직접 만들 수 있는 자유

SQLite 는 Richard 가 직접 만든 것 외에는 아무것에도 의존성이 없음 (C 컴파일러와 libc 제외하고). 직접 버전관리 시스템도 만들고 버그 트래커도 만듬. 이게 리차드에게 자유를 줌
자유(Freedom)라는 것은 자신을 스스로 돌보는 것을 의미
배낭여행 가는 사람들이 필요한 모든 것을 등에 지고 가면서 자유롭다고 하는 것은 그들이 직접 자신을 케어하기 때문
모든 것을 직접 만든다면 누군가에게 묶여있지 않기 때문에 그 안에 자유가 있음
만약 SQLite 2의 스토리지 엔진으로 Berkeley DB를 선택했다고 가정해보면
ㅤ→ 그 당시엔 Berkeley DB는 오픈소스 였지만 나중에 Oracle 에 매각되어서 듀얼 소스 독점 모델이 되어서 라이선스 비용을 내지 않고는 최신 버전의 소스코드를 얻지 못하게 되었음
지금 SQLite 의 Parser Generator는 Yak 나 Bison 을 사용하지 않고 Lemon 이라 불리는 직접 작성한 것인데, 그래서 새로운 언어 기능이 필요할 때 그것들에 묶이지 않고 수정할 수 있었음
2000년대 초에는 모든 프로젝트 CVS를 사용하기에 그걸 썼지만, 2000년대 중반이 되면서 분산 버전 관리 아이디어가 나오기 시작

Fossil 구축

Git 과 Mercurial 을 보고 요구사항을 정리한뒤 직접 버전관리 시스템을 개발하기로 함
이제 Fossil 은 잘 동작해서, 자체 프로젝트가 되었음
토발즈가 Linux Kernel 개발을 지원하기 위해 Git을 만들었기에, Linux Kernel 관련 일을 한다면 Git 이 완벽한 버전관리 시스템
Fossil 은 SQLite 작업을 하기위해 딱 맞는 버전 관리 시스템임. 내가 직접 만들었기에 내 요구사항을 정확히 충족
직접 개발함으로써, 자신의 운명을 통제하고, 더 많은 자유를 가지고, 제3자에게 의존하지 않게 됨

자급자족하기

도시를 벗어나서 직접 식량을 키우고 사는 사람을 뭐라고 할까요? Survivalist (생존주의자) ? 또는 Prepper (준비자)
"당신과 연락하는 동안에도 봤듯이 제 Gmail 이 조금 이상해요. 메일이 자꾸 리턴됩니다. 그래서 내 메일 서버를 만들려고 해요. 우리가 이 미팅을 셋업하는 중에도 관련 노트를 작성하고 있었어요. DB 엔진을 작성하는 것보다 어렵지는 않겠지만 Gmail 에 얽매이고 싶지는 않아요. 그들이 내 운명을 통제하는 것을 원하지 않아요. 그들이 내 모든 대화의 기록을 제어하는 것을 원하지 않아요. 내가 직접 통제하고 싶고, 그래서 고통스럽고 할일이 많겠지만 직접 통제할 해결책을 찾기위해 노력하려고 합니다. 클라우드에서 가상머신을 임대해서 실행해서 제3자에 의존하지 않아도 됩니다."
누군가 찾아와서 당신의 문제를 해결해 주겠어요 한다면, 그들이 당신의 자유를 빼앗아 갈거라는 것을 알아야 합니다. "자유롭고 싶다면 직접 해야 해요"

다른 사람을 위한 조언

저는 서버가 필요없이 직접 디스크에서 읽고 쓰는 DB 엔진을 만들겟다는 미친 아이디어로 시작했습니다.
전문가들에게 물어보면 "그건 불가능해요. 절대 동작하지 않을꺼에요. 멍청한 아이디어 입니다."라고 할겁니다.
다행스럽게도 난 그런 전문가들을 몰라서 그냥 했고, 이런 일들이 일어났습니다.
전문가들의 말을 많이 듣지 말고, 말이 되는 일을 하세요. 당신의 문제를 해결하세요

[1] Bus Factor : 팀원이 버스에 치어서 팀이 위기에 빠질 수 있는 위험도.

팀 멤버 간에 정보 및 기능들이 공유되지 않아서 생길수 있는 위험을 말하는 지표.
이 지수를 높여야 정보가 공유되고, 특정인에게 업무가 집중되지 않음.

[2] DO-178B : 항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항 (Software Considerations in Airborne Systems and Equipment Certification )

미연방항공국(FAA)에 의해 항공용 소프트웨어 인증을 위한 적합성 입증 방법으로 채택

[3] MCDC : Modified Condition / Decision Coverage

여러 개의 조건식이 있을 때, 각 개별 조건식이 다른 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 테스트 케이스를 설계하는 방법

▲

mkeasy 2021-07-08 [-]

몇번이고 다시 읽어보게 하는 글이네요. 감사합니다.
자유롭고 싶다면 직접 해야 해요.
말이 되는 일을 하세요.
당신의 문제를 해결하세요.