모든 데이터 동기화 중단
(sqlsync.dev)엣지 복제에 대한 새로운 접근 방식
- 데이터 동기화는 생각보다 어려운 문제임. 기존 솔루션은 전체 데이터셋을 클라이언트에 동기화하거나, 논리적 변경을 추적하는 방식으로 나뉨.
- Graft는 이러한 문제를 해결하기 위해 설계되었으며, 간단한 물리적 복제와 효율적인 논리적 복제를 결합한 오픈 소스 저장 엔진임.
게으른 동기화: 원하는 속도로 동기화
- Graft는 클라이언트가 언제 동기화할지 선택할 수 있게 하여, 간헐적으로 네트워크에 연결되는 엣지 환경에 적합함.
- 서버는 클라이언트의 마지막 스냅샷 이후 변경된 페이지의 인덱스를 제공하며, 클라이언트는 필요한 데이터만 선택적으로 가져올 수 있음.
부분 동기화: 필요한 것만 동기화
- 엣지 환경에서는 전체 데이터셋을 다운로드할 수 없으므로, Graft는 필요한 페이지만 선택적으로 가져오는 부분 동기화를 지원함.
- Graft는 일반적인 예측 알고리즘과 도메인 지식을 활용하여 필요한 페이지를 미리 가져올 수 있음.
엣지: 필요한 곳에 가까운 동기화
- Graft는 전 세계 엣지 서버를 통해 데이터를 제공하여, 사용자가 어디에 있든 낮은 대기 시간과 높은 응답성을 유지함.
- 클라이언트는 경량으로 설계되어 브라우저, 모바일 앱, 서버리스 환경에 쉽게 통합될 수 있음.
일관성: 안전한 동기화
- Graft는 강력한 일관성 모델을 제공하여, 클라이언트 간의 충돌을 안전하게 처리함.
- 클라이언트는 스냅샷 격리 모델을 통해 데이터의 일관된 뷰를 얻을 수 있으며, 쓰기는 엄격하게 직렬화됨.
Graft로 무엇을 만들 수 있을까?
- Graft는 다양한 엣지 네이티브 애플리케이션을 위한 강력한 기반을 제공함.
- 오프라인 우선 앱, 크로스 플랫폼 데이터, 상태 없는 읽기 복제본, 임의 데이터 복제 등이 가능함.
Graft SQLite 확장 (libgraft)
- libgraft는 SQLite의 네이티브 확장으로, 클라이언트가 실제로 사용하는 데이터베이스의 일부만 복제하여 리소스가 제한된 환경에서도 SQLite를 실행할 수 있게 함.
- 비동기 복제, 게으른 부분 복제, 스냅샷 격리, 시점 복원 등의 기능을 제공함.
참여 방법
- Graft는 GitHub에서 개발되고 있으며, 커뮤니티의 기여를 환영함.
- Discord에 참여하거나 이메일로 피드백을 제공할 수 있음.
- Graft 관리 서비스의 대기자 명단에 등록할 수 있음.
로드맵
- Graft는 아직 개발 중이며, WebAssembly 지원, SQLSync와의 통합, 다양한 클라이언트 라이브러리 지원 등의 계획이 있음.
- 쓰기 지연 시간 감소, 가비지 수집, 인증 및 권한 부여, 볼륨 포킹, 충돌 처리 등의 기능도 추가될 예정임.
다른 SQLite 복제 솔루션과의 비교
- Graft는 mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite, Verneuil 등과 비교하여 독특한 장점을 가짐.
- 부분 복제, 임의 데이터 구조 지원, 엣지에서의 효율적인 복제 등이 주요 차별점임.
Hacker News 의견
-
일관성 모델이 이해되지 않음
- Graft 클라이언트는 로컬에서 커밋하고 비동기적으로 원격 커밋을 시도함
- 두 클라이언트가 동일한 스냅샷을 기반으로 동시에 커밋하면 하나는 성공하고 다른 하나는 실패함
- API는 단일 커밋 작업만 제공함
- 로컬 커밋이 성공했을 때 비동기 전파가 실패하면 롤백해야 하는 문제 발생
- "커밋"의 개념이 여러 가지로 혼재되어 있음
-
Graft의 작성자가 감사 인사를 전함
- 워싱턴 DC에서 Antithesis BugBash에 참석 중임
- 워싱턴에 있는 사람들과 만나고 싶어함
-
일관성 모델이 git과 유사하다고 이해함
- 로컬 복사본을 변경하고 "푸시"할 때 충돌이 발생할 수 있음
- 충돌을 깨끗하게 감지할 방법이 없음
- 읽기 충돌로 인해 충돌이 발생할 수 있음
-
클라이언트가 Graft를 가져오면 변경된 내용을 정확히 알 수 있음
- Cloud-Backed SQLite의 매니페스트와 비교함
- 서버에서 계산이 필요하지 않음
-
구현 세부사항에 대해 언급하지 않음
- 앱 개발자가 동기화에 신경 쓰지 않아도 되는 동기화 레이어가 필요함
- 구독 없이 개인 동기화를 지원할 수 있음
-
VFS를 사용하는 것이 재미있는 "해킹"이라고 생각함
- 오프라인 우선 IDE를 위한 자체 동기화 엔진 개발 중임
- 트리 구조를 사용하여 충돌 해결이 도전 과제임
-
Leap 알고리즘을 사용한 프로젝트가 매우 흥미로움
- SQLite 통합에 집중하기 쉽지만, 더 일반적이고 낮은 수준의 분산 저장 문제로 접근함
- 구체적인 경험이 없는 일반적인 솔루션은 위험할 수 있음
-
모바일 클라이언트가 느린 연결에 있을 때 문제가 발생할 수 있음
- 느린 동기화를 감지하고 서버에 직접 쿼리를 보내는 하이브리드 접근법 제안
-
페이지를 기본 동기화 단위로 사용하는 접근법이 흥미로움
- 많은 동시 사용자와의 충돌이 발생할 수 있음
- OT나 CRDT가 더 나을 수 있음
-
매우 도전적인 문제임
- React Native 앱에서 시도해보고 싶음