fbpx
Que tipo de Banco de Dados utilizar

Como fazer essa escolha? Aplicações altamente distribuídas já lidam com a possibilidade de usar vários bancos de dados para desafios diferentes em sua arquitetura. Assim, a escolha se dá tendo em vista as finalidades para as quais os dados serão usados.

É com base nessa ideia que o termo Purpose built database foi cunhado. O que realmente vai dizer qual banco de dados você deve utilizar são o tipo, estrutura, modelo e uso pretendido dos seus dados.

Para ajudar a avaliar as suas opções, explicamos neste artigo os diferentes tipos de bancos de dados e suas abordagens, assim como usos comuns.

Diferenças entre SQL e NoSQL

Antes de começarmos a explorar os diversos tipos de bancos de dados e as possibilidades que eles nos oferecem, é importante esclarecer as diferenças entre SQL e NoSQL. Isso porque frequentemente essas duas categorias são vistas como opostas. Há também quem as veja como parte de uma “evolução dos bancos de dados” que coloca uma categoria como ultrapassada em relação à outra.

O SQL é conhecido e utilizado desde os anos 1970. Como a única opção disponível durante muito tempo, o SQL era utilizado para diversos cenários e tipos de dados, não importando a sua origem ou finalidade. Assim, os dados eram sempre moldados como relacionais.

Mas a emergência de dados oriundos de fontes diversas, usados por aplicações que possuem exigências específicas de latência e disponibilidade, e cujos usos não comportam o sistema relacional, mudou esse cenário. Se fez necessário usar bancos de dados Not Only SQL, ou NoSQL, como vieram a ser conhecidos.

O NoSQL é uma categoria que engloba vários tipos de bancos de dados, semi-relacionais ou não-relacionais. Esses bancos não são necessariamente melhores em relação aos bancos relacionais. Cada tipo de bancos de dados serve a uma necessidade diferente e bancos relacionais são ainda a melhor opção para alguns casos.

Tipos de Bancos de Dados
Relacional

Esse tipo de banco é ideal para dados tabulares e uniformes. Nele, são estabelecidas relações entre os dados de acordo com as informações contidas em linhas e seus atributos, distribuídos em colunas.

Os sistemas relacionais são maduros e possuem uma linguagem padrão, o SQL, que independe do sistema de gestão escolhido. O uso de SQL para escrever e extrair dados do banco é uma das grandes vantagens desse tipo de banco de dados.

Outros benefícios incluem a alta consistência dos dados, que se mantém inclusive em réplicas dos bancos, e a sua atomicidade, princípio essencial para manter a precisão das informações. Por esses motivos, o modelo relacional é mais indicado para transações críticas de negócios, como listas de pagamentos, dados de clientes, inventários e outros.

Chave-valor

Ao contrário dos bancos relacionais, que não são flexíveis porque priorizam a consistência dos dados, bancos de chave-valor tem como principais benefícios a sua escalabilidade e baixa latência, que se dá em detrimento da consistência. Por isso, bancos de chave-valor são recomendados para situações em que a integridade das informações não é crítica, como, por exemplo, histórico e sessões de usuários, fóruns e websites de e-commerce.

Os dados dentro de bancos de chave-valor são formados por duas partes: uma string, que representa a chave, e os dados em si, que são o valor. A chave é usada como um índice, permitindo que o usuário faça a requisição dos dados relacionados a ela.

Orientado a documentos

Nesse tipo de banco, os dados tem o formato de documentos. Diferentemente dos bancos relacionais, em que todas as informações possuem os mesmos campos, em bancos orientados a documentos, cada documento pode ter campos similares ou não. Além disso, a ausência de schema aumenta a sua performance e permite escalabilidade horizontal.

Para endereçar os documentos, são usadas chaves únicas que os representam, como nos bancos de chave-valor. A diferença é que bancos de documentos são mais complexos, já que podem englobar os pares de chave-valor em um documento.

Bancos orientados a documentos podem ser uma boa opção caso os seus dados não precisem ser armazenados em uma tabela, com campos uniformes. Eles funcionam bem para sistemas de gerenciamento de conteúdo, softwares de blogs, entre outros.

Grafos

Ideal para extrair valor das relações entre os dados, bancos de grafos são uma forma eficiente de armazenar dados semi-estruturados. Um grafo é constituído por nodes, que agem como objetos, e edges, que são as relações entre esses objetos.

