#Este é um post fechado Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
dê seu feedback
post favorito
Devorando Dados em Java - Java Magazine 79
Examinamos técnicas de programação geralmente classificadas no domínio de ETL ou Data Warehousing, que permitem manipular volumes muito grandes de dados.
Java Magazine 79
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 79
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 79
BRK##: 0 - 0
Devorando Dados em Java
Aplicações de manipulação intensiva de dados com Java e MySQL
Veja como enfrentar requisitos de gravação, leitura e transmissão de dados na ordem de milhões de registros por hora
Neste artigo, vamos abordar a manipulação de dados em grande volume. Este problema não é intrínseco à plataforma Java; é um desafio enfrentado por desenvolvedores que trabalham com sistemas de back-end de todos os tipos, mas o Java – e especialmente o Java EE – é hoje uma das principais plataformas utilizadas para construir tais sistemas.
Os problemas que vamos discutir exigem, em geral, um tratamento holístico, não podendo ser solucionados apenas por alguns passes de mágica de programação – uma API especial aqui, um algoritmo avançado ali. Pode ser também necessário otimizar seu código SQL ou schemas físicos de SGBD; repensar sua arquitetura de comunicação; ajustar estratégias de integração com outros sistemas, e assim por diante. Assim, vamos falar um pouco de Java, mas também um pouco de outras tecnologias e também de arquitetura em geral. Mas para deixar a discussão toda mais concreta, trabalharemos com um exemplo prático de aplicação.
O sistema de Cotações
Nossa aplicação de exemplo trabalha com cotações de ações (stock quotes). Este é um dos exemplos mais “manjados” da área de mensageria / distribuição de dados. Primeiro, os volumes de dados são enormes, frequentemente na ordem de milhares de mensagens por segundo. Para piorar, estes dados frequentemente têm uma logística complexa de distribuição e processamento, e a ação toda deve acontecer em tempo real.
No pior-caso, em aplicações de HFT (high-frequency trading), bancos de investimento usam supercomputadores com softwares que analisam cotações com modelos matemáticos sofisticados, tentando detectar tendências de curtíssimo prazo, e tomam decisões de compra ou venda milissegundos após uma informação decisiva ser disponibilizada. A necessidade de tanta velocidade é a competição – há vários bancos usando a mesma técnica, e não basta tomar a decisão correta, é preciso ser o primeiro a fazê-lo para ficar com o lucro.
Como se parece uma cotação de ações? Um registro completo – que pode ser obtido de um web service público como o popular Yahoo! Finance – inclui informações como as da Tabela 1, entre muita outras que não vamos incluir aqui para não “inchar” o exemplo.
Campo Valor
Símbolo da ação PZE
Valor atual 16.25
Data/Hora da última alteração 15/03/15/2010 04:02
Alteração (fechamento – abertura) -0.19
Valor de abertura 16.44
Valor máximo no dia 16.54
Valor mínimo no dia 16.25
Volume negociado 20590
Tabela 1. Exemplo de registro de cotações (para a Petrobras Energia / NYSE).
Schema de dados
Vamos criar uma tabela relacional, bastante simples, a partir dos nossos campos de cotação. Eu vou usar o MySQL 5.1, mas somente com código SQL ANSI, de forma que a aplicação funcionará em outros SGBDs.
Listagem 1. Tabela para as cotações.
CREATE TABLE QUOTE
(
symbol CHAR(5) NOT NULL,
updateTime DATETIME NOT NULL,
value DECIMAL(10,2) NOT NULL,
valOpen DECIMAL(10,2),
valMin DECIMAL(10,2),
valMax DECIMAL(10,2),
volume DECIMAL(10)
);
ALTER TABLE QUOTE ADD CONSTRAINT PK_QUOTE PRIMARY KEY(symbol, updateTime);
A Listagem 1 mostra a DDL da tabela. Já podemos identificar algumas decisões importantes:
• Não temos nenhuma redundância. Uma coluna para a alteração não é necessária, pois basta subtrair o valor de abertura do valor de fechamento. Também não precisamos de uma coluna para o valor de fechamento, pois este valor é nulo em horários de pregão aberto, e quando não é nulo (pregão fechado) é igual ao valor atual;
• Não temos normalização. Especialmente numa versão mais completa da tabela, um design relacional purista (3NF) determinaria o uso de mais de uma tabela. Esqueça isso. Nossa tabela irá acumular centenas ou milhares de registros por segundo – dezenas de milhões por dia – e queremos dispensar os custos de joins, FKs, etc. Mesmo a chave primária (PK) só foi criada por que esta chave acompanha o índice por symbol + updateTime, importante para consultas à tabela.
Gravando dados
A primeira dica aqui é óbvia: esqueça qualquer ferramenta de persistência de alto nível – JPA, iBatis ou qualquer outra coisa. Você precisará trabalhar somente com JDBC e SQL.
O segundo truque também não é nenhuma novidade: vamos inserir registros em batches, usando as facilidades de PreparedStatement. Porém, o problema não para por aí. Nossa aplicação estará recebendo estes dados continuamente, 24h por dia (imagine que somos alimentados por dados de bolsas de toda parte do mundo: sempre tem algum pregão aberto).
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado
Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
Devorando Dados em Java
Aplicações de manipulação intensiva de dados com Java e MySQL
Veja como enfrentar requisitos de gravação, leitura e transmissão de dados na ordem de milhões de registros por hora
Neste artigo, vamos abordar a manipulação de dados em grande volume. Este problema não é intrínseco à plataforma Java; é um desafio enfrentado por desenvolvedores que trabalham com sistemas de back-end de todos os tipos, mas o Java – e especialmente o Java EE – é hoje uma das principais plataformas utilizadas para construir tais sistemas.
Os problemas que vamos discutir exigem, em geral, um tratamento holístico, não podendo ser solucionados apenas por alguns passes de mágica de programação – uma API especial aqui, um algoritmo avançado ali. Pode ser também necessário otimizar seu código SQL ou schemas físicos de SGBD; repensar sua arquitetura de comunicação; ajustar estratégias de integração com outros sistemas, e assim por diante. Assim, vamos falar um pouco de Java, mas também um pouco de outras tecnologias e também de arquitetura em geral. Mas para deixar a discussão toda mais concreta, trabalharemos com um exemplo prático de aplicação.
O sistema de Cotações
Nossa aplicação de exemplo trabalha com cotações de ações (stock quotes). Este é um dos exemplos mais “manjados” da área de mensageria / distribuição de dados. Primeiro, os volumes de dados são enormes, frequentemente na ordem de milhares de mensagens por segundo. Para piorar, estes dados frequentemente têm uma logística complexa de distribuição e processamento, e a ação toda deve acontecer em tempo real.
No pior-caso, em aplicações de HFT (high-frequency trading), bancos de investimento usam supercomputadores com softwares que analisam cotações com modelos matemáticos sofisticados, tentando detectar tendências de curtíssimo prazo, e tomam decisões de compra ou venda milissegundos após uma informação decisiva ser disponibilizada. A necessidade de tanta velocidade é a competição – há vários bancos usando a mesma técnica, e não basta tomar a decisão correta, é preciso ser o primeiro a fazê-lo para ficar com o lucro.
Como se parece uma cotação de ações? Um registro completo – que pode ser obtido de um web service público como o popular Yahoo! Finance – inclui informações como as da Tabela 1, entre muita outras que não vamos incluir aqui para não “inchar” o exemplo.
Campo Valor
Símbolo da ação PZE
Valor atual 16.25
Data/Hora da última alteração 15/03/15/2010 04:02
Alteração (fechamento – abertura) -0.19
Valor de abertura 16.44
Valor máximo no dia 16.54
Valor mínimo no dia 16.25
Volume negociado 20590
Tabela 1. Exemplo de registro de cotações (para a Petrobras Energia / NYSE).
Schema de dados
Vamos criar uma tabela relacional, bastante simples, a partir dos nossos campos de cotação. Eu vou usar o MySQL 5.1, mas somente com código SQL ANSI, de forma que a aplicação funcionará em outros SGBDs.
Listagem 1. Tabela para as cotações.
CREATE TABLE QUOTE
(
symbol CHAR(5) NOT NULL,
updateTime DATETIME NOT NULL,
value DECIMAL(10,2) NOT NULL,
valOpen DECIMAL(10,2),
valMin DECIMAL(10,2),
valMax DECIMAL(10,2),
volume DECIMAL(10)
);
ALTER TABLE QUOTE ADD CONSTRAINT PK_QUOTE PRIMARY KEY(symbol, updateTime);
A Listagem 1 mostra a DDL da tabela. Já podemos identificar algumas decisões importantes:
• Não temos nenhuma redundância. Uma coluna para a alteração não é necessária, pois basta subtrair o valor de abertura do valor de fechamento. Também não precisamos de uma coluna para o valor de fechamento, pois este valor é nulo em horários de pregão aberto, e quando não é nulo (pregão fechado) é igual ao valor atual;
• Não temos normalização. Especialmente numa versão mais completa da tabela, um design relacional purista (3NF) determinaria o uso de mais de uma tabela. Esqueça isso. Nossa tabela irá acumular centenas ou milhares de registros por segundo – dezenas de milhões por dia – e queremos dispensar os custos de joins, FKs, etc. Mesmo a chave primária (PK) só foi criada por que esta chave acompanha o índice por symbol + updateTime, importante para consultas à tabela.
Gravando dados
A primeira dica aqui é óbvia: esqueça qualquer ferramenta de persistência de alto nível – JPA, iBatis ou qualquer outra coisa. Você precisará trabalhar somente com JDBC e SQL.
O segundo truque também não é nenhuma novidade: vamos inserir registros em batches, usando as facilidades de PreparedStatement. Porém, o problema não para por aí. Nossa aplicação estará recebendo estes dados continuamente, 24h por dia (imagine que somos alimentados por dados de bolsas de toda parte do mundo: sempre tem algum pregão aberto).
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
3 COMENTÁRIOS
Andre
em 28/7/2010 16:24 - Responder
Tem algum local que possa fazer download dos exemplos descritos nesse artigo?
em 28/7/2010 16:24 - Responder
Devmedia - Equipe De Moderação
Andre,
vc baixa os fontes dessa edição através do link http://www.devmedia.com.br/resumo/download.asp?site=6
vc baixa os fontes dessa edição através do link http://www.devmedia.com.br/resumo/download.asp?site=6
em 30/7/2010 20:53 - Responder
Diego Travassos Balduini
em 27/7/2011 17:02 - Responder
Artigo muito bom.
Já coloquei em prática em meu trabalho.
Parabéns!
Já coloquei em prática em meu trabalho.
Parabéns!
em 27/7/2011 17:02 - Responder
[Este post ainda não foi associado a uma sequência]
Você está em:
canal Java
Publicidade
Estudo comparativo entre banco de dados IBM Informix e Microsoft SQL
Osvaldo Pinali Doederlein
Space do autor
é Mestre em Engenharia de Software Orientado a Objetos e Arquiteto de Tecnologia da Visionnaire Informática, trabalhando em projetos de software e prospecção tecnológica.
Space do autor
0
0
Conheça os planos de créditos DevMedia e visualize esse post agora mesmo!