PoC Cassandra

Desenvolvimento de Sistemas Distribuídos sobre

NoSQL Apache Cassandra

AGENDA!

OBJETIVOS

PROJETO

RESULTADOS

LIÇÕES APRENDIDAS

PoC

Cassandra

PROBLEMAS

APRESENTAÇÃO

• A everis, uma empresa do grupo NTT DATA • Atualmente tem 13.000 profissionais em 14 países Linhas de Negócios: • Consultoria de negócios • Serviços de tecnologia da informação • Outsourcing • Business Process Outsourcing (BPO) • Soluções SAP

• Iniciativas & Inovação

O que é a everis?

O que é o Laboratório de Inovação Digital?

• Laboratório de Transformação Digital

• Centro de Criação de Ativos em Tecnologia Digital

• Iniciativas:

• Big Data • IoT • Realidade Aumentada • Realidade Virtual • Text Mining • Assistente Virtual

Quem sou eu?

• Formado em Processamento de Dados pela FATEC Sorocaba

• MBA em BI pela FIAP

• Mestrando pela EACH - USP

• Trabalho com Big Data a mais de 2 anos

• Especialista em Sistemas – Big Data na everis

• Certificado Apache Cassandra Developer

OBJETIVO – Principal

A PoC Cassandra visava estressar de modo continuo o banco de dados não relacional (NoSQL) Apache

Cassandra. Para este objetivo foi desenvolvido um caso de uso baseado no mercado financeiro, simulando uma casa de compra e venda de títulos disponíveis na bolsa

de valores eletrônica NASDAQ

OBJETIVOS - Secundários

• Teste de stress

• Conhecer o ciclo de vida de desenvolvimento de projetos com Cassandra

• Conhecer os problemas

• Conhecer as dificuldades no desenvolvimento

• Construir ferramentas de controle

• Observação de desempenho

OBJETIVO - Real

Mainframe Killer

OBJETIVOS – Motivação

Implementou todo o sistema de risco, monitoramento de transações e fornecimento de dados regulatórios sobre Cassandra, distribuído em dois data centers

Utiliza 3 clusters de Cassandra espalhados em 3 cidades diferentes da Holanda para substituir diversos serviços críticos que anteriormente eram processados em dois mainframes do banco. Todos os serviços on-line e de processamento em tempo real foram migrados dos mainframes para os clusters Cassandra

Criou o serviço UBSNeo, um broker para investimento e análise de séries temporais de negócios sobre o Apache Cassandra, distribuído em diversos data centers pelo mundo

EMPRESAS DO RAMO FINANCEIRO QUE UTILIZAM CASSANDRA

• Allied Payment – Provedora americana de serviços de pagamento

• ABC Arbitrage - Empresa financeira especializada no comércio automatizado

• Barracuda Networks – Empresa de serviços de segurança digital e detecção de fraude

• Clear Capital – Provedor de dados e de avaliação de ativos e riscos

• CardSpring - Provedora de APIs de serivços de pagamento de cartão de crédito

• First American Financial - Provedora de serviços financeiro diversos

• F-Secure – Empresa de serviços de segurança e detecção de fraudes

• iDeal – Empresa do grupo ING de provisão de serviços de pagamentos

• Macquarie - Banco de investimento australiano

• PayPal – Provedora de Serviços de Pagamento

• Simililty – Empresa de serviços de segurança e detecção de fraudes

• Venmo – Fincth provedora de serviços de pagamento e carteira digital

• XOOM – Empresa de serviços transferência de fundos financeiros

• Capital One Financial Corporation – Banco Americano

PROJETO

PROJETO – Caso de Uso

PROJETO

PROJETO

PROJETO – Modelo Lógico – Notação Chen

PROJETO – Modelo Físcio

PROBLEMAS – Desenvolvimento do Projeto

• Instalação do Cassandra Driver no Windows

• Apenas 50 Índices por requisição no Google Finance

