Armazenamento de perfil de usuário: Modelagem avançada de dados - Parte 1

Praticamente todas as organizações precisam registrar e recuperar dados de usuários. Frequentemente, esses dados de usuário são permanentes, como contas de usuário com configurações, históricos e preferências definidos. Com a mesma frequência, os dados são transitórios, como no caso de sessões anônimas com apenas atividades recentes. Em ambos os casos, a organização precisará de um armazenamento de perfil de usuário/armazenamento de sessão para persistir e consultar os dados. Como esse tipo de dados é a base de muitos aplicativos na maioria das organizações, é imprescindível que o design do banco de dados de perfil de usuário seja eficiente, disponível e dimensionável. Esta postagem sobre como armazenar as preferências do usuário no banco de dados explora esse sistema.

Examinaremos um serviço de armazenamento de perfil (API REST) utilizando o Couchbase como banco de dados com um modelo de dados de usuário que aproveita os pontos fortes do Couchbase. Começaremos com todos os dados em um documento. Em seguida, veremos como e por que podemos normalizar esse documento em documentos separados e a lógica por trás das alterações. Tudo isso na perspectiva do que funcionará melhor para o modelo de dados de perfil de usuário e como planejamos utilizar os recursos do Couchbase Server.

Definição do serviço de perfil de usuário

Vamos começar definindo o serviço de exemplo e seus parâmetros. Aqui estão os parâmetros de design que me dei para este projeto:

1. Ele deve ser o armazenamento de perfil autorizado para todos os microsserviços voltados para o cliente de uma empresa fictícia e expor uma API REST para dar suporte a operações CRUD nos dados.
2. A API deve ser versionada com a funcionalidade mantida e obsoleta de acordo com o documento de design.
3. A meta de tempo de atividade é 99,999% ou melhor.
4. Ser capaz de definir perfis de usuário a serem mantidos por X anos após o último login e, de preferência, o banco de dados deve gerenciar a exclusão dos dados da conta em conjunto com o aplicativo que define o tempo de vida (TTL) nos objetos de cada usuário.
5. O serviço deve ser capaz de executar um mínimo de 50.000 autenticações e 10.000 pesquisas de perfil de usuário principal por segundo em instâncias do AWS de tamanho relativamente modesto.

Definição dos serviços expostos pela API REST

É necessário começar mapeando como os dados serão usados. As interfaces que meu serviço exporá e quais serão as mais e as menos usadas. Isso me ajudará a definir a melhor forma de projetar meus documentos. O Couchbase me permite projetar um esquema de documento com base em como, quando e com que frequência o aplicativo usará os dados, e não em como o banco de dados os armazenará, como você pode ser forçado a fazer em um RDBMS.

Aqui estão alguns exemplos de métodos que alguém pode ter para esse serviço. Não vou listar todos eles e perder tempo, mas você já entendeu a ideia.

1. getUserProfile(userID) - obtém todos os objetos no banco de dados para o usuário. Ele lerá uma matriz do nome do objeto do padrão de chave estabelecido (por exemplo, ) e, em seguida, fará uma operação de obtenção em massa de todos os objetos do usuário.
2. getSecurityQuestions(userID) - Verifica no documento de informações de login se o usuário está habilitado e, se estiver, retorna o documento de perguntas de segurança do usuário. Se o usuário estiver desativado, ele retornará um erro.
3. setSecurityQuestions(userID) - grava o documento de perguntas de segurança do usuário.
4. authorizeUser(userID, passwordHash, IP) - obtém o documento de autenticação do usuário, chama a função isEnabled e, se a conta estiver ativada, verifica se a senha corresponde. Se corresponder, ele atualiza o documento com o IP e o último login.
5. isEnabled(userID) - verifica o documento de informações de login do usuário para ver se a conta está ativada ou não no sistema. Ele retornará verdadeiro ou falso.

Procure uma lista completa dos métodos na postagem posterior do blog que discute o desenvolvimento do aplicativo e o código de amostra.

O documento inicial do usuário principal

Aqui está um exemplo de um documento de perfil de usuário com o qual eu poderia começar a capturar todos os dados de que meu serviço precisará, e essa seria uma maneira perfeitamente válida de fazer isso.

Esse documento tem cerca de 1,41kb e todos os dados ainda não estão totalmente preenchidos. Portanto, esse documento pode ficar maior dependendo do usuário. Se você tiver desenvolvedores ou for um desenvolvedor que gosta de adicionar, adicionar e adicionar dados a um documento ou tabela, ele poderá crescer muito com a evolução do seu aplicativo/serviço. Vamos dar uma olhada na otimização desse documento para saber como e quando o aplicativo usará esses dados.

Uma rápida palavra sobre acesso a dados no Couchbase

