Apresentação do Meetup São Paulo Cassandra Users, sobre PoC desenvolvia na Everis sobre Desenvolvimento de Sistemas Distribuídos sobre NoSQL Apache Cassandra.

1. PoC Cassandra
Desenvolvimento de Sistemas Distribuídos sobre
NoSQL Apache Cassandra

2. AGENDA!
OBJETIVOS
PROJETO
RESULTADOS
LIÇÕES APRENDIDAS
PoC
Cassandra
PROBLEMAS
APRESENTAÇÃO

3. • 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?

4. 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

5. 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

6. 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

7. 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

8. OBJETIVO - Real
Mainframe Killer

9. 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

10. 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

11. PROJETO

12. PROJETO – Caso de Uso

13. PROJETO

14. PROJETO

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

16. PROJETO – Modelo Físcio

17. 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

18. 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

19. RESULTADO – Modelo Físico Realizado

20. RESULTADO – ARQUITETURA TECNICA REALIZADA

21. RESULTADOS

22. RESULTADOS

23. 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

24. 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

25. 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

26. 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

27. Thanks, we are
delighted to have the
opportunity to
transform with you