Temporizadores recursivos para agregação de documentos e menor TCO com o Couchbase Server 6.6

Onde isso começa...

IOT, dispositivos de borda e NoSQL são tecnologias que ganharam popularidade nos últimos anos. Permitem que as pessoas criem confortavelmente aplicativos pesados de interação, sem a preocupação com a estabilidade e a disponibilidade. Um problema com a liberdade e a flexibilidade dessas novas tecnologias é manter o custo. Agregar documentos e reduzir o espaço ocupado pelos dados é um caso de uso comum para aplicativos analíticos e de gravação pesada. O Couchbase 6.6 nos fornece ainda mais ferramentas para ajudá-lo a reduzir seu TCO. Vamos analisar onde o problema começou e como podemos usar o conjunto de ferramentas do Couchbase para resolvê-lo.

Aplicativos e interações

Lembro-me da época em que os aplicativos costumavam ser simples, quando se propunham a atingir um objetivo simples. Por exemplo, um aplicativo de varejo que permitisse que o processo de compras fosse disponibilizado digitalmente, evitando que as pessoas tivessem que se deslocar até o varejista local para realizar a mesma tarefa. Filmes e músicas sendo disponibilizados com o clique de um botão, em vez de ter que comprar CDs ou DVDs em uma loja de mídia. A transformação digital inicial de quase tudo foi um grande salto na conveniência do consumidor e devolveu mais tempo a todos, e por um tempo essa mudança foi suficiente para nos manter felizes. Quaisquer problemas técnicos pareciam menores porque eram ofuscados pela quantidade de conveniência que isso proporcionava.

No entanto, hoje em dia, um novo varejista que "se torna digital" não é motivo de alarde, pois essas expectativas já existem; o que os consumidores agora se preocupam é com as pequenas coisas que antes eram desconsideradas. Essas questões técnicas, que antes eram de menor importância, agora serão o "ponto de partida ou de chegada" de qualquer aplicativo bem-sucedido. À medida que a transformação digital se incorpora às atividades cotidianas das empresas, as expectativas em relação a esses aplicativos e sistemas aumentaram e continuarão a aumentar.

Bancos de dados

À medida que desenvolvemos software para atender a essa alta expectativa de experiência do usuário, proporcionamos mais interação entre o usuário final e o aplicativo. Aplicativos mais complexos vêm acompanhados de mais interações. Esse número cada vez maior de interações precisará de uma quantidade cada vez maior de armazenamento para registrá-las, e é nesse ponto que o nosso banco de dados se encaixa.

Assim como os próprios aplicativos, houve um tempo em que os bancos de dados relacionais eram perfeitos para armazenar as informações de praticamente todos os sistemas, e isso nos satisfazia. Entretanto, assim como as expectativas da experiência do usuário começaram a aumentar, o mesmo aconteceu com as expectativas do banco de dados subjacente. Agora estamos armazenando uma quantidade exponencial de dados com o passar do tempo e começamos a ver onde o banco de dados relacional tinha suas falhas. Mais dados significam mais armazenamento e, essencialmente, "mais banco de dados". Aqueles que estão familiarizados com bancos de dados relacionais sabem que isso não é tão simples quanto digitar ++. Para começar, fazer qualquer ajuste em um banco de dados relacional geralmente implicaria em tempo de inatividade, e esse tempo de inatividade no mundo de hoje não é mais aceitável. O escalonamento dos nós relacionais não é fácil de ser feito e, portanto, ficamos limitados ao escalonamento vertical, o problema é que o escalonamento vertical tornou-se caro e também tem suas próprias limitações. Também seria de se esperar um aumento linear do desempenho, considerando o aumento da capacidade de computação e do armazenamento dimensionado; no entanto, esse não é o caso. Além disso, a abordagem de esquema imposto significava que a arquitetura geral era rígida, o que dificultava qualquer alteração no conjunto de dados subjacente. De modo geral, o TCO dos sistemas relacionais era insustentável e, em um mundo em que a tecnologia está mudando cada vez mais rápido, é possível ver por que o banco de dados relacional precisava ser substituído para esses aplicativos altamente interativos.

A ideia das tecnologias NoSQL começou a surgir. O NoSQL incorporou uma abordagem distribuída, escalável e sem esquema para armazenar suas informações. Ele possibilitava dimensionar o banco de dados tanto para fora quanto para cima sem a necessidade de tempo de inatividade. Não havia restrições quanto ao conjunto de dados, o que permitia um desenvolvimento rápido e flexível. O TCO geral desses bancos de dados é muito menor e de fácil manutenção, o que é adequado para os aplicativos que exigem esse alto nível de interação.

