SQLite no disco permanente do Google Cloud

Question

O disco permanente do Google tem bloqueios apropriados de leitor / gravador para acesso simultâneo (muitas máquinas virtuais acessam dados de um único disco permanente) que é necessário para o SQLite?

De acordo com a FAQ do SQLite :

SQLite uses reader/writer locks to control access to the database. [...] But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.

Eu realmente gostaria de saber se o disco permanente do Google é bloqueado corretamente para gravações. Eu pesquiso o EFS da AWS e ele não tem um sistema de bloqueio adequado para suportar o SQLite.

    

Answer 1

Parece, pelos seus comentários, que o MySQL e o Google Cloud SQL não são uma opção, pois sua arquitetura exige o uso de um único arquivo SQLite.

Além disso, por documentos SQLite, o NFS não é uma opção devido aos problemas de bloqueio.

Aqui estão algumas outras opções a serem consideradas.

Sistema de arquivos distribuído alternativo

Além do NFS, há vários outros sistemas de arquivos distribuídos que você pode querer avaliar, como o Ceph , GlusterFS , OrangeFS , ZFS , etc. Além de sua própria pesquisa, considere entrar em contato com usuários ou desenvolvedores do SQLite para obter orientação e experiências passadas.

Use o NFS, mas imponha um único gravador por vez

O problema do NFS parece ser sobre bloqueio, que é necessário apenas para gravações: contanto que você possa garantir que apenas um processo tenha o banco de dados bloqueado para gravações de uma vez, vários outros processos podem abri-lo para leituras assim isso deve ser OK (por favor confirme / verifique se este é o caso).

Assim, enquanto houver um método externo para garantir um único gravador, você poderá usar o NFS. Considere o uso de um serviço de bloqueio distribuído, como Apache ZooKeeper , HashiCorp Consul ou CoreOS etcd para o serviço de bloqueio, e você pode armazenar seu SQLite no NFS.

Isso, é claro, depende de cada processo com acesso direto ao banco de dados SQLite para fechá-lo corretamente quando não precisar mais gravar nele, portanto, a correção é difícil de ser aplicada, pois depende de todos os softwares corretos e cooperativos .

Servidor RPC leve

Você mencionou que sua arquitetura (que não pode ser alterada neste momento) depende do SQLite, mas se é possível fazer com que eles chamem um serviço RPC em vez de abrir o arquivo diretamente, você pode ter esse servidor como o único ponto de abertura banco de dados SQLite e evitar o problema de bloqueio de vários usuários simultâneos. No entanto, isso significa que você teria que alterar todo o código do cliente para chamar o serviço RPC, em vez de abrir o banco de dados SQLite diretamente, o que é uma quantidade não trivial de trabalho.

Conclusão

Nenhuma dessas opções é trivial e exigirá trabalho. A razão é que :

In contrast to many other database management systems, SQLite is not a client–server database engine. Rather, it is embedded into the end program.

Como tal, não é a solução certa para vários acessores e, portanto, são necessárias várias soluções alternativas.

A longo prazo, se você estiver em uma situação em que teria que fazer alterações significativas para continuar a manter esse sistema, convém migrar para o MySQL ou o Google Cloud SQL em vez de investir em soluções alternativas para continue usando o SQLite.

    

Answer 2

Re: usando o SQLite para acesso múltiplo: as FAQs com as quais você fez o link dizem:

(5) Can multiple applications or multiple instances of the same application access a single database file at the same time?

Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.

, o que significa que você não deve usar o SQLite como um banco de dados de propósito geral, ele deve ser usado como um banco de dados incorporado para um único gravador, embora também possa suportar vários leitores.

Re: Discos persistentes: consulte minha resposta para uma pergunta relacionada no Stack Overflow; A história é que um disco permanente no Google Compute Engine pode ser montado:

• leitura e gravação em uma única instância
• somente leitura para várias instâncias

Assim, você não pode compartilhar o disco permanente no modo de leitura / gravação para várias VMs, como você está sugerindo. Se você quiser um banco de dados compartilhado, como yagmoth555 apontado nos comentários, você deve usar um banco de dados SQL, como o MySQL.

Convenientemente, o Google Cloud SQL fornece uma instância gerenciada do MySQL que você pode usar de várias VMs, pois fornece o bloqueio adequado bem como backups, failover, etc.