BANCO DE DADOS — NoSQL

Quando se fala de banco de dados não relacionais, pode-se enumerar uma lista de tipos deles desde de banco de dados orientado a objetos ao banco de dados do tipo NoSQL, sendo este último o qual nos ateremos, com o surgimento, segundo FOWLER .34 “ no final da década de 1990 com o nome de um banco relacional de código aberto [Strozzi NoSQL]. Armazenando suas tabelas sobre a forma ASCII, e cada tupla é representada por uma linha com os campos separadas por tabulações.”, no entanto não foi o BD de Strozzi que deu origem a nova onda NoSQL que surgiu no final da década de 2000.

“O uso do termo “NoSQL” que conhecemos hoje é resultado de uma reunião realizada no dia 11 de junho de 2009, em São Francisco, nos Estados Unidos, organizada por Johan Oskarsson, um desenvolvedor de software de Londres.”

(Sadalage. P — Fowler. M)

O paradigma do novo milênio é indubitavelmente o grande acúmulo de dados. Segundo a CISCO existe atualmente duas vezes a população da terra em dispositivos conectados à internet aproximadamente 14 bilhões, gadgets estes que produzem cento e setenta e oito mil conteúdos por segundo na rede mundial.

O desafio de obter, armazenar, processar e analisar está grande quantidade de dados com escalas cada vez maiores fez surgir o movimento chamado de “NoSQL”.

Com tal capacidade em mãos corporações podem tirar vantagens utilizando estes dados para planejar estratégias de mercado adequadas para qualquer tipo de negócios, sendo que invariavelmente o Big Data, Cloud, Social Analytics, Mobile Devices, etc., se beneficiaram e até mesmo impulsionaram este movimento, corporações como Amazon e Google que segundo SADALAGE. P — FOWLER. M (2013, p. 11) iniciaram projetos de banco de dados não relacionais por volta dos anos 2000 e produziram artigos concisos, sobre seus trabalhos: Big Table (Google) e Dynamo (Amazon).

“Big Data é o termo utilizado para descrever o armazenamento e processamento de grande volume de dados estruturados de várias formas. Desafiando o modelo tradicional dos SGBDRs sistemas que são usados para processar e armazenar dados, abrindo caminho para novas abordagens de processamento e armazenamento de dados”

(Sabharwal .N, Edward S.)

O papel de novas tecnologias como bancos de dados NoSQL que sugiram recentemente para suprir a demanda pelo já citado aumento exponencial de informações geradas por Big Data, Cloud, Social Analytics, Mobile Devices, etc. Mostra a sua importância no segmento de tecnologia SGBDs.

Figura 1. Ilustração da elevada taxa de geração de dados apenas dos usuários do Facebook no ano de 2013.

NoSQL via de regra utiliza-se de JSON e JSON binário (BSON) para persistência de dados. Notação de Objeto de JavaScript (JavaScript Object Notation) é o padrão para troca de dados endossado pela Ecma-262 e adotado por basicamente todas as categorias NoSQL descritas neste trabalho, pois é utilizada troca de dados na Web (Junto com XML), leve e está em formato legível tanto para humanos quanto para maquinas. Além de aceitar todos os tipos de dados primitivos como Strings, Number, Boolean além de Arrays e Hashes.

Modelos de Dados e de Distribuição

Quando nos referimos a modelagem de dados em banco de dados não relacional do tipo NoSQL, estamos conjecturando sobre os possíveis modelos para representar um conjunto dados, atualmente podendo ser definido em duas variantes: o modelo de relação ou modelo de grafos (no caso NoSQL não nos referimos a relação e tuplas de SGDBs) sendo mais conhecido como Grafos e orientação a agregados que pode se ser verificado em três categorias documentos, chave/valor e família de colunas.

O modelo relacional tradicional é baseado na simplicidade de traduzir o dado armazenado em tuplas (linhas). Está forma torna-se um tanto quanto inflexível, para as necessidades atuais dos aplicativos que exigem cada vez manipulação de quantidades massivas de dados com excelente performance. A orientação a agregados utiliza de diferente abordagem tornando explicita a possibilidade do uso de dados complexos: valores que podem ser aninhados dentro de si próprios. Agregado é um conjunto de objetos relacionados tratados como uma unidade. Trabalhar com agregados revela-se útil principalmente em execução em um cluster, já que dados representados por modelos agregados se constitui em unidade natural para replicação e fragmentação.

O modelo agregado idealizado para uso em clusters traça um paralelo com os modelos de distribuição mais encontrados em soluções de alta escalabilidade.

ACID ou eventual consistência (BASE)?

Atomicidade, Consistência, Isolamento e Durabilidade (ACID) está fora de contexto no que tange NoSQL, no entanto é um dos argumentos para o não uso em soluções baseadas neste banco de dados. O planejamento e execução de aplicações e soluções são indagadas desde início qual propriedade será relaxada, ou seja, nunca se obtém 100 % de consistência, durabilidade, etc.

A atomicidade trata o trabalho como parte indivisível (atômico). A transação deve ter todas as suas operações executadas em caso de sucesso ou nenhum resultado de alguma operação refletido sobre a base de dados em caso de falha. Ou seja, após o término de uma transação, a base de dados não deve refletir resultados parciais da transação.

