Pergunta

Eu preciso de um rápido, chave confiável e eficiente para a memória - banco de dados de valor para o Linux. Minhas chaves são cerca de 128 bytes, e o tamanho máximo valor pode ser 128K ou 256K. O subsistema de banco de dados não deve usar mais de cerca de 1 MB de RAM. O tamanho total do banco de dados é 20G (!), Mas apenas uma pequena fração aleatória dos dados são acessados ??ao mesmo tempo. Se for necessário, eu posso mover alguns blobs de dados do banco de dados (para arquivos regulares), de modo que o tamanho fica até 2 GB máximo. O banco de dados deve sobreviver a uma falha no sistema sem qualquer perda de dados recentemente não modificados. Eu vou ter cerca de 100 vezes mais leituras do que escreve. É uma vantagem se pode utilizar um dispositivo de bloqueio (sem um sistema de arquivos) como armazenamento. Eu não preciso de funcionalidade de cliente-servidor, apenas uma biblioteca. Eu preciso ligações Python (mas eu posso implementá-los se eles não estão disponíveis).

Que soluções devo considerar, e qual deles você recomenda?

Os candidatos que conheço que poderia funcionar:

  • Tokyo Cabinet (ligações Python são pytc , ver também pytc exemplo de código , suporta hashes e árvores B +, arquivos de log de transações e muito mais, o tamanho da matriz balde é fixo no momento da criação do banco de dados; o escritor deve fechar o arquivo de dar aos outros uma chance; lotes de pequenas escreve com reabrir o arquivo para cada um deles são muito lentos; o servidor Tyrant pode ajudar com os lotes de pequenas escritas; comparação de velocidade entre Tóquio Gabinete, Tokyo Tyrant e Berkeley DB )
  • VSDB (mesmo seguro em NFS, sem bloqueio, o que sobre atualizações barreiras ?; são muito lento, mas não tão lento como em CDB; última versão em 2003)
  • BerkeleyDB (fornece a recuperação de falhas; fornece transações; o módulo Python bsddb fornece ligações)
  • TDB do Samba (com transações e ligações Python, alguns usuários experiente corrupção , às vezes mmap()s todo o arquivo, a operação repack às vezes dobra o tamanho do arquivo, produz falhas misteriosas Se a base de dados for maior do que 2G (mesmo em sistemas de 64-bit), a implementação do cluster ( CTDB ) também disponíveis ; arquivo cresce muito grande após muitas modificações; ficheiro torna-se muito lento depois de muita disputa de hash, sem built-in maneira de reconstruir o arquivo; atualizações muito rápido paralelas, bloqueando baldes de hash individuais)
  • aodbm (append-only para que sobrevive a uma falha do sistema, com vínculos Python)
  • hamsterdb (com vínculos Python)
  • C-árvore (amadurecer, versátil solução comercial com alto desempenho, tem um edição gratuita com funcionalidade reduzida)
  • TDB (de 2001)
  • bitcask (escrito em Erlang estruturado em log)
  • várias outras implementações DBM (como GDBM, NDBM, QDBM ,, SDBM do Perl ou Ruby, provavelmente eles não têm a recuperação de falhas adequada)

Eu não vou usar estes:

  • MemcacheDB (cliente-servidor, utiliza BereleleyDB como um backend)
  • cdb (necessita regenerar toda a base de dados sobre cada write)
  • http://www.wildsparx.com/apbcdb/ (idem)
  • Redis (mantém todo o banco de dados na memória)
  • SQLite (torna-se muito lento, sem aspiração periódica, ver autocompletar na na barra de localização no Firefox 3.0, embora versões 3.1 e posterior do sqlite permitem auto_vacuuming; Cuidado: pequenas transações de escrita pode ser muito lento, cuidado: se um processo ocupado está fazendo muitas transações, outros processos fome, e eles nunca pode obter o bloqueio)
  • MongoDB (demasiado pesada-peso, os valores trata como objectos com estrutura interna)
  • Firebird (baseado em SQL RDBMS, muito pesado de peso )

FYI, uma recente artigo sobre a chave - bancos de dados de valor na revista Linux.

FYI, uma lista de software mais antigo

FYI, uma comparação velocidade da MemcacheDB, Redis e Tóquio Gabinete Tyrant

perguntas relacionadas sobre StackOverflow:

Foi útil?

Solução

Eu tive sorte com a solução Tokyo Cabinet / pytc. É muito rápido (um pouco mais rápido do que usar o módulo de prateleira usando anydbm na minha implementação), tanto para ler e escrever (embora eu também fazer muito mais lendo). O problema para mim foi a documentação espartano sobre os vínculos python, mas não há o suficiente código de exemplo ao redor para descobrir como fazer o que você precisa fazer. Além disso, Tóquio gabinete é bastante fácil de instalar (como são os vínculos python), não necessita de um servidor (como você menciona) e parece ser activamente apoiada (estável, mas não está mais em desenvolvimento ativo) . Você pode abrir arquivos em modo de somente leitura, permitindo o acesso simultâneo, ou ler / modo de escrita, impedindo que outros processos de acessar o banco de dados.

Eu estava olhando para várias opções durante o verão, e o conselho que eu tenho, em seguida, foi esta: experimentar as diferentes opções e ver o que funciona melhor para você. Seria bom se houvesse simplesmente uma "melhor" opção, mas todo mundo está procurando características ligeiramente diferentes e estão dispostos a fazer diferentes trade-offs. Você sabe melhor.

(Dito isto, seria útil para os outros, se você compartilhou o que acabou trabalhando o melhor para você, e por que você escolheu essa solução sobre os outros!)

Outras dicas

LMDB é a volta banco de dados mais eficiente para a memória http://symas.com/mdb/inmem/

e também provou ser o mais confiável - acidente-prova completamente. http://wisdom.cs.wisc.edu/workshops/spring -14 / palestras / Thanu.pdf

Dos que você mencionou, Tokyo Cabinet documentou problemas de corrupção https://www.google.com/search?q=cfengine+tokyo + gabinete + corrupção

BerkeleyDB também tem problemas de corrupção bem documentados, assim como Bitcask. (E bitcask é um in-memory-only DB de qualquer maneira, tão inútil para a sua exigência 1MB de RAM.)

LMDB também é bem suportado em Python, com um par de ligações diferentes disponíveis. https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

Disclaimer - Eu sou o autor de LMDB. Mas estes são fatos documentados:. LMDB é o menor, mais eficiente e armazenamento de chaves / valor fiável maioria no mundo e nada mais vem em qualquer lugar perto

cdb pode lidar com qualquer banco de dados de até 4 GB, tornando-se demasiado pequeno para a matéria de 20GB na mão.

Riak roda em Linux, e permite que você dinamicamente adicionar nós

como sobre dbm.ndbm Python 3.0 do?

Outra sugestão é TDB (a parte do projeto Samba). Eu usei-o através do tdb módulo, no entanto eu não posso dizer que' ve testada a sua fiabilidade em falhas; os projectos que eu usei-o em não ter tais requisitos, e eu não posso encontrar a documentação relevante.

Como cerca de um SQLite?

Eu usei bsddb.hashlib () com Python, ele funcionou muito bem.

Você pode gostar djb 's cdb , que tem as propriedades que você menciona.

Na minha consulta para uma multi-plataforma de banco de dados de estilo ISAM (similar), I também recebeu sugestões para a versão integrada do Firebird e GLib .

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top