Руководство по кэшированию базы данных

Обзор

Кэш базы данных — это таблица предварительно вычисленных данных, используемая для повышения производительности базы данных за счет сохранения и извлечения рассчитанных данных в высокопроизводительном хранилище. Представьте базу данных как набор связанных между собой таблиц-электронных таблиц с опорными точками: чем больше данных хранит каждая таблица, тем дольше вычисляются результаты. Вместо повторного вычисления по нескольким таблицам по запросу для каждого обращения, кэш сохраняет предварительно вычисленные результаты, чтобы сервер базы данных мог быстро отвечать.

В PokerTracker 4 кэш ускоряет отчеты и графики, но его польза наиболее заметна в HUD. Кэшированные и некэшированные запросы обрабатываются отдельно, поэтому статистика, использующая некэшированные столбцы, вычисляется на лету, и ее обновление в HUD задерживается по мере импорта новых рук — кэшированная статистика HUD по-прежнему отображается отдельно сразу после того, как становится доступной.

Однако отчеты и графики не загружаются поэтапно, поэтому даже одна некэшированная статистика замедляет загрузку всего отчета или графика.

Перестроение кэша базы данных

Иногда кэш базы данных устаревает, что может вызывать проблемы с HUD. Перестроение кэша должно устранить проблему.

Перестройте кэш для активной базы данных

1. В PT4 откройте File > Database > Database Management.
2. Нажмите Rebuild Cache.
3. Выберите Full Cache Rebuild.

примечание

Перестроение может занять некоторое время в зависимости от размера вашей базы данных и производительности компьютера.

Перестроение кэша для других баз данных

Кэш хранится отдельно для каждой базы данных, и перестроение затрагивает только текущую активную базу данных. Чтобы перестроить кэш для другой базы данных, сделайте её активной и повторите шаги выше.

подсказка

Повторите это для каждой базы данных отдельно — перестроить все кэши сразу невозможно.

Статы и колонки

Стат — это математический расчёт данных, взятых из колонок PokerTracker 4. Большинство кэшируемых статов делят столбец базы данных, считающий, как часто было выполнено действие, на столбец, считающий количество возможностей для этого действия.

Слово "Column" используется в двух связанных значениях. PokerTracker 4 Columns находятся на странице Columns в окне Statistics Configuration. Database Columns являются частью самой базы данных и создаются только после того, как стат будет закэширован.

Базы данных состоят из таблиц, а таблицы состоят из столбцов базы данных — примерно как в приведённой выше аналогии с таблицей. Статы — это объекты PokerTracker 4, которых нет в базе данных; они строятся на основе PokerTracker 4 Columns, что позволяет нескольким статам использовать одни и те же строительные блоки без их хранения в базе данных. Когда вы включаете кэш для пользовательской колонки, Database Cache создаёт соответствующую Database Column.

Database Cache в PokerTracker 4

Возьмём для примера стат 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 (обычно используемые в отчётах, сгруппированных By Date), не кэшируются.

Пользовательские статы, использующие стандартные колонки, обычно кэшируются. Однако пользовательские статы, основанные на пользовательских колонках, не могли кэшироваться до PokerTracker 4.11 — первой версии, в которой стало возможным кэшировать пользовательские колонки PokerTracker 4. Начиная с версии 4.11 и выше, HUD и отчёты работают быстрее для пользователей, которые добавляют собственные пользовательские статы или бесплатные статы из PokerTracker Download Warehouse, а также для пользователей сторонних Premium HUD, таких как CoffeeHUD и ProPokerHUD.

Рассмотрим стат Delayed (Turn) CBet из Download Warehouse:

(cnt_t_delayed_cbet / cnt_t_delayed_cbet_opp) * 100

Этот стат использует две пользовательские колонки: cnt_t_delayed_cbet (как часто игрок откладывал CBet до тёрна) и 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 проверяет каждый импортируемый пользовательский стат и автоматически включает кэш, если колонка допускает кэширование. Если вы создаёте пользовательский стат с колонкой, которую нельзя кэшировать, появится сообщение об ошибке, указывающее, что стат не подлежит кэшированию.

Если колонка просто не подлежит кэшированию, пользовательское уведомление не отображается — сообщение об ошибке ниже предназначено для разработчиков пользовательских статов. Обычные пользователи, импортирующие готовые пользовательские статы, полагаются на разработчика, который отвечает за решения по кэшированию.

Исключения кэширования

Следующие типы выражений не могут быть закэшированы.

1. Подзапросы. Например:

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

Подзапрос связывает колонки из разных таблиц. Если бы он кэшировался, обновление этой колонки требовало бы повторного чтения большей части базы данных для каждого игрока в конце каждой раздачи — это слишком медленно для использования во время игры. Даже если подзапрос занимал бы всего 1 мс на игрока, база данных на 100 игроков добавляла бы 100 мс на раздачу при импорте (допустимо), но база данных на 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 должен уметь разбивать кэшируемые статы по абсолютной позиции, по in/out of position для постфлоп-статов, по лимиту и по дате. Без явной ссылки на 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. Турнирные результирующие статы такие как ROI и ITM, потому что кэшироваться могут только колонки, основанные на раздачах.

8. Статы "Group By" — статы, используемые только для разбивки отчётов на несколько строк. Они предназначены для отчётов, а не для HUD.