대부분의 게임 서버 류의 응용에서는 DB 연결이 필요하다. 근데 이게 복잡한 SQL query 사용이 없거나 적다 — join 연산이 매우 적다. 그리고 프로토타입 개발 중일 때는 일부 성능 검사 때 빼곤 DB에 큰 부하가 걸리지도 않는다(…). 게다가 데이터 베이스에 저장할 내용도 좀 뻔하다(타입면에서나 테이블 구조면에서나…).
그런 연유로(…) 개발 중인 프로토타입 서버에서 DB 연결을 직접 안만들고 — 보통 이 동네도 3–tier 라 중간층을 두는데 여기서 adapt 하게 했다 — SQLite DB 객체가 미들웨어 연결인 것처럼 속여서(…) 쓰게 해봤다.
여튼 몇 가지 테스트 해본 결과는 대략 만족스러운데 이유가,
- SQLite는 RDBMS다. 대부분의 쿼리를 쓸 수 있음
- 파일 하나고 별도의 프로세스가 없다 — 즉 별도의 설정/설치가 필요없다
- 트랜잭션을 쓸 수 있다
- 약간의 코드로 ODBC 연결인양 위장(?)할 수 있다
- 라이브러리가 하나의 C 파일과 헤더 두 개로 구성된다 ((C 파일 하나로 합치는 방법/합쳐진 타르볼이 있다))
정도…
대략 실제 서버 개발 전의 (응용 개발 전의) 프로토타입 수준에서 귀찮게 MySQL이나 MSSQL 서버같은 녀석을 붙일게 아니라, 적당한 래퍼를 만들고 거기서 SQLite를 쓰는 것도 괜찮은 선택일 것 같다.
바이너리 하나만 있으면(…) SQLite 디비 파일을 읽는 것도 쉽기 때문에 유닛테스트에 붙이기도 쉬운 편이다.
ps. 사실 락을 테이블 단위나 row 단위로 유지하지 못하는 것 때문에 성능 병목이 있을 수 있어서 끝까지 가져가진 못하지만, 그렇지 않은 상당 수의 (개인 수준?) 응용에선 실제로도 SQLite를 쓴다…
그간 구독하며 깊으신 지식에 감탄해 온 블로그였는데 댓글을 달 줄은 몰랐군요.
SQLite는 저도 관심있게 보고 가끔 쓰다보니…^^ 아무래도 쓰기 간편하면서도 있을 기능은 다 있다는게 최고의 장점이죠. DB 레벨 락은 좀 아쉽긴 하지만…
근데 홈페이지 도큐먼트는 좀 업데이트 했으면 싶더군요(눈여겨 보면 꽤 오래된 – 현재 버전과 안 맞는 내용들이 많습니다 -_-).
과분한 칭찬이 좀 낯간지럽지만(…);
SQLite가 쓰기 편하단 점에선 참 좋죠. 테이블/row 단위 락이 생기면 좋을 것 같지만 그럼 지금처럼 작은 라이브러리로 남진 못하겠죠;