Simultaneidade BerkeleyDB

Question

• Qual é o nível ideal de simultaneidade que a implementação C++ do BerkeleyDB pode suportar razoavelmente?
• Quantos threads posso martelar no banco de dados antes que a taxa de transferência comece a sofrer devido à contenção de recursos?

Li o manual e sei como definir o número de bloqueios, armários, tamanho da página do banco de dados, etc.mas gostaria apenas de alguns conselhos de alguém que tenha experiência no mundo real com simultaneidade de BDB.

Minha aplicação é bem simples, farei entradas e colocações de registros com cerca de 1 KB cada.Sem cursores, sem exclusão.

Answer 1

Depende do tipo de aplicativo que você está construindo.Crie um cenário de teste representativo e comece a trabalhar.Então você saberá a resposta definitiva.

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

Sério, apenas teste seu próprio cenário.

Se você precisar de alguns números (isso pode não significar nada no seu cenário):

• Banco de dados Oracle Berkeley:Métricas de desempenho e benchmarks
• Métricas e benchmarks de desempenho:
  Banco de dados de Berkeley

Answer 2

Concordo plenamente com o argumento de Daan:crie um programa de teste e certifique-se de que a maneira como ele acessa os dados imite o mais próximo possível dos padrões que você espera que seu aplicativo tenha.Isto é extremamente importante com o BDB porque diferentes padrões de acesso geram taxas de transferência muito diferentes.

Fora isso, estes são fatores gerais que considero de grande impacto no rendimento:

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

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

3. O conjunto de trabalho cabe no cache?

4. Número de leituras vs.Escreve.

5. Quão espalhado é o seu acesso (lembre-se que o BTREE possui um bloqueio no nível da página - portanto, acessar páginas diferentes com threads diferentes é uma grande vantagem).

6. Padrão de acesso - significa qual a probabilidade de os threads bloquearem uns aos outros, ou até mesmo um impasse, e qual é a sua política de resolução de impasse (esta pode ser um assassino).

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

Isso equivale ao seguinte ponto:Dimensionar uma solução baseada em DBD para que ela ofereça maior simultaneidade tem duas maneiras principais de fazer isso;minimize o número de bloqueios em seu projeto ou adicione mais hardware.

Answer 3

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

Eu faria um teste simples e executaria com quantidades crescentes de fios martelando e veria o que parece melhor.

Answer 4

O que fiz ao trabalhar em um banco de dados de desempenho desconhecido foi medir o tempo de resposta em minhas consultas.Continuei aumentando a contagem de threads até que o tempo de resposta diminuísse e diminuindo a contagem de threads até que o tempo de resposta melhorasse (bem, eram processos em meu ambiente, mas tanto faz).

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

Ah, e outra coisa:evite mudanças de processo, se puder - agrupe as coisas.

---

Ah, devo deixar isso claro:tudo isso aconteceu em tempo de execução, não durante o desenvolvimento.

Answer 5

Do jeito que eu entendo as coisas, o Samba criou tdb para permitir "múltiplos escritoras" para qualquer arquivo de banco de dados específico.Portanto, se sua carga de trabalho tiver vários gravadores, seu desempenho poderá ser ruim (por exemplo, o projeto Samba optou por escrever seu próprio sistema, aparentemente porque não estava satisfeito com o desempenho do Berkeley DB neste caso).

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