Características de Tabelas BDB:

Para estar apto a fazer roolback da transação, o mecanismo de armazenamento BDB mantém arquivos de log. Para obter o máximo de desempenho você deve colocar estes arquivos em outro disco diferente do usado por seus bancos de dados usando a opção --bdb-logdir.

• O MariaDB realiza um ponto de verificação a cada vez que um novo arquivo de log do BDB é iniciado e remove qualquer arquivo de log que não for necessário para a transação atual. Pode se executar FLUSH LOGS a qualquer momento para faze um ponto de verificação de tabelas Berkeley DB.

  Para recuperação de desastres, deve-se usar backups de tabelas mais log binário do MariaDB. Leia "Backups dos Bancos de Dados".

  Aviso: Se você delatar arquivos de log antigos que estão em uso, o BDB não estará apto a fazer a recuperação e você pode perder dados se algo der errado.

• O MariaDB precisa de uma PRIMARY KEY em cada tabela BDB para poder fazer referência a linha lida anteriormente. Se você não criar um o MariaDB criará uma chave primária oculta para você. A chave oculta tem um tamanho de 5 bytes e é incrementada a cada tentaiva de inserção.
• Se todas as colunas que você acessa em uma tabela BDB são parte do mesmo índice ou parte de uma chave primária, então o MariaDB pode executar a consulta ser ter que acessar a linha atual. Em uma tabela MyISAM o descrito acima é guardado apenas se as colunas são parte do mesmo índice.
• A PRIMARY KEY será mais rápida que qualquer outra chave, já que a PRIMARY KEY é armazenada junto com o registro do dado. Como as outras chaves são armazenads como os dados da chave + a PRIMARY KEY, é importante manter a PRIMARY KEY o menor possível para economizar disco e conseguir maior velocidade.
• LOCK TABLES funciona em tabelas BDB como nas outras tabelas. Se você não utilizar LOCK TABLE, MariaDB comandará um bloqueio interno de múltipla-escrita nas tabelas para assegurar que a tabela será bloqueada apropriadamente se outra thread executar um bloqueio de tabela.
• Bloqueios internos em tabelas BDB é feito por página.
• SELECT COUNT(*) FROM nome_tabela é lento pois tabelas BDB não mantém um contador do número de linha na tabela.
• A varredura sequencial é mais lenta que com tabelas MyISAM já que os dados em tabelas BDB são armazenados em árvores-B e não em um arquivo de dados separado.
• A aplicação sempre deve estar preparada para tratar casos onde qualquer alteração de uma tabela BDB pode fazer um rollback automático e quqlquer leitura pode falhar com um erro de deadlock.
• As chaves não são compactadas por prefixo ou por sufixo como em tabelas MyISAM. Em outras palavras, a informação da chave gastará um pouco mais de espaço em tabelas BDB quando comparadas a tabelas MyISAM.
• Existem buracos frequentemente em tabelas BDB para permitir que você insira novas linhas no meio da árvore de chaves. Isto torna tabelas BDB um pouco maiores que tabelas MyISAM.
• O otimizador precisa conhecer aproximadamente o número de linhas na tabela. O MariaDB resolve isto contando inserções e mantendo isto em um segmento separado em cada tabela BDB. Se você não executar várias instruções DELETE ou ROLLBACK, este número deverá estar suficientemente próximo do exato para o otimizador do MariaDB, mas como o MariaDB só armazerna o número ao finalizar, ele pode estar incorreto se o MariaDB finalizar inesperadamente. Isto não deve ser fatail mesmo se este número não for 100% correto. POde se atualizar o número de linhas executando ANALYZE TABLE ou OPTIMIZE TABLE. Leia "Sintaxe de ANALYZE TABLE" . Leia "Sintaxe de OPTIMIZE TABLE".
• Se você ficar com o seu disco cheio com uma tabela BDB, você obterá um erro (provavelmente erro 28) e deve ser feito um rollback da transação. Isto está em contraste com as tabelas MyISAM e ISAM onde o mysqld irá esperar por espaço suficiente em disco pra continuar.

Retornar