Dispositivos IOT e de borda

Uma introdução importante no mundo do software foi o súbito boom da IOT e dos dispositivos de borda. Esses dispositivos normalmente consistem em uma combinação de hardware e software menores e podem atuar como pontos de entrada para a pilha de tecnologia subjacente. Um exemplo importante desses dispositivos é o uso de sensores e a capacidade de registrar continuamente dados que podem ser alimentados no banco de dados. Os bancos de dados NoSQL permitiram que esses dispositivos se multiplicassem e crescessem sem a preocupação com o dimensionamento, a rigidez e a alta disponibilidade, que um modelo relacional teria dificuldade em oferecer. Em muitos desses casos, o aplicativo abrangeria um alto nível de operações de gravação e as informações seriam analisadas em um estágio posterior.

Caso de uso

Agora, embora a capacidade de escalonar confortavelmente seja um suspiro de alívio para a maioria dos DBAs, rapidamente nos deparamos com um problema comum que todos estão tentando resolver: o aumento do custo. A flexibilidade e a liberdade de armazenar a maior quantidade possível de dados também têm suas desvantagens e, como resultado, o tamanho desses clusters pode ficar rapidamente fora de controle.

Se considerarmos uma equipe de corrida de Fórmula 1 durante uma corrida, por exemplo, ela poderia ter sensores embutidos no carro registrando estatísticas até o milésimo de segundo, poderia ter centenas ou até milhares desses sensores ao redor do carro durante cada corrida. Embora as leituras individuais sejam pequenas, o número total de documentos que estão sendo armazenados será da ordem de milhões, e eu estou sendo conservador! Quando tiverem todos esses dados, eles precisarão executar análises quase em tempo real. O resultado dessas análises permitirá que a equipe faça ajustes durante a corrida e melhore à medida que avança. O problema não surge em nenhum dos cenários acima, mas quando você observa o cluster que dá suporte a isso, pode ver como a quantidade de dados e o TCO desse banco de dados podem ficar rapidamente fora de controle. No entanto, para essa equipe de Fórmula 1, acontece que, depois de 15 minutos, a granularidade das leituras do sensor em milissegundos não é mais tão necessária e, em vez disso, eles ficam satisfeitos em armazenar médias por segundo; depois de uma hora, eles ficam satisfeitos em armazenar médias por minuto, e esse processo pode ser repetido quantas vezes for necessário.

Por exemplo, se analisarmos um conjunto de documentos que contém várias leituras de temperatura e pressão, poderemos obter um conjunto de documentos com a seguinte aparência

Para reduzir o conjunto de dados e compactar as informações que temos, podemos agregar os resultados em matrizes de documentos muito menores

O Couchbase introduziu o serviço de eventos na versão 5.5, que permite que os aplicativos atuem sobre os dados subjacentes no sistema, com lógica de programação JavaScript. Há uma ferramenta útil no eventing chamada timers que pode atrasar a execução da lógica. Para a equipe de Fórmula 1, eles poderiam utilizar esses temporizadores e chamar repetidamente as funções de eventos para agregar os documentos em um determinado período de tempo; no entanto, antes da versão 6.6, isso se tornou difícil de repetir. Muitos dos meus clientes utilizaram os cron jobs do Linux para agendar essas tarefas e permitir que as funções de eventos fossem executadas em intervalos regulares, acionando-as por meio de chamadas externas à API REST.

A versão 6.6 do Couchbase introduziu o cronômetro recursivo. Permitindo que os usuários criem temporizadores dentro da chamada de retorno de outro temporizador. No ponto de execução, a lógica agregaria os documentos dentro de um determinado período de tempo e, antes de sair, acionaria outro cronômetro para repetir o processo após um período de tempo.

Embora o recurso pareça trivial, ele simplifica muito o processo de recursão e elimina a necessidade de utilizar tecnologias externas para realizar algo que poderia ser feito internamente.

Portanto, talvez você não sinta a necessidade de agregação de documentos quando estiver começando a usar um banco de dados NoSQL. Para casos de uso pesado de gravação ou mesmo apenas quando o TCO geral começar a aumentar, você procurará todas as ideias e respostas que puder encontrar para ajudar a reduzir a quantidade de dados que está armazenando.