A Distributed, Multi-Staged, High-ThroughputMiddleware for Relational Databases
Rafael de Paula HerreraProf. Dr. Alan Salvany Felinto
São Paulo, 18 de Maio de 2012VIII Simpósio Brasileiro de Sistemas de Informação (SBSI 2012)
Introdução
● Indústria automotiva de base tecnológica– Monitoramento de veículos em tempo-real
– Logística
● Tendência Principal– Migração para Cloud Computing
● Desafios e Riscos– Sistemas Back-End Legados
– Em produção durante anos
– Aumento de operações, frota e base de usuários
Introdução
● Escalabilidade horizontal comprometida– Dificuldades encontradas
● Alta dependência do RDBMS● Modelo completamente thread-cêntrico● Overhead na leitura/escrita de informações● Estruturas de dados Statefull● Informações centralizadas● Infra-estrutura suscetível a falhas
– Solução proposta● Middleware distribuído● Sobrevida aos sistemas legados● Migração sustentável para novo modelo
Introdução
● O Middleware como agente facilitador de mudanças
Trabalhos Relacionados
● Fail-over de aplicações em tempo-real [Rubel et al. 2006]
● Falhas de BD em aplicações multi-estágios [Barga et al. 2002]
● Serviços back-end interconectados por filas [Urgaonkar et al. 2005]
● Multiplos estágios conectados por filas [Welsh et al. 2001]
● Múltiplos middlewares de cache com BD [Luo et al. 2002]
● Replicação de dados e performance [Cecchet et al. 2007]
Arquitetura
● Middleware reage à presença de dados● Estruturas de dados distribuídas de E/S● Dados replicados ao longo de múltiplos nós● Framework Hazelcast© para Grid● Framework Google© Guice para DI● Design Pattern Inversão de Controle via DI
– DDS substituíveis (baixo nível de acoplamento)
– BlockingQueue (E) / ConcurrentMap (S)
Arquitetura
● Fail-over mínimo com lista-circular de nós– Dados particionados
● Cada nó responde ativamente por sua porção de dados
– Backup automático● [...]● Nó atual faz backup da parte ativa do nó anterior● Próximo nó faz backup da parte ativa do nó atual● [...]
● API Cliente transparente para acesso de DDS– Causa o mínimo impacto nos sistemas legados
– Principais interfaces são mantidas: ResultSet
Arquitetura
● Múltiplos estágios de processamento
Arquitetura
● Nós do Grid
Arquitetura
● Cliente do Grid (API)– Requisita operações
– Recupera resultado de processamento
● Comportamentos implementados– Espera bloqueante
– Espera não-bloqueante
– Espera bloqueante guiada por timeout
– Espera bloqueante guiada por timeout e número de tentativas
Arquitetura
● Requests Queue x Responses Map
Arquitetura
● Requests x SQL Statement x Response x Communication Key
Arquitetura
● Mapeamento
Arquitetura
● Proxy
Arquitetura
● Commiter
Arquitetura
● DB Pool (Apache DBCP)
Resultados
● Proporção de operações SQL conhecidas no sistema
– Experimentos de tempo de bloqueio sobre Updates
– Updates responsáveis por 72.11% das operações
Resultados
● Benchmark comparativo com 30 amostras
● Até 100.000 Requisições procesadas
● Algoritmos tradicionais com acesso direto ao BD
– Single
– Bulk
– Batch
● Algoritmo com acesso indireto ao BD
– Intermediado por fila distribuída● Operações aleatórias
● Intel R CoreTMi3-350M (3M Cache, 2.26 GHz), 4GB DDR3 RAM, Samsung, HM321HI HD e RTL8101E/RTL8102E PCI Express Fast Ethernet controller.
Resultados
Resultados
Conclusão
● Middleware foi capaz de auxiliar o processo de migração
– Ambiente distribuído● Escrita durável e recuperação de falhas
– Desatachadas completamente da aplicação
– Abordagem guiada a eventos
– Reativa à presença de dados nas DDS● Comportamento Statefull reduzido
– Facilita a escalabilidade horizontal
– Redução de riscos perante quedas● Primeiro estágio de migração para Cloud Computing
– Transição suave de sistemas legados
Referências Bibliográficas● Barga, R., Lomet, D., and Weikum, G. (2002). Recovery guarantees for general multi-tier
applications. Data Engineering, International Conference on, 0:0543.● Bisbal, J., Lawless, D., Wu, B., and Grimson, J. (1999). Legacy information systems: Issues and
directions. IEEE Softw., 16:103–111.● Cecchet, E., Candea, G., and Ailamaki, A. (2007). Middleware-based database replication: The gaps
between theory and practice. CoRR, abs/0712.2773.● Fowler, M. (2004). Inversion of control containers and the dependency injection pattern.
http://www.martinfowler.com/articles/injection.html.● Luo, Q., Krishnamurthy, S., Mohan, C., Pirahesh, H., Woo, H., Lindsay, B. G., and Naughton, J. F.
(2002). Middle-tier database caching for e-business. In Proceedings of the 2002 ACM SIGMOD internationalconference on Management of data, SIGMOD ’02, pages 600–611, New York, NY, USA. ACM.
● Martin, R. C. (1996). The dependency inversion principle. C++ Report, 8:61–66.● Rubel, P., Loyall, J. P., Schantz, R. E., and Gillen, M. (2006). Fault tolerance in a multi-layered dre
system: A case study. JCP, 1(6):43–52.● Urgaonkar, B., Pacifici, G., Shenoy, P., Spreitzer, M., and Tantawi, A. (2005). An analytical model for
multi-tier internet services and its applications. SIGMETRICS Perform. Eval. Rev., 33:291–302.● Welsh, M., Culler, D., and Brewer, E. (2001). Seda: an architecture for well-conditioned, scalable
internet services. SIGOPS Oper. Syst. Rev., 35:230–243.● Yang, H. Y., Tempero, E., and Melton, H. (2008). An empirical study into use of dependency injection
in java. In Proceedings of the 19th Australian Conference on Software Engineering, pages 239–247, Washington, DC, USA. IEEE Computer Society.
Agradecimentos
● Universidade Estadual de Londrina (UEL)
– http://uel.br
● Departamento de Computação (DC)
– http://dc.uel.br
● Veltec Soluções Tecnológicas S.A.
– http://veltec.com.br
Dúvidas?
Contato:
– Rafael de Paula Herrera
– Prof. Dr. Alan Salvany Felinto
Obrigado.