Melhor maneira de usar um banco de dados PostGresql como uma loja simples de valor -chave

Question

Estou sendo obrigado a usar um banco de dados PostGresql e ele substituirá meu uso atual do BerkeLeyDB. Embora; Sei que essa não é uma situação ideal, está além do meu controle.

Portanto, a pergunta é ... se você fosse obrigado a transformar o PostgreSQL em um armazenamento de valores -chave, como você faria isso, tornando -o o mais eficiente possível?

Meus valores são matrizes de bytes e minhas chaves são strings, eu poderia impor algumas restrições aos comprimentos dessas cordas.

Suponho que eu deveria usar um blob para meu valor e coluna de chave primária segurando a chave, mas como estou apenas me aventurando nessa jornada, estou curioso para Eu deveria procurar.

Answer 1

A extensão no PostgreSQL para fazer isso corretamente é chamada hstore. Funciona de maneira semelhante, pois você esperaria outros sistemas de lojas de valor-chave. Basta carregar a extensão. A sintaxe é única, mas se você já usou o Redis ou o Mongo, o receberá rapidamente. Não torne mais difícil do que é. Entendo, geralmente não conseguimos escolher nossas ferramentas e precisamos fazer o assunto.
Aqui está a página do documento:

http://www.postgresql.org/docs/9.1/static/hstore.html

Answer 2

Se você for forçado a usar o banco de dados relacional, sugiro tentar encontrar a estrutura em seus dados para aproveitar o fato, já que você renuncia à vantagem da velocidade que obteve com dados não estruturados e armazenamento de valor-chave. Quanto mais estrutura você encontrar, melhor vantagem obtém da sua situação. Mesmo se você encontrar apenas estrutura nas teclas.

Considere também se você precisará apenas de acesso seqüencial ou aleatório aos seus dados e em qual índice e estruturar seu banco de dados por esse requisito. Você vai fazer consultas em seus valores por tipo, por exemplo? Cada uma dessas perguntas pode ter efeito sobre como você estrutura seu banco de dados.

Uma consideração específica sobre os blobs no PostgreSQL, eles são representados internamente como PG_LARGETABLE (LOID: OID, Pageno: Int4, Data: Bytea). O tamanho dos pedaços é definido pelo lobblksize, mas normalmente 2k. Portanto, se você puder usar matrizes de bytes em sua tabela em vez de blobs e tamanho limite do seu valor/par de teclas em Blocksize, poderá evitar essa indireção na segunda tabela. Você também pode aumentar o tamanho do bloco se tiver acesso à configuração do banco de dados.

Eu sugiro procurar estrutura em dados e padrões no acesso a dados e, em seguida, faça sua pergunta novamente com mais detalhes.

Answer 3

Realmente deve depender de qual será a chave. Se sempre for uma string com menos de 255 caracteres, use um Varchar como yoru pk e use um blob (assumindo um valor grande) para o valor. Se sempre for um número, use int, etc.

Em outras palavras, preciso de mais informações para realmente lhe dar uma boa resposta :)

Answer 4

O que você precisa armazenar como um valor? Cordas ? Ints? Objetos (por exemplo, objetos java serializados). Uma implementação simples funcionaria com uma tabela de 3 colunas parece:

NAME(VARCHAR)   TYPE(VARCHAR)   VALUE(VARCHAR)

(Talvez o tipo seja alguma enumeração). O exposto acima não funcionaria para dados binários, como objetos serializados, e talvez você precise de uma bolha lá.

Alternativamente (e provavelmente um Muito de melhor ideia), você viu Configuração do Apache Commons ? Você pode apoiar isso com um banco de dados (via JDBC) e pode armazenar propriedades para que você as recupere assim:

// get a property called 'number'
Double double = config.getDouble("number");
Integer integer = config.getInteger("number");

Isso pode economizar muita dor em termos de implementação. Você poderia Tenha um problema com a economia de dados binários, pois você precisaria serializar-os antes da inserção e pós-revieval. Mas eu usei isso no passado para armazenar INTs, duplas e objetos java serializados via Xstream, para que eu possa confirmar que funciona bem.