Eventing Simple Yet Powerful:
Eventos permite que pequenos scripts superem problemas difíceis de resolver.
Se você já conhece o Couchbase e o Eventing, fique à vontade para pular a breve visão geral e passar para a seção exemplos.
Visão geral:
Em primeiro lugar, vamos dar uma olhada no básico Ciclo de vida de eventos.
As etapas abaixo mostram como é fácil escrever e usar uma Eventing Function
- Adicionar (ou importar) uma Eventing Function por meio da interface do usuário do Couchbase Server.
- Atribua uma fonte de dados, um bucket de bloco de notas e algumas associações para manipular documentos ou se comunicar com o mundo externo.
- Implemente algum código JavaScript para processar a mutação recebida.
- Salve sua nova função e clique em "Deploy" (Implementar)
É isso, agora você tem uma função distribuída que responde a mutações em seu conjunto de dados em tempo real em todo o cluster.
O serviço Eventing oferece uma plataforma sem infraestrutura que pode escalonar suas Eventing Functions à medida que sua empresa cresce, seja um pico único ou um aumento mensal nos armazenamentos de dados ou nos clientes atendidos, sem se preocupar com o fato de que suas funções Eventing baseadas em JavaScript estão sendo executadas de forma distribuída paralela robusta e confiável. Para saber mais sobre o Couchbase Eventing, consulte a seção Visão geral de eventos em nossa documentação.
Os exemplos deste artigo mostram que, em alguns casos, o Eventing pode agir como uma gota de óleo para "liberar" as partes móveis de seus aplicativos.
O Couchbase é um banco de dados que você constrói sob encomenda:
Gosto de pensar em um cluster do Couchbase como um conjunto de "microsserviços" escalonáveis e interoperáveis. Esses serviços podem ser conectados e dimensionados para atender a um conjunto específico de necessidades operacionais e comerciais.
O Couchbase oferece escalonamento multidimensional, ou MDS, em seis serviços principais com interferência mínima de recursos entre eles. Além disso, cada serviço do Couchbase pode ser dimensionado de forma independente, bastando adicionar mais nós. Isso permite que os clientes criem o cluster ideal de vários nós com o menor TCO possível para a(s) tarefa(s) em questão.
- Os nós de dados são facilmente dimensionados para fornecer operações KV com reconhecimento de JSON em escala para pesquisas de registros únicos e múltiplos, o que é extremamente rápido. Eu acabei de mencionar que "para pesquisas de registros únicos e múltiplos, é extremamente rápido", sim, eu fiz, mas realmente quero enfatizar isso.
- Os nós de consulta são facilmente dimensionados para fornecer índices e também N1QL, um aprimoramento de SQL que funciona nativamente com documentos JSON, o que permite que os programadores comecem a trabalhar rapidamente sem precisar aprender uma nova maneira de pensar.
- Os nós de índice são facilmente dimensionados para fornecer índices flexíveis para acelerar algumas ou todas as consultas N1QL.
- Os nós de pesquisa são facilmente dimensionados para fornecer pesquisa de texto completo para consultas em linguagem natural, com: pesquisa com reconhecimento de idioma, pontuação de resultados e índices rápidos baseados em FTS,
- O nó Analytics é facilmente dimensionado para o recurso de gerenciamento de dados paralelos para executar com eficiência consultas complexas: grandes operações ad hoc de junção, conjunto, agregação e agrupamento em grandes conjuntos de dados.
- O serviço Eventing é facilmente dimensionado para fornecer um paradigma de computação que os desenvolvedores podem usar para lidar com alterações (ou mutações) de dados e reagir a elas em tempo real.
Como em todas as linhas de produtos, os serviços mais recentes do Couchbase Query, Search, Eventing e Analytics têm alguns defeitos, mas, no conjunto, a cesta completa oferece um pacote unificado ou um balcão único para resolver uma infinidade de problemas. Falando sério, se você não se importa com um produto unificado e tudo o que vai fazer é usar o FTS, talvez considere usar o Elasticsearch, mas quando precisar integrar os resultados do FTS com o N1QL (SQL para JSON), talvez tenha sido muito melhor começar com o Couchbase.
Hoje, utilizaremos apenas dois serviços: 1) o serviço KV principal fornecido pelos nós de dados; 2) o Eventing Service. Destacarei, por meio de algumas pequenas funções JavaScript, como você pode superar alguns problemas difíceis de escala aproveitando o Eventing Service.
Pré-requisitos / Aprendendo sobre Eventing:
Neste artigo, usaremos a versão mais recente do GA, ou seja, a versão 6.5.1 do Couchbase
No entanto, se você não estiver familiarizado com o Couchbase ou com o serviço Eventing, consulte o GET STARTED e um exemplo de Eventing, especificamente o seguinte:
- Configure um servidor Couchbase 6.5.1 funcional de acordo com as instruções em Comece aqui!
- Entenda como implantar uma função básica de Eventing de acordo com as instruções do Enriquecimento de dados exemplo, especificamente o "Caso 2", em que usaremos apenas um compartimento, o compartimento de "origem".
Enriquecimento de dados por meio de eventos:
Um problema típico do cliente
Um sistema de produção ativo armazenou bilhões de documentos. Surgiu uma nova necessidade comercial em que os dados existentes precisam ser enriquecidos. Essa necessidade de dados adicionais afeta o conjunto completo de documentos. O impacto operacional abrange dados antigos ou históricos e também dados novos ou mutantes. A empresa precisa manter o sistema de produção em funcionamento ininterrupto e responder continuamente a novos dados em tempo real.
Considere um aplicativo de exemplo um tanto forçado, um serviço de pesquisa GeoIP. Esse utilitário precisa de um conjunto de dados para permitir a pesquisa de países por intervalos de endereços IPV4. A implementação inicial armazenava registros da seguinte forma:
|
1 2 3 4 5 6 |
{ "tipo": "ip_country_map", "país": "RU", "ip_start": "7.12.60.1", "ip_end": "7.62.60.9" } |
Meses ou mais tarde, novos requisitos comerciais mudam. A engenharia precisava que os documentos JSON fossem enriquecidos com novos campos. O requisito era incluir as representações numéricas dos dois endereços IPV4 existentes.
|
1 2 3 4 5 6 7 8 |
{ "tipo": "ip_country_map", "país": "RU", "ip_end": "7.62.60.9", "ip_start": "7.12.60.1", "ip_num_start": 118242305, "ip_num_end": 121519113 } |
Eventing para o resgate
Uma simples função de evento de 14 linhas JavaScript (2 das quais são comentários) pode ser escrita e implementada para resolver o problema com o mínimo de recursos.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
função Sobre a atualização(doc, meta) { se (doc.tipo !== "ip_country_map" ) retorno; doc["ip_num_start"] = get_numip_first_3_octets(doc["ip_start"]); doc["ip_num_end"] = get_numip_first_3_octets(doc["ip_end"]); // src é um alias de bucket para o bucket de origem nas configurações, escreva de volta para ele src[meta.id]=doc; } função get_numip_first_3_octets(ip) { se (!ip) retorno 0; var peças = ip.dividir('.'); // Número IP = A x (256*256*256) + B x (256*256) + C x 256 + D retorno = (peças[0]*(256*256*256)) + (peças[1]*(256*256)) + (peças[2]*256) + parseInt(peças[3]); } |
Ao implantar a função acima com um "Limite de feed" definido como "Tudo", todos os documentos do tipo: "ip_country_map" são processados e enriquecidos.
A Eventing Function é deixada "implantada", reagindo a todas as novas inserções ou atualizações (ou mutações) em tempo real, enriquecendo novos itens e também atualizando itens existentes em alterações de "ip_start_num" ou "ip_end_num" para as representações "numéricas" adequadas.
Como os documentos são enriquecidos (os campos antigos ainda estão presentes), os aplicativos de produção existentes continuarão funcionando. Todos os dados novos ou alterados são atualizados em tempo real para o novo esquema. Os componentes do aplicativo GeoIP são desacoplados por meio dessa função de evento simples, de modo que podem ser atualizados um de cada vez.
Quando todos os componentes de produção tiverem sido atualizados, a Eventing Function poderá ser desimplantada e desativada.
Eliminação de dados obsoletos por meio de eventos:
Um problema típico do cliente
Um sistema de produção ativo armazenou mais de 7 bilhões de documentos. Todos os documentos têm uma expiração automática (ou TTL para tempo de vida). O ambiente de produção recebe constantemente novos dados e expira constantemente os dados antigos.
Foi cometido um erro operacional que resultou na criação de 2 bilhões de documentos sem validade.
O cliente não tinha os recursos (nem desejava pagar pelos recursos) para criar um índice grande para utilizar o N1QL para identificar, selecionar e eliminar os dados que não tinham um TTL ativo (diferente de zero) quando não fossem mais úteis.
Eventing para o resgate
Uma simples função de evento JavaScript de seis (6) linhas (2 das quais são comentários) foi implementada e resolveu o problema com o mínimo de recursos.
|
1 2 3 4 5 6 |
função Sobre a atualização(doc, meta) { se (meta.expiração !== 0) retorno; // excluir todos os itens que têm TTL ou expiração de 0 // src é um alias de bucket para o bucket de origem nas configurações, exclua dele. excluir src[meta.id]; } |
Ao implementar a função acima com um "Limite de alimentação" definido como "Tudo", todo o conjunto de documentos no bucket de origem foi digitalizado. Todos os documentos com um TTL diferente de zero (o que significa que eles não tinham expiração) foram ignorados. Somente os documentos correspondentes com um TTL maior que zero são excluídos.
Depois que o bucket de origem foi limpo, a Eventing Function não foi implantada, pois era usada como uma ferramenta administrativa.
Observe que poderíamos substituir o teste de expiração !== 0 em nosso JavaScript para filtrar os dados para qualquer finalidade necessária.
É muito fácil adivinhar o que estamos fazendo abaixo:
|
1 2 3 4 5 6 |
função Sobre a atualização(doc, meta) { se (!(doc.tipo === "cliente"&& doc.ativo === falso)) retorno // arquivar o cliente no bucket aias arc e remover do bucket alias src arco[meta.id] = doc; excluir src[meta.id]; } |
Na verdade, poderíamos facilmente atualizar o que foi dito acima para executar um arquivamento em cascata e excluir não apenas o cliente, mas qualquer outra informação relacionada, como pedidos, devoluções e endereços de entrega. Consulte o exemplo Cascade Delete na documentação de Eventing.
Remoção de dados confidenciais via Eventing:
Um problema típico do cliente
Uma empresa que executa o Couchbase no local em produção precisava compartilhar informações de perfil de clientes (150 milhões e em crescimento). Seu parceiro de negócios também está executando o Couchbase, mas em um provedor de nuvem, o AWS.
Dado um registro de perfil típico como o seguinte:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
{ "tipo": "master_profile", "first_name": "Peter", "last_name": "Chang", "id": 80927079070, "basic_profile": { "partner_id": 80980221, "serviços": [ { "música": verdadeiro }, { "rádio": verdadeiro }, { "vídeo": falso } ] }, "sensitive_profile": { "ssn": "111-11-1111", "credit_card" (cartão de crédito): { "número": "3333-333-3333-3333", "expira": "01/09", "ccv": "111" } }, "endereço": { "casa": { "rua": "4032 Kenwood Drive", "cidade": "Boston", "zip": "02102" }, "faturamento": { "rua": "541 Bronx Street", "cidade": "Boston", "zip": "02102" } }, "telefone": { "casa": "800-555-9201", "trabalho": "877-123-8811", "célula": "878-234-8171" }, "locale" (local): "en_US", "timezone": -7, "gênero": "M" } |
Eles não podiam simplesmente compartilhar todo o perfil, pois ele continha dados confidenciais sobre as preferências do usuário e os métodos de pagamento. Eles só precisavam compartilhar um subconjunto limitado, como o seguinte:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "tipo": "shared_profile" (perfil compartilhado), "first_name": "Peter", "id": 80927079070, "basic_profile": { "partner_id": 80980221, "serviços": [ { "música": verdadeiro }, { "rádio": verdadeiro }, { "vídeo": falso } ] }, "timezone": -7 } |
O cliente queria substituir a solução SPARK de uso intermediário, que exigia horas de falha para inicializar e fornecia apenas um processo em lote lento (horas para refletir as atualizações) e sincronizar as informações do perfil em tempo real.
Eventing para o resgate
Uma simples função de eventos de nove (9) linhas JavaScript (3 das quais são comentários) foi implementada e resolveu o problema com recursos mínimos.
|
1 2 3 4 5 6 7 8 9 |
função Sobre a atualização(doc, meta) { // processar somente os documentos de nosso perfil se (doc.tipo !== "master_profile") retorno; // aws_bkt é um alias de bucket para o bucket de destino a ser replicado para a AWS via // XCDR. Escreva o documento de perfil mínimo (não sensível) no bucket para o AWS. aws_bkt["shared_profile::"+doc.id] = { "tipo": "shared_profile" (perfil compartilhado), "first_name": doc.primeiro_nome, "id": doc.id, "basic_profile": doc.basic_profile, "timezone": doc.fuso horário }; } |
Ao implementar a função acima com um "Limite de alimentação" definido como "Tudo", todo o conjunto de documentos no bucket de origem foi digitalizado e todos os documentos do tipo: "master_profile" foram processados e apenas um subdocumento de cada perfil sem as informações confidenciais foi copiado para o bucket de destino compartilhado.
A Eventing Function é sempre implantada, reagindo a todas as alterações (ou mutações) de perfil de usuário em tempo real e encaminhando cada mutação para o bucket de destino do AWS.
Nesse caso de uso, uma sincronização final de balde para balde é realizada por meio do Couchbase XCDR em nenhum momento os dados confidenciais deixam o cluster local e nunca são transmitidos para o AWS.
Recursos
- Download: Download do Couchbase Server 6.5.1
Referências
- Documentação do Couchbase Eventing:
https://docs.couchbase.com/server/current/eventing/eventing-overview.html - Couchbase Server 6.5 O que há de novo:
https://docs.couchbase.com/server/6.5/introduction/whats-new.html - Blogs do Couchbase sobre eventos:
https://www.couchbase.com/blog/tag/eventing/
