O Couchbase Mobile usa uma técnica de controle de simultaneidade de várias versões (MVCC) para lidar com conflitos. Um dos desafios em um sistema baseado em MVCC é que, com o passar do tempo, um documento pode crescer e ter várias revisões. Pode-se concluir que, se todas as revisões dos documentos forem mantidas indefinidamente, o banco de dados poderá se tornar muito grande. Isso seria indesejável.
Esta é a segunda parte de nossa série sobre Resolução de conflitos no Couchbase Mobile. Em nossa primeira postagem sobre Desmistificando a resolução de conflitosNa postagem anterior, demos uma olhada nos bastidores de como as revisões e os conflitos de documentos são tratados no Couchbase Mobile usando o MVCC. Nesta postagem, discutiremos as técnicas usadas no Couchbase Mobile para gerenciar o tamanho das árvores de revisão de documentos e a função dos aplicativos nesse processo.
Histórico
A pilha do Couchbase Mobile inclui o Couchbase Lite banco de dados incorporado executado localmente em dispositivos e Gateway de sincronização na nuvem, que normalmente é apoiada por Servidor Couchbase mantendo os dados na nuvem. O Sync Gateway lida com a replicação de documentos entre os dispositivos. É concebível que um documento possa ser atualizado por vários dispositivos ao mesmo tempo.
Um documento no Couchbase Mobile é composto por um ID de documento, ID de revisão atual, corpo JSON e metadados. Os metadados, entre outras coisas, contêm o histórico de revisão do documento. Na versão de produção atual do Couchbase Mobile, os metadados são armazenados em uma propriedade _sync especial incorporada ao documento. Em V1.5 do Sync GatewaySe o documento não for alterado, os metadados serão transferidos para XATTRs.
Esta publicação pressupõe que você esteja familiarizado com a estrutura de árvore de revisão de documentos do Couchbase Mobile e com os conceitos de revisões atuais. Se você quiser saber mais, consulte a postagem sobre Desmistificando a resolução de conflitos.
Técnicas para gerenciar o tamanho do banco de dados
Para evitar que os documentos se tornem muito grandes, o Couchbase Mobile usa três técnicas, a saber,
- Compactação
- Poda
- Vencimento do documento
O Sync Gateway e o Couchbase Lite lidam com o processo de limpeza de forma ligeiramente diferente. Sempre que aplicável, as diferenças serão registradas na postagem.
Compactação
A compactação é definida como o processo de limpar os corpos JSON de não-folha revisões. As revisões de folhas não são eliminadas durante a compactação.
No Sync Gateway
No Sync Gateway, a compactação é executada pelo sistema periodicamente em segundo plano. Além disso, os aplicativos podem chamar manualmente o processo de compactação por meio do API compacta na interface de administração
No Couchbase Lite
No Couchbase Lite, a compactação só pode ser invocada manualmente por meio do comando Compact API No objeto CBLDatabase
Impacto da resolução de conflitos na compactação
O processo de compactação não remove os corpos JSON dos nós folha. Portanto, se você tiver um grande número de ramificações conflitantes não resolvidas, terá um grande número de nós folha com corpos JSON espalhados.
- Caso 1: quando os conflitos não são resolvidos, a compactação retém os corpos JSON de todos os nós folha.
- Caso 2: Quando os conflitos são resolvidos (ou seja, as ramificações não vencedoras são tombadas), a compactação remove os corpos JSON dos nós não folha
Portanto, a resolução de conflitos é importante para garantir que todas as revisões de folhas antigas e não utilizadas sejam eliminadas.
Poda
A poda é o processo que exclui os metadados e/ou os corpos JSON associados a arquivos antigos não-folha revisões. As revisões de folhas não são afetadas. O processo é executado automaticamente sempre que uma revisão é adicionada. Embora fundamentalmente o mesmo, o algoritmo de poda funciona de forma ligeiramente diferente entre o Sync Gateway e o Couchbase Lite.
No Sync Gateway
"Revisões antigas" são aquelas que são mais antigas do que o valor especificado pelo parâmetro revs_limit propriedade de configuração do banco de dados. A propriedade revs_limit tem como padrão 1000, o que significa que os metadados correspondentes às últimas 1000 revisões são armazenados no Sync Gateway. Embora o processo de poda não remova imediatamente os corpos JSON de revisões antigas, os corpos JSON de todas as revisões de documentos que não são folhas e que são mais antigas do que o valor TTL padrão de 5 minutos são automaticamente limpos por um processo em segundo plano que é executado periodicamente.
Algoritmo
- Encontre o número mínimo de geração gmin(o primeiro componente é um ID de revisão), de todas as revisões de folhas.
- Excluir todas as revisões não-folha cujo número de geração g ≤ gmin -
revs_limit
Poda de gateway de sincronização com conflitos : Um exemplo
Neste exemplo:
- Suponha que o
revs_limité definida como 2 (apenas para fins ilustrativos) - o documento tem revisões conflitantes não resolvidas na geração 3
No Couchbase Lite
"Revisões antigas" são aquelas que são mais antigas do que o valor especificado por maxRevTreeDepth do banco de dados. O valor maxRevTreeDepth tem como padrão 20, o que significa que os corpos de metadados e JSON correspondentes às últimas 20 revisões são mantidas no Couchbase Lite.
Basicamente, ao contrário do Sync Gateway, que faz um backup temporário (TTL de 5 minutos) dos corpos JSON de revisões antigas, o processo de poda no Couchbase Lite remove os metadados e os corpos JSON de revisões antigas que não são folhas.
Deve-se observar que pode haver pequenas diferenças na maneira como o algoritmo de poda é tratado nas várias plataformas do Couchbase Lite. Do ponto de vista do usuário, basta observar que a técnica de poda no Couchbase Lite eliminará os metadados e os corpos JSON de revisões antigas com base no maxRevTreeDepth valor.
Algoritmo
- Para cada ramo não tombstoned na árvore, remova as revisões cuja geração Id, g < (Depth Of Branch -
maxRevTreeDepth)
Após a poda, seu documento pode ficar com Filiais desconectadas. A árvore de revisão não está em um estado corrompido e a lógica que escolhe a revisão vencedora ainda se aplica. No entanto, isso pode impossibilitar a realização de determinadas mesclagens para resolver conflitos e deve ser evitado se isso for um problema para você.
Couchbase Lite Pruning with Conflicts : Um exemplo
Neste exemplo:
- Suponha que o
maxRevTreeDepthé definida como 2 (mais uma vez, você nunca vai querer fazer isso na prática) - o documento tem revisões conflitantes não resolvidas na geração 3
Impacto da resolução de conflitos na poda
- O processo de poda não remove as revisões das folhas. Portanto, se você tiver um grande número de ramificações conflitantes não resolvidas, terá um grande número de nós folha espalhados.
- No Gateway de sincronização, o algoritmo de poda é aplicado ao ramo mais curto e sem túmulos da árvore de revisão. Isso significa que, no caso de haver muitos ramos conflitantes não resolvidos, a poda pode não excluir algumas das revisões mais antigas,
- Cenário 1: Quando os conflitos não são resolvidos, a poda pode não remover todas as revisões antigas, pois o ramo mais curto pode ser um ramo conflitante
-
- Cenário 2: No entanto, no caso em que os conflitos são resolvidos, gmin corresponde ao nó folha do ramo da revisão vencedora.
- No Sync Gateway, no caso de conflitos não resolvidos, também é possível que os nós pai das revisões conflitantes sejam removidos prematuramente. Isso resultaria em um estado de ramo desconectado, conforme discutido anteriormente.
Vencimento do documento
Quando os documentos expiram, todos os rastros do documento, incluindo todas as revisões, são removidos do sistema. Os usuários têm a opção de controlar quando os documentos expiram. Observe que os usuários devem ter cuidado ao alterar o valor de expiração de um documento, pois um documento pode expirar prematuramente. Esse recurso é útil para criar documentos efêmeros que podem ser necessários apenas por um curto período.
No Sync Gateway
Ao gravar um documento no Sync Gateway via PUT doc ou bulk_docs API, os usuários podem definir o __exp no corpo do documento para especificar quando o documento deve expirar.
Os formatos compatíveis com o valor _exp incluem:
- Número JSON. TTL em segundos quando menor que 30 dias, hora unix quando maior
- Cadeia de caracteres JSON (formato numérico) - o mesmo que número JSON
- Cadeia de caracteres JSON (como data ISO-8601)
- JSON nulo. Define a expiração como zero (sem expiração)
No Couchbase Lite
O data de expiração no CBLDocument pode ser usada para especificar quando o documento deve expirar. Observe que, ao especificar uma expirationDate manualmente, você corre o risco de expirar os documentos adicionados ao Couchbase Lite no modo offline antes que eles tenham a chance de sincronizar com o Sync Gateway.
Configuração da profundidade máxima da árvore de revisão
Conforme discutido na seção sobre Poda, o maxRevTreeDepth no banco de dados Couchbase Lite tem como padrão 20 e a propriedade revs_limits no Sync Gateway tem como padrão 1000.
Esse valor afeta o número de revisões cujos metadados sobrevivem ao processo de poda. Portanto, ter um valor muito grande implica que o histórico de metadados do documento pode se tornar muito grande, resultando em maior necessidade de armazenamento no banco de dados.
Podemos nos sentir tentados a reduzir esses valores para economizar espaço. Mas torná-los muito pequenos pode ter consequências indesejáveis, conforme discutido abaixo
- O nó pai de ramificações conflitantes pode ser removido antes que o conflito possa ser resolvido, o que leva a nós de folha órfãos. Isso pode ser indesejável se o aplicativo desejar mesclar n-way as alterações simultâneas. Se você chegar a esse estado, a única opção para resolver o conflito é escolher um ramo vencedor e colocar no túmulo todos os ramos conflitantes não vencedores.
- Você pode acabar com filiais desconectadas conforme mostrado no exemplo abaixo. Os ramos desconectados são ramos que não têm um ancestral comum. Embora possa não ser um grande problema por si só, o aplicativo é responsável por registrar os ramos não vencedores.
No exemplo abaixo, após a sincronização, o dispositivo termina com duas ramificações desconectadas [16..19] e [35..38] sem um ancestral comum.
Observe que os cenários acima também podem ocorrer com os valores padrão da propriedade de profundidade da árvore. No entanto, a probabilidade de entrar nesse estado aumenta significativamente se os valores forem definidos como muito baixos.
O que vem a seguir
Uma consideração importante em um sistema baseado em MVCC é o gerenciamento do tamanho das árvores de revisão e a prevenção do inchaço. Esta publicação discutiu as técnicas disponíveis no Couchbase Mobile para controlar o tamanho dos documentos e o impacto das resoluções de conflitos no tamanho do banco de dados.
Se tiver dúvidas ou comentários, deixe um comentário abaixo ou sinta-se à vontade para entrar em contato comigo pelo Twitter @rajagp ou por e-mail priya.rajagopal@couchbase.com. O Fóruns do Couchbase são outro bom lugar para entrar em contato com perguntas.
Por fim, um agradecimento a Traun Leyden Traun@couchbase.com da equipe do gateway Sync por sua análise detalhada e a Jens Alfke jens@couchbase.com e Jim Borden jim.borden@couchbase.com da equipe do Couchbase Lite por sua contribuição.
