Bluesky bermigrasi ke SQLite single-tenant

• Bluesky telah bermigrasi ke datastore SQLite single-tenant.
• Kini setiap pengguna memiliki file SQLite mereka sendiri untuk menyimpan repositori dan status akun pribadi mereka.
• Basis data pengguna disimpan secara hierarkis.
• Kunci penandatanganan repositori untuk setiap repositori disimpan bersama file SQLite.
• Abstraksi yang berinteraksi dengan data pengguna telah dialihkan ke ActorStore.
• ActorStore memiliki kelas yang berbeda untuk pembacaan dan penulisan.
• Karena SQLite tidak mendukung transaksi bersamaan, ActorStore memerlukan "transact" yang eksplisit untuk penulisan.
• LRUCache untuk kunci penandatanganan dan basis data dipertahankan, memungkinkan 30 ribu file handle terbuka dan 30 ribu kunci disimpan di memori.
• Ketika basis data keluar dari cache, file handle akan ditutup.
• Tiga basis data SQLite terpisah diperkenalkan untuk mengelola status layanan: service DB untuk informasi akun, kode undangan, refresh token, dan lainnya; did cache DB untuk melakukan cache pada penyelesaian DID; serta sequencer DB untuk memproses pembaruan repositori secara berurutan dari semua repositori dalam layanan.
• File-file SQLite ini dijalankan dalam mode WAL agar memungkinkan pembacaan bersamaan dan replikasi streaming.
• Distribusi PDS diperkirakan akan dikirim bersama Litestream atau yang serupa.

[GN⁺]

Opini Hacker News

• Bluesky bermigrasi ke konfigurasi SQLite single-tenant, yang memicu diskusi tentang tantangan dan manfaat dari pendekatan ini.
• Sebagian pengguna menyampaikan kekhawatiran tentang potensi masalah migrasi data dan versi skema, serta kebutuhan agregasi data di masa depan.
• Yang lain meragukan klaim bahwa SQLite tidak mendukung transaksi serentak, dan menunjukkan bahwa dalam kondisi tertentu hal itu didukung.
• Strategi rasio 1:1 antara pengguna dan basis data terlihat menarik, dan muncul pertanyaan tentang bagaimana data yang perlu diagregasi antar pengguna akan ditangani.
• Ada juga ketertarikan pada bagaimana pengaturan ini akan menangani pembaruan ke basis data pengguna ketika pengguna lain memposting konten baru.
• Sebagian pengguna memuji adopsi server SQLite/Litestream, menyebutnya sebagai pilihan yang hemat biaya untuk basis data tenant.
• Muncul pertanyaan tentang jenis data apa yang disimpan di SQLite dan apa yang tidak, dan sebagian pengguna berasumsi bahwa pesan antar pengguna tidak disimpan di SQLite.
• Ada usulan bahwa menggunakan hash MD5 untuk mendapatkan direktori tujuan dua karakter akan lebih cepat daripada hash SHA256 dan menyelesaikan masalah yang sama.
• Sebagian pengguna melihat migrasi ini sebagai langkah positif, dan mengusulkan bahwa orang bisa meninggalkan layanan ini dengan mudah hanya dengan mengunduh file SQLite dan membuat front-end HTML lokal saja.
• Ada pertanyaan apakah Bluesky masih bersifat khusus undangan.