Bancos de dados Chave e Valor

Bancos de dados chave e valor são uma categoria que abrange uma série de bancos de dados NoSQL com características similares. Apesar disto, nem todos são iguais, aqui vou explicar um pouco algumas destas características sem entrar a fundo nas especificidades de cada um.

Para saber mais sobre a definição de um banco de dados NoSQL, as diferenças que eles tem de um banco de dados relacional sobre o teorema de CAP entre outras coisas, um ótimo livro chamado NoSQL Distilled. Este livro abrange conceitos iniciais e gerais de bancos de dados NoSQL e serve como uma ótima base para quem quer aprender um pouco mais.

Como assim chave e valor?

Um banco de dados chave valor é uma estrutura para armazenamento de dados que funciona de forma muito similar a uma estrutura de dados do tipo mapa ou um dicionário, onde nós temos uma chave. Esta chave é um identificador para um registro, é como se ela guardasse o endereço para o valor que procuramos.

Utilizando uma analogia simples, pode se dizer que uma estrutura deste tipo é como a recepção de uma pousada. Ao chegar na pousada e informar a hospedagem a recepção nos entrega uma chave e esta chave contém o número do nosso quarto e nos permite acessá-lo. De posse dessa chave sempre conseguimos ter um acesso direto ao nosso quarto.

Trazendo isto um pouco mais perto da linguagem técnica podemos pensar também em um JSON:

json
{
“quartos”: [
{“306”: {“camas”: 2, “tv”: “LCD”}},
{“206”: {“camas”: 1, “tv”: “LCD”}}
]
}

Tá, mas onde entra o banco de dados?

Certo, se chegamos até aqui, provavelmente você já entendeu um pouco de como tudo isto funciona, e talvez até já tenha lidado com mapas e dicionários com algumas linguagens de programação, mas fica a pergunta, o que diabos isso tudo tem a ver com bancos de dados e o que são bancos de dados chave e valor, certo?

Bom, tem tudo a ver e você já vai ver por que.

De acordo com a definição da Oracle:

Um banco de dados é uma coleção organizada de informações – ou dados – estruturadas, normalmente armazenadas eletronicamente em um sistema de computador

Nesta categoria se encaixam softwares cujo objetivo é manter dados de forma organizada:

• Redis
• DynamoDB
• Voldemort

Aqui trago somente 3 exemplos de bancos chave e valor, mas esta lista não tem o objetivo de de ser exaustiva. Este artigo possui uma lista mais completa caso seja do seu interesse.

Estes bancos, embora não trabalhem exclusivamente como chave e valor, desempenham bem este papel.

Bancos de dados Chave e Valor podem operar de duas formas: Em memória ou de forma híbrida.

Bancos de dados em memória

Quando um banco de dados está configurado para trabalhar em memória, o que ocorre é que toda a informação é armazenada na memória RAM do servidor. Como tudo, quando falamos de software (e até em outras situações) existem pontos positivos e negativos.

Como principal ponto positivo, temos a velocidade. Bancos de dados operando exclusivamente em memória não precisam escrever a informação em disco e o acesso à memória é muito mais rápido que o acesso a disco, portanto são bancos onde a escrita e a leitura de informações é muito rápida.

Em se tratando de bancos chave e valor, a leitura de informações se torna muito rápida também pela forma como é armazenada. Similar a um mapa, a partir da chave, temos acesso direto ao valor. Então, na maior parte dos casos, podemos dizer que teremos uma complexidade O(1) para a leitura de informações destes bancos de dados.

Mas, como não existe almoço grátis, existem também alguns lados negativos desta abordagem.

Como as informações estão em memória, e a memória RAM é volátil, caso ocorra alguma falha, queda de energia, etc. esta informação pode ser inteiramente perdida. Outro ponto importante é que, usualmente, temos uma quantidade muito menor de memória RAM do que disco nos servidores, e esta não é facilmente expansível a ponto de podermos ter memória de forma elástica – inclusive pelo seu custo. Sendo assim, ficamos limitados à quantidade disponível de memória RAM, tomando cuidado tanto para garantir que estamos usando esta abordagem com dados que realmente valham a pena (pois não teremos muito espaço) quanto para que esta informação não represente problema caso perdida – ou que possa ser realimentada de outra fonte.

Armazenamento Híbrido

Esses bancos geralmente não trabalham somente com armazenamento em disco, especialmente porque o objetivo deles, em geral, é ter ótima performance. Sendo assim, eles trabalham com uma abordagem mais híbrida. Esta abordagem funciona de forma que toda informação, quando é gravada, é persistida no disco; porém, uma parte dela é mantida em memória, para que o acesso seja rápido.

