▲

GN⁺: 웹 서버 정적 콘텐츠 저장소로 SQLite 사용

 (clace.io)
3P by neo 31일전 | favorite | 댓글 1개

웹 서버 정적 콘텐츠 저장소로서의 SQLite 사용

배경

  • Clace는 주로 내부 도구를 위한 웹 애플리케이션을 제공하기 위해 설계된 플랫폼임.
  • Clace는 웹 서버와 애플리케이션 서버가 별도로 처리하는 기능을 통합하여 제공함.
  • Clace 개발 초기에는 애플리케이션 데이터와 메타데이터를 어떻게 저장할지 결정하는 것이 중요했음.
  • 메타데이터는 데이터베이스에 저장하는 것이 합리적이었고, 정적 파일은 보통 파일 시스템에 저장됨.

파일 제공을 위한 SQLite 사용

  • Clace는 파일 시스템 대신 SQLite를 사용하여 앱 파일을 저장하기로 결정함.
  • 이는 원자적 버전 변경을 가능하게 하여, 업데이트 시 여러 파일을 한 번에 트랜잭션으로 처리할 수 있음.
  • 앱 생성 및 업데이트 시 모든 파일은 SQLite 데이터베이스에 업로드되며, 개발 모드에서는 로컬 파일 시스템을 사용함.

SQLite 사용의 이점

  • 트랜잭션 업데이트: 여러 파일을 한 번에 업데이트할 수 있으며, 업데이트 중 깨진 웹앱이 없도록 보장함.
  • 배포 롤백: 오류 발생 시 배포를 롤백할 수 있으며, 데이터베이스 트랜잭션 롤백이 파일 시스템 정리보다 쉬움.
  • 버전 간 파일 중복 제거: 동일한 파일이 여러 버전에 존재해도 파일 내용은 한 번만 저장됨.
  • 앱 간 중복 제거: 여러 앱 간 동일한 파일이 존재할 때 중복을 방지함.
  • 백업 용이성: SQLite를 사용하여 시스템 상태를 쉽게 백업할 수 있음.
  • 콘텐츠 해싱: 파일 업로드 시 콘텐츠 SHA를 저장하여 브라우저 캐싱을 용이하게 함.
  • 압축: 파일 내용은 Brotli로 압축되어 저장되며, 다양한 형식으로 쉽게 저장 가능함.

성능

  • Clace의 SQLite 데이터베이스 접근 방식은 뛰어난 성능을 제공함.
  • 파일 시스템을 사용하는 동등한 구현이 없어 직접적인 벤치마크 테스트는 수행되지 않았음.
  • SQLite 팀의 벤치마크에 따르면, 일부 작업 부하에서 SQLite가 파일 시스템보다 더 나은 성능을 가질 수 있음.

멀티 노드 지원

  • Clace는 현재 단일 노드에서 실행됨.
  • 멀티 노드 지원이 추가되면, 로컬 SQLite 대신 공유 Postgres 데이터베이스를 사용할 계획임.
  • 이로 인해 지연 문제가 발생할 수 있으며, 로컬 SQLite 데이터베이스를 파일 캐시로 사용하여 지연을 줄일 계획임.

이 접근 방식이 일반적이지 않은 이유

  • 대부분의 웹 서버가 파일 시스템을 사용하는 이유는 편리함 때문임.
  • 파일 시스템 도구를 사용하여 파일 업데이트가 가능하며, 데이터베이스를 사용하면 파일 업로드를 위한 API 인터페이스가 필요함.

GN⁺의 정리

  • Clace는 내부 도구 개발 및 배포를 위한 플랫폼으로, SQLite를 사용하여 파일 저장의 이점을 극대화함.
  • SQLite를 사용함으로써 트랜잭션 업데이트, 롤백, 중복 제거, 백업 용이성 등 다양한 이점을 제공함.
  • 이 접근 방식은 파일 시스템의 편리함과 역사적 이유로 인해 일반적이지 않지만, SQLite의 성능과 기능을 활용하여 효율성을 높임.
  • 유사한 기능을 가진 프로젝트로는 Firebase, AWS Lambda 등이 추천됨.
▲
neo 31일전  [-]
Hacker News 의견

  • 몇 년 전 "35% Faster Than The Filesystem" 기사에서 영감을 받아 SQLite를 사용하여 정적 파일을 제공하는 실험을 했음. Datasette를 통해 SQLite에서 정적 파일을 제공하는 플러그인을 만들었지만 많이 사용하지는 않았음. SQLite를 사용하여 파일을 제공하려면 "sqlite-utils insert-files" CLI 도구가 유용할 수 있음.

  • 트랜잭션 업데이트는 여러 파일을 한 번에 업데이트할 수 있는 주요 이점임. 서버가 SQLite나 파일 시스템을 사용하더라도 업데이트 중에 웹앱이 깨지는 것을 막을 수는 없음. 페이지의 모든 하위 리소스가 특정 콘텐츠 해시나 버전 이름을 사용하여 참조되도록 해야 함.

  • 2011/2012년에 작은 게임 개발 회사에서 일할 때, 모든 자산을 sqlite3 데이터베이스에 저장하고 pak 파일을 만들어 파일의 오프셋을 저장했음. 모바일 게임에서 자산을 빠르게 로드할 수 있었고, 메타데이터를 데이터베이스에 저장하여 유사한 파일을 쉽게 찾을 수 있었음.

  • 파일 시스템 대신 SQLite를 사용하여 파일을 쿼리할 수 있는 장점이 있음. SQL 쿼리는 Kysely를 사용하여 타입 세이프하게 사용할 수 있음.

  • SQLite를 사용하여 정적 콘텐츠를 제공하는 아이디어는 완전하지 않음. 현대 웹 서버는 정적 파일을 처리하는 최적의 전략을 사용함. SQLite는 메모리 매핑 I/O 지원을 제공하지만, 대규모 웹사이트에는 적합하지 않음.

  • SQLite는 하루 100K 히트 이하의 웹사이트에 적합함. SQLite 웹사이트는 하루 400K~500K HTTP 요청을 처리하며, 대부분의 경우 로드 평균이 0.1 이하임.

  • 정적 사이트 생성기 CMS는 SQLite 데이터베이스를 사용하여 웹사이트를 개발하고 업데이트하며, 그런 다음 정적 페이지로 파일 시스템에 덤프하여 배포함.

  • 고성능 과학 컴퓨팅에서 데이터에 접근하는 가장 유연하고 고성능의 방법은 종종 램디스크에 있는 읽기 전용 SQLite 데이터베이스임.

  • 파일 시스템이 중복 제거, 스냅샷, 버전 관리, 압축을 제공할 수 있는 경우와 SQLite 접근 방식을 비교하는 것이 흥미로울 것임. 고급 파일 시스템을 사용하면 디렉토리를 새 버전으로 교체하는 것이 더 쉬울 수 있음.

  • 데이터베이스를 파일 시스템으로 사용하는 접근 방식은 장점이 있지만, 문제가 발생할 때는 악몽이 될 수 있음.

답변달기