A consistência trata-se da execução de uma transação que deve levar o banco de dados de um estado consistente a um outro estado consistente, ou seja, uma transação deve respeitar as regras de integridade dos dados

O isolamento é um conjunto de técnicas que tentam evitar que transações paralelas interfiram umas nas outras, fazendo com que o resultado de várias transações em paralelo seja o mesmo o resultado destas mesmas transações sendo executadas sequencialmente). Operações exteriores a uma dada transação jamais verão esta transação em estados intermediários.

Os efeitos de uma transação em caso de sucesso devem persistir no banco de dados mesmo em casos de quedas de energia, travamentos ou erros. Garante que os dados estarão disponíveis em definitivo.

Uma alternativa para ACID é BASE: Basic Availability, Soft-state, Eventual consistency.

Ao invés de requerer consistência a cada transação, é o bastante o banco de dados eventualmente estar em um estado consistente, ou seja, tudo bem se alguns dados potencialmente desatualizados e dar previsões não tão precisas, se o caso permitir.

Projetar soluções e aplicações baseados na eventual consistência (BASE) é muito mais trabalhoso, porem segundo o Teorema CAP(Consistência, Disponibilidade e Partição), se o intuito é escalabilidade não há escolha senão eventual consistência. No entanto há um paralelo entre abordagem ACID e BASE, ou seja, pode-se ser ajustada as prioridades de acordo com o projeto.

Categorias

O movimento NoSQL se apresenta por banco de dados geralmente open-source que se utiliza da JSON ou BSON para representação de dados, e que pode ser classificado como orientado a documentos, família-de-colunas, chave/valor e a grafos.

O modelo de dados relacional tradicional desenhado a muito tempo atrás para interação com o usuário final. Essa natureza orientada a usuário tem ampla implicações:

• O usuário final geralmente está interessado em dados agregados (ex. Quantidade de vendas por vendedor), e o modelo relacional enfatiza este aspecto.
• Não é dever do usuário final controlar concorrência, integridade, consistência ou tipos validos de dados, e o modelo relacional enfatiza garantias transacionais, esquemas e integridade relacional.

Em contrapartida, soluções de alta escalabilidade geralmente não concentra esforços em agregação, controle, integridade e tipos validos de dados, tanto esforço empregado para manter as propriedades tradicionais despende grande quantidade de recurso dos SGDB, por isso a evolução de modelos de dados com NoSQL.

Orientado a Documentos

Esse modelo de banco de dados armazena coleções de documentos, em que um documento representa “um objeto com um identificador único e um conjunto de campos, que podem ser strings, listas ou documentos aninhados” (LÓSCIO, 2011, p. 7). Diana & Gerosa (2010, p. 5) destacam que as bases de dados orientadas a documentos “não possuem esquema, ou seja, os documentos armazenados não precisam possuir estrutura em comum”, isto permite que novos campos sejam adicionados a um documento sem que isso cause algum problema na base de dados.

O fato dos documentos integrarem suas relações diretamente dentro do próprio documento é o fator que gera duplicidade dos dados, porém torna a consulta direta. Desta forma, por exemplo, tendo como contexto uma estrutura que mantenha a relação de Pessoa com Cargo e fosse criada uma consulta para recuperar o cargo da pessoa “A”, no modelo orientado a documentos bastaria recuperar o documento da “A”, que conteria o documento de seu cargo, já no modelo relacional seria necessário realizar um join entre a tabela Pessoa e Cargo, o que tem um custo de desempenho para execução, melhor percebido em consultas mais complexas.

Outra vantagem da duplicação de dados é que “facilita a distribuição do sistema, já que a quantidade de nós a serem consultados em uma busca envolvendo várias entidades relacionadas é menor caso elas estejam próximas” (DIANA & GEROSA, 2010, p.5). Porém, dependendo do contexto, segundo Diana & Gerosa (2010, p. 5), “pode criar problemas de consistência no banco de dados, causados por anomalias de atualização e deleção”, isso ocorre, por exemplo, caso um documento duplicado seja atualizado em apenas um documento que o armazena. Segundo Strauch (2012), as bases de dados Apache CouchDB e MongoDB são os principais representantes dessa classe de banco de dados baseada em documento.

Orientado a Chave-valor

Este modelo tem sua composição de maneira simples, “trata-se de uma abordagem parecida com uma tabela hash” (TOTH, 2011, p. 3). Segundo Lóscio et al. (2010, p. 6), este “banco de dados é composto por um conjunto de chaves, as quais estão associadas um único valor, que pode ser uma string ou um binário”. Segundo Strauch (2012, p. 52, tradução nossa), o modelo chave-valor “favorece alta escalabilidade ao invés da consistência e, portanto, a maioria deles também omite recursos ricos para consultas e ferramentas analíticas (especialmente operações de interações (joins) e agregação são postas de lado) ”. Segundo Toth (2011), o modelo chave-valor na maioria dos casos apresenta uma interface composta principalmente pelos seguintes métodos:

• Put (chave, valor) — representa o método que insere um registro, garante maior velocidade a operação;

