BerkeleyDB Concorrência

votos
25
  • Qual é o nível ótimo de concorrência que a implementação do C ++ de BerkeleyDB pode razoavelmente suportar?
  • Quantas linhas eu posso ter martelando o DB antes rendimento começa a sofrer por causa da contenção de recursos?

Eu li o manual e sabe como definir o número de bloqueios, armários, banco de dados de tamanho da página, etc. mas eu gostaria apenas de alguns conselhos de alguém que tem experiência no mundo real com BDB concorrência.

Meu aplicativo é bastante simples, eu vou estar fazendo recebe e coloca de registros que são cerca de 1 KB cada. Não cursores, sem exclusão.

Publicado 02/08/2008 em 00:28
fonte usuário
Em outras línguas...                            


5 respostas

votos
10

Depende de que tipo de aplicação que você está construindo. Criar um cenário de teste representativo, e começar a martelar afastado. Então você vai saber a resposta definitiva.

Além de seu caso de uso, ele também depende de CPU, memória, barramento frontal, sistema operacional, configurações de cache, etcetera.

Sério, só testar o seu próprio cenário.

Se você precisa de alguns números (que, na verdade, pode não significar nada em seu cenário):

Respondeu 03/08/2008 em 13:34
fonte usuário

votos
7

Concordo plenamente com o ponto de Daan: criar um programa de teste e certifique-se a maneira em que ele acessa imita dados, tanto quanto possível os padrões que você espera sua aplicação ter. Isso é extremamente importante com BDB porque diferentes padrões de acesso render rendimento muito diferente.

Fora isso, estes são fatores gerais I encontrados para ser de grande impacto sobre o rendimento:

  1. método de acesso (que no seu caso eu acho que é BTREE).

  2. Nível de persistência com que você configurou DBD (por exemplo, no meu caso bandeira ambiente do 'DB_TXN_WRITE_NOSYNC' melhorou o desempenho de gravação por uma ordem de magnitude, mas compromete a persistência)

  3. Será que o trabalho criado ajuste em cache?

  4. Número de Lê Vs. Escreve.

  5. Como espalhar o seu acesso é (lembre-se que BTREE tem um bloqueio de nível de página - para acessar páginas diferentes com diferentes tópicos é uma grande vantagem).

  6. padrão de acesso - meanig qual a probabilidade de tópicos para bloquear um ao outro, ou mesmo impasse, e qual é a sua política de resolução de impasse (este pode ser um assassino).

  7. Hardware (disco e memória para cache).

Isso equivale ao ponto seguinte: Scaling uma solução baseada em DBD para que ele oferece uma maior concorrência tem duas principais maneiras de ir sobre ele; quer minimizar o número de bloqueios em seu projeto ou adicionar mais hardware.

Respondeu 13/10/2008 em 22:59
fonte usuário

votos
4

Isso não depende do hardware, bem como número de threads e outras coisas?

Gostaria de fazer um teste simples e executá-lo com quantidades crescentes de tópicos martelando e ver o que parece melhor.

Respondeu 02/08/2008 em 19:21
fonte usuário

votos
2

A maneira como eu entendo as coisas, Samba criado TDB para permitir que "múltiplas simultâneas escritores " para qualquer arquivo de banco de dados específico. Então, se sua carga de trabalho tem vários escritores seu desempenho pode ser ruim (como, o projeto Samba escolheu para escrever o seu próprio sistema, aparentemente porque ele não estava feliz com o desempenho do Berkeley DB, neste caso).

Por outro lado, se sua carga de trabalho tem muitos leitores, então a questão é o quão bem o seu sistema operacional lida com vários leitores.

Respondeu 16/09/2008 em 18:31
fonte usuário

votos
1

O que eu fiz ao trabalhar contra um banco de dados de desempenho desconhecido foi medir o tempo de resposta em minhas consultas. Eu continuei aumentando a contagem da linha até que o tempo de rotação caiu, e soltando a contagem da linha até que o tempo de rotação melhorada (bem, era processos no meu ambiente, mas qualquer que seja).

Havia médias móveis e todos os tipos de métricas envolvidas, mas a lição take-away foi: apenas se adaptar à forma como as coisas estão funcionando no momento. Você nunca sabe quando os DBAs irá melhorar o desempenho ou hardware será atualizado, ou talvez outro processo virá junto para carregar para baixo o sistema enquanto você está correndo. Então, se adaptar.

Ah, e outra coisa: evitar processo de muda se você pode - lote coisas.


Oh, eu deveria deixar isso claro: tudo isso aconteceu no tempo de execução, e não durante o desenvolvimento.

Respondeu 04/08/2008 em 08:45
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more