Запросы выполняются в 2 раза быстрее, но некоторые свойства событий станут временными

Фото: Markus Winkler (Unsplash) — https://unsplash.com/photos/a-wooden-table-topped-with-scrabble-tiles-spelling-out-please-be-quiet-YKF7A-S-yRM?utm_source=dev48&utm_medium=referral

Источник: Posthog•

Запросы выполняются в 2 раза быстрее, но некоторые свойства событий станут временными

Коротко: мы перестраиваем способ хранения событий в PostHog, благодаря чему запросы станут в среднем примерно на треть быстрее, а для частых запросов — до 2 раз быстрее. $set, $set…

  • Мы перестраиваем способ хранения событий в PostHog, благодаря чему запросы станут в среднем примерно на треть быстрее, а для частых запросов — до 2 раз быстрее.
  • $set, $set_once и другие недолговечные отладочные свойства событий теперь будут храниться 60 дней вместо бессрочного хранения.
  • События $feature_flag_called и свойства $feature/* перемещаются в выделенное хранилище, созданное специально для них.
  • Мы удаляем некоторые устаревшие свойства, в основном полезные данные флагов и внутреннее состояние SDK.
  • Остальные свойства пользователей и событий остаются без изменений. Они остаются у ваших пользователей и в каждом событии, доступные для запросов, как и раньше.
  • Все эти изменения вступают в силу 30 ноября.

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

Мы переходим на формат, который хранит каждое свойство в единственном экземпляре с его реальным типом (числа остаются числами, булевы значения — булевыми). Это требует гораздо меньше места для хранения, а запрос считывает только те свойства, которые ему нужны.

Вот что мы выяснили, воспроизведя реальные производственные запросы в новом формате:

Воспроизведение, отслеживание ошибок, наблюдаемость ИИ, эксперименты и PostHog AI стали работать быстрее, но для прозрачности отметим: запросы по множеству пользовательских свойств улучшаются меньше всего (некоторые могут даже работать чуть медленнее).

Мы проанализировали, как запрашиваются свойства событий. Небольшой набор, в основном состоящий из диагностики SDK и инструкций по обновлению пользователей вроде $set, полезен для отладки сразу после поступления события. После этого они практически никогда не запрашиваются, но мы хранили их бессрочно для каждого события.

$set и $set_once составляют наибольшую часть этого объема. Это инструкции для нашего движка слияния пользователей («обновите свойства этого пользователя»), которые мы применяем в момент поступления события. Результат сохраняется для пользователя и в каждом событии в качестве свойств пользователя. Бессрочное хранение исходной инструкции также означало дублирование данных: сохранялись как сами свойства, так и инструкции по их изменению.

С 30 ноября 2026 года мы будем хранить эти свойства в течение 60 дней, прежде чем удалять их. Это значит, что вы по-прежнему сможете их просматривать и использовать для отладки, но они не будут вечно содержаться в пользователях или событиях. Это означает меньший объем данных, дублируемых в PostHog, и более быстрые запросы для всех.

Еще один набор событий и свойств, которые мы дублируем, — это флаги функций. Опять же, они в основном используются для отладки флагов и проверки их работоспособности, но при этом замедляют работу остальной таблицы событий. Чтобы предотвратить это, мы переносим события $feature_flag_called в их собственную таблицу, а затем удаляем их через 90 дней. Мы также меняем формат $feature/<flag> с одного свойства для каждого флага на одну карту на каждый флаг.

Вот более подробная информация о том, что это значит:

Эти свойства остаются доступными для запросов в течение 60 дней после получения события, после чего мы их удаляем. Само событие и все остальные его свойства сохраняются в обычном режиме.

Полезно знать:

  • Свойства пользователей не затрагиваются. Мы применяем $set и $set_once к пользователю сразу же при поступлении события. Полученные свойства пользователя остаются в каждом событии и доступны для запросов, как и раньше. Истикю истекает только исходная инструкция в событии.
  • Отсчет 60 дней ведется с момента получения события, а не с метки времени события.
  • Исторические события: 30 ноября события, полученные нами более 60 дней назад (примерно до 1 октября), потеряют $set, $set_once и другие свойства из этой таблицы. Свойства их пользователей будут сохранены.
  • Не затронуты: $sent_at, $sdk_debug_current_session_duration и $debug_images остаются постоянными, так как пользователи применяют их в долгосрочных запросах и для сопоставления ошибок.

Эти свойства устарели, и мы прекратим их хранение в событиях.

Запросы, использующие $active_feature_flags, продолжат работать. HogQL преобразует их в новую карту флагов функций, поэтому существующие инсайты и запросы не сломаются. Для новых запросов используйте карту напрямую.

Сырые полезные данные LLM уже живут в другом месте. $ai_input, $ai_output и остальные перенесены в выделенную таблицу наблюдаемости ИИ с периодом хранения 30 дней, что позволяет удерживать очень тяжелые данные вне таблицы событий и сохранять доступность наблюдаемости ИИ. Любые копии, все еще находящиеся в таблице событий, являются устаревшими данными старше 30 дней, поэтому их удаление ничего не меняет в продукте.

Изменения вступают в силу 30 ноября. Есть вопросы? Обратитесь в службу поддержки.

О чём эта статья