Quando o mundo ficou grande demais para caber em tabelas – ou como nasceu o “NO-SQL”

611

Por: Marco Guimarães, líder da equipa de Analytics e Riscos na Tis

A computação, em seu início, era baseada em equipamentos caros, de uso pouco intuitivo e com suas limitações, principalmente relacionadas a preço e tamanho dos equipamentos.

Não vou entrar em muitos detalhes, mas pense num mundo onde a interação entre utilizadores e seus sistemas era feito por ecrãs em texto, a navegação entre campos era sempre feita por teclas especiais como “tab” ou “enter” e sequências enormes de comandos combinados como “control + K + B” para marcar um bloco de texto e depois dizer, com outra sequência de teclas combinadas, se ele ficaria em itálico, negrito, sublinhado, eram o lugar comum dos utilizadores de computador.

A ideia aqui é apenas contextualizar para o leitor actual um cenário da origem dos sistemas e em que, por limitação técnica, tudo precisava ser meticulosamente planeado antes. E o que os computadores conseguiam fazer muito bem desde esta época é guardar textos e números, para relacioná-los depois e recuperar estas informações quando necessário. E esta foi a receita do sucesso para que o mundo utilizasse esta tecnologia, emergente, até então.

Assim, chegamos aonde eu vos queria trazer: textos e números cabem muito bem em planilhas Excel e, por isso, também cabem muito bem em tabelas… mas quando juntamos informações de uma empresa inteira, ou de um governo, ou de um país, precisamos de uma estrutura mais robusta, um local que armazene todas estas tabelas e nos ajude a encontrá-las depois… e se isso puder ser feito em um formato que lembre a linguagem humana, ainda melhor.

E foi assim, resumidamente, que surgiram as bases de dados e uma linguagem de acesso a dados muito popular hoje em dia, a Structured Query Language, ou linguagem estruturada de consultas (em minha tradução livre). Esta linguagem de consultas a bases de dados, que me limitarei a dizer que vai além das simples perguntas e serve também para manipular estes dados e as estruturas complexas que os suportam, virou a sigla que hoje conhecemos por SQL (“esse-que-ele”, em Português, ou “síquel”, em Inglês), um sinônimo de armazenamento de informação estruturada e consistente. Assim, quando pensamos em SQL, automaticamente pensamos nestas estruturas de bases de dados que se transformaram no padrão mundial, as mais tradicionais.

Mas, sem querer fazer uma crítica injusta, diria que estas estruturas suportam o mundo tão bem quanto triângulos, círculos e retângulos explicam as formas da natureza. Ou seja, eu posso fazer um edifício ser um retângulo, uma nuvem ser um monte de círculos, uma montanha ser um triângulo e formas mais complexas serem uma junção muito bem orquestrada disto tudo, mas ainda assim estou a criar uma representação pouco fiel do que vemos no mundo real.

Assim, o que quero dizer com esta comparação, é que uma base de dados convencional e suas tabelas são excelentes para guardar uma certa visão do mundo e para relacionar as informações de uma forma que sempre nos serviu convenientemente bem para explicar cadastros de clientes, resultados de vendas, itens em estoques ou num carrinho de compras, mas sem a mesma desenvoltura para armazenar os capítulos de um livro, os possíveis caminhos para se chegar do ponto A ao B, as fotos de uma festa de aniversário tiradas por diversos aparelhos e, porque não, a estrutura de informações de um documento cheio de campos de preenchimento opcional. Na verdade, as bases comuns podem fazer isso, com certas limitações ou condições específicas…

Mas os anos 1990 e a revolução da Internet trouxeram para o plano digital tarefas antes ignoradas pelos sistemas comuns e empresas convencionais… vendas online, redes sociais e mecanismos que tentavam mapear a Internet para você… tudo isso não tinha estruturas técnicas criadas e conhecidas para suportar, pois era um mundo imperfeito e fora dos limites das bases de dados corporativas. Assim, não era mais possível representar o mundo através de tabelas e estruturas pré-moldadas e perfeitamente relacionadas, como os negócios tradicionais faziam.

