Bluesky migra para SQLite de locatário único

• A Bluesky migrou para um datastore SQLite de locatário único.
• Agora, cada usuário tem seu próprio arquivo SQLite para armazenar seu repositório e o estado privado da conta.
• Os bancos de dados de usuários são armazenados de forma hierárquica.
• A chave de assinatura do repositório de cada repositório é armazenada junto com o arquivo SQLite.
• A abstração que interage com os dados do usuário foi alterada para ActorStore.
• O ActorStore tem classes diferentes para leitura e escrita.
• Como o SQLite não oferece suporte a transações simultâneas, o ActorStore exige um "transact" explícito para escrita.
• Um LRUCache para chaves de assinatura e bancos de dados é mantido, permitindo 30 mil file handles abertos e 30 mil chaves mantidas em memória.
• Quando um banco de dados sai do cache, o file handle é fechado.
• Três bancos de dados SQLite separados foram introduzidos para gerenciar o estado do serviço: um service DB para informações de conta, códigos de convite, refresh tokens etc.; um did cache DB para armazenar em cache a resolução de DID; e um sequencer DB para processar sequencialmente atualizações de repositório de todos os repositórios do serviço.
• Esses arquivos SQLite são executados em modo WAL para permitir leituras simultâneas e replicação por streaming.
• Espera-se que as implantações de PDS sejam distribuídas com Litestream ou algo semelhante.

[GN⁺]

Opiniões no Hacker News

• A migração do Bluesky para uma configuração SQLite de locatário único gerou discussão sobre os desafios e benefícios dessa abordagem.
• Alguns usuários expressam preocupação com possíveis problemas na migração de dados, nas versões de esquema e em futuras necessidades de agregação de dados.
• Outros questionam a afirmação de que o SQLite não oferece suporte a transações simultâneas, apontando que isso é possível sob certas condições.
• A estratégia de uma proporção 1:1 entre usuário e banco de dados parece interessante, e surgiram perguntas sobre como serão tratados os dados que precisarem ser agregados entre usuários.
• Também há interesse em como essa configuração lidará com atualizações no banco de dados de um usuário quando outros usuários publicarem novo conteúdo.
• Alguns usuários elogiam a adoção de SQLite/Litestream no servidor, citando isso como uma escolha econômica para bancos de dados por locatário.
• Foram levantadas perguntas sobre que tipos de dados são armazenados no SQLite e quais não são; alguns usuários presumem que mensagens entre usuários não são armazenadas nele.
• Há uma sugestão de que usar um hash MD5 para obter diretórios de destino de dois caracteres seria mais rápido do que um hash SHA256 e resolveria o mesmo problema.
• Alguns usuários veem essa migração como um movimento positivo e sugerem que seria possível simplesmente deixar o serviço baixando o arquivo SQLite e criando um front-end HTML apenas local.
• Há uma pergunta sobre se o Bluesky ainda funciona apenas por convite.