• Get (chave) — responsável por recuperar um registro, não oferece opções para buscas mais complexas.

Orientado a família-de-colunas

Este modelo é um pouco mais complexo que o modelo chave-valor e, neste caso, mudasse o paradigma de orientação a registros ou tuplas (como no modelo relacional) para orientação a atributos ou colunas (modelo NoSQL). Neste modelo os dados são indexados por uma tripla (linha, coluna e timestamp), onde linhas e colunas são identificadas por chaves e o timestamp permite diferenciar múltiplas versões de um mesmo dado. Vale ressaltar que operações de leitura e escrita são atômicas, ou seja, todos os valores associados a uma linha são considerados na execução destas operações, independentemente das colunas que estão sendo lidas ou escritas.

Outro conceito associado ao modelo é o de família de colunas, que é usado com o intuito de agrupar colunas que armazenam o mesmo tipo de dados. Observe o exemplo da Figura 2.2. Que modela o conceito de amigos, onde primeiro Nome e sobrenome são colunas pertencentes à família de colunas denominada nome. De maneira semelhante, as colunas endereço, cidade e estado pertencem à família local. Observe que para a linha 001, o amigo Hélio tem diferentes endereços, onde para cada um deles tem um timestamp correspondente.

Como já foi dito, o acesso à linha é atômico, ou seja, mesmo que tenhamos interesse apenas na coluna sobrenome da linha 001, todas as colunas são retornadas quando esta linha for consultada. Figura 1.2. Exemplo de modelo baseado em colunas.

Este modelo de dados surgiu com o BigTable10 da Google, por isso é comum falar sobre o modelo de dados BigTable. Dentre as características deste modelo temos que permite particionamento dos dados, além de oferecer forte consistência, mas não garante alta disponibilidade. Outras soluções surgiram após o Bigtable, dentre elas o Cassandra11, desenvolvido pelo Facebook e baseado no Dynamo. Hbase12 é um banco de dados open-source semelhante ao BigTable, que utiliza o Hadoop.

Orientado a Grafos

O modelo de grafo é muito difundido em outras áreas da computação e está relacionado a soluções matemáticas. A estrutura do modelo de grafos é composta por: “nós (são os vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos) dos nós e relacionamentos” (LÓSCIO et al., 2011, p. 8). Toth (2012, p.4) ainda destaca que “pode-se armazenar qualquer tipo de dados dentro do conteúdo”.

A seguir são listadas algumas das vantagens na utilização do modelo orientado a grafo:

• O fato de “não existir tanta replicação de dados como nos outros modelos, fato que acontece por se aproveitar do relacionamento entre os registros” (TOTH, 2012, p. 4). Em modelos como o orientado a documentos, por exemplo, cada documento armazena todas suas relações de forma atômica, desta forma, se houver dois documentos, um representando a pessoa “A” e outra representando a pessoa “B” e ambos conhecem a pessoa “C”, tanto o documento “A” quanto “B” teriam que guardar uma instância da pessoa “C”. No caso dos grafos, isso é resolvido apenas utilizando ligações com arestas que armazenam um valor que indica que a pessoa conhece “C”;

• “A vantagem de utilização do modelo baseado em grafos fica bastante clara quando consultas complexas são exigidas pelo usuário. Comparado ao modelo relacional, que para estas situações pode ser muito custoso” (LÓSCIO et al., 2010, p. 8). Isso ocorre por existirem algoritmos heurísticos que podem ser aplicados para otimizar a busca por valores ao se percorrer um grafo, definindo o melhor caminho diretamente do nó inicial até o nó destino, sem que seja necessário verificar outros nós. No modelo relacional essas consultas exigiriam a construção de interações (joins), que dependendo da complexidade podem afetar no desempenho de execução da consulta;

• “Esse modelo também dá suporte ao uso de restrições sobre os dados, como restrições de identidade e de integridade referencial, por exemplo” (Diana & Gerosa, 2010, p. 6). Ao contrário da maioria dos modelos NOSQL que são mais flexíveis;

• “Esse modelo pode tornar consultas rápidas, devido à possibilidade da utilização de propriedades de grafos, medidas de centralidade (pagerank) e algoritmos de menor caminho” (TOTH, 2012, p. 3).

Logo, para situações de contexto complexo em que se conhece a semântica entre os objetos armazenados, o modelo orientado a grafo pode apresentar-se como uma escolha vantajosa.

SOLUÇOES DE ALTA-ESCALABIDADE

Quando se analisa a possibilidade de se optar por uma estratégia NoSQL em detrimento de um SGBD tradicional, é preciso levar em consideração algumas questões básicas, como, por exemplo, os critérios de escalonamento, consistência de dados e disponibilidade.

Escalabilidades horizontal (scale out)

