GN⁺: Bluesky, 단일 테넌트 SQLite로 이전

• Bluesky는 단일 테넌트 SQLite 데이터스토어로 이전했습니다.
• 이제 각 사용자는 자신의 저장소와 개인 계정 상태를 저장하는 자신만의 SQLite 파일을 가지고 있습니다.
• 사용자 데이터베이스는 계층적으로 저장됩니다.
• 각 저장소의 저장소 서명 키는 SQLite 파일과 함께 저장됩니다.
• 사용자 데이터와 상호 작용하는 추상화가 ActorStore로 전환되었습니다.
• ActorStore는 읽기와 쓰기를 위한 다른 클래스를 가지고 있습니다.
• SQLite는 동시 트랜잭션을 지원하지 않으므로, ActorStore는 쓰기를 위해 명확한 "트랜잭트"를 필요로 합니다.
• 서명 키와 데이터베이스를 위한 LRUCache가 유지되며, 30k개의 열린 파일 핸들과 30k개의 메모리에 보관된 키를 허용합니다.
• 데이터베이스가 캐시에서 떨어지면, 파일 핸들이 닫힙니다.
• 서비스 상태를 관리하기 위해 세 개의 별도의 SQLite 데이터베이스가 도입되었습니다: 계정 정보, 초대 코드, 새로고침 토큰 등을 위한 서비스 DB, DID 해결을 캐싱하기 위한 did 캐시 DB, 그리고 서비스의 모든 저장소에서 저장소 업데이트를 순차적으로 처리하기 위한 sequencer DB.
• 이 SQLite 파일들은 동시 읽기와 스트리밍 복제를 허용하기 위해 WAL 모드에서 실행됩니다.
• PDS 배포는 Litestream 또는 유사한 것과 함께 배송될 것으로 예상됩니다.

[neo]

Hacker News 의견

• Bluesky가 단일 테넌트 SQLite 설정으로 이전하여 이 접근법의 도전과 이점에 대한 논의가 일어났습니다.
• 일부 사용자들은 데이터 이전과 스키마 버전에 대한 잠재적인 문제, 미래의 데이터 집계 필요성에 대해 우려를 표현합니다.
• 다른 이들은 SQLite가 동시 트랜잭션을 지원하지 않는다는 주장에 의문을 제기하며, 특정 조건 하에서는 지원한다고 지적합니다.
• 사용자 대 데이터베이스의 1:1 비율 전략이 흥미롭게 보이며, 사용자 간에 집계해야 할 데이터가 어떻게 처리될지에 대한 질문이 제기되었습니다.
• 이 설정이 다른 사용자가 새로운 콘텐츠를 게시할 때 사용자의 데이터베이스에 대한 업데이트를 어떻게 처리할지에 대한 관심도 있습니다.
• 일부 사용자들은 서버 SQLite/Litestream의 채택을 칭찬하며, 이를 테넌트 데이터베이스에 대한 비용 효율적인 선택으로 인용합니다.
• SQLite에 어떤 유형의 데이터가 저장되고 어떤 것이 저장되지 않는지에 대한 질문이 제기되었으며, 일부 사용자들은 사용자 간의 메시지가 SQLite에 저장되지 않는다고 가정합니다.
• MD5 해시를 사용하여 두 문자 대상 디렉토리를 얻는 것이 SHA256 해시 대신 더 빠르고 동일한 문제를 해결할 것이라는 제안이 있습니다.
• 일부 사용자들은 이 이전을 긍정적인 움직임으로 보며, SQLite 파일을 다운로드하고 로컬 전용 HTML 프론트 엔드를 생성함으로써 서비스를 간단히 떠날 수 있을 것이라고 제안합니다.
• Bluesky가 여전히 초대 전용인지에 대한 질문이 있습니다.