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

herrera.rp@gmail.com

– Prof. Dr. Alan Salvany Felinto

alan@uel.br

Obrigado.