Amigos, este é o meu (#profMBA) segundo post de 2016, continuação do resultado da orientação da monografia de final de curso do GEORGE ASSUNÇÃO GADELHA.
1. BANCOS DE DADOS NOSQL
1.1 DEFINIÇÃO
Devido às limitações apresentadas pelos SGBDs baseados no modelo relacional, muitas mudanças ocorreram na tentativa de propor modelos alternativos que viriam com o objetivo de solucionar tais limitações. A estruturação dos dados do modelo relacional, que até então era vista como um diferencial passou a ser considerado um problema a ser contornado, pois o volume de dados que era gerado pelas aplicações web foi crescendo de forma exorbitante ao longo do tempo, e esta forma estruturada de armazenamento de dados não se mostra tão eficiente quando trabalhada com uma quantidade de dados muito grande.
Para atender a essa necessidade os projetistas de bancos de dados passaram a desenvolver uma nova estratégia de armazenamento. A ideia era a eliminação ou minimização da estrutura apresentada no modelo relacional. Dessa forma surgiram soluções que não mais apresentavam certas estruturas e regras, passando assim a perder em consistência, porém com ganho em performance. Essas soluções deram origem a uma nova categoria de bancos de dados, o NoSQL.
O termo NoSQL não é tão claro quanto a definição dos bancos de dados não relacionais. Essa falta de precisão tem gerado uma grande confusão em torno dessa categoria de bancos de dados, uma vez que a linguagem SQL não representa as limitações encontradas nos SGBDs relacionais. Por esse motivo, o termo NoSQL tem sido usado para significar “Not only SQL” ou “Não apenas SQL” como forma de reconhecer também a utilidade do modelo relacional (DIANA, GEROSA 2010).
Os bancos de dados não relacionais tem como objetivo principal promover escalabilidade no armazenamento de grandes volumes de dados. Como não possuem toda a estruturação do modelo relacional podem garantir maior disponibilidade e uma melhora na performance.
É importante destacar que o propósito desses bancos de dados não é substituir o modelo relacional como um todo, mas sim, operar em ambientes em que as limitações do modelo relacional já não o torna tão eficaz, como em casos em que seja necessário uma maior flexibilidade da estruturação de dados (BRITO, 2010).
1.2 ARQUITETURA
A arquitetura de um banco de dados descreve como os dados são organizados e armazenados em um determinado sistema. Ela fornece técnicas para obter um bom tempo de resposta das informações.
A arquitetura dos bancos NoSQL foi projetada com o intuito de prover alta performance e disponibilidade em suas aplicações. Para conseguir esses dois pontos a arquitetura dos bancos de dados NoSQL é baseada em duas importantes abordagens: A primeira recebe o nome de Sharding, que é o particionamento de uma tabela em mais de um nó. Essa técnica é usada para espalhar os dados de uma tabela por um ou mais nós segundo um critério aleatório qualquer, um nó que contenha nomes de usuários que iniciem com a letra A de uma tabela de usuários, por exemplo.
Sharding consiste em dividir os dados horizontalmente, ou seja, quebrar as tabelas, diminuindo o seu número de linhas e separando-as em ambientes diferentes. Neste ponto todos os dados de uma partição não devem conter referências aos dados de outras partições, sendo que os dados em comum deverão ser replicados entre as bases (SOUSA, Thalles; ROCHA, André, 2010 p.8).
A principal vantagem do sharding está no fato das informações serem divididas em nós separados, caso haja uma falha em algum desses nós o sistema continua funcionando normalmente para todas as operações que não dependam dos dados contidos naquele nó, ou seja, as informações dos demais nós podem continuar a serem acessadas de maneira normal.
A desvantagem dessa estratégia segundo Diana e Gerosa(2010), é que o banco de dados perde parte da sua capacidade de lidar com restrições dos dados, além de não serem mais capazes de realizar JOINs transparentemente.
A figura 1, a seguir, mostra um exemplo de esquema de sharding com n nós, onde cada um deles armazena nomes de usuário. O primeiro nó armazena nomes que iniciem com as letras A e B, o segundo com C e D e assim por diante.
Figura 1. Esquema de Sharding
Fonte: Cléverton, Jardel, Jonatam, Marcos, 2011.
A segunda técnica usada na arquitetura dos bancos de dados não relacionais é a replicação de dados. Essa abordagem, como o nome remete, consiste em replicar os dados, ou seja, armazenar cópias dos dados em outro(s) banco(s). A replicação é dividida em duas arquiteturas:
Master-Slave(mestre-escravo): Cada escrita em banco resulta em X escritas, onde X é o número de slaves. Neste caso temos um banco “Master” que propaga cada write para os bancos “slaves”. Isto aumenta a nossa velocidade de leitura, mas não melhora a capacidade de escrita (SOUSA; ROCHA, 2010).
A figura 2, logo abaixo, mostra um exemplo de banco de dados que utiliza a arquitetura Master-Slave. O banco master replica os dados para o banco slave, com isso as queries(consultas) podem ser executadas não mais em apenas um, mas em dois nós. Quando há sobrecarga desses nós, é criado um novo nó slave que também recebe uma cópia dos dados, aliviando assim o trabalho dos nós anteriores (ALMEIDA; SILVEIRA, 2010).
Figura 2. Replicação Master-Slave
Fonte: Blog Caelum
A replicação Master-Slave é pouco sujeita a inconsistência, pois, como todos os nós possuem uma cópia total dos dados, eles funcionam de maneira independente, ou seja, se um nó de leitura (slave) parar de funcionar, os demais nós continuarão trabalhando de maneira natural, porém se ocorrer uma falha no nó master, as atualizações são interrompidas. Outra vantagem dessa arquitetura de replicação é a diminuição no tempo de leitura dos dados, isso acontece por que as queries podem ser executadas de maneira simultânea.
A desvantagem encontrada nessa abordagem está no tempo de escrita, pois, para garantir a consistência é necessário usar a replicação síncrona, onde todos os nós são mantidos atualizados, e o tempo gasto para a realização deste trabalho é alto. Se usada a replicação assíncrona, onde a atualização dos nós é feita num segundo passo, a consistência passa a ser eventual.
Multi-master: Nessa abordagem não há slaves, porém, pode haver vários nós masters onde esses nós podem receber atualizações e propagar essas atualizações para os demais. Nesse tipo de replicação todos os nós trocam informações entre si.
Figura 3. Replicação Multi-Master
Fonte: Blog Caelum
A vantagem dessa abordagem é que o tempo de escrita passa a ser menor, pois como todos os nós se comunicam entre si, a replicação é feita de maneira multi-direcional, ou seja, cada servidor master aceita requisições de alterações de dados (write) de forma que a alteração seja transmitida do servidor original para os outros servidores masters que também devem confirmar a alteração (LEITE, 2010).
É bem verdade que a arquitetura multi-master leva vantagem no tempo de escrita dos dados, quando comparada a master-salve, entretanto, esta possui como desvantagem a complexidade no controle de transações, pois, exige um mecanismo mais elaborado para definir a política de propagação dos dados, visto que este trabalho pode ser feito por qualquer um dos nós.
1.3 CARACTERISTICAS DO NOSQL
1.3.1 Escalabilidade horizontal
Pode ser definida como o aumento de máquinas para a realização do particionamento dos dados em diferentes servidores, ou seja, à medida que os dados aumentam, aumenta-se também o número de servidores onde esses dados serão distribuídos. Com isso, pode-se garantir a eficiência nas operações de leitura e escrita mesmo quando se trabalha com grandes volumes de dados.
Outra vantagem do escalonamento horizontal, é que com a divisão dos dados em vários servidores, o volume dos dados por servidor é minimizado, pois, conjuntos de dados menores são mais fáceis de serem processados, armazenados ou gerenciados. (SOUSA; ROCHA, 2010).
1.3.2 Consistência eventual
Essa é mais uma característica particular dos bancos de dados NoSQL e recebe esse nome por que nem sempre a consistência é mantida.É de essencial importância para o alcance de altos níveis de escalabilidade nos bancos de dados não relacionais e foi observada a partir do teorema CAP (Consistency, Availability e Partition Tolerence). Esse teorema tem como propriedades a consistência, disponibilidade e tolerância a partição.
Consistência nesse contexto não tem exatamente o mesmo significado da consistência de transações de bancos de dados, mas sim diz respeito à ordem de execução de requisições, e significa que uma leitura de um item após uma escrita desse item deve retornar o novo valor. Disponibilidade é a propriedade de um sistema responder a todas as requisições que chegam a um nó funcionando. Tolerância à partição é a propriedade de um sistema continuar funcionando mesmo quando um problema ocorre na rede dividindo o sistema em duas ou mais partições, o que faz com que nós de uma partição não consigam se comunicar com as outras(DIANA, Mauricio De; Marco A. Gerosa, 2010 p.4).
O teorema CAP afirma que em sistemas distribuídos só é possível garantir, de forma simultânea, duas de suas três propriedades em um determinado momento. Portanto é necessário aos modelos de bancos de dados optarem entre tais propriedades. No caso do modelo não relacional são priorizados a disponibilidade e a tolerância à partição, como consequência disso a consistência nem sempre é garantida.
Esse conceito é estendido para o paradigma chamado BASE (Basically Available, Softstate, Eventual Consistency) que se caracteriza por ser basicamente disponível, ou seja, o sistema parece estar funcionando o tempo todo; em estado leve, o sistema não precisa ser consistente o tempo todo; eventualmente consistente, o sistema torna-se consistente no momento devido (BRITO, 2010).
1.3.3Esquema flexível (Schema-Free)
Consiste na ausência total ou parcial de esquema que define a estrutura dos dados. Por não possuírem essa estrutura, os bancos de dados NoSQL levam vantagem no que diz respeito a disponibilidade e escalabilidade, porém não garantem a integridade dos dados, o que é assegurado no modelo relacional.
1.3.4 Suporte nativo a replicação
Como descrito anteriormente, os bancos de dados NoSQL trabalham com replicação de dados. Essa replicação é feita de forma nativa e pode usar a arquitetura Master-Slave ou a Multi-Master. Com o uso desta técnica, em caso de falha do banco e perca de informação, os dados perdidos podem ser encontrados e recuperados usando a réplica. A vantagem que essa técnica trás consigo é um ganho considerável no tempo de recuperação das informações.
1.3.5 API Simples de acesso aos dados
O foco dos bancos de dados NoSQL, ao contrário do modelo relacional, não está em como os dados estão armazenados ou estruturados, mas sim na recuperação destes dados. Por esse motivo as API’s do modelo NoSQL são desenvolvidas com o propósito de facilitar o acesso aos dados, pois dessa forma poderia garantir maior rapidez e eficiência em suas operações.
1.3.6 Map/Reduce
Geralmente usada para trabalhar com volumes de dados muito grandes, essa técnica permite a manipulação dos dados em vários nós contidos em uma rede. Funciona da seguinte maneira: Na fase Map o problema é dividido em subproblemas que são enviados aos vários nós encontrados ao longo da rede. Na fase Reduce os subproblemas são resolvidos pelos nós filhos e a solução é repassada para seus nós pais. O processo é repetido até que a solução chegue ao nó de origem do problema (nó raiz).
1.4 CLASSIFICAÇÃO DOS BANCOS DE DADOS NOSQL
É nesta seção que serão apresentados os principais modelos de bancos de dados não relacionais, a estrutura e características de cada, de forma a ser possível identificar em que situação é mais indicado o uso de um, ao invés de outro.
Os bancos de dados NoSQL possuem várias características em comum entre si, entretanto se diferem quanto ao modelo de dados utilizados. Esses modelos podem ser divididos em quatro tipos principais, são eles:
1.4.1 Modelo chave-valor (key-value)
Esse tipo de banco de dados é o mais simples dos bancos NoSQL e o mais fácil de implementar. Permite a visualização do banco de dados como uma grande tabela de hash composta por um conjunto de chaves, onde cada uma delas está associada a um valor, que pode ser do tipo string ou binário. A figura 4 representa um exemplo de banco orientado ao modelo chave-valor, onde cada chave é um campo com uma determinada informação e cada valor é uma instância para seu campo chave correspondente. Por exemplo: a chave que está no índice 100 (Key100) da tabela, possui sua instância na página 6 (page#:6).
Figura 4: Exemplo modelo chave-valor
Fonte: Cléverton, Jardel, Jonatam, Marcos, 2011.
Além de fácil implementação, a manipulação dos dados também não é complexa. Operações simples como get(), usada para retornar um valor, e set(), que permite capturar uma valor, estão disponíveis em modelos chave-valor. Outra vantagem desses bancos é que permitem que a busca dos dados seja feita de maneira rápida pela chave, facilitando o acesso e com isso contribuindo para o aumento da disponibilidade. A desvantagem destes modelos, segundo Lóscio (2011), é que não permite a recuperação de objetos por meio de consultas mais complexas.
1.4.2 Modelo Orientado a colunas
Mais complexo que o chave-valor, o modelo de dados orientado a colunas é baseado em atributos (colunas), diferentemente dos SGBDs relacionais que tem sua orientação em registros (tuplas). O índice de um dado qualquer armazenado neste modelo é composto por três elementos: linha, coluna e timestamp. Onde linha e coluna são identificadas por chaves e o timestamp é usado para diferenciar múltiplas versões de um mesmo dado.
Outra característica particular dos bancos orientados a colunas está na escrita e leitura dos dados. A diferença é que estas operações são feitas de maneira atômica, ou seja, ao executar uma dessas ações todos os valores associados a uma linha são considerados, independente da coluna que está sendo lida ou escrita. Além disso, esses bancos também permitem agrupar as colunas que armazenam o mesmo tipo de informação em um repositório, esta técnica é conhecida como família de colunas (column family) (LÓSCIO, 2011).
Na figura 5, há uma representação de um modelo orientado a coluna. Nesse exemplo temos cinco colunas onde três delas pertencem à família "música" e as outras duas pertencem à família "cantor". Essa junção é um exemplo de uso da técnica "família de colunas", descrita anteriormente. O exemplo mostra ainda o uso do time stamp, pois na linha 001 o cantor "George Gadelha" possui mais de um e-mail.
Como dito há pouco as operações em bancos que adotam esse modelo de dados são feitas de maneira atômica, portanto se quiséssemos buscar somente o campo "faixa" da linha 002 o retorno seria as informações de todas as colunas pertencentes a tal linha.
Figura 5: Exemplo de modelo orientado a colunas
Fonte: Autor próprio
A técnica da família de colunas permite uma vantagem no tempo de leitura dos dados, visto que, estes dados são agrupados em subconjuntos, permitindo dessa forma que haja a necessidade de leitura somente em parte dos dados. A desvantagem em bancos desse tipo é que a escrita é lenta.
1.4.3 Modelo orientado a grafos
Neste caso, o banco de dados pode ser visto como um grande grafo, baseado nos grafos matemáticos, composto por nós, arestas e propriedades. Os nós são pontos no grafo também chamados de vértices, as arestas são usadas para ligar um nó a outro(s), representam o relacionamento entre os vértices, e as propriedades são os atributos contidos em cada vértice.
A figura 6 representa um exemplo de banco de dados orientado a grafo, onde os vértices em amarelo são nomes de pessoas e os vértices azuis são cidades. As arestas representam o relacionamento que cada nó pessoa, tem com os nós cidades. Aresta vermelha significa que a pessoa em questão (de onde sai a aresta) morou na cidade para a qual a aresta aponta; aresta azul significa que a pessoa em questão viajou para a cidade apontada.
Figura 6: Exemplo de modelo orientado a grafo
Fonte: Kokay, 2012
Uma consulta interessante para esse exemplo seria: “Qual cidade é a preferida para morar?”. Questões como essa não é tão simples de responder quando se usa o modelo relacional, pois nesse caso seria necessário usar muitas junções aumentando assim a complexidade e consequentemente diminuindo o desempenho da aplicação.
Portanto, segundo MAMEDE (2012), a principal vantagem de se trabalhar com dados modelados dessa forma é que essa estrutura é ideal para consultas complexas, pois, por meio dos relacionamentos inerentes aos grafos, essas consultas têm um alto ganho em performance.
1.4.4 Modelo orientado a documentos
Este tipo de banco, como o nome remete, armazena uma coleção de documentos. Um documento pode ser definido, segundo LÓSCIO(2011), como um objeto com um identificador único e um conjunto de campos, que podem ser strings, listas ou documentos aninhados. Esses documentos geralmente estão no formato JSON(Java Script Object Notation). Um documento JSON é uma coleção não ordenada de pares chave/valor.
Este modelo de dados se assemelha com o modelo chave-valor, a diferença é que no modelo chave-valor existe apenas uma única tabela hash com os campos ‘chave’ e ‘valor’ para todo o banco, enquanto no modelo orientado a documentos há uma coleção de documentos JSON onde cada um deles tem um conjunto de campos ‘chave’ e ‘valor’. Outra diferença é que a busca nesse tipo de banco pode ser feita não somente pela chave, mas também por qualquer registro ou valor que exista no banco.
Um exemplo de documento no formato JSON é representado na figura 7. Trata-se de um post informando sobre eventos, nesse documento há três campos: nome, e-mail e eventos. Os três campos são valorados, onde os dois primeiros são do tipo chave-valor e o ultimo é uma lista ordenada de valores.
Figura 7: Exemplo de documento JSON para bancos orientados a documentos
Fonte: Trabalho - NoSQL orientado a documentos
Uma vantagem importante ao se trabalhar com modelos de dados orientados a documentos é que não exige esquema fixo como acontece nos modelos relacionais. Essa flexibilidade permite que adições de campos e atualizações sejam feitas ao banco sem causar problemas a outros documentos. A desvantagem dos BDODs (Bancos de Dados Orientados a Documentos) é que perdem em consistência, pois permitem replicação de dados.
Vale salientar que não se deve considerar um modelo melhor que o outro visto que isso depende muito do ambiente de aplicação. Para entender melhor essa diferença, a tabela 1 faz um comparativo entre eles mostrando quando é mais indicado o uso de cada um deles, além de mostrar os pontos fracos e fortes e os principais bancos de dados.
Tabela 1: Comparação entre modelos de dados não relacionais
| MODELO DE DADOS | APLICAÇÕES TÍPICAS | PONTOS FORTES | PONTOS FRACOS | PRINCIPAIS BANCOS |
| Chave-Valor | Cache de conteúdo (Foco em escalar para imensas quantidades de dados). | Pesquisas rápidas | Sem esquema de armazenamento de dados | Redis, Riak |
| Orientado a Colunas | Sistemas de arquivos distribuídos | Boa distribuição de armazenamento de dados e pesquisas rápidas. | API de baixo nível | Cassandra, HiperTable |
| Orientado a Grafos | Redes Sociais | Algoritmos gráficos, caminho mais curto, conectividade. | Complexidade | Neo4j, InfoGrid |
| Orientado a Documentos | Aplicações Web. Similar ao chave-valor, mas o BD sabe o valor. | Tolerantes a dados incompletos. Flexibilidade. | Não possui sintaxe de query padrão. | CouchDB, MongoDB |
Fonte: Adaptação própria
Referências
ALMEIDA, Adriano; SILVEIRA, Guilherme. Quando muitos dados passam a atrapalhar: replicação e sharding, 2010. Disponível em:<http://blog.caelum.com.br/quando-muitos-dados-passam-a-atrapalhar-replicacao-e-sharding/>. Acessado em: 16setembro. 2013
BRITO, Ricardo W. Bancos de Dados NoSQL x SGBDs Relacionais: Análise Comparativa. Disponível em: http://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdf. Acessado em: 06, maio. 2013
DIANA, MauricioDe; Marco A. Gerosa. NOSQL na Web 2.0: Um Estudo Comparativo de Bancos Não/Relacionais para Armazenamento de Dados na Web 2.0. Disponível em:. http://www.ime.usp.br/~mdediana/nosql_wtdbd10.pdf. Acessado: 06, maio. 2013
LEITE, Gleidson. Análise Comparativa do Teorema CAP Entre Bancos de Dados NoSQL e Bancos de Dados Relacionais,2010.Disponivel em: <http://www.ffb.edu.br/sites/default/files/tcc-20102-gleidson-sobreira-leite.pdf > Acessado em 17 setembro. 2013
LÓSCIO, Bernadette Farias; OLIVEIRA, Hélio Rodrigues; PONTES, Jonas César de Sousa. NoSQL no desenvolvimento de aplicações Web colaborativas, 2011. Disponível em: http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf Acessado em: 20setembro. 2013
SOUSA, Thalles; ROCHA, André. NoSQL, 2010. Disponível em: http://www.slideshare.net/andrerochajp/artigo-nosql. Acessado em: 08 maio. 2013