• Listagem de Clientes muito maior que a capacidade das máquinas

• 1.3milhões de clientes

• Necessários pelo menos 200 agentes para processamento (Problema performance no Python)

• Servidor da Digital Ocean inferia que os testes eram ataques massivos e desligava os servidores

PROBLEMAS – Utilização do Cassandra

• Desenhos das tabelas não atendia todas as querys

• Uso de trace nas consultas deixou o sistema extremamente lento

• Necessidade de join do lado do cliente gerava muitas consultas

• Uso de tabelas como fila (anti-pattern)

• Driver Casssandra só retorna um result da operação se usado Lightweight Transactions (if exists) e para usar LT necessário deletar registro pela Partition Key

• Se usado trace, necessário remodelar a tabela para excluir com dados da chave.

• Python para processar quantidade de transações e sobrecarregar o Cassandra não foi suficiente. Foi necessário criar um host a mais de agentes para sobrecarregar de transações o cluster Cassandra.

• Ao adicionar um novo nó do Cassandra, foi necessário alterar o objeto de conexão adicionando o IP

• (procurar uma forma melhor para fazer isso)

• Tratamento de exceções de erro

• Tratamento das exceções tem de ser específicos

• Métricas do Cassandra precisam ser muito bem estudadas, pois são muitas e um pouco confusas

RESULTADO – Modelo Físico Realizado

RESULTADO – ARQUITETURA TECNICA REALIZADA

RESULTADOS

RESULTADOS

LIÇÕES APRENDIDAS

• Não usar Cassandra como fila

• Usar aplicações apropriadas para este fim (KAFKA, MQs, Filas, etc)

• Desenvolver as tabelas de acordo com as consultas

• Para projetos de grande performance usar linguagens com tipo de dados leves e que trabalham naturalmente com threads e assíncronos (GO, Java, Scala)

• Uso de Lightweight Transactions apenas com as chaves primarias completas

• Ordenação da Cluster Key é importante para consultas

• Usar Cassandra-Metrics para monitorar o cluster (Necessário de instalação de JAR do Grafite) ou configuração do JMS

LIÇÕES APRENDIDAS

• Pensar bem no Consistence Level da aplicação : • Nível alto de consistência apenas para transações

que necessariamente de alto grau de integridade • Não usar execute_assync com consistência alta • Se a execução não alcançar o Consistente Level,

retorna uma exceção

• O tratamento da exceção tem de ser específico, para gerenciar outros erros como de conexão, queda de clusters, timeout, etc.

• Uso de execute_assync na aplicação pode trazer velocidade na aplicação, mas não trás certeza de conclusão da operação

• Usar notação Chebotko ao pé da letra a definir a modelagem de dados do Cassandra

• KDM – Serviço Online Gratuito para modelar Chebotko

LIÇÕES APRENDIDAS

• Aplicação do Repair constante (1 vez por semana pelo menos)

• Diminui a quantidade de disco utilizada pela SSTables

• Pode aumentar a latência de algumas transações durante a aplicação

• Adicionar nós um de cada vez, esperando alguns minutos para adicionar o próximo nó

• Usar collections com moderação (List, Set, Maps)

• Quase tudo que é possível fazer com Collections, você consegue fazer com colunas

• Usar tuplas com moderação

• Nunca usar collections em registros que fazem muitos updates

• Problemas registrados de tombstones nesse caso

LIÇÕES APRENDIDAS

• Aninhar os dados sempre que possível

• Timeuuid necessitam diversas funções auxiliares para geração (Python)

• Timestamps são interessantes para pesquisa de dados – mas é preciso ordenar de forma correta

• Verificar o custo (trade-off) entre duplicação de dados e joins dentro de clientes (Volume x Latência). Para sistemas de baixa latência melhor duplicar os dados nas tabelas

• Projetos precisam de muitos testes para o desenvolvimento

Thanks, we are

delighted to have the

opportunity to

transform with you