Big Data & Cloud Computing & Microsoft Azure & Microsoft Azure Storage & NoSQL
Segue mais um capítulo desta saga. Desta vez vamos passar por alguns conceitos sobre NoSQL, sua forma e arquitetura base, escalabilidade, desempenho e sua relação com o Big Data.
Antes de prosseguir, recomendo a leitura dos seguintes posts:
Azure Table Storage e o NoSQL – Cluster e DHT
Nestes posts abordei alguns dos temas principais para o surgimento do tão falado NoSQL. Uma abordagem explicando algumas das limitações e necessidades que levaram ao surgimento de uma tecnologia capaz de atender alguns dos requisitos da Big Data, Big Users e escalabilidade.
As tecnologias e sistemas tem evoluído a passos largos. Sistemas web e aplicativos mobile tem arquiteturas com suporte a milhões de usuários simultâneos, espalhando sua carga em um conjunto de servidores atrás de um balanceador de carga. Muito se tem exigido dos bancos de dados dentro deste cenário, mesmo que estes não tenham acompanhado esta evolução na mesma proporção.
Em alguns aspectos, este é o último dominó a cair na marcha inevitável em direção a uma arquitetura de software totalmente distribuída (se é possível ansiar por isso).
Li isto em um artigo que afirmava ser um empecilho o famoso modelo de dados relacional. É claro que para as novas necessidades temos técnicas como sharding horizontal e vertical, cache distribuído e desnormalização de dados mas, essas táticas "anulam" os principais benefícios do modelo relacional, enquanto aumentam o custo e complexidade do desenvolvimento.
Ainda não encontrei uma linha de pensamento afirmando (o que faz todo o sentido) que todo o modelo relacional é ultrapassado e obsoleto, na verdade, o consenso é que existem novas necessidades e que em certos pontos fica inviável se utilizar do modelo atual.
O modelo de banco de dados relacional tem sido por convenção o modelo mais adotado até o presente momento. Muito provavelmente se você é programador aprendeu os princípios de sua profissão no desenvolvimento orientado ao modelo. Primeiro passo é fazer o modelo de dados, depois você faz a lógica e por último a casca... É como alguns pensam.
Martin Fowler em seu livro "NoSQL Distilled", traz alguns questionamentos importantes sobre o destino do banco de dados relacional. A sábia conclusão é que caminhamos para uma pluralidade de persistências onde empresas ou aplicativos usem distintas tecnologias de gerenciamento de dados conforme a necessidade. O termo introduzido por ele e Polyglot Persistence (Persistência Poliglota).
Neste livro algumas ideias e conceitos de Fowler que me chamaram a atenção:
A ascensão do NoSQL marca o fim da era de domínio do Banco de Dados Relacional... Entendendo que os bancos de dados relacionais não serão a "escolha automática".
BIG DATA é o caminho de ascensão para o NoSQL, mas não é o único motivo para usá-lo... Não é apenas pelo fato de ser um modelo de banco de dados projetado para um melhor funcionamento com grandes quantias de dados. Sua utilização se justifica em aplicações com estruturas de modelos simples.
A mudança é um fato e você precisa aproveitá-la... A ideia que o NoSQL é um necessidade e que os profissionais de dados vão precisar combinar as tecnologias para uma melhor solução conforme a necessidade.
Sob qualquer ângulo isso implica necessariamente em estar familiarizado com o conceito do NoSQL, o que passa por uma nova visão sobre a modelagem e consistência de dados.
NoSQL is BORN
Como já falei nos posts anteriores, a ênfase de um banco de dados relacional se baseia em um conjunto de propriedades chamada ACID (Atomicidade, Consistência, Isolamento e Durabilidade). De maneira simplificada, podemos dizer que este conjunto de propriedades garantem confiabilidade as transações com uma série de restrições a fim de garantir a integridade do dado. O lado negativo em relação ao Big Data é que estas mesmas restrições tornam o RDBMS padrão menos adequado para aplicações em escala.
Em geral os bancos de dados NoSQL seguem o padrão BASE (Basically Available, Soft-state, and Eventually Consistent). Este modelo premia a disponibilidadem detrimento a consistência, com o foco em arquiteturas de dados altamente escaláveis e acessíveis, o que gera algumas discuções sobre o nível de falha ou falta de coerência aceito ao se implementar este tipo de arquitetura.
O grande impulso para todo o movimento NoSQL veio em 2006 com o BigTable da Google e posteriormente em 2007 com o DynamoDB da Amazon que praticamente definiram o padrão para qualquer implementação de banco de dados NoSQL.
Os bancos de dados NoSQL são subdivididos pela maneira como trabalham com o dados, sendo classificados em quatro frentes:
Armazena os dados utilizando um par construído com base em uma chave de índice e um valor. Cada dado é armazendado em pares de chave/valor, onde os dados podem ser consultados com base na chave que é indexada.
Este esquema tem o desempenho de consulta mais rápido e são mais adequados para aplicações que necessitem de armazenamento de conteúdo em cache, por exemplo, um site de jogo que atualiza constantemente as 10 melhores pontuações dos jogadores.
Exemplos: Azure Table Storage, Dynamo DB, Redis, BerkleyDB.
Modelo de dados simples
Não há relacionamentos, você tem que criar suas próprias chaves estrangeiras
Não é adequado para modelos de dados complexos
Tenta realizar uma abordagem híbrida misturando características de um banco de dados relacional junto ao modelo NoSQL. Suportam várias linhas e colunas, além de permitir subcolunas.
Exemplos: Google Bigtable, Cassandra, HBase.
Suporta dados semi-estruturados
Naturalmente indexado
Não é adequado para dados relacionais
Podemos ver como uma extensão da simplicidade do modelo Key/Value, onde os valores são armazenados em documentos estruturados como XML ou JSON.
Um banco de dados de documentos é esquema livre onde você não tem que definir um esquema. Ela nos permite armazenar dados complexos em formatos de documento (JSON, XML etc.)
As bases de dados de documentos não suportam relações. Cada documento no armazenamento é independente e não existe integridade relacional.
Exemplos: MongoDB, CouchDB, Lotus Notes.
Modelo de dados simples e poderoso
Consultas limitadas a chaves e índices
Map Reduce para consultas maiores
Dados conectados é indexados localmente
Pode fornecer ACID
Difícil dimensionar, porém pode escalar para cima
Questões sobre a escalabilidade
O principal problema é referente a distribuição horizontal da carga de dados. O fato é que as soluções RDBMS não podem facilmente atingir SHARDING automático de dados. Isso por que o Sharding de dados exige entidades distintas que podem ser distribuídas e processadas de forma independente.
Um banco de dados relacional baseado em ACID não consegue fazer isso devido sua arquitetura baseada em tabelas.
É neste ponto que as soluções NoSQL se diferenciam. Sua arquitetura não é baseada na distribuição lógica de uma entidade entre várias tabelas, sendo armazenda em um determinado local. Uma entidade lógica pode ser qualquer coisa a partir de um valor simples ou um objeto complexo. Não existe a imposição da integridade referencial entre as entidades lógicas, apenas a consistência dentro de uma única entidade e às vezes nem isso.
Este é o aspecto que permite a distribuição automática de dados através de um grande número de nós em um banco de dados além de escrevê-las intedependentemente.
Temos que levar em consideração que ao trabalhar com multi-database temos algumas particularidades. Imanige que você precisa relizar um Commit de duas fases.
Commit em duas fases refere-se a uma transação que pode utilizar dois ou mais bancos de dados (multi-database), que podem estar localizados em servidores diferentes. Durante uma transação em bancos com essa característica garante-se que o Commit seja realizado em todos os bancos participantes ou em nenhum, ou seja, ou grava tudo ou não grava nada.
Por exemplo, se sua aplicação atualiza dados em 2 banco de dados e você faz um commit, o recurso de commit em duas fases previne situações como a de um dos bancos ficar indisponível e suas mudanças serem atualizadas somente em um dos bancos envolvidos.
Se você for escrever 20 entidades para um cluster de banco de dados com 3 nós, a ideia é gravar os dados de maneira uniforme entre todos eles. O banco de dados não precisa sincronizar entre os nós para que isso aconteça, e não há a necessidade de um Commint de duas fases, com o efeito visível que um cliente pode ver as mudanças no nó 1 antes do Cliente 2 gravar todas as 20 entidades.
Uma solução RDBMS distribuída por outro lado, precisa garantir a consistência em todos os três nós. Isso significa que um cliente irá ou não ver qualquer mudança até todos os três nós tenhan confirmado todas as fases da gravação. Além disso a sincronização do RDBMS também precisa ler os dados a partir de outros nós, a fim de assegurar a integridade referencial.
O fato de que de uma solução NoSQL poder escalar horizontalmente também significa que pode alavancar sua natureza distribuída para alta disponibilidade. Isso é muito importante na nuvem, já que um nó pode falhar a qualquer momento.
Utilizar um banco de dados NoSQL não significa que sua aplicação vai ter uma super melhora de desempenho! Na verdade o desempenho vai muito de se escolher a implementação correta para cada cenário, avaliando todas as nuances que envolvem o projeto.
Soluções de armazenamento Key / Value podem ser muito simples, e mesmo assim é possível usá-lo mal. Por ser um conceito diferente do já habitual modelo relacional e uma má concepção do modelo de dados vai matar o seu desempenho.
Além dos fatores óbvios de disco I/O, rede e armazenamento em cache (o que você deve, naturalmente, levar em consideração), tanto o desempenho do aplicativo quanto a escalabilidade dependem fortemente dos dados em si, mais especificamente sobre a distribuição em todo o cluster de banco de dados. Isto leva a um outro fator que influência até na adoção de um banco de dados NoSQL, a administração!
E o DBA?
Há um outro fator que irá desempenhar um papel fundamental na escolha entre os bancos de dados NoSQL em detrimento aos mais tradicionais. As empresas hoje já possuem expertise no uso de bancos de dados RDBMS, com especialistas e DBAs já rodados. NoSQL é novo e ainda pouco compreendido. A administração é diferente. Performance tuning e análise de desempenho são bem diferentes, assim como os padrões de problemas que vemos no dia a dia.
O processo mais importante para o desempenho e configuração estão agora regidos pelas aplicações clientes e não mais em index tuning.
No próximo post vou abordar especificamente sobre o Azure Table Service dentre deste contexto.
Windows Azure - Posters 2013 Meu guia de estudos para o Exam 70-487 Developing Windows Azure and Web Services