VoltDB talk at QCON-Brasil

551 visualizações

Publicada em

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

VoltDB talk at QCON-Brasil

  1. 1. Edward Ribeiro – edward.ribeiro@gmail.comHttp://www.twitter.com/edward_ribeiroHttp://www.github.com/eribeiro
  2. 2. Big DataNão vamosdeste BigData...
  3. 3. … mas sim desteBigData.
  4. 4. "The end of an architectural era: (it’s timefor a complete rewrite),"M. Stonebraker, S. Madden, D. J. Abadi, S. Harizopoulos,N. Hachem, and P. Helland, in VLDB ’07: Proceedings ofthe 33rd international conference on Very large databases, 2007, pp. 1150-1160.
  5. 5. OLTP OLAP
  6. 6. OLTP● Transações envolvem pequenas quantidades de dados ● Consultas simples e pontuais (where user_id = ?) ● Acesso a dados indexados ● Operações conhecidas a priori (sem ad hoc) ● Consultas e atualizações frequentes● Dados geralmente cabem em RAM ● Se os dados históricos forem arquivados periodicamente
  7. 7. "OLTP through the looking glass, and what wefound there,"S. Harizopoulos, D. J. Abadi, S. Madden, and M.Stonebraker, in SIGMOD ’08: Proceedings of the2008 ACM SIGMOD international conference onManagement of data, New York, NY, USA, 2008,pp. 981-992.
  8. 8. Divisão de Trabalho
  9. 9. "H-store: a high-performance, distributed mainmemory transaction processing system,"R. Kallman, H. Kimura, J. Natkins, A. Pavlo, A. Rasin, S.Zdonik, E. P. C. Jones, S. Madden, M. Stonebraker, Y.Zhang, J. Hugg, and D. J. Abadi, Proc. VLDB Endow.,vol. 1, iss. 2, pp. 1496-1499, 2008.
  10. 10. Características do VoltDB● Distribuído (sharding)● 100% in-memory● ACID e SQL (sub-set)● Interação entre aplicação e banco somente através de stored procedures
  11. 11. Características do VoltDB● Implementado em C++ (execution engine) e Java (JNI)● Clientes em Java, C++, Ruby*, Erlang*, e http- json ● não tem JDBC/ODBC !!!● Open Source (GPL)● Linux 64 bits
  12. 12. Distribuído● Sharding (particionamento horizontal) ● Cada tabela, uma coluna é usada para o particionamento (tabelas particionadas) ● Transações ordenadas globalmente● Peer-to-Peer (P2P)● Cluster LAN
  13. 13. 100% Memória● Dados + Stored Procedures + Index● 20 * 64 GB = 1.2 TB● MAS ● K-Safety para durabilidade (D em ACID) ● Snapshots em disco
  14. 14. Stored Procedures● A interação entre aplicações clientes e o BD se dá somente através de stored procedures ● SQL ANSI (subset) ● Java● Vantagens: ● Sem bloqueios de usuário ● Reduzir round-trip de rede ● Transação = stored procedure – sucesso → commit, exceção → abort
  15. 15. System Stored Procedures● Chamada síncrona ou assíncrona● Manual de boas práticas para stored procedures ● Não “pesar” a SP ● Maximizar o uso de single partition SP● System Stored Procedures: @AdHoc, @Shutdown, @SnapshotRestore, @SnapshotSave, @Statistics, @SystemInformation, @UpdateApplicationCatalog, @UpdateLogging, etc.
  16. 16. Partições● Uma participação contém: ● Execution Engine (single-threaded) ● Índice ● Dados ● Filas de execução ● Cada partição corresponde a um núcleo de CPU
  17. 17. Partições Work Queue execution engine Table Data Index Data
  18. 18. Transações● Single-partitionupdate pontuacao = 1000 from jogadoreswhere jogador_id = ?;● Multi-partitionselect max(pontuacao) from jogadores;
  19. 19. Single Partition x Multi-Partition select count(*) from orders where customer_id = 5 single-partition select count(*) from orders where product_id = 3 multi-partition insert into orders (customer_id, order_id, product_id) values (3,303,2) single-partition update products set product_name = ‘spork’ where product_id = 3 multi-partition Partition 1 Partition 2 Partition 31 101 2 2 201 1 3 201 1 table orders : customer_id (partition key)1 101 3 5 501 3 6 601 1 (partitioned) order_id product_id4 401 2 5 502 2 6 601 2 1 knife 1 knife 1 knife table products : product_id 2 spoon 2 spoon 2 spoon (replicated) product_name 3 fork 3 fork 3 fork
  20. 20. K-Safety● Disponibilidade, Tolerância a falhas, e Durabilidade● Cada tupla é replicada em um número “k” de máquinas. ● k-1 → uma cópia além do original ● k-2 → duas cópias além do original ● ...
  21. 21. Snapshots● Spooling para disco● Pode ser operação única, a intervalos regulares ou continuamente● Dois propósitos: ● Back-up contra desastres ● Exportar dados “vivos para outros sistemas – Configura-se as tabelas a serem exportadas
  22. 22. Snapshots
  23. 23. Export tables● Permite exportar tabelas para arquivos.● Exporta dados “vivos” ● Quaisquer modificações (insert, update, delete) ● Somente inserções● Tabelas especificadas pelo usuário● Flat files, jdbc/odbc em breve
  24. 24. Performance● A princípio, 45x superior a um BD convencial● Escalabilidade linear ● 300.000 tx/s em ~ 15 nós (commodity PCs) ● 1.000.000 tx/s (hardware high end SGI)● http://www.mysqlperformanceblog.com/2011/02/28/is- voltdb-really-as-scalable-as-they-claim/
  25. 25. Versão Comercial● Command Logging● VoltDB Enterprise Manager
  26. 26. Command Logging● Versão 1.5.5 e posteriores● Spool de chamadas a stored procedures para disco● Não é WAL (sorry trolls...), mas o princípio é o mesmo● Síncrono ou assíncrono.● Buffering e Replay
  27. 27. Casos de Uso (potenciais)● Jogos on-line● Monitoramento do mercado financeiro● Reserva de passagens aéreas on-line● Propaganda on-line● Tracking de pacotes● Registro de chamadas telefônicas● Real-time Analytics● Fonte:http://highscalability.com/blog/2010/12/6/what-the-heck-are-you- actually-using-nosql-for.html
  28. 28. Perspectivas Futuras● Particionamento de Dados Automático● Modelagem Preditiva de Aplicações OLTP● Execução Especulativa● Suporte a WAN● On-the-fly maintenance
  29. 29. ● Acesse!● Estude!● Baixe! (GPL)● Experimente!● Contribua!

×