회사에서 같이 일하는 분이 테스트 프로그램에서 실제 데이터베이스 대신에 SQLite를 쓰는데 문제가 있다는 얘길 하시더라.
(실제 데이터베이스에 비해) 너무 느려서, 데이터베이스 쪽과 연동된 코드들이 원하는대로 동작하지 않는다는 것.
그래서 어느 부분이 병목인지 시험해볼 수 있는 팁을 하나 알려드렸다. ((SQLite 자체가 문제인지, 아니면 주변 로직이 문제인지 검사하는 팁이라고 좀 더 정확하겠다))
SQLite 연결을 생성할 때 파일 경로 대신에 :memory: 를 주는 것. 이러면 in-memory DB 처럼 동작한다.
다만 여기엔 거대한 문제가 있다. 이런 식으로 데이터베이스를 만들면 persistency가 없다. 해당 연결을 닫아버리면 끝이다.
SQLite의 .dump 명령어를 구현하면 얘기가 좀 다르겠지만 프로그램이 크래시할 때 데이터가 날아갈 수 있다면 데이터베이스라고 부르기는 좀 뭣해지니 (…); ((.dump 자체가 transaction 안에서 모든 테이블과 인덱스를 내보내는 명령이라 데이터가 크다면 (하략) ))
자세한 내용은 모르지만 아마 autocommit으로 써서 느린게 아닐까 싶네요 <- 제가 SQLite 처음에 쓰며 겪었던…-_-;
예를 들어 다중 insert의 경우에 따로 begin~commit으로 묶어주지 않으면 매번 insert마다 저널링 파일을 만들었다가 commit하는 작업을 하므로 당연히 느립니다.
이 부분이 해소되면 SQLite는 Client-Server 구조의 DBMS가 아니므로 통신 비용이 없어 상당히 빠르지요.
Random 쓰기라서 autocommit 여부랑은 별 상관이 없을 것 같습니다. 그리고 CS 구조는 쿼리를 보내는 주체가 하나가 아닌 이상 latency에는 영향을 주지만 throughput에는 영향을 주지 않습니다.
제가 알기로는 한번 Write할때마다 전 Database가 Lock되는걸로 알고 있는데… 맞습니까?
http://six605.tistory.com/294
: SQLite 는 전체 database 에 대해 reader/writer locks 을 사용한다.
따라서 어떤 프로세스가 database 의 특정 부분을 읽기 있을 때, 다른 모든 프로세스
는 database 의 쓰기가 금지 된다. 비슷하게 한 프로세스가 database 의 특정 부분을
쓰고 있다면 다른 모든 프로세스는 읽기가 금지 된다.
모든 경우에서 이 같은 점은 문제가 되지 않는다. 어플리케이션이 빠른 속도로 data-
base 에 작업을 한다면. 그러나 엄격한 동시성을 요구하는 어플리케이션에서는 문제가
될 수 있다. 이런 어플리케이션은 다른 database 엔진을 찾기를 권한다.
뭐. 잘 쓸수 있는 방법이 있는지는 모르겠습니다만… -_-a….
여튼.. 예전에 Backup용 db로 쓸려다가 포기했던 경험이 있습니다.
제 경우는 write가 생각보다 너무 퍼포먼스가 안나오더군요.
네 맞습니다. SQLite가 파일 단위로 락을 잡으니 저건 당연한 동작입니다.