2)Lessons
learned from 8 years of using NoSQL-Mike Bowers-Arquiteto principal da LDS
Church-Igreja de Jesus Cristo dos Santos
dos Últimos dias.
A organização (Igreja de Jesus Cristo dos Santos dos últimos dias)
tem 15 milhões de membros, com quase 30.000 congregações no mundo, desenvolve
assistência humanitária em 185 países, milhares de documentos são publicados em
188 línguas, possui 192 websites e aplicações em produção com bilhões de
“views” de páginas anualmente e rodam em centenas de servidores com MarkLogic. O
apresentador, com uma aparente altíssima capacidade e domínio técnico sobre a
tecnologia NOSQL, independentemente da variedade dos produtos que há, abriu a
sessão, oferecendo à plateia a opção pela escolha do assunto que ele falaria.
Ela poderia falar sobre qualquer coisa sobre NoSQL, desde descrição de qualquer
dos produtos do mercado, ou responder perguntas específicas sobre técnicas de
NoSQL. Ao final, houve a preferência por uma exposição aberta , de preferência
do apresentador.
A tecnologia NoSQL segundo a apresentação, está no topo
da curva de Hype do Gartner Grupo (Inflated expectations) , com Map-Reduce, na
curva descendente em direção ao vale da desilusão (disillusionment valley) e os
produtos do tipo DB-Appliances e SQL, no platô da produtividade(productivity),
ultrapassados o “slope” do encantamento (enlightment). Maiores detalhes,
procure uma curva de hype do Gartner.
A organização usa o produto MarkLogic, depois de deixar o
Oracle. O produto Marklogic é um NoSQL baseado em Documentos, originalmente em
XML e agora também em JSON. Hoje é considerado um “dual” Data Base(trabalha com
documentos XML e JSon) e também com
triple store(RDF), que permite o desenvolvimento de redes semânticas. Trabalha
com SQL e promete melhorias nesse campo nos próximos releases.
Paradigmas
A apresentação enfatizou o que nós já sabemos: Um shift
de paradigma, quando se compara as duas linhas de produtos(relacionais e NoSQL).
O modelo relacional se apresenta com suas estruturas fixas de tabelas, centradas
em linhas e colunas, índices fixos, definidos na forma de B*tree e com um
esquema obrigatório upfront(ou seja eu tenho que definir tudo antes de fazer a
primeira inserção de uma linha numa tabela). Já a proposta NoSQL centra a ideia
na mudança, flexibilidade e imprevisibilidade estrutural dos dados e dos bancos
que vão recebê-los. Pode ser que se tenha que ir alterando o schema do NoSQL
várias vezes, de forma iterativa, até alcançar o ponto estrutural desejado. O
autor deu muita ênfase ao produto MarkLogic, que pela sua dualidade estrutural (Documentos
e Redes semânticas), entra com certa vantagem nesse ranking inicial. Segundo a
apresentação, o produto tem indexação poderosa, podendo criar acessos baseados
em cada palavra no documento, além de permitir o enriquecimento semântico das
estruturas, com tripla(sujeito-predicado-objeto), criando uma espécie de
múltiplos “joins” antecipados nas
estruturas de dados. Com documentos JSON , permite estruturas aninhadas
complexas, quase que impossíveis de serem obtidas em bancos relacionais. O
modelo NoSQL tem escalabilidade horizontal, crescendo ilimitadamente pelo
acréscimo de novos clusters. A solução Oracle Rack, uma tentativa Oracle de
sair das limitações relacionais da escalabilidade vertical, não conseguiu
implementar essa estratégia de forma natural e fácil. Custa muito e é uma
solução altamente complexa, conforme confirma Mike Bowers. De qualquer forma,
nos próximos anos, as soluções NoSQL deverão descer do pico do entusiasmo,
segundo a curva de Hype do Gartner e caminhar para o platô de produtividade, tendo
antes passado pelo vale da desilusão. Essa é a sina de todas as tecnologias,
sejam disruptivas ou não.
Performance
Os aspectos de performance, normalmente registrados em
transações por segundo foram levantados comparativamente na apresentação de
Mike Bowers. As taxas de 100 transações/segundo hoje são “commodities” na
maioria dos “engine” de BD. Todos alcançam. O modelo relacional, quando bem
“afinado” pode alcançar 1000 transações/segundo, podendo a variante especial Oracle
Exadata, alcançar 5000 transações/segundo, porém com alto custo de
investimento, segundo Bowers, tangenciando a casa do milhão de dólares. Com a
chegada dos BD em Appliances(máquinas de bancos de dados dedicadas, comparadas
como uma “geladeira” onde já vem instalados vários processadores, memória em
profusão e cpus poderosas), pode-se alcançar um patamar em torno de 5.000
transações/segundo. Nessa cesta entram a solução Exadata(Oracle), a Netezza
(IBM) e a Teradata(Teradata). A partir dai, os números começam a montar os seus
desafios, tanto no “throughput”, quando no custo. Arranjos em clusters desses
“appliances” podem custar muito dinheiro e alcançar limites de 10.000 transações/segundo
Bowers. Aqui entram os produtos NoSQL no benchmark. Naturalmente concebidos
para a escalabilidade, por genética de arquitetura, esses produtos hoje chegam
a limites superiores através da replicação de máquinas commodities baratas. Fazendo
um raciocínio simples: Hoje algumas organizações produzem cerca de 8640 GB de
dados por dia, que se distribuem por entre 8.640.000.000 transações de 1 KB/dia, o que dá cerca de 100.000 transações/segundo,
patamar desafiador para os SGBDR. Isso somente se consegue com muitos
servidores clusterizados, operando os bancos NoSQL do tipo Documento ou Chave-valor. Para
um patamar de 500.000 transações/segundo, restam somente os produtos KV(Chave-Valor) ou os Colunares, estes, herdeiros do Big
Table, também com múltiplos servidores clusterizados. Os valores desses
arranjos devem ser cuidadosamente avaliados. Um NoSQL gira em torno de
US4000,00-US32.000,00/servidor, segundo Bowers . O Oracle Exadata, gira em
torno de US75.000,00 /core(não por servidor). Um servidor com 24
core(processadores duplos), daria 24 x US$75.000,00, o que representa um
investimento significativo, com diferenças abissais em termos de valores a
investir. Isso explica, segundo o autor da palestra, a corrida das empresas
startups e mesmo das de outro porte, para soluções de bancos de dados NoSQL.
Outros pontos, porém devem ser observados.
Escalabilidade
A escalabilidade, grande fator diferencial desses tipos
de BD, passa pelo conceito de distribuição dos dados e do processamento em
diversas máquinas espalhadas geograficamente. Essas máquinas poderão habitar
Data Centers diferentes, em regiões diferentes. Os Data Centers (DC) podem ser
divididos, por questão de segurança, em zonas de processamentos independentes.
Se uma zona “cair”, a outra segura o funcionamento do DC, garantindo a sua disponibilidade.
Dessa forma, os dados NoSQL adotam a estratégia de replicação de dados,
normalmente realizada em zonas diferentes de um DC, ou em DC diferentes. O
modelo relacional, leia-se Oracle e SQL Server também tentam oferecer opções de
descentralização com replicação dos dados. De novo, essas “features” não são
baratas quando se fala de soluções como Oracle(Golden Gate), Dell Plex, etc,
podendo chegar a US$500.000 por uma implementação pequena de replicação entre data centers, segundo
Bowers. Já os produtos NoSQL não tem custo extra para isso, pois trouxeram do
berço, essas características. Um dos desafios desta arquitetura distribuída é o
sincronismo entre duas réplicas de dados e se potencializa se estiverem em dois
data centers diferentes, diz Bowers. Se a conexão for síncrona, claramente
haverá um comprometimento de performance, devido aos rigores do 2PC-Two Phase
Commit, conforme aprendemos nas aulas de BD distribuídos. Os bancos NoSQL tem ,
quase que nativamente, esses mecanismos de replicações assíncronas, que podem
ser M-M(Master-Master) ou M-S(Master Slave). No M-M, as atualizações podem
ocorrer em todas as cópias(que são consideradas Master) e as atualizações são enviadas para as outras. No caso M-S, as
atualizações ocorrem somente em um nó e as réplicas são enviadas aos outros
nós, os quais tem somente permissão de
leitura.
NoSQL:
Na palestra, Mike Bowers centrou no Marklogic um produto
(Document DB) em crescimento, com características completamente opostas aos RDBMS.
No Marklogic você pode indexar qualquer dado em qualquer documento. Pode
procurar pelo documento com aquela palavra. A pesquisa é precisa, usa a
semântica para dar consistência na busca(busca de um texto em um documento). A
precisão pode ser por palavra, por frase, etc. O autor mostrou um texto sobre EF
Codd, que foi o inventor do modelo relacional. O produto permite definir cada palavra como
pertencente a um certo domínio (pessoa, cliente, etc) dando a elas uma
semântica própria. Quando duas palavras são comparadas, embora elas tenham a
mesma grafia, o sistema é capaz de diferenciá-las pela semântica. Codd autor do
modelo relacional e codd(bacalhau), serão diferenciados, pela semântica
introduzida, como riqueza adicional. A modelagem é feita por documentos XML com
tags, que injetam um sentido preciso nas palavras. O produto, segundo o
consultor, também pode adotar o modelo de Grafos. A modelagem de grafos é rica
pois envolve metadados e ontologia. Hoje, há uma série de ontologias
disponíveis para diversos assuntos (procure por LOV-Linked Open Vocabularies,
que contém uma série dessas classificações, para diversos domínios). A
combinação de XML e JSON num banco de dados com Triplas (Grafos), forma um novo
paradigma de bancos de dados enriquecidos pela semântica. A pergunta principal
que deverá ser respondida com cuidado é o “Porquê” (Why) eu preciso caminhar
nessa direção? Antes do entusiasmo natural por soluções de bancos de dados ,
com taxas espetaculares de transação, arquiteturas distribuídas centradas em
HDFS(Hadoop), etc, procure sempre responder isso. Os produtos NoSQL são focados
em diversos domínios de resolução de problemas e você deverá analisar se as
suas dores serão resolvidas por eles.
Resumo:
Conforme mostrado na consideração da palestra
anteriormente discutida, a ênfase dada pelo técnico ao produto Marklogic,
deverá ser cuidadosamente balizada pelo tipo de aplicações que a Igreja Mórmon
desenvolve. No caso ilustrado, há nitidamente uma necessidade de se manipular
altíssimo volume de documentos e oferecer textos, de forma distribuída para uma
grande plateia de consumidores. Os bancos NoSQL não deverão nunca ser
considerados como a solução milagrosa(sem duplo sentido aqui), pois estão
focados em soluções caracterizadas por alto volume de dados especiais(texto,
imagem, etc). São propostas tecnológicas de solução para dados distribuídos,
com forte foco nos A e P do teorema CAP(Consistência), A(Disponibilidade) e P(Particionamento),
ficando o C(de Consistência) adjetivada pelo eventually do acrônimo BASE. Ela
acontecerá, com garantia, porém num tempo adiante. Não sincronamente, como
seria demandado num sistema de controle financeiro de “dízimos”, por exemplo. Aqui
o protocolo ACID dos velhos RDBMS se mostraria muito melhor.
Nenhum comentário:
Postar um comentário