Com o design de armazenamento somente para anexosÉ impossível corromper os dados e os arquivos de índice, pois as atualizações vão apenas até o final do arquivo. Não há atualizações de arquivos no local e os arquivos nunca ficam em um estado inconsistente. Mas a gravação em um arquivo em constante expansão acabará consumindo todo o seu espaço em disco. Portanto, o servidor Couchbase tem um processo chamado compactação. A compactação limpa o espaço em disco removendo dados obsoletos e valores de índice para que os arquivos de dados e de índice não consumam desnecessariamente o espaço em disco. Se o caso de uso do seu aplicativo for principalmente de leitura, talvez não haja problema, mas se você tiver cargas de trabalho de gravação pesada, talvez queira saber como a compactação automática funciona no Couchbase Server.
Por padrão, os documentos no Couchbase Server são particionados em vBuckets (ou partições). Há vários arquivos usados para armazenamento - um arquivo de dados por partição (os "arquivos de dados"), vários arquivos de índice (ativo, réplica e temporário) por documento de design e um arquivo mestre que tem metadados relacionados aos documentos de design e às definições de visualização. Por exemplo, no Mac OSX (conforme mostrado abaixo), o bucket de amostra "gamesim" tem
64 arquivos de dados individuaisum por partição (0.couch.1 a 63.couch.1) e um arquivo mestre que contém documentos de design e outros metadados de visualização (master.couch.1)
Dados e arquivo mestre do Couchbase
Os arquivos de índice estão na pasta @indexes e consistem no arquivo de índice ativo que começa com main_, no arquivo de índice de réplica (se a replicação de índice estiver ativada) que começa com replica_ e em um arquivo temporário que é usado durante a criação e a atualização do índice que começa com tmp_.
Arquivos de índice no Couchbase Server
Os arquivos de dados e de índice no Couchbase Server são organizados como árvores b. Os nós raiz (mostrados em vermelho) contêm ponteiros para os nós intermediários, que contêm ponteiros para os nós folha (mostrados em azul). No caso de arquivos de dados, os nós raiz e intermediários rastreiam os tamanhos dos documentos em sua subárvore. Os nós folha armazenam o ID do documento, os metadados do documento e os ponteiros para o conteúdo do documento. No caso de arquivos de índice, os nós raiz e intermediário rastreiam o resultado da função de mapa de saída e os valores de redução em sua subárvore.
Armazenamento em árvore B para arquivos de dados (mostrado à esquerda) e arquivos de índice (mostrado à direita)
Todas as mutações, inclusive inserções, atualizações e exclusões, são gravadas no final do arquivo, deixando os dados antigos no lugar. Adicionar um novo documento? A árvore B cresce no final. Excluir um documento? Isso é registrado no final da árvore B. Por exemplo, conforme mostrado na figura abaixo, o documento A sofre uma mutação, seguida de uma mutação no documento B e, em seguida, um novo documento D é adicionado, seguido de outra mutação no documento A. Os dados antigos são mostrados pelos nós vermelhos riscados na figura abaixo.
Layout de dados lógicos para arquivos de dados e de índice
Ao examinar o tamanho dos documentos rastreados pelo nó raiz na estrutura de arquivos da árvore B, é calculada a proporção entre o tamanho real e o tamanho atual do arquivo. Se essa proporção atingir um determinado limite configurável, conforme mostrado na Figura abaixo, um processo de compactação on-line será acionado. A compactação examina os arquivos de dados e de índice atuais e cria novos arquivos de dados e de índice, sem os itens marcados para limpeza. Durante a compactação, as árvores b são balanceadas e os valores de redução são recalculados para a nova árvore. Além disso, os dados que não pertencem a um nó específico também são limpos.
Finalmente, para acompanhar a carga de trabalho ativa que pode ter alterado o arquivo de dados da partição antiga durante a compactação, o Couchbase copia os dados que foram anexados desde o início do processo de compactação para o novo arquivo de dados da partição, para que ele fique atualizado. O novo arquivo de índice também é atualizado dessa maneira. Os dados da partição antiga e o arquivo de índice são excluídos e os novos arquivos de dados e índice são usados.
Normalmente, a compactação é uma operação do tipo tudo ou nada, mas como a compactação no Couchbase é feita por partição (vbucket)o conjunto de dados pode ser compactado de forma incremental sem perder as alterações feitas quando abortado.
Configuração dos limites de compactação na guia UI de configurações para arquivos de dados e de índice
A compactação no Couchbase Server é uma operação on-line. Por padrão, a compactação automática é ativada quando o limite de fragmentação atinge 30%, mas você deve testar quais configurações funcionam bem para sua carga de trabalho e ajustar essa configuração de acordo.
Porque a compactação é um recurso intensivo você também pode programá-la para horários fora de pico. Para evitar que a compactação automática ocorra quando o banco de dados estiver em uso intenso, você pode configurar um período fora do horário de pico durante o qual a compactação é permitida usando a interface do usuário mostrada acima. Por exemplo, aqui eu configurei a compactação para ser executada entre 12h e 1h, horário do servidor, todos os dias. Se a operação de compactação não for concluída nesse período de tempo, ela continuará, mas você pode marcar a caixa para que ela seja abortada.
A compactação também pode ser acionada manualmente por caçamba ou por documento de projeto, conforme mostrado nas figuras abaixo.
Compactação manual de um bucket de dados no Couchbase
Compactação manual de um documento de design no Couchbase
O desempenho da compactação no Couchbase Server depende da capacidade de E/S e da
dimensionamento adequado do cluster. Seu cluster deve ser dimensionado adequadamente para que haja capacidade suficiente em todas as várias áreas para dar suporte a tudo o que o sistema está fazendo para manter o nível de desempenho necessário.
Então, como você ajusta a compactação no Couchbase Server?Não há solução mágica aqui... Dependendo do requisito de IOPS do seu aplicativo, você precisa dimensionar seu cluster adequadamente e talvez queira testar sua carga de trabalho em uma variedade de hardwares de armazenamento diferentes. Se o seu aplicativo for pesado em termos de gravação, os SSDs podem ser a melhor opção, mas para taxas de leitura pesadas, o EBS pode ser uma boa solução a um custo baixo.
Por padrão, se os índices de dados e de exibições estiverem configurados para compactação automática, a compactação funcionará sequencialmente, primeiro no banco de dados e depois nas exibições. Ao ativar a compactação paralela, os bancos de dados e as exibições podem ser compactados ao mesmo tempo. Isso requer mais CPU e E/S de disco, mas se o banco de dados e os índices de visualização estiverem armazenados em diferentes dispositivos de disco físico (
como é nossa melhor prática de qualquer forma), os dois podem ser concluídos em paralelo para que os arquivos de índice e de dados não se tornem extremamente grandes.
Conclusão
No final das contas, todo banco de dados precisa de manutenção regular. A compactação on-line é uma grande vantagem, mas é preciso testar o sistema e definir as configurações de compactação adequadamente para que ela não afete a carga do sistema.
Bom artigo. Você poderia explicar um pouco melhor como funciona a compactação e o que é \"Limpeza de disco\" ou se é a mesma coisa? Estamos executando uma instalação \"write intensive\". Digamos que tenhamos 16 horas \"fora do pico\" por dia em que queremos executar o trabalho de compactação e, em seguida, interromper o processo de compactação. A compactação é feita em um vBucket por vez, e os vBuckets concluídos durante as 16 horas de compactação serão compactados e, durante a próxima manutenção, continuarão com os vBuckets que não foram compactados? Seria possível iniciar a compactação com os vBuckets mais fragmentados primeiro?
Oi, David,
Obrigado por ler este artigo e, sim, ótimas perguntas.
Q1: A compactação é feita em um vBucket de cada vez?
Sim. Ao fazer a compactação, processamos os vBuckets um a um.
P2: Os vBuckets concluídos durante a compactação de 16 horas serão compactados e, durante a próxima manutenção, continuarão com os vBuckets que não foram compactados?
Sim, depois que a compactação for reiniciada, ela retomará o último ponto de verificação onde parou e continuará o processo de compactação.
P3: Seria possível iniciar a compactação com os vBuckets mais fragmentados primeiro?
Os vbuckets são distribuídos aleatoriamente no cluster do couchbase e, no caso mais geral, tendem a acumular fragmentação aproximadamente na mesma taxa. Na pior das hipóteses, em que um ou mais vBuckets podem estar mais fragmentados, uma única passagem de compactação equilibrará o nível de fragmentação.
Espero que isso ajude!
-Don
Você poderia explicar melhor o que significa \"os índices de banco de dados e de exibição são armazenados em diferentes dispositivos de disco físico\"? Como isso pode ser configurado? Tentei criar um link simbólico para que os índices fossem mantidos em outro dispositivo, mas, no final do dia, a fragmentação das visualizações estava aumentando continuamente. Mesmo quando interrompi o tráfego de entrada, a pilha de fragmentação de visualizações estava em 80% (o limite de fragmentação é 30%).
Obrigado,
Kostas
[...] a compactação dos arquivos de disco deve ocorrer e isso exigirá uma certa quantidade de IO de disco adicional. Este blog pode ajudá-lo a entender a compactação [...]
[...] A compactação é um processo importante que é executado o tempo todo para recuperar espaço, dada a arquitetura somente de anexos do Couchbase. Ele também pode ser programado. Saiba mais sobre compactação aqui. [...]