Escalabilidade horizontal a medida em que o volume de dados cresce, aumenta a necessidade de escalabilidade e melhoria de desempenho. Dentre as soluções para este problema, temos a escalabilidade vertical, que consiste em aumentar o poder de processamento e armazenamento das máquinas, e a escalabilidade horizontal, onde ocorre um aumento no número de máquinas disponíveis para o armazenamento e processamento de dados. A escalabilidade horizontal tende a ser uma solução mais viável, porém requer que diversos threads/processos de uma tarefa sejam criados e distribuídos. Neste caso, o uso de um banco de dados relacional poderia ser inviável, uma vez que diversos processos conectando simultaneamente um mesmo conjunto de dados causaria uma alta concorrência, aumentando, consequentemente, o tempo de acesso às tabelas envolvidas. A ausência de bloqueios é uma característica fundamental dos bancos de dados NoSQL, permitindo a escalabilidade horizontal e tornando esta tecnologia adequada para solucionar os problemas de gerenciamento de volumes de dados que crescem exponencialmente, como os dados da Web 2.0.

Uma alternativa muito conhecida para alcançar escalabilidade horizontal é o Sharding, que consiste em dividir os dados em múltiplas tabelas a serem armazenadas ao longo de diversos nós de uma rede. A aplicação desta técnica traz o grande problema de “quebrar” a lógica de relacionamentos, o que é o grande forte dos bancos relacionais. Neste caso, as aplicações têm que resolver a complexidade gerada pela partição de informações como, por exemplo, a execução de interações (joins) e outros comandos. Fazer sharding, em um contexto de bacos de dados relacionais, de forma manual não é uma tarefa simples e exige considerável esforço da equipe de desenvolvimento.

MODELAGEM DE DADOS BDNR — NOSQL

Modelagem de dados NoSQL parte das especificações da aplicação para o modelo, sendo assim o oposto da modelagem tradicional relacional que parte das especificações do modelo para a aplicação.

• A modelagem relacional é conduzida pela estrutura disponível de dado, tornando a pergunta chave “O que devo responder?”.
• As especificações da aplicação conduzem a modelagem NoSQL, ex. O tipo de consulta a ser suportado, tonando a pergunta chave “O que devo perguntar?”.
• A modelagem NoSQL requer profundo conhecimento da estrutura de dados e de algoritmos diferentemente de banco de dados relacionais.
• Duplicação e desnormalização de dados são First-class citizen.
• Banco de dados relacionais não são convenientes para modelagem e processamento hierárquicos ou de grafos. NoSQL orientados a grafos é a soluções perfeita para esta demanda, mas todas as três categorias NoSQL são soluções extremamente cabíveis para modelagem hierárquica.

Desnormalização

Desnormalização pode ser definida como cópia do mesmo dado em várias tabelas ou documentos, tanto para simplificar ou otimizar processamento de consultas ou para preencher determinado modelo de dados de acordo com a regra de negócios.

As principais vantagens da desnormalização são:

• Grande volume de dados por consulta ou IO por consulta versus volume total de dados. A desnormalização pode agrupar todos os dados necessários para uma única consulta em um único lugar, ou seja, para diferentes tipos de consultas os mesmos dados estarão disponíveis. No entanto desnormalizar requer duplicação aumentando assim o volume total de dados.
• Complexidade de processamento versus volume total de dados, normalização modeling-time e query-time interações (joins) aumenta a complexidade do processamento de consultas, mais especificamente em sistemas distribuídos. A desnormalização permite o armazenamento de dados em estruturas amigáveis simplificando assim o processamento de consultas.

As técnicas de desnormalização podem ser implementadas tantos nos bancos orientados a documentos, chave-valor, família de colunas e grafos.

Agregação

A maioria das categorias de NoSQL possui soft-schema e oferece suporte a agregados, permitindo assim criação de classes, documentos, entidades com estrutura complexa (classes, documentos, entidades agregados), agregação diminui drasticamente relação one-to-many utilizando classes, documentos, entidades agregadas, conseguintemente reduzindo interações (joins). As técnicas de agregação podem ser implementadas tantos nos bancos orientados a documentos, chave-valor e família de colunas.

Interação

Interações (joins) são raramente aplicados a soluções escaláveis. Consequência de sua natureza “o que devo perguntar? ”, união de entidades são construídas na etapa da modelagem, sendo assim o oposto do tradicional modelo relacional que lida com Interações (joins) em consultas em tempo de execução. Isto quase sempre significa perda na performance, usualmente as interações são evitadas utilizando-se desnormalização e agregação, em inúmeros casos interações entre entidades são invitáveis.

As técnicas de interação podem ser implementadas tantos nos bancos orientados a documentos, chave-valor, família de colunas e grafos.

Técnicas Gerais de Modelagem

Agregação atômica

A grande parte das soluções NoSQL possui suporte limitado a transações, em alguns casos pode chegar a comportamento transacional utilizando-se aplicações MVCC acrônimo em inglês para Controle de concorrência multiversão, é comum em um modelo de dados orientado a agregados a garantia em parte das propriedades ACID.

O modelo de dados relacional tipicamente requer dados normalizados o que acarreta atualização simultânea em uma ou mais entidades trazendo um custo alto de transação, então a necessidade de infraestrutura robusta, principalmente em soluções escaláveis. A técnica de agregação atômica tem a vantagem de permitir o armazenamento centralizar entidades de negócios em um único documento, coluna ou chave/valor.

Chaves Enumeráveis

