O documento apresenta um projeto de Prova de Conceito (PoC) sobre o uso do banco de dados NoSQL Apache Cassandra em um sistema distribuído para o mercado financeiro, destacando objetivos, resultados e lições aprendidas. A PoC teve como foco estressar continuamente o Cassandra, assim como desenvolver ferramentas de controle e observar o desempenho do sistema. Lições aprendidas incluíram a importância de modelagem adequada, manejo de transações e otimização da arquitetura para garantir alta performance.

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