Lentiq e Couchbase

Alex Sirbu Líder da equipe de P&D da Lentiq, tem sete anos de experiência em arquitetura e construção de sistemas distribuídos confiáveis.

Lentiq é uma startup de data lake como serviço baseada em Kubernetes e com várias nuvens, o que significa que gerenciamos diariamente os dados e fluxos de trabalho de outras pessoas para ganhar a vida. Para fazer isso corretamente, precisamos de um banco de dados rápido, confiável e dimensionável para armazenar todas as nossas informações internas e que também nos permita implementar uma arquitetura orientada a microsserviços. O Couchbase provou repetidamente que atende a todos os nossos requisitos e tem sido o banco de dados escolhido desde o início do nosso projeto. Portanto, a seguir apresentamos nosso histórico de integração e uso do Couchbase como a única camada de armazenamento interno persistente na Lentiq.

Escolha

Por que escolhemos o Couchbase em primeiro lugar? A resposta a essa pergunta vem de nossa experiência anterior com ele. Nossa equipe mudou do projeto de nuvem bare metal na Grande passo nossa empresa controladora, para o novo projeto Lentiq. Alguns de nossos colegas trabalharam no produto Couchbase usado pela Bigstep, fazendo testes de desempenho (que mostraram como ele funcionava bem), além de usá-lo em algum momento como cache em frente a um banco de dados relacional mais lento. Essa experiência anterior com o Couchbase se mostrou valiosa quando tivemos que escolher nossa camada de armazenamento interno para o Lentiq.

Um fator importante em nossa seleção foi a arquitetura do novo produto. Ao dividir o aplicativo em vários microsserviços desacoplados, precisávamos aplicar o mesmo princípio de desacoplamento à camada de banco de dados. Isso reforçaria ainda mais a separação de preocupações entre os módulos, além do fato de que a única maneira de os microsserviços obterem informações de outros serviços seria por meio de interfaces expostas - não seria permitido contornar o banco de dados. Também precisávamos agir rapidamente e fazer experimentos, sem ter que lidar com esquemas rígidos, por isso decidimos seguir o caminho do NoSQL para esse projeto. E, por último, mas não menos importante, como o projeto deveria ser escrito em Java e Spring, o suporte para uma interface fácil com o banco de dados era outro fator essencial.

Assim, levando em consideração todos os requisitos e também vendo como o nosso velho amigo Couchbase atendia a todos os requisitos, decidimos usar o Couchbase para o nosso MVP - e não mudamos de ideia desde então!

Arquitetura

Os dois últimos requisitos são bastante diretos, mas como usamos o Couchbase para atingir o primeiro requisito - uma arquitetura baseada em microsserviços?

A solução óbvia foi alocar um bucket por microsserviço, dando a cada um deles um usuário separado que só pode acessar seu bucket específico, com as credenciais de acesso ao cluster fornecidas a cada serviço na inicialização. Fácil, não é? Com o uso de módulos desacoplados, conseguimos (principalmente) ter apenas um tipo de objeto com o qual cada microsserviço trabalha de perto. Esse objeto específico tem campos públicos (externos, acessíveis por microsserviços externos) e internos. Todos os campos são salvos dentro do bucket, mas o objeto é limpo e exposto somente com seus campos públicos por meio das interfaces externas de seu proprietário.

Nossa alocação também ajudou no dimensionamento e na confiabilidade. Como tínhamos poucos microsserviços no início, colocamos todos os buckets no mesmo cluster do Couchbase. À medida que adicionávamos mais e mais, nós os agrupávamos com base no tráfego e no tamanho dos objetos e os dividíamos em vários clusters, isolando-os ainda mais e permitindo o dimensionamento independente.

Consultas

Ao usar o Biblioteca Couchbase de dados do Spring , conectar-se ao Couchbase e usá-lo de fato para ler e gravar dados torna-se fácil.

As operações comuns de leitura e gravação são fornecidas por CouchbaseRepositories e CouchbaseTemplates (insert, update, delete, findById). O que nos ajuda muito é a maneira pela qual essas operações básicas podem ser expandidas. Por exemplo, a consulta de todos os ambientes de projeto dentro do minilago de dados que chamamos de data pool é feita simplesmente com a seguinte classe de repositório:

Para fazer consultas mais complexas (por exemplo, pesquisar um valor dentro de uma matriz), use o Linguagem de consulta N1Q1 é tão fácil quanto adicionar uma anotação para a função em questão. O exemplo a seguir retorna todos os conjuntos de dados com um determinado status e identifica quais contêm a visibilidade necessária em sua matriz de visibilidade:

O campo n1q1.filter é preenchido automaticamente com "_class=**SpecifiedClassForRepository**" para retornar somente o tipo de objeto solicitado, permitindo que vários tipos de objetos sejam armazenados dentro do mesmo bucket, sem a necessidade de fazer nada especial.

Travamento

Além de usarmos o Couchbase para armazenar e consultar dados, também o estamos usando para realizar o bloqueio de nossos serviços.

Um exemplo em que precisamos de bloqueio é quando um cliente deseja criar um novo aplicativo para processar alguns dados, e temos que verificar se o usuário tem recursos suficientes para inicializar o aplicativo. Não parece ser uma necessidade direta de bloqueio, certo? Bem, como nosso ambiente é colaborativo e várias pessoas podem trabalhar no mesmo projeto, vários clientes podem criar aplicativos dentro do mesmo ambiente ao mesmo tempo. Portanto, se não usarmos o bloqueio para esse ambiente específico, mesmo que o aplicativo de cada indivíduo seja inicializado, é possível que, ao tentar inicializá-los ao mesmo tempo, os recursos físicos reais sejam excedidos e um aplicativo - ou ambos, se os aplicativos tiverem vários componentes - possa falhar. Portanto, o requisito é realizar a verificação enquanto se mantém um bloqueio, até que o novo aplicativo possa ser levado em consideração pela outra operação de criação.

Então, qual é a nossa solução de bloqueio? O bloqueio pessimista, na forma de getAndLock e unlock, que bloqueia o acesso a um determinado documento enquanto o bloqueio é mantido. Aqui está um exemplo simplificado:

O principal problema que encontramos com essa abordagem é que, para que o getAndLock realmente funcione o tempo todo, o documento que ele bloqueia precisa existir previamente, e não há um getOrCreateAndLock atômico. Para resolver isso, como o bloqueio está vinculado ao ambiente para o qual bloqueia o acesso, integramos a criação e a exclusão do documento de bloqueio com os fluxos de criação e exclusão do ambiente. Dessa forma, o documento já é gerado quando um cliente cria um aplicativo (já que todo o processo de criação do ambiente precisa ser concluído antes), de modo que o bloqueio pode ser feito adequadamente. Como um bônus adicional, quando o ambiente específico é excluído, o documento também é excluído e não permanece no balde sem fazer nada.

Conclusão

Na Lentiq, sabemos que ter uma camada de armazenamento confiável e rápida é de extrema importância tanto para nossos clientes quanto para nossos serviços internos. O Couchbase nos provou que tomamos a decisão certa quando o escolhemos como camada de banco de dados para nossos microsserviços internos, e recomendamos de todo o coração o Couchbase se você precisar de um banco de dados NoSQL adequado!