A grande vantagem de dados chave/valor não ordenados são que os registros podem ser particionados em múltiplos servidores, sendo possível recuperar seu subconjunto apenas com o hash de sua chave. Já os ordenados é um mais difícil, alguns NoSQL dispõem de contadores atômicos que permitem a geração de identificadores sequencias, possibilitando assim o uso para Chaves enumeráveis, exemplos: um blog permite comentários informando nome (idUsuario) e mensagem (idMenssagem), possibilitando a utilização de chaves compostas permitindo assim um agrupamento das mensagens tornando consultas por data. As técnicas de chaves enumeráveis podem ser implementadas tantos nos bancos orientados a chave-valor.

Tabela de Índice

A criação de índices é uma excelente técnica para otimizar transações e consultas, sendo bastante utilizada no modelo relacional, a criação de uma tabela de índices é empregada principalmente em banco de dados NoSQL de categoria família de colunas. Esta técnica consiste em criar e manter índices em uma tabela com a chaves, posteriormente podendo submeter consultas através dos identificadores disponíveis nesta tabela, exemplo: Uma tabela mestra de contas dos usuários contém as informações referente ao endereço, tais como cidade tabela esta que pode ser acessada pelo código identificador (ID) do usuário, já na outra ponta encontra-se a tabela de índices contendo as informações de endereço denormalizada e código identificador (ID) dos usuários, sendo assim possível mostrar agrupamento de conta de usuário por cidade.

No caso da tabela de índice pode haver um custo alto na performance e penaliza

Modelos de Dados e de Distribuição

Quando nos referimos a modelo de dados em banco de dados não relacional do tipo NoSQL nos referimos aos possíveis modelos para representar um conjunto dados, podemos definir duas variantes o modelo relacional (no caso NoSQL não nos referimos a relação e tuplas de SGDBs) e a orientação a agregados que pode se ser verificado em três categorias documentos, chave/valor e família de colunas. Em comum

No modelo relacional se baseia na simplicidade de traduzir o dado armazenado em tuplas (linhas). No entanto um tanto quanto inflexível os dados provenientes de modelos relacionais, a orientação a agregados utiliza de diferente abordagem tornando explicita a possibilidade do uso de dados complexos: valores que podem ser aninhados dentro de si próprios. Agregado é um conjunto de objetos relacionados tratados como uma unidade. Trabalhar com agregados revela-se útil principalmente em execução em um cluster, já que dados representados por modelos agregados se constitui em unidade natural para replicação e fragmentação.

O modelo agregado idealizado para uso em clusters traça um paralelo com os modelos de distribuição mais encontrados em soluções de alta escalabilidade.

ACID ou eventual consistência (BASE)?

Atomicidade, Consistência, Isolamento e Durabilidade (ACID) está fora de contexto no que tange NoSQL, no entanto é um dos argumentos para o não uso em soluções baseadas neste banco de dados. O planejamento e execução de aplicações e soluções são indagadas desde início qual propriedade será relaxada, ou seja, nunca se obtém 100 % de consistência, durabilidade, etc.

A atomicidade trata o trabalho como parte indivisível (atômico). A transação deve ter todas as suas operações executadas em caso de sucesso ou nenhum resultado de alguma operação refletido sobre a base de dados em caso de falha. Ou seja, após o término de uma transação, a base de dados não deve refletir resultados parciais da transação.

A consistência trata-se da execução de uma transação que deve levar o banco de dados de um estado consistente a um outro estado consistente, ou seja, uma transação deve respeitar as regras de integridade dos dados

O isolamento é um conjunto de técnicas que tentam evitar que transações paralelas interfiram umas nas outras, fazendo com que o resultado de várias transações em paralelo seja o mesmo o resultado destas mesmas transações sendo executadas sequencialmente). Operações exteriores a uma dada transação jamais verão esta transação em estados intermediários.

Os efeitos de uma transação em caso de sucesso devem persistir no banco de dados mesmo em casos de quedas de energia, travamentos ou erros. Garante que os dados estarão disponíveis em definitivo.

Uma alternativa para ACID é BASE: Basic Availability, Soft-state, Eventual consistency.

Ao invés de requerer consistência a cada transação, é o bastante o banco de dados eventualmente estar em um estado consistente, ou seja, tudo bem se alguns dados potencialmente desatualizados e dar previsões não tão precisas, se o caso permitir.

Projetar soluções e aplicações baseados na eventual consistência (BASE) é muito mais trabalhoso, porem segundo o Teorema CAP, se o intuito é escalabilidade não há escolha senão eventual consistência. No entanto há um paralelo entre abordagem ACID e BASE, ou seja, pode-se ser ajustada as prioridades de acordo com o projeto.

Categorias

O movimento NoSQL se apresenta por banco de dados geralmente open-source que se utiliza da JSON ou BSON para representação de dados, e que pode ser classificado como orientado a documentos, família-de-colunas, chave/valor e a grafos.

O modelo de dados relacional tradicional desenhado a muito tempo atrás para interação com o usuário final. Essa natureza orientada a usuário tem ampla implicações:

• O usuário final geralmente está interessado em dados agregados (ex. Quantidade de vendas por vendedor), e o modelo relacional enfatiza este aspecto.
• Não é dever do usuário final controlar concorrência, integridade, consistência ou tipos validos de dados, e o modelo relacional enfatiza garantias transacionais, esquemas e integridade relacional.

