database.sarang.net
UserID
Passwd
Database
ㆍDBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DBMS Q&A 835 게시물 읽기
No. 835
SQLite 이야기 두번째
작성자
김상기(ioseph)
작성일
2003-09-05 00:23
조회수
10,424

이곳 DSN의 오라클 게시판 full text index 자료가 약 140만건 정도입니다.

이 자료를 sqlite 자료로 변환하고, 똑 같은 쿼리를 실행해 보았습니다.

 

당연히 같은 시스템에서 이루워진 것이니까, 그 비교가 그럭저럭 신뢰성은 있겠지요.

 

기존 PostgreSQL v7.3.4 속도보다 정확히 두배 빠르네요.

테스트한 SQLite 버전은 2.8.6.

두개 쿼리의 intersect 결과에 대한 정렬을 하는데, 걸리는 시간이 평균 50ms 정도입니다. (지금까지 경험한 최고의 수치입니다. 어느 광고처럼 '따라올테면 따라와봐'를 실감하는 순간이었습니다) 발견빈도수가 낮은 것은 심하면, 0.x ms에서 발견빈도수가 높아도 800ms 속도를 보이는 군요.

욕심같아서는 더 엄청난 데이터로 테스트를 해보고싶었것만 자료가 없어서..

 

한번에 대량의 자료조작(insert, update, delete)이 아주 빈번히 일어나는 자료가 아니라면, SQLite 엔진을 사용하는 것을 검토해 보는 것도 괜찮은 것 같습니다.

이 글에 대한 댓글이 총 4건 있습니다.

 

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

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

정재익(advance)님이 2003-09-05 10:19에 작성한 댓글입니다.

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

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

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

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

 

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

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

있습니다.

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

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

 

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

못하고 있습니다.

 

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

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

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

http://blueboard.co.kr

입니다.

 

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

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

MSN : pado100@korea.com

 

김파도님이 2003-09-06 08:56에 작성한 댓글입니다. Edit

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

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

서정호님이 2003-09-19 15:49에 작성한 댓글입니다. Edit

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% 이상 줄일 수 있겠지요. (어마어마한 수치입니다. - 구현만 된다면)

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

 

김상기(ioseph)님이 2003-09-21 23:39에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
840database-backed webpage? [1]
김청수
2003-09-10
4952
837집계 함수 [1]
김상기
2003-09-06
5344
835SQLite 이야기 두번째 [4]
김상기
2003-09-05
10424
833한국데이터베이스진흥센터 [2]
DPC
2003-09-03
6510
831쿼리 갯수가 틀려요.. [3]
jeje
2003-09-01
5421
829색인이라는게뭔가요설명좀.. [1]
ㅎㅎ
2003-08-31
5871
827[질문] DB 스키마를 이용해 ERD를 그려주는... [1]
주성식
2003-08-29
6748
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다