A validação de dados é um tópico interessante a ser abordado em uma tecnologia NoSQL, devido exclusivamente ao fato de que os princípios fundamentais do sistema giram em torno de uma arquitetura "sem esquema". Durante muitos anos, o SQL e os esquemas controlaram os dados dos aplicativos, garantindo a conformidade das informações dentro do banco de dados. Essas restrições impediram a modernização da maioria dos aplicativos, retardando o tempo de desenvolvimento.
Independentemente disso, você ainda precisa controlar e validar as informações contidas nos seus aplicativos. Com isso em mente, como podemos fazer isso com o Couchbase?
A flexibilidade de uma arquitetura sem esquema torna mais difícil impor a estrutura das informações provenientes de várias fontes, como a interação entre sensores e dispositivos de borda, em que o número de pontos de comunicação é grande. Há maneiras de conseguir validação de dados no próprio banco de dadosusando o serviço Eventing do Couchbase. O serviço, por si só, é extremamente avançado e flexível, dando ao administrador controle sobre as especificidades da validação nos documentos e as ações resultantes a serem tomadas.
A postagem do blog apresentará um exemplo de uso do serviço de eventos para validar as informações que estão em seu cluster. Como você verá, há muitas maneiras diferentes de criar isso, mas vamos nos concentrar em apenas uma para começar.
Fundamentos de NoSQL
No centro de qualquer banco de dados estão os dados - as informações reais que desejamos armazenar. Antes de adotar o NoSQL, inseríamos os dados em nosso sistema, mas eles tinham que aderir à estrutura definida pelos desenvolvedores ou pelos DBAs. Os DBAs gastavam tempo normalização as informações até a 6ª forma normal para reduzir a redundância de dados. Toda essa estrutura era comumente conhecida como esquema e era excelente para validar a integridade das informações, garantir a qualidade do sistema de registro e tornar-se uma fonte de verdade.
Apesar dos benefícios, a arquitetura baseada em esquema apresentou algumas desvantagens, principalmente quando os aplicativos começaram a operar em um nível mais alto e as empresas começaram a inovar mais rapidamente. A abordagem estruturada para armazenar dados começou a desacelerar o desenvolvimento, e as alterações de esquema se tornaram um incômodo.
Foi aí que a abordagem schema-lass começou a ter precedência, permitindo que os usuários armazenassem qualquer informação que desejassem e que a aceleração do desenvolvimento inovador florescesse.
SQL, mas NoSQL
Apesar da mudança para um banco de dados mais flexível e ágil, alguns atributos do modelo antigo são desejados com a nova abordagem; a validação de dados é um desses tópicos. O Couchbase fez mudanças consideráveis nas versões recentes para preencher a lacuna entre as tecnologias SQL e NoSQL.
Os escopos e as coleções eram lançado no Couchbase Server 7.0 e abriu as portas para uma maior organização lógica e casos de uso de multilocação. Isso nos permitiu mapear dados de esquema para sem esquema, mantendo as práticas de desenvolvimento flexíveis no núcleo.
Fornecimento de garantias ACID de um sistema distribuído foi outro grande passo, garantindo a semântica do tipo "tudo ou nada" em dados não relacionados para cargas de trabalho transacionais na versão 6.5.1.
Validação de dados é outro tópico que aparece junto com esses. Como avalio as informações em meu banco de dados quando não há um esquema que as imponha? Assim como os recursos anteriores que complementaram a abordagem de esquema, a capacidade de escolher se você tem isso ou não é benéfica. No entanto, não é necessário incorporar isso aos fundamentos do próprio aplicativo.
Com a proliferação da rede 5G e dos dispositivos móveis/de borda, é provável que a exigência de governança e gerenciamento de dados ainda exista. A utilização de ferramentas no arsenal do Couchbase pode fornecer um método fácil e totalmente controlado de aplicar essa validação sem afetar o desempenho dos nós do aplicativo ou do banco de dados.
Computação de borda com várias fontes de aplicativos
Antes de nos aprofundarmos nas formas divertidas de validação no servidor, vamos discutir a outra opção disponível. A validação no nível do aplicativo provavelmente será o primeiro pensamento que virá à mente. Se quisermos garantir que as informações sejam adequadas para armazenamento, por que não as verificamos antes de inserir os documentos no banco de dados? A aplicação da lógica do aplicativo nos dados antes da ingestão pelo sistema garantiria que nenhum documento chegaria perto do banco de dados, a menos que o sistema já o tivesse validado.
Teoricamente, essa parece ser uma boa ideia.... para um único aplicativo que se comunica com um único conjunto de dados. Entretanto, quando começamos a analisar o espaço dos aplicativos móveis, em que poderíamos estar falando com vários dispositivos de borda, todos falando com vários conjuntos de dados, em um único banco de dados, a capacidade de manutenção será prejudicada. Todas as equipes que escrevem no banco de dados precisariam manter e compartilhar a lógica de validação de forma consistente, e você começa a perder as garantias que existiam no cenário de um único aplicativo.
Serviço de eventos
Considerando os problemas de validação do aplicativo, precisamos de uma maneira de obter o mesmo resultado, mas em um ponto diferente; é aí que entra o serviço de eventos. Para aqueles que não o conhecem, o serviço de eventos permite que você atue em mutações de dados no banco de dados de forma programática. Essas ações são definidas em manipuladores de eventos JavaScript e são acionadas em qualquer atualização ou exclusão de dados.
| função Sobre a atualização(doc, meta) { log('docId', meta.id); } função OnDelete(meta, opções) { } |
Como o serviço de eventos pode executar essa lógica após a entrada dos dados no banco de dados, nada nos impede de incorporar a lógica do aplicativo a essas funções. Passaremos a responsabilidade ao serviço de eventos para verificar as informações sempre que elas forem inseridas ou modificadas.
Isso faz duas coisas:
- Elimina a duplicação da lógica de validação em vários aplicativos
- Centralizar a configuração e a capacidade de manutenção do que é considerado dados "válidos
Agora podemos usar o serviço de eventos para verificar os campos e valores do documento em um bucket, independentemente da origem dos dados. Mas ainda há uma consideração a ser feita: o que faremos com os documentos se decidirmos que eles são inválido? No nível do aplicativo, um documento inválido não passaria nas verificações e lançaria um erro ou uma exceção, que poderia ser tratada da maneira que fosse necessária.
Como as informações já estão no balde, precisamos sinalizar a validade do documento sem prejudicar a integridade dos dados. Cabe a você decidir como lidar com essa parte, mas, no meu exemplo, podemos manter um registro dos documentos inválidos em uma coleção separada e podemos remover o registro quando ele tiver sido limpo para um estado válido.
Implementação
Primeiro, precisamos criar uma função de eventos no conjunto de dados de destino. Para este exemplo, escolhi a função Usuários coleção. Também precisaremos especificar um local para armazenar os metadados de eventos (consulte a seção documentação de eventos aqui).
Por fim, precisarei definir um alias para o local dos dados inválidos, ao qual posso fazer referência; para isso, temos o Usuários_Inválidos coleção.
Uma vez que a estrutura tenha sido criada, precisamos criar algo que represente um válido documento. Dessa forma, podemos verificar todos os novos documentos com base nesse documento para garantir que as informações estejam corretas. Neste caso, criarei um documento que lista todos os campos obrigatórios e os tipos que eles devem conter. Se quiser, você pode correlacionar isso com o esquema que discutimos anteriormente, portanto, chamarei esse documento de Esquema_de_usuários.
| { "fields": [ { "name": "Nome", "tipo": "string" }, { "name": "Idade", "tipo": "número" }, { "name": "Assinante", "tipo": "booleano" } ] } |
A próxima coisa a ser criada é a lógica de validação. O Eventing executará a lógica sempre que houver uma mutação de documento na coleção de origem, Usuários. Ele verificará se o documento tem um documento de esquema relacionado associado. Em caso afirmativo, verifica todos os tipos de campos e valores e os compara com o documento que está sendo referenciado. Se algum dos campos não existir ou algum dos tipos não corresponder ao esperado, criaremos um registro no arquivo Usuários inválidos coleção.
Há uma condição na parte inferior do script que tenta excluir o registro se a lógica retornar um resultado válido. Ele é removido dos registros inválidos quando o documento é limpo ou corrigido para um estado válido.
| função Sobre a atualização(doc, meta) { log('docId', meta.id); var schema, valid, reason /Recolha o documento do esquema schema = inv[doc.type + '_schema'] motivo = ” válido = verdadeiro //Iterar pelos campos para(const campo de schema.fields) { /Verificar se o campo existe se (field.name em doc) { /Verificar se o tipo de campo está correto se (tipo de doc[field.name] == field.type) { válido = verdadeiro } mais { motivo = 'Incorrect Type for Field: ' + field.name + '. Esperado: ' + field.type + '. Real: ' + tipo de doc[field.name] válido = falso quebra } } mais { motivo = 'Campo: ' + field.name + ' não existe' válido = falso quebra } } se (valid == verdadeiro){ excluir inv[meta.id] } mais { var docContent = { "id": meta.id, "razão": motivo } inv[meta.id] = docContent } } |
Tudo o que há a fazer agora é testá-lo, inserir um Usuário com campos/tipos inválidos e verifique se um registro é criado no Usuários inválidos collection". Tente corrigir os documentos inválidos e verifique se o registro foi removido. Em geral, isso permite que você obtenha validação assíncrona de dados após o ponto de salvamento, em três etapas simples.
Indo além...
Como você deve ter percebido, esse é um exemplo muito simples, e não tenho dúvidas de que poderia ter escrito o JavaScript de forma mais eficiente. No entanto, ainda consegui validar todas as informações em um bucket em relação ao que poderíamos chamar de esquema, mantendo a integridade das informações e garantindo que não houvesse perda de dados no processo.
Essa abordagem era a que eu queria seguir, mas poderia ser modificada e ampliada de várias maneiras diferentes...
- Validação dos valores reais dos campos (por exemplo, a idade deve estar no intervalo de 1 a 100, etc.)
- Remoção total dos documentos da coleção
- Mover o documento inteiro para fora da coleção
- Envio de notificações via cURL para um serviço externo (resposta de e-mail, talvez?)
- Escrever lógica extra para corrigir de forma autônoma os dados inválidos com enriquecimento
Esta postagem do blog demonstrou algumas coisas:
- Validação assíncrona de dados após o ponto de salvamento
- O poder do serviço de eventos como um todo
Voltando aos pontos originais, a ponte entre as tecnologias SQL e NoSQL está se tornando cada vez mais comum, não como mudanças arquitetônicas, mas como ferramentas para alcançar o que antes era uma implementação fundamental.
