LiteFS FAQ
LiteFS는 가능한 한 단일 서버 SQLite 애플리케이션처럼 동작하는 것을 목표로 해요. 하지만 분산 시스템이기 때문에 일부는 예상과 다르게 동작할 수도 있어요. 이 페이지는 LiteFS, 동작 방식, 다른 유사한 데이터베이스 시스템과의 차이점에 대한 자주 묻는 질문에 답을 제공해요.
LiteFS는 가능한 한 단일 서버 SQLite 애플리케이션처럼 동작하는 것을 목표로 해요. 하지만 분산 시스템이기 때문에 어떤 것들은 예상과 다르게 동작할 수 있어요. 이 페이지는 LiteFS의 동작 방식과 다른 유사한 데이터베이스 시스템과의 차이점에 대한 자주 묻는 질문에 답을 제공해요.
출처: 문서
본문
LiteFS는 무엇에 사용되나요?
일반적으로 LiteFS는 애플리케이션 데이터를 사용자와 가까운 서버로 복제하는 데 사용돼요. 애플리케이션 서버가 네트워크를 통해 데이터베이스 서버와 통신하는 대신 로컬의 디스크에 있는 데이터베이스에서 읽기 요청을 처리할 수 있으므로 지연 시간을 줄이는 데 큰 영향을 줘요.
또한 보조 데이터베이스를 서버 함대에 복제해서 기본(primary)의 변경 사항이 복제본(replicas)에 즉시 보이게 할 수도 있어요. 이러한 데이터베이스에는 구성 정보가 포함될 수 있고, 지리공간 조회(geospatial lookups) 같은 보조 데이터가 포함될 수도 있어요.
LiteFS는 어떤 도구를 대체하나요?
LiteFS는 Postgres나 MySQL의 스트리밍 복제와 유사하게 동작하므로, SQLite를 데이터베이스로 사용할 때 그 도구들의 대안으로 사용할 수 있어요. SQLite 읽기 쿼리는 매우 빠르므로 일부 사용자는 Redis나 memcached 같은 도구가 더 이상 필요하지 않다는 것을 발견해요.
LiteFS는 어떤 크기의 데이터베이스를 처리할 수 있나요?
LiteFS는 개별 SQLite 데이터베이스 크기에 대한 하드 제한이 없어요. 일반적으로 네트워크와 디스크 I/O, 그리고 FUSE 파일 시스템 인터페이스의 쓰기 처리량에 의해 제약돼요. 테스트에서 우리는 일반적으로 10GB 이하의 SQLite 데이터베이스를 목표로 하는데, 그 크기가 실제 세계 애플리케이션의 SQLite 데이터베이스 대부분을 차지하기 때문이에요.
디스크 공간이 보통 제한 요소이며, 볼륨에 LiteFS가 임시 트랜잭션 파일을 저장하는 데 사용할 수 있는 여유 디스크 공간이 최소 20-50% 있도록 권장해요. 따라서 10GB 데이터베이스에는 12-15GB 볼륨을 권장해요.
LiteFS 클러스터는 몇 개의 데이터베이스를 처리할 수 있나요?
각 데이터베이스는 기본(primary)과 각 구독하는 복제본에서 현재 상태를 추적하는 데 약간의 메모리를 필요로 해요. 문제없이 LiteFS에서 수십 또는 수백 개의 데이터베이스를 사용할 수 있어야 해요. 우리는 많은 수의 데이터베이스에 대해 제한된 테스트만 했으므로 수천 또는 수십만 개의 데이터베이스는 문제가 될 수 있어요.
LiteFS 사용의 트레이드오프는 무엇인가요?
LiteFS가 사용하는 FUSE는 쓰기 처리량을 초당 약 100 트랜잭션으로 제한하므로, 쓰기가 많은 애플리케이션에는 적합하지 않을 수 있어요. 운영체제가 페이지를 메모리에 자동으로 캐시하므로 읽기 쿼리는 일반적으로 다른 파일 시스템에 비해 느려지지 않아요. 우리는 미래에 FUSE를 피하는 SQLite VFS 구현을 할 예정이며, 그것은 쓰기 속도를 크게 향상시킬 거예요.
다른 복제 도구와 비교할 때, LiteFS는 다른 비동기 스트리밍 복제 방법과 유사한 트레이드오프를 가져요. 비동기 복제는 기본(primary)이 예기치 않게 죽고 아직 복제본에 복제되지 않은 쓰기가 있으면 짧은 데이터 손실 창이 있을 수 있다는 뜻이에요. 우리는 미래에 동기식 복제를 지원할 예정이에요.
LiteFS 배포는 무중단(제로 다운타임)인가요?
LiteFS 클러스터의 롤링 배포는 읽기 가용성 손실을 겪지 않지만, 몇 밀리초의 짧은 쓰기 가용성 손실 창이 있을 수 있어요. LiteFS는 기본(primary) 역할을 다른 후보 노드에 자동으로 넘길 수 있지만, primary 변경이 복제본 노드에 전파되는 데 몇 밀리초가 걸릴 수 있으므로 이 짧은 창 동안 복제본이 이전 primary로 리다이렉트할 수 있어요.
primary 노드의 갑작스러운 실패가 발생하면, 다른 후보 노드가 Consul의 분산 임대(lease)를 통해 primary 상태를 획득해요. 기본적으로 임대의 TTL(time-to-live)은 10초이므로 그만큼 오래 쓰기 가용성을 잃을 수 있어요. 그래도 이 시간 동안 여러분의 데이터베이스는 모든 LiteFS 노드에서 여전히 읽을 수 있어요.
LiteFS와 Litestream의 차이점은 무엇인가요?
Litestream은 단일 노드, 재해 복구 도구로 의도되었어요. 단일 서버만 실행한다면 훌륭한 선택이 될 수 있어요. Litestream 사용의 주요 트레이드오프는 다른 라이브 서버로 데이터를 복제할 수 없고 자동 장애 조치를 지원하지 않는다는 거예요.
LiteFS는 원래 Litestream을 간단한 재해 복구 도구로 유지하기 위해 Litestream에서 분리됐어요. LiteFS는 복제본 서버로의 라이브 복제를 추가하고, 분산 임대를 위해 Consul을 사용해 장애 조치를 제공함으로써 Litestream보다 개선됐어요.
두 도구 사이에서 결정할 때는 일반적으로 단일 서버 배포에는 Litestream을, 다중 서버 배포에는 LiteFS를 선택하게 돼요.