Guia de cache do banco de dados
Visão geral
Um Database Cache é uma tabela de informações pré-calculadas usada para melhorar o desempenho do database, armazenando e recuperando dados calculados em um repositório de alto desempenho. Pense em um database como uma série de tabelas de planilha ligadas por pontos de referência: quanto mais dados cada tabela contém, mais tempo leva para calcular os resultados. Em vez de recalcular sob demanda, em várias tabelas, para cada consulta, o cache armazena resultados pré-calculados para que o servidor de database possa responder rapidamente.
No PokerTracker 4, o cache acelera relatórios e gráficos, mas seu benefício fica mais evidente no HUD. As consultas em cache e sem cache são gerenciadas separadamente, então uma stat que usa colunas sem cache é calculada em tempo real e sua atualização no HUD sofre atraso conforme novas mãos são importadas — as stats do HUD em cache continuam aparecendo separadamente assim que ficam disponíveis.
Relatórios e gráficos, porém, não são carregados em etapas separadas, então uma única stat sem cache reduz o tempo de carregamento de todo o relatório ou gráfico.
Reconstruindo o Database Cache
Ocasionalmente o database cache fica desatualizado, o que pode causar problemas no HUD. Reconstruir o cache deve resolver o problema.
Reconstruir o cache do database ativo
- No PT4, abra File > Database > Database Management.
- Clique em Rebuild Cache.
- Escolha Full Cache Rebuild.
A reconstrução pode levar algum tempo, dependendo do tamanho do seu database e do desempenho do seu computador.
Reconstruindo outros databases
O cache é armazenado separadamente para cada database, e uma reconstrução afeta apenas o database atualmente ativo. Para reconstruir o cache de outro database, defina-o como o database ativo e repita as etapas acima.
Repita isso para cada database individualmente — não há como reconstruir todos os caches de uma vez.
Stats e Columns
Uma stat é um cálculo matemático de dados extraídos das columns do PokerTracker 4. A maioria das stats em cache divide a coluna do database que conta quantas vezes uma ação foi tomada pela coluna que conta as oportunidades para aquela ação.
A palavra "Column" é usada de duas formas relacionadas. As PokerTracker 4 Columns ficam na página Columns, na janela Statistics Configuration. As Database Columns fazem parte do próprio database e só são criadas quando uma stat é colocada em cache.
Databases são feitos de tabelas, e tabelas são feitas de database columns — de forma parecida com a analogia da planilha acima. Stats são "objetos" do PokerTracker 4 que não existem no database; elas são construídas a partir das PokerTracker 4 Columns, o que permite que várias stats compartilhem os mesmos blocos de construção sem que esses blocos sejam armazenados no database. Quando você ativa o cache para uma coluna customizada, o Database Cache cria uma Database Column correspondente.
O Database Cache do PokerTracker 4
Tome a stat 3Bet Preflop como exemplo. Ela divide o número de vezes que um jogador deu 3Bet (armazenado na coluna cnt_p_3bet) pelo número de oportunidades que ele teve para dar 3Bet (armazenado em cnt_p_3bet_opp), e então multiplica por 100 para exibir o resultado como porcentagem.
(cnt_p_3bet / cnt_p_3bet_opp) * 100 = 3Bet Preflop %
Tanto cnt_p_3bet quanto cnt_p_3bet_opp ficam em cache, permitindo que o PostgreSQL os pré-calcule para que a stat apareça no HUD quase instantaneamente.
A maioria das colunas usadas pelas stats padrão embutidas fica em cache. A exceção são as stats que exigem pós-processamento: stats By Time, como Real Hours (comumente usadas em relatórios agrupados By Date), não ficam em cache.
Stats customizadas que usam colunas padrão normalmente ficam em cache. Já stats customizadas que dependem de colunas customizadas não podiam ser colocadas em cache antes do PokerTracker 4.11 — a primeira versão que permitiu colocar em cache colunas personalizadas do PokerTracker 4. No 4.11 e versões posteriores, o desempenho do HUD e dos relatórios é mais rápido para usuários que adicionam stats customizadas feitas por conta própria ou stats gratuitas do PokerTracker Download Warehouse, bem como para usuários de Premium HUDs de terceiros, como CoffeeHUD e ProPokerHUD.
Considere a stat Delayed (Turn) CBet do Download Warehouse:
(cnt_t_delayed_cbet / cnt_t_delayed_cbet_opp) * 100
Essa stat usa duas colunas customizadas: cnt_t_delayed_cbet (com que frequência o jogador adiou sua CBet até o Turn) e cnt_t_delayed_cbet_opp (as oportunidades que ele teve para fazer isso). Nenhuma existe no schema padrão do database, então ambas ficam sem cache no PokerTracker 4.10.9 e anteriores — mas ficam em cache se a stat for importada no 4.11 ou posterior.
Para verificar se uma column está em cache, vá em Configure > Statistics, escolha Cash Games ou Tournaments, depois Players ou Hands, e selecione Columns. Encontre a column e confirme se a caixa Cache está marcada.
Ao importar uma stat customizada, o PokerTracker 4 ativa o cache para toda column que pode ser colocada em cache. Já os desenvolvedores que definem novas columns precisam marcar manualmente a caixa Cache no próprio computador.
Quando uma Column Não Pode Ser Colocada em Cache
Nem toda column pode ser colocada em cache. O PokerTracker 4 analisa cada stat customizada importada e ativa automaticamente o cache quando a column é compatível com cache. Se você criar uma stat customizada com uma column que não pode ser colocada em cache, aparecerá uma mensagem de erro informando que a stat não é compatível com cache.
Não há nenhum aviso visível ao usuário quando uma column simplesmente não é compatível com cache — a mensagem de erro abaixo é destinada a desenvolvedores de stats customizadas. Quem importa stats customizadas predefinidas depende do desenvolvedor, que é responsável pelas decisões de cache.
Exceções de Cache
Os seguintes tipos de expressão não podem ser colocados em cache.
1. Subqueries. Por exemplo:
exists (select 1 from cash_hand_player_statistics chps where chps.flg_hero and chps.id_hand = cash_hand_player_statistics.id_hand)
Uma subquery conecta colunas de tabelas diferentes. Se ela fosse colocada em cache, atualizar essa column exigiria reler a maior parte do database para cada jogador ao final de cada mão — muito lento para uso durante o jogo. Mesmo que uma subquery levasse apenas 1 ms por jogador, um database com 100 jogadores adicionaria 100 ms por mão durante a importação (aceitável), mas um database com 10.000 jogadores adicionaria 10 segundos por mão (inaceitável).
Columns que contêm subqueries ainda são permitidas, mas espere que qualquer stat que precise de uma tenha desempenho tão ruim quanto antes do 4.11.
2–5. Referências a tabelas sem cash_hand_player_statistics. Uma referência a qualquer uma das seguintes só pode ser colocada em cache se a expressão também fizer referência a cash_hand_player_statistics:
- cash_hand_summary
- cash_hand_player_combinations
- cash_limit
- cash_table_session_summary
O PokerTracker 4 precisa ser capaz de quebrar stats que podem ser colocadas em cache por posição absoluta, por em posição/fora de posição para stats pós-flop, por stake e por data. Sem uma referência explícita a cash_hand_player_statistics, essa tabela não pode ser unida — e é essa união que fornece os detalhes de posição, stake e data.
Essa expressão pode ser colocada em cache, porque faz referência tanto a cash_hand_summary quanto a cash_hand_player_statistics:
sum(if[cash_hand_player_statistics.flg_f_saw and cash_hand_summary.amt_mgr > 0, 1, 0])
Essa expressão não pode ser colocada em cache, porque faz referência a cash_hand_summary sem a necessária cash_hand_player_statistics:
sum(if[cash_hand_summary.amt_mgr > 0, 1, 0])
6. Referências a lookup_positions. Essa tabela de lookup não pode ser usada no custom cache; teste diretamente cash_hand_player_statistics.position. Isso dá um pouco mais de trabalho para montar as posições EP e MP, mas é necessário para que as stats funcionem corretamente. Outras lookup tables são válidas — principalmente lookup_actions_p, lookup_actions_f, lookup_actions_t e lookup_actions_r.
7. Stats de resultado de torneio como ROI e ITM, porque apenas columns baseadas em mãos podem ser colocadas em cache.
8. Stats de "Group By" — stats usadas apenas para dividir relatórios em várias linhas. Elas são projetadas para relatórios, não para HUDs.