MongoDB em AdvPL – Parte 02

Introdução

No post anterior — MongoDB em AdvPL – Parte 01 — vimos as primeiras classes encapsulando o acesso ao MongoDB. Os fontes atualizados já estão no GITHUB, mas ainda estão sujeitos a alterações, o modelo de acesso ainda está em “prova de conceito”. Agora, vamos ver alguns detalhes das configurações e diferenças de operações e comportamentos.

Configurações mínimas do MongoDB

Instalar uma instância única do MongoDB local na máquina não têm mistério, tem muita documentação e tutorial, basicamente é next-next-finish, simples assim. Porém a configuração default não habilita autenticação de usuário ou controle de acesso — um usuário não precisa se autenticar e literalmente “pode tudo”, e o MongoDB aceita conexões de rede em todas as interfaces — conexões vindas de outras máquinas.

Uma forma de limitar o acesso ao banco de dados sem precisar autenticar usuário é fazendo ele aceitar apenas conexões vindas da máquina local. Se eu vou trabalhar com apenas uma instância, sem cluster, basta editar o arquivo de configurações mongod.cfg com um notepad por exemplo, e na seção “net:” acrescentar a configuração bindIp:

net:
   bindIp: 127.0.0.1

Controle de Usuário / Acesso

Para habilitar o controle de usuário, antes de mais nada é necessário criar um usuário administrador, que “possa tudo”, e então criar um ou mais usuários com os direitos desejados. Um detalhe interessante é que o MongoDB pode ter mais de um database, e você pode criar um usuário em um database, que tenha direitos apenas sobre aquele database, ou sobre os demais. A configuração é bem flexível, porém para realizar a autenticação, você deve informar ao client que vai conectar com o MongoDB qual é o banco de dados que será usado para autenticação. Após criar pelo menos um usuário administrador, você habilita o controle de acesso editando o arquivo de configuração do MongoDB acrescentando:

security:
   authorization: enabled

Vale lembrar que o arquivo de configurações do MongoDB não segue o padrão de um arquivo “INI”, com seções entre colchetes e chave=valor — na verdade a hierarquia é similar, mas o formato / sintaxe do arquivo — a partir do MongoDB 2.6 — foi alterada para o formato YAML — Onde seções iniciam com um identificador seguido por “:” dois pontos, e as configurações e valores dentro da seção devem ser identados com “espaço” em branco. Após alterar uma configuração, reinicie o serviço do MongoDB.

A classe de conexão publicada na ZLIB — https://github.com/siga0984/zLIB — já tem a implementação de autenticação com usuário e senha usando o método SCRAM-SHA-1. São tantas variáveis envolvidas que é até complicado de explicar, o método de autenticação evita repetição, trafega um hash criptográfico da senha “mastigado” de tal forma, que o banco consegue validar se você informou o usuário e senha corretos, e o cliente da conexão consegue verificar se o banco realmente conhece aquele usuário e senha. Usa MD5() , HMAC() e NXOR(), conversões de/para BASE64, hexadecimal e por aí vai. Em breve será implementado também o suporte ao SCRAM-SHA-256 😀

Conexão segura

O MongoDB também permite uso de conexões SSL/TLS, desde que você crie / obtenha um certificado digital, e configure o mongoDB para tal. Se você deseja apenas uma conexão criptografada, criar um certificado auto-assinado e configurá-lo no MongoDB já é suficiente. Mas ele permite opções mais avançadas, como por exemplo exigir um certificado “Client” na conexão para autenticar o usuário. Para a primeira opção — apenas criptografar a conexão — usando por exemplo um certificado auto-assinado sem senha, criamos o certificado no formato PEM, e editamos a configuração do MongoDB:

tls:
   mode: requireTLS
   certificateKeyFile: "C:\\MongoDB\\Server\\4.2\\certs\\certkey.pem"

Modelagem de Dados

