Consulta eficiente de documentos excluídos com a função MISSING do N1QL

Quando você está criando um aplicativo, muitas vezes surge uma situação em que os usuários querem excluir algum conteúdo, mas você ainda precisa saber que os dados já existiram.

Digamos que você esteja criando um aplicativo de mensagens. Talvez queira dar aos seus usuários a chance de restaurar conversas excluídas.

Portanto, quando alguém quiser excluir uma conversa, você precisará fazer algo diferente de simplesmente excluir o documento do Couchbase. Em vez disso, você pode usar um sinalizador no corpo do JSON que identifique o documento como não ativo de alguma forma. Por exemplo:

Abaixo disso, você criaria um índice GSI para ter acesso eficiente a todas essas informações excluído conversas:

Em seguida, para preencher a exibição de conversas excluídas na interface do usuário do seu aplicativo, você executaria um Consulta N1QL tais como:

Até agora, tudo parece bastante óbvio.

Adicionar isso a um conjunto de dados existente

Agora, o que acontece se você estiver apenas introduzindo esse recurso no seu aplicativo? É provável que você já tenha muitos milhares de conversas cujos documentos subjacentes não tenham o recurso excluído bandeira.

Você pode pensar nisso como uma ótima oportunidade de usar a função ESTÁ FALTANDO. Você estaria certo, mas talvez esteja pensando de forma um pouco diferente do que vou sugerir.

Você coulc conta para documentos que não têm o excluído alterando sua consulta N1QL para algo como isto:

Para torná-lo um pouco mais realista, também podemos filtrar nossa consulta com base na pessoa envolvida:

Isso faria o trabalho, mas não seria a maneira mais eficiente de fazê-lo.

Quando introduzimos a palavra-chave MISSING do N1QL em uma situação OR, acionamos o N1QL em uma varredura completa do documento: nossa consulta está solicitando que o N1QL verifique cada documento quanto à presença da chave JSON excluída. Nosso índice ajuda apenas com os documentos em que excluído existe, porque ele não indexa documentos em que a chave não está presente.

Em vez disso, nesse caso, seria melhor executar uma consulta única que retornaria todos os documentos que estão faltando excluído. Poderíamos então trabalhar em cada uma delas e atualizá-las para incluir excluído = falso e, portanto, todos esses documentos estariam agora em nosso índice eficiente.

Se a consulta demorar um pouco mais, não há problema: estaríamos executando-a como parte de uma tarefa de limpeza de dados em segundo plano, de modo que nenhum dos nossos usuários saberia disso. Depois de executarmos essa tarefa em todos os documentos, não precisaremos mais de FALTANDO em nossa consulta voltada para o usuário, pois saberíamos que todos os nossos documentos de conversa seriam excluído: true ou excluído: falso.

Usando versões de esquema em vez disso

Poderíamos evitar o uso de MISSING mantendo o controle de versão do esquema:

Se imaginarmos que nossa nova versão do esquema, com o excluído fosse 2.0.0, nossa tarefa de zelador em segundo plano poderia procurar todos os documentos que tivessem uma versão de esquema anterior a 2.0.0 e, em seguida, executá-los por meio de um processo de atualização, parte do qual seria adicionar o sinalizador excluído bandeira.