마음에 드는 검사 결과네요.

저희 병원 홈페이지 만들면서 백엔드 디비를 그놈으로 한번 해 볼까요. ^^;

김상기님의 글 잘 보았습니다.

상당히 여러모로 테스트 해보시는 군요.

저도 sqlite에 대하여 여러모로 분석해 보았습니다.

상당히 잘 만든 자료입니다.

저희 회사도 이와 비슷하게(정확하게 말하면 이보다는

규모가 작지만) db를 제작하여 1년전부터 서비스하고

있습니다.

쇼핑몰, 클럽, 홈빌더,인트라넷,게시판,회원관리등

이 db를 이용하여 움직이고 있습니다.

현재는 아직 Mysql 보다 3배 정도 밖에 성능을 내지

못하고 있습니다.

이 db를 이용한 PHP로 제작된 클럽은 무료배포를

9월 15일 부터 배포 할 예정입니다.

참고하시면 추가 자료가 되리라 봅니다.

http://blueboard.co.kr

입니다.

아 그리고 sqlite db나 저희 db 에 궁금한 사항이 

있으신 분은 MSN 으로 연락주세요. 언제나 환영입니다.

MSN : pado100@korea.com

sqlite 의 내용을 보고 php를 이용해 윈도우환경에서 실험을 해보았으나

자료삽입,삭제 속도가 너무 너무 느리고(2K  용량 10000건 삽입시 20여분) 자료가 30만건이 됐을때 아에 자료접근이 안되는 군요.. 무슨 이유인지.. 최적화 관련 작업이 따로 필요하나요

SQLite도 대용량으로 데이터를 집어넣어야할 경우는 PostgreSQL 처럼 insert 구문을 사용하지 않고, copy 구문을 사용합니다.

한 예를 들어, 검색 캐쉬를 예를 들면,

일단 검색 결과를 아무런 정렬없이 sqlite temp table로 copy 구문을 이용해서 집어넣고,

원하는 만큼 작업을 해서, 다시 insert into ... select 구문으로 집어넣지요.

이 작업을 하는데, 그 결과치가 5천건일 경우 약 1초 미만으로 작업이 끝납니다. (SQLite에서는 1초를 넘어가는 작업이 잘 없거든요. :))

하지만,

SQLite 놈을 main db로 사용한다는 것은 무리입니다.

main db가 하기에는 시답잖고(?), 쓸데없이 부하가 많이 많이 걸리는 그런 부분을 SQLite가 맡으면 제일 멋있는 모습이 될 듯 합니다.

제가 테스트 한 것으로 약 2백만건 테이터는 무난히 그것도 여느 RDBMS에서 찾아보기 힘들 정도의 속도로 입력이 되고, 처리됩니다. 단지 흠이 있다면, 인덱스를 사용하는데, 그 자료를 삭제해야할 경우는 내부적으로 reindex를 하는지, 속도가 많이 떨어지더군요.

SQLite가 사용되면 딱 인곳.

1. 간단한 로컬(file base) db
2. select 전용 db
3. 응용프로그램의 임베디드 db
4. 통계자료 보관 db
5. 검색 캐쉬 db
6. 윗 실전처럼 대용량 커뮤니티의 각 게시판들

딱이 아닌 곳.

1. 자료 보안이 철저해야하는 곳
2. 자료 무결성이 철저해야하는 곳
3. 영업(쇼핑몰)같은 곳 같이 잦은 트랜젝션이 일어나는 곳

이곳 DSN 설계의 두번째 안이 db를 분리하는 것입니다.

사용자측 front db는 sqlite로, 그 뒷단 backend db는 PostgreSQL로,

자료가 입력력되면, PostgreSQL 트리거에서 SQLite측으로 자료를 중복으로 입력하고, 사용자는 그 SQLite놈을 이용해서 보게 되는게지요. 이렇게 한다면, 지금의 속도에서 정확이 두배 이상의 속도를 내면서, DB 측 퍼포먼스를 70% 이상 줄일 수 있겠지요. (어마어마한 수치입니다. - 구현만 된다면)

물론 생각에 그쳤습니다. 실력도 없거니와 시간도 없어서...