O que nós chamamos de “tabela” em um banco de dados tradicional, damos o nome de “collection” no MongoDB. Por padrão não há a necessidade de você “definir” uma estrutura para uma collection, porém o objetivo de uma coleção de documentos é justamente colocar sob um mesmo “nome” um determinado tipo de informação. Criar uma collection pura e simples pode ser feito simplesmente acrescentando um documento nela — não existe a necessidade de uma instrução “create”, ao inserir um documento em uma collection que não existe, ela passa a existir.

Agora, para manter as coleções mais organizadas e evitar que um documento de um determinado tipo acabe dentro de uma collection que não tem nada a ver com ele, o MongoDB permite a criação de uma collection através de uma instrução específica, onde podemos criar um “schema validation” — ou validação de esquema. Com esse recurso é possível criar uma validação para um documento entrar naquela collection, exigindo por exemplo que um documento possua uma ou mais propriedades obrigatórias, e inserindo validações — ou constraints — para outras propriedades. Para detalhes de como isso funciona, consulte MongoDB Manual – Schema Validation

A modelagem dos dados normalmente não usa normalização de dados — ou relacionamentos — mas você pode e tem recursos para usar uma modelagem normalizada, e o Banco de Dados suporta transacionamento e operações de inserção e atualização de múltiplos documentos. Porém, cada escolha tem um peso em um determinado cenário, recomendo fortemente a leitura dos conceitos de modelagem de dados — MongoDB Manual – Data Modeling Concepts

Índices

Em um banco de dados relacional, quando não criamos um índice para uma ou mais colunas usadas em uma condição de busca, o Banco de Dados tem que olhar todos os registros para ver quem está dentro da condição desejada — isso chama-se “Full Scan”. Adivinha, o MongoBD é igualzinho. Conforme a quantidade de documentos dentro de uma collection cresce, pode ser necessário criar índices para otimizar o tempo de busca dos dados. O MongoDB tem ferramentas e comandos para retornar informações sobre o plano de execução de uma instrução de pesquisa, vamos ver isso em detalhes mais para a frente.

Interface Gráfica – Mongo Compass

Existe uma ferramenta chamada “Mongo Compass”, onde você pode fazer muita, muita coisa, com assistentes gráficos e visualizações. Você pode navegar pelos seus bancos de dados e tabelas, criar collections, executar buscas, inclusões, alterações, filtros, ver planos de execução, exportar e importar dados 😀 Muito legal, a versão “Community” é um espetáculo 😛

Mais Diferenças

Quem está acostumado a fazer uma Query, que praticamente é uma “explicação em texto descritivo” do que deve ser buscado na base de dados, a operação de “find” — ou busca de informações — trabalha com um documento JSON que deve ser escrito de uma forma especifica para informar as condições de busca a serem utilizadas. O Tutorial do MongoDB sobre “Query Documents” mostra bem estas diferenças. É um processo bem descritivo, mas fazer uma Query é mais fácil …risos…

Por exemplo :

SELECT * FROM PESSOAS WHERE CIDADE = 'Sao Paulo' AND AGE > 30

No MongoDB seria uma condição assim:

{ cidade: "Sao Paulo", age: { $gt: 30 } }

Na prática criamos um documento JSON onde podemos colocar múltiplas condições ( onde todas devem ser satisfeitas para um documento ser retornado), onde podemos colocar o valor desejado para cada campo, ou um outro JSON indicando o operador lógico ($and, $eq , $gt , $lt , entre outros) e o valor a ser aplicado. Podemos também fazer um “OR”, mas é mais diferente ainda — usamos o operador $or, especificando um array com as condições a serem consideradas:

 { $or: [ { cidade: "Sao Paulo" }, { age: { $gt: 30 } } ] }

Conclusão

Não tem caminho “Miojo” — do tipo “Aprenda MongoDB em 3 minutos” — para sair de uma modelagem relacional para uma modelagem “de-normalizada”, é um outro mindset. Acredito que a melhor forma de se fazer isso é propondo-se a criar uma ferramenta ou protótipo que USE realmente o MongoDB, e ir entendendo o “como faz” de cada coisa.

Espero que estas informações lhes sejam úteis, e lhes desejo TERABYTES DE SUCESSO !!! 

Referências

 

 

Um comentário sobre “MongoDB em AdvPL – Parte 02

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s