Mais rápida pequena armazenamento de dados no Windows

Question

Meu aplicativo mantém o controle do estado de cerca de 1000 objetos. Esses objetos são lidos e gravados para um armazenamento persistente (serializados) em nenhuma ordem particular.

Agora o aplicativo usa o registro para armazenar o estado de cada objeto. Isso é bom porque:

• É simples

• É muito rápido

• estado do objeto individual pode ser lido / escrito sem a necessidade de ler alguma entidade maior (como puxar um trecho de um grande arquivo XML)

• Há um editor decente (RegEdit) que permitem facilmente manipular itens individuais

Dito isto, eu estou querendo saber se existe uma maneira melhor. SQLite parece ser uma possibilidade, mas você não tem o mesmo nível de múltiplo-leitor / escritor de múltipla que você começa com o registro, e não há maneira simples de editar entradas existentes.

Qualquer sugestão melhor? Um grupo de arquivos simples?

Answer 1

Se você começar a experimentar com SQLite, você deve saber que "fora da caixa" pode não parecer tão rápido quanto você gostaria, mas que pode rapidamente ser feito para ser muito mais rápido através da aplicação de algumas dicas de otimização estabelecidos:

SQLite otimização

Dependendo do tamanho dos dados e a quantidade de memória RAM disponível, um dos melhores ganhos de desempenho ocorrerá através da criação sqlite para usar um banco de dados all-in-memory, em vez de gravar no disco.

Para bancos de dados em memória, passe NULL como o argumento filename para sqlite3_open e se certificar de que TEMP_STORE é definido apropriadamente

Por outro lado , se você contar sqlite para usar o disco rígido, então você vai ter um benefício semelhante ao seu uso atual do RegEdit para manipular dados do programa "on the fly".

A maneira como você pode simular a sua técnica RegEdit atual com sqlite seria usar a ferramenta de linha de comando SQLite para se conectar ao banco de dados no disco. Você pode executar instruções UPDATE sobre os dados SQL a partir da linha de comando, enquanto o seu principal do programa está em execução (e / ou enquanto ele está em pausa no modo de interrupção).

Answer 2

Se o que você quer dizer com 'multiple-reader / multiple-escritor' é que você mantenha um monte de tópicos de escrita para a loja ao mesmo tempo, SQLite é threadsafe (você pode ter SELECTs simultâneas e escritas concorrentes são tratados de forma transparente). Veja a [FAQ [1]] e grep para 'threadsafe'

[1]: http://www.sqlite.org/faq.html/ FAQ

Answer 3

Eu duvido que qualquer pessoa em sã consciência iria percorrer este caminho nos dias de hoje, no entanto algumas das coisas que você descreve poderia ser feito com da janela Estruturado / armazenamento Composto. Eu só mencionei isso desde que você está perguntando sobre Windows - e este é / era uma forma oficial do Windows para fazer isso

.

Esta é a forma como arquivos DOC foram colocados juntos (mas não o novo formato DOCX). De MSDN ele vai aparecer muito complicado, mas eu usei, não é a pior API em Win32.

• é não simples
• é rápido, eu palpite é mais rápido, então o registro.
• estado do objeto individual pode ser lido / escrito sem a necessidade de ler alguma entidade maior.
• Não existe um editor decente, no entanto, existem alguns reais coisas básicas (VC ++ 6.0 tinha o "DocFile Viewer" em Ferramentas (sim, isso é o que aquela coisa fez) Eu encontrei um alguns mais online.
• Você recebe um arquivo em vez de chaves de registro.
• Você ganha alguns old-school desenvolvedor do Windows geek-cred.

Outros pensamentos aleatórios: Eu acho que XML é o caminho a percorrer (apesar do problema de acesso aleatório). Heck, arquivos INI pode funcionar. O registro dá-lhe a segurança de grão muito fino se você precisar dele - as pessoas parecem esquecer isso quando a alegação de uso de arquivos são melhores. Um DB incorporado parece um exagero se eu estou entendendo o que você está fazendo.

Answer 4

Você precisa persistir os objetos em cada evento de alteração ou apenas na memória e armazenar no desligamento? Nesse caso, basta carregá-los e serializar-los no final, assumindo que seu aplicativo é executado por um longo tempo (e você não compartilhar esse estado com outro programa), então na memória vai ser um vencedor.

Se você tem fixo estruturas de tamanho, então você poderia considerar apenas usando um arquivo de memória mapeada e alocar memória do que?

Answer 5

Se a única coisa que você faz é serialize / deserialize objetos individuais (sem consultas elegantes), em seguida, usar um banco de dados btree, por exemplo Berkeley dB . É muito rápido no armazenamento e recuperação de blocos de dados pela chave (presumo seus objetos têm algum id que pode ser usado como uma chave) e acesso por múltiplos processos é suportado.