O que é ou não mantido em memória vai depender da política de cada banco de dados. Geralmente, pode ser configurada de acordo com o seu caso de uso para definir a forma que melhor se adequa, podendo ser, por exemplo, os registros mais recentes, os registros mais acessados, etc.

Ao utilizar esta abordagem, não temos mais a limitação da quantidade de informação com base na memória RAM, e sim no disco, que geralmente é bem maior. Caso ocorra alguma falha de hardware ou algo que ocasione a perda dos dados em memória, as informações não serão perdidas. O ponto negativo disto é que, em situações que fujam ao que foi configurado, teremos o tempo de acesso ao disco adicionado às nossas buscas.

À exceção de cenários específicos, onde realmente podemos estar dispostos a perder as informações, esta abordagem geralmente é preferível, visto que os tempos de acesso a disco vem se tornando cada vez mais rápidos à medida que tecnologias como SSD vão surgindo e sendo aprimoradas. Assim, os contras desta abordagem são cada vez menos relevantes face às vantagens presentes.

Modelagem

Quando já temos uma bagagem de um banco relacional, como geralmente é comum, temos a tendência de pensar a modelagem de dados de uma forma e as queries que iremos fazer decidimos depois. Isto ocorre pois os bancos relacionais, trabalhando com sql, nos oferecem uma infinidade de formas de localizar um registro ou uma série de registros.

Em geral isto não ocorre com bancos do tipo chave e valor, o modelo ideal de acesso é quando temos acesso direto a chave sem precisar realizar nenhum tipo de consulta. Na maior parte dos bancos, não é possível realizar uma busca dentro do valor. Para exemplificar, imagine uma biblioteca que organiza os livros de forma que sempre é possível localizá-los se souber a estante e a prateleira.

json
{
“biblioteca”: {
“A10:3”: [
{
“titulo”: “Harry Potter e a Ordem da Fênix”,
“autor”: “J.K. Rowling”
},
{
“titulo”: “Harry Potter e a Pedra Filosofal”,
“autor”: “J.K. Rowling”
}
],
“A10:12”: [
{
“titulo”: “O Hobbit”,
“autor”: “J.R.R. Tolkien”
},
{
“titulo”: “O Senhor dos Anéis: A Sociedade do Anel”,
“autor”: “J.R.R. Tolkien”
}
]
}
}

Caso saibamos qual a estante e a prateleira, poderemos localizar os livros da série Harry Potter, por exemplo. Porém, não conseguimos realizar uma consulta para saber em quais estantes estão os livros de J.R.R. Tolkien.

Portanto, com este tipo de banco de dados, é importante que realizemos a modelagem dos dados já pensando na maneira como será o acesso deles. É muito importante que se pense muito bem qual será a chave usada para estes dados, pois ela será essencial na forma de acessá-los.

Outro ponto importante sobre modelagem é o uso de aggregates, porém como isto não é um tema especifico de bancos chave e valor não vai ser alvo deste artigo, quem tiver interesse pode ler um pouco mais sobre isto aqui.

Quando usar?

Como já vimos, bancos chave e valor, em geral, possuem um modelo de acesso às informações que estão salvas que é dependente do conhecimento prévio da chave que guarda estas informações. Este modelo de acesso faz com que existam cenários onde não conseguimos utilizar este banco de dados da melhor forma possível. Imagine buscar uma lista de produtos onde, para exibir a informação de cada produto, precisamos consultar novamente o banco de dados? Então, essa seria a combinação de uma má modelagem com um use case que não combina com o tipo de banco.

Comumente, bancos de dados chave e valor são usados para armazenar informações que sejam uma unidade, tais como dados de sessão de um usuário, preferências de um usuário, carrinho de compras em e-commerce, etc.

Obviamente, o que indica se o seu caso de uso vai se adequar a um banco de dados desse tipo depende do seu modelo de negócio e da modelagem do banco e do sistema. Pode ser que, no seu cenário, seja possível ter uma lista de produtos, por exemplo, associada a uma chave específica, mas é sempre importante estar atento à forma como vai se buscar os dados face às limitações deste tipo de banco.

Conclusão

Bancos de dados chave e valor são ferramentas poderosas e não serei eu que irei fugir do clichê de dizer que com grandes poderes vem grandes responsabilidades. Ao trabalhar com este tipo de banco, precisamos avaliar com muita calma se ele é o ideal para o nosso caso, Qual a forma de armazenamento que vamos usar, se o banco que estamos pensando oferece mais de uma opção, se temos uma ideia da modelagem que iremos aplicar com base nos usos que vamos ter, etc. Mesmo com tudo isso eles tem muitas vantagens em performance, volume de acessos e dados, então se ainda não conhecem vale a pena experimentar!

Se tiver um tempinho me diga o que achou e vamos conversar!

Happy Coding!