O meu artigo sobre Big Data trata desta mudança de paradigma e, se quiseres saber mais sobre estas transformações, vale o tempo de leitura (https://pti.ao/a-ascensao-e-queda-do-big-data/) . Mas o facto é que neste mundo pós-Internet (ou pós-moderno, como muitos intelectuais se referem ao mundo conectado em que vivemos) era diferente demais e as novas empresas de tecnologia começaram a criar as estruturas necessárias para suportá-lo. Estas novas estruturas de dados “naturalmente imperfeitas” começaram a resolver problemas de desempenho que as bases de dados convencionais não estavam a conseguir resolver, pois não estavam preparadas para isso ou deixavam a solução muito cara e, dinheiro, era uma coisa que estas novas empresas de internet não tinham ainda.

O ponto principal é que surgiu um novo mundo, onde as estruturas de dados não precisavam ser rígidas para funcionar e, na verdade, funcionavam porque não eram rígidas. Para cada nova necessidade técnica foi criada uma estrutura otimizada de dados que atendia aos seus requisitos. Estas novas bases de dados iniciaram um movimento quase de “contra-cultura” (como os hippies nos anos 1960), pois mostravam que não era preciso se adaptar às regras pré-estabelecidas para registar os dados do mundo, que não existia apenas uma forma de armazenar bem os dados do mundo. A este movimento deu-se um nome: NO-SQL.

Mas não se engane, pois a ideia não era “destruir o SQL” e criar uma revolução que parasse de utilizar as bases de dados convencionais, como o “NO” pode sugerir, mas de dizer que o mundo não era representável apenas por elas e daí vem o significado real de “NO-SQL”, que não é a negação do SQL, mas a afirmação de que os sistemas não precisam utilizar apenas bases tradicionais, aquelas que utilizam a linguagem SQL, ou trazer uma abordagem em que a solução de dados era “Not Only SQL” (não apenas a utilizar linguagem de consulta estruturada).

Para não deixar o texto cansativo, hoje vou me limitar apenas a apresentar estas novas estruturas de modo mais amplo, mas já convido o leitor a pesquisar sobre cada uma delas, pois este “mundo novo” é muito amplo e não parou de crescer (“spoiler” de uma nova base NO-SQL que comentarei no final do texto).

Primeiro, antes de falar das bases e suas soluções para guardar dados, importante falar de um dos pilares das bases relacionais, o primeiro conceito a ser quebrado pela revolução “NO-SQL”: as propriedades de uma base conhecidas como ACID. Estas propriedades são o que me faz dizer que as bases NO-SQL querem lidar com um mundo imperfeito, pois são propriedades que dizem o que uma base de dados “que se preze” deve fazer e que, por isso, todas as bases SQL fazem, mas que às vezes sacrificam desempenho ou são uma “chatice desnecessária” para o negócio:

• Atomicidade: garantir que se uma transação na base de dados não acontecer por completo, então ela deve ser descartada (nota: transação é um trabalho na base de dados, como uma tarefa do dia-a-dia que tem seu começo, meio e fim – nosso “A” garante que só vamos guardar dados gerados por tarefas concluídas);
• Consistência: os dados sempre devem respeitar regras pré-estabelecidas e sem isso não podem ser registados (são informações obrigatórias, formatos obrigatórios e algumas condições que se o dado não obedecer, vai gerar seu descarte);
• Isolamento: uma transação é isolada da outra, ou seja, se alguém insere os dados enquanto eu leio, até que essa transação acabe com sucesso, eu nem preciso saber que ela existe e, importante, nada feito nela vai interferir no meu trabalho;
• Durabilidade: uma informação registada nunca pode se perder e sempre deve ser recuperada quando necessário.

As bases NO-SQL trouxeram o conceito de BASE, uma sigla que eu só consigo explicar com as palavras em Inglês: “Basically Available”, “Soft state”, “Eventually consistent”. Isso significa que toda a perfeição e consistência foi substituída por uma disponibilidade básica, com dados em estado maleável e de consistência eventual. Isso é o que acontece com bases distribuídas pelo planeta, algo que só apareceu em larga escala com a Internet.

A ideia é que a base de dados precisa estar disponível para o mundo todo e pode não estar uniforme por causa disso, pois um ponto da rede pode ter ficado desconectado e isso não deve atrapalhar quem está conectado. Se um pedaço dos dados ou da informação faltar, vou trabalhar com o que eu tenho e aceitar a informação como vier, pois melhor alguma informação do que nenhuma… E esta flexibilidade e praticidade faz com que as bases de dados parem de se preocupar com tudo e deixem esta responsabilidade para o sistema como um todo.

E agora vamos rapidamente falar sobre cada uma das novas famílias de dados que surgiram e que estão presentes em nossas vidas há muitos anos.

Bancos de Documento: funciona como um arquivo digital que guarda informações completas sobre algo, mesmo que “desiguais” – imagine uma pasta com todos os dados de um cliente (nome, endereço, pedidos) em um só lugar. O que é diferente: esta estrutura aceita falta de dados como algo natural (posso ter mais dados de um cliente que do outro e isso não é um problema para minha estrutura. Estes documentos são ficheiros em formato JSON, XML e algumas variações destes formatos. Exemplo: MongoDB (criado para funcionar em nuvem, distribuído e escalável, com uma estrutura “natural” para orientação a objectos).

Bancos de Pesquisa/Busca: especializados em indexar conteúdo e realizar buscas complexas e rápidas, com recursos como busca por texto completo, análise de relevância, filtros avançados e busca fuzzy (tolerante a erros). Exemplos: Apache Lucene e seus dois derivados: Elasticsearch e Solr (o desenvolvedor do Lucene trabalhou no Yahoo, hoje pouco falada, mas uma empresa que ajudou a moldar as bases da internet de hoje).

Bancos Chave-Valor: funcionam como um armário com gavetas numeradas – você usa uma “chave” (número da gaveta) para encontrar o “valor” (o que está guardado na gaveta. Muito rápido para buscar informações específicas. Isso é uma parte do que um motor de busca ou um dicionário do Python faz (uma informação pequena, rápida de buscar, aponta para outra maior). Exemplo: Redis (criado para fazer “web analytics” e entender o que um utilizador faz em um sítio web em tempo real).

• Bancos de Colunas (Colunares ou de “Colunas Grandes”): são duas variações de uma abordagem relacionada às mudanças no uso de colunas, se comparadas às bases tradicionais. As bases colunares “puras” organizam dados de uma forma em que uma característica é mais importante do que uma pessoa ou fato a que ela se refere, numa explicação simplificada… Na lógica de uma planilha, imagine que uma base de dados SQL dá mais importância para as linhas, mas uma base Colunar dá mais importância para as colunas. Ideal para análises de grandes volumes de dados e busca por características de algo (quero saber quem assistiu ao filme X, quanto foi a despesa com cartão de crédito na categoria “farmácia”, etc). A abordagem das colunas grandes, largas ou extensas (“wide column”) é ter colunas com muitos dados, como textos longos (Cassandra, criado pelo Facebook, buscava texto nas caixas de mensagens da plataforma) ou BigTable, do Google. O BigTable. Por exemplo, foi criado para ser escalável e gerenciar uma quantidade de dados que nenhuma outra base comum conseguia, com “cópias indexadas da Web inteira”.
• Bancos de Grafos: estas estruturas de dados, que se baseiam na Teoria dos Grafos, criada por Leonard Euler para resolver o problema das pontes de Königsberg, em 1736, e tratava de analisar caminhos (se era possível andar pela cidade sem passar duas vezes pela mesma ponte – e a cidade tinha 7 pontes). Claro que nesta época não havia internet e este uso não é a única função de uma base de dados de grafo. Esta base é execelente para armazenar relacionamentos de um jeito que é muito “custoso” para uma base relacional. Analisar as conexões de uma rede social, como os amigos, dos amigos, dos amigos, é algo que uma base de dados de grafo armazena e encontra sem dificuldades. Grafo é uma estrutura perfeita para entender relacionamentos complexos. Exemplo: Neo4j. Aqui vale citar a linguagem de busca de dados, que não é o SQL, mas o Cypher… só isso daria mais uma sequência enorme de artigos, então vou parar por aqui este tema.
• • Bancos Multi-modelo (híbridas ou polimórficas): são como canivetes suíços – podem funcionar de várias formas diferentes no mesmo sistema, combinando vários tipos de estrutura de dados conforme a necessidade, mas com a facilidade de ter toda a informação numa mesma base de dados. Exemplo: ArangoDB, OrientDB, Azure CosmosDB.

Muitas bases SQL tornaram-se multi-modelo, aceitando colunas em XML e outras estruturas como parte de uma tabela comum. E isso fez parte de uma especíe de “contra-ataque” das bases SQL a esta ofensiva das bases rebeldes e revolucionárias que se iniciou nos anos 2000, se fortaleceu em 2010 e hoje faz parte do nosso dia-a-dia, pois estas estruturas são fundamentais para lidar com os dados dos sistemas modernos. Mas uma diferença básica de SQL e NO-SQL é dar suporte à escalabilidade horizontal (melhorar um sistema aumentando a quantidade de computadores numa rede, não melhorando o equipamento) e a computação distribuída e paralelizada (distribui o trabalho por vários computadores para resolver um problema mais rápido).

E porque a revolução NO-SQL ainda não acabou? Porque já apareceu uma nova forma de base de dados, a Vetorial. E estas estruturas armazenam informações como listas de números (que são uma estrutura comum em computação, chamada de vetores, e daí veio o nome). Os vetores representam o significado de textos, imagens ou outros dados, como se tudo fosse convertido em coordenadas matemáticas que capturam o sentido do que se pretende classificar.

Isso é a alma do trabalho das IAs Generativas, que convertem sua pergunta em um vetor e procuram em vetores já organizados quais são os mais próximos matematicamente do que se perguntou, e assim geram as respostas. Exemplo: Pinecone, única base de dados vetorial incluída na lista inaugural Fortune 2023 50 AI Innovator – hoje há o recurso “Vector Search” em várias bases existentes. O fundador da Pinecone, Edo Liberty, trabalhou na AWS e Yahoo. Ele buscava viabilizar buscas por similaridade para resolver problemas de identificação de SPAM e viu a oportunidade no mercado quando percebeu que não havia produtos para este fim de fácil acesso a empresas de todo o tipo.

Quer saber mais sobre os exemplos que eu citei e quais as bases de dados são campeãs em adopção? Te convido a pesquisar a página https://db-engines.com/en/ranking. Nela consegues ver o ranking das bases de dados e validar quais as mais populares, como neste “TOP 10” abaixo – mas como eu consulto esta página há muitos anos, logo em seguida partilho como estava o “TOP 10” em Dezembro de 2018, para veres como algumas coisas mudaram (Access, da Microsoft, perdeu espaço e agora todas as bases são “multi-modelo”) e outras nem tanto, como os “TOP 5”, nos últimos anos:

Quer que eu fale de algum assunto específico no Portal de T.I? Dados, Data Mining, Machine Learning ou IA? Entre em contacto comigo no LinkedIn ou com o PortalTI e eu guiarei os próximos artigos para o que for mais solicitado.

Obrigado por chegar até aqui e espero que tenha sido uma leitura proveitosa!