Download - Meetup Everis Cassandra
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