Em contrapartida, soluções de alta escalabilidade geralmente não concentra esforços em agregação, controle, integridade e tipos validos de dados, tanto esforço empregado para manter as propriedades tradicionais despende grande quantidade de recurso dos SGDB, por isso a evolução de modelos de dados com NoSQL.

Orientado a Documentos

Esse modelo de banco de dados armazena coleções de documentos, em que um documento representa “um objeto com um identificador único e um conjunto de campos, que podem ser strings, listas ou documentos aninhados” (LÓSCIO, 2011, p. 7). Diana & Gerosa (2010, p. 5) destacam que as bases de dados orientadas a documentos “não possuem esquema, ou seja, os documentos armazenados não precisam possuir estrutura em comum”, isto permite que novos campos sejam adicionados a um documento sem que isso cause algum problema na base de dados.

O fato dos documentos integrarem suas relações diretamente dentro do próprio documento é o fator que gera duplicidade dos dados, porém torna a consulta direta. Desta forma, por exemplo, tendo como contexto uma estrutura que mantenha a relação de Pessoa com Cargo e fosse criada uma consulta para recuperar o cargo da pessoa “A”, no modelo orientado a documentos bastaria recuperar o documento da “A”, que conteria o documento de seu cargo, já no modelo relacional seria necessário realizar um join entre a tabela Pessoa e Cargo, o que tem um custo de desempenho para execução, melhor percebido em consultas mais complexas.

Outra vantagem da duplicação de dados é que “facilita a distribuição do sistema, já que a quantidade de nós a serem consultados em uma busca envolvendo várias entidades relacionadas é menor caso elas estejam próximas” (DIANA & GEROSA, 2010, p.5). Porém, dependendo do contexto, segundo Diana & Gerosa (2010, p. 5), “pode criar problemas de consistência no banco de dados, causados por anomalias de atualização e deleção”, isso ocorre, por exemplo, caso um documento duplicado seja atualizado em apenas um documento que o armazena. Segundo Strauch (2012), as bases de dados Apache CouchDB e MongoDB são os principais representantes dessa classe de banco de dados baseada em documento.

Orientado a Chave-valor

Este modelo tem sua composição de maneira simples, “trata-se de uma abordagem parecida com uma tabela hash” (TOTH, 2011, p. 3). Segundo Lóscio et al. (2010, p. 6), este “banco de dados é composto por um conjunto de chaves, as quais estão associadas um único valor, que pode ser uma string ou um binário”. Segundo Strauch (2012, p. 52, tradução nossa), o modelo chave-valor “favorece alta escalabilidade ao invés da consistência e, portanto, a maioria deles também omite recursos ricos para consultas e ferramentas analíticas (especialmente operações de interações (joins) e agregação são postas de lado) ”. Segundo Toth (2011), o modelo chave-valor na maioria dos casos apresenta uma interface composta principalmente pelos seguintes métodos:

• Put (chave, valor) — representa o método que insere um registro, garante maior velocidade a operação;

• Get (chave) — responsável por recuperar um registro, não oferece opções para buscas mais complexas.

Orientado a família-de-colunas

Este modelo é um pouco mais complexo que o modelo chave-valor e, neste caso, mudasse o paradigma de orientação a registros ou tuplas (como no modelo relacional) para orientação a atributos ou colunas (modelo NoSQL). Neste modelo os dados são indexados por uma tripla (linha, coluna e timestamp), onde linhas e colunas são identificadas por chaves e o timestamp permite diferenciar múltiplas versões de um mesmo dado. Vale ressaltar que operações de leitura e escrita são atômicas, ou seja, todos os valores associados a uma linha são considerados na execução destas operações, independentemente das colunas que estão sendo lidas ou escritas.

Outro conceito associado ao modelo é o de família de colunas, que é usado com o intuito de agrupar colunas que armazenam o mesmo tipo de dados. Observe o exemplo da Figura 2.2. Que modela o conceito de amigos, onde primeiro Nome e sobrenome são colunas pertencentes à família de colunas denominada nome. De maneira semelhante, as colunas endereço, cidade e estado pertencem à família local. Observe que para a linha 001, o amigo Hélio tem diferentes endereços, onde para cada um deles tem um timestamp correspondente.

Como já foi dito, o acesso à linha é atômico, ou seja, mesmo que tenhamos interesse apenas na coluna sobrenome da linha 001, todas as colunas são retornadas quando esta linha for consultada. Figura 1.2. Exemplo de modelo baseado em colunas.

Este modelo de dados surgiu com o BigTable10 da Google, por isso é comum falar sobre o modelo de dados BigTable. Dentre as características deste modelo temos que permite particionamento dos dados, além de oferecer forte consistência, mas não garante alta disponibilidade. Outras soluções surgiram após o Bigtable, dentre elas o Cassandra11, desenvolvido pelo Facebook e baseado no Dynamo. Hbase12 é um banco de dados open-source semelhante ao BigTable, que utiliza o Hadoop.

Orientado a Grafos

