Cloud Backed SQLite (CBS)

• Sistema que armazena bancos de dados SQLite em armazenamento em nuvem e permite leitura e escrita sem precisar baixar o banco inteiro
  • Atualmente oferece suporte a Azure Blob Storage e Google Cloud Storage
• Usa o módulo Block Cache VFS: funciona nos modos sem daemon (leitura/escrita) e com daemon (somente leitura)

Resumo do GN⁺

• O sistema "Cloud Backed SQLite" (CBS) armazena o banco de dados em uma conta de armazenamento em nuvem e permite que clientes de armazenamento acessem os dados sem baixar todo o banco.
• Vários clientes podem acessar o banco de dados ao mesmo tempo, mas apenas um cliente pode gravar no banco.
• Atualmente, o CBS oferece suporte a Azure Blob Storage e Google Cloud Storage, e também pode dar suporte a outros sistemas de armazenamento em nuvem.
• O banco de dados SQLite é dividido em blocos de tamanho fixo e armazenado no sistema de armazenamento em nuvem.
• O sistema é composto por elementos básicos para gerenciamento de contêineres de armazenamento em nuvem, um processo daemon que fornece acesso local ao banco de dados remoto e um módulo VFS para acessar o banco de dados na nuvem.
• Para usar o CBS, a aplicação precisa compilar e linkar os arquivos C e arquivos de cabeçalho necessários, além de linkar com libcurl e openssl.
• O sistema pode ser testado com uma suíte de testes automatizada.
• O banco de dados pode ser enviado para a conta de armazenamento em nuvem usando ferramentas de linha de comando.
• Para acessar um banco armazenado na nuvem, é preciso criar o VFS, conectar o contêiner, abrir o handle do banco e executar scripts SQL.
• O sistema fornece APIs para suportar novos sistemas de armazenamento em nuvem e implementar tabelas virtuais.
• O artigo discute o uso de contêineres seguros em sistemas de armazenamento em nuvem.
• Os contêineres podem ser conectados de forma segura ou insegura, e a conexão segura usa criptografia AES OFB para criptografar os dados.
• O cliente local precisa de credenciais válidas de armazenamento em nuvem para obter a chave de criptografia do processo daemon.
• O artigo menciona os módulos embutidos azure e google para sistemas de armazenamento em nuvem.
• A API do CBS e as ferramentas de linha de comando exigem a especificação do módulo, nome de usuário e valor de autenticação.
• O artigo fornece detalhes do módulo azure e como gerar tokens SAS para autenticação.
• O módulo google exige ID do projeto e token de acesso para conectar o CBS ao Google Cloud Storage.
• O artigo menciona o acesso simultâneo por vários clientes e a necessidade de fazer polling no contêiner para verificar mudanças.
• O Blockcachevfs oferece suporte a três instruções PRAGMA: bcv_upload, bcv_poll e bcv_client.
• A interface de tabela virtual é composta pelas tabelas bcv_container e bcv_database.
• A tabela bcv_container contém informações sobre os contêineres conectados, e a tabela bcv_database contém informações sobre os bancos de dados de cada contêiner.
• O artigo discute a estrutura e a função de várias tabelas do banco de dados blockcachevfs.
• A tabela bcv_database contém informações sobre alterações locais feitas no banco de dados.
• A tabela bcv_http_log registra as requisições HTTP feitas pelo VFS ou pelo daemon conectado.
• A tabela bcv_kv permite que a aplicação grave dados no contêiner de armazenamento em nuvem.
• A tabela bcv_kv_meta fornece acesso somente leitura aos cabeçalhos HTTP do servidor de armazenamento em nuvem.
• O artigo também fornece referência de linha de comando para várias operações no banco de dados blockcachevfs.
• O comando do daemon permite que o processo blockcachevfsd seja executado como servidor e aceite conexões de clientes.
• O processo daemon oferece várias opções para configuração e logging.

[GN⁺]

Comentários do Hacker News

• Compartilhamento da experiência de um desenvolvedor ao servir um grande banco de dados SQLite em chunks e consultá-lo com requisições HTTP de intervalo
• Menção à biblioteca sql.js-httpvfs, que ajuda nesse processo
• O desenvolvedor dividiu um banco de dados SQLite de 350MB em pequenos pedaços e fez upload para o GitHub
• Recomenda conferir o projeto e testá-lo no console e na aba de rede
• Outro comentarista levanta preocupações sobre consistência de cache, concorrência, interrupções de rede e autenticação ao usar armazenamento remoto de dados
• Sugere uma solução mais simples: copiar periodicamente o banco de dados para um sistema de arquivos tmpfs e depois para um armazenamento de objetos
• Destaca vantagens como resolução do problema, cópia de arquivos barata e rápida, ausência de daemon externo, bloqueio global simples, segurança de thread, ausência de interrupções de rede e autenticação externa
• Outro comentarista questiona por que implantar o SQLite, um banco de dados embarcado, em um serviço de nuvem se o PostgreSQL já resolve o mesmo problema
• Argumenta que mover o armazenamento para a nuvem pioraria a latência e a simplicidade
• Outro comentarista pergunta se existe um comando equivalente ao pg_dump e ao mysqldump para SQLite
• O sistema atualmente oferece suporte a Azure Blob Storage e Google Cloud Storage, e menciona que a AWS pode ficar de fora
• Outro comentarista não tem certeza se esse recurso é oficialmente suportado ou se é apenas uma situação de "tecnicamente possível"
• Pergunta se é possível executar o Datasette sobre armazenamento externo em nuvem
• Outro comentarista levanta preocupações sobre garantir que apenas um cliente escreva no banco de dados por vez
• Menciona que a camada VFS do SQLite é flexível e fácil de usar para implementar armazenamento de objetos em nuvem
• Observa que o cache pode ser um aspecto complicado da implementação
• Outro comentarista diz ficar confuso com a ideia de usar SQLite na nuvem em vez de outro banco de dados relacional, já que o SQLite foi originalmente projetado para uso local.