Bancos de grafos usam uma técnica chamada Index free adjacency, em que cada node possui o endereço físico na memória RAM de nodes adjacentes. Assim, os nodes apontam para objetos aos quais estão relacionados. Isso representa um ganho significativo de velocidade nas consultas, já que não é preciso recorrer a um mecanismo central de indexação para extrair os relacionamentos entre os objetos. Esse tipo de banco é muito usado em redes sociais, por exemplo.

 

Bancos de Dados em Memória Principal (IMDB)

Nesse banco, os dados são armazenados em memória ao invés de discos ou SSDs. Ao eliminar a necessidade de acesso a discos, esse tipo de banco reduz o tempo de resposta ao máximo. É ideal para operações que precisam de tempos de resposta de microssegundos ou que tenham altos picos de tráfego, como caching e real-time analytics.

Por depender exclusivamente de memória principal, IMDBs estão sujeitos a erros induzidos por falhas de servidores e processos. Para preservar os dados, eles são armazenados em discos através de logs e snapshots.

Ledger

Ledger databases permitem estabelecer relações históricas entre os seus dados. Como os dados escritos no banco são inalteráveis, cada nova atualização de estado nos dados existentes é um novo campo criado. Assim, o banco armazena um histórico com cada alteração.

O banco é constituído por alguns componentes chave: Current state, a última atualização disponível para a informação procurada; History, o histórico das transações feitas na informação procurada; e Journal, onde todas as transações são escritas e armazenadas em bloco. Uma vez que a transação é escrita no Journal, os dados não podem ser alterados.

Essa característica dos bancos Ledger é um grande diferencial para aplicações que necessitam saber com precisão as alterações de estado pelas quais os dados passaram. Esse banco pode ser aplicado em situações em que é preciso rastrear o históricos dos dados, como informações de venda de propriedades e transações financeiras, por exemplo.

Time-series

Bancos de dados de série temporal são ideais para armazenar uma sequência de pontos de dados gravados em um intervalo de tempo definido. Nesse tipo de banco, o tempo é o eixo principal, é a partir dele que as relações entre os dados são estabelecidas.

Com um schema flexível, esse tipo de banco oferece menos latência nas consultas e comporta bem dados que são atualizados com uma frequência rápida. É ideal para aplicações que fazem o acompanhamento em tempo real de variáveis, como tempo, ações na bolsa de valores e trânsito, por exemplo.

Fatores que podem afetar a sua decisão
ACID vs. CAP

Bancos relacionais possuem um conjunto de propriedades, chamado ACID, acrônimo para Atomic, Consistent, Isolated, Durable. Essas quatro propriedades são encontradas em todos os bancos de dados relacionais, isso significa dizer que as operações nesses bancos são indivisíveis, isoladas e garantem a consistência dos dados.

Bancos não-relacionais – sejam eles IMDBs, de chave-valor, orientados a documentos, entre outros- operam segundo o Teorema CAP (Consistency, Availability e Partition Tolerance). É muito difícil que um banco não-relacional tenha as três propriedades do Teorema CAP, sendo preciso escolher o banco de acordo com as propriedades necessárias para a finalidade escolhida.

 

Schema pré-definido vs. schema dinâmico

Schemas são descrições lógicas dos bancos de dados. Um schema pré-definido garante a confiabilidade e consistência dos dados, mas exige a sua uniformidade. Além disso, é difícil fazer alterações nele em bancos com dados já existentes.

Por outro lado, schemas dinâmicos permitem alterações no tipo e estrutura dos dados e são preferíveis em sistemas não-relacionais.

Big Data

Bancos relacionais são ideais para dados estruturados. Existentes desde os anos 1970, esses bancos foram pensados para uma realidade diferente dos dias de hoje.

Quando precisamos lidar com um grande volume de dados, gerados por fontes variadas, e que precisam de uma alta velocidade de processamento, esses bancos se tornam obsoletos. Isso não quer dizer que eles não sejam necessários, mas é preciso levar em consideração esses três fatores: volume, variedade e velocidade. Nesse caso, bancos NoSQL são mais indicados.

A solução: os seus dados e como você pretende utilizá-los

Nós começamos este artigo com uma pergunta: qual banco de dados utilizar? Não há uma única resposta certa. Tudo depende da estrutura dos seus dados, dos seus usos pretendidos, da necessidade de mecanismos de query, dos requerimentos de consistência, latência e velocidade de transação, entre outras variáveis.

SGBDs tradicionais e NoSQL são soluções que atendem a necessidades diferentes e que podem mostrar resultados satisfatórios, dependendo dos seus usos.

Entre em Contato

Tem interesse em saber mais sobre o assunto? Entre em contato conosco e converse com os nossos especialistas.