O modelo de grafo é muito difundido em outras áreas da computação e está relacionado a soluções matemáticas. A estrutura do modelo de grafos é composta por: “nós (são os vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos) dos nós e relacionamentos” (LÓSCIO et al., 2011, p. 8). Toth (2012, p.4) ainda destaca que “pode-se armazenar qualquer tipo de dados dentro do conteúdo”.

A seguir são listadas algumas das vantagens na utilização do modelo orientado a grafo:

• O fato de “não existir tanta replicação de dados como nos outros modelos, fato que acontece por se aproveitar do relacionamento entre os registros” (TOTH, 2012, p. 4). Em modelos como o orientado a documentos, por exemplo, cada documento armazena todas suas relações de forma atômica, desta forma, se houver dois documentos, um representando a pessoa “A” e outra representando a pessoa “B” e ambos conhecem a pessoa “C”, tanto o documento “A” quanto “B” teriam que guardar uma instância da pessoa “C”. No caso dos grafos, isso é resolvido apenas utilizando ligações com arestas que armazenam um valor que indica que a pessoa conhece “C”;

• “A vantagem de utilização do modelo baseado em grafos fica bastante clara quando consultas complexas são exigidas pelo usuário. Comparado ao modelo relacional, que para estas situações pode ser muito custoso” (LÓSCIO et al., 2010, p. 8). Isso ocorre por existirem algoritmos heurísticos que podem ser aplicados para otimizar a busca por valores ao se percorrer um grafo, definindo o melhor caminho diretamente do nó inicial até o nó destino, sem que seja necessário verificar outros nós. No modelo relacional essas consultas exigiriam a construção de interações (joins), que dependendo da complexidade podem afetar no desempenho de execução da consulta;

• “Esse modelo também dá suporte ao uso de restrições sobre os dados, como restrições de identidade e de integridade referencial, por exemplo” (Diana & Gerosa, 2010, p. 6). Ao contrário da maioria dos modelos NOSQL que são mais flexíveis;

• “Esse modelo pode tornar consultas rápidas, devido à possibilidade da utilização de propriedades de grafos, medidas de centralidade (pagerank) e algoritmos de menor caminho” (TOTH, 2012, p. 3).

Logo, para situações de contexto complexo em que se conhece a semântica entre os objetos armazenados, o modelo orientado a grafo pode apresentar-se como uma escolha vantajosa.

SOLUÇÕES DE ALTA ESCALABILIDADE

Quando se analisa a possibilidade de se optar por uma estratégia NoSQL em detrimento de um SGBD tradicional, é preciso levar em consideração algumas questões básicas, como, por exemplo, os critérios de escalonamento, consistência de dados e disponibilidade.

Escalabilidades horizontal (scale out)

Escalabilidade horizontal a medida em que o volume de dados cresce, aumenta a necessidade de escalabilidade e melhoria de desempenho. Dentre as soluções para este problema, temos a escalabilidade vertical, que consiste em aumentar o poder de processamento e armazenamento das máquinas, e a escalabilidade horizontal, onde ocorre um aumento no número de máquinas disponíveis para o armazenamento e processamento de dados. A escalabilidade horizontal tende a ser uma solução mais viável, porém requer que diversos threads/processos de uma tarefa sejam criados e distribuídos. Neste caso, o uso de um banco de dados relacional poderia ser inviável, uma vez que diversos processos conectando simultaneamente um mesmo conjunto de dados causaria uma alta concorrência, aumentando, consequentemente, o tempo de acesso às tabelas envolvidas. A ausência de bloqueios é uma característica fundamental dos bancos de dados NoSQL, permitindo a escalabilidade horizontal e tornando esta tecnologia adequada para solucionar os problemas de gerenciamento de volumes de dados que crescem exponencialmente, como os dados da Web 2.0.

Uma alternativa muito conhecida para alcançar escalabilidade horizontal é o Sharding, que consiste em dividir os dados em múltiplas tabelas a serem armazenadas ao longo de diversos nós de uma rede. A aplicação desta técnica traz o grande problema de “quebrar” a lógica de relacionamentos, o que é o grande forte dos bancos relacionais. Neste caso, as aplicações têm que resolver a complexidade gerada pela partição de informações como, por exemplo, a execução de interações (joins) e outros comandos. Fazer sharding, em um contexto de bacos de dados relacionais, de forma manual não é uma tarefa simples e exige considerável esforço da equipe de desenvolvimento.

MODELAGEM DE DADOS BDNR — NOSQL

Modelagem de dados NoSQL parte das especificações da aplicação para o modelo, sendo assim o oposto da modelagem tradicional relacional que parte das especificações do modelo para a aplicação.

• A modelagem relacional é conduzida pela estrutura disponível de dado, tornando a pergunta chave “O que devo responder?”.
• As especificações da aplicação conduzem a modelagem NoSQL, ex. O tipo de consulta a ser suportado, tonando a pergunta chave “O que devo perguntar?”.
• A modelagem NoSQL requer profundo conhecimento da estrutura de dados e de algoritmos diferentemente de banco de dados relacionais.
• Duplicação e denormalização de dados são First-class citizen.
• Banco de dados relacionais não são convenientes para modelagem e processamento hierárquicos ou de grafos. NoSQL orientados a grafos é a soluções perfeita para esta demanda, mas todas as três categorias NoSQL são soluções extremamente cabíveis para modelagem hierárquica.

