Vamos ao primeiro deles: o Banco de Dados Relacional. O termo é antigo e remonta a 1970, na IBM, a partir da pesquisa “A Relational Model of Data for Large Shared Data Banks” conduzida pelo cientista da computação E. F. Codd.
O que é um Banco de Dados Relacional?
Esse é o tipo mais comum de banco de dados. Trata-se de um sistema que classifica as informações em estruturas “limpas” e organizadas. Já um Sistema de Gerenciamento de Banco de Dados Relacional (RDBMS) acomoda um grande número de registros, fornece dados para muitos usuários simultaneamente e serve como um repositório central de dados para programas de computador (frequentemente chamados de “aplicações”).
Um banco de dados facilita a tarefa de gerenciamento de dados, tornando as informações mais acessíveis, seguras e úteis. Neste caso, uma das vantagens é a simplicidade: o modelo de dados que sustenta o banco de dados relacional é mais facilmente implementado e gerenciado do que outros modelos conhecidos. Todas as operações em um banco de dados relacional são feitas usando uma linguagem chamada SQL (Structured Query Language), que define como devem ser realizados os comandos enviados ao banco de dados.
Outra vantagem é o “controle de simultaneidade” (ou controle de concorrência), um conceito bem fácil de compreender: imagine um sistema de reserva de passagem aérea. Há um vôo com um assento restante e duas pessoas estão tentando reservar aquele assento ao mesmo tempo. Ambas as pessoas verificam o status do vôo e são informadas de que um assento ainda está disponível. Elas inserem suas informações de pagamento e clicam no botão de reserva ao mesmo tempo. O que deve acontecer? Se o sistema estiver funcionando corretamente, apenas uma pessoa deve receber um assento e a outra deve ser informada de que não há mais um assento disponível, certo? O controle de simultaneidade é o que faz a mágica acontecer.
Banco de Dados Transacional
Para entender o que é um Banco de Dados Transacional, primeiro vamos entender o que significa o termo transação. Em termos técnicos, uma transação é um conjunto de sequências de ações, que são independentes e dependentes ao mesmo tempo. Sim, é confuso assim mesmo, mas vamos esclarecer a seguir.
Uma transação é considerada concluída apenas quando todas as ações que fazem parte dela são concluídas com êxito. Mas se uma das ações falhar, a transação como um todo será considerada uma falha e todas as ações precisarão ser revertidas ou desfeitas.
O exemplo ideal aqui é o que ocorre em uma transação bancária: esta somente é considerada bem-sucedida quando o valor exato deduzido de uma conta é creditado com sucesso em outra conta. Se o valor for deduzido, mas não for creditado, toda a transação deve ser revertida para o estágio inicial.
A Microsoft define um banco de dados transacional da seguinte forma:
“Cada transação do banco de dados tem um ponto inicial definido, seguido por etapas para modificar os dados no banco de dados. No final, o banco de dados confirma as alterações para torná-las permanentes ou reverte as alterações para o ponto inicial, quando a transação pode ser tentada novamente”.
Em praticamente todos os casos, a tecnologia usada para bancos de dados transacionais é a de Bancos de Dados Relacionais, que garantem o correto suporte a transações.
Banco de dados NoSQL
Um banco de dados NoSQL (nomeado assim por ser um banco de dados “no SQL” ou “não relacional”) fornece um mecanismo para armazenamento e recuperação de dados modelados de formas diferentes das relações tabulares usadas em Bancos de Dados Relacionais. Os bancos de dados NoSQL podem ser de vários tipos, a depender do seu modelo de dados. Os principais tipos são:
– Documento
– Chave-valor
– Colunar
– Grafo
E são diferentes daqueles usados por padrão em bancos de dados relacionais (SQL), tornando algumas operações mais rápidas em NoSQL (e algumas mais lentas, dependendo das características). As estruturas de dados usadas pelos bancos de dados NoSQL também são vistas como “mais flexíveis” do que as tabelas de banco de dados relacionais, podendo contar com uma adequação específica, a depender do problema que ele deve resolver.
Muitos bancos NoSQL surgiram para resolver problemas específicos dos contextos onde foram criados. O DynamoDB por exemplo surgiu dentro da Amazon para resolver problemas do carrinho de compras e começou como um banco do tipo chave-valor, mas depois evoluiu para se tornar também um Banco de Dados Orientado a Documentos.
O Apache Cassandra surgiu dentro do Facebook para resolver o problema do inbox de mensagens e é um banco de dados do tipo colunar, mas possui características de outros tipos de bancos NoSQL também.
O Redis é atualmente o banco de dados chave-valor mais popular do mundo e surgiu em um contexto de análise de arquivos-texto de logs de internet e depois cresceu rapidamente ao ser patrocinado pela Pivotal Software (uma subsidiária da VMWare). Posteriormente, foi adotado pelo GitHub e Instagram, entre muitas outras empresas.
Os bancos NoSQL são cada vez mais usados em aplicativos da web em tempo real e se encaixam perfeitamente em muitos aplicativos modernos, como dispositivos móveis, web e jogos, que exigem bancos de dados flexíveis, escalonáveis, de alto desempenho e altamente funcionais para oferecer excelentes experiências aos usuários.
A quantidade de bancos NoSQL cresceu muito e hoje é muito comum encontrarmos múltiplos bancos de dados de tipos distintos sendo usados pelas empresas, cada qual sendo designado a atender fins específicos, conforme demanda e necessidade. À medida que mais empresas adotaram soluções NoSQL, as plataformas de nuvem passaram a oferecer modelos gerenciados de uso dos mesmos. Isto torna a adoção mais fácil e eficiente, deixando as empresas mais concentradas em seus problemas de negócio.
Certamente falaremos muitas vezes sobre bancos de dados de diferentes tipos no nosso blog e este é apenas o primeiro artigo. É interessante mencionar que após o enorme sucesso de algumas soluções NoSQL, os bancos de dados relacionais também evoluíram para suportar modelos mais flexíveis de dados, além de suas estruturas tradicionais. O mercado de bancos de dados como um todo evoluiu consideravelmente nos últimos 10 anos.
O site DB-Engines.com usa algumas fontes públicas de dados para montar um ranking de popularidade dos bancos de dados, o que é bem interessante para avaliar o nível de maturidade e adoção de cada solução. Atualmente os dez bancos mais populares mundialmente são:
- Oracle (originalmente relacional, mas já suporta vários modelos)
- MySql (originalmente relacional, mas também suporta DocumentDB)
- Microsoft SQL Server (originalmente relacional, mas também suporta DocumentDB e grafos)
- PostgreSQL (originalmente relacional, mas também suporta DocumentDB)
- MongoDB (orientado a documentos)
- IBM DB2 (originalmente relacional, mas também suporta DocumentDB)
- Redis (originalmente chave-valor, mas já suporta vários modelos)
- Elasticsearch (orientado a documentos)
- SQLite (relacional)
- Cassandra (colunar híbrido)
Block Storage
O tipo de armazenamento mais comum que conhecemos é o file storage, ou o armazenamento de arquivos tradicional – que usamos no Google Drive, por exemplo. Neste caso, os dados são organizados e representados como uma hierarquia de arquivos em pastas.
Com o Block Storage (armazenamento em bloco), a coisa muda um pouco de figura. Trata-se de uma abordagem ao armazenamento de arquivos onde cada volume de armazenamento atua como um disco rígido individual configurado pelo administrador de armazenamento. Neste modelo, os dados são salvos na mídia de armazenamento em pedaços de tamanho fixo chamados blocos. Cada bloco está associado a um endereço único, e o endereço é o único metadado atribuído a cada bloco.
Para gerenciar o armazenamento em bloco, um programa de software independente controla como os blocos são disponibilizados e organizados nas unidades de armazenamento. O software também lida com a recuperação de dados, usando metadados para localizar os blocos desejados e, em seguida, organizar os dados neles em arquivos completos.
O armazenamento em bloco é normalmente abstraído por um sistema de arquivos ou sistema de gerenciamento de banco de dados (DBMS) para uso por aplicativos e usuários finais. Ele é o tipo de armazenamento em nuvem mais compatível com aplicações tradicionais que precisam de um “disco rígido” para manipular arquivos.
Object Storage
A origem do object storage (ou armazenamento de objetos, também conhecido como armazenamento baseado em objetos) remonta ao final dos anos 1990, a partir de uma célebre empresa chamada Seagate, responsável anos antes por ter lançado também o primeiro HD físico em computadores comerciais em 1980. Trata-se de uma arquitetura de armazenamento de dados que os gerencia e manipula como unidades distintas, chamadas de objetos. Ao contrário de outras arquiteturas de armazenamento, como sistemas de arquivos, que gerenciam dados como uma hierarquia de arquivos, e armazenamento em bloco, que gerencia os dados como blocos, esses objetos são mantidos em um único repositório e não dispostos em arquivos dentro de outras pastas. Cada objeto inclui os próprios dados, uma quantidade variável de metadados e um identificador global único.
A importância do armazenamento de objetos reside no fato de que a eficiência do desempenho de dados estáticos pode chegar ao seu pico máximo. Além disso, também possibilita análises de dados mais significativas através do uso de metadados, com recuperação mais rápida em função da falta de hierarquia de pastas e melhor otimização de recursos através da alta personalização.
O armazenamento de objetos pode ser implementado em vários níveis, entre os quais: nível de dispositivo (dispositivo de armazenamento de objeto), nível de sistema e nível da interface. Em cada caso, o armazenamento de objetos busca habilitar recursos não abordados por outras arquiteturas de armazenamento, tais como: interfaces que podem ser diretamente programáveis pelo aplicativo; e um namespace, (conjunto de sinais usados para identificar e se referir a objetos de vários tipos) que pode abranger várias instâncias de hardware físico e funções de gerenciamento de dados, como replicação e distribuição na granularidade em nível de objeto.
Os sistemas de armazenamento de objetos permitem a retenção de grandes volumes de dados não estruturados e, por isso, são usados por grandes plataformas para determinados fins, como armazenar fotos no Facebook, músicas no Spotify ou arquivos em serviços de colaboração online, como o Dropbox.
Centralizador de Logs
Outro componente importante da nuvem é o centralizador de logs, que gerencia todos os logs do sistema e é muito usado para identificar a origem de problemas.
Um log é basicamente um arquivo com dados que podem incluir desde o nome do servidor, ao tipo de log, aplicativo, tags, endereço de rede, etc. É criado pelos desenvolvedores para antecipar e prevenir erros na operação de um aplicativo ou mesmo para entender o comportamento do usuário. A todo instante, são criados volumes gigantescos de dados coletados por esses logs que, por sua vez, precisam ser analisados e depurados em tempo real. Por esse motivo, é fundamental existir uma solução de gerenciamento de log escalável e centralizada capaz de automatizar o processo e fazer com que o monitoramento, geração de alertas e relatórios levem a operações de negócios com o mínimo de problemas possíveis em servidores e sistemas.
Antes do crescimento da nuvem, os arquivos de logs ficavam dentro dos servidores, junto dos demais arquivos. Porém, com as arquiteturas de nuvem o tamanho médio dos servidores diminuiu e a quantidade aumentou muito. Temos dezenas ou até centenas de servidores atuando em conjunto para atender à demanda dos clientes. Com essa quantidade, se torna bem difícil acessar individualmente cada servidor para consultar estes arquivos de log, o que motiva muito o uso de uma estrutura centralizada que permita consultar todos ao mesmo tempo.
Além da quantidade de servidores, a nuvem contempla uma característica de Elasticidade muito interessante. Essa característica possibilita obter uma quantidade variável de servidores de acordo com a demanda presente no momento. Com isso, em dias de pico como na Black Friday, por exemplo, é possível ter centenas de servidores processando as compras dos clientes. Logo após a Black Friday, a demanda de clientes provavelmente estará bem menor; com isso, é possível atender os clientes com uma quantidade muito menor de servidores, talvez centenas de vezes menor.
A partir dessa característica de Elasticidade, a nuvem suporta muitos servidores que podem ficar ativos por alguns dias – enquanto outros, talvez só por alguns minutos. As mensagens de log geradas nesses servidores de vida curta são importantes e não podem ser descartadas. Com isso é fundamental a existência de uma estrutura centralizada que possa receber, processar e depois disponibilizar estes logs produzidos em todos os servidores. Este é exatamente o papel do Centralizador de Logs.
Os Centralizadores de Logs mais populares atualmente são o ELK e o Graylog, ambos soluções open source. Há também algumas soluções enterprise bem conhecidas como o Splunk.