Para as partes principais desse serviço, preciso do poder e do desempenho de acessar meus dados por meio de uma chave e consultar os dados o mínimo possível. Sem repetir minha outra postagem no blog sobre acesso a dados Se você não quiser usar o Couchbase em demasia, o Couchbase tem várias maneiras de obter os dados. Se você fornecer o ObjectID do(s) objeto(s) desejado(s), seu aplicativo poderá ler e gravar esses objetos de forma excepcionalmente rápida no cache gerenciado do Data Service.

Se você quiser fazer uma consulta usando a linguagem N1QL do Couchbase (~98% compatível com ANSI 92 SQL), isso significa que você tem uma pergunta sobre os dados e isso também pode ser feito por meio do Query Service. Por sua natureza de ter que fazer mais trabalho, a consulta tem menos desempenho do que trabalhar com dados por ObjectID. É a diferença entre ter uma pergunta (consulta) e já saber a resposta (ObjectID). (Para obter mais informações sobre por que digo isso, consulte minha outra postagem no blog sobre "Como as necessidades funcionais e de desempenho determinam o acesso aos dados no Couchbase“).

Para esse projeto de esquema de banco de dados de perfil de usuário, garantiremos que nossos objetos possam ser acessados com eficiência por ambos os meios, quando necessário. Os "caminhos quentes" do aplicativo serão acessados pelo ObjectID o máximo possível, mas também faremos consultas onde isso for necessário. Temos que atender aos requisitos estabelecidos acima neste documento.

Otimização do documento principal do usuário

Ao projetar um modelo de dados do usuário para esse serviço, temos algumas opções disponíveis que são, de certa forma, exclusivas do Couchbase e de como ele dimensiona, executa e gerencia a memória. Como todos os objetos estão qualificados para serem mantidos no cache gerenciado do serviço de dados, queremos que o modelo de dados do documento e o padrão de chave usados pelo nosso serviço sejam flexíveis o suficiente para que os dados de que precisamos com frequência estejam no cache gerenciado e os dados usados com pouca frequência possam estar apenas no disco, o que não é problema. Outros bancos de dados de documentos NoSQL podem fazer com que você coloque tudo em um documento e depois consulte esses dados. A consulta com N1QL também está disponível no Couchbase, e nós a usaremos para fins específicos. Mais uma vez, a arquitetura do Couchbase, com seu modelo de dados flexível e cache gerenciado integrado, nos dá a capacidade de escolher onde e como queremos utilizar esse poder a nosso favor.

Usarei um padrão de chave e um modelo de dados normalizado, quando fizer sentido. Ao fazer isso, temos a capacidade de ler e gravar somente os dados exatos de que precisamos, quando precisamos e como precisamos, mas quando precisamos consultar dados com N1QL, também podemos fazer isso. Alguns desses padrões de design podem parecer estranhos para você, mas é assim que você poderá executar e dimensionar facilmente o Couchbase para atingir dezenas ou centenas de milhares de operações por segundo... ou até mais. Em blogs posteriores, falarei sobre como queremos consultar alguns dados para fazer análises ou algo do gênero mais tarde.

Mais uma vez, quero tentar projetar os documentos em torno do aplicativo, obtendo apenas os dados de que precisa, exatamente quando precisa, e lendo-os com a chave e não consultando. Não há necessidade de índices, exibições, junções etc. É assim que você obterá o melhor desempenho e escalabilidade absolutos com o Couchbase.

O documento de informações de login

Separei as informações de login do usuário em um documento próprio por alguns motivos, e esse mesmo tipo de filosofia também será usado em outros documentos mais tarde.

1. As informações de login são necessárias com frequência, pois os usuários se autenticam muito em nosso aplicativo e, quando o serviço precisa desses dados, ele não precisa do restante das informações do usuário na maioria das vezes. Sim, o Couchbase tem edição de subdocumentos, mas, como a maioria dos bancos de dados NoSQL, no back-end o documento ainda é remontado e transmitido por completo, por exemplo, replicação entre clusters (XDCR). Prefiro evitar isso sempre que possível.
2. Prefiro que o serviço apenas retorne do banco de dados para o aplicativo um documento de 141 bytes do que todos os 1,41k ou mais com o documento principal. A edição de subdocumentos pode atenuar isso, mas não os dois motivos seguintes.
3. Para fins de desempenho, prefiro manter uma tonelada de documentos de 141 bytes no cache gerenciado em vez dos maiores quando, novamente, nem sempre preciso do documento completo. Manter o documento inteiro no cache pode não ter muita importância quando tenho 100.000 usuários e estou fazendo apenas 1.000 operações por segundo, mas quando tenho milhões de usuários e preciso fazer 10s, se não 100s, de milhares de operações por segundo e preciso manter o desempenho, isso aumenta. Tanto em termos de desempenho quanto de recursos monetários, ou seja, RAM.
4. Isso também significa que, para os visitantes regulares do meu serviço, o documento deve estar sempre no cache gerenciado para que eles obtenham o melhor desempenho.

Também quero atualizar esse documento com a data atual no valor lastlogin e com o IP de onde eles vieram cada vez que o usuário fizer login com sucesso. Isso não é rastreado automaticamente pelo Couchbase, mas preciso disso para fins de análise de negócios e para excluir usuários que não se conectaram por um longo período. Nesse caso, também estou atualizando apenas um documento muito pequeno.

Como não é essencial para as operações diárias de autenticação de usuários, para o requisito de exclusão de usuários que não fazem login no sistema há X anos, usaremos esse assunto em outra postagem do blog.

Há também uma entidade no documento chamada "enabled" (habilitado) que pode ser usada no serviço para verificar se o usuário tem permissão para fazer login ou não.

Uma parte importante aqui é a chave do documento. Esse tipo de padrão de chave é algo que é consistente em meu aplicativo, como você verá mais adiante. Posso facilmente fazer o aplicativo concatenar isso com o nome de usuário exclusivo. Essa chave é importante porque não precisarei consultar esse documento no Couchbase, pois tenho a chave. Conhecer a chave significa que o SDK do Couchbase já sabe a resposta para a pergunta "Onde está o dado que estou procurando?", ao passo que consultar um banco de dados é fazer essa pergunta ao banco de dados e usar a potência do banco de dados (e tudo o que isso implica) para encontrar a resposta e trazer os dados de volta. Portanto, saber a chave e dizer ao banco de dados para ler/gravar esse objeto, especialmente se ele já estiver no cache gerenciado, será extremamente rápido com o Couchbase. Mesmo que o objeto esteja no disco e não no cache gerenciado, ele será rápido e colocado no cache gerenciado para estar pronto para uso em consultas posteriores. Esse gerenciamento de cache está nos bastidores e não é algo que seu aplicativo precise conhecer.

Eu também estava pensando em dividir a entidade "habilitada" do documento JSON em seu próprio objeto de par chave/valor, já que o Couchbase oferece suporte a isso. Eu estava pensando que poderia haver alguns lugares em que eu precisaria apenas saber se o usuário está habilitado no sistema ou não. Embora seja possível, decidi não fazer isso porque já estava começando a normalizar muito os dados e tenho que parar em algum lugar. Nesse caso, por uma questão de complexidade, fazia sentido deixar as coisas como estão.

Um dos outros aspectos a serem observados nesse novo documento é que adicionei as entidades doc-type e username ao esquema do documento. Você verá essas entidades em todos os outros documentos também. O motivo do tipo de documento é que posso fazer uma indexação secundária nele mais tarde. O nome de usuário é para indexação, mas também porque assim posso fazer JOINs no N1QL entre qualquer um desses documentos e o novo documento principal que você verá no final. Em partes posteriores desta série, você verá mais sobre por que isso é importante e como usá-lo a nosso favor.

Recapitulando, separamos essa parte das informações do documento principal do usuário em um documento menor por alguns bons motivos. Precisamos do documento com frequência, mantemos o documento pequeno para que as leituras/gravações sejam eficientes e, portanto, ele deve ser mantido no cache gerenciado para a maioria dos usuários com os quais nos preocupamos. Além de tudo isso, como podemos obter o objeto por sua chave, não precisamos consultar o banco de dados, portanto, as pesquisas são muito rápidas. Também adicionamos valores ao documento JSON para facilitar a consulta posteriormente.

Documento de perguntas de segurança

Criei o documento de perguntas de segurança, pois, diferentemente do documento de informações de login, que é necessário com muita frequência, esses dados devem ser necessários muito raramente. Nas ocasiões em que o serviço precisa dessas informações, ele não precisa especificamente de nenhuma das demais informações do usuário. Portanto, fazia sentido dividi-las em seu próprio objeto e adicionar uma chave que, mais uma vez, pudesse ser concatenada facilmente pelo aplicativo para obter o documento por chave. Também converti isso de uma matriz para que cada pergunta fosse seu próprio objeto. Por exemplo, question1.question ou question2.answer e, no código do meu aplicativo, posso gerar aleatoriamente um número entre 1 e 3 e, em seguida, usar uma API de subdocumento para obter apenas essa pergunta. Eu também teria a opção de mostrar todas as três perguntas, dependendo de como meu aplicativo funciona. Gosto de ter opções.

Além disso, como o documento não é usado com muita frequência, é possível que ele saia do cache gerenciado e eu não me importo. Ele é usado com tão pouca frequência pelos usuários que, se houver um pequeno impacto no desempenho para ir para o disco, aguente, usuário! Não estou pagando para manter todos esses dados na RAM porque você não consegue se lembrar de algo sobre sua conta de usuário.

Documento de funções de segurança do usuário

Eu queria ter uma lista de funções de segurança para associar a um usuário. Como muitas outras coisas, quando preciso dessas informações, não preciso de outras informações sobre o usuário. Provavelmente, terei outro documento em algum lugar definindo as funções de segurança às quais elas estão associadas.

Documento de funções de segurança

Terei outro conjunto de documentos que definem as funções de segurança a que eles se referem.

Essa é uma questão interessante, pois pode me trazer problemas mais tarde. Como esse documento pode ser lido com bastante frequência, posso criar um ponto de acesso dependendo da frequência com que meu aplicativo o utiliza. Vi um cliente que mantinha a configuração do aplicativo no Couchbase em um único documento, mas o lia mais de 10.000 vezes por segundo. Embora um único nó do Couchbase possa lidar com isso facilmente, isso se somava a todo o outro tráfego. Portanto, o único nó do cluster que tinha esse documento estava sobrecarregado. Isso não deve ser um problema aqui, mas apenas algo a ser observado. Provavelmente, mais tarde, farei uma postagem sobre como corrigir esse problema, mas 99 vezes em 100, isso não deve ser um problema. Só vi um hot spot no Couchbase uma única vez e a causa foi realmente um problema de design do aplicativo.

Documentos de e-mail, endereços e telefones

Você pode separar as matrizes de e-mail, telefones e/ou endereços do documento original, dependendo de como seu aplicativo usa os dados. Talvez tenhamos um método getEmail() ou getAddress() que seja exposto como parte desse serviço. O método getMail() receberia como entrada o nome de usuário exclusivo e seria capaz de construir facilmente a chave (email-addr::hernandez94) para o documento. Como a normalização em qualquer banco de dados, você pode ir longe demais. Portanto, tenha cuidado e só faça isso se tiver um motivo sólido para fazê-lo.

Fazer documentos para cada número de telefone que o usuário tem, como abaixo, me daria opções tanto para o acesso KV quanto para o acesso N1QL. A consulta abaixo me forneceria todos os números de telefone desse usuário e seu tipo (por exemplo, celular, trabalho etc.)

Você também poderia concatenar a chave do documento acima e obtê-la por meio do KV. Isso lhe dá opções.

O novo documento principal

Este é o documento principal agora. Se os padrões de usuário do meu aplicativo exigissem isso, eu separaria itens como endereços e telefones, mas, para fins de exemplo, decidi deixá-los, pois todos os dados que deixei aqui são dados de que não preciso com muita frequência ou, quando preciso, é ao mesmo tempo. Eu poderia normalizar mais? Sim, por exemplo, eu poderia dividir a data de criação em um objeto de valor-chave, já que quero registrá-la, mas raramente precisarei dela, mas, por enquanto, isso me leva aonde preciso estar. Não quero ficar muito louco. Além disso, quanto mais documentos você tiver, mais metadados terá também.

Exemplo de código Java

Este é um exemplo de código Java de uma operação de obtenção em massa para obter todos os documentos associados ao usuário:

Isso permite que você obtenha todos os documentos associados a esse usuário de forma muito fácil e rápida. É como colocar diferentes partes de dados em diferentes tabelas em um banco de dados relacional e, em seguida, fazer uma junção para obter todas as informações. Isso seria MUITO mais rápido do que isso.

Eu poderia pensar em modificar o código para garantir que eu tivesse todos os documentos quando terminasse essa chamada e, se não, fazer uma leitura de réplica para os documentos ausentes, no caso de um nó estar inativo, mas você entendeu a ideia.

Para obter mais informações sobre como fazer obtenções em massa, consulte a respectiva documentação do SDK do Couchbase.

Resumo

O Couchbase oferece uma maneira diferente de modelar seus dados em comparação com outros bancos de dados de documentos e, especialmente, com bancos de dados relacionais. Ao dividir alguns dados em documentos diferentes, mas relacionados por informações na chave e no documento, podemos obter os dados exatos de que precisamos para o aplicativo quando precisarmos. Mantemos exatamente os dados que queremos atualizados no cache gerenciado que é usado com frequência, mas se precisarmos de todos os documentos do usuário, podemos fazer uma operação em massa em todos eles muito rapidamente. A última parte importante é o padrão de chave usado aqui. Novamente, acessar objetos por chave é a diferença entre já saber a resposta e ter de fazer uma pergunta, como em outros bancos de dados.

Toda essa conversa sobre desempenho e padrões-chave ignora os momentos em que queremos de fato consultar os dados. Quando você tem perguntas como "Quantos usuários têm um código postal de endereço residencial 98038?". Mas, como eu disse antes, isso será deixado para outra postagem do blog nesta série.