Desnormalização

Desnormalização pode ser definida como cópia do mesmo dado em várias tabelas ou documentos, tanto para simplificar ou otimizar processamento de consultas ou para preencher determinado modelo de dados de acordo com a regra de negócios.

As principais vantagens da desnormalização são:

• Grande volume de dados por consulta ou IO por consulta versus volume total de dados. A desnormalização pode agrupar todos os dados necessários para uma única consulta em um único lugar, ou seja, para diferentes tipos de consultas os mesmos dados estarão disponíveis. No entanto desmoralizar requer duplicação aumentando assim o volume total de dados.
• Complexidade de processamento versus volume total de dados, normalização modeling-time e query-time interações (joins) aumenta a complexidade do processamento de consultas, mais especificamente em sistemas distribuídos. A desnormalização permite o armazenamento de dados em estruturas amigáveis simplificando assim o processamento de consultas.

As técnicas de desnormalização podem ser implementadas tantos nos bancos orientados a documentos, chave-valor, família de colunas e grafos.

Agregação

A maioria das categorias de NoSQL possui soft-schema e oferece suporte a agregados, permitindo assim criação de classes, documentos, entidades com estrutura complexa (classes, documentos, entidades agregados), agregação diminui drasticamente relação one-to-many utilizando classes, documentos, entidades agregadas, conseguintemente reduzindo interações (joins). As técnicas de agregação podem ser implementadas tantos nos bancos orientados a documentos, chave-valor e família de colunas.

Interação

Interações (joins) são raramente aplicadas à soluções escaláveis. Consequência de sua natureza “o que devo perguntar? ”, união de entidades são construídas na etapa da modelagem, sendo assim o oposto do tradicional modelo relacional que lida com Interações (joins) em consultas em tempo de execução. Isto quase sempre significa perda na performance, usualmente as interações são evitadas utilizando-se desnormalização e agregação, em inúmeros casos interações entre entidades são invitáveis.

As técnicas de interação podem ser implementadas tantos nos bancos orientados a documentos, chave-valor, família de colunas e grafos.

Técnicas Gerais de Modelagem

Agregação atômica

A grande parte das soluções NoSQL possui suporte limitado a transações, em alguns casos pode chegar a comportamento transacional utilizando-se aplicações MVCC acrônimo em inglês para Controle de concorrência multiversão, é comum em um modelo de dados orientado a agregados a garantia em parte das propriedades ACID.

O modelo de dados relacional tipicamente requer dados normalizados o que acarreta atualização simultânea em uma ou mais entidades trazendo um custo alto de transação, então a necessidade de infraestrutura robusta, principalmente em soluções escaláveis. A técnica de agregação atômica tem a vantagem de permitir o armazenamento centralizar entidades de negócios em um único documento, coluna ou chave/valor.

Chaves Enumeráveis

A grande vantagem de dados chave/valor não ordenados são que os registros podem ser particionados em múltiplos servidores, sendo possível recuperar seu subconjunto apenas com o hash de sua chave. Já os ordenados é um mais difícil, alguns NoSQL dispõem de contadores atômicos que permitem a geração de identificadores sequencias, possibilitando assim o uso para Chaves enumeráveis, exemplos: um blog permite comentários informando nome (idUsuario) e mensagem (idMenssagem), possibilitando a utilização de chaves compostas permitindo assim um agrupamento das mensagens tornando consultas por data. As técnicas de chaves enumeráveis podem ser implementadas tantos nos bancos orientados a chave-valor.

Tabela de Índice

A criação de índices é uma excelente técnica para otimizar transações e consultas, sendo bastante utilizada no modelo relacional, a criação de uma tabela de índices é empregada principalmente em banco de dados NoSQL de categoria família de colunas. Esta técnica consiste em criar e manter índices em uma tabela com a chaves, posteriormente podendo submeter consultas através dos identificadores disponíveis nesta tabela, exemplo: Uma tabela mestra de contas dos usuários contém as informações referente ao endereço, tais como cidade tabela esta que pode ser acessada pelo código identificador (ID) do usuário, já na outra ponta encontra-se a tabela de índices contendo as informações de endereço denormalizada e código identificador (ID) dos usuários, sendo assim possível mostrar agrupamento de conta de usuário por cidade.

No caso da tabela de índice pode haver um custo alto na performance e penalizar a consistência, pois a cada transação submetida na tabela mestra a tabela de índice pode ser atualizada.

As técnicas de chaves enumeráveis podem ser implementadas tantos nos bancos orientados a família de colunas.

Agregação com Chaves Compostas

Chaves compostas são largamente utilizadas para indexação e para diferentes tipos de agrupamento, considere o exemplo: um array armazena grande quantia de registros de logs de usuários de site de um e-commerce quando o mesmo clica em determinado produto. Objetivando obter a quantia de usuários por produtos.

r a consistência, pois a cada transação submetida na tabela mestra a tabela de índice pode ser atualizada.

As técnicas de chaves enumeráveis podem ser implementadas tantos nos bancos orientados a família de colunas.