Bluesky chuyển sang SQLite đơn tenant

• Bluesky đã chuyển sang datastore SQLite đơn tenant.
• Giờ đây, mỗi người dùng có tệp SQLite riêng để lưu trữ kho dữ liệu và trạng thái tài khoản cá nhân của mình.
• Cơ sở dữ liệu người dùng được lưu trữ theo cấu trúc phân cấp.
• Khóa ký kho dữ liệu của mỗi kho được lưu cùng với tệp SQLite.
• Lớp trừu tượng tương tác với dữ liệu người dùng đã được chuyển sang ActorStore.
• ActorStore có các lớp khác nhau cho đọc và ghi.
• Vì SQLite không hỗ trợ các giao dịch đồng thời, ActorStore yêu cầu một "transact" rõ ràng cho thao tác ghi.
• Một LRUCache cho khóa ký và cơ sở dữ liệu được duy trì, cho phép 30k file handle đang mở và 30k khóa được giữ trong bộ nhớ.
• Khi cơ sở dữ liệu bị đẩy khỏi cache, file handle sẽ được đóng.
• Ba cơ sở dữ liệu SQLite riêng biệt đã được đưa vào để quản lý trạng thái dịch vụ: service DB cho thông tin tài khoản, mã mời, refresh token, v.v.; did cache DB để cache việc phân giải DID; và sequencer DB để xử lý tuần tự các cập nhật kho dữ liệu trên mọi kho của dịch vụ.
• Các tệp SQLite này chạy ở chế độ WAL để cho phép đọc đồng thời và sao chép theo luồng.
• Dự kiến việc triển khai PDS sẽ được phân phối kèm Litestream hoặc công cụ tương tự.

[GN⁺]

Ý kiến trên Hacker News

• Bluesky đã chuyển sang cấu hình SQLite đơn tenant, làm dấy lên thảo luận về những thách thức và lợi ích của cách tiếp cận này.
• Một số người dùng bày tỏ lo ngại về các vấn đề tiềm ẩn liên quan đến di chuyển dữ liệu, phiên bản schema và nhu cầu tổng hợp dữ liệu trong tương lai.
• Những người khác đặt câu hỏi về nhận định rằng SQLite không hỗ trợ giao dịch đồng thời, và chỉ ra rằng trong một số điều kiện nhất định thì có hỗ trợ.
• Chiến lược tỷ lệ 1:1 giữa người dùng và cơ sở dữ liệu trông khá thú vị, đồng thời cũng xuất hiện câu hỏi về việc dữ liệu cần tổng hợp giữa nhiều người dùng sẽ được xử lý như thế nào.
• Cũng có sự quan tâm đến việc trong thiết lập này, các bản cập nhật tới cơ sở dữ liệu của một người dùng sẽ được xử lý ra sao khi người dùng khác đăng nội dung mới.
• Một số người dùng khen ngợi việc áp dụng server SQLite/Litestream, xem đây là lựa chọn tiết kiệm chi phí cho cơ sở dữ liệu tenant.
• Đã có câu hỏi về những loại dữ liệu nào được lưu trong SQLite và những gì không được lưu, trong đó một số người dùng cho rằng tin nhắn giữa người dùng không được lưu trong SQLite.
• Có đề xuất rằng sử dụng băm MD5 để lấy thư mục đích gồm hai ký tự sẽ nhanh hơn so với băm SHA256 mà vẫn giải quyết cùng một vấn đề.
• Một số người dùng xem đây là bước đi tích cực và cho rằng có thể rời khỏi dịch vụ một cách đơn giản bằng cách tải xuống tệp SQLite và tạo frontend HTML chỉ chạy cục bộ.
• Có câu hỏi liệu Bluesky hiện vẫn chỉ dành cho người được mời hay không.