跳到主要内容

Database Caching 指南

概述​

数据库缓存是一张预先计算信息的表，通过将已计算的数据存储并从高性能存储库中读取，以提升数据库性能。可以把数据库想象成一系列通过引用点连接起来的电子表格：每张表包含的数据越多，计算结果所需的时间就越长。与其在每次查询时按需跨多个表重新计算，不如由缓存存储预先计算好的结果，这样数据库服务器就能快速响应。

在 PokerTracker 4 中，缓存可以加快报告和图表的生成，但它在 HUD 中的作用最明显。缓存查询和非缓存查询是分别管理的，因此使用非缓存列的统计会实时计算，并且在导入新手牌时其 HUD 更新会延迟——而缓存的 HUD 统计则会在可用后立即单独显示。

不过，报告和图表不是分阶段加载的，因此只要有一个非缓存统计项，就会拖慢整个报告或图表的加载时间。

重建数据库缓存​

数据库缓存有时会过时，这可能导致 HUD 出现问题。重建缓存应可解决该问题。

为当前活动数据库重建缓存​

  1. 在 PT4 中，打开 File > Database > Database Management。
  2. 点击 Rebuild Cache。
  3. 选择 Full Cache Rebuild。
备注

重建可能需要一些时间，具体取决于数据库大小和电脑性能。

重建其他数据库​

缓存会针对每个数据库单独存储，而且重建只会影响当前活动数据库。要为另一个数据库重建缓存，请将其设为活动数据库，然后重复上述步骤。

提示

请对每个数据库单独重复此操作——无法一次性重建所有缓存。

统计与列​

统计项是基于 PokerTracker 4 列中的数据进行的数学计算。大多数缓存统计项会将数据库列中某项行动发生的次数，除以该行动可发生机会的次数。

“列”一词有两种相关含义。PokerTracker 4 Columns 位于 Statistics Configuration 窗口的 Columns 页面。Database Columns 是数据库本身的一部分，仅在统计项被缓存后才会创建。

数据库由表组成，表由数据库列组成——就像上面的电子表格类比一样。统计项是 PokerTracker 4 中并不存在于数据库里的“对象”；它们由 PokerTracker 4 Columns 构建而成，这使多个统计项可以共享相同的构建块，而这些构建块并不存储在数据库中。为自定义列启用缓存后，Database Cache 会创建一个对应的 Database Column。

PokerTracker 4 的 Database Cache​

以 3Bet Preflop 统计项为例。它将玩家 3Bet 的次数（存储在列 cnt_p_3bet 中）除以其可以 3Bet 的机会次数（存储在 cnt_p_3bet_opp 中），然后乘以 100，以百分比形式显示结果。

(cnt_p_3bet / cnt_p_3bet_opp) * 100 = 3Bet Preflop %

cnt_p_3bet 和 cnt_p_3bet_opp 都是缓存的，因此 PostgreSQL 可以预先计算它们，使该统计项几乎可立即在 HUD 中显示。

默认内置统计项所使用的大多数列都是缓存的。例外是需要后处理的统计项：例如 By Time 统计项，如 Real Hours（通常用于按日期分组的报表），不会被缓存。

使用默认列的自定义统计项通常会被缓存。不过，在 PokerTracker 4.11 之前，依赖自定义列的自定义统计项无法被缓存——4.11 是第一个允许自定义 PokerTracker 4 列被缓存的版本。在 4.11 及更高版本中，添加自制自定义统计项或来自 PokerTracker Download Warehouse 的免费统计项的用户，以及使用第三方 Premium HUD（如 CoffeeHUD 和 ProPokerHUD）的用户，HUD 和报表性能都会更快。

以 Download Warehouse 中的 Delayed (Turn) CBet 统计项为例：

(cnt_t_delayed_cbet / cnt_t_delayed_cbet_opp) * 100

该统计项使用了两个自定义列：cnt_t_delayed_cbet（玩家将 CBet 延迟到 Turn 的频率）和 cnt_t_delayed_cbet_opp（其可以这样做的机会次数）。这两个列都不属于默认数据库架构，因此在 PokerTracker 4.10.9 及更早版本中都不会缓存——但如果该统计项导入到 4.11 或更高版本，则会被缓存。

要确认某个列是否被缓存，请进入 Configure > Statistics，选择 Cash Games 或 Tournaments，然后选择 Players 或 Hands，再选择 Columns。找到该列并确认 Cache 复选框已勾选。

PokerTracker 4 Cache

导入自定义统计项时，PokerTracker 4 会为所有可缓存的列启用缓存。不过，定义新列的开发者必须在自己的电脑上手动勾选 Cache 复选框。

当列无法被缓存时​

并非所有列都可以缓存。PokerTracker 4 会检查每个导入的自定义统计项，并在某列可缓存时自动启用缓存。如果你创建的自定义统计项使用了一个无法缓存的列，就会出现一条错误信息，说明该统计项不可缓存。

如果某列只是不能缓存，界面上不会给出用户可见的提示——下面的错误信息是给自定义统计项开发者看的。普通用户导入预定义的自定义统计项时，需要依赖开发者，而开发者负责缓存方面的决定。

Unable to cache column

缓存例外​

以下表达式类型无法缓存。

1. 子查询。 例如：

exists (select 1 from cash_hand_player_statistics chps where chps.flg_hero and chps.id_hand = cash_hand_player_statistics.id_hand)

子查询会将不同表中的列关联起来。如果将其缓存，那么更新该列时，在每一手结束后都需要为每位玩家重新读取数据库中的大部分内容——这在游戏中使用会太慢。即使子查询对每位玩家只需 1ms，一个 100 人数据库在导入期间每手会增加 100ms（尚可接受），但一个 10,000 人数据库每手会增加 10 秒（不可接受）。

包含子查询的列仍然允许存在，但任何依赖此类列的统计项，其表现都应与 4.11 之前一样差。

2–5. 不包含 cash_hand_player_statistics 的表引用。 对以下任一表的引用，只有在表达式同时引用了 cash_hand_player_statistics 时，才可以缓存：

  • cash_hand_summary
  • cash_hand_player_combinations
  • cash_limit
  • cash_table_session_summary

PokerTracker 4 必须能够按绝对位置、翻牌后统计的有位置/无位置、下注级别以及日期来拆分可缓存统计项。如果没有明确引用 cash_hand_player_statistics，就无法连接该表——而正是这种连接提供了位置、下注级别和日期的详细信息。

这个表达式可以缓存，因为它同时引用了 cash_hand_summary 和 cash_hand_player_statistics：

sum(if[cash_hand_player_statistics.flg_f_saw and cash_hand_summary.amt_mgr > 0, 1, 0])

这个表达式不能缓存，因为它引用了 cash_hand_summary，却没有必要的 cash_hand_player_statistics：

sum(if[cash_hand_summary.amt_mgr > 0, 1, 0])

6. 对 lookup_positions 的引用。 这个查询表不能用于自定义缓存；请直接测试 cash_hand_player_statistics.position。这需要多做一些工作来构建 EP 和 MP 位置，但这是统计项正确运行所必需的。其他查询表没有问题——尤其是 lookup_actions_p、lookup_actions_f、lookup_actions_t 和 lookup_actions_r。

7. Tournament result 统计项，例如 ROI 和 ITM，因为只有基于手牌的列才能被缓存。

8. “Group By” 统计项——仅用于将报表拆分为多行的统计项。它们是为报表设计的，不适用于 HUD。