buscando recomendações para *servidor* de banco de dados simples na memória (sem necessidade de persistência) [fechado]

Question

Deve suportar múltiplas conexões, preferencialmente via ODBC.Os clientes serão executados como processos separados na mesma máquina.Não há necessidade de persistência, pois os clientes cuidarão da persistência em outro lugar.Os clientes são escritos em C++, se for importante.

Os dados são bastante simples, são um conjunto de mapas bidirecionais não relacionados.O acesso é feito diretamente por um valor ou por um intervalo (between X and Y), sem atualizações.Na verdade, não precisamos de SQL aqui, portanto, soluções não-SQL também podem ser consideradas.

O aplicativo cliente é multiprocessado e pode ser executado em várias máquinas.Cada máquina deve ter uma cópia local desse banco de dados, que é atualizada no armazenamento central por seus clientes locais.

Várias edições:

1. a plataforma é Linux
2. O disco RAM não é uma opção por motivos de segurança - não queremos que qualquer pessoa com acesso à máquina possa visualizar os dados
3. os dados devem ser persistidos apenas na forma criptografada, portanto, a solução não deve persistir os dados ou permitir um filtro/plugin definido pelo usuário para persistência.

Answer 1

Só por causa da minha familiaridade, eu iria com o MySQL. Para usá -lo como um banco de dados de memória, use a memória como o tipo de tabela. O Redis é um banco de dados NOSQL na memória que provavelmente seria um ajuste perfeito para isso (ele é executado na memória, com a escrita de disco apenas para persistência que pode ser desativada).

Answer 2

Algum motivo específico para não usar o sqlite com um RAM DB aberto?

Answer 3

O disco RAM não é uma opção por razões de segurança - não queremos que ninguém com acesso à máquina possa ver os dados

Você não está com sorte. Qualquer pessoa com acesso à máquina pode visualizar os dados de/proc/$ pid/MEM de qualquer maneira.

Se você está falando de acesso não raiz, use o diretório/Método/TMP/$ com o CHMOD 700.

Answer 4

Aqui está um truque que você pode usar no Linux, chamado "Lazy unmount".

1. Monte um tmpfs em algum lugar
2. Inicie alguns processos para usá-lo, que chdir() nesse diretório.Você pode usar uma instância do mysql;mysql sempre faz um chdir para seu diretório de dados.
3. Depois que o processo for iniciado com sucesso, desmonte o tmpfs com a opção -l (preguiçoso).

Agora, o tmpfs ainda existe e continuará a existir enquanto o(s) processo(s) estiver(em) acessando-o(s), mas ele não pode mais ser acessado por processos não relacionados, pois não está mais presente em seu ponto de montagem.

Observe que isso de forma alguma impede o root de obter os dados no tmpfs, apenas torna tudo um pouco mais difícil.

Observe também que ele pode ser trocado, então você deve desabilitar a troca (ou usar a troca criptografada) se for absolutamente necessário que ela seja não persistente.

Answer 5

Tentar Boost.multiIndex. Não é uma escolha óbvia, mas é baseada em conceitos relacionais de banco de dados.

O conceito de múltipla indexação sobre a mesma coleção de elementos é emprestado da terminologia do banco de dados relacional e permite a especificação de estruturas de dados complexas no espírito de tabelas relacionais indexadas multiplicar, onde conjuntos e mapas simples não são suficientes. Uma ampla seleção de índices é fornecida, modelada após contêineres STL análogos como std :: set, std :: list e hashed conjuntos.

Answer 6

Use o mysql com datadir = um tmpfs que você montou para esse fim. Você precisará preparar algum script de inicialização que instale o banco de dados (usando mysql_install_db ou algo assim) no tempo de inicialização, é claro, pois você perderá todos os dados.

Answer 7

Memcached pode ser uma solução viável. É um armazenamento de valor-chave que pode ser definido para manter valores por um certo período de tempo, é escalável e é simples de configurar e começar a usar. Também é executado em todos os tipos de ambientes. Aqui está o site wiki para mais informações, especialmente porque a página principal não é quase útil.