A abordagem NoSQL

Introdução

Depois de tanto ouvir falar de bancos NoSQL — Not Only SQL — fiz uma pesquisa e alguns testes pra ver o que é e como funciona … Já que eu estava estudando JSON, instalei um MongoDB — no Windows mesmo — pra fazer umas brincadeiras, e entender um pouco mais sobre o que é como isso exatamente funciona.

NoSQL — Not Only SQL

Quem desenvolve aplicações transacionais SQL utiliza uma abordagem relacional — tabelas com estruturas de dados definidas, uma coluna para cada informação, chaves primárias e estrangeiras, e relacionamentos entre as tabelas, ACID, queries com JOIN e afins. Consistência, resiliência, transacionamento, leitura “limpa”, normalização de dados, etc.

Quando ouvimos falar de bancos NoSQL, soa estranho “não ter uma estrutura definida”.. isso não é bem assim …. Na verdade você não é obrigado a ter um meta-dados ou uma estrutura declarada para armazenar informações. Por exemplo, armazenar um pedido de vendas em uma base de dados relacional (SQL) normalmente exige a criação de algumas tabelas e relacionamentos, basicamente e no mínimo uma tabela para o cabeçalho dos itens de pedido, e uma para os itens do pedido em si.

Agora, se você criar um documento — por exemplo um objeto JSON — que contenha todos os dados do pedido, cabeçalho e itens, naturalmente você vai identificar as informações que compõe este objeto, mas a sua estrutura não precisa estar previamente declarada, algumas implementações permitem que você declare explicitamente uma estrutura, mas isto é opcional. Você simplesmente adiciona o documento no banco em uma “Coleção” — uma coleção seria um sinônimo de “tabela”, apenas com outro nome … acesse esse link para ver mais detalhes sobre as equivalências e terminologias usadas para um SGDB SQL e um NOSQL.

NOSQL possui um significado bem abrangente, implementações como por exemplo o MongoDB e Cassandra são orientadas a documentos, já o Redis por exemplo é orientado a chave x valor, alguns são bancos de dados em memória — sem persistência direta, enfim, cada implementação e tecnologia disponível tem seus melhores cenários de uso.  E como esse é um assunto muito em pauta para lidar com grandes volumes de informação, têm muita informação e discussões a respeito na Internet.

Casos de uso

Recomendo dar uma lida no post “Top 6 NoSQL Databases”, do Blog “Ciência e Dados“, e nos FAQs dos provedores de cada tecnologia. Existem várias considerações sobre quando NÃO USAR uma abordagem NOSQL. Quando falamos de sistemas integrados e plataformas de negócio ou serviços, devemos ter em mente que muitas funcionalidades são OLTP ou OLAP — Processamento Transacional On-Line ou Processamento Analítico On-Line ( veja mais detalhes sobre isso neste link ). Sendo assim, uma solução que contempla BI ou DataWarehouse será melhor atendida por um banco NOSQL, já a parte de movimento transacional — pedidos, notas, faturas — é melhor atendida por um SQL tradicional. Existem bancos de dados que oferecem as duas abordagens, como por exemplo o PostgreSQL — onde você pode criar uma tabela SQL tradicional com uma coluna para armazenamento de documentos JSON, e o Banco de Dados oferece uma abordagem por queries para acesso a estes dados e opções inteligentes e eficientes de indexação e extração 😀 — veja mais detalhes nos links de referência no final do post.

O que eu testei ?

Quase ia esquecendo … Eu peguei uma tabela de cadastro de agenda de um sistema legado, apenas dados básicos — nome, endereço completo, até 3 números de telefone — com 8 mil registros. Gerei um arquivo JSON apenas com os valores dos campos preenchidos, onde cada linha da tabela é um objeto JSON, usando o nome das colunas como o nome da propriedade. Resultou em um arquivo de 1,6 MB de tamanho, importado fácil e rapidamente para o MongoDB usando uma ferramenta de linha de comando. Gostei da brincadeira, achei muito simples e rápido, mas ainda estou “gatinhando” no assunto.

No último post — MongoDB em AdvPL – Prova de Conceito — montei em AdvPL uma prova de conceito para testar a conectividade de uma aplicação AdvPL com o MongoDB usando a classe tSocketClient, e o resultado foi bem satisfatório. Agora, vou começar a montar um Driver em AdvPL para conectar com o MongoDB e usar os comandos de armazenamento e pesquisa 😀

Conclusão

Nobre colega, eu deixo a conclusão desse post em aberto. Recomendo a leitura de mais fontes, as referências abaixo … simples assim. Cada abordagem e implementação têm seus atributos e diferenciais. Para volumes pequenos de dados e requisições, até um driver ODBC em arquivo TXT funciona. Mas para entrar em cenários maiores, não têm como fazer só Muçarela ou só Calabresa 😀

Agradeço novamente a audiência, e desejo a todos TERABYTES DE SUCESSO !!! 

Referências

 

Um comentário sobre “A abordagem NoSQL

Deixe uma resposta para MongoDB em AdvPL – Parte 01 | Tudo em AdvPL Cancelar resposta

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