데이터베이스/SQL

SQLite은 언제 사용하면 좋을까?

한땀코딩 2020. 6. 28. 22:58

SQL이라는 존재 자체를 처음 접한 건 데잇걸즈 수업을 통해서였다. pandas로 csv 파일만 읽고 쓰던 작업을 하던 중에 잠시 맛보기처럼 배웠는데, 실무에서 많이 쓰인다는 건 조금 나중에 알게 되었다. SQL의 사용 빈도는 차치하고, 최근에 db를 붙여보는 것에 도전하고 싶어 이래저래 찾다 보니 sqlite를 다시 만나게 되었다. 처음 SQL을 접할 때도 sqlite를 설치해서 간단하게 쿼리문을 작성했던 기억이 난다. 42 과제나 실제 많은 서비스를 살펴보면 MySQL이나 Oracle을 사용하는데, 이들과 sqlite는 어떤 차이가 있을까.

SQLite는 이럴 때 사용하자!

 

Appropriate Uses For SQLite

Embedded devices and the internet of things Because an SQLite database requires no administration, it works well in devices that must operate without expert human support. SQLite is a good fit for use in cellphones, set-top boxes, televisions, game console

www.sqlite.org

공식 사이트에서 제공하는 문서인데, 꽤 쉽고 명확하게 잘 설명되어 있다. 그 중에서도 인상 깊은 것이 인트로인데 번역하면 다음과 같다.

SQLite is not directly comparable to client/server SQL database engines such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is trying to solve a different problem.
Client/server SQL database engines strive to implement a shared repository of enterprise data. They emphasize scalability, concurrency, centralization, and control. SQLite strives to provide local data storage for individual applications and devices. SQLite emphasizes economy, efficiency, reliability, independence, and simplicity.
SQLite does not compete with client/server databases. SQLite competes with fopen().
SQLite는 MySQL, Oracle, PostgreSQL, SQL Server와 같은 클라이언트/서버 SQL 데이터베이스 엔진과는 애초에 해결하고자 하는 문제가 달라서 직접적인 비교가 어렵습니다. 클라이언트/서버 SQL 데이터베이스 엔진은 기업의 데이터의 공용 저장소를 구현하는 데 중점을 두고 있어 확장성, 동시 접근성, 데이터 중앙집권화, 제어(컨트롤) 등을 강조합니다. SQLite는 개별 앱과 기기를 위한 로컬 저장소를 제공하는 데 중점을 두고 있습니다. SQLite는 경제성, 효율성, 확실성, 독립성, 단순함을 강조합니다.

SQLite는 클라이언트/서버 데이터베이스가 아닌 fopen()과 경쟁합니다.

마지막 문장이 포인트가 아닌가 싶다. 실제로 프로젝트를 진행하면서 AWS등을 통해 배포를 하고, 또 클라이언트/서버 sql에 대한 정보가 부족한 문제 등 제약이 많아서 알아보게 된 것이 sqlite였다 (온라인 예시에도 flask 자체도 sqlite와 SQLalchemy등을 통해 연동이 잘 되어 있었다). 유저 입장에서 데이터베이스에 write 할 것이 없기에, 필요할 때만 데이터를 뽑아오는 게 전부인 프로젝트인데 csv나 json파일을 마구 생성하여 관리하기보다는 가볍게 SQLite로 작업하는 것도 괜찮은 방법으로 보인다. SQLite의 db는 .db 확장자를 가지는 바이너리 파일이기 때문에 서버를 연동하는 작업 대신 그냥 파일을 함께 올려버리면 되는 편의성이 있다.

SQLite 체크리스트

공식 사이트에선 적절한 데이터베이스 엔진을 고르기 위한 체크리스트를 제공하고 있다.

  1. 데이터가 어플리케이션과 네트워크 통신을 해야 접근이 가능한가? → 클라이언트/서버 엔진

  2. 데이터베이스에 동시에 작성하는 경우가 많은가? → 클라이언트/서버 엔진

  3. 빅데이터를 다루는가? → 클라이언트/서버 엔진

  4. 그 외 → SQLite!

    동시에 데이터베이스를 작성하는 일이 크게 없고, 테라바이트 이하의 데이터라면 SQLite가 나을 수도 있습니다. SQLite는 빠르고 안정적이며 설정이나 관리도 필요가 없습니다. 단순하거든요. SQLite로도 충분할지도?

    For device-local storage with low writer concurrency and less than a terabyte of content, SQLite is almost always a better solution. SQLite is fast and reliable and it requires no configuration or maintenance. It keeps things simple. SQLite "just works".

이런 의미에서 특히나 수업이나 SQL 교육 목적으로도 많이 사용된다고 한다.

기타

다른 데이터베이스도 크게 다를지는 모르겠으나, SQLite는 파일로 관리되는 만큼, 너무나 당연히 깃허브에 올렸다가 낭패를 보았다. SQLite의 db파일은 깃으로 관리되지 않기 때문에, 푸시를 해봤자 이름만 똑같은 빈 파일이 올라간다. 이런 이유로 협업을 위한 데이터베이스를 찾는 중이라면 SQLite는 적절치 않을 것 같다.